From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43c569b2afe10e24fd9aa96244f229af@quanstro.net> To: 9fans@9fans.net From: erik quanstrom Date: Fri, 23 Jan 2009 18:26:04 -0500 In-Reply-To: <509071940901231508y6569a875s99008e8c3bb6b74@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] sick cpu server; 9load hates my SATA controller Topicbox-Message-UUID: 8613e1c0-ead4-11e9-9d60-3106f5b1d025 i have been using a sb600-based machine for a couple of years as a terminal, so i think that your bios configuration might have a lot to do with your problems. it is probablly tickling bugs in the driver. would you be able and willing to try booting the 9load at /n/sources/contrib/quanstro/src/9loadaoe and try the updated kernel driver at /n/sources/contrib/quanstro/src/9/pc/*ahci* ? > About a month ago, the motherboard in my CPU server went bad (visibly > bulging capacitors!). I finally got the replacement part on RMA from > the manufacturer and tried getting things going again yesterday. No > joy, and the problems are strange. The symptoms differ depending on > whether I have drives on sdE[0,1,3] (as was the case before) or > sdE[0,1,2]. that's definately a clue. your bios configuration should be for no raid, all ahci all the time. > sb600: sata-II with 4 ports > sdiahci: drive 0 in state ready after 0 resets > sdiahci: drive 1 in state ready after 0 resets > sdiahci: drive 2 in state missing after 0 resets > sdiahci: drive 3 in state ready after 0 resets > sdE3: i/o error 50 @0 > sdE3: i/o error 50 @1 > > but (as best I can tell) after "state missing" line all I/O becomes > dog slow. Characters print at what looks like maybe 300 baud, newlines > take a few seconds to redraw the screen. likely howling interrupts due to the i/o error. with ahci, this has often been a power management issue. > If I have drives on sdE[0,1,2], the case for the CD is the same, but > the on-disk kernel gets through asking where root is from, and then > yields "panic: fault: 0x11c" as it probes the drives. All the on-disk > kernels perform the same way. sometimes this is caused by sdata getting spurious interrupts. if you continue to have trouble, i would be more than happy to debug this problem offline. just let me know how it goes. - erik