Release 3.2 kernel issue tracking thread

[notaz]

I think it's better to add some file in /sys or /proc where you can say you don't want your card removed. Then you can add that to startup script or something.


As for fading LED, CPU is turned off so there is nothing left to do the fading effect.

 

[Binky]

Card corruption concerns sounds like they're leaving partial writes pending during suspend?

Could the cards be unmounted in the standard way before suspend. This would ensure that that all writes were complete, and if a program was using it, the suspend could be canceled. Then mount the cards again on wake.

 

[McLovin]

Hey, notaz. Why are there corruptions and to witch card, the old or the new? Wouldn't it be possible to instead call sync before suspending or would the new card still be corrupted because the system thinks it's still the old one? I'm curious.

 

[notaz]

Could the cards be unmounted in the standard way before suspend. This would ensure that that all writes were complete, and if a program was using it, the suspend could be canceled. Then mount the cards again on wake.

It's exactly what it does, and that causes a problem if you boot from SD, rootfs gets lost as it can't be unmounted and the system dies.

Hey, notaz. Why are there corruptions and to witch card, the old or the new? Wouldn't it be possible to instead call sync before suspending or would the new card still be corrupted because the system thinks it's still the old one? I'm curious.

New I guess, don't really know, just saying what I saw in config description.

 

[notaz]

I think it's better to add some file in /sys or /proc where you can say you don't want your card removed. Then you can add that to startup script or something.

It turns out this is already possible, just add:

mmc_core.removable=0

to your autoboot.txt or change

Boot experimental kernel|ubi part rootfs && ubifsmount rootfs && ubifsload ${loadaddr} /lib/boot/uImage && bootm ${loadaddr}

to

Boot experimental kernel|setenv bootargs 'ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw rootflags=bulk_read vram=6272K omapfb.vram=0:3000K mmc_core.removable=0';ubi part rootfs && ubifsmount rootfs && ubifsload ${loadaddr} /lib/boot/uImage && bootm ${loadaddr}

in /boot/bootmenu.txt , depending on what you use.

 

[WizardStan]

My charge LED is periodically turning itself on while the lid is closed. It's done it a few times, no obvious reason, just after some length of time the red LED comes on. It then stays on until I open the lid. I'm experimenting some more to try and determine what in the trigger is actually causing it to come on. Maybe the bq is mismeasuring current flow and detects a positive where there is none, I dunno.


Interesting idea changing the trigger from the twl to the bq, by the way. I'll have to take a look at the source to see how it works now


Loving this extended power saving. Nearly 5 hours of active wifi and still got 65% battery! Did I ever tell you you're awesome?

 

[DaMummy]

so this new kernel not only lasts twice as long on battery, but it also charges itself spontaneously while the lid is closed?

 

[Linux-SWAT]

so this new kernel not only lasts twice as long on battery, but it also charges itself spontaneously while the lid is closed?

As far as i saw, the unit is charging when it consumes few current, ie putting brighness down.

 

[Darkknight512]

I've just noticed another problem but I'm not sure if its the kernel or not.


Nub scrolling is not working for me, nub mouse, joystick and nub buttons work fine.

 

[Galaxis]

I think it's better to add some file in /sys or /proc where you can say you don't want your card removed. Then you can add that to startup script or something.

It turns out this is already possible, just add:

Cool, thanks

 

[Dave18]

This may be a known issue but, it seems that some files within /ssys/devices/omapdss/display0 canot be read. The two I noticed are timings and wss. The fact that timings cannot be read is the first error encountered when trying to use Notaz's SDL Lib as it tries to parse this file:


Others error reported from SDL are:


VSCREENINFO has nothing meaningful


SETUP_PLANE invalid argument.


Cheers


Dave

 

[notaz]

Updated the first post, if something is not right please report. It would be good if someone retested programs that were reported broken on beta1.

 

[WizardStan]

Regarding the wifi autoloading, why not just reverse the script? Instead of turning it on if the setting says to, have the script turn it off if it isn't set.

 

[EvilDragon]

Would it make sense to add the following to the suspend-script?


sync (save current open files)


unmount the card.


If card can't be properly unmounted: Tell the user that the card cannot be properly unmounted and ask whether he really wants to go into suspend to RAM or rather use the classic powersave mode (which still uses a lot less power than before).


If the card can be unmounted, go into suspend to RAM without further questions.


We could also setup a config where you can define to ALWAYS use powersave mode instead of suspend-to-RAM.

 

[urjaman]

I think if you do that script, it should be capable of detecting if the user has added (per above) mmc_core.removable=0 to their kernel commandline, and if so do the sync (just in case), but skip the unmount-attempt and just suspend.

 

[skeezix]

Thats an interesting idea; I mean, a lot of people (like me) never eject .. just use wifi scp or usbnet to do file transfers these days (the days of ejecting SD cards 20 times per minute, as in the gp32 SMC days.. are gone!) -- so really, sync and unmount is fine for me. (Or for peopel who have mature sertups and arenm't changing much.)


Really, ..


Could have a toggle in pref menu ..


Default suspend:


- sync


- kill running pnds


- unmount


- suspend


Or even.. at default:


- sync


- if pnds open -> go to low power mode


- if pnds closed -> unmount and suspend


Optional power user suspend:


- sync


- suspend


hmrf.


As in all things.. even the littlest ideas have many options and take too much time


jeff

 

[McLovin]

option 2 might result in unexpected behaviour if a program is still ghosting around, wouldn't it? Like window closed mustn't mean program/pnd stopped.

 

[Binky]

Perhaps popup a message:

You  have triggered power-saving while running .pnd app(s)

Your Pandora can either go into low-power mode, or suspend entirely to ram (saves more power). Suspending while PNDs are running is unsafe and may corrupt your SD cards - do not remove cards while is suspend mode


You can cancel this dialog, quit PNDs manually then trigger power saving again.


[ ] KILL all pnds now, sync cards, unmount and suspend

[o] use low power mode instead

[ ]suspend anyway (not recomended)


[x] Always do this in future


Going into low power mode in <timer> sec


[OK] [Cancel]

 

[notaz]

There is still a problem with someone running something fullscreen that will overdraw any message boxes.

I mean, a lot of people (like me) never eject .. just use wifi scp or usbnet to do file transfers these days (the days of ejecting SD cards 20 times per minute, as in the gp32 SMC days.. are gone!)

Good for you, when debugging bootloaders/kernel, it's either eject or wait for a full boot to do that..

 

[dsleaf67]

Edit 1: Sorry, post removed and will try and report what the real problem I have is


USB flash drives don't work under new kernel. If I reboot to other kernel they are fine.