Hi! According to http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2003/msg03936.html the problem may be related to the <ServerWorks ROSB4 ATA33 controller> and ATA write cache (hw.ata.wc=1). Note however, I had no kernel panic with post-PAE STABLE. I had kernel lockup. I can understand kernel panic due to the faulty devices but not endless loop that it seems to happen. It's known (and noted in the Errata for 4.9-RELEASE) that PAE integration broke hw.ata.tags. Perhaps, its time either to document that hw.ata.wc is broken for noted controller too, either to forbid write cache for it by force. I run my machine using pre-PAE 4.8-STABLE with security patches still. Eugene Grosbein
Eugene Grosbein wrote:> Hi! > > According to > http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2003/msg03936.html > the problem may be related to the <ServerWorks ROSB4 ATA33 controller> > and ATA write cache (hw.ata.wc=1). > > Note however, I had no kernel panic with post-PAE STABLE. > I had kernel lockup. I can understand kernel panic due to the faulty > devices but not endless loop that it seems to happen. > > It's known (and noted in the Errata for 4.9-RELEASE) > that PAE integration broke hw.ata.tags. Perhaps, its time > either to document that hw.ata.wc is broken for noted controller too, > either to forbid write cache for it by force.I have a hard time beliving WC can be the problem. WC is a function of the disk drive it has nothing todo with the controller or even the way we talk to the disk... That said, the ROSB4 is known to be wierd, bad things can easily happend with it in some setups and there is noting we can do about it in SW (less using PIO mode). However some HW vendors seem to have found a HW solution to the problem (ASUS is one of them, my old CUR-DLS doesn't show the problems at all)... -- -S?ren
On Thu, 18 Mar 2004, Eugene Grosbein wrote:> According to > http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2003/msg03936.html > the problem may be related to the <ServerWorks ROSB4 ATA33 controller> > and ATA write cache (hw.ata.wc=1).The problem is with DMA mode on these controllers, not write caching. Write caching may help to get the data rate up fast enough to trigger the bug, and turning it off slows things down. I HIGHLY recommend using a DIFFERENT controller for disks. The ROSB4 is OK for CDROMs and the like, but use a different controller for the system drive. Promise controllers work great. :) ATA tagging is known to work with only a few disk models. You should enable ATA tags ONLY if you KNOW your drive supports it, and test extensively to ensure stability. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Doug White wrote:> ATA tagging is known to work with only a few disk models. You should > enable ATA tags ONLY if you KNOW your drive supports it, and test > extensively to ensure stability.Oops! I think ATA-tagging is broken on Stable? cu rowi -- "Ich glaube, dass die Schwulen-Ehe etwas ist, das einem Mann und einer Frau vorbehalten sein sollte." Arnold Schwarzenegger