Re: VOP_STRATEGY on VCHR?
On Sat, Jan 04, 2003 at 10:48:15PM -0800, walt wrote: After updating world and kernel this evening I saw this message fly by during the reboot: Mounting root from ufs:/dev/ad0s3a VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? See phk's recent commit. Kris msg49688/pgp0.pgp Description: PGP signature
Re: troubles with realplay-er
MPlayer plays these streams perfectly here. On Sunday 05 January 2003 01:29, Mikhail Teterin wrote: This Linux program used to work well, but now it crashes (with SIGABRT) some URLs, such as pnm://rm.content.loudeye.com/~iii-600111/0255135_0101_00_0002.ra pnm://rm.content.loudeye.com/~a-600111/0631342_0103_00_0002.ra or hangs... The crashes are persistent -- the same URL will alway cause the SIGABRT. The hangs are intermittent -- after ``killall -9 realplay'' the new instance will play the same URL. Then -- eventually hang on another... -mi P.S. Teaching libfetch about pnm:// together with mplayer would eliminate the need for RealPlayer :-) Ducks... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, Jan 05, 2003 at 06:00:26PM +1100, Bruce Evans wrote: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis ... No; it would be more profitable to teach programmers to not ignore errors. whereintheworld is perfectly non-broken in not ignoring them. These *** Error messages (not to mention other error ouput from makeworld) also make it harder for human readers to see the actual errors. Agreed. I'd love to hear from fanf what the changes are to unifdef that causes this change in exit code. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rather verbose ACPI errors.
David O'Brien wrote: Ever since the last ACPI import, I get all this output (non-verbose) boot. What's the change on them going away soon? acpi0: PTLTDRSDT on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND In this case, the tyan thunder K7 bios has got a hosed acpi dsdt table. There are referecens to a field Z00Q in a structure, but it isn't defined anywhere. It is regarding the ACPI code to enable the second serial port (pin header on motherboard). It will go away if/when tyan fix the bios. They broke this in a recent upgrade. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR?
In message [EMAIL PROTECTED], walt writes: After updating world and kernel this evening I saw this message fly by during the reboot: Mounting root from ufs:/dev/ad0s3a VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? Well, to you it's just noise, to me it's a real problem :-) It is probably the same problem as the one I just commited a fix for. If you get this again after upgrading, please put the DDB option in your kernel and see if you can reproduce it so I get a traceback. The vnode information alone seems not quite as useful as I had hoped. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nVidia opengl works as root but not as user
Hi, it's getting boring seeing all the nvidia posts but I'm so darn close to having it working here. I have disabled INVARIANTS in the kernel and AGP and running with nvAgp (although I get the same results using kernel agp as well). The thing is that OpenGL apps run perfectly as root, but whenever I use my normal user I can run 1-2 OpenGL apps without any problems but when I run them the next time the machine locks instantly and then reboots, this never happens when I'm running as root. Since it works for root I must be close to having it fully working. Do anyone have any ideas? (No, I don't want to set the suid bit on my opengl apps ;). I've never seen any useful output in my system logs after these reboots, is there any way I can debug the driver without setting up a serial console? //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sat, 4 Jan 2003, Robert Watson wrote: Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: paprika:~/freebsd/test/pthread ./test ... load: 0.23 cmd: test 914 [running] 0.00u 0.01s 0% 824k 1 Bus error (core dumped) Hitting ^T to get status information seems to break output following the first printf after the information display. Here's the stack trace from the test program from the first execution above: This caused a reproducible kernel panic for a null pointer bug in ttyinfo() here, but seemed to work right once I fixed the panic. (The panic was just a bug in my unbreaking of the calculation of rss.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LOR - inp / tcp
-CURRENT from December 28th, 4:00 -0600. Triggered immediately after launching /usr/sbin/rpcbind -l -s /sbin/mountd -l /sbin/nfsd -n4 -t -u (This is the first time this has happened with that combination of operations.) The only kernel modules loaded are vesa, miibus, and if_dc. Sun Jan 5 04:27:31 CST 2003 lock order reversal 1st 0xc13c0c7c inp (inp) @ /usr/src/sys/netinet/tcp_input.c:641 2nd 0xc030b40c tcp (tcp) @ /usr/src/sys/netinet/tcp_usrreq.c:621 Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db sh locks exclusive sleep mutex inp r = 0 (0xc13c0c7c) locked @ /usr/src/sys/netinet/tcp_input.c:641 exclusive sleep mutex Giant r = 0 (0xc03010c0) locked @ /usr/src/sys/kern/kern_intr.c:534 db trace Debugger(c02cdc75,c030b40c,c02e4a2d,c02e4a2d,c02e5bf6) at Debugger+0x54 witness_lock(c030b40c,8,c02e5bf6,26d,1) at witness_lock+0x667 _mtx_lock_flags(c030b40c,0,c02e5bf6,26d,0) at _mtx_lock_flags+0xb1 tcp_usr_rcvd(c13a8b00,80,c5f2fa9c,c01bc5ac,3b9aca00) at tcp_usr_rcvd+0x30 soreceive(c13a8b00,c5f2faac,c5f2fab8,c5f2fab0,0) at soreceive+0x88a nfsrv_rcv(c13a8b00,c170e080,1,34,18) at nfsrv_rcv+0x8a sowakeup(c13a8b00,c13a8b4c,c02e536e,41f,108) at sowakeup+0x97 tcp_input(c09f8b00,14,c0309454,c5f2fc3c,c01906cd) at tcp_input+0xedc ip_input(c09f8b00,0,c02e5016,3aa,2) at ip_input+0x83e ipintr(c02dbb5b,c09d9680,c09d9680,c09e7f00,c5f2fd0c) at ipintr+0x91 swi_net(0,0,c02da578,216,c09ea8e8) at swi_net+0x23 ithread_loop(c09e7f00,c5f2fd48,c02da3ed,361,0) at ithread_loop+0x182 fork_exit(c01874a0,c09e7f00,c5f2fd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc5f2fd7c, ebp = 0 --- db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 612 c16cbc78 ca6ad0000 604 604 000 norm[SLPQnfsd c11f5800][SLP] nfsd 611 c16c7558 ca6680000 604 604 000 norm[SLPQnfsd c1667000][SLP] nfsd 610 c16c7720 ca6690000 604 604 000 norm[SLPQnfsd c1667200][SLP] nfsd 609 c1267c78 ca41d0000 604 604 000 norm[SLPQnfsd c1230e00][SLP] nfsd 608 c1281390 ca6f50000 604 604 000 norm[SLPQnfsd c1668e00][SLP] nfsd 607 c16cb8e8 ca6ab0000 604 604 000 norm[SLPQnfsd c1668a00][SLP] nfsd 606 c16c7390 ca6670000 604 604 000 norm[SLPQnfsd c1668c00][SLP] nfsd 605 c12811c8 ca6c0 604 604 000 norm[RUNQ] nfsd 604 c1281000 ca6bc0000 1 604 000 norm[RUNQ] nfsd 602 c12658e8 ca3dd0000 1 602 000 norm[CVQ select c03043b4][SLP] mountd 600 c1470ab0 ca65e0001 1 600 100 norm[CVQ select c03043b4][SLP] rpcbind 510 c16c7000 ca665000 1000 448 510 0004002 norm[SLPQ ttyin c1345610][SLP] bash 505 c1281720 ca6f7000 1000 504 505 2004002 norm[SLPQ pause ca6f7000][SLP] screen-3.9.13 504 c12818e8 ca6f8000 1000 447 504 0004002 norm[SLPQwait c12818e8][SLP] bash 503 c1281ab0 ca6f90000 1 503 0004002 norm[SLPQ ttyin c1219810][SLP] getty 481 c1338390 ca6fd000 1000 475 481 4004002 norm[CVQ select c03043b4][SLP] vim 480 c1338558 ca6fe000 1000 475 480 4004002 norm[CVQ select c03043b4][SLP] vim 479 c14708e8 ca65d000 1000 475 479 4004002 norm[CVQ select c03043b4][SLP] vim 478 c16c7ab0 ca66f000 1000 475 478 4004002 norm[CVQ select c03043b4][SLP] vim 477 c16c78e8 ca66e000 1000 475 477 4004002 norm[CVQ select c03043b4][SLP] vim 476 c16c71c8 ca666000 1000 475 476 4004002 norm[CVQ select c03043b4][SLP] vim 475 c1470c78 ca65f000 1000 1 475 000 norm[CVQ select c03043b4][SLP] screen-3.9.13 467 c16c7c78 ca6a5000 1000 460 467 4004002 norm[CVQ select c03043b4][SLP] vim 466 c16cb000 ca6a6000 1000 460 466 4004002 norm[CVQ select c03043b4][SLP] vim 465 c16cb1c8 ca6a7000 1000 460 465 4004002 norm[CVQ select c03043b4][SLP] vim 464 c16cb390 ca6a8000 1000 460 464 4004002 norm[CVQ select c03043b4][SLP] vim 463 c16cb558 ca6a9000 1000 460 463 4004002 norm[CVQ select c03043b4][SLP] vim 462 c16cb720 ca6aa000 1000 460 462 4004002 norm[CVQ select c03043b4][SLP] vim 461 c1267558 ca419000 1000 460 461 4004002 norm[CVQ select c03043b4][SLP] vim 460 c1267000 ca416000 1000 459 460 000 norm[CVQ select c03043b4][SLP] screen-3.9.13 459 c1265558 ca3db000 1000 457 457 2004002 norm[SLPQ pause ca3db000][SLP] screen-3.9.13 457 c1265390 ca3da000 1000 455 457 0004002 norm[SLPQwait c1265390][SLP] sh 455 c1267390 ca418000 1000 446 455 0004002 norm[SLPQwait c1267390][SLP] bash 453 c1267720 ca41a0000 445 453 0004002 norm[SLPQ ttyin c09e4a10][SLP] bash 452 c12678e8 ca41b0000 1 452 0004002 norm[SLPQ ttyin c1345c10][SLP] getty 451 c1267ab0 ca41c0000 1 451 0004002 norm[SLPQ ttyin c1219210][SLP] getty 449 c147 ca6580000 1 449 0004002 norm[SLPQ ttyin c1219e10][SLP] getty 448 c14701c8 ca6590000 1 448
Re: VOP_STRATEGY on VCHR?
On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], walt writes: After updating world and kernel this evening I saw this message fly by during the reboot: Mounting root from ufs:/dev/ad0s3a VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), I get this too (except I fixed the misformatting of the message while reviewing the code, so that it is printed on 1 line with a non-bogus :). From /var/log/messages: % Jan 5 21:09:22 gamplex kernel: VOP_STRATEGY on VCHR: 0xc2697000: tag none, type VCHR, usecount 4, writecount 0, refcount 4, flags (VV_OBJBUF), % Jan 5 21:18:37 gamplex kernel: VOP_STRATEGY on VCHR: 0xc2697000: tag none, type VCHR, usecount 4, writecount 0, refcount 4, flags (VV_OBJBUF), (This shows a formatting bug in vprint() itself: the , at the end.) Sorry, need DDB option to print backtrace I have the DDB option, so I don't get this. It is probably the same problem as the one I just commited a fix for. I haven't cvsupped' the fix or debugged it yet. If you get this again after upgrading, please put the DDB option in your kernel and see if you can reproduce it so I get a traceback. The vnode information alone seems not quite as useful as I had hoped. Neither is the traceback. db_trace() prints using db_printf() so the message never reaches log files. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Q) Does perl install libperl.so ?
On 2003.01.05 12:52:03 +, Yamada Ken Takeshi wrote: /usr/ports/lang/perl5 seemingly does not generate libperl.so with FreeBSD-current port as shown below. Is it intended one? Why? This was discussed on the ports list a while ago : http://www.freebsd.org/cgi/getmsg.cgi?fetch=593062+595495+/usr/local/www/db/text/2002/freebsd-ports/20021208.freebsd-ports -- Simon L. Nielsen msg49697/pgp0.pgp Description: PGP signature
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Jan 5 03:04:25 PST 2003 -- Kernel build for GENERIC completed on Sun Jan 5 03:37:06 PST 2003 -- Kernel build for LINT started on Sun Jan 5 03:37:07 PST 2003 -- === vinum Makefile, line 4445: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type cc1: warnings being treated as errors /h/des/src/sys/dev/wi/wi_hostap.c: In function `wihap_init': /h/des/src/sys/dev/wi/wi_hostap.c:208: warning: cast from pointer to integer of different size /h/des/src/sys/dev/wi/wi_hostap.c:208: warning: cast from pointer to integer of different size /h/des/src/sys/dev/wi/wi_hostap.c: In function `wihap_shutdown': /h/des/src/sys/dev/wi/wi_hostap.c:293: warning: cast from pointer to integer of different size /h/des/src/sys/dev/wi/wi_hostap.c:293: warning: cast from pointer to integer of different size /h/des/src/sys/dev/wi/wi_hostap.c:319: warning: cast from pointer to integer of different size *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current/stable remote gdb interoperability
On Sat, Jan 04, 2003 at 06:32:43AM +1100, Bruce Evans wrote: Another possible problem is using the same serial line for gdb as for the console and mixing speeds. If the userland speed differs from the low level speed, then the i/o routines switch back and forth between the speeds for every character and this tends to lose some. The userland speed is locked to the low level speed initially but userland unlock it. Losing a character or two is almost unnoticable in ddb but is fatal in gdb. I normally set all speeds to 115200 so I only see this problem when I look for it. Unless I'm misunderstanding, the serial port isn't doing any such double duty. I've explicity toggled between sio flags 0x10 and 0x80 in device.hints depending on what I'm trying to figure out. (In reality, it's more often trying to get useful information for others that can figure stuff out. :).) For what it's worth, I've taken Nate's suggestion and backed down to 9600bps, and this problem hasn't occurred yet, so I'm assuming this is the fix. (The 4.7 machine has an ASUS P2B-D board, and the -CURRENT box is a recent Dell Dimension, so I don't *think* I'm using garbage serial hardware.) Though slow, I guess I can't complain if it works. :). -- ryan beasley[EMAIL PROTECTED] GPG ID: 0x16EFBD48 http://www.goddamnbastard.org msg49699/pgp0.pgp Description: PGP signature
kernel compile bloat
Why does compiling a kernel (make buildkernel KERNCONF=GENERIC) take
7 times as much space on 5.0-current than it does on 4.7-stable?
On a 4.7-stable box, /usr/obj/usr/src/sys totals 34 MB.
On a 5.0-current box, /usr/obj/usr/src/sys totals 270 MB!
(for each box, I rm /usr/obj/*, make buildworld, then make buildkernel
KERNCONF=GENERIC)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Q) Does perl install libperl.so ?
Thank you, Simon for your response with pointer. I think I overlooked these as I did not care about then. I read through articles you pointed, but couldn't find the conclusion. What was the outcome of the discussion? or, still pending? I am now wrecked at 'plperl' installation as it is mentioned in the discussion. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, 2003/01/05 at 01:33:14 -0800, David O'Brien wrote:
On Sun, Jan 05, 2003 at 06:00:26PM +1100, Bruce Evans wrote:
=== usr.bin/vi
*** Error code 1 (ignored)
*** Error code 1 (ignored)
=== usr.bin/vis
..
No; it would be more profitable to teach programmers to not ignore errors.
whereintheworld is perfectly non-broken in not ignoring them. These
*** Error messages (not to mention other error ouput from makeworld)
also make it harder for human readers to see the actual errors.
Agreed. I'd love to hear from fanf what the changes are to unifdef that
causes this change in exit code.
According to the man page, this is the correct behaviour:
The unifdef utility exits 0 if the output is an exact copy of the input,
1 if not, and 2 if in trouble.
The exit status code in unifdef seems to have been broken before for a
while.
The vi Makefile just was sloppy in checking for the exit code; it
should probably check for 1 and exclude 0 also, like:
--- Makefile29 Jul 2002 09:40:16 - 1.38
+++ Makefile5 Jan 2003 13:20:49 -
@@ -75,10 +75,12 @@
# unifdef has some *weird* exit codes, sigh! RTFM unifdef(1)...
ex_notcl.c: ex_tcl.c
- -unifdef -UHAVE_TCL_INTERP ${SRCDIR}/ex/ex_tcl.c ${.TARGET}
+ ! { unifdef -UHAVE_TCL_INTERP ${SRCDIR}/ex/ex_tcl.c ${.TARGET} || \
+ [ $$? -ne 1 ] ; }
ex_noperl.c: ex_perl.c
- -unifdef -UHAVE_PERL_INTERP ${SRCDIR}/ex/ex_perl.c ${.TARGET}
+ ! { unifdef -UHAVE_PERL_INTERP ${SRCDIR}/ex/ex_perl.c ${.TARGET} || \
+ [ $$? -ne 1 ] ; }
CLEANFILES+= ex_notcl.c ex_noperl.c
---
(there's probably a more elegant way to do this, my sh is a bit
rusty).
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Panic when using Wine
Hi all, I got following panic, while trying to run Wine (ver.2002.12.19). ---8--8--8--8--8--8--8--8--8--- Mounting root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted VOP_STRATEGY on VCHR : 0xc197b000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags :(VV_OBJBUF), lock order reversal 1st 0xc198c950 process lock (process lock) @ ../../../kern/kern_descrip.c:2099 2nd 0xc1975634 filedesc structure (filedesc structure) @ ../../../kern/kern_descrip.c:2106 biodone: page busy 0, pindex: 0, foff: 0x(0,0), resid: 4096, index: 0 iosize: 4096, lblkno: 0, flags: 0x2220, npages: 1 valid: 0xff, dirty: 0x0, wired: 1 panic: biodone: page busy 0 syncing disks, buffers remaining... panic: bdwrite: buffer is not busy Uptime: 6m27s pfs_vncache_unload(): 1 entries remaining Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ---8--8--8--8--8--8--8--8--8--- Has anyone seen this? Thank you, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Q) Does perl install libperl.so ?
On 2003.01.05 21:23:32 +, Yamada Ken Takeshi wrote: I read through articles you pointed, but couldn't find the conclusion. What was the outcome of the discussion? or, still pending? I think the original submitter of the problem would try to look in to why plperl did not use the .a version, but since I don't use plperl myself I have not looked more at it myself. I am now wrecked at 'plperl' installation as it is mentioned in the discussion. :-( -- Simon L. Nielsen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel compile bloat
On Sun, 5 Jan 2003 22:14:26 +1000 (EST) Andy Farkas [EMAIL PROTECTED] wrote: Why does compiling a kernel (make buildkernel KERNCONF=GENERIC) take 7 times as much space on 5.0-current than it does on 4.7-stable? On a 4.7-stable box, /usr/obj/usr/src/sys totals 34 MB. On a 5.0-current box, /usr/obj/usr/src/sys totals 270 MB! (for each box, I rm /usr/obj/*, make buildworld, then make buildkernel KERNCONF=GENERIC) Because debug symbols are enabled in 5.0 for kernel compiles (the installed kernel is without debug symbols, but in your kernel build directory should also be a much larger kernel.debug). Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Saturday, January 4, 2003, at 06:00 PM, Robert Watson wrote: On Sat, 4 Jan 2003, Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2003-01-04 ] [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: Incidentally, this doesn't illustrate the problem I was actually trying to point out. Try making the sleep's pthread_yield(). That will make the threads never run again. sleep is the hack I've had to do. In my appp, I have a 'my_yield' function which will sleep on FreeBSD, and yield on everywhere else :( Hmm. I'm not experiencing that problem -- if I replace the sleep() with pthread_yield(), I get a long sequence of '1's until thread2 is started, and then clean alternation between '1' and '2'. I don't see any failure to schedule a thread after it has yielded. I'm updating my box from Dec 29 to today to see if that makes a difference either way on either problem. With pthread_yield() I get the same as Watson. It still core's with a few ctrl-T's. I'm running today's source. -DR To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic: Initiate_write_inodeblock_ufs1: already started
Recompiled the kernel (GENERIC) and installed.
But now it panics on:
Initiate_write_inodeblock_ufs1: already started.
--WjW
PS: Once it trips into the debugger, how do I get it to dump?
panic just reboots.
- Original Message -
From: [EMAIL PROTECTED]
To: Willem Jan Withagen [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, January 04, 2003 9:57 AM
Subject: Re: panic with panic: kmem_malloc(4096): kmem_map too small...
In message 03a701c2b38c$8e3ad990$471b3dd4@dual, Willem Jan Withagen writes:
Which seems a problem sticking up it's head once so often.
I had it happen to me now 3 times over the last day. It just drops into the
debugger.
And I've foun little extra info in the archive.
What dows this actually mean? Is something leaking in the kernel.
IF so how do I help it go away.
I'm copy 100G from a W2K system to my vinum file server with a 170G raid5.
Current is as of 28 dec...
Please try to move up to current as of today. On Dec 29th I commited
code to make the desiredvnodes a limit rather than a vague suggestion
and that should solve your problem I hope.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: Panic: Initiate_write_inodeblock_ufs1: already started
In message 063601c2b4d0$ff02dc50$471b3dd4@dual, Willem Jan Withagen writes: Recompiled the kernel (GENERIC) and installed. But now it panics on: Initiate_write_inodeblock_ufs1: already started. When does it panic ? in the boot sequence ? after ? Can you get me the first 4-5 lines of the output from trace ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Calling gcc created constructors in the kernel...
I want to get --test-coverage and --profile-arcs working for the
kernel in order to give us better statistical tools.
Unfortunately, GCC now uses construcorts to string the counters into
a list, and we don't call constructors in the kernel.
Would it be evil to do that ?
I've managed to get it working with the following patch, a modified
version of kernbb(8) and the standard GCC::gcov binary.
Any objections to me committing this ?
Is there a better way to get the start and end of the .ctors section ?
Poul-Henning
Index: conf/ldscript.i386
===
RCS file: /home/ncvs/src/sys/conf/ldscript.i386,v
retrieving revision 1.6
diff -u -r1.6 ldscript.i386
--- conf/ldscript.i386 11 Oct 2002 19:38:04 - 1.6
+++ conf/ldscript.i386 5 Jan 2003 13:50:12 -
@@ -65,10 +65,14 @@
CONSTRUCTORS
}
.data1 : { *(.data1) }
+ _start_ctors = .;
+ PROVIDE (start_ctors = .);
.ctors :
{
*(.ctors)
}
+ _stop_ctors = .;
+ PROVIDE (stop_ctors = .);
.dtors :
{
*(.dtors)
Index: kern/subr_prof.c
===
RCS file: /home/ncvs/src/sys/kern/subr_prof.c,v
retrieving revision 1.55
diff -u -r1.55 subr_prof.c
--- kern/subr_prof.c1 Oct 2002 13:15:11 - 1.55
+++ kern/subr_prof.c5 Jan 2003 13:53:38 -
@@ -78,6 +78,7 @@
}
#endif /* GUPROF */
+
/*
* Update the histograms to support extending the text region arbitrarily.
* This is done slightly naively (no sparse regions), so will waste slight
@@ -157,6 +158,7 @@
uintfptr_t tmp_addr;
#endif
+ tcov_init();
/*
* Round lowpc and highpc to multiples of the density we're using
* so the rest of the scaling (here and in gprof) stays in ints.
@@ -531,3 +533,24 @@
}
stopprofclock(p);
}
+
+#if 1
+typedef void (*ctor_t)(void);
+extern ctor_t _start_ctors, _stop_ctors;
+
+static void
+tcov_init(void *foo __unused)
+{
+ ctor_t *p, q;
+
+ printf(_start_ctors %p %p\n, _start_ctors, _start_ctors);
+ printf(_stop_ctors %p %p\n, _stop_ctors, _stop_ctors);
+ for (p = _start_ctors; p _stop_ctors; p++) {
+ printf( ctor %p %p\n, p, *p);
+ q = *p;
+ q();
+ }
+}
+
+SYSINIT(kmem, SI_SUB_KPROF, SI_ORDER_SECOND, tcov_init, NULL)
+#endif
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: nVidia opengl works as root but not as user
Hmm, when I mounted my home dir as read-only I was able to use OpenGL as a normal user. But I've looked all through my home dir and I can't find anything there that would affect OpenGL if the user had write access to the partition =(. //David Holm On Sunday 05 January 2003 11:38, David Holm wrote: Hi, it's getting boring seeing all the nvidia posts but I'm so darn close to having it working here. I have disabled INVARIANTS in the kernel and AGP and running with nvAgp (although I get the same results using kernel agp as well). The thing is that OpenGL apps run perfectly as root, but whenever I use my normal user I can run 1-2 OpenGL apps without any problems but when I run them the next time the machine locks instantly and then reboots, this never happens when I'm running as root. Since it works for root I must be close to having it fully working. Do anyone have any ideas? (No, I don't want to set the suid bit on my opengl apps ;). I've never seen any useful output in my system logs after these reboots, is there any way I can debug the driver without setting up a serial console? //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
specfs lock plumbing broken
The following change uncovers bugs in specfs locking and other places:
% RCS file: /home/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
% Working file: ufs_vnops.c
% head: 1.222
% ...
%
% revision 1.221
% date: 2003/01/04 08:47:19; author: phk; state: Exp; lines: +0 -9
% Since Jeffr made the std* functions the default in rev 1.63 of
% kern/vfs_defaults.c it is wrong for the individual filesystems to use
% the std* functions as that prevents override of the default.
%
% Found by: src/tools/tools/vop_table
%
specfs has always attempted to override the default to get no locking,
but having the std* in ufs_vnops.c overrode the override so specfs got
locking after all. This turns out to be essential for avoiding fatally
inconsistent lock states and not just for avoiding races. Without it,
the following bugs in ffs_vget() and deadfs are fatal:
- ffs_vget() returns a locked vnode ... according to ffs's idea of locking.
It calls lockmgr() directly, which gives the same result as ufs's
vop_lock which is vop_stdlock(). The vnode never gets unlocked if it
is handled by a file system whose vop_lock is vop_nolock (like specfs
with the above change).
- deadfs overrides the default for vop_lock but not for vop_unlock. So
when a vnode that was left bogusly locked by the above bugs is
revoked, deadfs_lock() is happy with it (it does nothing much), but
deadfs's vop_unlock (== vop_stdunlock) passes it to lockmgr() and
lockmgr() is often unhappy with it. For me, the bug was usually fatal
at reboot time because lockmgr() was unhappy with the shell unlocking
a vnode that was exclusively locked by a long-dead process. The
exclusive lock had no effect while the vnode was handled by specfs
because lockmgr() didn't get a chance to check it.
Fixing specfs is simple:
%%%
Index: spec_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/specfs/spec_vnops.c,v
retrieving revision 1.193
diff -u -2 -r1.193 spec_vnops.c
--- spec_vnops.c5 Jan 2003 10:03:57 - 1.193
+++ spec_vnops.c5 Jan 2003 15:58:55 -
@@ -85,9 +89,7 @@
{ vop_getwritemount_desc, (vop_t *) vop_stdgetwritemount },
{ vop_ioctl_desc, (vop_t *) spec_ioctl },
- { vop_islocked_desc, (vop_t *) vop_noislocked },
{ vop_kqfilter_desc, (vop_t *) spec_kqfilter },
{ vop_lease_desc, (vop_t *) vop_null },
{ vop_link_desc, (vop_t *) vop_panic },
- { vop_lock_desc, (vop_t *) vop_nolock },
{ vop_mkdir_desc, (vop_t *) vop_panic },
{ vop_mknod_desc, (vop_t *) vop_panic },
@@ -108,5 +110,4 @@
{ vop_strategy_desc, (vop_t *) spec_strategy },
{ vop_symlink_desc,(vop_t *) vop_panic },
- { vop_unlock_desc, (vop_t *) vop_nounlock },
{ vop_write_desc, (vop_t *) spec_write },
{ NULL, NULL }
%%%
Bugs found while investigating this:
- spec_print() is unreachable because ufs_vnops.c overrides it.
- spec_print() is of low quality: it doesn't print the device name or number.
- devfs_print() would be reachable but doesn't exist, so vprint() prints
even lower quality output for devfs since there nothing prints an inode
number either.
- the vop tables work even worse than might first appear.
- other entries in specfs's vop table seem to be unreachable or unnecessary
(because the default is better).
- deadfs is also missing an override for vop_islocked. This is OK provided
it is never passed locked vnodes.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR?
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], walt writes: VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? Well, to you it's just noise, to me it's a real problem :-) It is probably the same problem as the one I just commited a fix for. Your patch eliminated my noise -- I hope it also fixed your problem ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
In message [EMAIL PROTECTED], Bruce Evans writes: The following change uncovers bugs in specfs locking and other places: Wow, that was fun! :-/ I always wondered why specfs would insist on no locking, but I never had much ambition for finding out. Fixing specfs is simple: This is not tested with DEVFS I take it ? Bugs found while investigating this: - spec_print() is unreachable because ufs_vnops.c overrides it. - spec_print() is of low quality: it doesn't print the device name or number. spec_print should probably just be retired, after all specfs is only a set of common helper functions and not a filesystem as such. - the vop tables work even worse than might first appear. I agree, but I have no ambition to fiddle with the mechanics of them. - other entries in specfs's vop table seem to be unreachable or unnecessary (because the default is better). Suggestions ? - deadfs is also missing an override for vop_islocked. This is OK provided it is never passed locked vnodes. I have no opinion on this one. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nVidia opengl works as root but not as user
David Holm wrote: Hi, it's getting boring seeing all the nvidia posts but I'm so darn close to having it working here... May I ask what you've done to get as far as you have? I have their driver working okay on -STABLE but of course it won't even compile on -CURRENT and I don't know enough to fix it. I'm using their file NVIDIA_FreeBSD-1.0-3203.tar.gz. Are there other sources I could be trying? Other patches? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel compile bloat
On Sun, 5 Jan 2003, Alexander Leidinger wrote: On Sun, 5 Jan 2003 22:14:26 +1000 (EST) Andy Farkas [EMAIL PROTECTED] wrote: Why does compiling a kernel (make buildkernel KERNCONF=GENERIC) take 7 times as much space on 5.0-current than it does on 4.7-stable? On a 4.7-stable box, /usr/obj/usr/src/sys totals 34 MB. On a 5.0-current box, /usr/obj/usr/src/sys totals 270 MB! (for each box, I rm /usr/obj/*, make buildworld, then make buildkernel KERNCONF=GENERIC) Because debug symbols are enabled in 5.0 for kernel compiles (the installed kernel is without debug symbols, but in your kernel build directory should also be a much larger kernel.debug). It also builds modules. Normal bloat for -current is a measly factor of 2 or so. My kernel compile directory has size 340MB, but it has 9 kernels including GENERIC and LINT and copies of *.o in all of them. My normal kernel takes 12MB including 4M for a copy of *.o; GENERIC takes 135MB including 50MB for the copy. This is with modules avoided as far as possible; building modules would more than double the size of everything. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Examples of School Web Sites
Found some other school web sites that we may want to compare ours too! http://bearcat.ubly.k12.mi.us/links/links.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Periodic scripts ignore bzip2ed log files
When newsyslog.conf was modified to compress rotated log files with bzip2
instead of gzip some 3 months ago, most of the periodic scripts that process
those log files were not tought how to decompress those archived files.
This affects the following scripts:
etc/periodic/daily/470.status-named
etc/periodic/security/800.loginfail
etc/periodic/security/900.tcpwrap
The result is incomplete processing of log files and possibly the loss
of important warnings that else might have been generated.
In case there are no objections, I intend to commit the following patches
(which should be merged to 5.0R before the release, IMHO).
Regards, STefan
Index: etc/periodic/daily/470.status-named
===
RCS file: /usr/cvs/src/etc/periodic/daily/470.status-named,v
retrieving revision 1.4
diff -u -r1.4 470.status-named
--- etc/periodic/daily/470.status-named 7 Dec 2002 23:37:44 - 1.4
+++ etc/periodic/daily/470.status-named 4 Jan 2003 17:33:00 -
@@ -14,7 +14,13 @@
catmsgs() {
find /var/log -name 'messages.*' -mtime -2 |
sort -t. -r -n -k 2,2 |
- xargs zcat -f
+ while read f
+ do
+ case $f in
+ *.gz) zcat -f $f;;
+ *.bz2) bzcat -f $f;;
+ esac
+ done
[ -f /var/log/messages ] cat /var/log/messages
}
Index: etc/periodic/security/800.loginfail
===
RCS file: /usr/cvs/src/etc/periodic/security/800.loginfail,v
retrieving revision 1.4
diff -u -r1.4 800.loginfail
--- etc/periodic/security/800.loginfail 24 Sep 2002 18:53:46 - 1.4
+++ etc/periodic/security/800.loginfail 4 Jan 2003 17:33:15 -
@@ -45,7 +45,13 @@
catmsgs() {
find ${LOG} -name 'auth.log.*' -mtime -2 |
sort -t. -r -n -k 2,2 |
- xargs zcat -f
+ while read f
+ do
+ case $f in
+ *.gz) zcat -f $f;;
+ *.bz2) bzcat -f $f;;
+ esac
+ done
[ -f ${LOG}/auth.log ] cat $LOG/auth.log
}
Index: etc/periodic/security/900.tcpwrap
===
RCS file: /usr/cvs/src/etc/periodic/security/900.tcpwrap,v
retrieving revision 1.2
diff -u -r1.2 900.tcpwrap
--- etc/periodic/security/900.tcpwrap 24 Sep 2002 18:53:46 - 1.2
+++ etc/periodic/security/900.tcpwrap 4 Jan 2003 17:33:38 -
@@ -45,7 +45,13 @@
catmsgs() {
find ${LOG} -name 'messages.*' -mtime -2 |
sort -t. -r -n -k 2,2 |
- xargs zcat -f
+ while read f
+ do
+ case $f in
+ *.gz) zcat -f $f;;
+ *.bz2) bzcat -f $f;;
+ esac
+ done
[ -f ${LOG}/messages ] cat $LOG/messages
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce Evans writes: The following change uncovers bugs in specfs locking and other places: Wow, that was fun! :-/ It took a while, yes %-). I always wondered why specfs would insist on no locking, but I never had much ambition for finding out. Me too. It seems to be mostly a mistake. Fixing specfs is simple: This is not tested with DEVFS I take it ? It doesn't affect devfs because devfs doesn't go through ufs. It goes straight to the default vnodeop table so it gets std* since it doesn't override them. Bugs found while investigating this: - spec_print() is unreachable because ufs_vnops.c overrides it. - spec_print() is of low quality: it doesn't print the device name or number. spec_print should probably just be retired, after all specfs is only a set of common helper functions and not a filesystem as such. It can remove some knowledge of devices from ufs. There are similar problems for vprinting fifos. - the vop tables work even worse than might first appear. I agree, but I have no ambition to fiddle with the mechanics of them. - other entries in specfs's vop table seem to be unreachable or unnecessary (because the default is better). Suggestions ? Surely the table doesn't need so many vop_panic's? Panicing for unsupported things should be the default. I can't see where some of the others are called. I'm getting some other panics. One while writing this was bwrite: buffer is not busy???. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sat, 4 Jan 2003, Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2003-01-04 ] [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: Incidentally, this doesn't illustrate the problem I was actually trying to point out. Try making the sleep's pthread_yield(). That will make the threads never run again. sleep is the hack I've had to do. In my appp, I have a 'my_yield' function which will sleep on FreeBSD, and yield on everywhere else :( Updating to Jan 4 kernel generates the same failure mode for me: following a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: (gdb) bt #0 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 #1 0x2807a749 in pthread_mutex_unlock () from /usr/lib/libc_r.so.5 #2 0x28136164 in funlockfile () from /usr/lib/libc.so.5 #3 0x2812c6ab in vfprintf () from /usr/lib/libc.so.5 #4 0x2811ab82 in printf () from /usr/lib/libc.so.5 #5 0x08048611 in thread1 (arg=0x0) at test.c:12 #6 0x280732ce in _thread_start () from /usr/lib/libc_r.so.5 There's a bit more noise if I run it under gdb, since gdb picks up the SIGINFO delivery (twice?) but the same result occurs in the end: 1load: 0.07 cmd: test 690 [running] 0.04u 0.20s 0% 816k Program received signal SIGINFO, Information request. 0x280d4c83 in poll () from /usr/lib/libc.so.5 (gdb) cont Continuing. Program received signal SIGINFO, Information request. 0x280d4c83 in poll () from /usr/lib/libc.so.5 (gdb) cont Continuing. Program received signal SIGBUS, Bus error. [Switching to Process 690, Thread 4] 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 (gdb) trace trace command requires an argument (gdb) bt #0 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 #1 0x2807a749 in pthread_mutex_unlock () from /usr/lib/libc_r.so.5 #2 0x28136164 in funlockfile () from /usr/lib/libc.so.5 #3 0x2812c6ab in vfprintf () from /usr/lib/libc.so.5 #4 0x2811ab82 in printf () from /usr/lib/libc.so.5 #5 0x08048611 in thread1 (arg=0x0) at test.c:12 #6 0x280732ce in _thread_start () from /usr/lib/libc_r.so.5 (gdb) Either way, still not the symptoms you have, but equally fatal. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
In message [EMAIL PROTECTED], Bruce Evans writes: On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: I always wondered why specfs would insist on no locking, but I never had much ambition for finding out. Me too. It seems to be mostly a mistake. Fixing specfs is simple: This is not tested with DEVFS I take it ? It doesn't affect devfs because devfs doesn't go through ufs. It goes straight to the default vnodeop table so it gets std* since it doesn't override them. Uhm, no. DEVFS only goes to the default vector for directories, for devices it goes to spec_vnoperate. I'm getting some other panics. One while writing this was bwrite: buffer is not busy???. Yes, I'm hunting that one atm, but havn't found a way to reproduce. Did you get any complaints about the wrong strategy for the wrong type of node before this panic ? Do you have DEBUG_VFS_LOCKS in your kernel ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gdb: failed to set signal flags properly for ast()
While debugging the recent pthreads problem, I've started running into
this:
pid 663 (test), uid 1000: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
pid 709 (test), uid 0: exited on signal 10 (core dumped)
pid 713 (test), uid 0: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
It appears to happen frequently when running the previously posted test
source code for -pthread under gdb. When running the test program outside
of gdb, this doesn't happen, suggesting a possible interaction with
ptrace. To trigger it the first time under gdb, I have to hit Ctrl-T,
then type continue a few times. Under gdb, Ctrl-T appears to sometimes
cause a sigbus; the rest of the time, it causes this warning to start
being generated while the program continues. Once the warning has started
to be generated, it gets generated about 12 times almost immediately, and
then intermittently from then onwards.
Source below. Compiled using -g, -Wall, -pthread. (so not KSE)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
#include pthread.h
#include stdio.h
#include unistd.h
void *
thread1(void *arg)
{
while (1) {
/* sleep(2); */
pthread_yield();
printf(1\n);
}
}
void *
thread2(void *arg)
{
sleep(1);
while (1) {
/* sleep(2); */
pthread_yield();
printf(2\n);
}
}
int
main(int argc, char *argv[]) {
pthread_t t1, t2;
int error;
error = pthread_create(t1, NULL, thread1, NULL);
error = pthread_create(t2, NULL, thread2, NULL);
error = pthread_join(t1, NULL);
error = pthread_join(t2, NULL);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, Jan 05, 2003 at 18:00 +1100, Bruce Evans wrote: On Sat, 4 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Peter Wemm writes: No, it isn't the regression tests. It is this here in the start of stage 4: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis As soon as 'whereintheworld' sees an 'error code', it starts dumping that entire block to the end. If you care to find and fix the build in vi, that would solve it. I think it would be more profitable to teach whereintheworld about the (ignored) string, wouldn't it ? No; it would be more profitable to teach programmers to not ignore errors. Amen! :] Although the above case is special from what I learnt in another message in this thread (I managed to delete it after seeing it so I cannot quote it here). ISTR that the non zero exit status comes from a tool with the following convention: 0 is absolutely OK, 1 is not perfect but still plausible enough to get accepted most of the time, and 2 is a real error, never OK. So the exit code of 1 is more of a warning than an error. Ignoring _any_ non zero exit status in the Makefile is an error. The rule should instead accept success and warning messages as success while bailing out on the errors. This can be done with shell syntax as I have seen in some small test: $ sh -c 'exit 0'; [ $? -le 1 ] $ echo $? 0 $ sh -c 'exit 1'; [ $? -le 1 ] $ echo $? 0 $ sh -c 'exit 2'; [ $? -le 1 ] $ echo $? 1 $ sh -c 'exit 3'; [ $? -le 1 ] $ echo $? 1 This means: adding the [ $? -le 1 ] test to the Makefile rule and *not* ignoring the command's (sequence's) exit status will prevent the acceptable warning from stopping the build while real errors do break the build as one would expect from make(1). And the mentioned tool (sorry, I don't remember its name) is still able to warn those who are interested (release builders?). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s get gpg key [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb: failed to set signal flags properly for ast()
In message [EMAIL PROTECTED], Robe
rt Watson writes:
While debugging the recent pthreads problem, I've started running into
this:
pid 663 (test), uid 1000: exited on signal 10 (core dumped)
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
failed to set signal flags properly for ast()
I can't remember how I triggered this, but I have personally
run with this patch for some time:
(NB: CutPaste)
Index: kern/subr_trap.c
===
RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v
retrieving revision 1.239
diff -u -r1.239 subr_trap.c
--- kern/subr_trap.c28 Dec 2002 01:23:07 - 1.239
+++ kern/subr_trap.c28 Dec 2002 09:05:22 -
@@ -74,6 +74,7 @@
{
struct proc *p = td-td_proc;
struct kse *ke = td-td_kse;
+ static int enough;
CTR3(KTR_SYSC, userret: thread %p (pid %d, %s), td, p-p_pid,
p-p_comm);
@@ -84,7 +85,8 @@
mtx_lock_spin(sched_lock);
if (SIGPENDING(p) ((p-p_sflag PS_NEEDSIGCHK) == 0 ||
(td-td_kse-ke_flags KEF_ASTPENDING) == 0))
- printf(failed to set signal flags properly for ast()\n);
+ if (++enough 10)
+ printf(failed to set signal flags properly for ast()\n);
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
mtx_unlock(Giant);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
Hi, I had to install the e2fstools port before I could access my e2fs partitions after installing -current. Thereafter everything has been fine. No problems with the disk, etc. The only thing that is a problem is if your e2fs partion(s) are mounted and your system crashes or the mount is uncleanly shut down. Then I have to use a linux livecd to repair the partition as the freebsd e2fsck often isn't able to clean up the mess. Regards, Paul Rahul Siddharthan wrote: I decided to bump my laptop up to 5.0-CURRENT today. All seems to have gone well and all my old binaries work fine, it looks very nice. However, I can no longer mount my linux partition: when I try, I get # mount -t ext2fs /dev/ad0s2 /mnt ext2fs: /dev/ad0s2: No such file or directory Did something change when I install new bootblocks, and how do I fix it? Below, output from fdisk and disklabel. I don't remember anything unusual before the upgrade. Thanks, Rahul --- # fdisk *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=19485 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=19485 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 13912227 (6793 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 865/ head 254/ sector 63 The data for partition 2 is: sysid 131 (0x83),(Linux native) start 13912290, size 5719140 (2792 Meg), flag 0 beg: cyl 866/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # disklabel -r /dev/ad0s2 # /dev/ad0s2: type: ESDI disk: ad0s2 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 356 sectors/unit: 5719140 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 5719140 13912290unused0 0 # (Cyl. 866 - 1221) e: 5719140 139122904.2BSD 1024 819216 # (Cyl. 866 - 1221) partition c: offset past end of unit partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities partition e: offset past end of unit partition e: partition extends past end of unit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
In message [EMAIL PROTECTED], Paul A. Mayer writes: Hi, I had to install the e2fstools port before I could access my e2fs partitions after installing -current. Thereafter everything has been fine. No problems with the disk, etc. The only thing that is a problem is if your e2fs partion(s) are mounted and your system crashes or the mount is uncleanly shut down. Then I have to use a linux livecd to repair the partition as the freebsd e2fsck often isn't able to clean up the mess. The kernel should probably printf a warning about this if it rejects the mount because the filesystem is dirty. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
Hi Poul-Henning, I does printf, but it doesn't initiate the e2fsck. Using the ports e2fsck has not shown itself to be the way to do restore order. (I get et hav of ata unaligned access errors and lots of other garbage.) It's easier to boot up a Gentoo LiveCD and do it right.) Thanks, Paul [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Paul A. Mayer writes: Hi, I had to install the e2fstools port before I could access my e2fs partitions after installing -current. Thereafter everything has been fine. No problems with the disk, etc. The only thing that is a problem is if your e2fs partion(s) are mounted and your system crashes or the mount is uncleanly shut down. Then I have to use a linux livecd to repair the partition as the freebsd e2fsck often isn't able to clean up the mess. The kernel should probably printf a warning about this if it rejects the mount because the filesystem is dirty. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: This is not tested with DEVFS I take it ? It doesn't affect devfs because devfs doesn't go through ufs. It goes straight to the default vnodeop table so it gets std* since it doesn't override them. Uhm, no. DEVFS only goes to the default vector for directories, for devices it goes to spec_vnoperate. Hmm, that means that the spec_vnoperate() overrides actually worked, so devfs has never had locking and fixing specfs might break devfs :-). But devfs didn't have the bug either. This is presumably ufs stays out of its way in another way: it doesn't use ffs_vget(), so the vnode is not bogusly locked initially. I'm getting some other panics. One while writing this was bwrite: buffer is not busy???. Yes, I'm hunting that one atm, but havn't found a way to reproduce. Did you get any complaints about the wrong strategy for the wrong type of node before this panic ? I didn't notice one for that, but there is a panic for running wine which seems to be easy to reproduce and the message occurred just before that for at least the second of 2 panics in 2 attempts to run wine here. It was something simple involving vop_stdgetpages ...- ffsext_strategy ... ffs presumably avoids this path by having a specialized getpages. Do you have DEBUG_VFS_LOCKS in your kernel ? No. Also no INVARIANTS and the like. A profiling kernel (with profiling not running) seemed to panic faster. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sun, 5 Jan 2003, Robert Watson wrote: Updating to Jan 4 kernel generates the same failure mode for me: following What makes you think it's the kernel? a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sun, 5 Jan 2003, Julian Elischer wrote: On Sun, 5 Jan 2003, Robert Watson wrote: Updating to Jan 4 kernel generates the same failure mode for me: following What makes you think it's the kernel? Well, to be more precise, I upgraded the entire system to Jan 4. I'm assuming it's something about poor signal handling in libc_r, actually. a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
On Sun, 5 Jan 2003, Paul A. Mayer wrote: I does printf, but it doesn't initiate the e2fsck. Using the ports It prints essentially the same mount failure message as ufs. e2fsck has not shown itself to be the way to do restore order. (I get et hav of ata unaligned access errors and lots of other garbage.) It always worked for me until block devices were axed. Apparently it still depends on random accesses to non-block boundaries and sizes working. It's easier to boot up a Gentoo LiveCD and do it right.) Or upgrade to FreeBSD-3 to get unaxed block devices :-. The ext2fs utilites work on regular files (better than ffs ones), so they can be used (very slowly and with muttering about axes) directly under FreeBSD by copying partitions to regular files, fixing them there, and copying them back. This is least painful for mke2fs since you can start with a sparse file instead of a copy of a partition. [Context lost to top posting] Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
On Mon, 6 Jan 2003, Bruce Evans wrote: - spec_print() is of low quality: it doesn't print the device name or number. - devfs_print() would be reachable but doesn't exist, so vprint() prints even lower quality output for devfs since there nothing prints an inode number either. I was the one who left vprint in a not-so-desirable state. I plan to fix it very soon if you can tell me what info should be printed at what layer. For instance, several fs's print the device but this is probably unnecessary since specfs could do this. Care to elaborate? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Periodic scripts ignore bzip2ed log files
On Sun, Jan 05, 2003 at 07:38:58PM +0100, Stefan Esser wrote: When newsyslog.conf was modified to compress rotated log files with bzip2 instead of gzip some 3 months ago, most of the periodic scripts that process those log files were not tought how to decompress those archived files. This affects the following scripts: etc/periodic/daily/470.status-named etc/periodic/security/800.loginfail etc/periodic/security/900.tcpwrap Looks good. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic: Initiate_write_inodeblock_ufs1: already started
On Sun, Jan 05, 2003 at 05:01:15PM +0100, [EMAIL PROTECTED] wrote: In message 063601c2b4d0$ff02dc50$471b3dd4@dual, Willem Jan Withagen writes: But now it panics on: Initiate_write_inodeblock_ufs1: already started. When does it panic ? in the boot sequence ? after ? After about 24 hrs for me. Can you get me the first 4-5 lines of the output from trace ? (kgdb) bt #0 0xc01ccb5b in doadump () #1 0xc01cd05e in boot () #2 0xc01cd309 in panic () #3 0xc028aaf2 in initiate_write_inodeblock_ufs1 () #4 0xc028a500 in softdep_disk_io_initiation () #5 0xc019bb79 in spec_strategy () #6 0xc019ae18 in spec_vnoperate () #7 0xc020cdd3 in bwrite () #8 0xc020e270 in vfs_bio_awrite () #9 0xc019b937 in spec_fsync () #10 0xc019ae18 in spec_vnoperate () #11 0xc021ca24 in sched_sync () #12 0xc01b9f25 in fork_exit () Sorry already built a new kernel, so I don't have kernel.debug any longer. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel compile bloat
On Sun, Jan 05, 2003 at 10:14:26PM +1000, Andy Farkas wrote: On a 4.7-stable box, /usr/obj/usr/src/sys totals 34 MB. On a 5.0-current box, /usr/obj/usr/src/sys totals 270 MB! The debugging format (stabs to dwarf2) has also changed from 4.x to 5-CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
Hi Bruce, Thanks for this info. It's way beyond my technical understanding (which is truely minimal!), but I think I get the idea. What would this look like as a series of commands? Or better yet, what's the right way to share data between FreeBSD -current/coming and linux in a dual boot situation? ... Which is the real objective, (not playing with e2fs! ;.-) /Paul Bruce Evans wrote: On Sun, 5 Jan 2003, Paul A. Mayer wrote: I does printf, but it doesn't initiate the e2fsck. Using the ports It prints essentially the same mount failure message as ufs. e2fsck has not shown itself to be the way to do restore order. (I get et hav of ata unaligned access errors and lots of other garbage.) It always worked for me until block devices were axed. Apparently it still depends on random accesses to non-block boundaries and sizes working. It's easier to boot up a Gentoo LiveCD and do it right.) Or upgrade to FreeBSD-3 to get unaxed block devices :-. The ext2fs utilites work on regular files (better than ffs ones), so they can be used (very slowly and with muttering about axes) directly under FreeBSD by copying partitions to regular files, fixing them there, and copying them back. This is least painful for mke2fs since you can start with a sparse file instead of a copy of a partition. [Context lost to top posting] Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic: Initiate_write_inodeblock_ufs1: already started
In message [EMAIL PROTECTED], David O'Brien writes: On Sun, Jan 05, 2003 at 05:01:15PM +0100, [EMAIL PROTECTED] wrote: In message 063601c2b4d0$ff02dc50$471b3dd4@dual, Willem Jan Withagen writes: But now it panics on: Initiate_write_inodeblock_ufs1: already started. When does it panic ? in the boot sequence ? after ? After about 24 hrs for me. Ok, I just found another stupid bug and committed a fix. Can I get you (and others who see this) to upgrade your sources so you have rev 1.351 of kern/vfs_bio.c ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: specfs lock plumbing broken
In message [EMAIL PROTECTED], Bruce Evans writes: No. Also no INVARIANTS and the like. A profiling kernel (with profiling not running) seemed to panic faster. Ok, in this case listening to KASSERTS would probably have helped you. Please try 1.351 of vfs_bio.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
Paul A. Mayer wrote: I had to install the e2fstools port before I could access my e2fs partitions after installing -current. Thereafter everything has been fine. No problems with the disk, etc. Hm, didn't know about this port.. but it still doesn't include a mount program, and I still can't mount the partition even after installing the port. I don't want to fsck it and risk screwing it up: it's a real linux system (ie, a dual-boot machine) and the linux continues to boot perfectly nicely. But here's what I get with an e2fsck -n : # e2fsck -n /dev/ad0s2 e2fsck 1.27 (8-Mar-2002) The filesystem size (according to the superblock) is 714892 blocks The physical size of the device is 0 blocks Either the superblock or the partition table is likely to be corrupt! Abort? no /dev/ad0s2: clean, 136602/357632 files, 456658/714892 blocks So what does that mean? Any way to fix it? The only thing that is a problem is if your e2fs partion(s) are mounted and your system crashes Not a problem for me (it's likely to be mounted read-only anyway, and I can always boot into linux to fix it if it's dirty) - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nVidia opengl works as root but not as user
Im not sure why this would cause it but it's the only thing I can think of that differentiates between root and non-root for gl stuff: In your XF86Config-4, do you have a section which resembles the following? : Section DRI Mode 0666 EndSection If not, try adding it... On Sun, Jan 05, 2003 at 11:38:16AM +0100, David Holm wrote: The thing is that OpenGL apps run perfectly as root, but whenever I use my normal user I can run 1-2 OpenGL apps without any problems but when I run them the next time the machine locks instantly and then reboots, this never happens when I'm running as root. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nVidia opengl works as root but not as user
hi, there! On Sun, Jan 05, 2003 at 12:31:56PM -0500, Jonah Sherman wrote: Im not sure why this would cause it but it's the only thing I can think of that differentiates between root and non-root for gl stuff: In your XF86Config-4, do you have a section which resembles the following? : Section DRI Mode 0666 EndSection If not, try adding it... Seems that nVidia OpenGL does not use DRI and nVidia drivers do not implement it. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
In message [EMAIL PROTECTED], Rahul Siddharthan writes: # e2fsck -n /dev/ad0s2 e2fsck 1.27 (8-Mar-2002) The filesystem size (according to the superblock) is 714892 blocks The physical size of the device is 0 blocks Either the superblock or the partition table is likely to be corrupt! Abort? no /dev/ad0s2: clean, 136602/357632 files, 456658/714892 blocks So what does that mean? Any way to fix it? Can you send us the output of sysctl -b kern.geom.conftxt please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
[EMAIL PROTECTED] wrote: # e2fsck -n /dev/ad0s2 e2fsck 1.27 (8-Mar-2002) The filesystem size (according to the superblock) is 714892 blocks The physical size of the device is 0 blocks Either the superblock or the partition table is likely to be corrupt! Abort? no /dev/ad0s2: clean, 136602/357632 files, 456658/714892 blocks So what does that mean? Any way to fix it? Can you send us the output of sysctl -b kern.geom.conftxt please ? 0 DISK ad0 10056130560 512 hd 16 sc 63 1 MBR ad0s2 2928199680 512 i 1 o 7123092480 ty 131 1 MBR ad0s1 7123060224 512 i 0 o 32256 ty 165 2 BSD ad0s1e 6816876032 512 i 4 o 306184192 2 BSD ad0s1c 7123060224 512 i 2 o 0 2 BSD ad0s1b 201326592 512 i 1 o 104857600 2 BSD ad0s1a 104857600 512 i 0 o 0 - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
In message [EMAIL PROTECTED], Rahul Siddharthan writes: [EMAIL PROTECTED] wrote: # e2fsck -n /dev/ad0s2 e2fsck 1.27 (8-Mar-2002) The filesystem size (according to the superblock) is 714892 blocks The physical size of the device is 0 blocks Either the superblock or the partition table is likely to be corrupt! Abort? no /dev/ad0s2: clean, 136602/357632 files, 456658/714892 blocks So what does that mean? Any way to fix it? Can you send us the output of sysctl -b kern.geom.conftxt please ? 0 DISK ad0 10056130560 512 hd 16 sc 63 1 MBR ad0s2 2928199680 512 i 1 o 7123092480 ty 131 1 MBR ad0s1 7123060224 512 i 0 o 32256 ty 165 2 BSD ad0s1e 6816876032 512 i 4 o 306184192 2 BSD ad0s1c 7123060224 512 i 2 o 0 2 BSD ad0s1b 201326592 512 i 1 o 104857600 2 BSD ad0s1a 104857600 512 i 0 o 0 Hmm, I can't see anything wrong here. I'm not an EXT2 specialist, and I don't really intend to become one, so I hope somebody else can help you out... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unable to mount ext2fs partition
[EMAIL PROTECTED] said on Jan 6, 2003 at 00:14:15: I'm not an EXT2 specialist, and I don't really intend to become one, so I hope somebody else can help you out... As posted earlier, there seems to be funny stuff on my ufs disklabel too: # disklabel -r /dev/ad0s1 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 204800 634.2BSD0 0 0 # (Cyl.0*- 12*) b: 393216 204863 swap# (Cyl. 12*- 37*) c: 13912227 63unused0 0 # (Cyl.0*- 865*) e: 13314211 5980794.2BSD0 0 0 # (Cyl. 37*- 865*) Warning, partition c doesn't start at 0! Warning, partition c doesn't cover the whole unit! Warning, An incorrect partition c may cause problems for standard system utilities Should I worry about that? As for the ext2fs partition: I can probably live with it. But it may bite more people after the -RELEASE Not sure whether this information is relevant, but the ext2 partition was originally a UFS partition. A few months ago I changed it to ext2 with freebsd 4.x's fdisk and then newfs'd with the linux mke2fs binary under linux emulation (FreeBSD 4.x, again). I then wrote a gentoo bootstrap filesystem to it and was able to boot it via grub. It's worked fine since then (I haven't messed with it again under freebsd, and it's mostly been mounted read-only). - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR?
Hi I received a similar problem during booting into single user mode upon startup. I hope the following helps: mounting root from ufs:/dev/ad2s1a start_init: trying /sbin/init VOP_STRATEGY on VCHR :0xc189a00: tag none, type VCHR, usecount 5, write count 0, refcount 6, flags (VV_OBJBUF) backtrace spec_strategy spec_getpages ffs_getpages vnode_pager_getpages exec_map_first_page kern_execve execve start_init fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xcbaaed7c, ebp = 0 --- [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], walt writes: After updating world and kernel this evening I saw this message fly by during the reboot: Mounting root from ufs:/dev/ad0s3a VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? Well, to you it's just noise, to me it's a real problem :-) It is probably the same problem as the one I just commited a fix for. If you get this again after upgrading, please put the DDB option in your kernel and see if you can reproduce it so I get a traceback. The vnode information alone seems not quite as useful as I had hoped. -- Regards Peter As always the organisation disavows knowledge of this email To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Jan 5 15:08:12 PST 2003 -- Kernel build for GENERIC completed on Sun Jan 5 15:43:51 PST 2003 -- Kernel build for LINT started on Sun Jan 5 15:43:51 PST 2003 -- === vinum Makefile, line 4445: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type cc1: warnings being treated as errors /h/des/src/sys/netinet6/ip6_fw.c: In function `check_ip6fw_mbuf': /h/des/src/sys/netinet6/ip6_fw.c:979: warning: int format, different type arg (arg 4) /h/des/src/sys/netinet6/ip6_fw.c: In function `ip6_fw_ctl': /h/des/src/sys/netinet6/ip6_fw.c:1196: warning: int format, different type arg (arg 4) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bzip2recover isn't compiled/installed during build/install world (STABLE CURRENT)
Nuno Teixeira [EMAIL PROTECTED] writes: I noted that bzip2recover isn't installed during build/installworld. I think it may be something related with it makefile. This happens on both STABLE and CURRENT brach. I someone could correct this, I apreciate that. I don't think it's a mistake. It isn't needed or used for the regular system operation, so there's no need for it to be in the base system. If you want it, installing the port is a trivial way of getting it into your system. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bzip2recover isn't compiled/installed during build/install world (STABLE CURRENT)
On Sun, Jan 05, 2003 at 11:38:18AM -0500, Lowell Gilbert wrote: Nuno Teixeira [EMAIL PROTECTED] writes: I noted that bzip2recover isn't installed during build/installworld. I think it may be something related with it makefile. This happens on both STABLE and CURRENT brach. I someone could correct this, I apreciate that. I don't think it's a mistake. It isn't needed or used for the regular system operation, so there's no need for it to be in the base system. If you want it, installing the port is a trivial way of getting it into your system. After a cvsup yesterday I have had the same problem. The problem was that in src/usr.bin/Makefile bzip2recover was listed as subdir, but there was no subdir bzip2recover. After deleting the line with bzip2recover all works fine. Today there is now a subidr bzip2recover. Jan -- [ gpg key: http://nl1.physik.tu-berlin.de/~jan/jschlesn.gpg ] [ key fingerprint: 4236 3497 C4CF 4F3A 274F B6E2 C4F6 B639 1DF4 CF0A ] -- It's better to reign in hell, than to serve in heaven... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On Sat, Jan 04, 2003 at 10:31:45AM -0600, ryan beasley wrote:
Sources are HEAD from Dec 28th, 2002, 04:00 -0600.
DDB session reprinted below. dmesg at the tail.
OK, I found a way to reproduce this one, but given that it only happens
with a 3rd party module, I'm not necessarily sure where the fault lies.
*boot in multiuser (vesa/miibus/if_dc loaded)*
load module
unload module
attempt to execute any process
*panic*
I'm including a GDB capture including traceback and some locking
information. Anyone have any ideas? Is there any other data I should
grab and submit?
(gdb) bt
#0 Debugger (msg=0x12 Address 0x12 out of bounds) at atomic.h:260
#1 0xc019a03b in panic (fmt=0x0)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/kern_shutdown.c:503
#2 0xc01bbfff in witness_lock (lock=0xc0301160, flags=8,
file=0xc02ea34e /usr/src/sys/vm/vm_fault.c, line=206)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:508
#3 0xc0190441 in _mtx_lock_flags (m=0xc0300fc0, opts=0,
file=0xc0301160 À\0170ÀJ¿-ÀJ¿-À, line=206)
at /usr/src/sys/kern/kern_mutex.c:328
#4 0xc0271789 in vm_fault (map=0xc082f000, vaddr=3245330432,
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:206
#5 0xc02b6ac1 in trap_pfault (frame=0xca3e27b8, usermode=0, eva=3245332734)
at /usr/src/sys/i386/i386/trap.c:746
#6 0xc02b669d in trap (frame=
{tf_fs = 24, tf_es = -1070268400, tf_ds = -1070596080, tf_edi =
-1070713064, tf_esi = -1070592064, tf_ebp = -901896196, tf_isp = -901896220,
tf_ebx = -1070400984, tf_edx = -1070713064, tf_ecx = -1049634562, tf_eax =
-1049634562, tf_trapno = 12, tf_err = 0, tf_eip = -1071664406, tf_cs = 8,
tf_eflags = 66050, tf_esp = -1070400984, tf_ss = -901896160}) at
/usr/src/sys/i386/i386/trap.c:445
#7 0xc02a7158 in calltrap () at {standard input}:98
#8 0xc01bce28 in enroll (description=0xc02e3718 vnode interlock,
lock_class=0xc0300fc0)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:985
#9 0xc01bbcb5 in witness_init (lock=0xc032fa28)
---Type return to continue, or q return to quit---
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:388
#10 0xc0190eb1 in mtx_init (m=0xc02e3718, name=0xc02e3718 vnode interlock,
type=0x0, opts=0) at /usr/src/sys/kern/kern_mutex.c:940
#11 0xc01ebe6f in getnewvnode (tag=0xc02e56e9 ufs, mp=0x12, vops=0x12,
vpp=0x12) at /usr/src/sys/kern/vfs_subr.c:1000
#12 0xc025fc6b in ffs_vget (mp=0xc09fdc00, ino=481954, flags=2, vpp=0xca3e2984)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1254
#13 0xc026706b in ufs_lookup (ap=0xca3e2ab8)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:601
#14 0xc026d5f8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
#15 0xc01e2bac in vfs_cache_lookup (ap=0x12) at vnode_if.h:82
#16 0xc026d5f8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
#17 0xc01e7172 in lookup (ndp=0xca3e2c24) at vnode_if.h:52
#18 0xc01e6b6e in namei (ndp=0xca3e2c24) at /usr/src/sys/kern/vfs_lookup.c:181
#19 0xc01f4152 in stat (td=0xc1266000, uap=0xca3e2d10)
at /usr/src/sys/kern/vfs_syscalls.c:1654
#20 0xc02b714e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135567080, tf_esi =
135655208, tf_ebp = -1077937688, tf_isp = -901894796, tf_ebx = 135567080, tf_edx
= 135564138, tf_ecx = 135655219, tf_eax = 188, tf_trapno = 12, tf_err = 2,
tf_eip = 134954771, tf_cs = 31, tf_eflags = 662, tf_esp = -1077937812, tf_ss =
47})
at /usr/src/sys/i386/i386/trap.c:1033
(gdb)
#2 0xc01bbfff in witness_lock (lock=0xc0301160, flags=8,
file=0xc02ea34e /usr/src/sys/vm/vm_fault.c, line=206)
at /usr/src/sys/kern/subr_witness.c:508
translating /usr/src/sys/kern/subr_witness.c -
/home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c
508 panic(blockable sleep lock (%s) %s @ %s:%d (td
%p),
(gdb) p td
$1 = (struct thread *) 0xc1266000
(gdb) p *lock
$2 = {lo_class = 0xc0300fc0, lo_name = 0xc02dbf4a Giant,
lo_type = 0xc02dbf4a Giant, lo_flags = 0xb, lo_list = {
tqe_next = 0xc0301120, tqe_prev = 0xc03041f0}, lo_witness = 0xc0330f18}
(gdb) p *td-td_sleeplocks
$3 = {ll_next = 0x0, ll_children = {{li_lock = 0xc0301160,
li_file = 0xc02efb57 /usr/src/sys/i386/i386/trap.c, li_line = 1025,
li_flags = 131072}, {li_lock = 0xc122a0d8,
li_file = 0xc02ec088 /usr/src/sys/vm/uma_core.c, li_line = 1335,
li_flags = 131072}, {li_lock = 0xc122a024,
li_file = 0xc02ec088 /usr/src/sys/vm/uma_core.c, li_line = 1352,
li_flags = 131072}}, ll_count = 1}
(gdb) p *td-td_sleeplocks.ll_children[0].li_lock
$4 = {lo_class = 0xc0300fc0, lo_name = 0xc02dbf4a Giant,
lo_type = 0xc02dbf4a Giant, lo_flags = 0xb, lo_list = {
tqe_next = 0xc0301120, tqe_prev = 0xc03041f0}, lo_witness = 0xc0330f18}
(gdb) p *td-td_sleeplocks.ll_children[1].li_lock
$5 = {lo_class = 0xc0300fc0, lo_name = 0xc122a000 PCPU VNODE,
lo_type = 0xc02ec1e8 UMA cpu, lo_flags = 0x43, lo_list = {
tqe_next = 0xc122a144,
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On Sun, Jan 05, 2003 at 08:54:01PM -0600, ryan beasley wrote:
I'm including a GDB capture including traceback and some locking
information. Anyone have any ideas? Is there any other data I should
grab and submit?
I'm really sorry for following up to myself again, but the following
might be useful:
(gdb)
#8 0xc01bce28 in enroll (description=0xc02e3718 vnode interlock,
lock_class=0xc0300fc0)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:985
985 if (w-w_name == description || (w-w_refcount 0
Current language: auto; currently c
(gdb) p *w
$16 = {w_name = 0xc16fd8fe Address 0xc16fd8fe out of bounds,
w_class = 0xc0300fc0, w_list = {stqe_next = 0xc032fa50}, w_typelist = {
stqe_next = 0xc032fa50}, w_children = 0x0, w_file = 0x0, w_line = 0,
w_level = 0, w_refcount = 2, w_Giant_squawked = 0 '\0',
w_other_squawked = 0 '\0', w_same_squawked = 0 '\0'}
This is the instruction where the page fault occurred. As to how w_name
was clobbered, I have no idea.
--
ryan beasley[EMAIL PROTECTED]
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg49751/pgp0.pgp
Description: PGP signature
unsubscribe
auth 72159d4c unsubscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR?
That one should already be fixed. In message [EMAIL PROTECTED], Peter Kostouros writes: Hi I received a similar problem during booting into single user mode upon startup. I hope the following helps: mounting root from ufs:/dev/ad2s1a start_init: trying /sbin/init VOP_STRATEGY on VCHR :0xc189a00: tag none, type VCHR, usecount 5, write count 0, refcount 6, flags (VV_OBJBUF) backtrace spec_strategy spec_getpages ffs_getpages vnode_pager_getpages exec_map_first_page kern_execve execve start_init fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xcbaaed7c, ebp = 0 --- [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], walt writes: After updating world and kernel this evening I saw this message fly by during the reboot: Mounting root from ufs:/dev/ad0s3a VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? Well, to you it's just noise, to me it's a real problem :-) It is probably the same problem as the one I just commited a fix for. If you get this again after upgrading, please put the DDB option in your kernel and see if you can reproduce it so I get a traceback. The vnode information alone seems not quite as useful as I had hoped. -- Regards Peter As always the organisation disavows knowledge of this email To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
usb hid device timeout
I have a CD Tower device (a USB HID device) which always failed to be identified
under CURRENT source without following patch, it is always timeout, could anyone
look the following patch:
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.52
diff -u -u -r1.52 usb_subr.c
--- usb_subr.c 17 Jun 2002 20:52:26 - 1.52
+++ usb_subr.c 6 Jan 2003 07:48:51 -
@@ -1106,9 +1106,15 @@
usbd_reload_device_desc(usbd_device_handle dev)
{
usbd_status err;
-
+ int i;
+
/* Get the full device descriptor. */
- err = usbd_get_device_desc(dev, dev-ddesc);
+ for (i = 0; i 3; ++i) {
+ err = usbd_get_device_desc(dev, dev-ddesc);
+ if (!err)
+ break;
+ usbd_delay_ms(dev, 200);
+ }
if (err)
return (err);
--
After patched, I can use usbhidctl to dump some informaton:
Report descriptor:
Collection page=0xffa0 usage=0x0001
Collection page=0xffa0 usage=0x0002
Input size=8 count=1 page=0xffa1 usage=0x0003, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Input size=8 count=1 page=0xffa1 usage=0x0004, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0005, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
Output size=8 count=1 page=0xffa1 usage=0x0006, logical range -128..127, physical
range 0..-1
End collection
End collection
Total input size 8 bytes
Total output size 8 bytes
Total feature size 0 bytes
N
'²æìr¸zǧvf¢Új:+v¨· è® ¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
