headers
dholland | 1 Dec 2011 01:04
Picon

Re: port-amd64/42980 (satalink DMA fails under amd64)

Synopsis: satalink DMA fails under amd64

State-Changed-From-To: open->feedback
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Thu, 01 Dec 2011 00:04:05 +0000
State-Changed-Why:
This appears to have been committed and pulled up a year ago - is it fixed
or is it still awaiting additional work?
Permalink | Reply | 0 comments |
headers
David A. Holland | 1 Dec 2011 01:30
Picon

PR/45672 CVS commit: src/usr.sbin/user

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

From: "David A. Holland" <dholland <at> netbsd.org>
To: gnats-bugs <at> gnats.NetBSD.org
Cc: 
Subject: PR/45672 CVS commit: src/usr.sbin/user
Date: Thu, 1 Dec 2011 00:26:45 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Thu Dec  1 00:26:45 UTC 2011

 Modified Files:
 	src/usr.sbin/user: user.c

 Log Message:
 Handle return value from system() properly.
 PR 45672 from River Tarnell.

 
 To generate a diff of this commit:
 cvs rdiff -u -r1.127 -r1.128 src/usr.sbin/user/user.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
Permalink | Reply | 0 comments |
headers
dholland | 1 Dec 2011 01:35
Picon

Re: bin/45672 (usr.sbin/user generates incorrect error messages)

Synopsis: usr.sbin/user generates incorrect error messages

State-Changed-From-To: open->feedback
State-Changed-By: dholland <at> NetBSD.org
State-Changed-When: Thu, 01 Dec 2011 00:35:57 +0000
State-Changed-Why:
Fixed in HEAD - if you have a test case in mind please give it a try. Also,
do you need this on the netbsd-5 branch? I'm not convinced it's worth the
trouble.
Permalink | Reply | 1 comment |
headers
matthew green | 1 Dec 2011 05:42
Picon
Favicon

re: kern/45647: kill from ddb broken


> Trying to kill a process from ddb fails:
> 
> db{1}> kill 0t507
> Skipping crash dump on recursive panic
> panic: kernel diagnostic assertion "mutex_owned(proc_lock)" failed: file
"../../../../kern/kern_proc.c", line 590 

this is non trivial to solve.

simply taking proc_lock (and more!) isn't going to work if some cpu
was stopped mid-lock of these.

perhaps a solution would be to have ddb create a thread that will go
away that will send the signal asap...

.mrg.
Permalink | Reply | 2 comments |
headers
matthew green | 1 Dec 2011 05:45
Picon
Favicon

re: kern/45647: kill from ddb broken

The following reply was made to PR kern/45647; it has been noted by GNATS.

From: matthew green <mrg <at> eterna.com.au>
To: gnats-bugs <at> NetBSD.org
Cc: kern-bug-people <at> netbsd.org, gnats-admin <at> netbsd.org,
    netbsd-bugs <at> netbsd.org
Subject: re: kern/45647: kill from ddb broken
Date: Thu, 01 Dec 2011 15:42:50 +1100

 > Trying to kill a process from ddb fails:
 > 
 > db{1}> kill 0t507
 > Skipping crash dump on recursive panic
 > panic: kernel diagnostic assertion "mutex_owned(proc_lock)" failed: file
"../../../../kern/kern_proc.c", line 590 

 this is non trivial to solve.

 simply taking proc_lock (and more!) isn't going to work if some cpu
 was stopped mid-lock of these.

 perhaps a solution would be to have ddb create a thread that will go
 away that will send the signal asap...

 
 .mrg.
Permalink | Reply | 0 comments |
headers
Martin Husemann | 1 Dec 2011 07:18
Picon

Re: kern/45647: kill from ddb broken

On Thu, Dec 01, 2011 at 03:42:50PM +1100, matthew green wrote:
> perhaps a solution would be to have ddb create a thread that will go
> away that will send the signal asap...

I'm not sure that is worth the trouble - in the case at hand it turned out
to be stuck in kernel and would have been unkillable anyway.
I'm also fine with just removing the command, or making it work in "the easy
case" (if that is detectable) but fail gracefully otherwise.

Martin
Permalink | Reply | 0 comments |
headers
Martin Husemann | 1 Dec 2011 07:20
Picon

Re: kern/45647: kill from ddb broken

The following reply was made to PR kern/45647; it has been noted by GNATS.

From: Martin Husemann <martin <at> duskware.de>
To: matthew green <mrg <at> eterna.com.au>
Cc: gnats-bugs <at> NetBSD.org, kern-bug-people <at> netbsd.org,
	gnats-admin <at> netbsd.org, netbsd-bugs <at> netbsd.org
Subject: Re: kern/45647: kill from ddb broken
Date: Thu, 1 Dec 2011 07:18:35 +0100

 On Thu, Dec 01, 2011 at 03:42:50PM +1100, matthew green wrote:
 > perhaps a solution would be to have ddb create a thread that will go
 > away that will send the signal asap...

 I'm not sure that is worth the trouble - in the case at hand it turned out
 to be stuck in kernel and would have been unkillable anyway.
 I'm also fine with just removing the command, or making it work in "the easy
 case" (if that is detectable) but fail gracefully otherwise.

 Martin
Permalink | Reply | 0 comments |
headers
Jared McNeill | 1 Dec 2011 13:18
Picon

re: kern/45647: kill from ddb broken


You could probably just mutex_tryenter(&proc_lock) and print a message if 
it fails.

On Thu, 1 Dec 2011, matthew green wrote:

>
>> Trying to kill a process from ddb fails:
>>
>> db{1}> kill 0t507
>> Skipping crash dump on recursive panic
>> panic: kernel diagnostic assertion "mutex_owned(proc_lock)" failed: file
"../../../../kern/kern_proc.c", line 590
>
> this is non trivial to solve.
>
> simply taking proc_lock (and more!) isn't going to work if some cpu
> was stopped mid-lock of these.
>
> perhaps a solution would be to have ddb create a thread that will go
> away that will send the signal asap...
>
>
> .mrg.
>
>
Permalink | Reply | 0 comments |
headers
Jared McNeill | 1 Dec 2011 13:20
Picon

re: kern/45647: kill from ddb broken

The following reply was made to PR kern/45647; it has been noted by GNATS.

From: Jared McNeill <jmcneill <at> invisible.ca>
To: matthew green <mrg <at> eterna.com.au>
Cc: gnats-bugs <at> NetBSD.org, kern-bug-people <at> netbsd.org, gnats-admin <at> netbsd.org, 
    netbsd-bugs <at> netbsd.org
Subject: re: kern/45647: kill from ddb broken
Date: Thu, 1 Dec 2011 07:18:43 -0500 (EST)

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 
 You could probably just mutex_tryenter(&proc_lock) and print a message if 
 it fails.

 On Thu, 1 Dec 2011, matthew green wrote:

 >
 >> Trying to kill a process from ddb fails:
 >>
 >> db{1}> kill 0t507
 >> Skipping crash dump on recursive panic
 >> panic: kernel diagnostic assertion "mutex_owned(proc_lock)" failed: file
"../../../../kern/kern_proc.c", line 590
 >
 > this is non trivial to solve.
 >
 > simply taking proc_lock (and more!) isn't going to work if some cpu
 > was stopped mid-lock of these.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Bourne | 1 Dec 2011 18:00
Picon

Re: port-amd64/42980 (satalink DMA fails under amd64)

The following reply was made to PR port-amd64/42980; it has been noted by GNATS.

From: Julian Bourne <julian.bourne <at> gmail.com>
To: gnats-bugs <at> netbsd.org
Cc: 
Subject: Re: port-amd64/42980 (satalink DMA fails under amd64)
Date: Thu, 1 Dec 2011 11:55:40 -0500

 --0015174c3418f653c204b30ab833
 Content-Type: text/plain; charset=UTF-8

 I raised the original issue and its fixed as far as I am concerned.  There
 might have been some manual pages that needed updating and so forth - so
 perhaps the devs can answer that?

 On Wed, Nov 30, 2011 at 7:04 PM, <dholland <at> netbsd.org> wrote:

 > Synopsis: satalink DMA fails under amd64
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: dholland <at> NetBSD.org
 > State-Changed-When: Thu, 01 Dec 2011 00:04:05 +0000
 > State-Changed-Why:
 > This appears to have been committed and pulled up a year ago - is it fixed
 > or is it still awaiting additional work?
 >
 >
 >
 >
(Continue reading)

Permalink | Reply | 0 comments |

Gmane