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
>> PICKUP_GIANT() as an acquisition of Gia
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 of Giant, this clearly
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>
>On Sat, 16 Aug 2003, Poul-Henning Kamp 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, t
On Sat, 16 Aug 2003, Poul-Henning Kamp 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
On Sat, Aug 16, 2003 at 09:12:27AM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Robe
> rt Watson writes:
> >
> >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 l
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>
>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
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/portbuild/i386/src-client/sys/fs
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 backt
On Mon, Aug 11, 2003 at 03:09:32PM -0700, Kris Kennaway wrote:
> 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.
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 Giant (Giant) @
Robert Watson wrote:
> On Sun, 27 Jul 2003, Kris Kennaway wrote:
> > After upgrading last night, one of the package machines found this:
>
> I've bumped into some similar problems -- it's a property of how we
> current lock select(). We hold the file descriptor lock for the duration
> of polling
On Mon, Jul 28, 2003 at 02:53:12PM -0700, Kris Kennaway wrote:
> On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
> >
> > On Sun, 27 Jul 2003, Kris Kennaway wrote:
> >
> > > After upgrading last night, one of the package machines found this:
> >
> > I've bumped into some similar pr
On Mon, Jul 28, 2003 at 11:09:55AM -0400, Robert Watson wrote:
>
> On Sun, 27 Jul 2003, Kris Kennaway wrote:
>
> > After upgrading last night, one of the package machines found this:
>
> I've bumped into some similar problems -- it's a property of how we
> current lock select(). We hold the fil
On Sun, 27 Jul 2003, Kris Kennaway wrote:
> After upgrading last night, one of the package machines found this:
I've bumped into some similar problems -- it's a property of how we
current lock select(). We hold the file descriptor lock for the duration
of polling each object being "selected", a
On Sun, Jul 27, 2003 at 04:33:51PM -0700, Kris Kennaway wrote:
> 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 0xc04aa12
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/spec_vn
17 matches
Mail list logo
