Next kernel wishlist

[curaga]

It's +80kb not needed by 99%, plus it hardly works nowadays. It gets no testing and no fixes..

[danielibarnes]

It's +80kb not needed by 99%, plus it hardly works nowadays. It gets no testing and no fixes..

It works for me, although I've not tested it extensively. Since the size and user base can't justify inclusion, I'll look into creating a custom kernel. That'll work just as well.

[curaga]

That'd be good. Available for those who need it.

[genec]

What about moving from the old, deprecated ATA drivers to the new Serial/Parallel ATA drivers where possible?

[curaga]

Please read the thread, especially posts 14 and 15

[genec]

Please read the thread, especially posts 14 and 15

Whoops!  Missed that one. 

[hiro]

powertop suggests enabling
-CONFIG_HPET_TIMER and
-CONFIG_NO_HZ for longer sleep times
-CONFIG_INOTIFY allows programs to wait for changes in files and directories
-CONFIG_USB_SUSPEND for disabling UHCI USB when not in use
-CONFIG_CPU_FREQ_GOV_ONDEMAND better speed governor

edit: statistics go into debug kernel

[curaga]

$ egrep 'HPET_TIMER|NO_HZ|INOTIFY|USB_SUSP|ONDEMAND' config-2.6.33.3-tinycore
CONFIG_NO_HZ=y
CONFIG_HPET_TIMER=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_USB_SUSPEND=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y

Powertop is not the smartest app it seems I recall it suggested I enable usb and sound suspend, when I already had them enabled, just with a different timeout than the one powertop expected.

[hiro]

Strange. IIRC there were power usage improvements when I let powertop enable USB suspending.
I'll check again

[gerald_clark]

How about nbd module?

[curaga]

OK, will add nbd.

[maro]

Not so much a particular wish (at this stage), but more of a point I'd suggest to put on a dedicated list of test scenarios: During the 3.x phase we've seen repeatedly DMA problems with CD-ROM devices (mostly on older systems). The most recent one has triggered me to write this post.

I am one who still owns such a system, but I pretty much only boot it with TC to investigate for example possible hardware issues. I've noticed a kind of regression in the "out of the box" behaviour in this area between TC 2.x and 3.x: there are warnings etc. when booting 2.6.11, but it will eventually work, whilst 3.x gets "fatally stuck" on this problem (if not using the 'ide-core.nodma' boot code). Combine this with reports that others (like Puppy) are not showing those problems one likes to think that we've got an "unfortunate" kernel config in 3.x.

I don't think it's serious enough to try to track it down on the current kernel, but I think it would be worth comparing kernel configs of others (like Puppy) and attempting to test things when we move to a new kernel.

[curaga]

I don't have any hw that fails DMA. But with the transition to libata, the issue is likely to go away.

[curaga]

I'm liking the new build so far Also, my new netbook shows the floppy issue, so I can confirm that delay gone.

Qemu before-after:
 

AMD netbook before-after:
 

[hiro]

So now the whole base will be booted faster than some of our extensions need to get mounted, hah