Hiroki Sato wrote
in <20110907.094717.2272609566853905102@allbsd.org>:
hr> During this investigation an disk has to be replaced and resilvering
hr> it is now in progress. A deadlock and a forced reboot after that
hr> make recovering of the zfs datasets take a long time (for committing
h
Attilio Rao wrote
in :
at> This should be enough for someone NFS-aware to look into it.
at>
at> Were you also able to get a core?
Yes. But as kib@ pointed out it seems a deadlock in ZFS. Some
experiments I did showed that this deadlock can be triggered at least
by doing "rm -rf" against a
On Sat, Sep 03, 2011 at 12:05:47PM +0200, Attilio Rao wrote:
> This should be enough for someone NFS-aware to look into it.
>
> Were you also able to get a core?
>
> I'll try to look into it in the next days, in particular about the
> softclock state.
>
I am absolutely sure that this is a zfs d
2011/9/1 Trent Nelson :
>
> On Aug 19, 2011, at 7:53 PM, Attilio Rao wrote:
>
>> If nobody complains about it earlier, I'll propose the patch to re@ in 8
>> hours.
>
> Just a friendly 'me too', for the records. 22 hours of heavy network/disk
> I/O and no panic yet -- prior to the patch it was a
On Aug 19, 2011, at 7:53 PM, Attilio Rao wrote:
> If nobody complains about it earlier, I'll propose the patch to re@ in 8
> hours.
Just a friendly 'me too', for the records. 22 hours of heavy network/disk I/O
and no panic yet -- prior to the patch it was a panic orgy.
Any response from re@
Attilio Rao wrote
in :
at> If nobody complains about it earlier, I'll propose the patch to re@ in 8
hours.
Running fine for 45 hours so far. Please go ahead!
-- Hiroki
pgp3JVRs7kKa0.pgp
Description: PGP signature
If nobody complains about it earlier, I'll propose the patch to re@ in 8 hours.
Attilio
2011/8/19 Mike Tancsa :
> On 8/18/2011 8:37 PM, Chip Camden wrote:
>
>>> st> Thanks, Attilio. I've applied the patch and removed the extra debug
>>> st> options I had added (though keeping debug symbols). I'
Quoth Mike Tancsa on Friday, 19 August 2011:
> On 8/18/2011 8:37 PM, Chip Camden wrote:
>
> >> st> Thanks, Attilio. I've applied the patch and removed the extra debug
> >> st> options I had added (though keeping debug symbols). I'll let you know
> >> if
> >> st> I experience any more panics.
>
On 8/18/2011 8:37 PM, Chip Camden wrote:
>> st> Thanks, Attilio. I've applied the patch and removed the extra debug
>> st> options I had added (though keeping debug symbols). I'll let you know if
>> st> I experience any more panics.
>>
>> No panic for 20 hours at this moment, FYI. For my NFS s
Quoth Hiroki Sato on Friday, 19 August 2011:
> Chip Camden wrote
> in <20110818025550.ga1...@libertas.local.camdensoftware.com>:
>
> st> Quoth Attilio Rao on Thursday, 18 August 2011:
> st> > In callout_cpu_switch() if a low priority thread is migrating the
> st> > callout and gets preempted af
Chip Camden wrote
in <20110818025550.ga1...@libertas.local.camdensoftware.com>:
st> Quoth Attilio Rao on Thursday, 18 August 2011:
st> > In callout_cpu_switch() if a low priority thread is migrating the
st> > callout and gets preempted after the outcoming cpu queue lock is left
st> > (and sched
Quoth Attilio Rao on Thursday, 18 August 2011:
> 2011/8/18 Hiroki Sato :
> > Hiroki Sato wrote
> > in <20110818.043332.27079545013461535@allbsd.org>:
> >
> > hr> Attilio Rao wrote
> > hr> in
> > :
> > hr>
> > hr> at> 2011/8/17 Hiroki Sato :
> > hr> at> > Hi,
> > hr> at> >
> > hr> at> > Mi
On Wed, Aug 17, 2011 at 05:01:05PM -0700, Chip Camden wrote:
> Quoth Jeremy Chadwick on Wednesday, 17 August 2011:
> > >
> > > I'm also getting similar panics on 8.2-STABLE. Locks up everything and I
> > > have to power off. Once, I happened to be looking at the console when it
> > > happened an
2011/8/18 Hiroki Sato :
> Hiroki Sato wrote
> in <20110818.043332.27079545013461535@allbsd.org>:
>
> hr> Attilio Rao wrote
> hr> in :
> hr>
> hr> at> 2011/8/17 Hiroki Sato :
> hr> at> > Hi,
> hr> at> >
> hr> at> > Mike Tancsa wrote
> hr> at> > in <4e15a08c.6090...@sentex.net>:
> hr> at>
2011/8/18 Hiroki Sato :
> Hiroki Sato wrote
> in <20110818.043332.27079545013461535@allbsd.org>:
>
> hr> Attilio Rao wrote
> hr> in :
> hr>
> hr> at> 2011/8/17 Hiroki Sato :
> hr> at> > Hi,
> hr> at> >
> hr> at> > Mike Tancsa wrote
> hr> at> > in <4e15a08c.6090...@sentex.net>:
> hr> at>
Hiroki Sato wrote
in <20110818.043332.27079545013461535@allbsd.org>:
hr> Attilio Rao wrote
hr> in :
hr>
hr> at> 2011/8/17 Hiroki Sato :
hr> at> > Hi,
hr> at> >
hr> at> > Mike Tancsa wrote
hr> at> > in <4e15a08c.6090...@sentex.net>:
hr> at> >
hr> at> > mi> On 7/7/2011 7:32 AM, Mike Tan
Quoth Jeremy Chadwick on Wednesday, 17 August 2011:
> >
> > I'm also getting similar panics on 8.2-STABLE. Locks up everything and I
> > have to power off. Once, I happened to be looking at the console when it
> > happened and copied dow the following:
> >
> > Sleeping thread (tif 100037, pid 0
machine just after it occurred, but
> > according to the stack trace it was the same as posted one.
> > Switching to an 8.2R kernel can prevent this panic.
> >
> > Any progress on the investigation?
> >
> > --
> > spin lock 0x80cb46c0 (sched lock 0)
Attilio Rao wrote
in :
at> 2011/8/17 Hiroki Sato :
at> > Hi,
at> >
at> > Mike Tancsa wrote
at> > in <4e15a08c.6090...@sentex.net>:
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 pa
2011/8/17 Hiroki Sato :
> Hi,
>
> Mike Tancsa wrote
> in <4e15a08c.6090...@sentex.net>:
>
> mi> On 7/7/2011 7:32 AM, Mike Tancsa wrote:
> mi> > On 7/7/2011 4:20 AM, Kostik Belousov wrote:
> mi> >>
> mi> >> BTW, we had a similar panic, "spinlock held too long", the spinlock
> mi> >> is the sched l
On 8/17/2011 1:38 PM, Hiroki Sato wrote:
> Any progress on the investigation?
Unfortunately, I cannot reproduce it yet with a debugging kernel :(
---Mike
>
> --
> spin lock 0x80cb46c0 (sched lock 0) held by 0xff01900458c0 (tid
> 100489) too long
> pan
vy I/O load. I could not get a kernel dump
> because this panic locked up the machine just after it occurred, but
> according to the stack trace it was the same as posted one.
> Switching to an 8.2R kernel can prevent this panic.
>
> Any progress on the investigation?
>
&g
ed one.
Switching to an 8.2R kernel can prevent this panic.
Any progress on the investigation?
--
spin lock 0x80cb46c0 (sched lock 0) held by 0xff01900458c0 (tid
100489) too long
panic: spin lock held too long
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_se
ot; to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> spin lock 0xc0b1d200 (sched lock 1) held by 0xc5dac2e0
on 07/07/2011 14:41 Jeremy Chadwick said the following:
> 1. info threads
> 2. Find the index value that matches the tid in question (in the above
>spin lock panic, that'd be tid 100109). The index value will be
>the first number shown on the left
> 3. thread {index}
Just in case, in kgdb
t; Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> spin lock 0xc0b1d200 (s
arcel-freebsd"...
Unread portion of the kernel message buffer:
spin lock 0xc0b1d200 (sched lock 1) held by 0xc5dac2e0 (tid 100109) too long
panic: spin lock held too long
cpuid = 0
Uptime: 5h37m43s
Physical memory: 2035 MB
Dumping 260 MB: 245 229 213 197 181 165 149 133 117 101 85 69 53 37 2
panic'd tonight with
> >
> > Unread portion of the kernel message buffer:
> > spin lock 0xc0b1d200 (sched lock 1) held by 0xc5dac8a0 (tid 100107) too long
> > panic: spin lock held too long
> > cpuid = 0
> > Uptime: 13h30m4s
> > Physical memory: 2035 MB
> >
lock 0xc0b1d200 (sched lock 1) held by 0xc5dac8a0 (tid 100107) too long
> panic: spin lock held too long
> cpuid = 0
> Uptime: 13h30m4s
> Physical memory: 2035 MB
>
>
> Its a somewhat busy box taking in mail as well as backups for a few
> servers over nfs. At the time, it
I did a buildworld on this box to bring it up to RELENG_8 for the BIND
fixes. Unfortunately, the formerly solid box (April 13th kernel)
panic'd tonight with
Unread portion of the kernel message buffer:
spin lock 0xc0b1d200 (sched lock 1) held by 0xc5dac8a0 (tid 100107) too long
panic: spin
oad and no swap usage, and no panics for 1.5 months until
yesterday]
Yesterday I tried to install Windows 2008, and in the ~6 hours I was
messing around, it panicked around 8 times [after random amounts of time]
panic: spin lock held too long
[cpuid either 2,3, or 4 as far as I remember]
4GB of
2009/9/28 C. C. Tang :
> C. C. Tang wrote:
>>
>> Attilio Rao wrote:
>>>
>>> 2009/9/22 C. C. Tang :
>
>>> I have patched the sched_ule.c and did a make buildkernel & make
>>> installkernel (is buildworld and installworld necessary?), rebooted
>>> and
>>> the
>>> machine i
C. C. Tang wrote:
Attilio Rao wrote:
2009/9/22 C. C. Tang :
I have patched the sched_ule.c and did a make buildkernel & make
installkernel (is buildworld and installworld necessary?),
rebooted and
the
machine is running now.
I will post here again if there is any update.
My server is up fo
Attilio Rao wrote:
2009/9/22 C. C. Tang :
I have patched the sched_ule.c and did a make buildkernel & make
installkernel (is buildworld and installworld necessary?), rebooted and
the
machine is running now.
I will post here again if there is any update.
My server is up for 3.5 days now with H
2009/9/22 C. C. Tang :
>>
>>
I have patched the sched_ule.c and did a make buildkernel & make
installkernel (is buildworld and installworld necessary?), rebooted and
the
machine is running now.
I will post here again if there is any update.
>
> My server is up for 3
I have patched the sched_ule.c and did a make buildkernel & make
installkernel (is buildworld and installworld necessary?), rebooted and the
machine is running now.
I will post here again if there is any update.
My server is up for 3.5 days now with HyperThreading & powerd enabled.
No panic o
2009/9/19 Dan Naumov :
> On Fri, Sep 18, 2009 at 2:25 PM, C. C. Tang wrote:
>>> Attilio Rao wrote:
2009/9/17 C. C. Tang :
>>>
>>> Dan, is that machine equipped with Hyperthreading?
>>>
>>> Attilio
>>
>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT
On Fri, Sep 18, 2009 at 2:25 PM, C. C. Tang wrote:
>> Attilio Rao wrote:
>>>
>>> 2009/9/17 C. C. Tang :
>>
>> Dan, is that machine equipped with Hyperthreading?
>>
>> Attilio
>
> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
> visible in "top" as
Attilio Rao wrote:
2009/9/17 C. C. Tang :
Dan, is that machine equipped with Hyperthreading?
Attilio
Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
visible in "top" as a result)
Yes, mine is also Atom 330.
I cannot test the patch because my machine is also in productio
Attilio Rao wrote:
2009/9/17 C. C. Tang :
Dan, is that machine equipped with Hyperthreading?
Attilio
Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
visible in "top" as a result)
Yes, mine is also Atom 330.
I cannot test the patch because my machine is also in productio
2009/9/17 C. C. Tang :
>>> Dan, is that machine equipped with Hyperthreading?
>>>
>>> Attilio
>>
>> Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
>> visible in "top" as a result)
>
> Yes, mine is also Atom 330.
>
> I cannot test the patch because my machine is also in produc
Dan, is that machine equipped with Hyperthreading?
Attilio
Yes. It's an Intel Atom 330, which is a dualcore CPU with HT (4 cores
visible in "top" as a result)
Yes, mine is also Atom 330.
I cannot test the patch because my machine is also in production now.
But I have tested it with hyperthr
On Mon, Sep 14, 2009 at 3:43 PM, Attilio Rao wrote:
> 2009/7/23 C. C. Tang :
>> Attilio Rao wrote:
>>>
>>> 2009/7/22 C. C. Tang :
>
> Could that one (on i386) be related?
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>
I have no idea about it but I can tell the diff
2009/7/23 C. C. Tang :
> Attilio Rao wrote:
>>
>> 2009/7/22 C. C. Tang :
Could that one (on i386) be related?
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>>> I have no idea about it but I can tell the difference...
>>> My machine panic randomly rather than on shutdown
file is /boot/kernel/kernel
>> Jul 7 03:49:38 atom kernel: spin lock 0x80b3edc0 (sched lock
>> 1) held by 0xff00017d8370 (tid 100054) too long
>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
>>
>> /var/crash looks empty. This is a system run
f80b3edc0 (sched lock
> 1) held by 0xff00017d8370 (tid 100054) too long
> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
>
> /var/crash looks empty. This is a system running official 7.2-p1
> binaries since I am using freebsd-update to keep up with the patches
> The following reply was made to PR kern/134584; it has been noted by GNATS.
>
> From: Attilio Rao
> To: barbara
> Cc: bug-followup , FreeBSD-stable
>
> Subject: Re: kern/134584: [panic] spin lock held too long
> Date: Sun, 26 Jul 2009 16:36:44 +0200
>
> 2009/7
> 2009/7/26 barbara :
> > It happened again, on shutdown.
> > As the previous time, it happened after a high (for a desktop) uptime and,
> > if it could matter, after running net-p2p/transmission-gtk2 for several
> > hours.
> > I don't know if it's related, but often quitting transmission, doesn'
2009/7/26 barbara :
> It happened again, on shutdown.
> As the previous time, it happened after a high (for a desktop) uptime and, if
> it could matter, after running net-p2p/transmission-gtk2 for several hours.
> I don't know if it's related, but often quitting transmission, doesn't
> terminate
2009/7/26 barbara :
> It happened again, on shutdown.
> As the previous time, it happened after a high (for a desktop) uptime and, if
> it could matter, after running net-p2p/transmission-gtk2 for several hours.
> I don't know if it's related, but often quitting transmission, doesn't
> terminate
ng (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...7 6 5 3 1 2 2 0 0 done
All buffers synced.
Uptime: 22h41m12s
Rebooting...
cpu_reset: Stopping other CPUs
spin lock 0xc08ae540 (sc
> In <3bbf2fe10907221748j7f317ce0yc13bc5d01b49...@mail.gmail.com>
> Attilio Rao wrote:
> 2009/7/23 NAKAJI Hiroyuki :
> >> In <4a667469.1080...@gmail.com>
> >> "C. C. Tang" wrote:
> >> > Could that one (on i386) be related?
> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=ker
On Wednesday 22 July 2009 12:30:47 pm Attilio Rao wrote:
> 2009/7/22 C. C. Tang :
> >> Could that one (on i386) be related?
> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
> >>
> >
> > I have no idea about it but I can tell the difference...
> > My machine panic randomly rather than on
On Thu, Jul 23, 2009 at 5:24 AM, C. C. Tang wrote:
> Attilio Rao wrote:
>>
>> 2009/7/22 C. C. Tang :
Could that one (on i386) be related?
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>>> I have no idea about it but I can tell the difference...
>>> My machine panic rand
Attilio Rao wrote:
2009/7/22 C. C. Tang :
Could that one (on i386) be related?
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
I have no idea about it but I can tell the difference...
My machine panic randomly rather than on shutdown and I remembered that it
failed to write core dump. I
2009/7/23 NAKAJI Hiroyuki :
>> In <4a667469.1080...@gmail.com>
>> "C. C. Tang" wrote:
>> > Could that one (on i386) be related?
>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>> >
>
>> I have no idea about it but I can tell the difference...
>> My machine panic randomly rath
> In <4a667469.1080...@gmail.com>
> "C. C. Tang" wrote:
> > Could that one (on i386) be related?
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
> >
> I have no idea about it but I can tell the difference...
> My machine panic randomly rather than on shutdown and I remembere
2009/7/22 C. C. Tang :
>> Could that one (on i386) be related?
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>>
>
> I have no idea about it but I can tell the difference...
> My machine panic randomly rather than on shutdown and I remembered that it
> failed to write core dump. It also
> Could that one (on i386) be related?
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134584
>
I have no idea about it but I can tell the difference...
My machine panic randomly rather than on shutdown and I remembered that
it failed to write core dump. It also failed to reboot automatically.
> > I hope you can get some crash dumps for the developers to look at,
> > Attilio was trying to help me but sadly the machine had to be put into
> > active use so I could no longer play with FreeBSD due to unsolved
> > instability.
>
> I want to help investigate this problem also but I remembered
> I hope you can get some crash dumps for the developers to look at,
> Attilio was trying to help me but sadly the machine had to be put into
> active use so I could no longer play with FreeBSD due to unsolved
> instability.
I want to help investigate this problem also but I remembered that the
/v
>> But is that happening at reboot time?
>>
>> Thanks,
>> Attilio
>>
>
> I think I am also having similar problem on my Atom machine.
> (FreeBSD-7.2-Release-p1)
> It does not happen at boot/reboot but panic randomly.
> And I found that it remains stable for more than a month now after I
> disabled
tom kernel: panic: spin lock held too long
That's a known bug, affecting -CURRENT as well.
The cpustop IPI is handled though an NMI, which means it could
interrupt a CPU in any moment, even while holding a spinlock,
violating one well known FreeBSD rule.
That means that the cpu can stop itself while
>>>> Jul 7 03:49:38 atom kernel: spin lock 0xffffffff80b3edc0 (sched lock
>>>>>> 1) held by 0xff00017d8370 (tid 100054) too long
>>>>>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
>>>>>
>>>>> That
fff80b3edc0 (sched lock
>>>>> 1) held by 0xff00017d8370 (tid 100054) too long
>>>>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
>>>>
>>>> That's a known bug, affecting -CURRENT as well.
>>>> The cpustop IPI
update", /var/log/messages shows the following:
>>>>
>>>> Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel
>>>> Jul 7 03:49:38 atom kernel: spin lock 0x80b3edc0 (sched lock
>>>> 1) held by 0xffffff00017d8370 (tid 100054)
Jul 7 03:49:38 atom syslogd: kernel boot file is /boot/kernel/kernel
>>> Jul 7 03:49:38 atom kernel: spin lock 0x80b3edc0 (sched lock
>>> 1) held by 0xff00017d8370 (tid 100054) too long
>>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
>>
e is /boot/kernel/kernel
>> Jul 7 03:49:38 atom kernel: spin lock 0x80b3edc0 (sched lock
>> 1) held by 0xff00017d8370 (tid 100054) too long
>> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
>
> That's a known bug, affecting -CURRENT as well
f80b3edc0 (sched lock
> 1) held by 0xff00017d8370 (tid 100054) too long
> Jul 7 03:49:38 atom kernel: panic: spin lock held too long
That's a known bug, affecting -CURRENT as well.
The cpustop IPI is handled though an NMI, which means it could
interrupt a CPU in any moment, even
00017d8370 (tid 100054) too long
Jul 7 03:49:38 atom kernel: panic: spin lock held too long
/var/crash looks empty. This is a system running official 7.2-p1
binaries since I am using freebsd-update to keep up with the patches
(just updated to -p2 after this panic) running with very low load,
most
Holger Kipp wrote:
Hi,
I currently encounter
spin lock 0xc0c83ba8 (sio) held by 0xc6337460 (tid 15) too long
panic: spin lock held too long
cpuid=3
on hp server with two dual-core intel xeon (3.8GHz) and 3GB RAM.
System is 7.1-PRELEASE last fetched 29.11.2008, 17:58 UTC.
This happens
Hi,
I currently encounter
spin lock 0xc0c83ba8 (sio) held by 0xc6337460 (tid 15) too long
panic: spin lock held too long
cpuid=3
on hp server with two dual-core intel xeon (3.8GHz) and 3GB RAM.
System is 7.1-PRELEASE last fetched 29.11.2008, 17:58 UTC.
This happens with VSCom Card that was
Original Message
Subject: Re: kern/118044: panic: spin lock held too long
Date: Wed, 14 Nov 2007 15:20:01 GMT
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
To: Per olof Ljungmark <[EMAIL PROTECTED]>
Thank you very much for your problem report.
On Fri, May 11, 2007 at 10:43:54AM -0600, Scott Swanson wrote:
> >> [EMAIL PROTECTED] /usr/src/sys/i386/conf > kldstat
> >> Id Refs AddressSize Name
> >> 13 0xc040 65e308 kernel
> >> 21 0xc0a5f000 59f20acpi.ko
> >
> > So, yes then :) Can you follow the steps for debuggi
>> [EMAIL PROTECTED] /usr/src/sys/i386/conf > kldstat
>> Id Refs AddressSize Name
>> 13 0xc040 65e308 kernel
>> 21 0xc0a5f000 59f20acpi.ko
>
> So, yes then :) Can you follow the steps for debugging modules and see
> if it gives a better trace?
>
> Kris
>
Unfortunatel
On Thu, May 10, 2007 at 07:44:37PM -0600, Scott Swanson wrote:
> >> (kgdb) proc 18303
> >> (kgdb) bt
> >> #0 0xc0644f5b in sched_switch (td=0xc95a5900, newtd=0xc92aad80,
> >> flags=0) at /usr/src/sys/kern/sched_4bsd.c:973
> >> #1 0xeaa6dcb4 in ?? ()
> >> #2 0x0001 in ?? ()
> >> #3 0x0ee2c00
>> (kgdb) proc 18303
>> (kgdb) bt
>> #0 0xc0644f5b in sched_switch (td=0xc95a5900, newtd=0xc92aad80,
>> flags=0) at /usr/src/sys/kern/sched_4bsd.c:973
>> #1 0xeaa6dcb4 in ?? ()
>> #2 0x0001 in ?? ()
>> #3 0x0ee2c000 in ?? ()
>> #4 0x in ?? ()
>> #5 0x4000 in ?? ()
>> #6 0x000
On Thu, May 10, 2007 at 07:13:51PM -0600, Scott Swanson wrote:
> Kris Kennaway wrote:
> > On Thu, May 10, 2007 at 07:00:00PM -0600, Scott Swanson wrote:
> >
> Unread portion of the kernel message buffer:
> spin lock smp rendezvous held by 0xc95a5900 for > 5 seconds
> >>> What is thread 0
Kris Kennaway wrote:
> On Thu, May 10, 2007 at 07:00:00PM -0600, Scott Swanson wrote:
>
Unread portion of the kernel message buffer:
spin lock smp rendezvous held by 0xc95a5900 for > 5 seconds
>>> What is thread 0xc95a5900 doing?
>>>
>>> Kris
>>>
>> Is this the best way to determine the
On Thu, May 10, 2007 at 07:00:00PM -0600, Scott Swanson wrote:
> >> Unread portion of the kernel message buffer:
> >> spin lock smp rendezvous held by 0xc95a5900 for > 5 seconds
> >
> > What is thread 0xc95a5900 doing?
> >
> > Kris
> >
>
> Is this the best way to determine the action of the th
Kris Kennaway wrote:
> On Thu, May 10, 2007 at 02:49:45PM -0600, Scott Swanson wrote:
>> Hello all,
>>
>> I have a couple dozen SuperMicro servers in production and have had
>> reoccurring crashing issues on a couple of them that are under higher
>> load.
>>
>> After managing to pry one out of prod
Kris Kennaway wrote:
> On Thu, May 10, 2007 at 02:49:45PM -0600, Scott Swanson wrote:
>> Hello all,
>>
>> I have a couple dozen SuperMicro servers in production and have had
>> reoccurring crashing issues on a couple of them that are under higher
>> load.
>>
>> After managing to pry one out of prod
tion of the kernel message buffer:
> spin lock smp rendezvous held by 0xc95a5900 for > 5 seconds
What is thread 0xc95a5900 doing?
Kris
> panic: spin lock held too long
> cpuid = 0
> Uptime: 1d3h51m44s
> Dumping 3967 MB (3 chunks)
> chunk 0: 1MB (158 pages) ... ok
> chunk 1:
symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Unread portion of the kernel message buffer:
spin lock smp rendezvous held by 0xc95a5900 for > 5 seconds
panic: spin lock held too long
cpuid = 0
Uptime: 1d3h51m44s
Dumping 3967 MB (3 chunks)
chunk 0: 1MB (158 pages) ... ok
chunk
appreciated.
>
> Unread portion of the kernel message buffer:
> spin lock smp rendezvous held by 0xca78ed80 for > 5 seconds
> panic: spin lock held too long
> cpuid = 2
> Uptime: 14h25m47s
> Dumping 3967 MB (3 chunks)
> chunk 0: 1MB (159 pages) ... ok
> chunk 1: 39
Hi,
A week old -stable panic trace inlined below. The kernel config file
is SMP + KDB/DDB options. Any help to debug futher is appreciated.
Unread portion of the kernel message buffer:
spin lock smp rendezvous held by 0xca78ed80 for > 5 seconds
panic: spin lock held too long
cpuid = 2
Upt
Hello.
Today one of my boxes paniced with "panic: spin lock held too long."
message -- it was online for 6 hours, under rather light load.
Unfortunately, I wasn't able to get any more information, as the box got
restarted by our staff.
Is this, anyway, a known problem (I
I just got a panic with GENERIC 5.3-RELEASE:
Script started on Mon Nov 8 08:42:44 2004
$ cd /usr/src/sys/i386/compile/GENERIC
$ kgdb kernel /var/crash/vmcore.1
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD
88 matches
Mail list logo
