We have a nubmer of similar machines that were initiallly formated with 6.2 before it was released and have subsequently been upgraded to 6.2-RELEASE with no issues. So, we upgraded a 6.1 box which has been running fine as long as the nightly dumps do not use -L to take snapshots. Once it was upgraded to 6.2, we enabled -L on the nightly dumps and it hung on the first try. So, I'm suspecting that 6.1 has left SOMEthing on the filesystem which is corrupt. For the moment. we have once again removed -L from the nightly dumps but, other than a complete fsck, is there any other suggested action? 6.2-RELEASE twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x9c00-0x9c0f mem 0xfc9ffc00-0xfc9ffc0f,0xfc000000-0xfc7fffff irq 20 at device 1.0 on pci2 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 /\/\ \/\/
On Wed, Jan 31, 2007 at 02:24:35AM -0500, Michael R. Wayne wrote:> We have a nubmer of similar machines that were initiallly formated > with 6.2 before it was released and have subsequently been upgraded > to 6.2-RELEASE with no issues. So, we upgraded a 6.1 box which has > been running fine as long as the nightly dumps do not use -L to > take snapshots. > > Once it was upgraded to 6.2, we enabled -L on the nightly dumps and > it hung on the first try. So, I'm suspecting that 6.1 has left > SOMEthing on the filesystem which is corrupt. For the moment. we > have once again removed -L from the nightly dumps but, other than > a complete fsck, is there any other suggested action? > > 6.2-RELEASE > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x9c00-0x9c0f mem 0xfc9ffc00-0xfc9ffc0f,0xfc000000-0xfc7fffff irq 20 at device 1.0 on pci2 > twe0: [GIANT-LOCKED] > twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048See kernel deadlock debugging chapter from the developer handbook for instructions on how to properly report deadlock. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070131/a6f85582/attachment.pgp
On Wed, Jan 31, 2007 at 11:28:16AM +0200, Kostik Belousov wrote:> On Wed, Jan 31, 2007 at 02:24:35AM -0500, Michael R. Wayne wrote: > > We have a nubmer of similar machines that were initiallly formated > > with 6.2 before it was released and have subsequently been upgraded > > to 6.2-RELEASE with no issues. So, we upgraded a 6.1 box which has > > been running fine as long as the nightly dumps do not use -L to > > take snapshots. > > > > Once it was upgraded to 6.2, we enabled -L on the nightly dumps and > > it hung on the first try. So, I'm suspecting that 6.1 has left > > SOMEthing on the filesystem which is corrupt. For the moment. we > > have once again removed -L from the nightly dumps but, other than > > a complete fsck, is there any other suggested action? > > > > 6.2-RELEASE > > twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0x9c00-0x9c0f mem 0xfc9ffc00-0xfc9ffc0f,0xfc000000-0xfc7fffff irq 20 at device 1.0 on pci2 > > twe0: [GIANT-LOCKED] > > twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 > > See kernel deadlock debugging chapter from the developer handbook for > instructions on how to properly report deadlock.I replied privately with no result, so I'll try the list again. As I read the "kernel deadlock debugging chapter", I see that it operates on core dumps. Once the machine enters this state, my only recourse is to power cycle (shutdown hangs forever, processes never die, etc). No disk writes seem to survive the reboot so if I'm going to debug it, it has to be while the system is live but hung. I'll re-iterate that it's tied to -L on dumps, no problems since removing that option. Suggestions welcome. /\/\ \/\/