Andrew Reilly | 1 May 01:12 2010
Picon

Re: Panic <at> r207433: "System call fork returning with the following locks held"

Hi all,

I'm not sure if it's related (I get my src via csup, so I don't
have svn reveision numbers), but I upgraded about 16 hours ago
again a few hours after that, and my two-core AMD64 system has
been (seemingly) quite unstable.  I've had a few boot cycles
that have failed and dumped me out into kdb, rebooting through
single-user (to check file systems) seems to get me "up", but my
logs are completely full of:

Calling uiomove() with the following non-sleepable locks held:
exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xffffffff80e60a00) locked  <at>  /nb/src/sys/vm/vm_pageout.c:452
exclusive sleep mutex page lock (page lock) r = 0 (0xffffffff80e59e00) locked  <at>  /nb/src/sys/vm/vm_pageout.c:451
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_warn() at witness_warn+0x2c2
uiomove() at uiomove+0x52
ffs_write() at ffs_write+0x32d
VOP_WRITE_APV() at VOP_WRITE_APV+0x103
vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5
vnode_pager_putpages() at vnode_pager_putpages+0x97
vm_pageout_flush() at vm_pageout_flush+0x1ad
vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470
vm_object_page_clean() at vm_object_page_clean+0x408
vfs_msync() at vfs_msync+0xef
sync_fsync() at sync_fsync+0x12a
sync_vnode() at sync_vnode+0x157
sched_sync() at sched_sync+0x1d1
fork_exit() at fork_exit+0x12a
(Continue reading)

K. Macy | 1 May 01:42 2010
Picon

Re: Panic <at> r207433: "System call fork returning with the following locks held"

Hi Andrew,

Does FBSDID get expanded when checking out with csup?

You should see:
__FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
22:31:37Z kmacy $");

line 451 is part of a KASSERT on this version.

Cheers,
Kip

On Fri, Apr 30, 2010 at 4:12 PM, Andrew Reilly <areilly <at> bigpond.net.au> wrote:
> Hi all,
>
> I'm not sure if it's related (I get my src via csup, so I don't
> have svn reveision numbers), but I upgraded about 16 hours ago
> again a few hours after that, and my two-core AMD64 system has
> been (seemingly) quite unstable.  I've had a few boot cycles
> that have failed and dumped me out into kdb, rebooting through
> single-user (to check file systems) seems to get me "up", but my
> logs are completely full of:
>
> Calling uiomove() with the following non-sleepable locks held:
> exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xffffffff80e60a00) locked  <at>  /nb/src/sys/vm/vm_pageout.c:452
> exclusive sleep mutex page lock (page lock) r = 0 (0xffffffff80e59e00) locked  <at>  /nb/src/sys/vm/vm_pageout.c:451
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
(Continue reading)

James Butler | 1 May 02:29 2010
Picon

Re: ports and PBIs

On Sunday, April 11, 2010, Tim Kientzle <kientzle <at> freebsd.org> wrote:
> Garrett Cooper wrote:
>
> If I'm understanding you correctly you're saying it's an issue when I do:
>
> pkg_add A B C
>
> # 1 year passes
>
> pkg_add D
>
> # D depends on A, B, C, of different revisions. pkg_add barfs because
> it can't find the applications, etc.
>
> This is something that's been hashed over a number of times (a few of
> which I've participated in in #bsdports). There needs to be a simple
> update command which will handle the action of upgrading packages,
> because there isn't a proper command that will do so today.
>
>
> I'm not convinced that the "simple update command" you
> mention is actually feasible, much less desirable.
> (If I want to try out the new Firefox, why does that
> imply that my year-old Gimp has to be upgraded?)
>
> As for feasibility, here's the easy problem:
>    A2.7 requires B3.6
>      ... one year passes ...
>    A4.8 now requires B7.2
> But A4.8 is incompatible with B3.6 and A2.7 is
(Continue reading)

Taku YAMAMOTO | 1 May 10:12 2010
Picon

if_em.c prevents the 2nd time resuming

Greetings,

I found a bug in if_em.c which triggers a panic when resuming from the 2nd
suspend. (sleep, wakeup, sleep and wakeup will result to a panic)

It seems it has got introduced by r206001 (head) or r206211 (stable/8).

I guess the following change mistakenly slipped into em_resume() which is
completely bogus (suppose these lines should go into em_detach()?):

 <at>  <at>  -769,6 +774,9  <at>  <at>  
 	struct adapter *adapter = device_get_softc(dev);
 	struct ifnet *ifp = adapter->ifp;

+	if (adapter->led_dev != NULL)
+		led_destroy(adapter->led_dev);
+
 	EM_CORE_LOCK(adapter);
 	em_init_locked(adapter);
 	em_init_manageability(adapter);

Should I file a PR?

Virtually yours,
--

-- 
-|-__   YAMAMOTO, Taku
 | __ <     <taku <at> tackymt.homeip.net>

      - A chicken is an egg's way of producing more eggs. -
_______________________________________________
(Continue reading)

Maxim Sobolev | 1 May 11:11 2010
Picon

Re: Making IFQ_MAXLEN tunable

Gary Jennejohn wrote:
> On Fri, 30 Apr 2010 13:23:13 -0700
> Maxim Sobolev <sobomax <at> sippysoft.com> wrote:
> 
>> Hi,
>>
>> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to 
>> set length of the outgoing packets queue. The default value for that 
>> parameter is only 50, which is pretty low especially for the cases when 
>> the system handles lot of small packets and can cause ENOBUFS in 
>> applications under the load. The following patch makes IFQ_MAXLEN a 
>> tunable. I am also tempted to bump the default value for IFQ_MAXLEN 
>> 10-fold, but would like to hear what do people think about it first.
>>
>> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff
>>
> 
> Seems like a good idea, although I don't see where ifqmaxlen is being
> initialized.

sys/net/if.c

-Maxim
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Bjoern A. Zeeb | 1 May 11:17 2010
Picon

Re: Making IFQ_MAXLEN tunable

On Fri, 30 Apr 2010, Maxim Sobolev wrote:

Hi,

> Julian Elischer wrote:
>> On 4/30/10 1:23 PM, Maxim Sobolev wrote:
>>> Hi,
>>> 
>>> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
>>> set length of the outgoing packets queue. The default value for that
>>> parameter is only 50, which is pretty low especially for the cases when
>>> the system handles lot of small packets and can cause ENOBUFS in
>>> applications under the load. The following patch makes IFQ_MAXLEN a
>>> tunable. I am also tempted to bump the default value for IFQ_MAXLEN
>>> 10-fold, but would like to hear what do people think about it first.
>>> 
>>> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff
>> 
>> so just tunable? not a sysctl :-)
>
> The sysctl would require much bigger rewrite. As long as I understand the 
> value is now cached in many instances of the ifnet structure, and some 
> drivers even use their own queue length instead of IFQ_MAXLEN. Therefore, 
> even if I make this parameter a sysctl one would have to destroy interface 
> and create it again in order for the change to have an effect. Therefore, 
> keeping it tunable would be less confusing.
>
>> patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen 
>> (do different vimages want a different value?)
>
(Continue reading)

Gary Jennejohn | 1 May 11:25 2010

Re: Making IFQ_MAXLEN tunable

On Sat, 01 May 2010 02:11:04 -0700
Maxim Sobolev <sobomax <at> FreeBSD.org> wrote:

> Gary Jennejohn wrote:
> > On Fri, 30 Apr 2010 13:23:13 -0700
> > Maxim Sobolev <sobomax <at> sippysoft.com> wrote:
> > 
> >> Hi,
> >>
> >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to 
> >> set length of the outgoing packets queue. The default value for that 
> >> parameter is only 50, which is pretty low especially for the cases when 
> >> the system handles lot of small packets and can cause ENOBUFS in 
> >> applications under the load. The following patch makes IFQ_MAXLEN a 
> >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN 
> >> 10-fold, but would like to hear what do people think about it first.
> >>
> >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff
> >>
> > 
> > Seems like a good idea, although I don't see where ifqmaxlen is being
> > initialized.
> 
> sys/net/if.c
> 

Shame on me for not looking at the file itself!  I only looked at the
patch.

--
(Continue reading)

Gary Jennejohn | 1 May 10:58 2010

Re: Making IFQ_MAXLEN tunable

On Fri, 30 Apr 2010 13:23:13 -0700
Maxim Sobolev <sobomax <at> sippysoft.com> wrote:

> Hi,
> 
> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to 
> set length of the outgoing packets queue. The default value for that 
> parameter is only 50, which is pretty low especially for the cases when 
> the system handles lot of small packets and can cause ENOBUFS in 
> applications under the load. The following patch makes IFQ_MAXLEN a 
> tunable. I am also tempted to bump the default value for IFQ_MAXLEN 
> 10-fold, but would like to hear what do people think about it first.
> 
> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff
> 

Seems like a good idea, although I don't see where ifqmaxlen is being
initialized.

--
Gary Jennejohn
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Andrew Reilly | 1 May 14:49 2010
Picon

Re: Panic <at> r207433: "System call fork returning with the following locks held"

Hi Kip,

Sorry for the delay: it's been a tussle...

On Fri, Apr 30, 2010 at 04:42:12PM -0700, K. Macy wrote:
> Does FBSDID get expanded when checking out with csup?

Looks like it:

> __FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
> 22:31:37Z kmacy $");

My version says:
__FBSDID("$FreeBSD: src/sys/vm/vm_pageout.c,v 1.316 2010/04/30
22:31:37 kmacy Exp $");

> line 451 is part of a KASSERT on this version.

Yep.

About half an hour after sending the previous message my system
siezed up again, and I've been coaxing it back to health since.

Must make a note to myself to be more careful...  I managed
to find a boot configuration that was stable enough to grab
the latest updates off the local cvs server.  Then back to
single-user mode to build the kernel, and all was sweetness and
puppies after that.  Thanks for the fixes!

All?  Not quite: about simultaneous with the vm_pageout
(Continue reading)

Marius Strobl | 1 May 17:03 2010
Picon

Re: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE

On Fri, Apr 30, 2010 at 06:50:26PM +0400, pluknet wrote:
> On 30 April 2010 18:22, Matthew Jacob <mj <at> feral.com> wrote:
> > pluknet wrote:
> > Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll put
> > it in
> 
> Err.. I thought that list is dedicated for cam related stuff.
> 
> [cc'ing scsi <at>  for better coverage. Sorry for cross-posting :/ ]
> 
> >
> >> --- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c    2010-03-02
> >> 15:38:13.000000000 +0300
> >> +++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c  2010-04-21
> >> 19:31:00.000000000 +0400
> >>  <at>  <at>  -2564,6 +2564,12  <at>  <at>  mpt_cam_event(struct mpt_softc *mpt, req
> >>        CAMLOCK_2_MPTLOCK(mpt);
> >>        break;
> >>    }
> >> +    case MPI_EVENT_IR_RESYNC_UPDATE:
> >> +    {
> >> +        uint8_t resync = (data0 >> 16) & 0xff;
> >> +        mpt_prt(mpt, "IR resync update %d completed\n", resync);
> >> +        break;
> >> +    }
> >>    case MPI_EVENT_EVENT_CHANGE:
> >>    case MPI_EVENT_INTEGRATED_RAID:
> >>    case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE:
> >>
> >> Another way - just hide such event since mptutil displays rebuild
(Continue reading)


Gmane