oot or log console messages:
> >
> > [...]
> > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD
> > 13.0.
> >
> > Where does this message come from and what is causing the warning? I tried
> > to identify
> > and eliminate this message,
From: Mark Millard
Subject: Re: WARNING: Device "kbd" is Giant locked and may be deleted before
FreeBSD 13.0.
Date: Fri, 15 Jan 2021 16:54:26 -0800
> Other examples for the general type of question . . .
>
>
> For example, various aarch64, armv7, and powerpc*:
>
&g
On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O.
wrote:
> Running FreeBSD CURRENT on a USB only platform with a customised kernel, I
> see this
> message all the time I reboot or log console messages:
>
> [...]
> WARNING: Device "kbd" is Giant locked and may be d
Running FreeBSD CURRENT on a USB only platform with a customised kernel, I see
this
message all the time I reboot or log console messages:
[...]
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
Where does this message come from and what is causing the
On 2021-Jan-12, at 13:11, Mark Millard wrote:
> PowerMac G5's and G4's with not much in them or connected to them report:
>
> WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD
> 13.0.
> WARNING: Device "kbd" is Giant
PowerMac G5's and G4's with not much in them or connected to them report:
WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD
13.0.
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
There is also, using and ex
The list is shorter than it was for an old PowerMac G4
(32-bit powerpc).
For a G5 powerpc64 example running head -r356187 (so
ELFv2):
# dmesg -a | grep Giant
WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD
13.0.
WARNING: Device "kbd" is Gia
Booting head -r356187 on an old G4 PowerMac3,6 shows
the following Giant warnings:
# dmesg -a | grep Giant
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD
1
sjakie kernel log messages:
+FreeBSD 13.0-CURRENT #0 r355527M: Sun Dec 8 19:09:50 CET 2019
+CPU: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz (2400.12-MHz K8-class CPU)
+avail memory = 5144903680 (4906 MB)
+WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0
On 03/10/14 00:45, Oliver Pinter wrote:
critical section held
Hi,
Can you try this patch:
http://svnweb.freebsd.org/changeset/base/262972
I suppose this happens if SCROLL LOCK LED is set while rebooting.
Thank you!
--HPS
___
freebsd-current@freeb
spinlock or
critical section held (sleep mutex) Giant @
/usr/src/sys/dev/usb/input/ukbd.c:1929
[1212048] cpuid = 0
[1212048] KDB: stack backtrace:
[1212048] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0237bcb470
[1212048] kdb_backtrace() at kdb_backtrace+0x39/frame 0xf
> > > I would like to replace Giant with a local sx lock in sysvshm code.
> > > > Looked really straightforward so maybe I missed something.
> > >
> > > At very least, the shmget_existing() is no longer functional.
> > > The sx is owned around tsleep(),
On Tue, Apr 23, 2013 at 11:36:21PM +0200, Mateusz Guzik wrote:
> On Tue, Apr 23, 2013 at 11:55:32PM +0300, Konstantin Belousov wrote:
> > On Tue, Apr 23, 2013 at 10:38:23PM +0200, Mateusz Guzik wrote:
> > > I would like to replace Giant with a local sx lock in sysvshm code.
&
On Tue, Apr 23, 2013 at 11:55:32PM +0300, Konstantin Belousov wrote:
> On Tue, Apr 23, 2013 at 10:38:23PM +0200, Mateusz Guzik wrote:
> > I would like to replace Giant with a local sx lock in sysvshm code.
> > Looked really straightforward so maybe I missed something.
>
&g
On Tue, Apr 23, 2013 at 10:38:23PM +0200, Mateusz Guzik wrote:
> Hello,
>
> I would like to replace Giant with a local sx lock in sysvshm code.
> Looked really straightforward so maybe I missed something.
At very least, the shmget_existing() is no longer functional.
The sx is owned a
Hello,
I would like to replace Giant with a local sx lock in sysvshm code.
Looked really straightforward so maybe I missed something.
Patch: http://people.freebsd.org/~mjg/patches/sysvshm-giant-sx.patch
Inlined version for comments:
diff --git a/sys/kern/sysv_shm.c b/sys/kern/sysv_shm.c
index
On 8/3/2012 5:18 PM, John Baldwin wrote:
>>
>> Seems to apply to RELENG_9 just fine. Are there any stress tests you
>> suggest I run that might expose some bugs ? The machine is not
>> production yet, so its ok to crash it.
>
> Probably pho's stress2 stuff. Thinks like dbench might be a good sta
On 8/10/2012 10:05 AM, John Baldwin wrote:
>
> 5972 tw_cli CALL
> __sysctl(0x7fffd798,0x2,0x7fffd7a0,0x7fffd790,0x7fffd960,0x16)
> 5972 tw_cli SCTL "sysctl.name2oid"
> 5972 tw_cli RET __sysctl -1 errno 2 No such file or directory
> 5972 tw_cli CALL unlink(0x7fff
On 8/10/12 9:52 AM, Mike Tancsa wrote:
> On 8/10/2012 9:31 AM, John Baldwin wrote:
>> On 8/9/12 5:04 PM, Mike Tancsa wrote:
>>> Start up the tw_cli client
>>>
>>> 0{offsite2}# tw_cli
>>> //offsite2> show
>>>
>>> Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
>>> --
On 8/10/2012 9:31 AM, John Baldwin wrote:
> On 8/9/12 5:04 PM, Mike Tancsa wrote:
>> Start up the tw_cli client
>>
>> 0{offsite2}# tw_cli
>> //offsite2> show
>>
>> Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
>> ---
On 8/9/12 5:04 PM, Mike Tancsa wrote:
> Start up the tw_cli client
>
> 0{offsite2}# tw_cli
> //offsite2> show
>
> Ctl Model(V)Ports Drives Units NotOpt RRate VRate BBU
>
> c09650SE-2LP 2 2
ght. I nuked all the kernel files and recompiled
> again, and it no longer panics and I see the entry in /dev now!?
>
> 0{offsite2}# kldload twe
> twe0: <3ware Storage Controller. Driver version 1.50.01.002> port
> 0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27
longer panics and I see the entry in /dev now!?
0{offsite2}# kldload twe
twe0: <3ware Storage Controller. Driver version 1.50.01.002> port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
twe0: 2 ports, Firmware FE8S 1.05.00.068, B
5.00.068, BIOS BE7X 1.08.00.048
> isab0: at device 31.0 on pci0
>
>
> Patch below is causing a panic now on boot. Just going to add debugging
> to the serial console to see what it is and
>
> 0{offsite2}# kldload twe
> twe0: <3ware Storage Controller. Driver version 1
are Storage Controller. Driver version 1.50.01.002> port
0x2000-0x200f mem 0xe281-0xe281000f,0xe200-0xe27f at device
0.0 on pci6
twe0: [GIANT-LOCKED]
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x3
fault code
On 8/9/12 8:22 AM, Mike Tancsa wrote:
> On 8/8/2012 2:39 PM, Mike Tancsa wrote:
>> On 8/8/2012 7:27 AM, John Baldwin wrote:
Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able
to see the 8006 controller I added.
>>>
>>> Ugh, ok. A few questions:
>>>
>>> 1) Does the d
On 8/8/2012 2:39 PM, Mike Tancsa wrote:
> On 8/8/2012 7:27 AM, John Baldwin wrote:
>>> Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able
>>> to see the 8006 controller I added.
>>
>> Ugh, ok. A few questions:
>>
>> 1) Does the driver see any attached drives/volumes?
>
> Yes
On 8/8/2012 7:27 AM, John Baldwin wrote:
>> Looks like it breaks 3dm2 and the tw_cli. With the patch, I am not able
>> to see the 8006 controller I added.
>
> Ugh, ok. A few questions:
>
> 1) Does the driver see any attached drives/volumes?
Yes
>
> 2) If it does, does basic I/O to the drives
On Tuesday, August 07, 2012 10:11:01 AM Mike Tancsa wrote:
> On 8/3/2012 5:26 PM, John Baldwin wrote:
> >>If there's a tool for poking at the drives/controller, I would use
> >>that, plus camcontrol. Of course you want a data intensive workload
> >
> > (iometer/iozone/xdd with async and sy
On 8/3/2012 5:26 PM, John Baldwin wrote:
>> If there's a tool for poking at the drives/controller, I would use
>> that, plus camcontrol. Of course you want a data intensive workload
> (iometer/iozone/xdd with async and sync mode, random reads and sequential
> reads, etc), and maybe resort t
On Friday, August 03, 2012 5:17:09 pm Garrett Cooper wrote:
> On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote:
>
> > On 8/3/2012 3:39 PM, John Baldwin wrote:
> >> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
> >>> I'll try to find time to try it later today, but I'm in the middle of
>
On Friday, August 03, 2012 4:42:59 pm Mike Tancsa wrote:
> On 8/3/2012 3:39 PM, John Baldwin wrote:
> > On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
> >> I'll try to find time to try it later today, but I'm in the middle of
> >> budget wrangling and I can't make any promises.
> >>
> >
On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote:
> On 8/3/2012 3:39 PM, John Baldwin wrote:
>> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
>>> I'll try to find time to try it later today, but I'm in the middle of
>>> budget wrangling and I can't make any promises.
>>>
>>> Before I tr
On 8/3/2012 3:39 PM, John Baldwin wrote:
> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
>> I'll try to find time to try it later today, but I'm in the middle of
>> budget wrangling and I can't make any promises.
>>
>> Before I try, will these patches apply to the twe driver in
>> 9.1-
--
> R. Kevin Oberman, Network Engineer
> E-mail: kob6...@gmail.com
>
> On Fri, Aug 3, 2012 at 11:18 AM, John Baldwin wrote:
> > We only have a few storage drivers left that use Giant and twe(4) is one of
> > them. I don't have any hardware to test with, however.
e to install current right now.
--
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
On Fri, Aug 3, 2012 at 11:18 AM, John Baldwin wrote:
> We only have a few storage drivers left that use Giant and twe(4) is one of
> them. I don't have any hardware to test with, however. I hav
We only have a few storage drivers left that use Giant and twe(4) is one of
them. I don't have any hardware to test with, however. I have verified the
patch compiles, but I'd appreciate it if some folks with twe(4) hardware could
test it.
The patch is at http://www.FreeBSD.org/~j
7;s a more succinct summary of the key points from the wiki:
FreeBSD has supported Giant lock-free file systems for years, and almost all
file systems have been shipping "MPSAFE" for several years. However, VFS
retains compatibility support for non-MPSAFE file systems. We want
eral developers happened
> in order to reduce Giant influence over the entire kernel.
> The VFS layer didn't make an exception, as many several tasks have
> been completed along the years, including fine-grained locking for
> vnodes lifecycle, fine-grained locking of the VFS structure (m
[ Sorry for cross-posting, but I included -arch@ for technical
discussion, -current@ for reaching the wider audience and -fs@ for the
relevance of the matter.]
During the last years a lot of effort by several developers happened
in order to reduce Giant influence over the entire kernel.
The VFS
Am 24.11.2003 um 22:56 schrieb Kris Kennaway:
On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote:
Am 24.11.2003 um 22:19 schrieb Kris Kennaway:
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
This is with a current from around two days ago, with a kernel not
much
differe
On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote:
>
> Am 24.11.2003 um 22:19 schrieb Kris Kennaway:
>
> >On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
> >>This is with a current from around two days ago, with a kernel not
> >>much
> >>different from GENERIC.
> >
> >
Am 24.11.2003 um 22:19 schrieb Kris Kennaway:
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
This is with a current from around two days ago, with a kernel not
much
different from GENERIC.
Known problem.
I do follow -current quite closely, but none of the cvs lists. It
appears t
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
> This is with a current from around two days ago, with a kernel not much
> different from GENERIC.
Known problem.
Kris
pgp0.pgp
Description: PGP signature
This is with a current from around two days ago, with a kernel not much
different from GENERIC.
lock order reversal
1st 0xc48ab234 filedesc structure (filedesc structure) @
/usr/src/sys/kern/sys_generic.c:896
2nd 0xc0729a60 Giant (Giant) @ /usr/src/sys/fs/specfs/spec_vnops.c:377
Stack
In message <[EMAIL PROTECTED]>, David Malone writes:
>On Sat, Aug 16, 2003 at 10:18:43PM +0200, Poul-Henning Kamp wrote:
>> At one point we have to say "Well, the locks we have above are solid,
>> but we need to drop Giant below here" but if Witness sees a
>>
On Sat, Aug 16, 2003 at 10:18:43PM +0200, Poul-Henning Kamp wrote:
> At one point we have to say "Well, the locks we have above are solid,
> but we need to drop Giant below here" but if Witness sees a
> PICKUP_GIANT() as an acquisition of Giant, rather than as a
> resumption
e descriptor lockin
>> >the lock order, or that might sleep.
>>
>> Doesn't this effectively doom any attempt at getting rid af Giant from
>> below ?
>
>I have mixed feelings about our current strategy. [...]
Well, I was thinking more of the work I have been
same issue you've been bumping into for a
> >bit -- we hold filedesc lock over select(), which means every object we
> >poll can't grab a lock that either comes before the file descriptor lockin
> >the lock order, or that might sleep.
>
> Doesn't this effe
poll can't grab a lock that either comes before the file descriptor lockin
> >the lock order, or that might sleep.
>
> Doesn't this effectively doom any attempt at getting rid af Giant
> from below ?
It seems like the locking strategy is wrong (see other LORs in
select() a
oll.
>
>Yeah, this is pretty much the same issue you've been bumping into for a
>bit -- we hold filedesc lock over select(), which means every object we
>poll can't grab a lock that either comes before the file descriptor lockin
>the lock order, or that might sleep.
Doesn&#
On Fri, 15 Aug 2003, Kris Kennaway wrote:
> The problem seems to be due to select() being called on the /dev/null
> device, and it is holding the filedesc lock when it reaches
> PICKUP_GIANT() in spec_poll.
Yeah, this is pretty much the same issue you've been bumping into for a
bit -- we hold fi
On Mon, Aug 11, 2003 at 03:47:02PM -0700, Kris Kennaway wrote:
> > lock order reversal
> > 1st 0xc3d25134 filedesc structure (filedesc structure) @
> > /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:902
> > 2nd 0xc04aa500 Giant (Giant) @
> > /a/asami
Aug 9 11:29:50 dosirak kernel: lock order reversal
Aug 9 11:29:50 dosirak kernel: 1st 0xcf3fa334 filedesc structure (filedesc structure)
@ kern/sys_generic.c:895
Aug 9 11:29:50 dosirak kernel: 2nd 0xc070a8e0 Giant (Giant) @
fs/specfs/spec_vnops.c:372
Aug 9 11:29:50 dosirak kernel: Stack
gt; structure) @ kern/sys_generic.c:895
> > Aug 9 11:29:50 dosirak kernel: 2nd 0xc070a8e0 Giant (Giant) @
> > fs/specfs/spec_vnops.c:372
> > Aug 9 11:29:50 dosirak kernel: Stack backtrace:
> >
> > And that's it (i.e. no backtrace is recorded).
>
> I got this
On Fri, Aug 08, 2003 at 11:11:12PM -0700, Kris Kennaway wrote:
> Aug 9 11:29:50 dosirak kernel: lock order reversal
> Aug 9 11:29:50 dosirak kernel: 1st 0xcf3fa334 filedesc structure (filedesc
> structure) @ kern/sys_generic.c:895
> Aug 9 11:29:50 dosirak kernel: 2nd 0xc070a8e0
On Wed, Aug 13, 2003 at 02:34:15PM -0400, John Baldwin wrote:
>
>
> sendsig() on ia64 drops the lock around the copyout, see line 921 in
> machdep.c. It is not reacquired again until the very end of the
> function. You could change the assert at the top of the function to
> say that sigacts is
Gang,
When the copyout() in sendsig() fails and we call sigexit(), we get
into the following LOR:
lock order reversal
1st 0xe000300ffca8 sigacts (sigacts) @ kern/subr_trap.c:260
2nd 0xe0b75250 Giant (Giant) @ kern/kern_sig.c:2407
Stack backtrace:
witness_lock
Stopped at
On 13-Aug-2003 Marcel Moolenaar wrote:
> Gang,
>
> When the copyout() in sendsig() fails and we call sigexit(), we get
> into the following LOR:
>
> lock order reversal
> 1st 0xe000300ffca8 sigacts (sigacts) @ kern/subr_trap.c:260
> 2nd 0xe0b75250 Giant (
uthorize polling the vnode using
> VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
> WITNESS warning. Unfortunately, it's not immediately clear what a better
> locking scheme would look like without going overboard on the fine-grained
> side. We probably nee
WITNESS warning. Unfortunately, it's not immediately clear what a better
> > locking scheme would look like without going overboard on the fine-grained
> > side. We probably need to grab Giant before entering the select code
> > since it's highly likely something in th
ur MAC code,
> because I need to grab a vnode lock to authorize polling the vnode using
> VOP_POLL(), and since the vnode lock is a sleep lock, this generates a
> WITNESS warning. Unfortunately, it's not immediately clear what a better
> locking scheme would look like without going
de lock is a sleep lock, this generates a
WITNESS warning. Unfortunately, it's not immediately clear what a better
locking scheme would look like without going overboard on the fine-grained
side. We probably need to grab Giant before entering the select code
since it's highly likely some
ic.c:902
> 2nd 0xc04aa120 Giant (Giant) @
> /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
> Stack backtrace:
> backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
> witness_lock(c04aa120,8,c0434e3d,174,1bc) at witness_lock+0x672
> _mtx_lock_flags
After upgrading last night, one of the package machines found this:
lock order reversal
1st 0xc6c1c334 filedesc structure (filedesc structure) @
/a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:902
2nd 0xc04aa120 Giant (Giant) @
/a/asami/portbuild/i386/src-client/sys/fs/specfs
Hi
I just got the following LOR with a kernel and world from today
lock order reversal
1st 0xc49ce134 filedesc structure (filedesc structure) @
/home/k/FreeBSD-src/5-current/src/sys/kern/sys_generic.c:902
2nd 0xc03149e0 Giant (Giant) @
/home/k/FreeBSD-src/5-current/src/sys/fs/specfs
On 17 Jun, Alfred Perlstein wrote:
> * Don Lewis <[EMAIL PROTECTED]> [030617 13:06] wrote:
>> On 17 Jun, Alfred Perlstein wrote:
>> > * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
>> >> It's not legal to attempt to aquire Giant in fdrop_
* Don Lewis <[EMAIL PROTECTED]> [030617 13:06] wrote:
> On 17 Jun, Alfred Perlstein wrote:
> > * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
> >> It's not legal to attempt to aquire Giant in fdrop_locked(), while
> >> FILE_LOCK() is held. The p
ILE_LOCK() held, but the fdrop_locked()
>> implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK(). In
>> addition to violating the proper usage of the "pool mutex", there is
>> also the potential for a lock order violation. The close()
>> implem
On 17 Jun, Alfred Perlstein wrote:
> * Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
>> It's not legal to attempt to aquire Giant in fdrop_locked(), while
>> FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool,
>> which should only be used
ntation calls mtx_lock(&Giant) before calling FILE_UNLOCK(). In
> addition to violating the proper usage of the "pool mutex", there is
> also the potential for a lock order violation. The close()
> implementation grabs Giant and eventually calls fdrop(), which calls
> FIL
* Don Lewis <[EMAIL PROTECTED]> [030617 12:00] wrote:
> It's not legal to attempt to aquire Giant in fdrop_locked(), while
> FILE_LOCK() is held. The problem is that FILE_LOCK uses the mutex pool,
> which should only be used for leaf mutexes.
>
> It also looks like
The FILE_LOCK() implementation uses "pool mutex" under the hood, which
means it should only be used as a leaf level mutex. The fdrop_locked()
code wants to be called with FILE_LOCK() held, but the fdrop_locked()
implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK().
David Malone writes:
> > > This may be my fault, as I made some changes recently that assumed that
> > > the mbuf allocator grabbed giant when needed. I'll check the code path
> > > you've mentioned to see if it grabs giant now, but I suspect that I just
> > This may be my fault, as I made some changes recently that assumed that
> > the mbuf allocator grabbed giant when needed. I'll check the code path
> > you've mentioned to see if it grabs giant now, but I suspect that I just
> > need to move the giant grabbing
t; $FreeBSD: src/sys/vm/vm_kern.c,v 1.97 2003/04/15 01:16:05 alc Exp $
> $FreeBSD: src/sys/kern/subr_mbuf.c,v 1.47 2003/05/02 03:43:40 silby Exp $
>
> I haven't seen this panic previously; a lack of Giant coming out of the
> socket code is a bit surprising to me, but I think is un
On Wed, 28 May 2003, David Malone wrote:
> On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote:
> > I haven't seen this panic previously; a lack of Giant coming out of the
> > socket code is a bit surprising to me, but I think is unlikely to be a
> > resu
On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote:
> I haven't seen this panic previously; a lack of Giant coming out of the
> socket code is a bit surprising to me, but I think is unlikely to be a
> result of our local MAC tweaks.
This may be my fault, as I made some ch
/kern/subr_mbuf.c,v 1.47 2003/05/02 03:43:40 silby Exp $
I haven't seen this panic previously; a lack of Giant coming out of the
socket code is a bit surprising to me, but I think is unlikely to be a
result of our local MAC tweaks.
Robert N M Watson FreeBSD Core Team, TrustedBSD Proje
Hello
When i try to create an RAID array with atacontol I get the following
panic when the rebuild is complete.
The problem seems to be that exit1 requires that giant is held but it
isn't. I have no idea where it should be aquired so it will be released
again.
#0 doadump () at /data/Fr
AIT set. :) Other ideas?
>
I suppose the only alternative is to "do it right" and remove Giant
from the uma zone alloc code.
>From looking at the code for a little while this morning, it looks
like there are 3 allocators that could be called at this point in the
code:
1) page_
err http://people.freebsd.org/~mtm/limits
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The following patches at http://people.freebsd.org/~mtm
remove process resource limits out from under Giant. I have been bouncing
them off jhb for a while now, and I think they are ready. I would appreciate
a review/testing
There are 4 incremental patches for your reviewing pleasure
* John Baldwin <[EMAIL PROTECTED]> [2003-03-25 18.41 -0500]:
Hi John,
> http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's
> except that I patched alpha as well. Similarly untested. Apply
> with patch -p6 while in /sys. Please let me know if it fixes the
> problem.
It fixes th
Martin Karlsson writes:
> * John Baldwin <[EMAIL PROTECTED]> [2003-03-25 18.41 -0500]:
>
> [...snip...]
>
> > http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's
> > except that I patched alpha as well. Similarly untested. Apply
> > with patch -p6 while in /sys. Please l
* John Baldwin <[EMAIL PROTECTED]> [2003-03-25 18.41 -0500]:
[...snip...]
> http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's
> except that I patched alpha as well. Similarly untested. Apply
> with patch -p6 while in /sys. Please let me know if it fixes the
> problem.
Sure, I
* Andrew Gallatin <[EMAIL PROTECTED]> [2003-03-25 18.10 -0500]:
[...snip text...]
> Index: compat/linux/linux_mib.c
> ===
[...snip patch]
Hi! Sure, I'll try it. But, from where (i.e. which directory) should I apply
it, and with whi
On 25-Mar-2003 John Baldwin wrote:
>
> On 25-Mar-2003 Andrew Gallatin wrote:
>>
>> Martin Karlsson writes:
>>
>> > #9 0xc02dca88 in calltrap () at {standard input}:96
>> > #10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
>> > #11 0xc020256e in witness_lock (lock=0x
John Baldwin writes:
>
> Oh, good catch Drew. My bad it seems :( I'll work up a patch.
>
I see this all the time when people add code to our driver, test it
only on linux. So I'm quite used to the symptoms ;)
Thanks,
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
On 25-Mar-2003 Andrew Gallatin wrote:
>
> Martin Karlsson writes:
>
> > #9 0xc02dca88 in calltrap () at {standard input}:96
> > #10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
> > #11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
> "/usr/src
Martin Karlsson writes:
> #9 0xc02dca88 in calltrap () at {standard input}:96
> #10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
> #11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
> "/usr/src/sys/vm/vm_fault.c", line=206)
> at /usr/src
le sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
The first time this happened was with a system built from yesterday's (March 24)
sources. Unloading
linux.ko, and running kldstat produced the panic. I noticed that
/usr/src/sys/vm/vm_fault.c had been
touched since m
On Tue, Jan 07, 2003 at 11:41:33AM -0500, John Baldwin wrote:
> Your 3rd party registered a lock somehow? Does it do mtx_init() and not
> do mtx_destroy() when being unloaded?
Gah! You hit this one right on the head. I thought I had equivalent
mtx_destroy calls for every mtx_init, but t
On 06-Jan-2003 ryan beasley wrote:
> On Sun, Jan 05, 2003 at 08:54:01PM -0600, ryan beasley wrote:
>> I'm including a GDB capture including traceback and some locking
>> information. Anyone have any ideas? Is there any other data I should
>> grab and submit?
>
> I'm really sorry
On Sun, Jan 05, 2003 at 08:54:01PM -0600, ryan beasley wrote:
> I'm including a GDB capture including traceback and some locking
> information. Anyone have any ideas? Is there any other data I should
> grab and submit?
I'm really sorry for following up to myself again, but the fo
d
%p)",
(gdb) p td
$1 = (struct thread *) 0xc1266000
(gdb) p *lock
$2 = {lo_class = 0xc0300fc0, lo_name = 0xc02dbf4a "Giant",
lo_type = 0xc02dbf4a "Giant", lo_flags = 0xb, lo_list = {
tqe_next = 0xc0301120, tqe_prev = 0xc03041f0}, lo_witness = 0xc0330f18}
(gdb) p *td->t
reason entirely, and followed by doing some crazy things until it
finally rebooted itself.
Sources are HEAD from Dec 28th, 2002, 04:00 -0600.
DDB session reprinted below. dmesg at the tail.
Any ideas? :(.
panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c
I just got this on one of the alpha package build machines
Kris
panic: mutex Giant not owned at /local0/src-client/sys/vm/vm_kern.c:312
db_print_backtrace() at db_print_backtrace+0x18
panic() at panic+0x104
_mtx_assert() at _mtx_assert+0xb4
kmem_malloc() at kmem_malloc+0x50
page_alloc() at
On 27-Sep-2002 Poul-Henning Kamp wrote:
> 4. It may not even work at all in the first place. We havn't done
> the VFS locking yet, so dropping giant in specfs may open a pathway
> to the dungeon-dimensions (this is a bad thing).
I actually implemented this very early o
Various people have bugged me for when they could make their drivers
Giant-free and this is an attempt to give them a chance to try that.
There are *MANY* things to be aware of trying to do this, I'll just
list some of them here:
1. Your driver has to be re-entrant on all the cdevs
1 - 100 of 180 matches
Mail list logo
