|Summary:||[2.6.20 regression] libata/sata_nv lockup|
|Product:||Gentoo Linux||Reporter:||STefan <Nuckerl.Stefan>|
|Component:||[OLD] Core system||Assignee:||Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel>|
|Package list:||Runtime testing required:||---|
Kernlog showing ata failures
Description STefan 2007-04-29 11:40:28 UTC
I upgraded yesterday to the latest gentoo kernel. I upgraded from 2.6.19-gentoo-r5, used the oldconfig with make oldconfig and rebuild the kernel, basically without changing the config. Now after aprox. 10-30 min my system locks up with some ata problem. I can reproduce it every time. I'm back to 2.6.19-gentoo-r5, System is running fine again. Reproducible: Always
Comment 1 STefan 2007-04-29 11:43:12 UTC
Created attachment 117629 [details] Kernlog showing ata failures
Comment 2 Daniel Drake (RETIRED) 2007-04-29 16:49:38 UTC
Can you explain the lockup in more detail? i.e. does the entire system hang or what? Can you reproduce this with the latest kernel, currently 2.6.21? Please also attach dmesg output from a working 2.6.19 kernel.
Comment 4 STefan 2007-04-29 18:18:44 UTC
Attached a 2.6.19 bootlog. The lockup basically locks up anything that needs to access the filesystem, for example I can switch through my virtual consoles, and I can select windows, but that's about it. I have just compiled a stock 2.6.21 kernel and will check later on
Comment 5 STefan 2007-04-29 18:46:46 UTC
Okay, that was a quick one. I booted with 2.6.21 and it took only about 5 mintues until it locked up again. Since my box also looks up with the latest stable kernel from kernel.org. I will contact firstname.lastname@example.org directly and keep you updated.
Comment 6 Daniel Drake (RETIRED) 2007-05-06 15:07:42 UTC
Was the 2.6.19 log generated just after boot or does it include a few hours of uptime? I'm specifically interested in seeing a few hours of uptime so that we can see if there were any errors detected but they were gracefully handled on older kernels.
Comment 7 STefan 2007-05-12 22:29:41 UTC
Hi Daniel, I contacted the sata_nv maintainers, they suspect some hardware issue, it only occurs if ADMA is enabled which is the default option on kernels > 2.6.19. If I disable ADMA with: sata_nv.adma=0 the problem won't occur. I have already changed cables, once I have time for it I will also replace my sata drive to see if there is a problem with my samsung drive, because the status flags in my kern log show link errors reported by the controller. So right now this does not look like a software bug but rather hardware failure or hardware bug.
Comment 8 STefan 2007-05-13 21:36:28 UTC
I have replaced one of the 2 drives (the 400GB Samsung) with another 160GB Seagate, the problem goes away and I don't get any crash. I've notified libata maintainers that there may be an issue with the combination NFORCE4 + SAMSUNG HD401LJ + ADMA --Stefan
Comment 9 Daniel Drake (RETIRED) 2007-05-14 22:54:01 UTC
OK. we'll leave it for upstream to figure out.