* Emiel Kollof ([EMAIL PROTECTED]) wrote:
exclusive (sleep mutex) Giant (0xc0462c00) locked @
/usr/src/sys/i386/i386/trap.c:1102
panic: system call pwrite returning with mutex(s) held
Hmm, erm, go kick Alfred really hard. :) This function locks Giant and then
doesn't ever unlock
* Emiel Kollof [EMAIL PROTECTED] [020116 13:29] wrote:
* Emiel Kollof ([EMAIL PROTECTED]) wrote:
exclusive (sleep mutex) Giant (0xc0462c00) locked @
/usr/src/sys/i386/i386/trap.c:1102
panic: system call pwrite returning with mutex(s) held
Hmm, erm, go kick Alfred really hard.
* Alfred Perlstein [EMAIL PROTECTED] [020116 13:30] wrote:
* Emiel Kollof [EMAIL PROTECTED] [020116 13:29] wrote:
* Emiel Kollof ([EMAIL PROTECTED]) wrote:
exclusive (sleep mutex) Giant (0xc0462c00) locked @
/usr/src/sys/i386/i386/trap.c:1102
panic: system call pwrite returning
* Alfred Perlstein ([EMAIL PROTECTED]) wrote:
It would help if someone cc'd me on these. :P
Fix should be in now.
Great! Thanks! Remind me to buy you a beer if I ever get to meet you in
real life :-)
Right.. cvsup it is...
Cheers,
Emiel
--
If you can survive death, you can probably
My kernel compile from fresh CURRENT sources bombed today with this:
linking kernel.debug ddp_input.o: In function `atintr':
/usr/src/sys/netatalk/ddp_input.c:51: multiple definition of `atintrq1_present'
intrq.o(.data+0x0):/usr/src/sys/net/intrq.c: first defined here
ddp_input.o: In function
On 15-Jan-02 Emiel Kollof wrote:
My kernel compile from fresh CURRENT sources bombed today with this:
linking kernel.debug ddp_input.o: In function `atintr':
/usr/src/sys/netatalk/ddp_input.c:51: multiple definition of
`atintrq1_present' intrq.o(.data+0x0):/usr/src/sys/net/intrq.c: first
* John Baldwin ([EMAIL PROTECTED]) wrote:
The panics moan about a kernel trap and some mutex stuff involving
Giant. It only happens when I start Samba.
Having the actual panic messages would be very helpful here.
Hmm, I will proceed to crash my machine again and have a go in hand
* John Baldwin ([EMAIL PROTECTED]) wrote:
lock order reversal 1st 0xc185e934 filedesc structure @
/usr/src/sys/kern/kern_descrip.c:925
2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959
This one is due to not releasing the filedesc lock when grabbing Giant to free
oldofile in
On 16-Jan-02 Emiel Kollof wrote:
* John Baldwin ([EMAIL PROTECTED]) wrote:
lock order reversal 1st 0xc185e934 filedesc structure @
/usr/src/sys/kern/kern_descrip.c:925
2nd 0xc0419b00 Giant @ /usr/src/sys/kern/kern_descrip.c:959
This one is due to not releasing the filedesc lock when
* John Baldwin ([EMAIL PROTECTED]) wrote:
/var: lost blocks 62 files 8
No, that's softupdates stuff. I think releasing filedesc is ok this case,
but usually I would recode it to move malloc's and free's around to avoid
having to drop and reacquire locks.
Ah right... Good to know...
In message [EMAIL PROTECTED], Emiel Kollof writes:
Oh, on another note, is someone working at that netatalk breakage? Who
do I have to discipline for that? :-)
Could you try the following patch in src/sys/netatalk? The problem
was caused by the -fno-common compiler option that was added to
the
* Ian Dowse ([EMAIL PROTECTED]) wrote:
Oh, on another note, is someone working at that netatalk breakage? Who
do I have to discipline for that? :-)
Could you try the following patch in src/sys/netatalk? The problem
was caused by the -fno-common compiler option that was added to
the kernel
* Emiel Kollof ([EMAIL PROTECTED]) wrote:
This compiles for me, but I haven't checked that it actually works.
I will test it. (run netatalk and transfer some files to and fro)
It compiled, and after making a connection with Appletalk with one of my
macs, file transfers went off without a
13 matches
Mail list logo
