Attilio Rao <[email protected]> wrote in <caj-fndcdow0_b2mv0lzeo-tpea9+7oanj7ihvkqsm4j4b0d...@mail.gmail.com>:
at> 2011/8/17 Hiroki Sato <[email protected]>: at> > Hi, at> > at> > Mike Tancsa <[email protected]> wrote at> > in <[email protected]>: at> > at> > mi> On 7/7/2011 7:32 AM, Mike Tancsa wrote: at> > mi> > On 7/7/2011 4:20 AM, Kostik Belousov wrote: at> > mi> >> at> > mi> >> BTW, we had a similar panic, "spinlock held too long", the spinlock at> > mi> >> is the sched lock N, on busy 8-core box recently upgraded to the at> > mi> >> stable/8. Unfortunately, machine hung dumping core, so the stack trace at> > mi> >> for the owner thread was not available. at> > mi> >> at> > mi> >> I was unable to make any conclusion from the data that was present. at> > mi> >> If the situation is reproducable, you coulld try to revert r221937. This at> > mi> >> is pure speculation, though. at> > mi> > at> > mi> > Another crash just now after 5hrs uptime. I will try and revert r221937 at> > mi> > unless there is any extra debugging you want me to add to the kernel at> > mi> > instead ? at> > at> > I am also suffering from a reproducible panic on an 8-STABLE box, an at> > NFS server with heavy I/O load. I could not get a kernel dump at> > because this panic locked up the machine just after it occurred, but at> > according to the stack trace it was the same as posted one. at> > Switching to an 8.2R kernel can prevent this panic. at> > at> > Any progress on the investigation? at> at> Hiroki, at> how easilly can you reproduce it? It takes 5-10 hours. I installed another kernel for debugging just now, so I think I will be able to collect more detail information in a couple of days. at> It would be important to have a DDB textdump with these informations: at> - bt at> - ps at> - show allpcpu at> - alltrace at> at> Alternatively, a coredump which has the stop cpu patch which Andryi can provide. Okay, I will post them once I can get another panic. Thanks! -- Hiroki
pgpFqPofBZyKa.pgp
Description: PGP signature
