Re: Can't delete IPV6 addresses with ifconfig
On Sat, 16 Feb 2008, Kurt Jaeger wrote: > Hi! > > > > Put ipv6_enable="YES" into your /etc/rc.conf > > > > Yeah but I need to reboot to have it work it's magic.. > > > > I'd like to know what goes on behind the mask. > > It works like this: > > If ipv6_enable="YES", then you have a "true" from > /etc/network.subr:ipv6if(), which is used in /etc/rc.d/auto_linklocal > to set the linklocal adress. > > Again, using a function from /etc/network.subr:network6_getladdr() Yes but network6_getladdr only actually returns a result if there is already a link local address set. So presumably it must rely on the kernel to do so? I couldn't actually figure out what sets it originally and ended up rebooting the box :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Single user mode behaviour with serial console in 7.0RC2
On Sat, Feb 16, 2008 at 11:51:46PM +1100, Geoff Roberts wrote: > Hi, > > I have built a FreeBSD 7.0RC2 system to use both the serial and video > consoles. > > I find that when I drop into single user mode (shutdown now) on the terminal > connected to the box itself I do not see the single user mode prompt on the > serial console terminal. > > Likewise, when I drop to single user mode on the serial console I do not see > the single user prompt on the terminal connected to the box itself. > > Is this expected, or have I configured something incorrectly? FreeBSD does not support 100% dual-console configuration under all stages of use; that is to say, single-user prompts will be output to either VGA or serial console, but not both. Some additional tips: > In /etc/make.conf I have BOOT_COMCONSOLE_SPEED=115200 Not required if you use -S115200 in /boot.config. > options CONSPEED=115200 Not needed; see above. > boot_multicon="YES" > boot_serial="YES" > comconsole_speed="115200" > console="vidconsole,comconsole" Not needed if -Dh is added to /boot.config (e.g. -S115200 -Dh). Hope this helps. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Single user mode behaviour with serial console in 7.0RC2
Hi, I have built a FreeBSD 7.0RC2 system to use both the serial and video consoles. I find that when I drop into single user mode (shutdown now) on the terminal connected to the box itself I do not see the single user mode prompt on the serial console terminal. Likewise, when I drop to single user mode on the serial console I do not see the single user prompt on the terminal connected to the box itself. Is this expected, or have I configured something incorrectly? In /etc/make.conf I have BOOT_COMCONSOLE_SPEED=115200 In my kernel configuration file I have: options CONSPEED=115200 I have rebuilt and installed world and the kernel. In /etc/ttys I have ttyd0 "/usr/libexec/getty std.115200" vt100 on secure I have also re-installed the bootstrap code: cd /usr/src/sys/boot make install bsdlabel -B bootPartition In /boot/loader.conf I have boot_multicon="YES" boot_serial="YES" comconsole_speed="115200" console="vidconsole,comconsole" Kind regards, Geoff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATA -- erratic behaviour when removing disk
Is anyone aware of the situation where FreeBSD behaves erratically when a disk is physically removed without "atacontrol detach ataX" being run prior to removal (at least on RELENG_7)? Below are my notes from said situation. I can provide remote access to this machine (serial-level) to whoever wants to hack on it. I can be available for disk removal/insertion as well; just ask. Also FWIW: I also tested all this for comparison on Ubuntu Linux earlier this morning. I was able to yank the disk in the middle of an I/O operation, resulting in an immediate I/O error from dd. I took no precautions prior to yanking the disk. Upon reinsertion, the system found the disk and I could continue I/O operations on it as if it had never been removed. Only reason I'm pointing this out is that it confirms the issue isn't hardware or with vendor implementation, but rather specific to the OS. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | Hardware: Supermicro SuperServer 5015M-T+B Intel ICH7 AHCI enabled (version 01.10), BIOS-based RAID disabled ad4: 190782MB at ata2-master SATA150 ad6: 190782MB at ata3-master SATA150 OS installed on /dev/ad4 and OS was booted with verbose logging enabled: FreeBSD 7.0-RC2 FreeBSD 7.0-RC2 #0: Fri Feb 8 00:09:57 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 * Logged in and physically removed ad6 drive ata3: DISCONNECT requested subdisk6: detached ad6: detached ata3: DISCONNECTED * Physically reinserted ad6 drive ata3: CONNECT requested ata3: CONNECTED ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: reiniting channel .. ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: reiniting channel .. ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: reinit done .. * A couple seconds later, the I/O LED on ad6 turned solid and remained on. POINT #1 The I/O LED turning on is very disconcerting. This seems to indicate something bad is happening to the controller, likely induced by something the ATA driver is doing (or not doing?) * Executed: atacontrol list - No sign of ad6 * Executed: atacontrol detach ata3 POINT #2 I would have expected this to emit a bunch of kernel messages stating the channel had been removed. Where are they? I'm willing to bet the kernel is confused about the current state of the ATA subsystem. * Executed: atacontrol attach ata3 ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata3: reiniting channel .. ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: reiniting channel .. ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: reinit done .. * Executed: atacontrol list - No sign of ad6 * Physically removed ad6 drive, just to see if anything would come up on the console. ata3: DISCONNECT requested ata3: DISCONNECTED * Physically reinserted ad6 drive ata3: CONNECT requested ata3: CONNECTED ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 POINT #3 Why no reinit? Or, possibly, why the reinits earlier? Why isn't this consistent? Now I rebooted the box, deciding to *administratively* detach the channel before trying anything (vs. just pulling the disk). * Logged in * Executed: atacontrol detach ata3 subdisk6: detached ad6: detached * Executed: atacontrol attach ata3 ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 190782MB at ata3-master SATA150 ad6: 390721968 sectors [387621C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed Master: ad6 Serial ATA v1.0 Slave: no device present * Executed: atacontrol detach ata3 subdisk6: detached ad6: detached * Physically removed ad6 drive * Executed: atacontrol list - no sign of ad6, which is expected * Physically reinserted ad6 drive * Executed: atacontrol attach ata3 ata3: SATA connect time=0ms ata3: SIGNATURE: 0101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6:
Re: ATA -- erratic behaviour when removing disk
On Feb 16, 2008 7:07 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > Is anyone aware of the situation where FreeBSD behaves erratically when > a disk is physically removed without "atacontrol detach ataX" being run > prior to removal (at least on RELENG_7)? Yes, I have seen this since 4.5, IIRC. > Below are my notes from said situation. > > I can provide remote access to this machine (serial-level) to whoever > wants to hack on it. I can be available for disk removal/insertion as > well; just ask. > > Also FWIW: I also tested all this for comparison on Ubuntu Linux earlier > this morning. I was able to yank the disk in the middle of an I/O > operation, resulting in an immediate I/O error from dd. I took no > precautions prior to yanking the disk. Upon reinsertion, the system > found the disk and I could continue I/O operations on it as if it had > never been removed. Only reason I'm pointing this out is that it > confirms the issue isn't hardware or with vendor implementation, but > rather specific to the OS. Congratulations to the Linux folks. Or not, since this looks like a very risky behavior. Who warrants you that the *same* disk was plugged back? Blindly continuing to write could easily corrupt the contents of the second drive. > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Hardware: > Supermicro SuperServer 5015M-T+B > Intel ICH7 > AHCI enabled (version 01.10), BIOS-based RAID disabled > ad4: 190782MB at ata2-master SATA150 > ad6: 190782MB at ata3-master SATA150 > > OS installed on /dev/ad4 and OS was booted with verbose logging enabled: > > FreeBSD 7.0-RC2 FreeBSD 7.0-RC2 #0: Fri Feb 8 00:09:57 UTC 2008 [EMAIL > PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 [lengthy contents purposefully removed in the reply message] -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0-RC2 package glitch
I maintain a cluster of FreeBSD machines, and for various reasons tend to do clean installs or re-installs on my machines with each new release. As a result, I've been doing some testing involving clean installs from the 7.0-RC* releases, and noticed a small glitch in the initial package installation from sysinstall. This shows up on the i386 RC2 disc 1, but probably also shows up on other platforms. When doing a clean install from disc 1, sysinstall gives you the option to install the X Windows packages from disc 1 during a new installation. The RC2 sysinstall misses six packages, which are included on disc 1, which RC1 did install: imake-1.0.2_4,1 makedepend-1.0.1,1 gccmakedep-1.0.2 xorg-cf-files-1.0.2_2 xorg-nestserver-1.4,1 xorg-vfbserver-1.4,1 Between RC1 and RC2, sysinstall was cleaned up to install X by using the single top level xorg meta-package rather than the old method of specifying a number of different meta-packages. Unfortunately, the xorg-7.3_1 package in 7.0-release does not pull in the above six packages. They were installed in RC1, and have in the past been included in a full X install. A fix for the next release would probably involve adding devel/imake to the xorg port, and perhaps defaulting to building with XORG_COMPLETE to pull in xorg-nestserver and xorg-vfbserver. For the 7.0 release, since the release packages are already set, perhaps a temporary hack in sysinstall to add imake, xorg-nestserver, and xorg-vfbserver would suffice. A second very minor issue: it would be nice if the mod times for the packages on the RC2 (and 7.0 release) disks would match those on the web 7.0-release package directory on the web site. They matched in RC1, and it makes it very clear to someone installing from the release disks which packages are included. (I wasn't sure whether installation release issues like this merited a full-fledged PR). -- Wayne Chapeskie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA -- erratic behaviour when removing disk
On Sat, Feb 16, 2008 at 09:08:38PM -0200, Carlos A. M. dos Santos wrote: > On Feb 16, 2008 7:07 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > Is anyone aware of the situation where FreeBSD behaves erratically when > > a disk is physically removed without "atacontrol detach ataX" being run > > prior to removal (at least on RELENG_7)? > > Yes, I have seen this since 4.5, IIRC. Wonderful. > > Also FWIW: I also tested all this for comparison on Ubuntu Linux earlier > > this morning. I was able to yank the disk in the middle of an I/O > > operation, resulting in an immediate I/O error from dd. I took no > > precautions prior to yanking the disk. Upon reinsertion, the system > > found the disk and I could continue I/O operations on it as if it had > > never been removed. Only reason I'm pointing this out is that it > > confirms the issue isn't hardware or with vendor implementation, but > > rather specific to the OS. > > Congratulations to the Linux folks. Or not, since this looks like a > very risky behavior. Who warrants you that the *same* disk was plugged > back? Blindly continuing to write could easily corrupt the contents of > the second drive. I'm not sure I understand. There were no filesystems on the drive, and nothing mounted prior to removal: just like what I did with FreeBSD. The procedure: * Boot Ubuntu CD, get a shell * dd if=/dev/sdb of=/dev/null bs=8k * In the middle of I/O, yank the disk * dd exits with "I/O error" * System continued to be responsive; no ATA subsystem oddities * Reinserted disk; kernel saw the disk without any issue * dd if=/dev/sdb of=/dev/null bs=8k * I/O still operating as before; no system "oddities" If you'd like, I can try inserting a completely different disk (both in size and vendor), but I really don't think anything odd will happen. If there were filesystems mounted or other whatnots, yes, I could see how there might be concern. I can try that as well if you're interested. I am a bit curious to see what Linux does if I pull a disk that has mounted filesystems which are being accessed at the time. This test was done solely to see how FreeBSD behaved when a disk was removed. The fact that the entire ATA channel goes into some bizarre non-recoverable state when a disk is removed without detaching first warrants the need for investigation, especially if this behaviour has existed since the mid-4.x days. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA -- erratic behaviour when removing disk
17.02.08, 02:08, "Carlos A. M. dos Santos" <[EMAIL PROTECTED]>: > > precautions prior to yanking the disk. Upon reinsertion, the system > > found the disk and I could continue I/O operations on it as if it had > > never been removed. Only reason I'm pointing this out is that it > > confirms the issue isn't hardware or with vendor implementation, but > > rather specific to the OS. > Congratulations to the Linux folks. Or not, since this looks like a > very risky behavior. Who warrants you that the *same* disk was plugged > back? Blindly continuing to write could easily corrupt the contents of > the second drive. There is no risk. Linux's libata detects it when you inserts a different disk. You can read some details here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11742.html -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tmpfs: strange behaviour (was: broken buildkernel (scsi_low and -Os) and duplicate manpages)
On 14/02/2008, Oliver Fromme <[EMAIL PROTECTED]> wrote: > David Naylor wrote: > > It is a strange problem, normal installworld works fine, but somehow > > the duplicate manpages result in a failure when installing with > > DESTDIR=, here are some possible reasons: > > > > 1) I use tmpfs when using DESTDIR (could be tmpfs does something strange) > > 2) Base system (compiled and installed) is compiled using -O2??? > > What is the exact CFLAGS setting that you use? > Do you use -O2 (or -Os) without -fno-strict-aliasing? I have managed to isolate the problem and it is definitely tmpfs related. If the directory that I'm installing into is tmpfs then it will fail, if it is ufs then it works. I recompiled tmpfs module (and reloaded) with CFLAGS='' with the same result. As an aside I have found that the default CFLAGS for src are: -O2 -fno-strict-aliasing -pipe. Would -fstrict-aliasing break anything in base/sys? David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
