Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
On Thu, Feb 20, 2003 at 02:28:45PM -0800, Darryl Okahata [EMAIL PROTECTED] wrote: Vallo Kallaste [EMAIL PROTECTED] wrote: I'll second Brad's statement about vinum and softupdates interactions. My last experiments with vinum were more than half a year ago, but I guess it still holds. BTW, the interactions showed up _only_ on R5 volumes. I had 6 disk (SCSI) R5 volume in Compaq Proliant 3000 and the system was very stable before I enabled softupdates.. and of course after I disabled softupdates. In between there were crashes and nasty problems with filesystem. Unfortunately it was production system and I hadn't chanche to play. Did you believe that the crashes were caused by enabling softupdates on an R5 vinum volume, or were the crashes unrelated to vinum/softupdates? I can see how crashes unrelated to vinum/softupdates might trash vinum filesystems. The crashes and anomalies with filesystem residing on R5 volume were related to vinum(R5)/softupdates combo. The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IPFILTER Problems [branch from: Ethernet (xl) will not transmit or receive]
Due to the fact that when I install a fresh box (straight from CD [release versions]) the machine works fine, Im thinking it has to do with some possible changes to the code for IPFILTER. It only happens when I grab the setup data from the ftp servers. My problem, however, seemed to disappear when I ripped IPFILTER out of the kernel conf and rebuilt everything. Im not using an xl card in the latest machine I have, it's using fxp (dual Intel Pro 10/100+'s) and it occured there also. IPFILTER on the RELEASE version from CD worked fine, but after a cvsup all hell broke lose on the system again. Were there any changes to the IPFILTER code since 5.0-RELEASE was set in ISO? Is anyone else having this problem on any of their machines? I have tried a couple of interface setups (one being DHCP, the other being manually set) and it produces the same results using both methods. I'll compare the IPFILTER from the -RELEASE cd to the IPFILTER currently on the CVS servers. If I find anything, I'll be sure to send it here first ;) Regards, Nick H. - Original Message - From: Kevin Oberman [EMAIL PROTECTED] To: Tilman Linneweh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 20, 2003 3:54 PM Subject: Re: Ethernet (xl) will not transmit or receive : Date: Thu, 20 Feb 2003 22:41:11 +0100 : From: Tilman Linneweh [EMAIL PROTECTED] : : Check out the Errata : http://www.freebsd.org/releases/5.0R/errata.html There is an item : for the xl0 driver, although your problem looks different then mine. : : Not the problem. First, the interface was working fine with : 5.0-Release. The problem occurred after updating to : RELENG_5_0. Second, I just have a broken xl0, no panics. : : Thanks. : : R. Kevin Oberman, Network Engineer : Energy Sciences Network (ESnet) : Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) : E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 : : 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: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
Vallo Kallaste wrote: The crashes and anomalies with filesystem residing on R5 volume were related to vinum(R5)/softupdates combo. The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. I think this is an expected problem with a lot of concatenation, whether through Vinum, GEOM, RAIDFrame, or whatever. This comes about for the same reason that you can't mount -u to turn Soft Updates from off to on: Soft Updates does not tolerate dirty buffers for which a dependency does not exist, and will crap out when a pending dirty buffer causes a write. This could be fixed in the mount -u case for Soft Updates, and it can also be fixed for Vinum (et. al.). The key is the difference between a mount -u vs. a umount ; mount, which comes down to flushing and invalidating all buffers on the underlying device, e.g.: vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p); vinvalbuf(devvp, V_SAVE, NOCRED, p, 0, 0); error = VOP_CLOSE(devvp, ronly ? FREAD : FREAD|FWRITE, FSCRED, p); error = VOP_OPEN(devvp, ronly ? FREAD : FREAD|FWRITE, FSCRED, p); VOP_UNLOCK(devvp, 0, p); ... Basically, after rebuilding, before allowing the mount to proceed, the Vinum (and GEOM and RAIDFRame, etc.) code needs to cause all the pending dirty buffers to be written. This will guarantee that there are no outstanding dirty buffers at mount time, which in turn guarantees that there will be no dirty buffers that the dependency tracking in Soft Updates does not know about. FWIW: I've maintained for over 6 years now that the mount update code should be modified to do this automatically (and provided patches; see early 1997 mailing list archives), essentially turning a mount -u into a umount ; mount, without invalidating outstanding vnodes and in-core inodes or their references (so that open files do not break... they just get all their buffers taken away from them). Of course, the only open files that matter for device layering are the device exporting the layered block store, and the underlying component block stores that make it up (i.e. no open files there). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/share/man/man4 Makefile
On Sat, Feb 15, 2003 at 02:28:34PM -0800, Tom Rhodes wrote: trhodes 2003/02/15 14:28:34 PST Modified files: share/man/man4 Makefile Log: Link several of the if_* modules to their respected manual pages. Revision ChangesPath 1.190 +40 -0 src/share/man/man4/Makefile Hmm, if we really want this, mdoc(7) rules say that we should also add if_*'s to the NAME sections of all affected manpages, e.g.: %%% Index: an.4 === RCS file: /home/ncvs/src/share/man/man4/an.4,v retrieving revision 1.15 diff -u -r1.15 an.4 --- an.415 Feb 2003 17:12:53 - 1.15 +++ an.421 Feb 2003 11:52:33 - @@ -34,7 +34,7 @@ .Dt AN 4 .Os .Sh NAME -.Nm an +.Nm an , if_an .Nd Aironet Communications 4500/4800 wireless network adapter driver .Sh SYNOPSIS .Cd device an %%% But my personal opinion on this change is that it is unnecessary. The if_* convention on calling network interface modules is an internal implementation detail, and only to allow ifconfig(8) to automatically load driver modules. Any other opinions? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg52799/pgp0.pgp Description: PGP signature
Question about KLDs...
All, This may be a fairly elementary question, but I have not seen this addressed in the Handbook at all -- Which is the preferred method for using drivers: KLDs or compiling into the kernel? Are there some that work better one way than the other? Inquiring minds would like to know! :-) Thanks! -- Paul A. Howes To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reproducable ACPI hang on 5.0-RELEASE + Asus A7V mobo
The Anarcat (Mon, Feb 17, 2003 at 08:09:05PM -0500) wrote: On Tue Feb 18, 2003 at 12:19:35AM +, Bruce Cran wrote: ACPI power management on Asus motherboards with the VIA chipset seems to be quite broken. On my A7V333 I can use mode 1 (CPU off), 2 and 3 report AE_NOT_FOUND and 4 dumps the cpu registers, while power-off on shutdown reports an ACPI timeout error. I can power-off on shutdown (halt -p acpiconf -s 5, if I understand this correctly). mode 1 doesn't seem to do anything, but that might just be because I can't notice the CPU stopped. 3 actually halts the drives and the fans, but powering evrything back up gives me a nice freeze. 4 just hangs. I don't think the S4 (-s4) state is supported, but I may be wrong. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: tcp related?
Hi
With yesterday's current I get repeating panics while having increased
tcp traffic. I don't know if this is really tcp related.
A backtrace is attached. I'll supply more info if needed.
bye
--
Tobias Reifenberger -- [EMAIL PROTECTED] -- DG1NGT
GEE e* dpu s:- a-- C+++ UB+++ L- W+ N+ w--- Y+ tv+ b++ D++ h++ r---
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc73cec78 not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x15259
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01a47c0
stack pointer = 0x10:0xccdb7cb4
frame pointer = 0x10:0xccdb7cc0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi6: tty:sio clock)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bremfree: bp 0xc73cec78 not locked
Uptime: 16m6s
Dumping 247 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc01ac369 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc01ac598 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc01e3629 in bremfreel (bp=0xc73cec78) at ../../../kern/vfs_bio.c:672
#4 0xc01e35b1 in bremfree (bp=0xc73cec78) at ../../../kern/vfs_bio.c:659
#5 0xc01e52ae in vfs_bio_awrite (bp=0xc73cec78) at ../../../kern/vfs_bio.c:1714
#6 0xc02706d1 in ffs_fsync (ap=0xccdb7b38) at ../../../ufs/ffs/ffs_vnops.c:257
#7 0xc026fafc in ffs_sync (mp=0xc25bec00, waitfor=2, cred=0xc0e80e80, td=0xc031a320)
at vnode_if.h:612
#8 0xc01f5756 in sync (td=0xc031a320, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#9 0xc01abfc5 in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#10 0xc01ac598 in panic () at ../../../kern/kern_shutdown.c:542
#11 0xc02bf7b8 in trap_fatal (frame=0xccdb7c74, eva=86617) at
../../../i386/i386/trap.c:844
#12 0xc02bf4eb in trap_pfault (frame=0xccdb7c74, usermode=0, eva=86617) at
../../../i386/i386/trap.c:758
#13 0xc02bf0e1 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1070636219, tf_esi = 222, tf_ebp
= -858030912, tf_isp = -858030944, tf_ebx = 86617, tf_edx = 16, tf_ecx = 215, tf_eax =
-1058465200, tf_trapno = 12, tf_err = 0, tf_eip = -1072019520, tf_cs = 8, tf_eflags =
66182, tf_esp = -1028071744, tf_ss = 86441}) at ../../../i386/i386/trap.c:445
#14 0xc02b1008 in calltrap () at {standard input}:96
#15 0xc022250a in tcp_timer_2msl (xtp=0xc2b8dec0) at ../../../netinet/tcp_timer.c:222
#16 0xc01b8012 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#17 0xc019d616 in ithread_loop (arg=0xc0e8f200) at ../../../kern/kern_intr.c:536
#18 0xc019ca2f in fork_exit (callout=0xc019d4f0 ithread_loop, arg=0xc0e8f200,
frame=0xccdb7d48)
at ../../../kern/kern_fork.c:871
Re: cvs commit: src/share/man/man4 Makefile
On Fri, 21 Feb 2003, Ruslan Ermilov wrote: On Sat, Feb 15, 2003 at 02:28:34PM -0800, Tom Rhodes wrote: trhodes 2003/02/15 14:28:34 PST Modified files: share/man/man4 Makefile Log: Link several of the if_* modules to their respected manual pages. Revision ChangesPath 1.190 +40 -0 src/share/man/man4/Makefile Hmm, if we really want this, mdoc(7) rules say that we should also add if_*'s to the NAME sections of all affected manpages, e.g.: --snip patch-- But my personal opinion on this change is that it is unnecessary. The if_* convention on calling network interface modules is an internal implementation detail, and only to allow ifconfig(8) to automatically load driver modules. Any other opinions? Well for those who know the convention its fine to leave as is, but I could see how it might be useful for someone new to FreeBSD to be able to do a 'whatis' on the modules: # whatis ciss ciss(4) ... # whatis aio aio(4) ... aio_waitcomplete(2) ... # whatis if_kue if_kue: nothing appropriate # apropos if_kue if_kue: nothing appropriate # whatis exca exca: nothing appropriate There are some non-if_* modules in there now that seem to be only documented in /usr/src, exca is a good example. -James To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
telnet(1) strange behaviour
telnet(1) is behaving rather strangely when dealing with escape sequences. Please try 'telnet bbs.cis.nctu.edu.tw' and type guest, it will appear as uest only. telnet(1) on -stable does not exhibit such behaviour. ssh(1) is also immune. The problem could be in libtelnet since zh-telnet port is also affected. Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: config files and includes.
Julian Elischer [EMAIL PROTECTED] writes: I have just gone through the process of upgrading or installing several hundred machines, and Thst includes altering or editing many config files in /etc. I like the way that rc.conf is handled, in that defaults/rc.comf can be updated and only the local changes live in r.conf. I wish that more files had this capability. For example syslogd.conf or newsyslog.conf are updated between releases but they are also prime candidates for local additions. What would be really cool is if more config files could do 'includes' so that you could have a syslogd.local.conf wher eall your local entries could be. In addition you could make it look in /usr/local/etc/syslogd.conf for loging requirments for packages. Why not making it simple on yourself and use CPP. /etc/defaults/syslog.global.conf: #ifndef SECURITY security.* /nfs/log/security #endif #ifndef MAIL mail.info /nfs/log/maillog #endif /etc/syslog.local.conf: #define SECURITY security.* /var/log/security #include /etc/defaults/syslog.global.conf /etc/rc.d/syslogd (or similar): +# Preprocess syslog.conf +cpp /etc/syslog.local.conf -o /etc/syslog.conf + Unix has *so* many text processing tools, I don't see why we need to bloat daemons with this stuff. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet (xl) will not transmit or receive
Date: Thu, 20 Feb 2003 08:19:05 -0800 From: Kevin Oberman [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I updated my 5.0 system built in late January to RELENG_5_0 on Sunday and the Ethernet was not working. I tried again last night with no change in behavior. The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B Ethernet which had been working fine on a kernel built in late January. The dmesg is not too meaningful, but the system shows no errors. It simply never receives a packet. ARPs are all incomplete and no packets are transmitted although netstat -in indicates that they are. The packets never actually reach the wire, though. I can't believe that no one else has this card, but I didn't find anything in the archives on it. Any idea what needs to be rolled back and how far? I'm suspicious that it might be an mii problem. Maybe even an interrupt issue. I an suspicious of the second, empty xlphy0: line in the dmesg, but the reported MAC is right and my old kernel that works seems to generate a similar empty line. To follow up with more information: Several folks suggested ifconfiging the interface down and up (or down and up with media and mediaopt specified). This did not help at all. ifconfig shows the interface as up but in hardware loopback at 100BaseTX. I see no link on the line and the status line in the ifconfig output is blank. I tried to force it to 10BaseT/UTP and half-duplex, but this did not work. When the system boots I see link until the device probes. After about 1-2 seconds, link is restored. This is identical to what I see with the January kernel. Then, when the network is started, the link goes out and stays out. I have not had time to try instrumenting the network startup to see exactly which command does this, but may get a chance this weekend. The system in question is at home and it's a bit hard to deal with remotely since I lose connectivity if the system boots the new V5 kernel. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Ethernet (xl) will not transmit or receive
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Oberman Sent: Friday, February 21, 2003 7:27 AM Cc: [EMAIL PROTECTED] Subject: Re: Ethernet (xl) will not transmit or receive Date: Thu, 20 Feb 2003 08:19:05 -0800 From: Kevin Oberman [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I updated my 5.0 system built in late January to RELENG_5_0 on Sunday and the Ethernet was not working. I tried again last night with no change in behavior. The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B Ethernet which had been working fine on a kernel built in late January. The dmesg is not too meaningful, but the system shows no errors. It simply never receives a packet. ARPs are all incomplete and no packets are transmitted although netstat -in indicates that they are. The packets never actually reach the wire, though. I can't believe that no one else has this card, but I didn't find anything in the archives on it. Any idea what needs to be rolled back and how far? I'm suspicious that it might be an mii problem. Maybe even an interrupt issue. I an suspicious of the second, empty xlphy0: line in the dmesg, but the reported MAC is right and my old kernel that works seems to generate a similar empty line. To follow up with more information: Several folks suggested ifconfiging the interface down and up (or down and up with media and mediaopt specified). This did not help at all. ifconfig shows the interface as up but in hardware loopback at 100BaseTX. I see no link on the line and the status line in the ifconfig output is blank. I tried to force it to 10BaseT/UTP and half-duplex, but this did not work. When the system boots I see link until the device probes. After about 1-2 seconds, link is restored. This is identical to what I see with the January kernel. Then, when the network is started, the link goes out and stays out. I have not had time to try instrumenting the network startup to see exactly which command does this, but may get a chance this weekend. The system in question is at home and it's a bit hard to deal with remotely since I lose connectivity if the system boots the new V5 kernel. Do you have PNP os on in your bios? I had the same problem with one those cards several months ago and turning off PNP solved it. Beech --- Beech Rintoul - Network Administrator - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | NorthWind Communications \ / - NO HTML/RTF in e-mail | X - NO Word docs in e-mail | Anchorage, AK 99518-1841 No More Spam! http://www.knockmail.com/default.asp?AID=B0R00073 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Witness This
Ok, a couple of witness complains, first about the sound driver, I
think, and the second something macish. Then a backtrace for a mac_mls
panic. All this for your weekend entertainment. :-)
First, witness cmi:
backtrace(c032e7d9,c25af500,c25a98d4,c046236e,c04623ec) at backtrace+0x17
witness_lock(c25af500,8,c04623ec,1b8,c) at witness_lock+0x660
_mtx_lock_flags(c25af500,0,c04623ec,1b8,8095) at _mtx_lock_flags+0xb1
chn_intr(c25a9880,c,1,208,c25af7c0) at chn_intr+0x2f
cmi_intr(c25a9800,0,c0329618,217,c25ae9ec) at cmi_intr+0xa6
ithread_loop(c25a9000,cd2ced48,c032948d,366,55ff44fd) at ithread_loop+0x182
fork_exit(c01cd420,c25a9000,cd2ced48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xcd2ced7c, ebp = 0 ---
Now, witness biba:
backtrace(c032e7d9,c0831110,c03395bc,c03395bc,c0339453) at backtrace+0x17
witness_lock(c0831110,8,c0339453,145,d1d726dc) at witness_lock+0x660
_mtx_lock_flags(c0831110,0,c0339453,145,d1d72704) at _mtx_lock_flags+0xb1
_vm_map_lock(c08310b0,c0339453,145,d1d72708,c038a058) at _vm_map_lock+0x36
kmem_malloc(c08310b0,1000,5,d1d72770,c02bda1d) at kmem_malloc+0x65
page_alloc(c083c240,1000,d1d72763,5,c0389e00) at page_alloc+0x27
slab_zalloc(c083c240,5,c033ae28,667,c083cda4) at slab_zalloc+0xfd
uma_zone_slab(c083c240,5,c033ae28,667,0) at uma_zone_slab+0xd8
uma_zalloc_internal(c083c240,0,5,6e7,0) at uma_zalloc_internal+0x55
uma_zfree_arg(c083cd80,c2bc0900,c2bc0fc8,116,80) at uma_zfree_arg+0x2c9
free(c2bc0900,c0364b80,d1d72838,c027620d,c2bc0900) at free+0xde
biba_free(c2bc0900,c0364e60,d1d72858,c01d6baf,c2c1621c) at biba_free+0x1d
mac_biba_destroy_label(c2c1621c,0,c032a35b,3eb,0) at
mac_biba_destroy_label+0x1d
mac_destroy_vnode_label(c2c1621c,d1d728bc,c0240373,c2c1611c,0) at
mac_destroy_vn
ode_label+0x7f
mac_destroy_vnode(c2c1611c,0,c03329d0,3bd,15d) at mac_destroy_vnode+0x16
getnewvnode(c0334a68,c25f9800,c2607700,d1d7290c,6) at getnewvnode+0x393
ffs_vget(c25f9800,19273,2,d1d72984,d1d72988) at ffs_vget+0x9b
ufs_lookup(d1d72ab8,d1d72af4,c0236d7c,d1d72ab8,d1d72c38) at ufs_lookup+0xdfb
ufs_vnoperate(d1d72ab8,d1d72c38,d1d72c4c,c01f3b04,c26095a0) at
ufs_vnoperate+0x1
8
vfs_cache_lookup(d1d72b68,d1d72b94,c023b6d9,d1d72b68,c2c40e6c) at
vfs_cache_look
up+0x2fc
ufs_vnoperate(d1d72b68,c2c40e6c,d1d72c4c,0,c26095a0) at ufs_vnoperate+0x18
lookup(d1d72c24,0,c0332347,a4,c26095a0) at lookup+0x329
namei(d1d72c24,0,d1d72c24,c0390440,0) at namei+0x24e
lstat(c26095a0,d1d72d10,c033e8c9,407,2) at lstat+0x52
syscall(806002f,806002f,bfbf002f,8072b00,8072b48) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (190), eip = 0x280b8ea3, esp = 0xbfbffb0c, ebp = 0xbfbffba8 ---
Finally, trace this:
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
No locals.
#1 0xc0128945 in db_fncall (dummy1=0, dummy2=0, dummy3=1999,
dummy4=0xcd2a7750 \200'7À\bÚ6Àlw*Í\r)
at /usr/src/sys/ddb/db_command.c:546
fn_addr = -1071732400
args = {0 repeats 11 times}
nargs = 11
retval = 0
func = (fcn_10args_t *) 0xc01ea950 doadump
t = 0
#2 0xc01286c2 in db_command (last_cmdp=0xc0346ae0, cmd_table=0x0,
aux_cmd_tablep=0xc0341084, aux_cmd_tablep_end=0xc0341088)
at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc0346a70
t = 0
modif = \200'7À\bÚ6Àlw*Í\r\0\0\0`\006À\r\0\0\0\001\0\0\0\214w*ͦU-Ààì:
À\aK\0
à\006À\200Ë:À\200'7Àx\0\0\0\200'7À\bÚ6À°w*Íá£\022ÀGò1ÀТ\022À\0\0\0\0\02
0\0\0\0\bÚ6À\200'7ÀN\234\022À\200'7À`\0377Àx\0\0\0\003\0\0
addr = 0
count = 1999
have_addr = 0
result = 0
#3 0xc01287d6 in db_command_loop () at /usr/src/sys/ddb/db_command.c:470
No locals.
#4 0xc012b56a in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
bkpt = 0
#5 0xc02dec22 in kdb_trap (type=3, code=0, regs=0xcd2a78a4)
at /usr/src/sys/i386/i386/db_interface.c:166
ddb_mode = 1
#6 0xc02f060f in trap (frame=
{tf_fs = 24, tf_es = -1070006256, tf_ds = -852885488, tf_edi =
-1058227632
, tf_esi = 256, tf_ebp = -852854544, tf_isp = -852854576, tf_ebx = 0,
tf_edx = 0
, tf_ecx = 1920, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip =
-1070731580, t
f_cs = 8, tf_eflags = 646, tf_esp = -1070350146, tf_ss = -1070421591})
at /usr/src/sys/i386/i386/trap.c:603
td = (struct thread *) 0xc0ecba50
p = (struct proc *) 0xc0eca9ec
sticks = 0
i = 0
ucode = 0
type = 3
code = 0
eva = 0
#7 0xc02e0578 in calltrap () at {standard input}:96
No locals.
#8 0xc01eb0bb in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
td = (struct thread *) 0xc0ecba50
bootopt = 256
newpanic = 1
buf = mac_mls_single_in_range: a not single, '\0' repeats 218 times
#9 0xc0277274 in mac_mls_single_in_range (single=0x0, range=0xc2605e80)
at /usr/src/sys/security/mac_mls/mac_mls.c:225
No locals.
#10 0xc0278cb6 in mac_mls_check_ifnet_transmit (ifnet=0xc25ebc00,
ifnetlabel=0x0, m=0xc0eda000, mbuflabel=0x0)
at /usr/src/sys/security/mac_mls/mac_mls.c:1462
p = (struct mac_mls *) 0x0
i = (struct mac_mls *) 0x0
#11 0xc01dad7a in
Re: Ethernet (xl) will not transmit or receive
On Thu, 20 Feb 2003, Kevin Oberman wrote: I updated my 5.0 system built in late January to RELENG_5_0 on Sunday and the Ethernet was not working. I tried again last night with no change in behavior. The system is an AMD K6-2 on an ASUS P5A mobo. I have a 3Com 3c905B Ethernet which had been working fine on a kernel built in late January. The dmesg is not too meaningful, but the system shows no errors. It simply never receives a packet. ARPs are all incomplete and no packets are transmitted although netstat -in indicates that they are. The packets never actually reach the wire, though. I had an almost similar behavior but had watchdog timeouts. see http://www.freebsd.org/cgi/query-pr.cgi?pr=47441 Any idea what needs to be rolled back and how far? I'm suspicious that it might be an mii problem. Maybe even an interrupt issue. I an suspicious of the second, empty xlphy0: line in the dmesg, but the reported MAC is right and my old kernel that works seems to generate a similar empty line. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/share/man/man4 Makefile
On Fri, 21 Feb 2003 14:01:32 +0200 Ruslan Ermilov [EMAIL PROTECTED] wrote: But my personal opinion on this change is that it is unnecessary. There is a right way, and a wrong way. To be honest, the `right' way here is alot of extra work, and I don't think that most users will really care about listing them. The if_* convention on calling network interface modules is an internal implementation detail, and only to allow ifconfig(8) to automatically load driver modules. Any other opinions? See above :) -- Tom Rhodes To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
today's 5-current hang hard when building apache2 port
I cvsup today and build/install world kernel. The machine was working fine until I tried to build apache2 port. When configuring apache2, my PC hanged at the following line and need hard reset (i.e. cannot break into debugger and need pressing reset button). checking if TCP_NODELAY setting is inherited from listening sockets... I traced the conftest program under gdb and received the following error on the rc = connect(client_s, (struct sockaddr *)sa, sizeof sa) call. Program received signal SIGSEGV, Segmentation fault. 0x280fdaf0 in _longjmp () from /usr/lib/libc.so.5 Anyone has the same problem or idea what's happening? Attached are the confdefs.h and conftest.c extracted from srclib/apr/configure that gave the above problem. P.S. When building the apache2 port, I had CPUTYPE=p3 in make.conf and used make configure WITH_THREADS=yes __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ #define PACKAGE_NAME #define PACKAGE_TARNAME #define PACKAGE_VERSION #define PACKAGE_STRING #define PACKAGE_BUGREPORT #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define HAVE_DLFCN_H 1 #define HAVE_LIBM 1 #define HAVE_PTHREAD_H 1 #define USE_THREADS 1 #define HAVE_PTHREAD_KEY_DELETE 1 #define HAVE_PTHREAD_RWLOCK_INIT 1 #define READDIR_IS_THREAD_SAFE 1 #define GETHOSTBYNAME_IS_THREAD_SAFE 1 #define GETHOSTBYADDR_IS_THREAD_SAFE 1 #define HAVE_GETHOSTBYADDR_R 1 #define HAVE_SIGSUSPEND 1 #define HAVE_SIGWAIT 1 #define HAVE_POLL 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_IPC_H 1 #define HAVE_SYS_SHM_H 1 #define HAVE_SYS_FILE_H 1 #define HAVE_MMAP 1 #define HAVE_MUNMAP 1 #define HAVE_SHM_OPEN 1 #define HAVE_SHM_UNLINK 1 #define HAVE_SHMGET 1 #define HAVE_SHMAT 1 #define HAVE_SHMDT 1 #define HAVE_SHMCTL 1 #define HAVE_MAP_ANON 1 #define anonymous shared memory allocation method 1 #define USE_SHMEM_MMAP_ANON 1 #define namebased memory allocation method 1 #define USE_SHMEM_SHMGET 1 #define HAVE_ALLOCA 1 #define HAVE_CALLOC 1 #define HAVE_STRCASECMP 1 #define HAVE_SETSID 1 #define HAVE_ISINF 1 #define HAVE_ISNAN 1 #define HAVE_SETRLIMIT 1 #define HAVE_GETRLIMIT 1 #define HAVE_WRITEV 1 #define HAVE_SENDFILE 1 #define HAVE_SIGACTION 1 #define SYS_SIGLIST_DECLARED 1 #define HAVE_FORK 1 #define HAVE_STRERROR_R 1 #define STRERROR_R_RC_INT 1 #define HAVE_MMAP 1 #define HAVE_MEMMOVE 1 #define HAVE_GETPASS 1 #define HAVE_GMTIME_R 1 #define HAVE_LOCALTIME_R 1 #define HAVE_HSTRERROR 1 #define HAVE_MKSTEMP 1 #define DIRENT_INODE d_fileno #define DIRENT_TYPE d_type #define STDC_HEADERS 1 #define HAVE_CTYPE_H 1 #define HAVE_DIRENT_H 1 #define HAVE_DLFCN_H 1 #define HAVE_ERRNO_H 1 #define HAVE_FCNTL_H 1 #define HAVE_GRP_H 1 #define HAVE_LIMITS_H 1 #define HAVE_MEMORY_H 1 #define HAVE_NETDB_H 1 #define HAVE_OSRELDATE_H 1 #define HAVE_POLL_H 1 #define HAVE_PWD_H 1 #define HAVE_SEMAPHORE_H 1 #define HAVE_SIGNAL_H 1 #define HAVE_STDARG_H 1 #define HAVE_STDDEF_H 1 #define HAVE_STDIO_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_STRINGS_H 1 #define HAVE_TERMIOS_H 1 #define HAVE_TIME_H 1 #define HAVE_UNISTD_H 1 #define HAVE_ARPA_INET_H 1 #define HAVE_NETINET_IN_H 1 #define HAVE_SYS_FILE_H 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_POLL_H 1 #define HAVE_SYS_RESOURCE_H 1 #define HAVE_SYS_SELECT_H 1 #define HAVE_SYS_SEM_H 1 #define HAVE_SYS_SIGNAL_H 1 #define HAVE_SYS_SOCKET_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_SYSCTL_H 1 #define HAVE_SYS_SYSLIMITS_H 1 #define HAVE_SYS_TIME_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_UIO_H 1 #define HAVE_SYS_UN_H 1 #define HAVE_SYS_WAIT_H 1 #define HAVE_NETINET_TCP_H 1 #define HAVE_SOCKLEN_T 1 #define SIZEOF_VOIDP 4 #define SIZEOF_CHAR 1 #define SIZEOF_INT 4 #define SIZEOF_LONG 4 #define SIZEOF_SHORT 2 #define SIZEOF_LONG_DOUBLE 12 #define SIZEOF_LONG_LONG 8 #define SIZEOF_SSIZE_T 4 #define SIZEOF_SIZE_T 4 #define SIZEOF_OFF_T 8 #define SIZEOF_PID_T 4 #define HAVE_STRNCASECMP 1 #define HAVE_STRCASECMP 1 #define HAVE_STRDUP 1 #define HAVE_STRSTR 1 #define HAVE_MEMCHR 1 #define HAVE_STRTOLL 1 #define HAVE_DLOPEN 1 #define HAVE_DLSYM 1 #define DSO_USE_DLFCN 1 #define HAVE_WAITPID 1 #define HAVE_VLA 1 #define HAVE_SEMGET 1 #define HAVE_SEMCTL 1 #define HAVE_FLOCK 1 #define HAVE_SEMAPHORE_H 1 #define HAVE_SEM_CLOSE 1 #define HAVE_SEM_UNLINK 1 #define HAVE_SEM_POST 1 #define HAVE_SEM_WAIT 1 #define HAVE_LOCK_EX 1 #define HAVE_F_SETLK 1 #define HAVE_SEM_UNDO 1 #define HAVE_POLLIN 1 #define HAVE_PTHREAD_PROCESS_SHARED 1 #define apr_lock implementation method 1 #define USE_FLOCK_SERIALIZE 1 #define DEV_RANDOM /dev/random #define HAVE_GMTOFF 1 #define HAVE_SOCKADDR_SA_LEN 1 #line 25093 configure #include confdefs.h #include stdio.h #ifdef HAVE_SYS_TYPES_H #include sys/types.h #endif
Re: today's 5-current hang hard when building apache2 port
I experienced this problem also. Also could not buildworld or buildkernel (caused a reboot). I reverted to a 2/16 kernel and the problems went away. Haven't had time to narrow it down further than that. - Original Message - From: Shizuka Kudo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 21, 2003 3:41 PM Subject: today's 5-current hang hard when building apache2 port I cvsup today and build/install world kernel. The machine was working fine until I tried to build apache2 port. When configuring apache2, my PC hanged at the following line and need hard reset (i.e. cannot break into debugger and need pressing reset button). checking if TCP_NODELAY setting is inherited from listening sockets... I traced the conftest program under gdb and received the following error on the rc = connect(client_s, (struct sockaddr *)sa, sizeof sa) call. Program received signal SIGSEGV, Segmentation fault. 0x280fdaf0 in _longjmp () from /usr/lib/libc.so.5 Anyone has the same problem or idea what's happening? Attached are the confdefs.h and conftest.c extracted from srclib/apr/configure that gave the above problem. P.S. When building the apache2 port, I had CPUTYPE=p3 in make.conf and used make configure WITH_THREADS=yes __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ #define PACKAGE_NAME #define PACKAGE_TARNAME #define PACKAGE_VERSION #define PACKAGE_STRING #define PACKAGE_BUGREPORT #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define HAVE_DLFCN_H 1 #define HAVE_LIBM 1 #define HAVE_PTHREAD_H 1 #define USE_THREADS 1 #define HAVE_PTHREAD_KEY_DELETE 1 #define HAVE_PTHREAD_RWLOCK_INIT 1 #define READDIR_IS_THREAD_SAFE 1 #define GETHOSTBYNAME_IS_THREAD_SAFE 1 #define GETHOSTBYADDR_IS_THREAD_SAFE 1 #define HAVE_GETHOSTBYADDR_R 1 #define HAVE_SIGSUSPEND 1 #define HAVE_SIGWAIT 1 #define HAVE_POLL 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_IPC_H 1 #define HAVE_SYS_SHM_H 1 #define HAVE_SYS_FILE_H 1 #define HAVE_MMAP 1 #define HAVE_MUNMAP 1 #define HAVE_SHM_OPEN 1 #define HAVE_SHM_UNLINK 1 #define HAVE_SHMGET 1 #define HAVE_SHMAT 1 #define HAVE_SHMDT 1 #define HAVE_SHMCTL 1 #define HAVE_MAP_ANON 1 #define anonymous shared memory allocation method 1 #define USE_SHMEM_MMAP_ANON 1 #define namebased memory allocation method 1 #define USE_SHMEM_SHMGET 1 #define HAVE_ALLOCA 1 #define HAVE_CALLOC 1 #define HAVE_STRCASECMP 1 #define HAVE_SETSID 1 #define HAVE_ISINF 1 #define HAVE_ISNAN 1 #define HAVE_SETRLIMIT 1 #define HAVE_GETRLIMIT 1 #define HAVE_WRITEV 1 #define HAVE_SENDFILE 1 #define HAVE_SIGACTION 1 #define SYS_SIGLIST_DECLARED 1 #define HAVE_FORK 1 #define HAVE_STRERROR_R 1 #define STRERROR_R_RC_INT 1 #define HAVE_MMAP 1 #define HAVE_MEMMOVE 1 #define HAVE_GETPASS 1 #define HAVE_GMTIME_R 1 #define HAVE_LOCALTIME_R 1 #define HAVE_HSTRERROR 1 #define HAVE_MKSTEMP 1 #define DIRENT_INODE d_fileno #define DIRENT_TYPE d_type #define STDC_HEADERS 1 #define HAVE_CTYPE_H 1 #define HAVE_DIRENT_H 1 #define HAVE_DLFCN_H 1 #define HAVE_ERRNO_H 1 #define HAVE_FCNTL_H 1 #define HAVE_GRP_H 1 #define HAVE_LIMITS_H 1 #define HAVE_MEMORY_H 1 #define HAVE_NETDB_H 1 #define HAVE_OSRELDATE_H 1 #define HAVE_POLL_H 1 #define HAVE_PWD_H 1 #define HAVE_SEMAPHORE_H 1 #define HAVE_SIGNAL_H 1 #define HAVE_STDARG_H 1 #define HAVE_STDDEF_H 1 #define HAVE_STDIO_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_STRINGS_H 1 #define HAVE_TERMIOS_H 1 #define HAVE_TIME_H 1 #define HAVE_UNISTD_H 1 #define HAVE_ARPA_INET_H 1 #define HAVE_NETINET_IN_H 1 #define HAVE_SYS_FILE_H 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_POLL_H 1 #define HAVE_SYS_RESOURCE_H 1 #define HAVE_SYS_SELECT_H 1 #define HAVE_SYS_SEM_H 1 #define HAVE_SYS_SIGNAL_H 1 #define HAVE_SYS_SOCKET_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_SYSCTL_H 1 #define HAVE_SYS_SYSLIMITS_H 1 #define HAVE_SYS_TIME_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_UIO_H 1 #define HAVE_SYS_UN_H 1 #define HAVE_SYS_WAIT_H 1 #define HAVE_NETINET_TCP_H 1 #define HAVE_SOCKLEN_T 1 #define SIZEOF_VOIDP 4 #define SIZEOF_CHAR 1 #define SIZEOF_INT 4 #define SIZEOF_LONG 4 #define SIZEOF_SHORT 2 #define SIZEOF_LONG_DOUBLE 12 #define SIZEOF_LONG_LONG 8 #define SIZEOF_SSIZE_T 4 #define SIZEOF_SIZE_T 4 #define SIZEOF_OFF_T 8 #define SIZEOF_PID_T 4 #define HAVE_STRNCASECMP 1 #define HAVE_STRCASECMP 1 #define HAVE_STRDUP 1 #define HAVE_STRSTR 1 #define HAVE_MEMCHR 1 #define HAVE_STRTOLL 1 #define HAVE_DLOPEN 1 #define HAVE_DLSYM 1 #define DSO_USE_DLFCN 1
Re: Wavelan problems
Just a suggestion. Do not set media autoselect. Set it to DS/11Mbps mediaopt adhoc or something. This still gives me a TON of tx timeouts, but the card works. I've only had the problem you're seeing when I set media autoselect. James. Maikel Verheijen wrote: Since I deleted the original email of Michael Bretterklieber, I can't actually reply anymore :( This is what I would have replied: I can say nothing more than me too, with a Lucent pC24E-H-ET, a generic lucent silver card. Dmesg info: wi0: WaveLAN/IEEE at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:02:2d:0c:e1:24 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (7.28.1) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps And exact the same wicontrol output. I would like to add that, on enabeling the card (ifconfig wi0 up), my machine practically freezes, and when I pull the card out, I got my machine back most of the time... Dmesg info after doing ifconfig wi0 up: wi0: timeout in wi_cmd 0x0002; event status 0x0080 wi0: timeout in wi_cmd 0x; event status 0x0080 wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: wi_cmd: busy bit won't clear. wi0: init failed wi0: timeout in wi_seek to fc00/0 wi0: timeout in wi_seek to fc81/0 wi0: timeout in wi_seek to fc0c/0 wi0: timeout in wi_seek to fc02/0 wi0: timeout in wi_seek to fc03/0 wi0: timeout in wi_seek to fc04/0 wi0: timeout in wi_seek to fc01/0 wi0: timeout in wi_seek to fc09/0 wi0: timeout in wi_seek to fc07/0 wi0: timeout in wi_seek to fc83/0 wi0: timeout in wi_seek to fc06/0 wi0: timeout in wi_seek to fc25/0 wi0: timeout in wi_seek to fc84/0 wi0: timeout in wi_seek to fc0e/0 wi0: timeout in wi_seek to fc85/0 wi0: timeout in wi_seek to fc20/0 wi0: timeout in wi_seek to fc80/0 wi0: wi_cmd: busy bit won't clear. wi0: failed to allocate 2372 bytes on NIC wi0: tx buffer allocation failed (error 12) wi0: interface not running wi0: wi_cmd: busy bit won't clear. wi0: detached (got this after unplugging the wi-card, to un-freeze the card. Kind regards, Maikel Verheijen Kind regards, Maikel Verheijen USER, n.: The word computer professionals use when they mean idiot. -- Dave Barry, Claw Your Way to the Top 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: today's 5-current hang hard when building apache2 port
On Fri, Feb 21, 2003 at 12:41:52PM -0800, Shizuka Kudo wrote: I cvsup today and build/install world kernel. The machine was working fine until I tried to build apache2 port. When configuring apache2, my PC hanged at the following line and need hard reset (i.e. cannot break into debugger and need pressing reset button). checking if TCP_NODELAY setting is inherited from listening sockets... I traced the conftest program under gdb and received the following error on the rc = connect(client_s, (struct sockaddr *)sa, sizeof sa) call. Program received signal SIGSEGV, Segmentation fault. 0x280fdaf0 in _longjmp () from /usr/lib/libc.so.5 Anyone has the same problem or idea what's happening? Attached are the confdefs.h and conftest.c extracted from srclib/apr/configure that gave the above problem. P.S. When building the apache2 port, I had CPUTYPE=p3 in make.conf and used make configure WITH_THREADS=yes I've had this same problem. Here's the test program I was using, extracted from the latest Apache 2 source, with puts() calls added: http://people.freebsd.org/~tjr/nodel.c . It seems to be locking up after the getsockopt() call has returned, presumably when crt0 calls exit(). Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock panic when UDF mounting
Hi, got this when trying to mount_udf a DVD+RW, could not get a crashdump unfortunately: panic: lockmgr: locking against myself cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0 db trace Debugger(c0349145,0,c0347804,eb5309dc,1) at Debugger+0x5a panic(c0347804,0,c034776c,ee,100) at panic+0x12f lockmgr(c8529e04,1030002,c8529d50,c6c16540,eb530a24) at lockmgr+0x533 vop_stdlock(eb530a40,eb530a60,c02197e5,eb530a40,0) at vop_stdlock+0x2c vop_defaultop(eb530a40,0,c0350674,35c,c01afd38) at vop_defaultop+0x18 vn_lock(c8529d50,20002,c6c16540,86,0) at vn_lock+0xa5 udf_hashins(c85a2000,eb530ab4,c6c16540,800,0) at udf_hashins+0x89 udf_vget(c66d2600,c0,2,eb530b20,0) at udf_vget+0x238 udf_root(c66d2600,eb530b20,c034fa72,2ee,100) at udf_root+0x3e vfs_nmount(c6c16540,1,eb530cb0,0,8056c6b) at vfs_nmount+0x623 nmount(c6c16540,eb530d10,c03653af,407,ca6695cc) at nmount+0xcd syscall(2f,2f,2f,bfbffbbe,bfbffaac) at syscall+0x3c6 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (378, FreeBSD ELF32, nmount), eip = 0x80493db, esp = 0xbfbff60c, ebp = 0xbfbffa80 --- Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ACPI: -dp2 vs. -release
It is however possible to change this back to normal with the Fn key (you probably have something similiar on your Toshiba) so that the brightness back to normal. Dell laptops remember this, so the next time I run the computer on batteries it will restore the brightness to the level I had last time I used it on batteries. The Fn-keys for turning the brightness up/down doesn't work with 5.0 on my laptop. I had a Toshiba laptop, a rather new one (p3 500MHz) and IIRC the powersave-modes (dimmer screen etc) adjusting via function keys didn't ask anything from OS, BIOS trapped the keyboard signals and carried the operation away. Atte Peltomäki http://kameli.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On 10-Feb-2003 Mike Makonnen wrote: On Mon, 10 Feb 2003 13:31:48 +1100 Tim Robbins [EMAIL PROTECTED] wrote: hashinit() can sleep, and I don't think it's safe to sleep here (msdosfs_hashget() and msdosfs_hashins()) with dehash_mtx and sometimes a vnode lock held. Doh! I should have noticed that. It might be better to initialise the table the first time an msdosfs filesystem is mounted. Sounds reasonable enough. So, maybe allocate it in msdosfs_mount or mountmsdosfs and deallocate it in msdosfs_unmount? If there isn't an easy way to tell if you're on the last mounted msdos filesystem, it might be better to just leave the deallocation in msdosfs_uninit. Is that basically what you're saying? That sounds good. You can call a function defined in msdofs_denode.c from the mount vfsop to init the hash table if needed w/o having to expose the actual hash table to the vfsops.c file. Just export the function. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2.2 import -- questions
On 11-Feb-2003 Craig Rodrigues wrote: On Mon, Feb 10, 2003 at 08:44:33PM -0500, Wesley Morgan wrote: that are supposedly fixed with 3.2.2... My question is, should I consider rebuilding my ports with this new compiler because of stability and/or speed improvements? Or is this point release not worth the effort. Speed improvements? No. gcc 3.2.2 is definitely slower than gcc 2.95. There is a lot of arguing on the gcc mailing list right now about this, but no concrete action to improve the situation yet. Umm, his question was to see if there were bugfixes in the Pentium 4 specific optimizations in the 3.2.1 to 3.2.2 GCC upgrade. Not related to 2.95.x at all. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: WITNESS questions
On 12-Feb-2003 Maksim Yevmenkin wrote: Dear Hackers, Does WITNESS keeps track of particular mutex instance or just places where particular mutex type was acquired and released? Is it even possible to keep track of individual instance of the particular mutex type? It just keeps track of types. This is sufficient for tracking lock orders. Here is my problem. In my code (Bluetooth sockets layers) each socket/PCB has a mutex. The mutex type is the same. Also there are few global mutexes that used to protect sockets/PCBs list etc. Now when i do testing and both client and server reside on the same machine, i, sometimes, get lock order reversal messages. All messages can be put into two groups: : 1) Both mutexes are particular instances of the two different types. This is a bug then. You shouldn't be doing this unless you have a well defined order for when you acquire different instances of the lock. Otherwise, what is to prevent two threads from acquiring the same two locks of the same type in the opposite order? 2) One mutex is global and another is particular instance of the particular type. Similarly, you need to have the same order between global mutexes and all the mutexes of a given type. These messages are bugging me and i want to get to the bottom of this. How i can verify/convince myself that these messages are not problems? How should i deal with multiple mutex instances? Will WITNESS be able to help me here? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Need an expert's advise on WITNESS problem(?) (very long)
On 17-Feb-2003 Maksim Yevmenkin wrote: Dear Hackers, I need an expert's advice on the small locking/WITNESS problem (if this is a real problem of course). It basically boils down to the following: Consider three (3) MTX_DEF mutexes: A, B1 and B2. Mutex A has a name mutex_A and type type_A. Mutex B1 has a name mutex_B1 and mutex B2 has name mutex_B2. Both mutex B1 and B2 have the same type type_B. Please note that mutexes B1 and B2 are completely independent from each other. They just have the same mutex type (B1 and B2 are used for fine grained locking). Now consider the code that has two (2) paths: P1 and P2. On the path P1 the code first acquires mutex A and then mutex B1. Then the code releases mutex B1 and then mutex A. On the path P2 the code first acquires mutex B2 and then mutex A. Then the code releases mutex B2 and then mutex A. So the code's flow looks something like this --\ /-- B1 -- Code path P1 A --/ \-- B2 -- Code path P2 Now the problem (again if this is a problem) is that WITNESS code builds relations between mutex types (or at least I think it does). So when the code runs, WITNESS will build relations between mutex types for the first path the code follows (lets say P1). Later when the code follows the second path (in this example P2), WITNESS will create lock order reversal message. The questions are: 1) Is anything wrong with the such code and/or mutex use? Since mutexes B1 and B2 are completely independent, there is no deadlock danger, right? Please tell me if I'm wrong and missing something here. 2) Is there any way to resolve the problem? I'm prepared to change/re-design my code if needed. 3) Is WITNESS right in this case? Yes. By saying that two locks are the same type, you are saying that they should be treated the same. For example, you could have all process locks have 'process lock' for their type and have 'pid ' for their name so that the names are more informative for debugging. Similarly, all network interface drivers would use the same type for their driver lock but might use the name of the interface for the name of the actual lock. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Witness This
On Fri, 21 Feb 2003, Daniel C. Sobral wrote:
backtrace(c032e7d9,c25af500,c25a98d4,c046236e,c04623ec) at
backtrace+0x17
witness_lock(c25af500,8,c04623ec,1b8,c) at witness_lock+0x660
_mtx_lock_flags(c25af500,0,c04623ec,1b8,8095) at
_mtx_lock_flags+0xb1 chn_intr(c25a9880,c,1,208,c25af7c0) at
chn_intr+0x2f cmi_intr(c25a9800,0,c0329618,217,c25ae9ec) at
cmi_intr+0xa6 ithread_loop(c25a9000,cd2ced48,c032948d,366,55ff44fd) at
ithread_loop+0x182 fork_exit(c01cd420,c25a9000,cd2ced48) at
fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1,
eip = 0, esp = 0xcd2ced7c, ebp = 0 ---
This one is probably not my fault, but may well be of interest to
Jeffrey Hsu.
Now, witness biba:
Is there any change you have the console output about three or four lines
above this? It identifies the locks in the lock order reversal. It
sounds like a lock might be held in getnewvnode() across
mac_destroy_vnode_label, which in the original design it wasn't intended
to be, and that might result in the reversal. I'll have to take a closer
look at that.
Finally, trace this:
...
#8 0xc01eb0bb in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
td = (struct thread *) 0xc0ecba50
bootopt = 256
newpanic = 1
buf = mac_mls_single_in_range: a not single, '\0' repeats 218 times
#9 0xc0277274 in mac_mls_single_in_range (single=0x0, range=0xc2605e80)
at /usr/src/sys/security/mac_mls/mac_mls.c:225
No locals.
#10 0xc0278cb6 in mac_mls_check_ifnet_transmit (ifnet=0xc25ebc00,
ifnetlabel=0x0, m=0xc0eda000, mbuflabel=0x0)
at /usr/src/sys/security/mac_mls/mac_mls.c:1462
p = (struct mac_mls *) 0x0
i = (struct mac_mls *) 0x0
#11 0xc01dad7a in mac_check_ifnet_transmit (ifnet=0xc25ebc00,
mbuf=0xc0eda000)
at /usr/src/sys/kern/kern_mac.c:2269
mpc = (struct mac_policy_conf *) 0xc2605e80
error = 0
I'm a bit puzzled by this; it could be this relates to recent changes
regarding when socket state is discarded. Especially odd are the
ifnetlabel and mbuflabel arguments being NULL, as well as the two mac_mls
pointers. Really they should be non-NULL, or you would have panicked
earlier, so perhaps there's stack corruption. If you still have this
dump, you might consider walking back up the stack to these two frames,
and printing the contents of *ifnetlabel and *mbuflabel, as well as
the two struct mac_mls values in mac_mls_check_ifnet_transmit.
BTW, the attached patch might also be useful, as it's possible there's now
a NULL pointer dereference here now. I don't think the trace you have
above will be fixed by this change, but you never know. :-)
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: tcp_subr.c
===
RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.155
diff -u -r1.155 tcp_subr.c
--- tcp_subr.c 21 Feb 2003 23:17:12 - 1.155
+++ tcp_subr.c 22 Feb 2003 02:34:07 -
-484,7 +484,7
m-m_pkthdr.len = tlen;
m-m_pkthdr.rcvif = (struct ifnet *) 0;
#ifdef MAC
- if (tp != NULL) {
+ if (tp != NULL tp-t_inpcp != NULL) {
/*
* Packet is associated with a socket, so allow the
* label of the response to reflect the socket label.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Witness This
Revised patch without typo attached.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Index: tcp_subr.c
===
RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.155
diff -u -r1.155 tcp_subr.c
--- tcp_subr.c 21 Feb 2003 23:17:12 - 1.155
+++ tcp_subr.c 22 Feb 2003 02:44:42 -
-484,7 +484,7
m-m_pkthdr.len = tlen;
m-m_pkthdr.rcvif = (struct ifnet *) 0;
#ifdef MAC
- if (tp != NULL) {
+ if (tp != NULL tp-t_inpcb != NULL) {
/*
* Packet is associated with a socket, so allow the
* label of the response to reflect the socket label.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
kernel panic
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01bcab9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01bcd23 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0200cc2 in bwrite (bp=0xc785a060) at /usr/src/sys/kern/vfs_bio.c:842
#4 0xc0202481 in vfs_bio_awrite (bp=0xc785a060)
at /usr/src/sys/kern/vfs_bio.c:1724
#5 0xc0209e17 in vop_stdfsync (ap=0xcd32ca60)
at /usr/src/sys/kern/vfs_default.c:755
#6 0xc01811e0 in spec_fsync (ap=0xcd32ca60)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
#7 0xc01806b8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
#8 0xc026ed67 in ffs_sync (mp=0xc2691400, waitfor=2, cred=0xc0eb5e80,
td=0xc0316c00) at vnode_if.h:612
#9 0xc021763b in sync (td=0xc0316c00, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc01bc69c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#11 0xc01bcd23 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#12 0xc02c9472 in trap_fatal (frame=0xcd32cc28, eva=0)
at /usr/src/sys/i386/i386/trap.c:844
#13 0xc02c9152 in trap_pfault (frame=0xcd32cc28, usermode=0, eva=3310622)
at /usr/src/sys/i386/i386/trap.c:758
#14 0xc02c8c40 in trap (frame=
---Type return to continue, or q return to quit---
{tf_fs = -1070333928, tf_es = -1058275312, tf_ds = -852361200, tf_edi = -1
071351312, tf_esi = -1030640448, tf_ebp = -852308848, tf_isp = -852308908, tf_eb
x = 3310418, tf_edx = -1058256304, tf_ecx = -1030640408, tf_eax = 4, tf_trapno =
12, tf_err = 2, tf_eip = -1071351204, tf_cs = 8, tf_eflags = 66050, tf_esp = -1
071897635, tf_ss = -1070479488}) at /usr/src/sys/i386/i386/trap.c:445
#15 0xc02b8df8 in calltrap () at {standard input}:96
#16 0xc01cc435 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:195
#17 0xc01a8931 in ithread_loop (arg=0xc0ec2200)
at /usr/src/sys/kern/kern_intr.c:536
#18 0xc01a7823 in fork_exit (callout=0xc01a8760 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
FreeBSD leafy.idv.tw 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Feb 22 01:19:49 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHIHIRO i386
--
Without the userland, the kernel is useless.
--inspired by The Tao of Programming
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: kernel panic
Panic message? A panic w/o the actual panic message is like taking your
car to the shop and saying it doesn't drive right.
On 22-Feb-2003 leafy wrote:
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01bcab9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01bcd23 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0200cc2 in bwrite (bp=0xc785a060) at /usr/src/sys/kern/vfs_bio.c:842
#4 0xc0202481 in vfs_bio_awrite (bp=0xc785a060)
at /usr/src/sys/kern/vfs_bio.c:1724
#5 0xc0209e17 in vop_stdfsync (ap=0xcd32ca60)
at /usr/src/sys/kern/vfs_default.c:755
#6 0xc01811e0 in spec_fsync (ap=0xcd32ca60)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
#7 0xc01806b8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
#8 0xc026ed67 in ffs_sync (mp=0xc2691400, waitfor=2, cred=0xc0eb5e80,
td=0xc0316c00) at vnode_if.h:612
#9 0xc021763b in sync (td=0xc0316c00, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc01bc69c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#11 0xc01bcd23 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#12 0xc02c9472 in trap_fatal (frame=0xcd32cc28, eva=0)
at /usr/src/sys/i386/i386/trap.c:844
#13 0xc02c9152 in trap_pfault (frame=0xcd32cc28, usermode=0, eva=3310622)
at /usr/src/sys/i386/i386/trap.c:758
#14 0xc02c8c40 in trap (frame=
---Type return to continue, or q return to quit---
{tf_fs = -1070333928, tf_es = -1058275312, tf_ds = -852361200, tf_edi = -1
071351312, tf_esi = -1030640448, tf_ebp = -852308848, tf_isp = -852308908, tf_eb
x = 3310418, tf_edx = -1058256304, tf_ecx = -1030640408, tf_eax = 4, tf_trapno =
12, tf_err = 2, tf_eip = -1071351204, tf_cs = 8, tf_eflags = 66050, tf_esp = -1
071897635, tf_ss = -1070479488}) at /usr/src/sys/i386/i386/trap.c:445
#15 0xc02b8df8 in calltrap () at {standard input}:96
#16 0xc01cc435 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:195
#17 0xc01a8931 in ithread_loop (arg=0xc0ec2200)
at /usr/src/sys/kern/kern_intr.c:536
#18 0xc01a7823 in fork_exit (callout=0xc01a8760 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
FreeBSD leafy.idv.tw 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Feb 22 01:19:49 CST
2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHIHIRO i386
--
Without the userland, the kernel is useless.
--inspired by The Tao of Programming
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: vm_page_alloc: free/cache page 0xc09fb738 was dirty
I know my kernel is a bit old, but does this panic look familiar to
anyone?
uname -a
FreeBSD laptop.baldwin.cx 5.0-CURRENT FreeBSD 5.0-CURRENT #795: Fri Feb 14 17:30:12
EST 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/LAPTOP i386
panic: bremfree: bp 0xcae44ed8 not locked
panic messages:
---
panic: vm_page_alloc: free/cache page 0xc09fb738 was dirty
syncing disks, buffers remaining... panic: bremfree: bp 0xcae44ed8 not locked
Uptime: 6h51m43s
Dumping 383 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc027ae87 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc027b0f3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc02bc0d7 in bremfree (bp=0xcae44ed8) at ../../../kern/vfs_bio.c:664
#4 0xc02be18b in vfs_bio_awrite (bp=0xcae44ed8)
at ../../../kern/vfs_bio.c:1707
#5 0xc02c542f in vop_stdfsync (ap=0xd6e70aa0)
at ../../../kern/vfs_default.c:755
#6 0xc0243880 in spec_fsync (ap=0xd6e70aa0)
at ../../../fs/specfs/spec_vnops.c:422
#7 0xc0242ca8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:123
#8 0xc0369137 in ffs_sync (mp=0xc3374a00, waitfor=2, cred=0xc11f9e80,
td=0xc046bc60) at vnode_if.h:612
#9 0xc02d154b in sync (td=0xc046bc60, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#10 0xc027aa8c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#11 0xc027b0f3 in panic () at ../../../kern/kern_shutdown.c:542
#12 0xc0386571 in vm_page_alloc (object=0xc3c68c78, pindex=33, req=0)
at ../../../vm/vm_page.c:864
#13 0xc03790d2 in vm_fault (map=0xc3c3d000, vaddr=671707136,
fault_type=1 '\001', fault_flags=0) at ../../../vm/vm_fault.c:405
#14 0xc03cc20f in trap_pfault (frame=0xd6e70d48, usermode=1, eva=671709200)
at ../../../i386/i386/trap.c:734
#15 0xc03cbcc2 in trap (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077936732, tf_esi = -1077936704,
tf_ebp =
-1077936740, tf_isp = -689500812, tf_ebx = 6, tf_edx = -1077936554, tf_ecx =
671407760, tf_eax =
134520516, tf_trapno = 12, tf_err = 4, tf_eip = 671709200, tf_cs = 31, tf_eflags =
66050, tf_esp =
-1077936768, tf_ss = 47})
at ../../../i386/i386/trap.c:331
#16 0xc03bc718 in calltrap () at {standard input}:96
---Can't read userspace from dump, or kernel process---
(kgdb) p *(struct vm_page *)0xc09fb738
$1 = {pageq = {tqe_next = 0xc09fc938, tqe_prev = 0xc0484e90}, listq = {
tqe_next = 0xc08d9380, tqe_prev = 0xc33a104c}, left = 0x0,
right = 0xc08e47c8, object = 0x0, pindex = 0, phys_addr = 102170624, md = {
pv_list_count = 0, pv_list = {tqh_first = 0x0, tqh_last = 0xc09fb764}},
queue = 0, flags = 1, pc = 16, wire_count = 0, hold_count = 0,
act_count = 0 '\0', busy = 0 '\0', valid = 0 '\0', dirty = 255 'ÿ', cow = 0}
kernel.debug and vmcore available on request.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic
On Fri, Feb 21, 2003 at 10:38:46PM -0500, John Baldwin wrote: Panic message? A panic w/o the actual panic message is like taking your car to the shop and saying it doesn't drive right. I am sorry, here it is: panic: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x32841e fault code = supervisor write, page not present instruction pointer = 0x8:0xc0247a5c stack pointer = 0x10:0xcd32cc68 frame pointer = 0x10:0xcd32cc90 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: tty:sio clock) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? Uptime: 9h12m49s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: config files and includes
What would be really cool is if more config files could do 'includes' so that you could have a syslogd.local.conf wher eall your local entries could be. In addition you could make it look in /usr/local/etc/syslogd.conf for loging requirments for packages. Hmmm... glancing through syslogd.c, it doesn't look like it would be hard to alter it to support multiple -f options. In that case, just add the following to rc.conf (or /etc/rc.d/syslogd, I suppose): if [ -e /etc/syslog.local ] then syslogd_args=$syslogd_args -f /etc/syslog.local fi for f in /usr/local/etc/syslogd.d/* do syslogd_args=$syslogd_args -f $f done This largely removes the need for include handling. It doesn't allow you to override or remove existing entries, though. One approach that preserves backward compatibility would be to allow optional line numbers, with duplicates overriding earlier entries. That requires some non-trivial code changes to support, but it shouldn't be too hard. There's also considerable precedent for using cpp or m4 to preprocess configuration files. Either supports file inclusions, conditionals, etc. It's generally not too hard to support this: it usually just involves replacing fopen() with popen(). Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Mounting Root fails with error 22 (EINVAL)
Hi! I've just cvsupped current and rebuilt world and now I'm getting this error when I boot with the new kernel. I had a look at the archives and found out that such a problem existed in January, too and I verified, that I do have the right revision of src/sys/ufs/ffs/fs.h (1.38). A kernel dated Feb. 14th boots without problems. Did I miss something? Many thanks, Christian. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Several oddities on a new Sis-based laptop (wi and keyboard problems)
I've got a Winbook J4. I've managed to get most everything working, but there are still two nagging problems that I'd love to get solved. First, I've got an integrated Accton 802.11b card: wi0: Intersil Prism2.5 mem 0xe8006000-0xe8006fff irq 9 at device 5.0 on pci0 wi0: 802.11 address: 00:30:f1:4b:5d:c4 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.2) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps I can successfully set the ssid on this card, but as soon as I try and send a packet, it appears that the machine locks up. However, on further investigation, VT switching still works, as does console buffer (Pause/pageup pagedown). Typeing anything else gives no response. It appears that other processes are running, as I see periodic disk activity (i.e. a background compile). No screen update will occur. The power key no longer functions, however, removing AC power shows the expected console message for power management. The second problem is that pressing CTRL_ALT_BREAK appears to shut the machine off. It actually looks more like it goes into hibernation, but I have yet to find a way to bring it out of this state. Pressing the power button has so far either resulted in a running but apparently dead machine or the machine immediately turning itself back off. Anyone have any insight? Thanks -- This song is Copyrighted in U.S., under Seal of Copyright # 154085, for a period of 28 years, and anybody caught singin' it without our permission, will be mighty good friends of ourn, cause we don't give a dern. Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that's all we wanted to do. --Woody Guthrie on Copyright To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question about KLDs...
Paul A. Howes [EMAIL PROTECTED] writes: This may be a fairly elementary question, but I have not seen this addressed in the Handbook at all -- Which is the preferred method for using drivers: KLDs or compiling into the kernel? Are there some that work better one way than the other? Drivers compiled into the kernel can be compiled with specific options, and they make debugging easier in case of a panic (provided you get a dump). Some drivers fail to initialize properly if they are not loaded at boot time (i.e. compiled into the kernel *or* enabled in loader.conf) and of course some drivers (such as those you need to access your root partition) *must* be present at boot time. Leaving drivers out of your kernel config saves some compilation time, since unless you tweak MODULES_OVERRIDE to only build modules you know that you will need, everything in your kernel which is also a module gets built twice. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
