https://bugzilla.novell.com/show_bug.cgi?id=208782 ------- Comment #17 from kern@sibbald.com 2006-10-05 04:36 MST ------- Here are a few points that may help you pinpoint where the problem (at least for me) is coming from. - All my tests are with a tape in the drive. - The sequence of events (simplifed) that cause the error are: fd = open(/dev/nst0) a couple of ioctl() read(fd) errno == EBUSY (system is probably damaged at this point) loop rapidly 30 times redoing the read() system dyes quickly - The OS never crashes unless an EBUSY is returned from the read(). - IMO, I should never be getting an EBUSY, and when I see it, it indicates that the problem is present. - If I reissue the read() multiple times, the problem quickly becomes serious. - If I stop the program after the first EBUSY, the OS most likely will continue running, but is probably damaged, i.e. it will probably crash within the next 10 minutes. - I don't think (a bit uncertain) that the ioctl()s are important as I think I eliminated them but the failure still occurred. - The failure occurs on both dual-core Pentium and single core Pentium machines. - Whether or not the EBUSY is returned seems to be totally bizarre. I can add an unused 8 byte field to a structure, recompile the program, and the OS will crash. I remove the 8 byte field, and the OS will run fine (no EBUSY returned). I guess this in indicative of a kernel locking problem, but why it is repeatably sensitive to a 8 byte position change in the program's data is a mystery to me. - All buffers presented for the read() are from the heap and properly aligned (see the strace output). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.