Re: nullfs and unionfs
[replies sent directly to me may timeout and bounce, since I'm not
online as often as I should be, but I'll check the list archives]
I wrote a while back to freebsd-hackers:
> Is it safe (relatively speaking) to use the null and the union
> filesystems?
Well, so far I have had no serious problems with -stable, though
a few apparent bugs seem to be obvious; however, it seems that
the unionfs mount in -current is a great way for me to readily
and reliably panic the system, with a couple mutex panics that I
didn't make notes of.
Apart from the failure of getcwd() on my particular unionfs mount
atop a nullfs mount in both -stable and -current, I seem to see a
few other oddities only in -current. To wit:
[01:48:09][EMAIL PROTECTED]:~{507}# mount_unionfs /usr/local/sour
ce-hacks/ /usr/src
[01:48:33][EMAIL PROTECTED]:~{508}# ls -la !$
ls -la /usr/src
total 127
drwxr-xr-x 42 root wheel512 Dec 27 02:43 .
drwxr-xr-x 42 root wheel512 Dec 27 02:43 .
drwxr-xr-x 24 root wheel512 Dec 27 06:31 ..
drwxr-xr-x 24 root wheel512 Dec 27 06:31 ..
-rw-r--r--1 root wheel 4735 Sep 5 1999 COPYRIGHT
-rw-r--r--1 root wheel 7494 Mar 27 2001 Makefile
-rw-r--r--1 root wheel 25954 Dec 24 02:46 Makefile.inc1
-rw-r--r--1 root wheel 9761 Aug 28 1999 Makefile.upgrade
-rw-r--r--1 root wheel 2678 Aug 31 2000 README
-rw-r--r--1 root wheel 32930 Dec 27 23:45 UPDATING
drwxr-xr-x 36 root wheel512 Dec 27 02:43 bin
drwxr-xr-x 36 root wheel512 Dec 27 02:43 bin
drwxr-xr-x 53 root wheel512 Dec 27 03:17 contrib
drwxr-xr-x 53 root wheel512 Dec 27 03:17 contrib
drwxr-xr-x9 root wheel512 Dec 27 02:43 crypto
drwxr-xr-x9 root wheel512 Dec 27 02:43 crypto
drwxr-xr-x 19 root wheel512 Dec 27 02:43 etc
etc. Trust me, I am not making this up.
> mount -t union -a fail to do anything, like
> /usr/local/system/src /usr/src null ro
> /usr/local/source-hacks /usr/src/ union rw )
> ^
I just noticed that NetBSD's `mount' man page says that an `-a' mount
will not work if the same *type* of mount on the mountpoint already
exists; perhaps FreeBSD needs to check the type in addition to the
mountpoint in ismounted() and allow certain types of filesystems,
such as unionfs, to pile up atop existing mountpoints, in order for
the above fstab lines to work without the ugly trailing directory slash...
thanks
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panics, panics. And stuff.
[replies sent directly to me may timeout and bounce, since I'm not online as often as I should be, but I'll check the list archives] Aiee, aiee. One hardware-related failure resulted in the root filesystem getting hosed, with trashed inodes for a couple links, a couple empty directories, a couple kernel modules, and a couple loader-related files in /boot going missing. The result of this is that when the normal bootblocks couldn't find the missing (corrupt/bad format) /boot/loader, it defaulted to booting as happens when one gives a keypress and (as seen in manpage) >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/kernel boot: appears, but of course one has to specify /boot/kernel/kernel (or more likely /boot/loader.old, if one has it and actually knows enough to do so rather than trying the kernel, which I didn't) Which is fine until the kernel loads and starts booting. Then it appears to change to a block cursor as normal except that no kernel messages are appearing on the screen. If I'm not mistaken, this is what happens when the hints file is missing. (I've been offline for many months and haven't downloaded all the archives to brush up on that discussion.) No booting single-user or nuthin. I couldn't think of a workaround, other than to replace the missing /boot/loader which worked. Am I correct that without statically compiling hints into the kernel proper, you can't boot a kernel directly from the above prompt with -current, as one used to in the past, or if one loses the loader like I did? (Looking at the archive, it seems someone else has just experienced similar) Other non-panic but leftover from the panic that affected /var described above was the kernel message Jan 3 01:37:52 dastardly kernel: /var: mount pending error: blocks 40 files 9 (I had just fsck -p'ed /var from -stable, which resulted in a spew of messages but no claim as with the hosed root filesystem that I had to run fsck by hand.) I don;t know if this is something worth reporting. Also of note, these messages when I attempt to play an mp3 file with mpg123 through an ES1868 sound card: Jan 3 01:43:56 dastardly kernel: lock order reversal Jan 3 01:43:56 dastardly kernel: 1st 0xc13dbf80 sbc0 @ /usr/src/sys/dev/sound/pcm/sound.c:132 Jan 3 01:43:56 dastardly kernel: 2nd 0xc13ef340 pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/channel.c:438 No problems (other than sounding like crap, being a 75MHz machine) were obvious. If this means anything, I can provide more details. (Actually, it only sounds like crap because I give an option that seems to need more CPU -- without it, the machine actually has some 5% idle time and the mp3 sounds fine) I've mentioned earlier that I've had some panics when playing with unionfs mounts under -current, probably to be expected. I've been able to panic NetBSD doing union mount things that I haven't yet tried under FreeBSD, although some things work there which fail under FreeBSD, such as the cursed getcwd() problem. And some things don't work, so I need to verify if it's a common problem in the unionfs code on both systems. More about this later. (Okay, it's later, and no, these things are not problems under freebsd) On the subject of kernel messages, I'm guessing that swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 272, size: 4096 swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 256, size: 4096 swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 256, size: 4096 swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 264, size: 4096 swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 264, size: 4096 is not of great concern, and is a result of the disk being very busy doing a copy of a large file or something similar I was doing at the same time. No panic resulted. (that might have been -stable) acpi0: AcpiHwObtainSleepTypeRegisterData failed - AE_NOT_FOUND this happens when I hit ctrl-alt-space with -current, of course no panic FWIW, I've got device `apm' defined in the -current kernel config but it never seems to appear on three machines, one of which has the above acpi0, and all three of which have `apm' without problems in -stable... Probably not a concern, because in spite of this, I can still get results from the command `apm' and I am able to power down the machine automagically at shutdown. As usual, these are just observations, and I could be stumbling upon something well-known or discussed to death when I Had a Life. thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Performance of -current vs -stable
Serwoas! %s wrote on %.3s, %lld Sep 1993 > > Could it be due to the DDB, INVARIANTS & WITNESS options in the > > kernel? If it is that's fine with me, I'm just wondering where > > that magnitude of a slowdown would be coming from. > WITNESS can really hurt. Quite possibly I should turn it off in GENERIC now (I Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an optimized `mpg123' on a 75MHz pentium machine, where the difference was far more obvious than on a faster machine. I suspected that WITNESS and similar goodies might be a problem, and even composed a lengthy message wondering about it, but what really got me wondering was the fact that -stable had far less idle time than the same hardware running NetBSD-current, so that I could do `useful' work under NetBSD while playing an mp3 cleanly, but such was difficult with FreeBSD-stable and impossible with -current. However, I suspect that such a question is more on-topic in -hackers or even -stable than here, but I'm wondering if I should extract any useful info from the message I composed but never sent, and post my kernel config and ask if there's anything obvious in there that would explain why FreeBSD's mpg123 takes ~60% CPU and NetBSD's ~30% (vs the ~90+% usage by -current)... Oh, I'll try rebuilding -current Real Soon^W^W later today, without WITNESS, and compare, just to stay on-topic for this list. thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock order reversals, login-related, maybe...
Are the following lock order reversals something that I should mention when I encounter them, in general? On the other hand, this is from an older -current, built 25.Jan, before which I don't see these messages, while after installworld/reboot, I see them, except I haven't normally booted into -current other than after -stable wedges/panics and I want to background-fsck all filesystems. Actually, it looks like once I did, so this, which immediately follows my alternate-r00t-login, is unrelated to the background fsck, but it always follows my login. If that made any sense. Jan 30 08:34:56 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Jan 30 08:34:57 dastardly kernel: lock order reversal Jan 30 08:34:57 dastardly kernel: 1st 0xc188b634 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Jan 30 08:34:57 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:13:36 dastardly login: ROOT LOGIN (t00r) ON ttyv3 Feb 1 14:13:37 dastardly kernel: lock order reversal Feb 1 14:13:37 dastardly kernel: 1st 0xc187e734 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:13:37 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:22:24 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Feb 1 14:22:25 dastardly kernel: lock order reversal Feb 1 14:22:25 dastardly kernel: 1st 0xc1880034 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:22:25 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 [etc] I'll assume that since this is two weeks old, it's been noted already, but in general, I wonder if I should report such occurrences, in a more timely manner... thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MODULES_WITH_WORLD=true means no modules?
Is it just me, or... I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. I just finished the buildworld/kernel/install jig, and I've got a fistful of modules built in /usr/obj/5.0-CURRENT/usr/src/sys/modules but after both installkernel and installworld, I've got an empty /boot/modules, and the only inhabitant of /boot/kernel/ is kernel. /boot/kernel.old/ is where I can find old modules, from when I built things the default way (build a new kernel, modules too) Either the modules aren't getting installed, or some other thing I've changed in /etc/make.conf (like the /usr/obj/5.0-CURRENT prefix) has hosed the modules install process. Is someone else using `MODULES_WITH_WORLD=true' successfully? If so, I'll boot back into -current and see if I can check it out... thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MODULES_WITH_WORLD=true means no modules?
> > MODULES_WITH_WORLD=true # do not build modules when building kernel > ^^^ > ...you need to read the option you enabled? Never mind, I figured out what happened, and will happen again in the future, since this doesn't quite `optimize' things as I'd like I had actually started writing to ask why /boot/kernel.old hadn't been updated with my previous /boot/kernel, but then I figured it out. Since I had done two `installkernel's, I was using the kernel image in /boot/kernel.old/ from the first installkernel, and a test is made, so that if I'm using it, it doesn't get deleted. Instead, what happened was that the existing /boot/kernel contents were nuked. This had been populated by kernel modules by the installworld step that I did following the first installkernel. So, when the above option is enabled, normally your previous contents of /boot/kernel/ are moved to replace /boot/kernel.old/ by `installkernel' and the new contents of /boot/kernel/ are no more than kernel alone -- look ma, no modules! In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. Actually, on this machine, a complete installworld probably takes less time than the present way to build a fresh kernel and set of modules as the `buildkernel' step, which I had hoped would be sped up. What I had perhaps been thinking (if you could claim that I was in fact thinking at all) was that the modules would be installed into a location by `installworld' that would be independent of any `build/installkernel's that would follow -- such as /boot/modules, which appears in the sysctl kern.module_path under -current. That way one could build new kernels from the same source, adding or removing devices, only needing to update the modules as part of the installworld when the source gets changed. At least, that was my goal in enabling this /etc/make.conf option, to speed up the buildkernel/installkernel process by skipping module rebuilding any time I swap in a different ethernet or sound card or find a new spiffy kernel option to try out. That's it in a nutshell. FWIW, booting the new kernel just built a few hours ago gives the following: | CPU: Pentium/P54C (75.00-MHz 586-class CPU) | Origin = "GenuineIntel" Id = 0x524 Stepping = 4 | Features=0x1bf = WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS | real memory = 41943040 (40960K bytes) Once again, I fling off a message before engaging brane barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Minor things: swi_net: unregistered isr number
If this might be of interest: kernel built 07.feb at boot time... | Doing initial network setup: hostname. * swi_net: unregistered isr number: 18. | xl0: flags=8843 mtu 1500 | options=3 [...] This is (probably) the dhclient being run at this time, maybe. Should I be bothered by the following? unknown: can't assign resources unknown: can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: can't assign resources unknown: can't assign resources this is after all of these have been detected and assigned (sio0, sio1, etc) ata3: at port 0x36e-0x36f,0x168-0x16f irq 10 o n isa0 Where did that come from, and why don't I know about it? I know about: ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 and -stable makes no claim I have a third ata controller... machine is ancient digital venturis 575 pc thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock order reversals, login-related, maybe...
Are the following lock order reversals something that I should mention when I encounter them, in general? On the other hand, this is from an older -current, built 25.Jan, before which I don't see these messages, while after installworld/reboot, I see them, except I haven't normally booted into -current other than after -stable wedges/panics and I want to background-fsck all filesystems. Actually, it looks like once I did, so this, which immediately follows my alternate-r00t-login, is unrelated to the background fsck, but it always follows my login. If that made any sense. Jan 30 08:34:56 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Jan 30 08:34:57 dastardly kernel: lock order reversal Jan 30 08:34:57 dastardly kernel: 1st 0xc188b634 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Jan 30 08:34:57 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:13:36 dastardly login: ROOT LOGIN (t00r) ON ttyv3 Feb 1 14:13:37 dastardly kernel: lock order reversal Feb 1 14:13:37 dastardly kernel: 1st 0xc187e734 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:13:37 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 Feb 1 14:22:24 dastardly login: ROOT LOGIN (t00r) ON ttyv7 Feb 1 14:22:25 dastardly kernel: lock order reversal Feb 1 14:22:25 dastardly kernel: 1st 0xc1880034 filedesc structure @ /usr/src/sys/kern/kern_descrip.c:925 Feb 1 14:22:25 dastardly kernel: 2nd 0xc031c940 Giant @ /usr/src/sys/kern/kern_descrip.c:959 [etc] I'll assume that since this is two weeks old, it's been noted already, but in general, I wonder if I should report such occurrences, in a more timely manner... thanks barry bouwsma 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
MODULES_WITH_WORLD=true means no modules?
Is it just me, or... I've changed my /etc/make.conf from the default, to be MODULES_WITH_WORLD=true # do not build modules when building kernel since I find myself often building new kernels (plus identical modules) without updating the rest of the source, taking extra time. I just finished the buildworld/kernel/install jig, and I've got a fistful of modules built in /usr/obj/5.0-CURRENT/usr/src/sys/modules but after both installkernel and installworld, I've got an empty /boot/modules, and the only inhabitant of /boot/kernel/ is kernel. /boot/kernel.old/ is where I can find old modules, from when I built things the default way (build a new kernel, modules too) Either the modules aren't getting installed, or some other thing I've changed in /etc/make.conf (like the /usr/obj/5.0-CURRENT prefix) has hosed the modules install process. Is someone else using `MODULES_WITH_WORLD=true' successfully? If so, I'll boot back into -current and see if I can check it out... thanks barry bouwsma 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: MODULES_WITH_WORLD=true means no modules?
> > MODULES_WITH_WORLD=true # do not build modules when building kernel > ^^^ > ...you need to read the option you enabled? Never mind, I figured out what happened, and will happen again in the future, since this doesn't quite `optimize' things as I'd like I had actually started writing to ask why /boot/kernel.old hadn't been updated with my previous /boot/kernel, but then I figured it out. Since I had done two `installkernel's, I was using the kernel image in /boot/kernel.old/ from the first installkernel, and a test is made, so that if I'm using it, it doesn't get deleted. Instead, what happened was that the existing /boot/kernel contents were nuked. This had been populated by kernel modules by the installworld step that I did following the first installkernel. So, when the above option is enabled, normally your previous contents of /boot/kernel/ are moved to replace /boot/kernel.old/ by `installkernel' and the new contents of /boot/kernel/ are no more than kernel alone -- look ma, no modules! In order to get /boot/kernel/ populated with modules, either one needs to installworld again, or use one of the targets to install only modules, I guess. Actually, on this machine, a complete installworld probably takes less time than the present way to build a fresh kernel and set of modules as the `buildkernel' step, which I had hoped would be sped up. What I had perhaps been thinking (if you could claim that I was in fact thinking at all) was that the modules would be installed into a location by `installworld' that would be independent of any `build/installkernel's that would follow -- such as /boot/modules, which appears in the sysctl kern.module_path under -current. That way one could build new kernels from the same source, adding or removing devices, only needing to update the modules as part of the installworld when the source gets changed. At least, that was my goal in enabling this /etc/make.conf option, to speed up the buildkernel/installkernel process by skipping module rebuilding any time I swap in a different ethernet or sound card or find a new spiffy kernel option to try out. That's it in a nutshell. FWIW, booting the new kernel just built a few hours ago gives the following: | CPU: Pentium/P54C (75.00-MHz 586-class CPU) | Origin = "GenuineIntel" Id = 0x524 Stepping = 4 | Features=0x1bf = WARNING: Driver mistake: make_dev(perfmon) called before SI_SUB_DRIVERS | real memory = 41943040 (40960K bytes) Once again, I fling off a message before engaging brane barry bouwsma 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
Minor things: swi_net: unregistered isr number
If this might be of interest: kernel built 07.feb at boot time... | Doing initial network setup: hostname. * swi_net: unregistered isr number: 18. | xl0: flags=8843 mtu 1500 | options=3 [...] This is (probably) the dhclient being run at this time, maybe. Should I be bothered by the following? unknown: can't assign resources unknown: can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: <16550 compatible COM device> can't assign resources unknown: can't assign resources unknown: can't assign resources this is after all of these have been detected and assigned (sio0, sio1, etc) ata3: at port 0x36e-0x36f,0x168-0x16f irq 10 o n isa0 Where did that come from, and why don't I know about it? I know about: ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 and -stable makes no claim I have a third ata controller... machine is ancient digital venturis 575 pc thanks barry bouwsma 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: Performance of -current vs -stable
Serwoas! %s wrote on %.3s, %lld Sep 1993 > > Could it be due to the DDB, INVARIANTS & WITNESS options in the > > kernel? If it is that's fine with me, I'm just wondering where > > that magnitude of a slowdown would be coming from. > WITNESS can really hurt. Quite possibly I should turn it off in GENERIC now (I Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an optimized `mpg123' on a 75MHz pentium machine, where the difference was far more obvious than on a faster machine. I suspected that WITNESS and similar goodies might be a problem, and even composed a lengthy message wondering about it, but what really got me wondering was the fact that -stable had far less idle time than the same hardware running NetBSD-current, so that I could do `useful' work under NetBSD while playing an mp3 cleanly, but such was difficult with FreeBSD-stable and impossible with -current. However, I suspect that such a question is more on-topic in -hackers or even -stable than here, but I'm wondering if I should extract any useful info from the message I composed but never sent, and post my kernel config and ask if there's anything obvious in there that would explain why FreeBSD's mpg123 takes ~60% CPU and NetBSD's ~30% (vs the ~90+% usage by -current)... Oh, I'll try rebuilding -current Real Soon^W^W later today, without WITNESS, and compare, just to stay on-topic for this list. thanks barry bouwsma 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: message regurgitation from bestweb.net, not me...
I just wrote > In case anyone else hasn't figured out why you're seeing a few old > I read this list via usenet, so here's relevant headers from a post Murphy's law. The news swerver I read from has stopped getting any new articles after about three bestweb regurgitations, which I didn't realize until just now, so there was plenty of activity since 3am local time that I missed. Sorry about restating the obvious. All news swervers suck, some more than others... barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
message regurgitation from bestweb.net, not me...
In case anyone else hasn't figured out why you're seeing a few old messages, it looks like there's a mailer at bestweb.net that's re-sending the mails it has queued up but using the `To:' header field for the new recipient, so that mails from several days ago are appearing again. It's not me and others forgetting and resending old mails. Here's a second copy of a message someone sent me: Feb 12 08:09:40 dastardly sendmail[277]: g1C79dU00277: from=<[EMAIL PROTECTED]>, size=1169, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED] et>, proto=ESMTP, daemon=MTA, relay=newman2.bestweb.net [209.94.102.67] Note that the messages sent to the list have a different msgid than the originals and are all [EMAIL PROTECTED]> . I read this list via usenet, so here's relevant headers from a post that ``I'' just made: Original-Date: Wed, 6 Feb 2002 16:03:16 +0100 (CET) From: BOUWSMA Beery <[EMAIL PROTECTED]> Subject: Lock order reversals, login-related, maybe... Original-Message-Id: <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2002 02:33:19 GMT Message-ID: <[EMAIL PROTECTED]> I see a few other messages others have ``sent'' today too. Hope this helps if anyone's confused by this and ready to direct a flamethrower at the apparent perpetrator. barry bouwsma recycling mail for fun and profit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld error
[This is an IPv6-only e-mail address, if you have any need to respond to this and send me a copy but do not have IPv6- capability, strip out the obvious part of the address, but I follow the list archives so no need to mail me] > > /usr/src/lib/libc/net/gethostbydns.c: In function `gethostanswer': > > /usr/src/lib/libc/net/gethostbydns.c:392: `buflen' undeclared (first use > It looks like that has been fixed in revison 1.36 of gethostbydns.c. Hmmm, I see that gethostbydns.c and getnetbydns.c got deltas in the most recent cvsup I did, but I had hacked around these problems an hour or two earlier and also found I needed to hack on name6.c, with one `buflen' and an `obp'... Maybe I still need to update again, but just to be safe, I'm cc'ing the committer of the other two deltas thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: custom kernel
> >> # diff -u2 /usr/src/Makefile.inc1.orig /usr/src/Makefile.inc1
> >> --- /usr/src/Makefile.inc1.origMon Apr 29 20:42:50 2002
> >> +++ /usr/src/Makefile.inc1 Tue Jun 25 20:05:28 2002
> >> @@ -402,9 +402,10 @@
> >> KRNLCONFDIR= ${KRNLSRCDIR}/${TARGET}/conf
> >> KRNLOBJDIR=${OBJTREE}${KRNLSRCDIR}
> >> +KERNCONFDIR?= ${KRNLCONFDIR}
> I asked only if is possible to back-port to 4.x STABLE tree...
> The whole Makefile.inc1 is very different, but this functionality
> can be obtained with only 3 lines of changes.
I've been using the above for months in -stable, as well as the
native -current functionality, to build kernels with read-only
/usr/src and no config file within (instead off in /usr/local
somewhere), and it's worked great. I've had to reapply the above
patch anytime the -stable Makefile.inc1 changes, so I second the
request that 4.x get the above patch MFC applied to bring its ability
to that of -current for alternative kernel config file locations,
and I can't see that it would cause any problems (I've never
experienced any)
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
duplicate includes in kdump/ioctl.c ?
[don't mail me, I'm going on holiday Real Soon Now again]
Am I the only one getting duplicated #include lines in the generated
ioctl.c file, created as part of building usr.bin/kdump?
Probably yes, because when I build things in other locations (I'm
using a MAKEOBJDIRPREFIX), I don't see the lines in those ioctl.c
files...
I'm using the relevant make.conf lines to set MAKEOBJDIRPREFIX as
RELNAME!= /usr/bin/uname -r
MAKEOBJDIRPREFIX?= /usr/local/obj/${RELNAME}
This puts everything in paths like this...
bash-2.05a$ less -N /usr/local/obj/5.0-CURRENT/usr/src/usr.bin/kdump/ioctl.c-BUGGY
[...]
23 #include
24
25 const char *ioctlname(u_long val);
26
27 #include
28 #include
29 #include
30 #include
31 #include
32 #include
33 #include
34 #include
35 #include
Note that lines 27-29 match lines 30-32, leading to a build failure
like
cc -O -pipe -DMAXPARTITIONS=16 -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/us
r.bin/kdump/../..-c ioctl.c
In file included from ioctl.c:31:
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:88: conf
licting types for `ses_object'
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:88: prev
ious declaration of `ses_object'
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:128: con
flicting types for `ses_objstat'
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:128: pre
vious declaration of `ses_objstat'
[snip]
If I `make' with `env MAKEOBJDIRPREFIX=...' in the source directory
/usr/src/usr.bin/kdump/ itself, it builds (more or less) fine...
25 const char *ioctlname(u_long val);
26
27 #include
28 #include
29 #include
30 #include
31 #include
[...]
However, there seem to be significant differences between the two
generated ioctl.c files (including another duplicated disklabel.h line).
(Also, I had done a `make includes' for laughs, and I seem to have
needed to hack the new /usr/include/sys/proc.h to be like
u_char ar_args[0]; /* Arguments. */
as was my old proc.h from March, in order to get the kdump binary
to be built by hand after the `make includes')
Is this b0rken for me because I'm using a make.conf MAKEOBJDIRPREFIX,
and I now have to give it on the command line? Oh, just for laughs,
I did a buildworld, specifying `env MAKEOBJDIRPREFIX' on the make line,
with the same results as earlier (failed build, as the .depends file
is regenerated, so a new ioctl.c file is generated even if I have a
successful kdump binary, meaning it gets rebuilt)... Or might the
fact that I'm using a unionfs mount over /usr/src have something to
do with it (since disklabel.h appears twice with `ls' since I needed
to hack it in the upper unionfs layer)... Source is current of last
night, while the -current I'm trying to update from was built early
march (cough)
Just to be *really* sure, I've commented out my make.conf lines, and
am doing another -DNOCLEAN buildworld, and I guess if that fails too,
when I get back, I'll do it again without the -DNOCLEAN (started with an
empty MAKEOBJDIRPREFIX just for safety), to see if I can get things
working for me... (Nope, failed too, have to try again later, sigh)
(sorry if I'm being typically unclear)
thanks
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: duplicate includes in kdump/ioctl.c ?
Sorry to answer myself, but after a bit of free time to reflect on this, I may as well talk back at myself. I wrote: > Am I the only one getting duplicated #include lines in the generated > ioctl.c file, created as part of building usr.bin/kdump? YES! > 27 #include > 28 #include > 29 #include > 30 #include > 31 #include > 32 #include > However, there seem to be significant differences between the two > generated ioctl.c files (including another duplicated disklabel.h line). Yow. A clue, that points to: > ... Or might the > fact that I'm using a unionfs mount over /usr/src have something to > do with it (since disklabel.h appears twice with `ls' since I needed > to hack it in the upper unionfs layer)... It is. There's a shadow `scsi' directory that appears under -current (at least, that I'm still using) with a unionfs mount under `ls' twice, and gets traversed twice as well by the `find' that I should have noted had I had the time to pay attention to the mkioctls innards, leading to the duplicate inclusions. So I've added a `sort -u' into the `find' pipeline in hopes of quenching the duplicated includes that appear due to this imperfection of the unionfs. We'll see how it goes... The only way anyone else *might* see this is if they too do a unionfs mount, to keep an unmolested /usr/src around while still allowing one to hack on bits and pieces of it with local customizations, like my hack to mkioctls... Sorry for the noise, but in case anyone else might see such a thing, I thought I'd put this into the archives And, in fact, I've successfully built `kdump' as part of my normal `buildworld', so it seems as if I may even be well on the way to a successful build of -current. Yay. thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM and NetBSD partitions/disklabels
[IPv6-only address above; strip the obvious for IPv4-only mail] > > We never had to ability to do this before. GEOM can probably do it for > > you, with something like this patch: > > Oops. Now I get the same error with both kinds of partitions: > > disklabel: ioctl DIOCGDINFO: Operation not supported by device > (However, it compiled just fine ;-) > > I have a NetBSD partition I'd like to read also. Is there something simple, > or preferably even braindead, that I can do to debug this? Actually, I've had no problem for about a year or so mounting NetBSD partitions under FreeBSD-stable and -current, once I got it working. Do you get the above error from the disklabel command? If so, have you rebuilt both `disklabel' and the kernel? (I think there's another thing or two you may need to rebuild, until you go through with rebuilding the whole world) That is, your kernel can mount the NetBSD partitions with their 16 partitions within, even if `disklabel' doesn't work yet... I'm probably not recalling everything right, since for the last year all I've needed to do has been to keep my patches (which is mostly a make.conf -DMAXPARTITIONS=16 applied to the whole world and kernel, where possible) in sync, like with the assert noted... But the last time I built and used a new world was a couple weeks ago, so I haven't tried GEOM. If you still have no luck, when I wake up I can review my patchset for both -current and -stable to see exactly what changes I made to get my NetBSD partitions mounted: The data for partition 3 is: sysid 169,(NetBSD) start 1028160, size 118768545 (57992 Meg), flag 0 beg: cyl 1020/ head 0/ sector 1; end: cyl 1023/ head 15/ sector 63 bash-2.05a# disklabel ad0s3 # /dev/ad0s3c: type: unknown disk: NetBSD1.5 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 117825 sectors/unit: 118768545 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 16 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 26208004.2BSD 1024 8192 101 # (Cyl.0 - 259) b: 787248 262080 swap# (Cyl. 260 - 1040) c: 1187685450unused0 0# (Cyl.0 - 117825*) e: 20971440 10493284.2BSD 2048 16384 102 # (Cyl. 1041 - 21845) f: 262080 220207684.2BSD 2048 16384 104 # (Cyl. 21846 - 22105) g: 6290928 222828484.2BSD 2048 1638489 # (Cyl. 22106 - 28346) h: 90194769 285737764.2BSD16384 65536 2968 # (Cyl. 28347 - 117825*) /dev/ad0s3g on /usr/obj (ufs, local, soft-updates) /dev/ad0s3h on /usr/home (ufs, local, soft-updates) /dev/ad0s3a on /NetBSD (ufs, local, read-only) /dev/ad0s3e on /NetBSD/usr (ufs, local, read-only) /dev/ad0s3f on /NetBSD/var (ufs, local, read-only) (I have no problem mounting rw when needed; note that you also will need to modify NetBSD's fsck as needed to be done in FreeBSD-stable or use an alternate superblock under NetBSD after a FreeBSD rw mount; and also the above output is from FreeBSD-stable that I'm running now) barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM and NetBSD partitions/disklabels
[IPv6-only address above; strip the obvious for IPv4-only mail] > > ...That is, your kernel can mount the NetBSD partitions with their 16 > > partitions within, even if `disklabel' doesn't work yet... > Heh, I just mounted the NBSD partition using an un-patched FBSD kernel > with GEOM, even though disklabel (recompiled) refuses to list it. I took a look at my local patches, and just looked at phk's original patch, which apparently doesn't touch `disklabel'... Under -current, my only patch to any related source file is to disable the assert as noted. In my make.conf file I have the lines CFLAGS= -O -pipe -DMAXPARTITIONS=16 COPTFLAGS= -O -pipe -DMAXPARTITIONS=16 which is arguably wrong, but it defines this for everything, world, kernel, or otherwise. Utilities that need to grok the disklabel are going to include src/sys/sys/disklabel.h which looks something like #ifndef MAXPARTITIONS #define MAXPARTITIONS 8 The patch from phk doesn't seem to do anything other than patch src/sys/geom/geom_bsd.c which won't touch disklabel, maybe. Don't quote me, I haven't looked at recent changes. The earlier solution I did was to change src/sys/sys/disklabel.h from 8 up to 16, but rather than continue to apply that hack each time I built the world, I instead used make.conf which worked until the assert sanity check was added. (I'd love to see it changed as per the patch from a hardcoded constant to something that will work for 8 or 16 MAXPARTITIONS...) The last time I built world -current was 02.Okt and I saw no problems with the mounted NetBSD filesystems there, though it was a non-devfs and non-geom world for me. I do the same thing with -stable, but I needed to hack around an explicit sanity check in diskslice.h there, but I don't see any other obvious changes I made to be able to mount NetBSD filesystems. I don't know that it will break anything to build the whole world with MAXPARTITIONS as 16, but I've done it for something like a year now with both -current and -stable and not noticed anything as a result, and nobody's told me that something will break, so... > What a mess. I hope I can un-bork any damage I may have done. I can't remember if I saw anything like that -- I vaguely recall it. If you want to risk it, you can try changing disklabel.h and making the whole world and kernel again to get MAXPARTITIONS universally distributed, but as I note, I've only done this no later than a few weeks ago, so any potential breakage is unknown to me. (You did a read-only mount, I hope?) Also, if you have enough machines around, you might want to try it without geom or anything to verify that you can reproduce my successes... > > to modify NetBSD's fsck as needed to be done in FreeBSD-stable or use an > > alternate superblock under NetBSD after a FreeBSD rw mount... > Thanks for the reminder. I'd completely forgotten about that problem. If you need it, I have a NetBSD pr that you can find by searching their -current mailing list, including patch, based on old NetBSD- current, that works for me... > Now I'll go and re-apply phk's patch (which was undone by cvsup) and try I have a few files I want to hack for various reasons, and I use a unionfs mount of the hacked versions atop the unhacked source, which also requires tracking whether the sources have changed below, and that's why I chose to use a make.conf MAXPARTITIONS rather than to fudge the source files proper. You can cd into the `disklabel' source directory and build a version of that binary with the -DMAXPARTITIONS=16 if you hesitate to build the whole world, and see if that will read your NetBSD disklabel with no problems, but I seem to recall that I may have needed to rebuild a MAXPARTITIONS kernel as well. Can't hurt to try, I don't think... barry bouwsma will improperly build world for food To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
