Prev: get_maintainer.pl: improve config-file support
Next: [patch] libsas: dereferencing variable before check
From: david on 12 May 2010 18:40 I have a couple hundred boxes running kernels from 2.6.12 through 2.6.33.3 that each burn a backup to a IDE CD-ROM once a week. Every couple of months one of the boxes (_not_ the same one each time) runs into some sort of error when burning the CD and the entire box locks up (unable to toggle numlock even). I have not been able to find any correlation between failures and anything on the system. when the system locks up it doesn't log anything, and the screen just freezes in the middle of the cdrecord status (X of Y MB written) with no error message. I'm actually not worried that much about the burn failing, The problem is that the burn failing will take out the entire system. Is there anything that I should be doing to make the systems more robust in the face of such failures? David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Borislav Petkov on 13 May 2010 03:10 From: david(a)lang.hm Date: Wed, May 12, 2010 at 03:35:06PM -0700 > I have a couple hundred boxes running kernels from 2.6.12 through > 2.6.33.3 that each burn a backup to a IDE CD-ROM once a week. Every > couple of months one of the boxes (_not_ the same one each time) > runs into some sort of error when burning the CD and the entire box > locks up (unable to toggle numlock even). I have not been able to > find any correlation between failures and anything on the system. > > when the system locks up it doesn't log anything, and the screen > just freezes in the middle of the cdrecord status (X of Y MB > written) with no error message. > > I'm actually not worried that much about the burn failing, The > problem is that the burn failing will take out the entire system. Is > there anything that I should be doing to make the systems more > robust in the face of such failures? Are you using the ide drivers or libata? If it is the first, try switching to libata to see whether this fixes your freezes. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: david on 13 May 2010 03:30
On Thu, 13 May 2010, Borislav Petkov wrote: > From: david(a)lang.hm > Date: Wed, May 12, 2010 at 03:35:06PM -0700 > >> I have a couple hundred boxes running kernels from 2.6.12 through >> 2.6.33.3 that each burn a backup to a IDE CD-ROM once a week. Every >> couple of months one of the boxes (_not_ the same one each time) >> runs into some sort of error when burning the CD and the entire box >> locks up (unable to toggle numlock even). I have not been able to >> find any correlation between failures and anything on the system. >> >> when the system locks up it doesn't log anything, and the screen >> just freezes in the middle of the cdrecord status (X of Y MB >> written) with no error message. >> >> I'm actually not worried that much about the burn failing, The >> problem is that the burn failing will take out the entire system. Is >> there anything that I should be doing to make the systems more >> robust in the face of such failures? > > Are you using the ide drivers or libata? If it is the first, try > switching to libata to see whether this fixes your freezes. most of the boxes are using the ide drivers. Unfortunantly the problem is very intermittent (every few thousand disks burned I get a problem) I'm upgrading them all to 2.6.33.3 with the libata drivers within the next few days, so we'll see what happens over the next couple of months. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |