Re: BSDCan Toolchain Summit Summary
On Tue, 1 Jun 2010, Brooks Davis wrote: On Tue, Jun 01, 2010 at 11:15:26AM +0200, Dag-Erling Sm??rgrav wrote: Brooks Davis writes: http://wiki.freebsd.org/201005ToolchainSummitSummary "No new functionality that requires clang/llvm." How about "No new functionality with non-trivial incompatibilities with clang/llvm"? That too. I'll add it to the real roadmap page once I create it. As long as people are willing to avoid the darker areas of gcc misfeatures that shouldn't be a problem in general, but I agree stating it as a target is a good idea. I think the gist of our discussion was really about where we can/should introduce new dependencies on features specific to clang/llvm. For example, there are some quite interesting ideas about distributing binaries in the LLVM intermediate format and doing on-the-fly tuning for the architecture we find ourselves running on. This is pretty neat stuff, but it does mean that it won't be available in the immediate future for architectures not supported by LLVM or for shops that have to use external non-LLVM-based toolchain parts (such as compilers for specific embedded platforms). I think the consensus from the meeting was that we should start to explore the possible, but that key OS features that don't strictly require new compiler/etc functionality should not be caused to unnecessarily depend on them. This doesn't prohibit doing interesting runtime reoptimization stuff, but it does prohibit making it so that the OS won't work without them. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sem.ko and vfs_aio.ko modules not built by default
On Sun, 23 Mar 2003, Craig Rodrigues wrote: > I notice that with a recent -current, that the vfs_aio.ko and sem.ko > modules do not seem to be built by default. In the past, this was not > the case. > > Is it mandatory now to specify the kernel options: > options VFS_AIO > options P1003_1B_SEMAPHORES > > in order for these modules to be built? I thought that the modules > would be built if no options were specified, and if those options were > specified, the modules would be built into the kernel. Sometimes, kernel modules will not be built by default because they are unstable or experimental features that have not been adequately deployed or tested. I know our AIO implementation has improved in quality a great deal over the last couple of years, but last I checked the psem implementation had very little practical deployment experience or testing. Probably what it will take is someone owning the code for a bit to develop a proper test suite, chase down nasty interactions, etc. I know similar (although not identical) code exists in Darwin -- would be interesting to ask Apple if they have a test suite for their psem implementation. 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
ACPI problem: sio ports improperly attached with ACPI on Intel L440GX+
I'm attempting to use an Intel L440GX+ motherboard with 5.x, and am running into the following problem: when I boot without ACPI, the serial ports probe, attach, and work fine: Mar 23 14:21:56 none kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Mar 23 14:21:56 none kernel: sio0: type 16550A Mar 23 14:21:56 none kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Mar 23 14:21:56 none kernel: sio1: type 16550A When I boot with ACPI, the following appears in dmesg: Mar 23 14:14:31 none kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Mar 23 14:14:31 none kernel: sio0: port may not be enabled Mar 23 14:14:31 none kernel: sio0 port 0x3f8-0x3ff irq 4 on acpi0 Mar 23 14:14:31 none kernel: sio0: type 16550A Mar 23 14:14:31 none kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Mar 23 14:14:31 none kernel: sio1: port may not be enabled Mar 23 14:14:31 none kernel: sio1 port 0x2f8-0x2ff irq 3 on acpi0 Mar 23 14:14:31 none kernel: sio1: type 16550A And sure enough, when using ACPI, interrupts don't work properly with the serial ports, resulting in them essentially being unusable (stuff goes out, but not in, except once in a while when the silo overflows). I notice that, unlike my other 5.x boxes, sio0 and sio1 seem to attach to acpi0, rather than isa0 as one would expect, so I guess it's not entirely surprising that the interrupts aren't working right. Any suggestions about how I might go about diagnosing and remedying this problem? 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: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Daniel C. Sobral wrote: > The messages below are from today's kernel + mac_mls and mac_biba > kld-loaded from loader(8). None of the warning appear if these modules > are not loaded (I haven't tried not loading one and then the other, but > I can do it on request) ... > malloc() of "128" with the following non-sleepablelocks held: > exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ > /usr/src/sys/netinet/udp_usrreq.c:1034 > exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ > /usr/src/sys/netinet/udp_usrreq.c:1027 Hmm. I think there's a witness flag to generate stack traces when giving out these sorts of warnings -- debug.witness_trace I think. Can you try turning that on in loader.conf and see if we get some additional information? The only MAC call in udp_output() is mac_create_mbuf_from_socket(), which isn't supposed to result in memory allocation. That should only happen when the mbuf itself is allocated. A stack trace might narrow down the source of the problem. Thanks, 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: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Christian Brueffer wrote: > FYI, debug.witness_trace is set (seems to default to 1). Any other ways > to get more info out of this? Are you only looking at syslog, or also at the actual console? It could be that the Witness traces only appear on the console itself, not in the log (undesirable, but possible). 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: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Christian Brueffer wrote: > On Mon, Mar 24, 2003 at 02:45:57PM -0500, Robert Watson wrote: > > On Mon, 24 Mar 2003, Christian Brueffer wrote: > > > > > FYI, debug.witness_trace is set (seems to default to 1). Any other ways > > > to get more info out of this? > > > > Are you only looking at syslog, or also at the actual console? It could > > be that the Witness traces only appear on the console itself, not in the > > log (undesirable, but possible). > > > > It's on the console. Any chance you could copy/paste it using a serial console or the like? 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: IP stack problem -- possibly mac-related
On Mon, 24 Mar 2003, Christian Brueffer wrote: > > Well, not much to see here: > > > > malloc() of "128" with the following non-sleepablelocks held: > > exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n > > etisr.c:215 > > > > which is repeated over and over again, when I copy a large file over > > NFS. There's no actual trace appearing. > > > > Sorry, these ones are appearing too: > > malloc() of "128" with the following non-sleepablelocks held: > exclusive sleep mutex inp r = 0 (0xc27a4608) locked @ /usr/src/sys/netinet/udp_u > srreq.c:1034 > exclusive sleep mutex udp r = 0 (0xc041a18c) locked @ /usr/src/sys/netinet/udp_u > srreq.c:1027 Looks like witness warnings don't automatically auto-trace. Could you set witness.ddb and generate a backtrace for each of the warnings and e-mail them to me? Thanks! 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: init not loading? why?
On Fri, 28 Mar 2003, Sean Chittenden wrote: > > I recently purchased a new laptop HDD, tossed three partitions onto > > the drive (/, /usr, and swap), newfs'ed them with UFS2, mounted the > > new drive as a umass device, copied files over (tar), and now when I > > boot with my new drive, the kernel is having problems launching > > /sbin/init. For the life of me, I can't figure out why it's not > > loading. After dropping to DDB, I don't see it in the process list > > and I'm not getting any output other than notice that the kernel is > > starting /sbin/init. > > Ah! Figured it out after reading through init's src: /dev didn't exist > therefore the machine wouldn't start. No good. I may find a place to > stick this got'cha in the docs or add an mkdir() call to init. -sc mkdir(2) on / is not going to work if / is readonly. The kernel actually tries to do a vop_mkdir() already, I think. The eventual solution is probably a rootfs (blaim mux). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: init not loading? why?
On Fri, 28 Mar 2003, Sean Chittenden wrote: > > > Ah! Figured it out after reading through init's src: /dev didn't > > > exist therefore the machine wouldn't start. No good. I may find > > > a place to stick this got'cha in the docs or add an mkdir() call > > > to init. > > > > mkdir(2) on / is not going to work if / is readonly. The kernel > > actually tries to do a vop_mkdir() already, I think. The eventual > > solution is probably a rootfs (blaim mux). > > Well, I haven't tested this, but I think you're right that it's nmount() > that's failing and the lack of a check on it's return value. I haven't > tested this beyond compiling it, but I suspect it'll work and fix this > corner case. -sc Per our out-of-band conversation, it looks like this won't work because of a lack of /dev. It seems like the most reasonable solution is to generate a kernel warning message if the kernel-side devfs mount attempt fails. If we cause init to fail, the kernel will panic, and I can't quite decide if (a) the system hanging, or (b) the kernel panicking is a better answer. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libthr and 1:1 threading.
On Wed, 2 Apr 2003, Sheldon Hearn wrote: > On (2003/04/02 06:05), Terry Lambert wrote: > > > > I think Jeff (or someone else?) said, that some web browsers gain > > > "something" too (serialization issues with libc_r)? I had the impression > > > that this also applies to UP systems. > > > > > > Do I misremember this? If not, does it not apply to UP systems as well? > > > > FWIW: the libc_r reentrancy isn't fixed by a 1:1 model for > > anything but calls for which there are no non-blocking > > alternative kernel APIs. [...long ramble...] > > For all the rambling, I'm happy to report that my SCHED_ULE + libthr UP > workstation feels noticibly more responsive when I have several Mozilla > tabs all loading pages simultaneously while I'm trying to make a > threaded Java IDE do something sensible. > > It's possible that I'm actually seeing the impact of other changes that > have been committed in the last week, I suppose. You should notice marked interactivity and UI latency improvements with threaded GUI apps over libc_r because GUI threads will generally no longer be blocked when disk I/O and blocking I/O occurs. For example, applications like Open Office, Netscape, et al, really get a lot better with 1:1. Likewise, non-interactive applications that are disk I/O-intensive, such as mysql, will also perform substantially better because a thread that hits blocking using an interface that doesn't support non-blocking I/O (such as the file system) won't clog up the application. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libthr and 1:1 threading.
On Wed, 2 Apr 2003, Terry Lambert wrote: > Is the disk I/O really that big of an issue? All writes will be on > underlying non-blocking descriptors; I guess you are saying that the > interleaved I/O is more important, further down the system call > interface than the top, and this becomes an issue? The I/O issue is a big deal for things like mysql, yes. > It seems to me that maybe the correct fix for this is to use AIO instead > of non-blocking I/O, then? Well, they're both fixes. Another issue for applications that are threaded and may be bumping up against the system memory limits is whether or not the whole process stalls on a page fault or memory mapping fault, or whether it's just the thread. If you have an application that is accessing a large memory mapped file, there may be some long kernel sleeps as you pull in the pages. Certainly, you can argue that the application should be structured to make all I/O explicit and asynchronous, but for various reasons, that's not the case :-). Our VM and VFS subsystems may have limited concurrency from an SMPng perspective, but probably have enough that a marked benefit should be seen there too (you might have to wait for another thread to block in the subsystem, but that will be a short period of time compared to how long it takes to service the page from disk). > The GUI thread issues are something I hadn't considered; I don't > generally think of user space CPU intensive operations like that, but I > guess it has to be rendered some time. 8-). One of the problems I've run into is where you lose interactivity during file saves and other disk-intensive operations in OpenOffice. Other windows could in theory still be processing UI events, such as menu clicks, etc, but since you're dumping several megabytes of data to disk or doing interactive file operations that require waiting on disk latency, you end up with a fairly nasty user experience. One way to explore this effect is to do a side-by-side comparison of the behavior of OpenOffice and Mozilla linked against libc_r and linuxthreads. I haven't actually instrumented the kernel, but it might be quite interesting to do so--attempt to estimate the total impact of disk stalls on libc_r. From a purely qualitivative perspective, there is quite a noticeable difference. > Has anyone tried compiling X11 to use libthr? Not sure. > Also, any ETA on the per process signal mask handing bug in libthr? > Might not be safe to convert everything up front, in a rush of eager > enthusiasm... Can't speculate on that, except one thing that is useful to note is that many serious threaded applications are already being linked against linuxthreads on FreeBSD, which arguably has poorer semantics when it comes to signals, credentials, etc, than libthr already :-). For example, most sites I've talked to that deploy mysql do it with linuxthreads rather than libc_r to avoid the I/O issues, as well as avoid deadlocks. There are enough bits of the kernel (for example, POSIX fifos) that don't handle non-blocking operation that libc_r can stall or get into I/O buffer deadlocks. I seem to recall someone mentioning (but can't confirm easily) that Netscape at one point relied on using pipes to handle some sorts of asynchronous events and wakeups within the same process. If that pipe filled, the process would block on a pipe write for a pipe that would never drain. I can think of a couple of other interesting excercises to explore the problem -- implementing AIO "better" using the KSE primitives mixed between userspace and kernel, reimplementing libc_r to attempt to use AIO rather than a select loop where possible, etc. It might be quite interesting to see whether (for a bounded number of threads, due to our AIO implementation), a libc_r that used AIO rather than select demonstrated some of the performance improvements we see with 1:1 via linuxthreads (and now libthr). I'm not sure if there are any open source tools available to easily track process and thread scheduling and blocking, but there have been several pretty useful visual analysis and tracing tools for realtime. Some basic tools for thread tracing and visualization exist for Mac OS X, and presumably other COTS platforms. ktrace on FreeBSD makes some attempt to track context switches, but without enough context (har har) to be useful for this kind of analysis. I've been thinking about tweaking the local scheduler to put a bit more information into ktr and alq about blocking circumstances as well as some way to constrain the tracing to a particular bit of the process hierarchy with an inheritance flag of some sort. It might be quite helpful for understanding some of the nasty threading blocking/timing issues that we already run into with libc_r, and will continue to run into as our threading evolves. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories __
Something in NFS server calling vrele() not vput()?
Unfortunately, I don't have too much information here. The scenario is as follows: cboss: NFS file/build server crash2: NFS diskless client I built world on cboss; I then did installworld in crash2. I intended to installworld to a DESTDIR on a local disk on crash2, but I failed to mount it first, so the installworld had both the source and target in NFS. When I realizes this had happened, I proceeded to rm -Rf the DESTDIR tree. Shortly thereafter, rm -Rf hung on a vnode lock, and other processes started to stack up going up the directory tree. I have a little debugging information below that may be relevant--show lockedvnods shoes two directories where the locks are held by rm (0x40a25a0), a later ls (0xc48bd2d0). The last there entries are worring because the refcounts on each of these vnodes is 0, and the VI_FREE flag is set. Earlier in the debugging session, the VI_FREE flag wasn't set, so presumably the vnode was being free'd following a removal (not unlikely with installs, renames, and removals). Interestingly, the last three entries in the locked vnode list were apparently grabbed by the nfs daemon. Unfortunately, we lost of the pid entry in the lock structure so I can't tell if the thread pointer is stale and the struct thread has been reused or not. I suspect given that the nfsd thread pool is pretty much static that the locks were indeed grabbed by NFS, so some NFS operation may be calling vrele() instead of vput() (or the like). Alternatively, perhaps there's a race somewhere during ufs_inactive() between it and an NFS operation? Any other thoughts would be welcome; unfortunately, no core dump is available. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories db> show lockedvnods Locked vnodes 0xc5a2bc8c: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc48bd2d0 ino 619588, on dev ad0s1g (4, 18) 0xc4fbd6d8: tag ufs, type VDIR, usecount 4, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc40a25a0 with 1 pending ino 1129851, on dev ad0s1g (4, 18) 0xc4d456d8: tag ufs, type VREG, usecount 1, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc3f78c30 with 1 pending ino 1129935, on dev ad0s1g (4, 18) 0xc5046248: tag ufs, type VREG, usecount 0, writecount 0, refcount 0, flags (VI_FREE|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc3f78c30 ino 1215822, on dev ad0s1g (4, 18) 0xc41fe920: tag ufs, type VREG, usecount 0, writecount 0, refcount 0, flags (VI_FREE|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc3f78c30 ino 1216038, on dev ad0s1g (4, 18) db> cont -> cboss# db> trace 13805 mi_switch(c40a25a0,50,c5c4536c,dba91c40,0) at mi_switch+0x181 msleep(c4d45794,c058a2a0,50,c04fabf4,0) at msleep+0x43c acquire(dba919d0,140,600,689bd73c,c40a25a0) at acquire+0xa0 lockmgr(c4d45794,1010002,c4d456d8,c40a25a0,dba919ec) at lockmgr+0x3f7 vop_stdlock(dba91a14,dba919f8,c0440778,dba91a14,dba91a38) at vop_stdlock+0x2c vop_defaultop(dba91a14,dba91a38,c036629e,dba91a14,c4603e10) at vop_defaultop+0x1 8 ufs_vnoperate(dba91a14,c4603e10,dba91a5c,c043cb34,2) at ufs_vnoperate+0x18 vn_lock(c4d456d8,10002,c40a25a0,c034ca3a,c5bd7de2) at vn_lock+0x11e vget(c4d456d8,2,c40a25a0,1064428,c40a25a0) at vget+0x100 vfs_cache_lookup(dba91b54,dba91b80,c0352122,dba91b54,20002) at vfs_cache_lookup+ 0x1ed ufs_vnoperate(dba91b54,20002,c40a25a0,dba91b0c,c40a25a0) at ufs_vnoperate+0x18 lookup(dba91c18,c46f1800,400,dba91c34,c40a25a0) at lookup+0x302 namei(dba91c18,80bd948,60,0,c40a25a0) at namei+0x20b lstat(c40a25a0,dba91d10,8,c40a25a0,2) at lstat+0x52 syscall(2f,2f,2f,80bda00,80b7040) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (190, FreeBSD ELF32, lstat), eip = 0x804b45f, esp = 0xbfbff53c, ebp = 0xbfbff5c8 --- (kgdb) inspect ((struct thread *)0xc3f78c30)->td_proc.p_pid $1 = 404 (kgdb) inspect ((struct thread *)0xc3f78c30)->td_proc.p_comm $2 = "nfsd\0er", '\0' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital. | |---++---+---| | || | Support for pluggable | | || | directory services using | | || | NSS, including| | || | adaptations of current| | || Jacques | directory services (local | | NSSwitch support | -- | Vidrine | databases, NIS), and | | || | support for new services
Re: 5.1-RELEASE TODO
On Thu, 5 Jun 2003, Robert Watson wrote: > This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. > The live version of this list is available at: Well, we won't be needing *that* anymore :-). Expect the 5.2 TODO to trickle in every few weeks for the next few months, and feel free to submit updates to the TODO list to [EMAIL PROTECTED] I should say, of course, that the primary goals for 5.2 are not new software features (although those will happen too), but improved performance, robustness, and usability across all of our platforms, so don't submit too many feature TODO items that will distract people from making that happen :-). I think I speak for everyone when I say I'm on the edge of my seat for RELENG_5 being branched--5.x has been a long time coming, but it's going to be well worth it. Thanks again to everyone who made the 5.1 release process happen, especially to those who spent the last couple of weeks chasing down obscure and difficult bugs (the ones that make such a difference); and to those who made the push to make libthr and libkse so much more functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PANIC: FreeBSD dislikes temps (panic when mounting /tmp)
On Fri, 6 Jun 2003, Daniel C. Sobral wrote: > Robert, I cc'ed you because you are usually guilty anyway... (besides, > there's a ea thingy there :) I probably am, actually :-). Is the file system in question UFS or UFS2? To summarize the context of the crash: when UFS_EXTATTR_AUTOSTART is present in the kernel, UFS file systems are scanned for a ".attribute" directory in the root of the file system, and then it walks into various subdirectories of that directory looking for attribute files to start. This happens fairly early in the mount process, and it looks like the panic is in the UFS_DIRHASH code, so perhaps we're bumping into an incompletely initialized inode field of some sort. I'll look in detail at this over the weekend. Is this during the boot, or is this later when you mount a UFS file system? The trace is truncated at the bottom, I think. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PANIC: FreeBSD dislikes temps (panic when mounting /tmp)
On Fri, 6 Jun 2003, Daniel C. Sobral wrote: > > I probably am, actually :-). Is the file system in question UFS or UFS2? > > [1] [EMAIL PROTECTED]:/opt/home/dcs$ sudo dumpfs /dev/ad0s2f > magic 19540119 (UFS2) timeFri Jun 6 14:06:59 2003 Hmm. Ok. Well, UFS_EXTATTR_AUTOSTART doesn't really need to do that on UFS2, only UFS1, so I probably need to add a check somewhere. It shouldn't crash, but it also shouldn't need to be there. If you're not using UFS1, you can turn it off in your kernel config also, although I'd like to make sure I fix the problem so I'll probably ask you to turn it on briefly once I get you a patch. > > Is this during the boot, or is this later when you mount a UFS file > > system? The trace is truncated at the bottom, I think. > > On mount. fsck works, even. > > As for the trace, there's the following on a simple bt: Ok, that's fine; I just needed the context to know if it could be something special about the boot-time environment. > Funny that bt full actually stops on that problem. Yeah, bizarre. Who knows, maybe gdb got bored. :-) I'll try to drop you a patch in the next day or so, thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
Got this panic recently on a MAC development box. The MAC development
branch hasn't been integrated in a few weeks, so this might well be fixed
in the main tree. The versions of various files are:
$FreeBSD: src/sys/vm/vm_kern.c,v 1.97 2003/04/15 01:16:05 alc Exp $
$FreeBSD: src/sys/kern/subr_mbuf.c,v 1.47 2003/05/02 03:43:40 silby Exp $
I haven't seen this panic previously; a lack of Giant coming out of the
socket code is a bit surprising to me, but I think is unlikely to be a
result of our local MAC tweaks.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
<118>a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout
/usr/X11R6/lib/aout
<118>/etc/rc: INFO: nfsd depends on mountd, which will be forced to start.
<118>Starting mountd.
<118>Starting nfsd.
panic: mutex Giant not owned at ../../../vm/vm_kern.c:315
P
Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54
db> trace
Debugger(c04ec67c,c0586b60,c04ebdc3,c8cddb2c,1) at Debugger+0x54
panic(c04ebdc3,c04ebefc,c050050a,13b,c04eaf98) at panic+0xab
_mtx_assert(c0584ee0,1,c050050a,13b,4) at _mtx_assert+0xec
kmem_malloc(c0b7f000,2000,2,230,163) at kmem_malloc+0x39
mb_pop_cont(c0587c20,8,c0b6cac0,2c7,c0b7d700) at mb_pop_cont+0xa0
mb_alloc(c0587c20,8,e,0,0) at mb_alloc+0x217
m_get(8,e,5f7,c04eef16,0) at m_get+0x34
sockargs(c8cddc4c,bfbfd550,60,e,c8cddc68) at sockargs+0x4a
sendit(c192b4c0,c,c8cddcb4,0,806b000) at sendit+0x91
sendmsg(c192b4c0,c8cddd10,c050602b,3fb,3) at sendmsg+0xc2
syscall(2f,2f,2f,bfbfd5b0,20) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x280d24b3, esp =
0xbfbfd52c, ebp = 0xbfbfd5d8 ---
db> show pcpu
cpuid= 0
curthread= 0xc192b4c0: pid 275 "rpcbind"
curpcb = 0xc8cddda0
fpcurthread = none
idlethread = 0xc0b88850: pid 11 "idle"
currentldt = 0x28
spin locks held:
(kgdb) l *kmem_malloc+0x39
0xc043eea9 is in kmem_malloc (../../../vm/vm_kern.c:317).
312 int pflags;
313
314 if ((flags & M_NOWAIT) == 0)
315 GIANT_REQUIRED;
316
317 size = round_page(size);
318 addr = vm_map_min(map);
319
320 /*
321 * Locate sufficient space in the map. This will give us
the final
(kgdb) l *mb_pop_cont+0xa0
0xc0334e10 is in mb_pop_cont (../../../kern/subr_mbuf.c:573).
568 bucket = malloc(sizeof(struct mb_bucket) +
569 mb_list->ml_objbucks * sizeof(void *), M_MBUF,
MBTOM(how));
570 if (bucket == NULL)
571 return (NULL);
572
573 p = (caddr_t)kmem_malloc(mb_list->ml_map,
mb_list->ml_objsize *
574 mb_list->ml_objbucks, MBTOM(how));
575 if (p == NULL) {
576 free(bucket, M_MBUF);
577 if (how == M_TRYWAIT)
(kgdb) l *mb_alloc+0x217
0xc0336057 is in mb_alloc (../../../kern/subr_mbuf.c:712).
707 } else {
708 /*
709 * We'll have to allocate a new page.
710 */
711 MB_UNLOCK_CONT(gen_list);
712 bucket = mb_pop_cont(mb_list, how,
cnt_lst);
713 if (bucket != NULL) {
714 MB_GET_OBJECT(m, bucket, cnt_lst);
715 MB_MBTYPES_INC(cnt_lst, type, 1);
716
(kgdb) l *m_get+0x34
0xc0335354 is in m_get (../../../kern/subr_mbuf.c:1186).
1181struct mbuf *
1182m_get(int how, short type)
1183{
1184struct mbuf *mb;
1185
1186mb = (struct mbuf *)mb_alloc(&mb_list_mbuf, how, type, 0,
NULL);
1187if (mb != NULL)
1188_mb_setup(mb, type);
1189return (mb);
1190}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mb alloc and: panic: mutex Giant not owned at../../../vm/vm_kern.c:315
On Wed, 28 May 2003, David Malone wrote: > On Wed, May 28, 2003 at 10:06:14AM -0400, Robert Watson wrote: > > I haven't seen this panic previously; a lack of Giant coming out of the > > socket code is a bit surprising to me, but I think is unlikely to be a > > result of our local MAC tweaks. > > This may be my fault, as I made some changes recently that assumed that > the mbuf allocator grabbed giant when needed. I'll check the code path > you've mentioned to see if it grabs giant now, but I suspect that I just > need to move the giant grabbing back where it was before. This doesn't seem to be a reproduceable problem for me, FWIW, (presumably a property of bucket sizes, etc) so you have all the information I have :-). If possible, we should get this fix in for 5.1? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |---+-+---+--| | | | | There are reports of | | | | | alignment problems | | ipfw/ipfw2| | | with ipfw and/or | | alignment issues | In progress | Luigi Rizzo | ipfw2 on 64-bit | | on alpha/sparc64 | | | platforms| | | | | (specifically alpha | | | | | and sparc64).| |---+-+---+--| | | | | Kris Kennaway| | | | | reports high | | | | | instability of | | | | | 5.0-CURRENT on ia64 | | ia64 stability| -- | --| machines, such as| | | | | the pluto* machines. | | | | | These problems need | | | | | to be fixed in order | | | | | to get a successful | | | | | package build. | |---+-+---+--| | | | | Brian Feldman has| | | | | submitted patches to | | | | | improve the | | | | | consistency of the | | | | | pathnames passed | | MAC Framework | | | into the MAC | | devfs path fixes | In progress | Robert Watson | Framework devfs | | | | | labeling entry | | | | | points. These| | | | | patches need to be | | | | | thoroughly reviewed | | | | | and tested, then | | | | | merged. | |---+-+---+--| | | | | If a network device | | | | | driver, possibly any | | Panic on | | | driver, is linked| | load/unload a | | | into the kernel and | | kernel module for | Patch | Maxime| then loaded and | | a driver already | approved| Henrion | unloaded as a| | statically linked | | | module, the kernel | | into the kernel. | | | will panic. This has | | | | | been observed with | | | | | both if_dc and | | | | | if_fxp. | |---+-+---+--| | | | | Update the run-time | | rtld-elf | patch | Alexander | link editor (rtld) | | thread-safety | submitted | Kabaev| thread-safe with | | | | | libpthread. | |---+-+---+--| | | | | rpc.lockd(8) | | | | | client-side and | | | | | server-side NFS | | | | | locking appears to
5.2-RELEASE TODO
eeBSD | | | | | tree. | |-+--+-+-| | | | | Port syscons to | | | | | sparc64. Add device | | | | | drivers for sun | | | | | mice and keyboards. | | | | | Allow for more than | | sparc64 adaptation | In | | 3 bits of | | of syscons | progress | Jake Burkholder | background colour | | | | | in syscons. Creator | | | | | frame buffer device | | | | | driver. In the | | | | | process, generally | | | | | improve the MI-ness | | | | | of syscons. | |-+--+-+-| | | | | Many systems| | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | | | | entry overrides the | | ACL_MASK override | In | | umask, rather than | | of umask support in | progress | Robert Watson | being intersected | | UFS | | | with it. The| | | | | resulting semantics | | | | | can be useful in| | | | | group-oriented | | | | | environments, and | | | | | as such would be| | | | | very helpful on | | | | | FreeBSD.| |-+--+-+-| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4 and IPv6) now | | | | | have fine-grained | | | | | locking of their| | | | | data structures.| | | | | However, it is not | | | | | yet possible for| | | | | the netisr threads | | | | | to run without | | | | | Giant, due to | | Fine-grained| | | dependencies on | | network stack | In | Jeffrey Hsu,| sockets, routing, | | locking without | progress | Seigo Tanimura | etc. A 5.2-RELEASE | | Giant | | | goal is to have the | | | | | network stack | | | | | running largely | | | | | without Giant, | | | | | which should| | | | | substantially | | | | | improve performance | | | | | of the stack, as| | | | | well as other | | | | | system components | | | | | by reducing | | | | | contention on | | | | | Giant. | |-+--+-+-| | | | | Move ATA com
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital
Re: 5.1-RELEASE TODO
On Sat, 31 May 2003, Scott Long wrote: > It's been a matter of not having enough time, nothing more. I *will* > address this one way or another before the release. I apologize for > taking so long. Ditto, here, unfortunately. I managed to hose my sparc64 box a couple of weeks ago trying to upgrade it to run precisely these tests, but haven't had time to figure out how to recover it. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital
5.2-RELEASE TODO
| | | | | now.| |-+--+-+-| | | | | Apple's Darwin | | | | | operating system| | | | | has fairly | | | | | extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | -- | -- | msdosfs and other | | fixes | | | kernel services;| | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD | | | | | tree. | |-+--+-+-| | | | | Port syscons to | | | | | sparc64. Add device | | | | | drivers for sun | | | | | mice and keyboards. | | | | | Allow for more than | | sparc64 adaptation | In | | 3 bits of | | of syscons | progress | Jake Burkholder | background colour | | | | | in syscons. Creator | | | | | frame buffer device | | | | | driver. In the | | | | | process, generally | | | | | improve the MI-ness | | | | | of syscons. | |-+--+-+-| | | | | Many systems| | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | | | | entry overrides the | | ACL_MASK override | In | | umask, rather than | | of umask support in | progress | Robert Watson | being intersected | | UFS | | | with it. The| | | | | resulting semantics | | | | | can be useful in| | | | | group-oriented | | | | | environments, and | | | | | as such would be| | | | | very helpful on | | | | | FreeBSD.| |-+--+-+-| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4 and IPv6) now | | | | | have fine-grained | | | | | locking of their| | | | | data structures.| | | | | However, it is not | | | | | yet possible for| | | | | the netisr threads | | | | | to run without | | | | | Giant, due to | | Fine-grained| | | dependencies on | | network stack | In | Jeffrey Hsu,| sockets, routing, | | locking without | progress | Seigo Tanimura | etc. A 5.2-RELEASE | | Giant | | | goal is to have the | | | | | network stack | | | | | running la
Re: Fatal trap on RELENG_5_1 SMP
Could you build your kernel with options DDB and debugging symbols, and when the kernel drops to the debugger on this panic, copy and past the stack trace into an e-mail? Alternatively, or perhaps as well, extract the information with a core. There are some excellent instructions on generating some comprehensive crash reports here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html This looks like it's a NULL pointer dereference, so the question we need to answer is: which pointer? To do that, we'll need to turn that back into a C line number, which will need the kernel with debugging symbols. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 1 Jun 2003, Magnus J wrote: > Hello everyone > > > I'm getting a fatal trap when I do 'shutdown' on an SMP-box that > I did cvsup on RELENG_5_1 yesterday. > 'reboot' works without any problems. > > This is the message: > > Fatal trap 12: page fault while in kernel mode > cpuid=1; lapic.id = 0100 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xe0197d11 > stack pointer = 0x10:0xe0197cec > frame pointer = 0x10:0x8 > 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 = 11 (idle: cpu1) > trap number = 12 > panic: page fault > cpuid=1; lapic.id = 0100 > boot() called on cpu#1 > > > The machine is a 2x933 MHz PIII, Mainboard is Tyan Tiger 230, > 1.5 GB RAM. > > If you need more details, please let me know. > I'm not a member of this mailing list. > > Regards > Magnus > > > _ > Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express > Se mer på: http://se.docs.yahoo.com/info/express/help/index.html > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On Mon, 2 Jun 2003, Daniel C. Sobral wrote: > Actually, I would think it a desirable feature mac support that won't > panic within 24 hours. :-) > > I've given up on mac again. Can't have it if it panics on every daily. > :-( What's the plans for dealing with that? Right now I'm aware of one panic that shows up only if labeled MAC policies are linked to the kernel, rather than loaded as modules during the boot process. Currently, it manifests when multiple applications open sockets listening on the same UDP port, and may relate to multiple delivery of mbufs; this panic does not occur when using the modules, however. I'm still tracking down the details. We corrected the compat/linux/dev/null panic (or at least, eliminated it) -- this turned out to be a bug in UFS2 that can be triggered without the use of MAC. Are there are additional panics you're experiencing? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Bryan Liesner wrote: > Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I > removed atapicam from my kernel config. These patches (now committed?) > panic the system whether I use atapicam or not. With kern_umtx v1.2 > there is no panic at all, with or without atapicam. > > Actually, I think it's cam in general that's causing the panic with > these changes. Bizarre. Sounds like an errant pointer in some other code, and it's just a matter of the memory layout as to what gets stepped on. Alternatively, it might be affected by the insertion of the MTX sysinit event. Perhaps that revision rearranges memory a bit. Anyhow, here are some things you might consider, since this whole thing is so odd. Try merging the addition of the struct mtx declaration from 1.3 into 1.2 and see if you get the same panic. If you don't, try merging the MTX_SYSINIT line and see if that triggers the panic. The other changes probably wouldn't cause disruptive memory rearrangement, so see what happens. If the panics appear with the addition of the variable, it probably is a memory stepping thing and a bug in some other piece of code (unfortunately, probably hard to track down). If it's the addition of the initializer, it's a different class of problem. I have to admit that I'm also fairly baffled: my current reading of the change suggests there won't be a specific bug in umtx, rather, the triggering of symptoms from another bug, but I guess we can only find out with a bit of experimentation. You might also find the problem "disappears" if you remove INVARIANTS, although given that you can reproduce this nicely, I'm reluctant to have you do that for fear the bug will get away and not get fixed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sendmail starts before rpc.statd and rpc.lockd
On Sat, 7 Jun 2003, David Yeske wrote: > Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot > flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C. > NFS access cache time=2 > Starting statd. > Starting lockd. > > It looks like sendmail starts before rpc.lockd and rpc.statd? This will > cause diskless clients to hang? This is a nfs server and diskless > client running 5.1-RELEASE. I'm running rpc.lockd and rpc.statd on the > server and the client. Should rpc.lockd and rpc.statd be started before > sendmail starts? Hmm. It shouldn't cause diskless clients to hang, or at least, doesn't for me. The cause of the error message, however, is exactly as you surmise -- befpre rpc.lockd, calls to flock() on the NFS file system will return an error. Is the hang you're seeing immediately after the "Starting lockd"? If you hit Ctrl-T, does it tell you anything useful? Note that unless you're running 5.x pretty close to the release, pressing Ctrl-T while a process is attempting to grab an NFS-backed file lock will result in a slipped lock and many nasty failure modes. I disabled signal delivery to processes while sleeping on an NFS lock as a workaround until out rpc.lockd addresses the "process aborts the lock request" race, which isn't handled right now. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re Regression: Playing QT files from mplayer stopped working in5.1
On Sun, 8 Jun 2003, Arjan van Leeuwen wrote:
> Indeed, a very dirty but effective fix. Thank you. I'll forward this to
> ports@ and lioux@, who has done all the recent updates on mplayer.
So one interesting question would be: if you ktrace on both 4.x and 5.x,
do both pass in the bad value to close(), or is there something else in
5.x triggering the use of negative file descriptor numbers?
>
> Arjan
>
> On Sunday 08 June 2003 15:06, Ted Lindgreen wrote:
> > > Since a short time (don't know exactly when it happened) it's not
> > > possible anymore to play Quicktime files (.mov) with mplayer on
> > > 5.1-CURRENT. It has to be a change in -CURRENT, I haven't updated
> > > mplayer.
> >
> > I do not have the right fix, but the cause of the problem is
> > that in loader/win32.c at line 2077:
> >
> > 2076 if (v1 > 2)
> > 2077 if (!close(v1a))
> >
> > close is called with a ridiciously large value. In previous
> > FreeBSD releases this appearently did not cause a fatal problem,
> > but since a week or so mplayer aborts on it.
> >
> > A stupid, but effective workaround is not to call close if v1
> > is too large, f.i.:
> >
> > 2072 static int WINAPI expCloseHandle(long v1)
> > 2073 {
> > 2074 dbgprintf("CloseHandle(0x%x) => 1\n", v1);
> > 2075 /* do not close stdin,stdout and stderr */
> > 2076 if (v1 > 2 && v1 < 128)
> > 2077 if (!close(v1))
> > 2078 return 0;
> > 2079 return 1;
> > 2080 }
> >
> > Of course for the real fix one needs to delve deeper into mplayer
> > to find out where the large valued filedescriptor comes from.
> >
> > -- ted
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libthr faults with recent kernel?
Jake Burkholder just posted a patch to freebsd-threads that works around (fixes?) the problem; indeed, it does seem to be a result of the recent LAZY_SWITCH changes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 6 Apr 2003, Munehiro Matsuda wrote: > Hi, > > When ever I try to run application with the new libthr.so.1 with > recent kernel, I get my system falt and just reboots: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xa0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc037f80e > stack pointer = 0x10:0xd202fca0 > frame pointer = 0x10:0xd202fcc8 > 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 = Idle > trap number = 12 > panic: page fault > > > Anybody seen this, or am I the only getting this? > > I'm assuming that, it started after the LAZY_SWITCH commit, > but I can't say for sure. > > Thanks, > 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] > > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sendmail starts before rpc.statd and rpc.lockd
On Sun, 8 Jun 2003, David Yeske wrote: > This is when sendmail is ran from virecover. > > Is this because sendmail is taking redirection, and it needs to flock() > for that? Generally, sendmail uses flock() on the aliases file and related databases to ensure consistency. As far as I know, it's unrelated to redirection. > I think a solution could be to make virecover called later on. Why are > rpc.lockd and rpc.statd not started directly after rpcbind? No idea. Moving virecover later is a possibility; probably the missing piece is that sendmail should depend on rpc.lockd, ordering-wise. Or perhaps, it should depend on late-stage file system bits, and the file system bits don't probably depend with the rpc bits. > Here is some more output. > > Recovering vi editor sessions:Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: > SYSERR(root): > cannot flock(./dfh5913dfn000292, fd=3, type=2, omode=40002, euid=25): Operation not > supported > collect: Cannot write ./dfh5913dfn000292 (bfcommit, uid=25, gid=25): Operation not > supported > cannot flock(./tfh5913dfn000292, fd=5, type=6, omode=40001, euid=25): Operation not > supported > cannot flock(./tfh5913dfn000292, fd=5, type=6, omode=40001, euid=25): Operation not > supported > Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: SYSERR(root): collect: Cannot > write > ./dfh5913dfn000292 (bfcommit, uid=25, gid=25): Operation not supported > Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: SYSERR(root): cannot > flock(./tfh5913dfn000292, fd=5, type=6, omode=40001, euid=25): Operation not > supported > Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: queueup: cannot lock > ./tfh5913dfn000292: > Operation not supported > > Here is what Control-T does > load: 0.20 cmd: sendmail 292 [pause] 0.02u 0.04s 0% 2016k pause, eh? That doesn't sound like it's related the the NFS locking. Note that the errors you get for sendmail due to lack of locking result in a fairly clean exit, not a hang. Hangs are generally associated with DNS. Try a packet sniff? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-RELEASE panic, trace included
If you have the kernel.debug for this kernel, could you send the gdb -k output of: l *in6_pcbbind+0x2a7 l *tcp6_usr_bind+0x19a No need to use the core just yet. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Fri, 13 Jun 2003, Jason Dambrosio wrote: > Apparantly it is related to ipv6 bind(). > > ircd: version hybrid-7-CURRENT > ircd: pid 54524 > ircd: running in background mode from /test/ircd > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xc4 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0254147 > stack pointer = 0x10:0xd53fabec > frame pointer = 0x10:0xd53fac34 > 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 = 54524 (ircd) > kernel: type 12 trap, code=0 > Stopped at in6_pcbbind+0x2a7: movl0xc4(%eax),%edx > db> trace > in6_pcbbind(c2bf3474,c2971ba0,c1507e40,c2971ba0,d53fac88) at in6_pcbbind+0x2a7 > tcp6_usr_bind(c2b4c600,c2971ba0,c1507e40,d53facb8,c01e08b7) at tcp6_usr_bind+0x19a > sobind(c2b4c600,c2971ba0,c1507e40,0,c2b4c600) at sobind+0x23 > kern_bind(c1507e40,f,c2971ba0,c2971ba0,0) at kern_bind+0x87 > bind(c1507e40,d53fad10,c,c018ebab,3) at bind+0x43 > syscall(2f,2f,2f,bfbff9a4,8c600ac) at syscall+0x27a > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (104, FreeBSD ELF32, bind), eip = 0x14217f23, esp = 0xbfbff8fc, ebp = > 0xbfbff9c8 --- > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-RELEASE TODO
| | | | | now.| |-+--+-+-| | | | | Apple's Darwin | | | | | operating system| | | | | has fairly | | | | | extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | -- | -- | msdosfs and other | | fixes | | | kernel services;| | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD | | | | | tree. | |-+--+-+-| | | | | Port syscons to | | | | | sparc64. Add device | | | | | drivers for sun | | | | | mice and keyboards. | | | | | Allow for more than | | sparc64 adaptation | In | | 3 bits of | | of syscons | progress | Jake Burkholder | background colour | | | | | in syscons. Creator | | | | | frame buffer device | | | | | driver. In the | | | | | process, generally | | | | | improve the MI-ness | | | | | of syscons. | |-+--+-+-| | | | | Many systems| | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | | | | entry overrides the | | ACL_MASK override | In | | umask, rather than | | of umask support in | progress | Robert Watson | being intersected | | UFS | | | with it. The| | | | | resulting semantics | | | | | can be useful in| | | | | group-oriented | | | | | environments, and | | | | | as such would be| | | | | very helpful on | | | | | FreeBSD.| |-+--+-+-| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4 and IPv6) now | | | | | have fine-grained | | | | | locking of their| | | | | data structures.| | | | | However, it is not | | | | | yet possible for| | | | | the netisr threads | | | | | to run without | | | | | Giant, due to | | Fine-grained| | | dependencies on | | network stack | In | Jeffrey Hsu,| sockets, routing, | | locking without | progress | Seigo Tanimura | etc. A 5.2-RELEASE | | Giant | | | goal is to have the | | | | | network stack | | | | | running la
tweaks to sysctl integer value parsing (report any problems)
Last night, I committed some tweaks to how sysctl integer value parsing occurs. The motivation for these changes was the outcome of finding the following in my sysctl.conf: kern.maxfiles="4000" Which, to my great sadness, occurred on a box without DDB or remote power. For the uninitiated, until my recent commit, the "4000" would converted to 0, resulting in severely degraded operation (your kernel now exists solely to report that it is out of files after a reboot). Now, sysctl will reject poorly formatted values that will be converted to integers, as well as empty strings in the integer conversion. This means that the following will now generate an error: kern.maxfiles= # previously: 0 kern.maxfiles=5" # previously: 5 I'm not convinced my changes are 100% ideal, so I'm going to be on the lookout for posts saying "my sysctl.conf no longer works!", and perhaps we can refine the approach a bit. On the other hand, I now have only one working foot after my recent foot-shooting exercise, so I'm fairly convinced that some change, even if not this precise change, is necessary :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fdrop_locked() and FILE_LOCK() vs. Giant
On Tue, 17 Jun 2003, Don Lewis wrote: > The FILE_LOCK() implementation uses "pool mutex" under the hood, which > means it should only be used as a leaf level mutex. The fdrop_locked() > code wants to be called with FILE_LOCK() held, but the fdrop_locked() > implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK(). In > addition to violating the proper usage of the "pool mutex", there is > also the potential for a lock order violation. The close() > implementation grabs Giant and eventually calls fdrop(), which calls > FILE_LOCK() immediately before calling fdrop_locked(). If another > caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first, > then the lock order will be reversed when fdrop_locked() grabs Giant. > > It looks like fdrop_locked() should require that Giant be grabbed by the > caller before fdrop_locked() is called. I've also noticed that the file descriptor lock is held over per-object calls to fo_poll(), which currently isn't a big deal for most objects, but may be in the future if we have to grab other locks in order to test the poll status inside the object. I run into this problem with the MAC work because the vnode label is protected by the vnode lock, which is a sleepable lock. We may want to change label locking in the future to avoid this, but in the mean time I get a lot of witness warnings, and using a pool mutex for the fd lock may cause lock order problems if there is more complex locking. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI: LCD
On Wed, 18 Jun 2003, Sebastian Yepes [ESN] wrote: > Any one know how to turn off the screen on a notebook i mean totally > off, Not the dpms > > The problem is that when i close the lid it stays on and produces to > much heat.. > > 5-Current on dell inspiron 8500 (with AML patch) More sucky answers from the sucky answer brigade: if I close my notebook lid, the screen remains powered on. But if I open the lid, the screen powers off until I swap virtual consoles between X and normal consoles. So when I want the screen to turn off, I open and close my notebook twice. :-) There seems to be a message here that syscons and other bits need to learn more about dpms, and that acpi needs to provide the necessary events (and time) to the device tree to allow proper power management (and may not currently do that). This came up a number of times at the dev summit last week. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking problems in IPv6 code
Could you run with debug.witness_ddb and get a stack trace for the warning? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 19 Jun 2003, John-Mark Gurney wrote: > I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings > about mallocing data w/ a lock aquired. > > dmesg output: > malloc() of "64" with the following non-sleepablelocks held: > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > malloc() of "64" with the following non-sleepablelocks held: > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > malloc() of "32" with the following non-sleepablelocks held: > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > malloc() of "64" with the following non-sleepablelocks held: > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > malloc() of "64" with the following non-sleepablelocks held: > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > > If I disable IPv6 in /etc/rc.conf, the above warnings don't appear. > I tried to follow the code path in IPv6's source, but it's s long > that I couldn't find where it might be allocating memory. > > Anyone have any ideas? > > -- > John-Mark GurneyVoice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current kernel Fatal Trap 12
If you have a version of the kernel in question on disk and with debugging symbols, could you attach gdb -k to it and send us the results of: l *0xc01f6212 That will provide a bit more information about where the panic is occuring. This is likely a NULL pointer dereference. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Fri, 20 Jun 2003, Manfred Antar wrote: > For the past week i have not been able to boot with current kernel. > The last kernel that works is from Sat June 14th. > When I build and try and boot a current kernel I get: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x38 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01f6212 > stack pointer = 0x10:0xc04b1e24 > frame pointer = 0x10:0xc04b1e24 > 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 = 0 (swapper) > trap number = 12 > panic: page fault > Uptime: 1s > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x38 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01f6212 > stack pointer = 0x10:0xc04b1cec > frame pointer = 0x10:0xc04b1cec > 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 = 0 (swapper) > trap number = 12 > panic: page fault > Uptime: 1s > > This continues to scroll by many times and I can't get to the debugger. > The machine is i386 SMP dual pentium-pro overdrive processors. > Same thing happens with kernel configured as UNIprocessor. > > > > > == > || [EMAIL PROTECTED] || > || Ph. (415) 681-6235 || > == > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wi driver has WEP issues on both 5.0 and 5.1
I've seen this on my older Wavelan card, but not my more recent PRISM card. If I run with WITNESS compiled in, I don't see it, which suggests a timing issue. This came up at USENIX a couple of times and I know Scott and Warner were discussing potential sources and fixes; Scott noticed there were a lot of card resets in the new code not present previously, so one theory was that we needed a delay for a bit to settle during the reset. I've CC'd Warner and Scott to bug them. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sat, 21 Jun 2003, BSDVault wrote: > A head up about the wi driver in FreeBSD 5.0 and 5.1. I have a netgear > MA-311 card that supports HostAP mode. The issue is that I get a busy bit > error. The exact error starts with the following.. THIS ONLY OCCURS WHEN > WEP IS ENABLED: > > wi0: timeout in wi_seek to fc00/0; last status 800b > > We then move on to : > > wi0: wi_cmd: busy bit won't clear. > > This seems to cycle until the next error: > > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: mgmt. Buffer allocation failed > > Then back through the entire error sequence again. Eventually the box will > freeze as these errors cycle and then free up again when it starts back at > the timeout error. I was hopeful that the new wi driver in 5.1 would > address this problem as I know several persons with Prism chipsets that have > this very same issue on 5.0 and 5.1. > > Please respond directly as I am not on -current mailing list. > > Thanks > > Ray > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: locking problems in IPv6 code
On Sat, 21 Jun 2003, Hiten Pandya wrote: > On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote: > > I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings > > about mallocing data w/ a lock aquired. > > > > dmesg output: > > malloc() of "64" with the following non-sleepablelocks held: > > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > > For what it's worth, these warnings also appear if netisr direct > dispatch is enabled with the fxp(4) driver. These messages occur because our link layer address management code does mallocs with M_WAITOK. We need to teach that code to not wait when called from the interrupt path, and pass back up failure modes, or avoid holding locks while calling it. Probably the former, although the latter is also going to be good from a lock order perspective. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs_getpages: error 13
On Sat, 21 Jun 2003, Kris Kennaway wrote: > I have 3 machines running off of a 5.1-CURRENT NFS server (updated on > June 19), and the 5.1-BETA clients are all getting the following under > load: > > > Jun 20 21:24:35 dalki kernel: nfs_getpages: error 13 > > Jun 20 21:24:35 dalki kernel: vm_fault: pager read error, pid 82331 (cp) > > Any ideas? 13 is EACCES. Were you by any chance replacing or modifying the cp file or one of the shared libraries it relies on in NFS during the accesses? (i.e., installworld) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
On Wed, 25 Jun 2003, Socketd wrote: > I have just installed 5.1 Release on my laptop (6gb harddisk and 60 mb > ram). I only installed the base system + man pages and the port > collection. A little info: / 128M Swap 256M /var 128M /var/tmp 256M > (/tmp is symlinked to this) /home 256M /usr The rest > > I compiled a new kernel, with no support for SCSI, RAID, IPv6 and all > but my USB NIC (also removed a few USB things). I added: options > SC_DISABLE_REBOOT options MAC device pcm > > It compiled fine and I installed it. Now, if I run with this kernel the > system freezes! I can boot, login and run a few commands, but that's it. > There is nothing in the logs, but when I tried ssh'ing to the mashine I > got this before it froze: fork() - Not enough ressources available at > this time > > (or something like that). > > Is there a memory leak somewhere or am I doing something wrong? (I > compiled and installed the kernel with: > make buildkernel KERNCONF=SOCKETD > make installkernel KERNCONF=SOCKETD) > > btw please cc to me as I am not on the list. Sounds like a memory leak to me; it might also be a locking problem. Are you actually running with any MAC policies, or just with the framework? The code most likely to cause a memory leak in the MAC Framework is the label management code, since that's the only code that really does much in the way of memory allocaiton. Try compiling options MAC_DEBUG into your kernel, which causes the MAC Framework to track the number of labels it has allocated/free'd in a series of variables: static unsigned int nmacmbufs, nmaccreds, nmacifnets, nmacbpfdescs, nmacsockets, nmacmounts, nmactemp, nmacvnodes, nmacdevfsdirents, nmacipqs, nmacpipes, nmacprocs; You can inspect them using a series of sysctls in the security.mac.debug tree; I'd be interested to see how those values change as you approach the hang. If you have DDB compiled into the kernel (which you probably will want for debugging this problem), I'd be interested in seeing if you can break into DDB using a console break or serial console break. If so, print out the values of those variables and see if any are through the roof. Also, you might do a ps in DDB and see if processes are blocked on anything in particular. The most likely locking problem is a vnode deadlock; if you can get into DDB, try "show lockedvnods" to see whether any locks are held, etc. If you don't have a serial console set up, you might want to set one up because it will make copying and pasting all this stuff into e-mail a lot easier. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
Just FYI, there are actually some "legitimate" situations in which processes will appear to hang when using MAC. For example, if you have MLS or Biba turned on, and revocation support specifically enabled (not the default), you can see interactive processes appear to hang when they are interacting with a terminal that is not authorized to receive its output. For example, if you change the process labels so that they have access to top secret data, but your terminal label is set so it is only cleared for confidential data, the process can't write to the terminal. Given that you don't appear to have any policies loaded, that's presumably not what is going on. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-Release freezes
On Thu, 26 Jun 2003, Socketd wrote: > On Wed, 25 Jun 2003 16:44:56 -0400 (EDT) > Robert Watson <[EMAIL PROTECTED]> wrote: > > > The code most likely to cause a memory leak in the MAC Framework is > > the label management code, since that's the only code that really does > > much in the way of memory allocaiton. Try compiling options MAC_DEBUG > > into your kernel, which causes the MAC Framework to track the number > > of labels it has allocated/free'd in a series of variables: > > > > static unsigned int nmacmbufs, nmaccreds, nmacifnets, nmacbpfdescs, > > nmacsockets, nmacmounts, nmactemp, nmacvnodes, nmacdevfsdirents, > > nmacipqs, nmacpipes, nmacprocs; > > After running a few commands, ssh logins and loading mac_seeotheruids we > now have: <...> > Loading mac_seeotheruids made vnodes increase a little, but it has (very > slowly) been increasing and as you can see is now at 524 (don't know if > this means anything). You can compare the number of labeled vnodes with the number of actual vnodes by looking at the vfs.numvnodes sysctl value -- ideally they should be the same. The fact that the problem went away with the addition of the debugging code is a little concerning. Here's what I'd like you to try, if you can: set up a serial console to another machine. Compile the kernel with options DDB, but without options MAC_DEBUG. Do whatever it is you do that triggers the hang. On the serial console, send a serial break and see if you can get into DDB. If you can, send the output of the following commands: ps show lockedvnods I may then ask you to run the trace command on various processes/threads, and use "show locks" to show which threads hold which locks (assuming you have WITNESS in the kernel, which also changes the timing). On the whole, enabling MAC doesn't substantially change the locking, but there are a couple of edge cases where we grab locks that were not previously grabbed. For example, we now grab vnode locks when polling a vnode so we can do a label check on the vnode; this generates WITNESS warnings as we hold the file descriptor lock over the call to VOP_POLL() (ouch). If we wend up concluding this is a locking problem, it might be that I send you some patches to modify the locking and see if we can get rid of the problem. thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1 NFS locking problems
On Fri, 27 Jun 2003, Mark Hannon wrote: > I have two 5.1-RELEASE boxes with an NFS locking problem. One box is > the NFS server and the other the client. When attempting to login via > gdm I get: > > messages:Jun 27 18:09:07 tbird gconfd (mark-2316): Failed to get lock > for daemon, exiting: Failed to lock '/home/mark/.gconfd/lock/ior': > probably another process has the lock, or your operating system has NFS > file locking misconfigured (Resource temporarily unavailable) > > rpc.statd and rpc.lockd are running on both the server and client. > > Any ideas how to trace? The first thing I'd probably do is ktrace gdm (make sure to use the descend flag) and see what the system call and arguments are that generate this error. Generally, locks are asserted using one of the following system calls: open() with a lock flag, flock(), or fcntl(). Grep the ktrace output looking for the return of EAGAIN. Off the top of my head, the most likely source of EAGAIN is open() with the O_NONBLOCK flag set, which indicates that the caller doesn't want to wait for the lock to become available if the lock is contended. In which ase it sounds like it's an application "feature" (hence the message reading "probably another process has the lock...", which sounds right). You can use: http://www.watson.org/~robert/freebsd/locktest.c to test lock contention and servicing; it's basically a wrapper around open() and flock() so you can easily specify various cases, sock as O_NONBLOCK, etc, to try to reproduce the exact arguments and flags you see in the ktrace. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: something wrong with fxp driver ?
You might compare the dmesg output from before/after and see if there are
any obvious changes in IRQ allocation, shared interrupts, etc. Perhaps
the changes in interrupt routing have resulted in some new behavior.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Fri, 27 Jun 2003, Ying-Chieh Liao wrote:
> my previous kernel is about May 10, and the fxp works fine for me
> but I cvsuped and make world/kernel yesterday (6/26), and then terrible thing
> happens... the connection becomes v...e...r...y... s...l...o...w...
> my ping time to the gateway is about 8000ms (but sometimes 20ms)
>
> I've browse the mail archive of -current and -net, and I've noticed some
> similar problems with fxp (device timeout), and I also get this message
> (fxp0 device timeout) in my dmesg output, but I cant find out any solution :<
> Is there any workaround, or patches ?
> --
> char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> -- Anonymous
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-RELEASE TODO
| | | | | now.| |-+--+-+-| | | | | Apple's Darwin | | | | | operating system| | | | | has fairly | | | | | extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | -- | -- | msdosfs and other | | fixes | | | kernel services;| | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD | | | | | tree. | |-+--+-+-| | | | | Port syscons to | | | | | sparc64. Add device | | | | | drivers for sun | | | | | mice and keyboards. | | | | | Allow for more than | | sparc64 adaptation | In | | 3 bits of | | of syscons | progress | Jake Burkholder | background colour | | | | | in syscons. Creator | | | | | frame buffer device | | | | | driver. In the | | | | | process, generally | | | | | improve the MI-ness | | | | | of syscons. | |-+--+-+-| | | | | Many systems| | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | | | | entry overrides the | | ACL_MASK override | In | | umask, rather than | | of umask support in | progress | Robert Watson | being intersected | | UFS | | | with it. The| | | | | resulting semantics | | | | | can be useful in| | | | | group-oriented | | | | | environments, and | | | | | as such would be| | | | | very helpful on | | | | | FreeBSD.| |-+--+-+-| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4 and IPv6) now | | | | | have fine-grained | | | | | locking of their| | | | | data structures.| | | | | However, it is not | | | | | yet possible for| | | | | the netisr threads | | | | | to run without | | | | | Giant, due to | | Fine-grained| | | dependencies on | | network stack | In | Jeffrey Hsu,| sockets, routing, | | locking without | progress | Seigo Tanimura | etc. A 5.2-RELEASE | | Giant | | | goal is to have the | | | | | network stack | | | | | running la
Re: 5.2-RELEASE TODO
On Sun, 29 Jun 2003, David Taylor wrote: > On Sun, 29 Jun 2003, Robert Watson wrote: > > ++ > > |Issue| Status | Responsible | Description | > > |-+--+-+-| > ^^^ > > I don't suppose it would be possible to delete a couple of those leading > spaces on each line? > > Although it fits into an 80-column display in vim/cat/whatever, mutt > ends up wrapping it, and making it very ugly, but removing a couple of > the spaces would make it fit fine. The way these are currently produced is to check out the web tree, build the HTML for the todo lists/etc, render them with links, dump to text, trim the unnecessary headers and footers, and spit them into a form e-mail. I can trim the leading spaces easily enough using sed; most other properties of the rendering are up to links and therefore hard to adjust. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On Mon, 30 Jun 2003, Tim Robbins wrote: > This has already been fixed. Great, I'll update the list, thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: timeseal program doesn't work with FreeBSD-5.1
On Mon, 30 Jun 2003, Juan Francisco Rodriguez Hervella wrote: > bash: ./timeseal.FreeBSD: cannot execute binary file > > "ldd" shows this: > > ldd: timeseal.FreeBSD: not a dynamic executable Try running the file command on the binary to see what kind of file it is. If the program is an old i386 a.out binary, you could try rebuilding your kernel with "options COMPAT_AOUT", and make sure the compat libs are installed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VMWare not working anymore
Did you rebuild the Vmware kernel module(s) from scratch? Make sure you do so each time you update to a newer kernel version, as it's important the data structures referenced by the module be the same version as the ones referenced by the kernel you're running. I've seen precisely this output when my kernel module has been out of sync, previously. If it's in sync, well, I guess it's a different problem :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 30 Jun 2003, Eirik Oeverby wrote: > Hi, > > As of yesterday (I think), VMWare 3.2.1 is no longer working on my > 5-CURRENT box. When I try to start it, I get > > = > [EMAIL PROTECTED] ~$ vmware > Setting TMPDIR=/var/tmp. > > > VMware Workstation Err > > VMware Workstation Error: > Version mismatch with vmmon module: expecting 30.0, got 0.0. > You have an incorrect version of the `vmmon' kernel module. > Try reinstalling VMware Workstation. > > Press "Enter" to continue... > > > > ^C > = > > A ps shows some parts are still running: > > [EMAIL PROTECTED] ~$ ps ax | grep vmw > 652 p1 W 0:00.10 vmware-ui -A 7 -B 4 -S -L > /var/tmp/vmware-ltning-651. > 653 p1 W 0:00.08 vmware-mks -A 8 -B > 5 -S -L /var/tmp/vmware-ltning-651 663 p1 S+ 0:00.01 grep vmw > = > > And kldstat shows the vmmon module(s) are indeed loaded: > > [EMAIL PROTECTED] ~$ kldstat > Id Refs AddressSize Name > 1 16 0xc010 3f5758 kernel > 21 0xc04f6000 4930cacpi.ko > 31 0xc406c000 5000 linprocfs.ko > 43 0xc42a2000 18000linux.ko > 51 0xc41f5000 8000 vmmon_up.ko > 61 0xc41f1000 2000 vmnet.ko > 74 0xc437a000 11000netgraph.ko > 82 0xc42be000 4000 ng_ether.ko > 91 0xc4361000 5000 ng_bridge.ko > 101 0xc42ba000 4000 ng_socket.ko > = > > Anyone else seeing this? Anyone have an idea how to solve it? This is > pretty bad, as I've just managed to get rid of my last Windows > workstation, which I only used to run a development SQLServer. Guess > where that DBMS (should be/is) running now.. :-/ > > > /Eirik > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-RELEASE TODO
arwin | | | | | operating system| | | | | has fairly | | | | | extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | -- | -- | msdosfs and other | | fixes | | | kernel services;| | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD | | | | | tree. | |-+--+-+-| | | | | Port syscons to | | | | | sparc64. Add device | | | | | drivers for sun | | | | | mice and keyboards. | | | | | Allow for more than | | sparc64 adaptation | In | | 3 bits of | | of syscons | progress | Jake Burkholder | background colour | | | | | in syscons. Creator | | | | | frame buffer device | | | | | driver. In the | | | | | process, generally | | | | | improve the MI-ness | | | | | of syscons. | |-+--+-+-| | | | | Many systems| | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | | | | entry overrides the | | ACL_MASK override | In | | umask, rather than | | of umask support in | progress | Robert Watson | being intersected | | UFS | | | with it. The| | | | | resulting semantics | | | | | can be useful in| | | | | group-oriented | | | | | environments, and | | | | | as such would be| | | | | very helpful on | | | | | FreeBSD.| |-+--+-+-| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4 and IPv6) now | | | | | have fine-grained | | | | | locking of their| | | | | data structures.| | | | | However, it is not | | | | | yet possible for| | | | | the netisr threads | | | | | to run without | | | | | Giant, due to | | Fine-grained| | | dependencies on | | network stack | In | Jeffrey Hsu,| sockets, routing, | | locking without | progress | Seigo Tanimura | etc. A 5.2-RELEASE | | Giant | | | goal is to have the | | | | | network stack | | | | | running largely | | | | | without Giant, | | | | | which should| | | | | substantially | | | | | improve performance | | | | | of the stac
Re: Experiences with ath(4)
On Sat, 5 Jul 2003, Lukas Ertl wrote: > > The ADSL router (a Speedtouch 510) does NAT. Everything seems to work > > fine, but after some time, all connections from the WLAN client to the > > outside world have died. I can connect to the other hosts in the LAN just > > fine, though, and there are no further messages in the log files. > > The quickest way to make it work again, is pulling the card out and plug > > it back it. Any ideas? > > Ok, I've investigated this further. The strange thing is: whenever the > connections to the outside drop, I can ping and connect to any host in > my LAN (10.0.0.0/24), but I _cannot_ ping 10.0.0.138 from the WLAN > client, which is the inside interface of the ADSL router and thus the > default route. I can't explain why. "ifconfig ath0 down && ifconfig ath0 > up" solves this lock-up. Could this be a driver bug? Just to check: you're not using multiple NATs in this configuration, right? I've noticed terrible TCP and general networking interactions when I layer a Linksys wireless router NAT behind a SpeedStream DSL modem that was also doing NAT -- TCP connections frequently stall, disconnect, etc. Using the Linksys router to bridge the wired and wireless networks, and avoiding network address translation, really made a difference. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-RELEASE TODO
arwin | | | | | operating system| | | | | has fairly | | | | | extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | -- | -- | msdosfs and other | | fixes | | | kernel services;| | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD | | | | | tree. | |-+--+-+-| | | | | Port syscons to | | | | | sparc64. Add device | | | | | drivers for sun | | | | | mice and keyboards. | | | | | Allow for more than | | sparc64 adaptation | In | | 3 bits of | | of syscons | progress | Jake Burkholder | background colour | | | | | in syscons. Creator | | | | | frame buffer device | | | | | driver. In the | | | | | process, generally | | | | | improve the MI-ness | | | | | of syscons. | |-+--+-+-| | | | | Many systems| | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | | | | entry overrides the | | ACL_MASK override | In | | umask, rather than | | of umask support in | progress | Robert Watson | being intersected | | UFS | | | with it. The| | | | | resulting semantics | | | | | can be useful in| | | | | group-oriented | | | | | environments, and | | | | | as such would be| | | | | very helpful on | | | | | FreeBSD.| |-+--+-+-| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4 and IPv6) now | | | | | have fine-grained | | | | | locking of their| | | | | data structures.| | | | | However, it is not | | | | | yet possible for| | | | | the netisr threads | | | | | to run without | | | | | Giant, due to | | Fine-grained| | | dependencies on | | network stack | In | Jeffrey Hsu,| sockets, routing, | | locking without | progress | Seigo Tanimura | etc. A 5.2-RELEASE | | Giant | | | goal is to have the | | | | | network stack | | | | | running largely | | | | | without Giant, | | | | | which should| | | | | substantially | | | | | improve performance | | | | | of the stac
Re: looking for warn quota tools
I always just used the following script in the /etc/csh.login:
#if ("`quota | grep '\*'`" != "") then
# echo Warning: Quota Exceeded:
# quota
#endif
Given that the output of the quota command is fairly parseable, a little
bit of scripting or perl should do the trick.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Tue, 11 Jun 2002, Paul S. Puth wrote:
> Hi,
>
> I am looking for a tool that will email to the user if his/her account
> (more specifically email box) is approaching quota limit. I've searched
> everywhere for such a tool but to no avail.
>
> On Linux, there is a tool called "warnquota" that fits my need but I am
> running FreeBSD 4.5 -RELEASE so I can't utilize that tool. Also, from
> searching on google, I've found a tool called "psntools" that has the
> warnquota feature but it doesn't work on a filesystem that has a mailspool.
>
> Can someone help me?
>
> Thanks,
>
> Paul
>
>
> 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: Syscalls.master broken on -CURRENT?
On Sat, 15 Jun 2002, walt wrote: > > During the compilation of usr.bin/truss this error stops world: > > > > syscalls.master: line 55: syscall number out of sync at 7 > > line is: > > struct rusage * rusage ) ; } wait4 wait_args int > > > > The error is actually produced by the execution of > > '/usr/src/sys/kern/makesyscalls.sh syscalls.master' > > > > What I don't understand is why this same error breaks world > > on one of my -CURRENT machines but not on the other machine... > > Try this: > > # cd /usr/src/usr.bin/truss > # make clean > # make > > I think you will see the error appear. s/appear/disappear/? It basically looks like the generated include files aren't in sync, but it's not something I can reproduce locally. Lots of make cleaning and make includes should clear this up. If it doesn't, let me know, and I'll do more chasing. 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: Zsh dumps core after cap_get_proc() removal
On Sun, 16 Jun 2002, Munehiro Matsuda wrote: > Hello Robert Watson, > > After removal of cap_get_proc() and friends from libc, zsh from the ports > started to dump core: > > > #0 0x28172333 in __sys___cap_get_proc () from /usr/lib/libc.so.5 > (gdb) where > #0 0x28172333 in __sys___cap_get_proc () from /usr/lib/libc.so.5 > #1 0x2816003e in cap_get_proc () from /usr/lib/libc.so.5 > #2 0x280ca331 in privasserted () from /usr/local/lib/zsh/libzsh-4.0.4.so > #3 0x28080099 in evalcond () from /usr/local/lib/zsh/libzsh-4.0.4.so > #4 0x2807e5d7 in bin_test () from /usr/local/lib/zsh/libzsh-4.0.4.so > > I had to manually disable HAVE_CAP_GET_PROC in config.h for zsh. > > Can't we have some kind of HEADS-UP or version-bump for this matter. __cap_get_proc() has always returned ENOSYS in the base system (indicating that it was not implemented), as we never committed the implementation of the system call. It looks like your binary is picking up cap_get_proc() from libc, which suggests your libc isn't in sync with the source tree, since libc no longer contains cap_get_proc(). It may be that zsh's autoconf picked up on the library calls (now removed), and built in a dependency on them. You might need to rebuild zsh to work around this once libc is rebuilt. 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: Zsh dumps core after cap_get_proc() removal
FWIW, it looks like privasserted() in zsh might be (and this is without reading the source) some attempt to reproduce the issetugid() functionality. It should just invoke that call rather than rolling its own, if so -- the TrustedBSD cap implementation update the issetugid() flag to reflect capability privileges. 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: HEADSUP: UFS2 patch coming...
On Thu, 20 Jun 2002, Greg 'groggy' Lehey wrote: > On Wednesday, 19 June 2002 at 10:07:29 +0200, Poul-Henning Kamp wrote: > > > > Kirk is loading and aiming is committatron with the UFS2 patch, > > expect to see it hit -current any day soon. > > Any details of what it will contain? Per previous e-mails to -current and -arch, this first stage of the process essentially consists of rolling the on-disk inode format to include 64-bit pointers, extent information, and extended attribute information. Almost every other change in there is to support the UFS1/2 split, and moving to the larger sizes. The actual EA implementation, extent behavior, etc, will not operate until future commits are in the tree. 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
Bootstrap problems for asm
I'm attempting to build a modern world on a box from about a month ago (specifically, the head of the trustedbsd_mac branch, which I'd like to integ), and keep bumping into problems associated with the compiler upgrade. What's odd is that it seems to me that at the point where the build breaks, it seems to me I should actually be using the compiler that was built as part of the tree (i.e., post build-tools). Anyone got any suggestions? Boot-strapping forward on -CURRENT is actually a useful thing to be able to do :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ===> libexec/smrsh cc -pipe -I/cboss/freebsd/commit/src/libexec/smrsh/../../contrib/sendmail/src -I/cboss/freebsd/commit/src/libexec/smrsh/../../contrib/sendmail/include -I.-Wformat=2 -Wno-format-extra-args -c /cboss/freebsd/commit/src/contrib/sendmail/smrsh/smrsh.c cc -pipe -I/cboss/freebsd/commit/src/libexec/smrsh/../../contrib/sendmail/src -I/cboss/freebsd/commit/src/libexec/smrsh/../../contrib/sendmail/include -I.-Wformat=2 -Wno-format-extra-args-o smrsh smrsh.o /cboss/devel/obj/freebsd/commit/src/libexec/smrsh/../../lib/libsm/libsm.a gzip -cn /cboss/freebsd/commit/src/libexec/smrsh/../../contrib/sendmail/smrsh/smrsh.8 > smrsh.8.gz ===> libexec/rtld-elf cc -pipe -Wall -DFREEBSD_ELF -I/cboss/freebsd/commit/src/libexec/rtld-elf/i386 -I/cboss/freebsd/commit/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=2 -Wno-format-extra-args -c /cboss/freebsd/commit/src/libexec/rtld-elf/i386/rtld_start.S cc -pipe -Wall -DFREEBSD_ELF -I/cboss/freebsd/commit/src/libexec/rtld-elf/i386 -I/cboss/freebsd/commit/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=2 -Wno-format-extra-args -c /cboss/freebsd/commit/src/libexec/rtld-elf/rtld.c /cboss/freebsd/commit/src/libexec/rtld-elf/rtld.c: In function `atomic_decr_int': /cboss/freebsd/commit/src/libexec/rtld-elf/i386/rtld_machdep.h:58: inconsistent operand constraints in an `asm' *** Error code 1 Stop in /cboss/freebsd/commit/src/libexec/rtld-elf. *** Error code 1 Stop in /cboss/freebsd/commit/src/libexec. *** Error code 1 Stop in /cboss/freebsd/commit/src. *** Error code 1 Stop in /cboss/freebsd/commit/src. *** Error code 1 Stop in /cboss/freebsd/commit/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrap problems for asm
On Mon, 24 Jun 2002, John Polstra wrote: > > /cboss/freebsd/commit/src/libexec/rtld-elf/rtld.c: In function > > `atomic_decr_int': > > /cboss/freebsd/commit/src/libexec/rtld-elf/i386/rtld_machdep.h:58: > > inconsistent operand constraints in an `asm' > > *** Error code 1 > > There is a problem at the moment in compiling that file without -O. Is > your /etc/make.conf standard, or did you specifically ask for no > optimization? I haven't made any explicit changes to the optimization level; on the other hand, perhaps that should be CFLAGS+=? Here's my make.conf: CFLAGS=-pipe NOPROFILE= yes NO_WERROR=yes NO_PERL=yes 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: Bootstrap problems for asm
On Mon, 24 Jun 2002, John Polstra wrote: > > > There is a problem at the moment in compiling that file without -O. Is > > > your /etc/make.conf standard, or did you specifically ask for no > > > optimization? > > > > I haven't made any explicit changes to the optimization level; on the > > other hand, perhaps that should be CFLAGS+=? > > > > Here's my make.conf: > > > > CFLAGS=-pipe > > NOPROFILE= yes > > NO_WERROR=yes > > NO_PERL=yes > > That's the problem. The default CFLAGS setting in > /etc/defaults/make.conf is "-O -pipe". You have eliminated the "-O". Do you mind if I add an entry to UPDATING: 20020624: Building the real time loader (rtld) currently requires optimization to be enabled for the build. If you override CFLAGS in make.conf, make sure that -O is included in in your definition of the variable, or you may get assembler errors compiling rtld. ? 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: Bootstrap problems for asm
s/real-time/run-time/ s/rwatson/rmoron/ :-) (Thanks to Scott Long for pointing this out) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 24 Jun 2002, Robert Watson wrote: > > On Mon, 24 Jun 2002, John Polstra wrote: > > > > > There is a problem at the moment in compiling that file without -O. Is > > > > your /etc/make.conf standard, or did you specifically ask for no > > > > optimization? > > > > > > I haven't made any explicit changes to the optimization level; on the > > > other hand, perhaps that should be CFLAGS+=? > > > > > > Here's my make.conf: > > > > > > CFLAGS=-pipe > > > NOPROFILE= yes > > > NO_WERROR=yes > > > NO_PERL=yes > > > > That's the problem. The default CFLAGS setting in > > /etc/defaults/make.conf is "-O -pipe". You have eliminated the "-O". > > Do you mind if I add an entry to UPDATING: > > 20020624: > Building the real time loader (rtld) currently requires optimization > to be enabled for the build. If you override CFLAGS in make.conf, > make sure that -O is included in in your definition of the variable, > or you may get assembler errors compiling rtld. > > ? > > 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Error in truss (Was: Re: error in ncurses in 'make buildworld')
Compile and install a fresh sed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 24 Jun 2002, Johan Granlund wrote: > Hi > > I'ts probably not related, but i have problems :) > > I have tried a couple of days to compile world, with CFLAGS=-O -pipe, with > a system from Jun 16 and it stops at the same place every time. I have > tried to clean out /usr/src and obj and resup. Recompiled awk and sh if > something happened to them but no change. > > Any ideas as what happened ? > > The error is: > > ===> usr.bin/truncate > rm -f .depend > mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c > echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend > ===> usr.bin/truss > cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master > /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh > syscalls.master / > usr/src/usr.bin/truss/i386.conf > syscalls.master: line 55: syscall number out of sync at 7 > line is: > struct rusage * rusage ) ; } wait4 > wait_args int > *** Error code 1 > > Stop in /usr/src/usr.bin/truss. > *** Error code 1 > > > Regards > > /Johan > > > On Mon, 24 Jun 2002, Claus Guttesen wrote: > > > Hi. > > > > > What -O level did you compile libc with? > > > Optimisation levels >= 2 damage > > > __vfprintf() with the in-tree gcc, causing these > > > same symptoms. > > > > > > The fix is to remove any optimisation options above > > > -O, go into > > > /usr/src/lib/libc, rebuild and install the static > > > libc.a, build and install a > > > static linked awk binary, then rebuild world + > > > kernel as usual. > > > > > > > With this advise my 'make world' and 'make kernel' > > completed without any errors. Thank you. > > > > Regards > > Claus > > > > > > _ > > Følg VM i fodbold på tæt hold fra Yahoo!s officielle VM-side > > www.yahoo.dk/vm2002 > > > > 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: KSE M-III status & junior hacker project.
On Tue, 9 Jul 2002, John Baldwin wrote: > > If anyone knows of something that was broken by the KSE commit, > > (i.e. it worked just before and not after) and is STILL > > broken please let me know because I think I can pretty much declare that > > chapter finished, and I'd like to get on with "extending" KSE > > functionality. This will be the start of Milestone IV, which would be > > add support for threads to run on multiple processors. > > Coincident with that some work should also proceed on gradually > > identifying and cleaning up places in the kernel where multithreading > > is just not ready.. e.g. which thread status do you get when you type ^T? > > I would like it if you would make KSE-3 work on other architectures now > rather than adding more functionality that only works on i386. This > would serve to validate the design decisions made thus far before a > whole lot of code depends on those design decisions making it easier to > make changes if need be. I have to admit I got a bit nervous about the KSE work on learning that the existing fork-like approach was not compatible with several of our new (or existing) target architectures; my impression was Julian and Doug had hashed out a good solution to the problem at the dev summit last month, however. I agree that getting at least one non-i386 platform working at this point is really an important priority, since we really don't want to bump into any more such problems. Also, since we're now getting to the point where userland work is feasible, I think it's important that we start to congeal a bit more on the multi-platform aware interface to avoid building in assumptions that will be broken later resulting in a lot more work. Julian--following your conversation/design session with Doug, how long do you think it would take to get i386 moved over to the revised design, and then assuming you and someone infinitely familiar with the target platform sat down together, how long would it take to bootstrap at least one more platform to work with KSE? I tend to agree with John that this is an important thing to have happen before we get too much more featureful. To make an additional platform happen (say, Alpha or Sparc64), what would it take in terms of expertise you don't have -- just someone familiar with the architecture's context management and kernel trap code? I.e., a day or two of Doug's, Jake's, or Peter's time? 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
HEADS UP: TrustedBSD MAC supporting going into the 5.0 HEAD
I've just committed some of the supporting infrastructure files to the main kernel tree. Right now, not much is hooked up to the build, but over the next couple of hours, I'll start to hook things up. If you catch the tree at a poor moment during the commit process, it probably won't build very well, and if it does, you may be very sorry. Hopefully not too sorry, since almost all the MAC code is conditionally compiled based on "options MAC" and therefore this shouldn't have much if any impact for GENERIC, but the risk exists. I'll send out a follow-up message when I'm done merging. 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: HEADS UP: TrustedBSD MAC supporting going into the 5.0 HEAD
Ok, well, I committed the following:
- include files (mac.h, mac_policy.h)
- basic MAC framework (kern_mac.c)
- label management for several key types of system objects, including
mbufs, creds, vnodes, mountpoints, sockets
I'll start up again tomorrow morning and bring in:
- management for more network objects
- management for pipes
- access control for managed objects
I'll also bring in several sample policies, including:
- mac_mls, mac_biba, mac_seeotheruids, mac_bsdextended (uid/gid-based file
system firewall)
Finally, I'll start on the userland code:
- libc MAC extensions
- libugidfw
- userland tools such as ugidfw, {get,set}[fp]mac(8), setusercontext
extensions
I believe that the system currently builds, but I haven't finished a
buildworld with the current set of patches. Certainly all the compile
tests I've been doing seem OK. If there is build breakage in userland,
it's probably because of header leakage from including kernel headers.
In any case, will get started again first thing tomorrow morning.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Tue, 30 Jul 2002, Robert Watson wrote:
>
> I've just committed some of the supporting infrastructure files to the
> main kernel tree. Right now, not much is hooked up to the build, but over
> the next couple of hours, I'll start to hook things up. If you catch the
> tree at a poor moment during the commit process, it probably won't build
> very well, and if it does, you may be very sorry. Hopefully not too
> sorry, since almost all the MAC code is conditionally compiled based on
> "options MAC" and therefore this shouldn't have much if any impact for
> GENERIC, but the risk exists. I'll send out a follow-up message when I'm
> done merging.
>
> 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
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sendfile(2) is broken (Was: ftpd problem: Input/output error)
On Sun, 11 Aug 2002, Maxim Konovalov wrote: > This is sendfile(2) mis-behaviour arised after rev.1.109 > sys/kern/uipc_syscalls.c but I think the real problem in vn_rdwr(), > sys/kern/vfs_vnops.c. Here is my patch but I really need somebody with > vfs clue. I CC'ed Robert Watson as an author of sendfile(2) > modification and our vfs expert. Semen Ustimenko <[EMAIL PROTECTED]> ran into a similar problem, but his fix was to teach sendfile() to pass in a non-NULL resid and handle the failure mode better. I suspect this fix is more correct since it will both handle the failure mode and the data delivered, and probably is required for other consumers of vn_rdwr(). He was going to run the patch past dg, and then commit it assuming dg approved it, so hopefully it will go into the tree in the next day or so. 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: panic: system call accept returning with mutex(s) held
Hmm. This could be my bug due to mixing up a -stable and a -current
patch. I modified accept() to reject negative sockaddr name lengths, but
it looks like I botched the return path:
if (uap->name) {
error = copyin(uap->anamelen, &namelen, sizeof (namelen));
if(error)
goto done2;
if (namelen < 0)
return (EINVAL);
}
Try turning that 'return (EINVAL);' into a 'goto done2;' and see if that
helps.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Thu, 15 Aug 2002, Mike Heffner wrote:
> With -current from earlier this week, panics whenever I start
> gaim. Didn't see anything similar in the archives. I'll be happy to
> provide more information if needed.
>
> Mounting root from ufs:/dev/ad0s2a
> exclusive sleep mutex Giant r = 0 (0xc02da9a0) locked @ ../../../kern/subr_trap.c:80
> panic: system call accept returning with mutex(s) held
>
>
> syncing disks... panic: bremfree: bp 0xc3c32ee4 not locked
> Uptime: 3m18s
> pfs_vncache_unload(): 1 entries remaining
> Dumping 127 MB
> ata0: resetting devices ..
> done
> 16 32 48 64 80 96 112
> ---
> #0 doadump () at ../../../kern/kern_shutdown.c:213
> 213 dumping++;
> (kgdb) bt
> #0 doadump () at ../../../kern/kern_shutdown.c:213
> #1 0xc01aaa86 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
> #2 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
> #3 0xc01dfc47 in bremfree (bp=0xc02b0f05) at ../../../kern/vfs_bio.c:633
> #4 0xc01e1668 in vfs_bio_awrite (bp=0xc1525840) at ../../../kern/vfs_bio.c:1627
> #5 0xc022e991 in ffs_fsync (ap=0xc8e7bc1c) at ../../../ufs/ffs/ffs_vnops.c:231
> #6 0xc022df8e in ffs_sync (mp=0xc1471400, waitfor=2, cred=0xc0babe00, td=0xc02d6480)
> at vnode_if.h:545
> #7 0xc01f162c in sync (td=0xc02d6480, uap=0x0) at ../../../kern/vfs_syscalls.c:129
> #8 0xc01aa6a2 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
> #9 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
> #10 0xc027d8a2 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135554112, tf_esi = 135604464,
>tf_ebp = -1077940868, tf_isp = -924336780, tf_ebx = 673945180, tf_edx = 1, tf_ecx =
>0, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 676290179, tf_cs = 31, tf_eflags
>= 663, tf_esp = -1077941024, tf_ss = 47}) at ../../../i386/i386/trap.c:1120
> #11 0xc026e76d in Xint0x80_syscall () at {standard input}:140
>
>
> FreeBSD 5.0-CURRENT #1: Wed Aug 14 12:19:54 EDT 2002
> [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SATELLIT
> E
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc03ff000.
> Preloaded elf module "/boot/kernel/random.ko" at 0xc03ff0a8.
> Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03ff154.
> Timecounter "i8254" frequency 1193182 Hz
> Timecounter "TSC" frequency 746339059 Hz
> CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0x686 Stepping = 6
> Features=0x383f9ff T,PSE36,MMX,FXSR,SSE>
> real memory = 134086656 (130944K bytes)
> avail memory = 125779968 (122832K bytes)
>
>
> Mike
>
> --
>
> Mike Heffner
> <[EMAIL PROTECTED]>
>
>
> 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: system call accept returning with mutex(s) held
Actually, I've gone ahead and committed the change, update to
uipc_syscalls.c:1.128 and see if the problem goes away. (if you do it by
hand locally, make sure to assign error = EINVAL before jumping).
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
On Thu, 15 Aug 2002, Robert Watson wrote:
>
> Hmm. This could be my bug due to mixing up a -stable and a -current
> patch. I modified accept() to reject negative sockaddr name lengths, but
> it looks like I botched the return path:
>
> if (uap->name) {
> error = copyin(uap->anamelen, &namelen, sizeof (namelen));
> if(error)
> goto done2;
> if (namelen < 0)
> return (EINVAL);
> }
>
> Try turning that 'return (EINVAL);' into a 'goto done2;' and see if that
> helps.
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> [EMAIL PROTECTED] Network Associates Laboratories
>
> On Thu, 15 Aug 2002, Mike Heffner wrote:
>
> > With -current from earlier this week, panics whenever I start
> > gaim. Didn't see anything similar in the archives. I'll be happy to
> > provide more information if needed.
> >
> > Mounting root from ufs:/dev/ad0s2a
> > exclusive sleep mutex Giant r = 0 (0xc02da9a0) locked @
>../../../kern/subr_trap.c:80
> > panic: system call accept returning with mutex(s) held
> >
> >
> > syncing disks... panic: bremfree: bp 0xc3c32ee4 not locked
> > Uptime: 3m18s
> > pfs_vncache_unload(): 1 entries remaining
> > Dumping 127 MB
> > ata0: resetting devices ..
> > done
> > 16 32 48 64 80 96 112
> > ---
> > #0 doadump () at ../../../kern/kern_shutdown.c:213
> > 213 dumping++;
> > (kgdb) bt
> > #0 doadump () at ../../../kern/kern_shutdown.c:213
> > #1 0xc01aaa86 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
> > #2 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
> > #3 0xc01dfc47 in bremfree (bp=0xc02b0f05) at ../../../kern/vfs_bio.c:633
> > #4 0xc01e1668 in vfs_bio_awrite (bp=0xc1525840) at ../../../kern/vfs_bio.c:1627
> > #5 0xc022e991 in ffs_fsync (ap=0xc8e7bc1c) at ../../../ufs/ffs/ffs_vnops.c:231
> > #6 0xc022df8e in ffs_sync (mp=0xc1471400, waitfor=2, cred=0xc0babe00,
>td=0xc02d6480)
> > at vnode_if.h:545
> > #7 0xc01f162c in sync (td=0xc02d6480, uap=0x0) at ../../../kern/vfs_syscalls.c:129
> > #8 0xc01aa6a2 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
> > #9 0xc01aaca3 in panic () at ../../../kern/kern_shutdown.c:493
> > #10 0xc027d8a2 in syscall (frame=
> > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135554112, tf_esi = 135604464,
>tf_ebp = -1077940868, tf_isp = -924336780, tf_ebx = 673945180, tf_edx = 1, tf_ecx =
>0, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 676290179, tf_cs = 31, tf_eflags
>= 663, tf_esp = -1077941024, tf_ss = 47}) at ../../../i386/i386/trap.c:1120
> > #11 0xc026e76d in Xint0x80_syscall () at {standard input}:140
> >
> >
> > FreeBSD 5.0-CURRENT #1: Wed Aug 14 12:19:54 EDT 2002
> > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SATELLIT
> > E
> > Preloaded elf kernel "/boot/kernel/kernel" at 0xc03ff000.
> > Preloaded elf module "/boot/kernel/random.ko" at 0xc03ff0a8.
> > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03ff154.
> > Timecounter "i8254" frequency 1193182 Hz
> > Timecounter "TSC" frequency 746339059 Hz
> > CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU)
> > Origin = "GenuineIntel" Id = 0x686 Stepping = 6
> > Features=0x383f9ff > T,PSE36,MMX,FXSR,SSE>
> > real memory = 134086656 (130944K bytes)
> > avail memory = 125779968 (122832K bytes)
> >
> >
> > Mike
> >
> > --
> >
> > Mike Heffner
> > <[EMAIL PROTECTED]>
> >
> >
> > 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
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: emulators/rtc and vmware2
My recollection is that the problem relates to calling make_dev() from the attach routine, and attach from the open call, and of course you can't open before you make_dev with devfs. Someone needs to restructure the driver to match some our other pseudo-device drivers where the device is properly created as part of module initialization. If fixed this and other things locally at one point on my notebook, but eventually got sufficiently sick of always fixing the kernel module for the latest -CURRENT change that I gave up on updating it. I have since lost the changes, but they shouldn't be too hard to reproduce. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 15 Aug 2002, dmk wrote: > > Is anybody successfully using the port emulators/rtc with vmware2 on > -current? > > While the port builds and installs fine, a /dev/rtc device never appears. > > ISTM that the rtc device does a make_dev as part of the device open() > rather than at module load and that vmware doesn't work like that. > > Having no kernel (module) hacking experience, I come to the list for > pointers. I am trying to wrap my head around rtc enough to try make_dev() > at module load time, but maybe someone can give me a hint as to what's > going on. > > > I'm breaking the rules and running an old -CURRENT from Feb 4, 2002, so > I'll humbly swallow suggestions that I upgrade. > > Thanks loads, > dan > > > 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: buildworld breakage
I ran into this also, and a bit of fiddling with a debugger was un-enlightening -- it was segfaulting on a write to __collate_substitute_table in parse.y. The pointer to the table didn't appear to be corrupted, and it should have been in writable memory. It also appeared to be properly aligned. I moved on to other stuff but was planning to submit a bug report if it persisted (and therefore wasn't a local nit of mine due to heavy local kernel mods). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 15 Aug 2002, Mike Makonnen wrote: > I don't know if I'm the only one having this problem, but I haven't > been able to make a complete buildworld for a couple of > days now. The last time I upgraded was arround August 5. > I have been getting a signal 11 consistently in the same spot. > > ===> secure/usr.sbin/sshd > ===> share > ===> share/colldef > colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out > /daemon/build/current/src/share/colldef/bg_BG.CP1251.src > *** Signal 11 > > Stop in /daemon/build/current/src/share/colldef. > *** Error code 1 > > Stop in /daemon/build/current/src/share. > *** Error code 1 > > Stop in /daemon/build/current/src. > *** Error code 1 > > Stop in /daemon/build/current/src. > *** Error code 1 > > Stop in /daemon/build/current/src. > > 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: HEADS UP: GCC 3.2.1-pre imported
Great news. Hopefully this means we'll actually be able to ship 5.0 with a working KDE, since the 3.1 gcc we were running with had compiler optimization problems with the gif code. And, as previously discussed, this was a big checkbox item for getting 5.0 in decent shape for the release. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 1 Sep 2002, Alexander Kabaev wrote: > GCC 3.2.1-pre is now in the tree. Please let me know if you see any > problems recompiling your world/kernel. > > Remember to recompile your C++ ports. GCC 3.2 is not binary compatible > with 3.1. > > -- > Alexander Kabaev > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: aic7xxx kernel build failure...
I ran into this, and found that re-running config and make depend made it go away. Didn't have time to do any other follow-up. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 2 Sep 2002, Long, Scott wrote: > > > > Is anyone else seeing something similar to the following? I'm able to > > build world, but can't get this kernel build to budge. I've not seen > > this error before so I'm a tad lost as to where to poke next. -sc > > This is the third report of this that I've seen, and I'm completely > baffled. How old is your existing kernel and world? If it's old, > can you just build a new kernel (no modules) and try with that? > > Scott > > > > > ===> aic7xxx > > ===> aic7xxx/aicasm > > make -f > > /usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicas > > m/Makefile > > MAKESRCPATH=/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/a > > ic7xxx/aicasm depend > > ===> aic7xxx/ahc > > @ -> /usr/src/sys > > machine -> /usr/src/sys/i386/include > > /usr/obj/usr/src/sys/DELLAPTOP/modules/usr/src/sys/modules/aic > > 7xxx/ahc/../aicasm/aicasm > > -I/usr/src/sys/modules/aic7xxx/ahc/../../../cam/scsi > > -I/usr/src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx > > -o aic7xxx_seq.h -r aic7xxx_reg.h -p > > aic7xxx_reg_print.c-i > > /usr/src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx_ > > osm.h > > /usr/src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx.seq > > (null): Unable to malloc scope object > > *** Error code 70 > > > > Stop in /usr/src/sys/modules/aic7xxx/ahc. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules/aic7xxx. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules. > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/DELLAPTOP. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > > > -- > > Sean Chittenden > > > > 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: vnode lock assertion problem in nfs_link()
On Mon, 9 Sep 2002, Don Lewis wrote: > nfs_link() contains the following code: > > /* > * Push all writes to the server, so that the attribute cache > * doesn't get "out of sync" with the server. > * XXX There should be a better way! > */ > VOP_FSYNC(vp, cnp->cn_cred, MNT_WAIT, cnp->cn_thread); > > The problem is that vp is not locked by the caller, but VOP_FSYNC() > expects its argument to be locked. > > I think we can probably just lock and unlock vp around the call to > VOP_FSYNC() ... What I'd actually like to do is lock vp on going in to the VOP. I need to grab the lock in the link() code anyway to do the MAC check. UFS and others all immediately lock the vnode on entry anyway... 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: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Don Lewis wrote:
> >>> > The changes are obviously just cleanups for leaf file systems, but I
> >>> > wonder why everything wasn't always locked at the top. Could it have
> >>> > been because locking all the way down is harmful?
>
> >> I think this is because some places are still worrying about using
> >> link(2) on directories. I think there aren't any significant problems
> >> when vp is not a directory. Hard linking of directories was permitted
> >> (and perhaps even supported) until relatively recently:
> >
> > I suspect that you are right about this. If so, it should be able to
> > let namei() lock the first vnode since we check its type and bail out if
> > it is a directory before the second namei() call.
>
> I looked at namei() and ufs_lookup() and found a problem with telling
> the first namei() to grab the lock. It appears that the *_lookup()
> routines always lock the child vnode, and namei() later releases the
> lock if LOCKLEAF is not set. If we passed LOCKLEAF to the first
> namei(), then link("/foo/bar", "/foo/bar") would attempt to lock "bar"
> twice.
This also violates the "directory vnodes before file vnodes" lock order.
Generally speaking, you must always lock directories before files, since
files are always leaves, and directories may not be. The patch you have
looks fine to me, since it grabs a reference to the file but doesn't lock
it until after the directory look is held (and guarantees it's a leaf node
by checking VDIR so that it's safe to do the locking later).
> Because we now bail out early if the first vnode turns out to be a
> pointer, I believe we can dispense with the vnode inequality test and
> always grab the lock.
Yeah. vp != VDIR, and dvp == VDIR due to earlier constraints, so we know
that vp != dvp.
> BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
> reference has been dropped with vput() or vrele()?
Well, all the VFS code currently runs under Giant so a certain class of
unsafe cases is avoided, but generally no: ASSERT_VOP_UNLOCKED() invokes a
vnode operation to determine if the vnode is locked or not, which
dereferences fields in the vnode that require a valid reference to use.
Because none of the code there currently blocks, it's not an issue
generally right now (as neither vnode is likely to have been deleted
during the link operation, so releasing the reference is unlikely to
result in chances to the vnode). It's worth fixing though.
> Here's a replacement for the kern_link() patch in my previous patch
> file:
Looks good to me. I'm not familiar enough with unionfs and stacking to
provide an effective review of that code, however. Maybe Jeff can give us
some comments? (unionfs is actually the reason I stalled in making the
same changes).
> Index: vfs_syscalls.c
> ===
> RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
> retrieving revision 1.285
> diff -u -r1.285 vfs_syscalls.c
> --- vfs_syscalls.c1 Sep 2002 20:37:28 - 1.285
> +++ vfs_syscalls.c10 Sep 2002 11:28:01 -
> @@ -1027,10 +1027,12 @@
> if (nd.ni_vp != NULL) {
> vrele(nd.ni_vp);
> error = EEXIST;
> - } else {
> + } else if ((error = vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td))
> + == 0) {
> VOP_LEASE(nd.ni_dvp, td, td->td_ucred, LEASE_WRITE);
> VOP_LEASE(vp, td, td->td_ucred, LEASE_WRITE);
> error = VOP_LINK(nd.ni_dvp, vp, &nd.ni_cnd);
> + VOP_UNLOCK(vp, 0, td);
> }
> NDFREE(&nd, NDF_ONLY_PNBUF);
> vput(nd.ni_dvp);
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Tue, 10 Sep 2002, Don Lewis wrote:
> On 11 Sep, Bruce Evans wrote:
> > On Tue, 10 Sep 2002, Don Lewis wrote:
> >
> > I have just one thing to add to Robert's reply.
> >
> >> BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
> >> reference has been dropped with vput() or vrele()?
> >
> > I think it is. It has some internal locking (v_interlock at least), and
> > only asserts that the vnode is unlocked by curthread so it doesn't matter
> > if another thread locks it.
>
> I'm mostly worried about the vnode being recycled as something else
> after the vput() or vrele() call. I think a better approach would be to
> add the assertion checks to vput() and vrele(), which would mean that we
> could remove most of the checks in the syscall code. The only problems
> we would miss would be when we leak vnode references, but reference
> leaks are a problem anyway. I wish there was a good way to add
> assertion checks for detecting the leaks.
Unfortunately, we can't assert not locked at the end of vput because of
recursive locking of vnodes.
What I would like to see is a check that, when control is returned to
userland, that the thread owns no locks. It's a bit like sleeping while
holding a mutex: don't do that. Also, last time I tried to use the ddb
show lockedvnods command, I got the problem attached below due to locking
issues, which makes it a lot harder to debug locking problems...
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
db> show lockedvnods
Locked vnodes
panic: blockable sleep lock (sleep mutex) mountlist @
../../../kern/vfs_subr.c:2621
Debugger("panic")
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0423ed4
stack pointer = 0x10:0xc869b9d0
frame pointer = 0x10:0xc869b9dc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 11 (idle)
Stopped at siointr1+0xf4: movl$0,brk_state1.0
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vnode lock assertion problem in nfs_link()
On Wed, 11 Sep 2002, Bruce Evans wrote:
> On Tue, 10 Sep 2002, Robert Watson wrote:
>
> > ... Also, last time I tried to use the ddb
> > show lockedvnods command, I got the problem attached below due to locking
> > issues, which makes it a lot harder to debug locking problems...
> >
> > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> > [EMAIL PROTECTED] Network Associates Laboratories
> >
> > db> show lockedvnods
> > Locked vnodes
> > panic: blockable sleep lock (sleep mutex) mountlist @
> > ../../../kern/vfs_subr.c:2621
> > Debugger("panic")
>
> Try removing all the locking in the command. ddb commands can't use
> locking. I have printfs in _mtx_lock_flags(), _mtx_lock_spin_flags(),
> _mtx_lock_sleep() and _mtx_lock_spin() to detect locking when ddb is
> active.
>
> The error handling would be better if trap_fatal() were called before
> panic panic(), like it is for null pointer panics. ddb on i386's then
> notices that it shot itself and longjmps to its entry point. This
> handles things like reading through garbage pointers OK, but not
> external state changes like locking. Maybe my printfs should be
> trap_fatals or or direct longjmps.
I'll try removing the locking tonight sometime. Yeah, the other
frustrating thing about this particular panic is that there is no way to
recover from it if you just broke to ddb for the purposes of checking
locks, because the panic hoses the ddb state, which in this case is highly
unfortunate.
Thanks,
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: Crashdumps available for download ... please help
On Tue, 17 Sep 2002, Martin Blapp wrote: > If you don't beleave it or not. I've taken out again (I've already > switched them once) one bank of 512M ram and since then I've not had any > panics anymore. > > Can a ram error occur after a system has been fine one month ? Chances are, if you change an important variable such as memory size, it will change the failure mode for this bug. Carefully marking the memory so you know which is which, find replacement memory of identical size and other characteristics, and see if the failure comes back. If the failure comes back with different memory, the chances of it being a problem with the memory are pretty low. However, if you're going to halve the available memory, you're going to substantially change the behavior of the system for large and parallel builds, because the swapping/paging behavior will probably be quite different, especially if your working set is larger than 512mb and smaller than 1gb. I.e., be careful that tweaks changing the behavior of your system aren't just masking the real bug. 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: smbus, geom or ufs attr break the kernel
That's an odd set of things to have break in concert. The UFS options should not affect devfs at all. That said, your best bet is probably to turn off sets of related options until you figure out what the source is. Obvious candidates would be to turn off the UFS options as a set, GEOM, and then the smbus support, and see what makes things work again. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Tue, 24 Sep 2002, Marc Recht wrote: > Hi! > > Something checked-in yesterday broke the kernel badly.. Some of these > options or a combination of these break the kernel badly. If they're activatet then >not all devices are created by devfs (ttv* is missing..). > Even without devfs ttv* isn't working... > Commenting this out of my config fixed the prob for me. > > options UFS_EXTATTR > options UFS_EXTATTR_AUTOSTART > options UFS_ACL > options GEOM > device smbus# Bus support, required for smb below. > device viapm > device smb > device iicbus # Bus support, required for ic/iic/iicsmb below. > device iicbb > device ic > device iic > device iicsmb # smb over i2c bridge > > Marc > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbus, geom or ufs attr break the kernel
On Tue, 24 Sep 2002, Marc Recht wrote: > > That's an odd set of things to have break in concert. The UFS options > > should not affect devfs at all. That said, your best bet is probably to > > turn off sets of related options until you figure out what the source is. > > Obvious candidates would be to turn off the UFS options as a set, GEOM, > > and then the smbus support, and see what makes things work again. > > I did and it's the smbus/ic/iic/iicsmb stuff what breaks the kernel for > me. Maybe it was the commit by Nicolas Souchu (smbus.c 1.16). Yeah, you probably didn't want a console anyway. :-) 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: troubles with recent -current
On Wed, 25 Sep 2002, Mikhail Teterin wrote: > Hi! I'm experiencing an increasing amount of problems here, and will try > to list them below. Some of this may be well known already, but, > hopefully, something will be usefull. > > Unless I set rc_ng to NO, the ypbind will not start, even though > enable_nis_client is set and "Starting ypbind" is displayed on boot. Locally, I discovered that the hard dependency of ypbind on rpcbind now seems to be broken. Try setting rpcbind_enable="YES" explicitly in rc.conf and see if that helps. Gordon already has a bug report from me on this and has plans to resolve it. This is true of some other RPC dependencies also. 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: troubles with recent -current
On Wed, 25 Sep 2002, Mikhail Teterin wrote: > Thanks, but I have much bigger troubles at the moment :-( The workaround > for this one is simple -- rc_ng="NO"... > > FWIW, this -- introducing this sort of instability just two months > before the scheduled release -- is a lot more damaging than the stupid > trolls, IMO. The finger-breakers should consider leaving the troll alone > and switching to super-gluing the pointy hats to the apropriate skulls > :-| There are probably going to be a few nits involved in the VFS changes, but there are a number of serious bugs being fixed here. I've been running into a bug on some boxes involving a race condition that occurs when newsyslog runs on a busy system resulting in a inode deadlock. It also may be that many of the problems were bumping into now may merely be existing bugs that are now more visible. 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: troubles with recent -current
On Wed, 25 Sep 2002, Mikhail Teterin wrote: > > There are probably going to be a few nits involved in the VFS changes, > > but there are a number of serious bugs being fixed here. I've been > > running into a bug on some boxes involving a race condition that > > occurs when newsyslog runs on a busy system resulting in a inode > > deadlock. It also may be that many of the problems were bumping into > > now may merely be existing bugs that are now more visible. > > I'm sure we made progress. But it would be better, if the "few nits" > were noticed and fixed before committing. They are impossible not to > bump into -- judging by the others' responses -- unless, of course, the > developers do not routinely use -current as their primary OS. Something > we all should be doing now, that the long promised release date is only > two months away. The VFS patch was posted at least a week or two ago, and I've been running it on one of my own machines for at least a few days without problems. Inevitably in the committing of any large set of changes, there will be nits, and they seem to be resolving themselves pretty quickly (just saw two jeffr commits that were things missed in merging the patchset). 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: ttys patch - any objections?
If you do make this change, make sure it's carefully documented in the release notes. Otherwise we're going to get a lot of surprised "I can no longer get back to my X server after I switch away from it"'s. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 26 Sep 2002, Mark Murray wrote: > Hi > > The attached patch gets done by me any time I set up a FreeBSD > box (I like lots of VTYs and X on ALT-F12). > > Any objections to my committing this? > > M > -- > o Mark Murray > \_ > O.\_Warning: this .sig is umop ap!sdn > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lightweight interrupt threads
Dunno who it was, but my understanding is that we already actually use lightweight interrupt threads on sparc64, so you might want to peruse there and look at the approach taken. :-) You might have been talking to Bosko (possibly at USENIX ATC), as he was maintaining an i386 lightweight interrupt thread implementation (although I think it got fairly hosed over time due to a lot of changes in the main tree). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 30 Sep 2002, Julian Elischer wrote: > > I was talking to someone about lightweight interrupt threads > and interactions with KSEs and specifically about > KSE borrowing.. > > Believe it or not, I can't remember who it was.. > if it was you, let me know :-) > > Julian > > > > 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: NIS broken by pw_scan.c commits?
On Wed, 2 Oct 2002, Maxim Konovalov wrote: > Yes, it is my bug, fixed in rev. 1.23, sorry for inconvenience. No problem -- sorry for getting a bit snippy. I was just a bit surprised and couldn't imagine at first what I had broken in my password file :-). > By the way, there is still an issue: pw_scan() allows an empty GID in > non-NIS entries too. Any objections to a patch below? It looks to me like this is a reasonable approach, but if for some reason it doesn't work out, I'll be sure to whine when it hits my office machines. :-) 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
rpcbind failure mode non-ideal if run more than once
crash1# rpcbind Oct 2 12:47:15 crash1 rpcbind: cannot bind (null) on udp6: Address already in use Segmentation fault Oct 2 12:47:15 crash1 kernel: pid 1595 (rpcbind), uid 0: exited on signal 11 crash1# I'm having trouble extracting a core so won't be able to follow-up just yet, but it looks like it might not be too hard to track down. 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
NFS hang on rmdir(2) with 5.0-current client, server
Running into an odd (and apparently recent) problem involving rmdir(2) and
NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS
/tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in
NFS hanging. It appears to send out the RPC, but no response comes back
from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the
client:
crash1# which rmdir
/bin/rmdir
crash1# rmdir /usr/local
load: 0.04 cmd: rmdir 466 [sbwait] 0.00u 0.00s 0% 76k
~^B
Stopped at siointr1+0xf4: movl$0,brk_state1.0
db> trace 466
mi_switch(c0baa8d8,1f4,c02eb8f0,c0baa840,3d4) at mi_switch+0x238
msleep(c1996eec,0,58,c04bdba0,1f4) at msleep+0x474
sbwait(c1996ed4,c0518e80,c0bac630,c0bac630,f4240) at sbwait+0x51
soreceive(c1996e88,0,c86a1aec,c86a1b38,0) at soreceive+0x306
nfs_receive(c1bcb800,c86a1b3c,c86a1b38,c199d000,c0e34844) at
nfs_receive+0x4c0
nfs_reply(c1bcb800,c18d7850,c0bb3400,c1bcb800,44) at nfs_reply+0x5e
nfs_request(c19d94a0,c0bb3d00,d,c0baa840,c1cdb280) at nfs_request+0x2dc
nfs_rmdir(c86a1c04,c04e8600,c19d94a0,c1bc8de0,c86a1c98) at nfs_rmdir+0x11a
VOP_RMDIR(c19d94a0,c1bc8de0,c86a1c98,c86a1c98,0) at VOP_RMDIR+0x33
kern_rmdir(c0baa840,bfbffd3e,0,c86a1d40,c044ff4e) at kern_rmdir+0x1be
rmdir(c0baa840,c86a1d10,c04dedc9,418,1) at rmdir+0x22
syscall(2f,2f,2f,0,0) at syscall+0x2be
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (137, FreeBSD ELF32, rmdir), eip = 0x804886f, esp =
0xbfbffbfc, ebp = 0xbfbffc20 ---
db>
I can't do much debugging on the server just yet as it's actually the
development box and I don't have remote serial console access / debugger
access / etc on it. It strikes me that either the client is sending an
invalid request that the server blocks, or the server is getting unhappy
about the request. The server NFS processes seem to be idle, so at the
very least the server doesn't care:
0 354 1 85 106 0 1104 776 select Is??0:00.12 nfsd:
master
0 356 354 0 4 0 1012 628 nfsd I ??1:16.66 nfsd:
server
0 357 354 0 4 0 1012 628 nfsd I ??0:00.18 nfsd:
server
0 358 354 0 4 0 1012 628 nfsd I ??0:00.03 nfsd:
server
0 359 354 0 4 0 1012 628 nfsd I ??0:00.02 nfsd:
server
I've attached the tcpdump output from the server interface below, if
anyone is interested. Has anyone else experienced this problem?
I believe / is mounted using NFSv3, and quite possibly "soft":
file:/home on /home (nfs)
file:/projects on /projects (nfs)
It looks like the client is basically hung waiting for an RPC response.
I'd be glad to provide more debugging information if someone can point me
in the right direction.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
23:46:09.588003 192.168.50.10.1260868882 > 192.168.50.1.2049: 152 lookup
[|nfs]
4500 00b4 12b2 4011 822b c0a8 320a
c0a8 3201 03ff 0801 00a0 22d0 4b27 5512
0002 0001 86a3 0002
0004 0001 0044
000c
23:46:09.588168 192.168.50.1.2049 > 192.168.50.10.1260868882: reply ok 128
lookup [|nfs]
4500 009c 7e3b 4011 16ba c0a8 3201
c0a8 320a 0801 03ff 0088 15d3 4b27 5512
0001
4f29 ba3b db0f a103
0c00 3356 0a00 6e81 461d
23:46:09.588675 192.168.50.10.1260868883 > 192.168.50.1.2049: 152 rmdir
[|nfs]
4500 00b4 12b3 4011 822a c0a8 320a
c0a8 3201 03ff 0801 00a0 22c4 4b27 5513
0002 0001 86a3 0002
000f 0001 0044
000c
23:46:10.592213 192.168.50.10.1260868883 > 192.168.50.1.2049: 152 rmdir
[|nfs]
4500 00b4 12b4 4011 8229 c0a8 320a
c0a8 3201 03ff 0801 00a0 22c4 4b27 5513
0002 0001 86a3 0002
000f 0001 0044
000c
23:46:12.602134 192.168.50.10.1260868883 > 192.168.50.1.2049: 152 rmdir
[|nfs]
4500 00b4 12b5 4011 8228 c0a8 320a
c0a8 3201 03ff 0801 00a0 22c4 4b27 5513
0002 0001 86a3 0002
000f 0001 0044
000c
Re: NFS hang on rmdir(2) with 5.0-current client, server
On Wed, 2 Oct 2002, Don Lewis wrote: > On 2 Oct, Robert Watson wrote: > > > > Running into an odd (and apparently recent) problem involving rmdir(2) and > > NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS > > /tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in > > NFS hanging. It appears to send out the RPC, but no response comes back > > from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the > > client: > > > It looks like the client is basically hung waiting for an RPC response. > > I'd be glad to provide more debugging information if someone can point me > > in the right direction. > > I haven't seen this seen this problem with a 5.0-CURRENT client and a > 4.7-PRERELEASE server, so as near as I can tell the client side isn't > totally hosed. I pointed my client at a Solaris server and it seems not to be a problem in that configuration, leading me to suspect the server. I'm going to twiddle kernels a bit and see if it's a local problem of some sort or not. 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: NFS hang on rmdir(2) with 5.0-current client, server
On Wed, 2 Oct 2002, Don Lewis wrote: > On 2 Oct, Robert Watson wrote: > > > > Running into an odd (and apparently recent) problem involving rmdir(2) and > > NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS > > /tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in > > NFS hanging. It appears to send out the RPC, but no response comes back > > from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the > > client: > > > It looks like the client is basically hung waiting for an RPC response. > > I'd be glad to provide more debugging information if someone can point me > > in the right direction. > > I haven't seen this seen this problem with a 5.0-CURRENT client and a > 4.7-PRERELEASE server, so as near as I can tell the client side isn't > totally hosed. Interesting observation: rm on files, and rmdir on empty directories doesn't trigger it, but attempt to rmdir on a non-empty directory does. 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: NFS hang on rmdir(2) with 5.0-current client, server
On Thu, 3 Oct 2002, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Robe > rt Watson writes: > >> > It looks like the client is basically hung waiting for an RPC response. > >> > I'd be glad to provide more debugging information if someone can point me > >> > in the right direction. > >> > >> I haven't seen this seen this problem with a 5.0-CURRENT client and a > >> 4.7-PRERELEASE server, so as near as I can tell the client side isn't > >> totally hosed. > > > >Interesting observation: rm on files, and rmdir on empty directories > >doesn't trigger it, but attempt to rmdir on a non-empty directory does. > > This an NFSv2 mount, and I think the problem is specific to NFSv2. > Something like the following patch should fix it. I probably missed > this in revision 1.112 when fixing some similar issues in other > server op functions. See the commit message for that revision for > further details. You are right--for whatever reason, we mount NFSv2 as the default in a diskless boot, and the patch you provide me with seems to clear up the problem. Thanks, 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: usermount with devfs
On Thu, 3 Oct 2002, Lars Eggert wrote: > So there is no more usermount under -current with devfs? Or is there > another way to have the symlinks be created with the different > permissions (since devfs rules don't seem to apply to them)? We used usermounts with devfs in our last TrustedBSD demo to our sponsor. In the demo, we manually manage the protections on the CD device -- since it doesn't disappear when the CD is inserted and removed, just when the device goes away, it works fairly well. We can also set protections at login for users as part of fbtab. I know that Warner's devd is more targetted at support newbus and device driver binding, but there was also (at one point) discussion of a devfsd that responded to device events. 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: usermount with devfs
On Thu, 3 Oct 2002, Dima Dorfman wrote: > Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]>, Lars Eggert writes: > > > > >So there is no more usermount under -current with devfs? Or is there > > >another way to have the symlinks be created with the different > > >permissions (since devfs rules don't seem to apply to them)? > > > > Symlinks permissions are not used in FreeBSD, only the permissions > > of whatever they point at is used. > > Do we think that devfs rules *should* apply to symlinks? I couldn't > quite make it work when I tried before, but I didn't try very hard, so > it's probably doable if it's desirable. Is it desirable, though? As > phk points out, symlink permissions aren't used, so is there a reason > besides aesthetics that one would want to change them? Likewise for > ownership. symlink ownership is used for sticky bit directories to determine if it can be deleted. This probably doesn't apply in the devfs case, but is a real restriction in UFS. 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: [ GEOM tests ] disklabel warnings and vinum drives lost
On Fri, 4 Oct 2002, Terry Lambert wrote:
> The assumption here is that the devfs will be available to the system
> before the root is mounted transparently over it. This is also doable
> with an unmounted instance of the backing devfs, not yet mounted on
> /dev, if a transparent mount of / over top of a preexiting / -> /dev is
> not supported (i.e. devfs is mounted on /dev on the root FS, rather than
> the root FS being mounted on a backing node on which defvfs is already
> mounted on /, and the devices showing through as if they were on /).
Actually, no -- Vinum doesn't know how to do that--the device name used in
this code originates in a userland ioctl() configuration call for Vinum.
However, here's a patch that makes Vinum use namei() to rely on devfs to
locate requested devices instead of parsing the device name and guessing
the device number (incorrectly with GEOM). Unfortunately, I almost
immediately run into a divide by zero due to a zero sector size. Jeff
Roberson mentioned to me he had a fix for this bug that he sent to Greg,
but that was never committed.
Index: vinumio.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinumio.c,v
retrieving revision 1.75
diff -u -r1.75 vinumio.c
--- vinumio.c 21 Aug 2002 23:39:51 - 1.75
+++ vinumio.c 5 Oct 2002 00:03:09 -
@@ -50,92 +50,25 @@
int
open_drive(struct drive *drive, struct thread *td, int verbose)
{
-int devmajor; /* major devs for disk
device */
-int devminor; /* minor devs for disk
device */
-int unit;
-char *dname;
+struct nameidata nd;
struct cdevsw *dsw;/* pointer to
cdevsw entry */
+int error;
-if (bcmp(drive->devicename, "/dev/", 5)) /* device name doesn't
start with /dev */
- return ENOENT; /* give up */
if (drive->flags & VF_OPEN)/* open already, */
return EBUSY; /* don't do it again */
-/*
- * Yes, Bruce, I know this is horrible, but we
- * don't have a root filesystem when we first
- * try to do this. If you can come up with a
- * better solution, I'd really like it. I'm
- * just putting it in now to add ammuntion to
- * moving the system to devfs.
- */
-dname = &drive->devicename[5];
-drive->dev = NULL; /* no device yet */
-
-/* Find the device */
-if (bcmp(dname, "ad", 2) == 0) /* IDE disk */
- devmajor = 116;
-else if (bcmp(dname, "wd", 2) == 0)/* IDE disk */
- devmajor = 3;
-else if (bcmp(dname, "da", 2) == 0)
- devmajor = 13;
-else if (bcmp(dname, "vn", 2) == 0)
- devmajor = 43;
-else if (bcmp(dname, "md", 2) == 0)
- devmajor = 95;
-else if (bcmp(dname, "ar", 2) == 0)
-devmajor = 157;
-else if (bcmp(dname, "amrd", 4) == 0) {
- devmajor = 133;
- dname += 2;
-} else if (bcmp(dname, "mlxd", 4) == 0) {
- devmajor = 131;
- dname += 2;
-} else if (bcmp(dname, "idad", 4) == 0) {
- devmajor = 109;
- dname += 2;
-} else if (bcmp(dname, "twed", 4) == 0) { /* 3ware raid */
- devmajor = 147;
- dname += 2;
-} else
- return ENODEV;
-dname += 2;/* point past */
-
-/*
- * Found the device. We can expect one of
- * two formats for the rest: a unit number,
- * then either a partition letter for the
- * compatiblity partition (e.g. h) or a
- * slice ID and partition (e.g. s2e).
- * Create a minor number for each of them.
- */
-unit = 0;
-while ((*dname >= '0') /* unit number */
-&&(*dname <= '9')) {
- unit = unit * 10 + *dname - '0';
- dname++;
+NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, drive->devicename,
+curthread);
+error = namei(&nd);
+if (error)
+ return (error);
+if (!vn_isdisk(nd.ni_vp, &error)) {
+ NDFREE(&nd, 0);
+ return (error);
}
+drive->dev = udev2dev(nd.ni_vp->v_rdev->si_udev, 0);
+NDFREE(&nd, 0);
-if (*dname == 's') { /* slice */
- if (((dname[1] < '1') || (dname[1] > '4')) /* invalid slice */
- ||((dname[2] < 'a') || (dname[2] > 'h'))) /* or invalid partition */
- return ENODEV;
- devminor = ((unit & 31) << 3) /* unit */
- +(dname[2] - 'a') /* partition */
- +((dname[1] - '0' + 1) << 16) /* slice */
- +((unit & ~31) << 16); /* high-order unit bits */
-
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Fri, 4 Oct 2002, Robert Watson wrote: > On Fri, 4 Oct 2002, Terry Lambert wrote: > > > The assumption here is that the devfs will be available to the system > > before the root is mounted transparently over it. This is also doable > > with an unmounted instance of the backing devfs, not yet mounted on > > /dev, if a transparent mount of / over top of a preexiting / -> /dev is > > not supported (i.e. devfs is mounted on /dev on the root FS, rather than > > the root FS being mounted on a backing node on which defvfs is already > > mounted on /, and the devices showing through as if they were on /). > > Actually, no -- Vinum doesn't know how to do that--the device name used > in this code originates in a userland ioctl() configuration call for > Vinum. However, here's a patch that makes Vinum use namei() to rely on > devfs to locate requested devices instead of parsing the device name and > guessing the device number (incorrectly with GEOM). Unfortunately, I > almost immediately run into a divide by zero due to a zero sector size. > Jeff Roberson mentioned to me he had a fix for this bug that he sent to > Greg, but that was never committed. On the general topic of access to devices before a root has been found, Maxime Henrion <[EMAIL PROTECTED]> has done some interesting work on 'rootfs', a pseudofs used to bootstrap support for devfs, etc. In such an environment, Vinum and other consumers of devices would be able to rely on devfs access prior to the "real root" mount process. I'm not sure which pivotroot-like trick he's using, or whether he's doing the union thing to do the root re-mount. Presumably he has to be careful not to deadfs the devfs nodes in place before the real root turns up, etc. 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: [ GEOM tests ] disklabel warnings and vinum drives lost
On Sat, 5 Oct 2002, Greg 'groggy' Lehey wrote: > FWIW, I've never seen this code. The dates on the patch suggest that > it was made in the last quarter of an hour: I didn't claim that this was his code. This was code I just wrote to address Vinum not finding the devices due to major/minor number changes. I was referring to a separate problem involving a zero'd sectorsize resulting in a divide by zero in the kernel, which Jeff reported experiencing and fixing previously. > > --- vinumio.c 21 Aug 2002 23:39:51 - 1.75 > > +++ vinumio.c 5 Oct 2002 00:03:09 - > > However: > > RCS file: /home/ncvs/src/sys/modules/vinum/Makefile,v > revision 1.18 > date: 2000/04/16 00:17:46; author: grog; state: Exp; lines: +1 -3 > Remove MAINTAINER. > > Since that point, this particular file has had 5 updates, only one from > me. Jeff's a committer; he can commit it himself if he wants. Hmm. Funny, I was paying more attention to the line in the MAINTAINER's file which seems to suggest you are the maintainer. :-) Given that you appear to have read this patch -- may I commit it since it appears to resolve the first of the nits I ran into using Vinum with GEOM? There appear to be more problems in the tubes, but this one seemed straight-forward enough, especially since the functionality this patch replaces seems not to be in the tree. 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: [ GEOM tests ] disklabel warnings and vinum drives lost
On Sat, 5 Oct 2002, Ian Dowse wrote:
> >The divide by zero problem seems to be caused by an interaction
> >between two bugs: GEOM refuses to return the sector size because
> ...
> >The next failure I get is:
> >
> > Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP)
>
> This turns out to be vinum doing a DIOCWLABEL to make the label writable
> before writing its configuration, but GEOM does not support that ioctl I
> presume. It should be safe to ignore these DIOCWLABEL ioctl return
> values as the actual writing of the vinum data should give a suitable
> error if making the label writable fails and is important. The patch
> below is Robert's patch with all 3 other issues fixed, and together,
> this seems to be enough to make vinum work again.
Wonderful. I just committed a fix so that vinum.ko can be unloaded
without a panic when WITNESS is present. I'll give the combined patch a
spin on my crashbox and see if it does the trick here. Thanks!
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
> Index: vinumio.c
> ===
> RCS file: /dump/FreeBSD-CVS/src/sys/dev/vinum/vinumio.c,v
> retrieving revision 1.75
> diff -u -r1.75 vinumio.c
> --- vinumio.c 21 Aug 2002 23:39:51 - 1.75
> +++ vinumio.c 5 Oct 2002 02:40:18 -
> @@ -50,92 +50,25 @@
> int
> open_drive(struct drive *drive, struct thread *td, int verbose)
> {
> -int devmajor;/* major devs for disk
>device */
> -int devminor;/* minor devs for disk
>device */
> -int unit;
> -char *dname;
> +struct nameidata nd;
> struct cdevsw *dsw; /* pointer to
>cdevsw entry */
> +int error;
>
> -if (bcmp(drive->devicename, "/dev/", 5)) /* device name doesn't
>start with /dev */
> - return ENOENT; /* give up */
> if (drive->flags & VF_OPEN) /* open already, */
> return EBUSY; /* don't do it again */
>
> -/*
> - * Yes, Bruce, I know this is horrible, but we
> - * don't have a root filesystem when we first
> - * try to do this. If you can come up with a
> - * better solution, I'd really like it. I'm
> - * just putting it in now to add ammuntion to
> - * moving the system to devfs.
> - */
> -dname = &drive->devicename[5];
> -drive->dev = NULL; /* no device yet */
> -
> -/* Find the device */
> -if (bcmp(dname, "ad", 2) == 0) /* IDE disk */
> - devmajor = 116;
> -else if (bcmp(dname, "wd", 2) == 0) /* IDE disk */
> - devmajor = 3;
> -else if (bcmp(dname, "da", 2) == 0)
> - devmajor = 13;
> -else if (bcmp(dname, "vn", 2) == 0)
> - devmajor = 43;
> -else if (bcmp(dname, "md", 2) == 0)
> - devmajor = 95;
> -else if (bcmp(dname, "ar", 2) == 0)
> -devmajor = 157;
> -else if (bcmp(dname, "amrd", 4) == 0) {
> - devmajor = 133;
> - dname += 2;
> -} else if (bcmp(dname, "mlxd", 4) == 0) {
> - devmajor = 131;
> - dname += 2;
> -} else if (bcmp(dname, "idad", 4) == 0) {
> - devmajor = 109;
> - dname += 2;
> -} else if (bcmp(dname, "twed", 4) == 0) { /* 3ware raid */
> - devmajor = 147;
> - dname += 2;
> -} else
> - return ENODEV;
> -dname += 2; /* point past */
> -
> -/*
> - * Found the device. We can expect one of
> - * two formats for the rest: a unit number,
> - * then either a partition letter for the
> - * compatiblity partition (e.g. h) or a
> - * slice ID and partition (e.g. s2e).
> - * Create a minor number for each of them.
> - */
> -unit = 0;
> -while ((*dname >= '0') /* unit number */
> -&&(*dname <= '9')) {
> - unit = unit * 10 + *dname - '0';
> - dname++;
> -}
> -
> -if (*dname == 's') { /* slice */
> - if (((dname[1] < '1') || (dname[1] > '4')) /* invalid slice */
> - ||((dname[2] < 'a') || (dname[2] > 'h'))) /* or invalid partition */
> - return ENODEV;
> - devminor = ((unit & 31) << 3) /* unit */
> - +(dname[2] - 'a') /* partition */
> - +((dname[1] - '0' + 1) << 16) /* slice */
> - +((unit & ~31) << 16); /* high-order unit bits */
> -} else { /* compatibility partition
>*/
> - if ((*dname < 'a') || (*dname > 'h')) /* or invalid partition */
> - return ENODEV
Re: [ GEOM tests ] disklabel warnings and vinum drives lost
On Sat, 5 Oct 2002, Ian Dowse wrote: > >The divide by zero problem seems to be caused by an interaction > >between two bugs: GEOM refuses to return the sector size because > ... > >The next failure I get is: > > > > Can't write config to /dev/da1s1d, error 45 (EOPNOTSUPP) > > This turns out to be vinum doing a DIOCWLABEL to make the label writable > before writing its configuration, but GEOM does not support that ioctl I > presume. It should be safe to ignore these DIOCWLABEL ioctl return > values as the actual writing of the vinum data should give a suitable > error if making the label writable fails and is important. The patch > below is Robert's patch with all 3 other issues fixed, and together, > this seems to be enough to make vinum work again. Ok -- I went ahead and booted and ran the merged patch on my testbox, and Vinum is up and running fine with GEOM. I think we're set to commit -- do you want to, or shall I? 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
