NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/39993: lockup on i386 SMP (raidframe related ?)



On Fri, Nov 21, 2008 at 03:20:03PM +0000, Greg Oster wrote:
>  bouyer%antioche.eu.org@localhost writes:
>  > I also have a core dump. The stack traces were indentical in all hangs I 
> got.
>  > disabling SMP at boot (boot -1) work around the problem.
>  > LOCKDEBUG+DEBUG+DIAGNOSTIC does't give any additionnal info. 
>  > This hardware was running without issues under 3.1 with SMP.
>  > 
>  > >How-To-Repeat:
>  >    boot a SMP system with raidframe and generate I/O ?
>  
>  Were it only that simple, I'd be happy...  Unfortunately, I've got a 
>  couple of different boxes w/ 5.0_BETA+SMP+RAIDframe+heavy IO and I 
>  havn't seen this problem at all.. :( 
>  
>  What happens if you do:
>  
>    dd if=/dev/rsd0e of=/dev/null bs=1m &
>    dd if=/dev/rsd1e of=/dev/null bs=1m &
>  
>  where rsd0e and rsd1e are the (raw) components of your RAID set?

works fine (I tried with the different components of the RAID).

I also tried to reproduce it on a athlonx2 with 2 SATA drives, no luck.

other factors that may be relevant:
- when this happens a background parity rewrite is running
- there may be hardware issues with drives (like command timeouts),
  so there may be aborted transfers/I/O errors reported to the raidframe 
  layer.

What I could do it try let it rebuild parity on the UP kernel, and reboot
to the SMP kernel after.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index