kern/164705: inability to terminate process in D state

2012-02-02 Thread Eugene M. Zheganin 

>Number: 164705
>Category:   kern
>Synopsis:   inability to terminate process in D state
>Confidential:   no
>Severity:   critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 02 08:20:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Eugene M. Zheganin
>Release:8.2-STABLE
>Organization:
RealService LLC
>Environment:
FreeBSD bsdrookie.norma.com. 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Jul 25 
14:13:03 YEKST 2011 emz@:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
There's only two holy grails in FreeBSD: one, nowadays patched but sometimes 
still haunting FreeBSD, is the panic (livelock, hangup, name it yourself) when 
the mounted media is physically removed (a diskette, a flash-disk etc).

And the second - this is inability to terminate a process when it hangs in D 
state. Of course, kill -9 didn't work (as always. I'm guessing thi isn't a 
'uncatchable uniterruptable signal' as it's man page says, It looks more like 
'no big deal, safe to ignore signal, just for a process knows that something is 
up')

Last time I plugged the USB-mouse out of its port to hadle the mess with the 
cord, and when I plugged it back - hald hanged in the D state, so did all of 
the usbconfigs and so on.

I had to reboot the FreeBSD just to get my mouse back. Like we're back in 1996 
with an non-OSR Windows 95.

It's completely ridiculous.
>How-To-Repeat:
I'm pretty sure that if you're actually using FreeBSD, then at least once in a 
lifetime you got the need to kill something, you realise you cannot, and then 
when trying to understand what the hell is going on you see the magical D 
letter in ps's output, which means you're doomed.
>Fix:
There's always an answer. Reboot loves you.

>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Коньков Евгений 
The following reply was made to PR kern/164705; it has been noted by GNATS.

From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= 
To: "Eugene M. Zheganin" 
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/164705: inability to terminate process in D state
Date: Thu, 2 Feb 2012 11:02:38 +0200

 Çäðàâñòâóéòå, Eugene.
 
 Âû ïèñàëè 2 ôåâðàëÿ 2012 ã., 10:17:46:
 
 
 >>Number: 164705
 >>Category:   kern
 >>Synopsis:   inability to terminate process in D state
 >>Confidential:   no
 >>Severity:   critical
 >>Priority:   low
 >>Responsible:freebsd-bugs
 >>State:  open
 >>Quarter:
 >>Keywords:   
 >>Date-Required:
 >>Class:  sw-bug
 >>Submitter-Id:   current-users
 >>Arrival-Date:   Thu Feb 02 08:20:11 UTC 2012
 >>Closed-Date:
 >>Last-Modified:
 >>Originator: Eugene M. Zheganin
 >>Release:8.2-STABLE
 >>Organization:
 EMZ> RealService LLC
 >>Environment:
 EMZ> FreeBSD bsdrookie.norma.com. 8.2-STABLE FreeBSD 8.2-STABLE #0:
 EMZ> Mon Jul 25 14:13:03 YEKST 2011
 EMZ> emz@:/usr/obj/usr/src/sys/GENERIC  amd64
 >>Description:
 EMZ> There's only two holy grails in FreeBSD: one, nowadays patched
 EMZ> but sometimes still haunting FreeBSD, is the panic (livelock,
 EMZ> hangup, name it yourself) when the mounted media is physically
 EMZ> removed (a diskette, a flash-disk etc).
 
 EMZ> And the second - this is inability to terminate a process when
 EMZ> it hangs in D state. Of course, kill -9 didn't work (as always.
 EMZ> I'm guessing thi isn't a 'uncatchable uniterruptable signal' as
 EMZ> it's man page says, It looks more like 'no big deal, safe to
 EMZ> ignore signal, just for a process knows that something is up')
 
 EMZ> Last time I plugged the USB-mouse out of its port to hadle the
 EMZ> mess with the cord, and when I plugged it back - hald hanged in
 EMZ> the D state, so did all of the usbconfigs and so on.
 
 EMZ> I had to reboot the FreeBSD just to get my mouse back. Like
 EMZ> we're back in 1996 with an non-OSR Windows 95.
 
 EMZ> It's completely ridiculous.
 >>How-To-Repeat:
 EMZ> I'm pretty sure that if you're actually using FreeBSD, then at
 EMZ> least once in a lifetime you got the need to kill something, you
 EMZ> realise you cannot, and then when trying to understand what the
 EMZ> hell is going on you see the magical D letter in ps's output, which means 
you're doomed.
 >>Fix:
 EMZ> There's always an answer. Reboot loves you.
 
 not always, I have process going to 'T' state (STOP).
 and it is not killed even when I run 'reboot'
 only hard reboot helps (
 
 as developers sayed:
 >A signal cannot forcibly kill a process that is stuck in the kernel.
 >Allowing this would put the integrity of the kernel data structures at
 >risk and likely cause hangs, data corruption or panics later on.
 
 see: bin/164526: kill(1) can not kill process despite on -KILL
 
 
 -- 
 Ñ óâàæåíèåì,
  Êîíüêîâ  mailto:kes-...@yandex.ru
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re[2]: bin/164526: kill(1) can not kill process despite on -KILL

2012-02-02 Thread Коньков Евгений 
Здравствуйте, Alan.

Вы писали 2 февраля 2012 г., 9:20:10:

AD> The following reply was made to PR bin/164526; it has been noted by GNATS.

AD> From: Alan DeKok 
AD> To: =?UTF-8?B?0JrQvtC90YzQutC+0LIg0JXQstCz0LXQvdC40Lk=?=
AD>  , 
AD>  FreeRadius users mailing list 
AD> Cc: Jilles Tjoelker , 
AD>  firebird-de...@lists.sourceforge.net, bug-follo...@freebsd.org
AD> Subject: Re: bin/164526: kill(1) can not kill process despite on -KILL
AD> Date: Thu, 02 Feb 2012 08:13:54 +0100

AD>  Коньков Евгений wrote:
 >> repeated again:
 >> bug is repeateable:
 >> 1. radiusd + mod_perl + example.pl(it is connects to FireBird) +
AD>  
AD>Why?  FreeRADIUS has native support for all major SQL servers.
AD>  There's no need to use a Perl plugin.
AD>  
 >> FireBIrd
 >> 2. restart firebird
 >> 3. try to restart radiusd
 >> 4. process in fall into STOP state
AD>  
AD>You've built a system which has a lot of components.  The problem
AD>  could be anywhere.
AD>  
AD>I'll note that I've *never* seen this problem when using the native
AD>  SQL plugins which are shipped with FreeRADIUS.
AD>  
AD>Alan DeKok.

sorry: mod_perl => rlm_perl which configured as:

cat modules/perl
perl {
module = ${confdir}/example.pl
 }

cat sites/default
..
authorize {
  ...
  mschap
  perl
  }
...
accounting {
detail
perl

   }

and in example.pl do:

cat example.pl
# Function to handle accounting
sub accounting {
 my $result;

 doLog( L_INFO, "$dbh_fb: start accounting" );
 $result= RLM_MODULE_OK;

# $RAD_REPLY{'mpd-Update-Interim-Interval'} = '60';
# $RAD_REPLY{'mpd-Drop-User'} = 'Yes';.
 &db_logAttributes("accounting");
 &updateOnline();
 if( changePacket( $RAD_REQUEST{'User-Name'} ) ) {
   $RAD_REPLY{'mpd-drop-user'}= 1;
   }

 doLog( L_INFO, "$dbh_fb: finish accounting" );
 if ($result) {return $result; }...
 return RLM_MODULE_REJECT;
}

..
#  UPDATE ONLINE
sub updateOnline{
#!my ($sql, $query, $packet);
$_= $RAD_REQUEST{'Acct-Status-Type'};
SWITCH: {
 /Interim-Update|Stop/ && do {
   my $termCause= $RAD_REQUEST{'Acct-Status-Type'} eq 'Stop' ? 
$RAD_REQUEST{'Acct-Terminate-Cause'} || 'User-Request' : 'OnLine';
   my $trafIn= $RAD_REQUEST{'Acct-Input-Octets'} + 
2**32*$RAD_REQUEST{'Acct-Input-Gigawords'};
   my $trafOut= $RAD_REQUEST{'Acct-Output-Octets'} + 
2**32*$RAD_REQUEST{'Acct-Output-Gigawords'};


   doLog( L_INFO, "$dbh_fb: update online status for 
'$RAD_REQUEST{'User-Name'}'" );
   $dbh_fb->do( $QR_UPDATE_ONLINE_STATUS, undef,.
  $RAD_REQUEST{'User-Name'}
  ,$RAD_REQUEST{'Acct-Session-Time'}
  ,$RAD_REQUEST{'NAS-Port'}
  ,$RAD_REQUEST{'Calling-Station-Id'}
  ,$RAD_REQUEST{'NAS-IP-Address'}
  ,$trafIn
  ,$trafOut
  ,$termCause
  ,$RAD_REQUEST{'Framed-IP-Address'}
  ,$RAD_REQUEST{'Acct-Unique-Session-Id'}
  )  or doLog( L_INFO, "DO UPDATE ONLINE FB $DBI::errstr" );
..
 }

I just connect to DB and update session info.

But maybe this may lock system?

sub doLog {
 my( $level, $message )= @_;

 my $datetime= localtime();
 radiusd::radlog( $level, $message );
 `echo "$datetime: $message" >> "/var/log/radius/radius.kes.log"`;
 }

-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread avg 
Synopsis: inability to terminate process in D state

State-Changed-From-To: open->closed
State-Changed-By: avg
State-Changed-When: Thu Feb 2 09:22:32 UTC 2012
State-Changed-Why: 
The general problem can not be meaningfully resolved.

http://www.freebsd.org/cgi/query-pr.cgi?pr=164705
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Коньков Евгений 
aFo> Synopsis: inability to terminate process in D state

aFo> State-Changed-From-To: open->closed
aFo> State-Changed-By: avg
aFo> State-Changed-When: Thu Feb 2 09:22:32 UTC 2012
aFo> State-Changed-Why: 
aFo> The general problem can not be meaningfully resolved.

why close? keep the problem open until resolve.

-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Andriy Gapon 
The following reply was made to PR kern/164705; it has been noted by GNATS.

From: Andriy Gapon 
To: bug-follo...@freebsd.org, eug...@zhegan.in
Cc:  
Subject: Re: kern/164705: inability to terminate process in D state
Date: Thu, 02 Feb 2012 11:16:56 +0200

 Because you used words "completely ridiculous" in your bug report, I have to 
ask
 you what solution a genius like you can propose for a process which is stuck
 inside a system call (that is, in kernel).
 
 Now to techical side.  FreeBSD has no problem killing processes which execute 
in
 userland.  When a process is executing in kernel (in a system call), it is
 impossible to kill the process in a completely safe/clean fashion without
 affecting/corrupting internal kernel state.
 
 So bad news is that there will not be a universal kill command that can kill
 anything.
 
 Good news is that processes should never get stuck forever inside the kernel.
 Every time this happens it means that there is a (potentially new) bug in
 kernel, which should be properly reported and then hopefully fixed.
 
 So you will have to report concrete bugs with concrete diagnostics.
 
 See PR 164526 for a reference.
 
 P.S.  In my explanation I've omitted techicalities of kill sending a signal and
 how the signal is delivered to its target process.
 
 -- 
 Andriy Gapon
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Andriy Gapon 
on 02/02/2012 11:37 Коньков Евгений said the following:
> aFo> Synopsis: inability to terminate process in D state
> 
> aFo> State-Changed-From-To: open->closed
> aFo> State-Changed-By: avg
> aFo> State-Changed-When: Thu Feb 2 09:22:32 UTC 2012
> aFo> State-Changed-Why: 
> aFo> The general problem can not be meaningfully resolved.
> 
> why close? keep the problem open until resolve.
> 

Resolve exactly what?

-- 
Andriy Gapon
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Eugene M. Zheganin 

On 02.02.2012 16:00, Andriy Gapon wrote:

on 02/02/2012 11:37 Коньков Евгений said the following:

why close? keep the problem open until resolve.

Resolve exactly what?

Yeah, someone's enormous ego is not exactly a FreeBSD problem.
I can see it's grown up to an unresolvable size.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Andriy Gapon 
on 02/02/2012 12:10 Eugene M. Zheganin said the following:
> On 02.02.2012 16:00, Andriy Gapon wrote:
>> on 02/02/2012 11:37 Коньков Евгений said the following:
>>> why close? keep the problem open until resolve.
>> Resolve exactly what?
> Yeah, someone's enormous ego is not exactly a FreeBSD problem.
> I can see it's grown up to an unresolvable size.

Anything on the technical side you might want to add?

-- 
Andriy Gapon
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

conf/164709: [patch] [pc-sysinstall] add raidz3 support; permit 'raidz' in input

2012-02-02 Thread Garrett Cooper 

>Number: 164709
>Category:   conf
>Synopsis:   [patch] [pc-sysinstall] add raidz3 support; permit 'raidz' in 
>input
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 02 14:50:04 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:9.0-STABLE
>Organization:
n/a
>Environment:
FreeBSD bayonetta.local 9.0-STABLE FreeBSD 9.0-STABLE #4 r230371M: Thu Jan 19 
23:55:38 PST 2012 
gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA  amd64
>Description:
The attached patch permits one to specify raidz3 in get_fs_line_xvars(..) 
(RAIDZ3 is 3-disk parity option available in versions of ZFS in 8.3+/9.0+), and 
also relaxes the checks to allow one to specify raidz instead of raidz1.
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

Index: usr.sbin/pc-sysinstall/backend/functions-bsdlabel.sh
===
--- usr.sbin/pc-sysinstall/backend/functions-bsdlabel.sh(revision 
230088)
+++ usr.sbin/pc-sysinstall/backend/functions-bsdlabel.sh(working copy)
@@ -59,7 +59,7 @@
   ZTYPE="NONE"
   ZFSVARS="`echo $LINE | cut -d '(' -f 2- | cut -d ')' -f 1 | xargs`"
 
-  echo $ZFSVARS | grep -qE 
"^(disk|file|mirror|raidz(1|2)?|spare|log|cache):" 2>/dev/null
+  echo $ZFSVARS | grep -qE 
"^(disk|file|mirror|raidz[1-3]?|spare|log|cache):" 2>/dev/null
  if [ $? -eq 0 ] ; then
ZTYPE=`echo $ZFSVARS | cut -f1 -d:`
ZFSVARS=`echo $ZFSVARS | sed "s|$ZTYPE: ||g" | sed "s|$ZTYPE:||g"`


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: conf/164709: [patch] [pc-sysinstall] add raidz3 support; permit 'raidz' in input

2012-02-02 Thread eadler 
Synopsis: [patch] [pc-sysinstall] add raidz3 support; permit 'raidz' in input

Responsible-Changed-From-To: freebsd-bugs->eadler
Responsible-Changed-By: eadler
Responsible-Changed-When: Thu Feb 2 17:00:59 UTC 2012
Responsible-Changed-Why: 
I'll take it.

http://www.freebsd.org/cgi/query-pr.cgi?pr=164709
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re[2]: kern/164705: inability to terminate process in D state

2012-02-02 Thread Коньков Евгений 
Здравствуйте, Andriy.

Вы писали 2 февраля 2012 г., 15:04:04:

AG> on 02/02/2012 12:10 Eugene M. Zheganin said the following:
>> On 02.02.2012 16:00, Andriy Gapon wrote:
>>> on 02/02/2012 11:37 Коньков Евгений said the following:
 why close? keep the problem open until resolve.
>>> Resolve exactly what?
>> Yeah, someone's enormous ego is not exactly a FreeBSD problem.
>> I can see it's grown up to an unresolvable size.

AG> Anything on the technical side you might want to add?

people with sufficiant knowledge looking through opened PRs maybe will
notice this, take attention of it and fix.

I do not have any knowledge of kernel design I just report a PR
and if this is really problem it must be opened until fix. IMHO.

this PR and PR bin/164526 may be related and this one
may be closed as 'dublicate'  but not as:
  'this problem can not be resolved'

2:
thank you about your explanation of "bad and good news"

-- 
С уважением,
 Коньков  mailto:kes-...@yandex.ru

___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164694: Regression in 3726 port multiplier support in 9.0

2012-02-02 Thread Allen Belletti 
The following reply was made to PR kern/164694; it has been noted by GNATS.

From: Allen Belletti 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/164694: Regression in 3726 port multiplier support in 9.0
Date: Thu, 02 Feb 2012 13:08:13 -0500

 I've reached a dead end but come up with a few more bits of information. 
   It's definitely some sort of irq setup/handling problem.  I 
 experimented with setting hint.siis.X.msi=1 for these cards. 
 Surprisingly, they almost seem to work.  They're able to immediately 
 detect the pmp device and recognize the four disks on the other side of 
 it.  However, after a few seconds of I/O, it'll get stuck and time out. 
   Presumably MSI just doesn't work on these cards which is why it 
 defaults to disabled (I've seen hints of problems like that in my 
 search.)  I did also try forcing hint.siisch.X.sata_rev=1 but it didn't 
 seem to improve the situation, which makes sense if it's fundamentally 
 an interrupt handling problem.
 
 It's unlikely that I can get any further on my own, but it seems likely 
 that some sort of IRQ handling problem was introduced between 8.2 and 9.0.
 
 Thanks,
 Allen
 
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164705: inability to terminate process in D state

2012-02-02 Thread Andriy Gapon 
on 02/02/2012 20:02 Коньков Евгений said the following:
> Здравствуйте, Andriy.
> 
> Вы писали 2 февраля 2012 г., 15:04:04:
> 
> AG> on 02/02/2012 12:10 Eugene M. Zheganin said the following:
>>> On 02.02.2012 16:00, Andriy Gapon wrote:
 on 02/02/2012 11:37 Коньков Евгений said the following:
> why close? keep the problem open until resolve.
 Resolve exactly what?
>>> Yeah, someone's enormous ego is not exactly a FreeBSD problem.
>>> I can see it's grown up to an unresolvable size.
> 
> AG> Anything on the technical side you might want to add?
> 
> people with sufficiant knowledge looking through opened PRs maybe will
> notice this, take attention of it and fix.
> 
> I do not have any knowledge of kernel design I just report a PR
> and if this is really problem it must be opened until fix. IMHO.
> 
> this PR and PR bin/164526 may be related and this one
> may be closed as 'dublicate'  but not as:
>   'this problem can not be resolved'

PR 164526 reports a concrete problem that can be diagnosed and hopefully fixed.
This PR is equivalent to "when FreeBSD has bugs it sucks", only about a 
sub-class
of bugs with some specific symptoms (process being stuck and unkillable).  There
could be different actual underlying bugs and bug classes - driver bugs,
deadlocks, etc.  Hence, this PR can not be diagnosed and fixed.
A new (concrete/useful) PR can be opened at any time, it's a low cost operation.

> 2:
> thank you about your explanation of "bad and good news"
> 


-- 
Andriy Gapon
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/161257: commit references a PR

2012-02-02 Thread dfilter service 
The following reply was made to PR bin/161257; it has been noted by GNATS.

From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: bin/161257: commit references a PR
Date: Thu,  2 Feb 2012 18:22:40 + (UTC)

 Author: trociny
 Date: Thu Feb  2 18:22:25 2012
 New Revision: 230918
 URL: http://svn.freebsd.org/changeset/base/230918
 
 Log:
   MFC r227956, r228090, r228446, r230471, r230548:
   
   r227956:
   
   Add -l flag to display resource limits.
   
   PR:  bin/161257
   Reviewed by: kib
   
   r228090:
   
   Update SYNOPSIS to include the flags added recently.
   
   Spotted by:  jhb
   
   r228446:
   
   Make procstat -l output similar to the output of limits(1).
   
   Suggested by:jhb
   
   r230471, r230548:
   
   Make procstat -l to work with the new version of kern.proc.rlimit.
   
   Submitted by:Andrey Zonov 
 
 Added:
   stable/9/usr.bin/procstat/procstat_rlimit.c
  - copied, changed from r227956, head/usr.bin/procstat/procstat_rlimit.c
 Modified:
   stable/9/usr.bin/procstat/Makefile
   stable/9/usr.bin/procstat/procstat.1
   stable/9/usr.bin/procstat/procstat.c
   stable/9/usr.bin/procstat/procstat.h
 Directory Properties:
   stable/9/usr.bin/procstat/   (props changed)
 
 Modified: stable/9/usr.bin/procstat/Makefile
 ==
 --- stable/9/usr.bin/procstat/Makefile Thu Feb  2 18:17:49 2012
(r230917)
 +++ stable/9/usr.bin/procstat/Makefile Thu Feb  2 18:22:25 2012
(r230918)
 @@ -10,6 +10,7 @@ SRCS=procstat.c  \
procstat_cred.c \
procstat_files.c\
procstat_kstack.c   \
 +  procstat_rlimit.c   \
procstat_sigs.c \
procstat_threads.c  \
procstat_vm.c
 
 Modified: stable/9/usr.bin/procstat/procstat.1
 ==
 --- stable/9/usr.bin/procstat/procstat.1   Thu Feb  2 18:17:49 2012
(r230917)
 +++ stable/9/usr.bin/procstat/procstat.1   Thu Feb  2 18:22:25 2012
(r230918)
 @@ -25,7 +25,7 @@
  .\"
  .\" $FreeBSD$
  .\"
 -.Dd November 22, 2011
 +.Dd November 28, 2011
  .Dt PROCSTAT 1
  .Os
  .Sh NAME
 @@ -37,7 +37,7 @@
  .Op Fl n
  .Op Fl C
  .Op Fl w Ar interval
 -.Op Fl b | c | f | i | j | k | s | t | v
 +.Op Fl b | c | e | f | i | j | k | l | s | t | v | x
  .Op Fl a | Ar pid ...
  .Sh DESCRIPTION
  The
 @@ -69,6 +69,8 @@ Display the stacks of kernel threads in 
  threads currently running on a CPU and threads with stacks swapped to disk.
  If the flag is repeated, function offsets as well as function names are
  printed.
 +.It Fl l
 +Display resource limits for the process.
  .It Fl s
  Display security credential information for the process.
  .It Fl t
 
 Modified: stable/9/usr.bin/procstat/procstat.c
 ==
 --- stable/9/usr.bin/procstat/procstat.c   Thu Feb  2 18:17:49 2012
(r230917)
 +++ stable/9/usr.bin/procstat/procstat.c   Thu Feb  2 18:22:25 2012
(r230918)
 @@ -39,8 +39,8 @@
  
  #include "procstat.h"
  
 -static int aflag, bflag, cflag, eflag, fflag, iflag, jflag, kflag, sflag, 
tflag;
 -static int vflag, xflag;
 +static int aflag, bflag, cflag, eflag, fflag, iflag, jflag, kflag, lflag, 
sflag;
 +static int tflag, vflag, xflag;
  int   hflag, nflag, Cflag;
  
  static void
 @@ -50,7 +50,7 @@ usage(void)
fprintf(stderr, "usage: procstat [-h] [-C] [-M core] [-N system] "
"[-w interval] \n");
fprintf(stderr, "[-b | -c | -e | -f | -i | -j | -k | "
 -  "-s | -t | -v | -x] [-a | pid ...]\n");
 +  "-l | -s | -t | -v | -x] [-a | pid ...]\n");
exit(EX_USAGE);
  }
  
 @@ -72,6 +72,8 @@ procstat(struct procstat *prstat, struct
procstat_threads_sigs(prstat, kipp);
else if (kflag)
procstat_kstack(kipp, kflag);
 +  else if (lflag)
 +  procstat_rlimit(kipp);
else if (sflag)
procstat_cred(kipp);
else if (tflag)
 @@ -123,7 +125,7 @@ main(int argc, char *argv[])
  
interval = 0;
memf = nlistf = NULL;
 -  while ((ch = getopt(argc, argv, "CN:M:abcefijkhstvw:x")) != -1) {
 +  while ((ch = getopt(argc, argv, "CN:M:abcefijklhstvw:x")) != -1) {
switch (ch) {
case 'C':
Cflag++;
 @@ -167,6 +169,10 @@ main(int argc, char *argv[])
kflag++;
break;
  
 +  case 'l':
 +  lflag++;
 +  break;
 +
case 'n':
nflag++;
break;
 @@ -210,8 +216,8 @@ main(int argc, char *argv[])
argv += optind;
  
/* We require that either 0 or 1 mode flags be set. */
 -  tmp = bflag + cflag

misc/164716: ports: net-mgmt/xymon-server add menu options

2012-02-02 Thread falz 

>Number: 164716
>Category:   misc
>Synopsis:   ports: net-mgmt/xymon-server add menu options
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  update
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 02 19:30:13 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: falz
>Release:9.0
>Organization:
>Environment:
>Description:
Enable menu options for `make config`. Patch also here:

http://falz.net/static/xymon-server-opts.diff

>How-To-Repeat:

>Fix:


Patch attached with submission follows:

diff -ruN /usr/ports/net-mgmt/xymon-server/Makefile 
/usr/local/ports/net-mgmt/xymon-server/Makefile
--- /usr/ports/net-mgmt/xymon-server/Makefile   2012-01-24 13:05:03.0 
-0600
+++ /usr/local/ports/net-mgmt/xymon-server/Makefile 2012-02-02 
13:07:56.0 -0600
@@ -37,6 +37,9 @@
 SUB_LIST+= XYMONUSER="${XYMONUSER}"
 PLIST_SUB+=XYMONUSER="${XYMONUSER}" VARBASE="/var"
 
+OPTIONS=   LDAP"Enable LDAP support" off \
+   SNMP"Enable Net-SNMP support" off
+
 CONFIG_FILES=  alerts.cfg analysis.cfg cgioptions.cfg client-local.cfg \
columndoc.csv combo.cfg graphs.cfg holidays.cfg protocols.cfg \
rrddefinitions.cfg tasks.cfg xymonserver.cfg


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164694: Regression in 3726 port multiplier support in 9.0

2012-02-02 Thread Allen Belletti 
The following reply was made to PR kern/164694; it has been noted by GNATS.

From: Allen Belletti 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/164694: Regression in 3726 port multiplier support in 9.0
Date: Thu, 02 Feb 2012 15:59:05 -0500

 One final thing; I forgot that I still had a mirror of my 8.2 
 installation.  I was able to boot that and return to my original 
 configuration.  Indeed, the problem with the siis interfaces goes away 
 under 8.2, so it's 100% a regression and not a hardware issue.
 
 Also, for reference, the system runs a SuperMicro X8DTH board.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

kern/164721: ath device timeouts

2012-02-02 Thread Lev Serebryakov 

>Number: 164721
>Category:   kern
>Synopsis:   ath device timeouts
>Confidential:   no
>Severity:   serious
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 02 21:30:11 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Lev Serebryakov 
>Release:FreeBSD 10.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD 
10.0-CURRENT #1: Wed Jan 11 21:07:34 MSK 2012 
r...@vmware-c-32.home.serebryakov.spb.ru:/usr/obj/nanobsd.gateway-net5501/usr/src/sys/NET5501
 i386

ath0:  mem 0xa006-0xa006 irq 15 at device 17.0 on pci0
ath0: [HT] enabling HT modes
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9220 mac 128.2 RF5133 phy 13.0
ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0

ath0@pci0:0:17:0:   class=0x028000 card=0x2091168c chip=0x0029168c rev=0x01 
hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR922X Wireless Network Adapter'
class  = network

ath0: flags=8843 metric 0 mtu 2290
ether f4:ec:38:a3:10:6d
nd6 options=29
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng 
status: running

wlan0: flags=8843 metric 0 mtu 1500
ether f4:ec:38:a3:10:6d
inet 192.168.135.1 netmask 0xff00 broadcast 192.168.135.255 vhid 5 
inet6 fe80::f6ec:38ff:fea3:106d%wlan0 prefixlen 64 scopeid 0xc vhid 5 
inet6 2001:470:923f:2::1 prefixlen 64 vhid 5 
nd6 options=21
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng 
status: running
ssid home.serebryakov.spb.ru channel 9 (2452 MHz 11g ht/20) bssid 
f4:ec:38:a3:10:6d
regdomain ROW country RU indoor ecm authmode WPA2/802.11i -wps -tsn
privacy MIXED deftxkey 3
AES-CCM 2:128-bit
AES-CCM 3:128-bit powersavemode OFF powersavesleep 100 txpower 30
txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7
11a ucast NONEmgmt  6 Mb/s mcast  6 Mb/s maxretry 6
11b ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
11g ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
turboA  ucast NONEmgmt  6 Mb/s mcast  6 Mb/s maxretry 6
turboG  ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
sturbo  ucast NONEmgmt  6 Mb/s mcast  6 Mb/s maxretry 6
11naucast NONEmgmt 12 MCS  mcast 12 MCS  maxretry 6
11ngucast NONEmgmt  2 MCS  mcast  2 MCS  maxretry 6
halfucast NONEmgmt  3 Mb/s mcast  3 Mb/s maxretry 6
quarter ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250
roam:11a rssi7dBm rate 12 Mb/s
roam:11b rssi7dBm rate  1 Mb/s
roam:11g rssi7dBm rate  5 Mb/s
roam:turboA  rssi7dBm rate 12 Mb/s
roam:turboG  rssi7dBm rate 12 Mb/s
roam:sturbo  rssi7dBm rate 12 Mb/s
roam:11narssi7dBm  MCS  1
roam:11ngrssi7dBm  MCS  1
roam:halfrssi7dBm rate  6 Mb/s
roam:quarter rssi7dBm rate  3 Mb/s
-pureg protmode CTS ht htcompat -ampdutx ampdurx ampdulimit 64k
ampdudensity 8 amsdu shortgi htprotmode RTSCTS -puren -smps -rifs wme
burst -dwds -hidessid apbridge dtimperiod 1 doth -dfs inact
bintval 100
AC_BE cwmin  4 cwmax  6 aifs  3 txopLimit   0 -acm ack
  cwmin  4 cwmax 10 aifs  3 txopLimit   0 -acm
AC_BK cwmin  4 cwmax 10 aifs  7 txopLimit   0 -acm ack
  cwmin  4 cwmax 10 aifs  7 txopLimit   0 -acm
AC_VI cwmin  3 cwmax  4 aifs  1 txopLimit  94 -acm ack
  cwmin  3 cwmax  4 aifs  2 txopLimit  94 -acm
AC_VO cwmin  2 cwmax  3 aifs  1 txopLimit  47 -acm ack
  cwmin  2 cwmax  3 aifs  2 txopLimit  47 -acm
groups: wlan 

>Description:
  
  Sometimes ath0 gives tiemout when transmitting to 802.11g client.
  The higher is speed the higher is tiemouts frequency.
  When environment is noisy, speed is low and timeouts is rare. When 
environment is clean, speed is high (up to 2.5MiB/s) but timeouts are frequent.
  Here is output of `dmesg' when reset debug is enabled.
 
ath0: stuck beacon; resetting (bmiss count 4)
ath0: ath_reset: called
ath0: ath_stoptxdma: tx queue [9] 0x1b9b000, link 0
ath0: ath_tx_stopdma: tx queue [0] 0, link 0
ath0: ath_tx_stopdma: tx queue [1] 0x212fb40, link 0
ath0: ath_tx_stopdma: tx queue [2] 0, link 0
ath0: ath_tx_stopdma: tx queue [3] 0, link 0
ath0: ath_tx_stopdma: tx queue [8] 0x20beb40, link 0
ar5212StopDmaReceive: dma failed to stop in 10ms
AR_CR=0x0024
AR_DIAG_SW=0x4220
ath_stoprecv: rx queue 0x1b96480, link 0xcdb96420
ath0: stuck beacon; resetting (bmiss count 4)
ath0: ath_reset: called
ath0: ath_stoptxdma:

Re: bin/164526: kill(1) can not kill process despite on -KILL

2012-02-02 Thread Andriy Gapon 
The following reply was made to PR bin/164526; it has been noted by GNATS.

From: Andriy Gapon 
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:  
Subject: Re: bin/164526: kill(1) can not kill process despite on -KILL
Date: Thu, 02 Feb 2012 23:29:13 +0200

 Eugen,
 
 thank you for reporting and debugging this problem.
 In addition to what Jilles has already suggested I would like to also advise
 that it's possible to use kgdb to examine the vnode and its lock.
 You can use kgdb's 'tid' command to switch to a thread of interest (it would be
 100195 for your earlier report) and the you can use standard gdb commands to
 examine the data.
 
 Another, and more standard way, to deal with deadlocks like this one is
 described here:
 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
 
 -- 
 Andriy Gapon
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: kern/164721: ath device timeouts

2012-02-02 Thread lev 
Synopsis: ath device timeouts

Responsible-Changed-From-To: freebsd-bugs->adrian
Responsible-Changed-By: lev
Responsible-Changed-When: Thu Feb 2 21:30:50 UTC 2012
Responsible-Changed-Why: 
Pass to ath driver owner.


http://www.freebsd.org/cgi/query-pr.cgi?pr=164721
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

kern/164724: Signal bug in Dtrace

2012-02-02 Thread Pedro Giffuni 

>Number: 164724
>Category:   kern
>Synopsis:   Signal bug in Dtrace
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 03 02:10:12 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Pedro Giffuni
>Release:9.0-release
>Organization:
>Environment:
FreeBSD pcbsd-8714 9.0-RELEASE FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 
2011 
r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC
  amd64
>Description:
Last year Bryan Cantrill found a nasty bug in Dtrace:

http://dtrace.org/blogs/bmc/2011/03/09/when-magic-collides/

He warns "you are not expected to understand this", and not
really being used to Dtrace I haven't really reproduced it.

The fix, however, was relatively easy so I adapted the patch
here:

http://dtrace.org/resources/bmc/dtrace-signal.patch

to work on FreeBSD's port.
>How-To-Repeat:

>Fix:
Patch attached

Patch attached with submission follows:

Index: cddl/dev/dtrace/i386/dtrace_subr.c
===
--- cddl/dev/dtrace/i386/dtrace_subr.c  (revision 230923)
+++ cddl/dev/dtrace/i386/dtrace_subr.c  (working copy)
@@ -27,6 +27,10 @@
  * Use is subject to license terms.
  */
 
+/*
+ * Copyright (c) 2011, Joyent, Inc. All rights reserved.
+ */
+
 #include 
 #include 
 #include 
@@ -298,14 +302,15 @@
}
 
/*
-* If we've executed the original instruction, but haven't performed
-* the jmp back to t->t_dtrace_npc or the clean up of any registers
-* used to emulate %rip-relative instructions in 64-bit mode, do that
-* here and take the signal right away. We detect this condition by
-* seeing if the program counter is the range [scrpc + isz, astpc).
+* If we have executed the original instruction, but we have performed
+* neither the jmp back to t->t_dtrace_npc nor the clean up of any
+* registers used to emulate %rip-relative instructions in 64-bit mode,
+* we'll save ourselves some effort by doing that here and taking the
+* signal right away.  We detect this condition by seeing if the program
+* counter is the range [scrpc + isz, astpc).
 */
-   if (t->t_dtrace_astpc - rp->r_pc <
-   t->t_dtrace_astpc - t->t_dtrace_scrpc - isz) {
+   if (rp->r_pc >= t->t_dtrace_scrpc + isz &&
+   rp->r_pc < t->t_dtrace_astpc) {
 #ifdef __amd64
/*
 * If there is a scratch register and we're on the
Index: cddl/dev/dtrace/amd64/dtrace_subr.c
===
--- cddl/dev/dtrace/amd64/dtrace_subr.c (revision 230923)
+++ cddl/dev/dtrace/amd64/dtrace_subr.c (working copy)
@@ -27,6 +27,10 @@
  * Use is subject to license terms.
  */
 
+/*
+ * Copyright (c) 2011, Joyent, Inc. All rights reserved.
+ */
+
 #include 
 #include 
 #include 
@@ -297,14 +301,15 @@
}
 
/*
-* If we've executed the original instruction, but haven't performed
-* the jmp back to t->t_dtrace_npc or the clean up of any registers
-* used to emulate %rip-relative instructions in 64-bit mode, do that
-* here and take the signal right away. We detect this condition by
-* seeing if the program counter is the range [scrpc + isz, astpc).
+* If we have executed the original instruction, but we have performed
+* neither the jmp back to t->t_dtrace_npc nor the clean up of any
+* registers used to emulate %rip-relative instructions in 64-bit mode,
+* we'll save ourselves some effort by doing that here and taking the
+* signal right away.  We detect this condition by seeing if the program
+* counter is the range [scrpc + isz, astpc).
 */
-   if (t->t_dtrace_astpc - rp->r_pc <
-   t->t_dtrace_astpc - t->t_dtrace_scrpc - isz) {
+   if (rp->r_pc >= t->t_dtrace_scrpc + isz &&
+   rp->r_pc < t->t_dtrace_astpc) {
 #ifdef __amd64
/*
 * If there is a scratch register and we're on the


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"