After compiling and booting 2.6.18-r2 no drive (nforce2 controller on board, ite8212 as pci card) may be forced into any DMA-mode (mdma, udma) only pio possible. Worked with 2.6.16 and 2.6.17. Module still available, no migration notes, did I miss something? When switching back to 2.6.17 or -16 it works fine and instantly after booting. (all modules same configuration and autoloading, did not change anything in kernel config nor structure [module/static])
Please post "emerge --info" output and attach dmesg from a working kernel and a non-working kernel
Created attachment 102281 [details] emerge --info
Created attachment 102282 [details] working dma dmesg output
dmesg is rather lame, full of senseless FW-logging. But I found a similar problem with Fedora Core 5/6: http://www.linuxquestions.org/questions/showthread.php?t=500089 same for me, no drive has dma enabled, with 2.6.17 and 2.6.16-r9 works out of the box. (switching ite821x of or unplugging it does not change it, e.g. makes dma for onboard controller drives available). BTW I'm not a modprobe nor kernel module expert.
There isnt really any info in that thread, we're going to need to see proper dmesg output to be able to diagnose this. Those log messages look like netfilter log messages, perhaps you could remove rules which do stuff with the log target. You might also be able to get i2c to shut up by not including that in your kernel. You can also increase the dmesg buffer size with CONFIG_LOG_BUF_SHIFT (use the search feature inside menuconfig - type /LOG_BUF_SHIFT<enter>)
As far as I remember I had the same useless information when invoking dmesg with 2.6.18, some BUG DMA, hdparm -tT showed normal behaviour with cached reading but only 1-2MB/s with buffered reading. Every call with hdparm -d 1 returned an operation not permitted and any bit was 0 when retrieving info with hdparm -v. Module loading was always successful but dma not available. What exactly are you looking for in dmesg-output? There was nothing suspicious when booting, no failed modules or something similar. Only recognized it after transferring slowly large archives. I'll need some time to re-install 2.6.18 and remove the spammer modules from autoload list. Maybe tomorrow you'll know more.
I've created 4 attachments, dma* is made with 2.6.16-r9, nodma* with 2.8.18-r2.
Created attachment 102390 [details] hdparm -i for all drives with dma
Created attachment 102391 [details] dmesg, 2.6.18-r2, right after boot
Created attachment 102392 [details] hdparm -i for all drives without dma
Created attachment 102393 [details] dmesg, 2.6.16-9, right after boot
Please also attach kernel .config for both kernels
The problem appears to be that the amd74xx IDE driver is claiming the device in 2.6.16 whereas the generic IDE driver is claiming the device in 2.6.18. This usually boils down to a user error in configuration (e.g. you haven't built amd74xx into 2.6.18, or have built it as a module) http://www.gentoo.org/doc/en/kernel-config.xml
Created attachment 102419 [details] config-2.6.16-r9
Created attachment 102420 [details] config-2.6.18-r2
(In reply to comment #13) > The problem appears to be that the amd74xx IDE driver is claiming the device in > 2.6.16 whereas the generic IDE driver is claiming the device in 2.6.18. This > usually boils down to a user error in configuration (e.g. you haven't built > amd74xx into 2.6.18, or have built it as a module) > http://www.gentoo.org/doc/en/kernel-config.xml > I always built chipset modules as modules, does not matter, either kernel autoloads it or some funky config does that for me (/etc/modules.autoload) after editing. But I could not succeed with any strategy, except running 2.6.16. amd74xx can be loaded but does not change anything, still no dma (found that hint at nvidia's chipset-download-page). Why do I built the module database and do a lot of kernel compiling, if I'm the one who decides which modules must be loaded? Kernel reads something like device registers, recognizes magic numbers and loads something that fits into that slot...why does (lame) audio load at startup with no config at all and (basic) dma not? It's not a user configuration error if chipsets built as modules, there's no necessity to built them into the kernel, SuSE does not do so, Red Hat neither...imagine your mainboard crashes and chipset is built into kernel? How will you recover from that? Righty right, modules, that's what they're here for and no warning at all that one should not do so...if unsure, say 'M'...or write a migration howto esp. for important things like DMA or just post here and I'll transform it into the wiki...but why not first wiki-ing and posting the link here?
2.6.16 config: CONFIG_BLK_DEV_AMD74XX=y 2.6.18 config: CONFIG_BLK_DEV_AMD74XX=m Building modules is not recommended for manual kernel compiles unless you have a strong reason to do so. The kernel configuration guide has some advice here: http://www.gentoo.org/doc/en/kernel-config.xml You may disagree with that, but there is a very significant reason why your disk controller module cannot be loaded when it is built as a module. In the modular case, the amd74xx disk controller module is stored ON DISK, and because the kernel has no way of being able to access the disks at that point (this is what the disk controller allows!) it cannot load that module. Other distro's have no choice but to build disk controller support as modules (there are too many of them to build into the kernel, and they try for a 'one size fits all' base system). The way they work around this is by putting them in an initramfs and ensuring some userspace utility which runs inside the initramfs loads the correct disk controller module before ide-generic is loaded. You can do this with Gentoo as well, either manually or with genkernel, but I wouldn't say that *you* have any reason to add so much extra complexity to the boot sequence.
(In reply to comment #17) > size fits all' base system). The way they work around this is by putting them > in an initramfs and ensuring some userspace utility which runs inside the > initramfs loads the correct disk controller module before ide-generic is > loaded. You can do this with Gentoo as well, either manually or with genkernel, That explains it to 50 percent and it turns from a bug into a basic problem. I wouldn't mind if the kernel boots in non-dma, waits until everything's fine and reloads such modules. There's module unloading and it ought to be possible to make dma available without ramdisk or sophisticated module guessing techniques. Until the kernel is capable of re-initiating chipset modules and generic ide I'll keep it built in. Thanks for patience...
