Date: Sat, 06 Mar 2010 14:09:26 -0500 From: Adam McDougall <mcdouga9@egr.msu.edu> To: svn-src-all@freebsd.org Subject: Re: svn commit: r203889 - in stable/8/sys: cam cam/ata cam/scsi dev/ahci dev/asr dev/ata dev/ciss dev/hptiop dev/hptrr dev/mly dev/mpt dev/ppbus dev/siis dev/trm dev/twa dev/usb/storage Message-ID: <4B92A866.8070108@egr.msu.edu> In-Reply-To: <4B822FEB.5030901@freebsd.org> References: <201002141938.o1EJcRpx065470@svn.freebsd.org> <4B7D4962.8070706@freebsd.org> <4B7EC763.4090507@FreeBSD.org> <4B81C41F.2080601@freebsd.org> <4B822CD4.5080604@FreeBSD.org> <4B822FEB.5030901@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/22/10 02:19, Lawrence Stewart wrote: > On 02/22/10 18:05, Alexander Motin wrote: >> Lawrence Stewart wrote: >>> On 02/20/10 04:16, Alexander Motin wrote: >>>> Lawrence Stewart wrote: >>>>> I compiled DDB into my r203889 kernel. Unfortunately my ILO emulates a >>>>> USB keyboard so I can't do anything in DDB which is a huge pain, but >>>>> here's the info I did get (hand transcribed): >>>>> >>>>> Fatal trap 12: page fault while in kernel mode >>>>> current process: mpt_raid0 >>>>> Stopped at xpt_rescan+0x1d: movq 0x10(%rsi),%rdx >>>>> >>>>> 1. Any thoughts on how to resolve the regression in the mpt driver >>>>> with >>>>> the r203889 commit? >>>> >>> Perhaps this commit should be backed out of 8-STABLE until we get a >>> chance to diagnose a bit more? >> >> I also have successful reports with this driver, so problem is not >> common. So I don't think it is reasonable to back-out it now. As soon as >> you are the only complaining now, it is only you who can debug the >> issue. So could you be so kind to provide more info? Even without >> keyboard you should be able to get verbose boot messages and full panic >> message. > > Fair enough, if I'm the only person complaining and you've had other > success reports, then that's cool. > > I will get some more info and report back but will have to wait until > later in the week before the machine can be scheduled for some > out-of-hours downtime. > > Cheers, > Lawrence > Short version of my tale below: it might be bad disks... It might be worth mentioning that I discovered similar (but not identical) symptoms today on a Sun Fire v20z with parallel SCSI, no hardware mirroring being used (just zfs/gmirror). I had just reinstalled it to a feb 27 build of 8-stable and encountered trouble while running portsnap extract. I was seeing timeouts, resets, and errors involving both drives. I tried reinstalling with older versions even 8.0-release and still ran into trouble, although on one fresh boot I was watching the console before it started complaining and saw a short burst of messages relating to da1 only: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 0 40 ad 22 0 0 80 0 (da1:mpt0:0:1:0): CAM Status: SCSI Status Error (da1:mpt0:0:1:0): SCSI Status: Check Condition (da1:mpt0:0:1:0): HARDWARE FAILURE info:40ad22 asc:80,87 (da1:mpt0:0:1:0): Vendor Specific ASC field replaceable unit: be (da1:mpt0:0:1:0): Retrying Command (per Sense Data) I haven't looked up the vendor code but I replaced both disks (couldn't easily find the same model as da0 so I replaced both) and so far its fine with the Feb 27 build.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B92A866.8070108>