Could someone please take a look at it before I commit this?
- Forwarded message from Ruslan Ermilov <[EMAIL PROTECTED]> -
Date: Fri, 22 Jun 2001 18:05:09 +0300
From: Ruslan Ermilov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: ucred.cr_gid
Message-ID: <[EMAIL PRO
On 25 Jun, An: [EMAIL PROTECTED] wrote:
>> It seems that there is a bug in the GNU ld(1) in -CURRENT. Currently it can't
>> link SDL library from ports/devel/sdl12 port (confirmed by bento). When I'm
>> replacing /usr/libexec/elf/ld with the corresponding file from my 4.3-STABLE
>> system the pro
On Tue, Jun 26, 2001 at 01:15:17PM +0200, Alexander Leidinger wrote:
> Oops. I wanted to say: Every software which has a problem with ld
> dumping core uses nasm (so far). The core dump is a bug in ld, but I
> didn't know if the condition which triggers the core dump is a problem
> with nasm, the
On Tue, 26 Jun 2001, Ruslan Ermilov wrote:
> Could someone please take a look at it before I commit this?
I won't get a chance to properly review this until I'm at USENIX tomorrow.
If you're willing to hold off for about a week, I'd be happy to give it a
fairly detailed review: I had some thoug
At Tue, 26 Jun 2001 07:23:57 -0700,
David O'Brien wrote:
> If someone could provide me with the minal input to nasm which then fed
> to `ld' dumps core, it would really speed up a fix. :-)
I'm not sure when but this problem seems to be fixed in CVS at
sources.redhat.com. I built binutils from sou
Nevermind -- let's try binutils-2.11.2. :-)
Thanks David!
--
FUJISHIMA Satsuki
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>> Oops. I wanted to say: Every software which has a problem with ld
>> dumping core uses nasm (so far). The core dump is a bug in ld, but I
>> didn't know if the condition which triggers the core dump is a problem
>> with nasm, the input of
On Wed, Jun 27, 2001 at 02:16:48AM +0900, NAKAMURA Kazushi wrote:
> Not only nasm, but also gas has same problem. In case of
> ports/audio/gogo and ports/audio/lame, nasm outputs object which
> make ld dumps core. While gcc+gas outputs object which can't link
> by ld. I think the problem occures
matusita> lock order reversal
matusita> 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
matusita> 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
I've caught tracelog of this reversal, with debug.witness_ddb=1.
Here's console log:
lock order reversal
1st 0xc5e3cfdc process
On 27-Jun-01 Makoto MATSUSHITA wrote:
>
> matusita> lock order reversal
> matusita> 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487
> matusita> 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239
>
> I've caught tracelog of this reversal, with debug.witness_ddb=1.
> Here's cons
On Tue, Jun 26, 2001 at 11:18:56AM -0400, Robert Watson wrote:
>
> On Tue, 26 Jun 2001, Ruslan Ermilov wrote:
>
> > Could someone please take a look at it before I commit this?
>
> I won't get a chance to properly review this until I'm at USENIX tomorrow.
> If you're willing to hold off for abo
>John Baldwin wrote:
>> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try
>> this: find the ahc driver's interrupt handler, and add a printf.
>> Then see if the printf fires while the machine is hung.
>
>Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint().
That wo
Justin T. Gibbs wrote:
> >John Baldwin wrote:
> >> Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try
> >> this: find the ahc driver's interrupt handler, and add a printf.
> >> Then see if the printf fires while the machine is hung.
> >
> >Ok, I put a printf in ahc_handle_seqint()
>> That won't catch all interrupts. Most notably, you won't know
>> if commands are completing. Command completions are much more
>> prevalent than sequencer or scsi interrupts.
>
>should I try and catch the command completions? which routine is best
>to do this in?
ahc_intr() in aic7xxx_inlin
14 matches
Mail list logo
