Re: Ifconfig config of gif tunnels
On Sun, 13 Oct 2002, Adrian Wontroba wrote: Did you run mergemaster or otherwise get /etc/rc.network up to date before rebooting? I';ve done something semi-simple to manage things that possibly might get broken by mergemaster. I have a script that backs up critical files (/etc/hosts, /etc/master.passwd, /etc/group, etc), then runs mergemaster where it answers i to all things, then copies the essential files back. All other rc scripts are run out of rc.local in a programmatic fashion, that gives the options of turning them on and off in rc.conf... those control things like... gif tunnels, freenet6 configuration, ipsec, ipfw, ip6fw, etc. Those are never overwritten, ever. This means I don;t have to rely on system scripts being the same for everything to come back up correctly through upgrades... :) -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Oper @ efnet.dkom.atAilleCat@EFNet UNIXNet IRC Admin @ femme.ipv6.sapphite.org AilleCat@UNIXNet Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: after cvsup'd to RELENG_4_7 source, Could not find bsd.init.mk bsd.links.mk error
in message [EMAIL PROTECTED], wrote parv thusly... first i did make cleandir; make clean in /usr/src w/o problems. then when i tried make modules-cleandir make modules-cleandepend in /usr/src/sys/complile/KERNCONF, i get the following error... cd ../../modules ; env MAKEOBJDIRPREFIX=/cdrw/src/sys/compile/BOVINE/modules DEBUG=-g DEBUG_FLAGS=-g MACHINE=i386 make cleandir === accf_data /cdrw/src/sys/modules/accf_data/../../conf/kmod.mk, line 63: Could not find bsd.init.mk /cdrw/src/sys/modules/accf_data/../../conf/kmod.mk, line 190: Could not find bsd.links.mk make: fatal errors encountered -- cannot continue *** Error code 1 for the sake of closure... i removed the /sys/compile/BOVINE directory, followed by (cvsup to RELENG_4_7 for the sake of my sanity, followed by) another cleaning. that didn't produce the problem. after another install of world/kernel, reissuing the above modules-clean* commands didn't produce any errors either. thankfully! so, above problem is not a problem any more. not for me. - parv -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
mergemaster (was Re: Ifconfig config of gif tunnels)
On Sun, Oct 13, 2002 at 01:05:27PM -0400, Trish Lynch wrote: I';ve done something semi-simple to manage things that possibly might get broken by mergemaster. I don't recall ever having anything broken by mergemaster. I have broken things for myself by failing to drive mergemaster properly, e.g. my not noticing that a file (i)nstalled by mergemaster should have been (m)erged, to preserve local changes. The incidence of this has much reduced since I adopted the convention of flagging files I have modified with a # MODIFIED line near the top. -- Adrian Wontroba To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4,7 Kernel panic
Hi, Even with the latest : lab# CVSS Parsing supfile /etc/cvsupfile-stable Connecting to cvsup1.FreeBSD.org Connected to cvsup1.FreeBSD.org Server software version: SNAP_16_1e Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully lab# locate vfs_subr.c /usr/src/sys/kern/vfs_subr.c lab# ls -l /usr/src/sys/kern/vfs_subr.c -rw-r--r-- 1 root wheel 75933 Oct 13 13:10 /usr/src/sys/kern/vfs_subr.c I still get a panic on a Sony vaio : processor eflags=3D interrupt enabled,resume,IOPL =3D0 --- current process = 0 (swapper) interrupt mask = net tty bio cam kernel: type 12 trap, code=0 stopped at nexus_print_all_resources+0x14: cmpl $0,0(%esi) db t nexus_print_all_ressources(... nexus_print_child(... BUS_PRINT_CHILD(... device_print_child(c15a5600,c15c4a80) at device_print_child+0x20 device_probe_attach(c15c4a80) at device_probe_and_attach+0x20 nexus_attach(c15a5600,c05c4a80 DEVICE_ATTACH(c15a56000,c15c4a80) at DEVICE_ATTACH+0x2e device_probe_and_attach(c15a5600) at device_probe_and_attach+0x63 root_bus_configure(c0e35180) at device_probe_and_attach+0x63 configure(0,5c0c00,5c8000,0,c02304e0) at configure+0x33 mi_startup(0,0,0,0,0) at mi_startup+0x68 begin() at begin+0x47 db Thanks again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4,7 Kernel panic
In message [EMAIL PROTECTED], Roger Savard writes: Even with the latest : nexus_print_all_ressources(... That is the other 4.7 problem that people have been reporting recently, but only on some hardware. You could try reverting John Baldwin's latest change to src/sys/i386/i386/nexus.c by grabbing version 1.26.2.6 of that file from http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/i386/i386/nexus.c?rev=1.26.2.6 Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
HEADS UP: Re: Ifconfig config of gif tunnels
Hi,
On Sun, 13 Oct 2002 16:36:16 +0100
chris scott [EMAIL PROTECTED] said:
c.scott I've just cvsed up and made world to freebsd 4.7 stable, without a hitch.
c.scott However when I rebooted my machine the vpn tunnel which it was running
c.scott wouldnt come back up. After a while of checking configs and poking around I
c.scott found it was because the gif interfaces were cinfigured and not up. A simple
c.scott ifconfig gif0 up fixed this. I have never had to do this before as when I
c.scott have created gif interfaces the device was automatically up, this doesnt
c.scott seem to be the case anymore. Is this a new feature or a bug?
Doing up gif device automatically was a bug, and it was corrected.
/etc/rc.network was changed to do up gif tunnel during setup. Please
don't forget to do mergemaster.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: 4,7 Kernel panic
Ian Dowse wrote: In message [EMAIL PROTECTED], Roger Savard writes: Even with the latest : nexus_print_all_ressources(... That is the other 4.7 problem that people have been reporting recently, but only on some hardware. You could try reverting John Baldwin's latest change to src/sys/i386/i386/nexus.c by grabbing version 1.26.2.6 of that file from http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/i386/i386/nexus.c?rev=1.26.2.6 So the error is in the probe/attach routines. Correct in that the fatal trap only occurs on certain machines. On my laptop, the kernel bombs immediately after the EISA bus is probed. For example: eisa0: EISA bus *BOMB* Backtrace reveals: nexus_print_all_resources(c0e62280,c0e4a680,c0e62280,c0e62280,0) at nexus_print_all_resources+0x14 nexus_print_child(c0e4a680,c0e62280,c0535f68,c01eb838,c0e4a680) at nexus_print_child+0x19 BUS_PRINT_CHILD(c0e4a680,c0e62280,c0e62280,c0e4a680,c0535f68) at BUS_PRINT_CHILD+0x31 device_print_child(c0e4a680,c0e62280) at device_print_child+0x20 device_probe_and_attach(c0e62280) at device_probe_and_attach+0x5a nexus_attach(c0e4a680,c0535f68,c01ec003,c0e4a680,c0e4a680) at nexus_attach+0x4e DEVICE_ATTACH(c0e4a680,c0e4a680,c0429cd0,53a000,1) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0e4a680) at device_probe_and_attach+0x63 root_bus_configure(c0b30800,c03e7f0c,0) at root_bus_configure+0x16 configure(0,532c00,53a000,0,c012bb70) at configure+0x33 mi_startup(0,0,0,0,0) at mi_startup+0x68 begin() at begin+0x47 When I did ps at the DDB prompt, it said swapper was the last procss running. The message said something about a virtual address of 0x0. I think it's odd that swapper is starting before the probing is finished (during the probing of the EISA bus). Sounds like something in the Oct 10 nexus.c commit is causing certain things to be started out of order on certain HW. In a nutshell, it looks as though swapper is being started even before /etc/fstab is read. I should point out that my laptop is an HP Pavilion N5440, a Pentium III. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4,7 Kernel panic
On October 13, 2002 03:14 pm, Ian Dowse wrote: In message [EMAIL PROTECTED], Roger Savard writes: Even with the latest : nexus_print_all_ressources(... That is the other 4.7 problem that people have been reporting recently, but only on some hardware. You could try reverting John Baldwin's latest change to src/sys/i386/i386/nexus.c by grabbing version 1.26.2.6 of that file from http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/i386/i386/nexus.c ?rev=1.26.2.6 Ian Yep, it works for me , reverting back nexus.c dit it. %uname -a FreeBSD freebee.henocoffice.com 4.7-STABLE FreeBSD 4.7-STABLE #7: Sun Oct 13 15:49:03 EDT 2002 [EMAIL PROTECTED]:/data/obj/.amd_mnt/haydn/host/usr/src/sys/TheMatrix i386 Here is my /var/run/dmesg.boot file: syncing disks... 2 1 done Uptime: 7m7s Rebooting... Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-STABLE #7: Sun Oct 13 15:49:03 EDT 2002 [EMAIL PROTECTED]:/data/obj/.amd_mnt/haydn/host/usr/src/sys/TheMatrix Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (745.25-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 266862592 (260608K bytes) avail memory = 253816832 (247868K bytes) Preloaded elf kernel kernel at 0xc05a. Preloaded elf module splash_bmp.ko at 0xc05a009c. Preloaded splash_image_data /boot/splash.bmp at 0xc05a0140. Preloaded elf module linux.ko at 0xc05a0190. Preloaded elf module snd_ich.ko at 0xc05a0230. Preloaded elf module snd_pcm.ko at 0xc05a02d0. Preloaded elf module usb.ko at 0xc05a0370. Preloaded elf module umass.ko at 0xc05a040c. Preloaded elf module agp.ko at 0xc05a04ac. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00fdf30 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 agp0: Intel 82815 (i815 GMCH) SVGA controller mem 0xf400-0xf407,0xf800-0xfbff irq 9 at device 2.0 on pci0 pcib1: PCI to PCI bridge (vendor=8086 device=2448) at device 30.0 on pci0 pci1: PCI bus on pcib1 pci1: unknown card (vendor=0x104c, dev=0x8021) at 0.0 irq 9 pcic0: Ricoh RL5C475 PCI-CardBus Bridge irq 0 at device 2.0 on pci1 pcic0: PCI Memory allocated: 0x8800 pcic0: Polling mode pccard0: PC Card 16-bit bus (classic) on pcic0 fxp0: Intel Pro/100 Ethernet port 0x3000-0x303f mem 0xf4104000-0xf4104fff irq 9 at device 8.0 on pci1 fxp0: Ethernet address 08:00:46:40:c3:b4 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI to ISA bridge (vendor=8086 device=244c) at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0x1800-0x180f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0x1820-0x183f irq 9 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: unknown card (vendor=0x8086, dev=0x2443) at 31.3 irq 9 uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0x1840-0x185f irq 9 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered umass0: Sony USB Memory Stick Slot, rev 1.10/1.83, addr 2 pcm0: Intel 82801BA (ICH2) port 0x1880-0x18bf,0x1c00-0x1cff irq 9 at device 31.5 on pci0 pci0: unknown card (vendor=0x8086, dev=0x2446) at 31.6 irq 9 eisa0: EISA bus on motherboard eisa0: unknown card @H@ (0x0100) at slot 1 orm0: Option ROMs at iomem 0xc-0xcbfff,0xd8000-0xdbfff,0xdc000-0xd on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging ad0: 14403MB TOSHIBA MK1517GAP [29264/16/63] at ata0-master UDMA100 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0
Re: Kernel Panics in 4.7-STABLE
The nexus_print_all_resources() panic is due to a bug in EISA bus
handling that shows up due to a recent commit John made.
He has a tentitive patch for it but it needs to be tested / verified.
I've included it below. Pelase try this patch and tell us if it
fixes it.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:
:nexus_print_all_resources(c0e62280,c0e4a680,c0e62280,c0e62280,0) at
:nexus_print_all_resources+0x14
:...
Index: nexus.c
===
RCS file: /usr/cvs/src/sys/i386/i386/nexus.c,v
retrieving revision 1.26.2.6
diff -u -r1.26.2.6 nexus.c
--- nexus.c 3 Mar 2002 05:42:49 - 1.26.2.6
+++ nexus.c 11 Oct 2002 18:07:45 -
@@ -219,21 +219,21 @@
* connection points now so they show up on motherboard.
*/
if (!devclass_get_device(devclass_find(eisa), 0)) {
- child = device_add_child(dev, eisa, 0);
+ child = BUS_ADD_CHILD(dev, 0, eisa, 0);
if (child == NULL)
panic(nexus_attach eisa);
device_probe_and_attach(child);
}
#if NMCA 0
if (!devclass_get_device(devclass_find(mca), 0)) {
- child = device_add_child(dev, mca, 0);
- if (child == 0)
+ child = BUS_ADD_CHILD(dev, 0, mca, 0);
+ if (child == NULL)
panic(nexus_probe mca);
device_probe_and_attach(child);
}
#endif
if (!devclass_get_device(devclass_find(isa), 0)) {
- child = device_add_child(dev, isa, 0);
+ child = BUS_ADD_CHILD(dev, 0, isa, 0);
if (child == NULL)
panic(nexus_attach isa);
device_probe_and_attach(child);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: cvs commit: src/sys/kern vfs_subr.c
On Sun, 13 Oct 2002, Stefan Farfeleder wrote:
On Sun, Oct 13, 2002 at 07:22:17PM +0400, Dmitry Morozovsky wrote:
On Sun, 13 Oct 2002, Dmitry Morozovsky wrote:
DM On Sun, 13 Oct 2002, Kelly Yancey wrote:
DM
DM KY kbyanc 2002/10/13 00:38:41 PDT
DM KY
DM KY Modified files:(Branch: RELENG_4)
DM KY sys/kern vfs_subr.c
DM KY Log:
DM KY Use sys/queue.h macros rather than fondling implementation details.
DM
DM Kelly, it seems this commit broke -stable (see PR/44007)
... and I can confirm that backing out this change revert -stable to working
(patch for band-aiding follows)
Index: sys/kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.249.2.28
diff -u -r1.249.2.28 vfs_subr.c
--- sys/kern/vfs_subr.c 13 Oct 2002 07:38:41 - 1.249.2.28
+++ sys/kern/vfs_subr.c 13 Oct 2002 15:17:55 -
@@ -1256,7 +1256,7 @@
KASSERT(bp-b_vp != NULL, (pbrelvp: NULL));
/* XXX REMOVE ME */
- if (!TAILQ_NEXT(bp, b_vnbufs)) {
+ if (bp-b_vnbufs.tqe_next != NULL) {
panic(
relpbuf(): b_vp was probably reassignbuf()d %p %x,
bp,
The line should probably read:
if (TAILQ_NEXT(bp, b_vnbufs) != NULL) {
Yeah, I inverted the sense. Sorry.
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: cvs commit: src/sys/kern vfs_subr.c
On Sun, 13 Oct 2002, Dmitry Morozovsky wrote:
On Sun, 13 Oct 2002, Ian Dowse wrote:
ID KY Use sys/queue.h macros rather than fondling implementation details.
ID
ID Kelly, it seems this commit broke -stable (see PR/44007)
ID
ID As this seemed to affect quite a few people, I went ahead and checked
ID in the obvious fix in case it is a few hours until Kelly returns.
ID Thanks to you and others for identifying the changed that caused
ID this!
ID
ID Can somebody confirm that revision 1.249.2.29 of vfs_subr.c does
ID indeed fix the relpbuf() panics?
I just patch vfs_subr.c with your change, and confirm that machine is up and
running ;-)
Thanks for your quick reaction -- broken -stable is not The Right Thing [tm]!
Ian, thanks for catching this so quick. I don't know why my test machine
didn't panic, but the error is so obvious it should have. Thanks again,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Kernel Panics in 4.7-STABLE
Oh, also, just a general note to people. These bug reports are great, it tells us that something went wrong, but it would be nice if they were a little more complete :-) For example, it wasn't until the 20th posting in this and the similar other kernel panic thread on -hackers that someone actually posted the console text (or DDB backtrace) leading up to the crash, so we didn't connect it with the NEXUS issue until just now. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4,7 Kernel panic
On Sun, 13 Oct 2002, Chrisy Luke wrote:
Donn Miller wrote (on Oct 13):
So the error is in the probe/attach routines. Correct in that the fatal
trap only occurs on certain machines. On my laptop, the kernel bombs
immediately after the EISA bus is probed. For example:
eisa0: EISA bus *BOMB*
I commented out the EISA code in nexus_attach(), and my 4.7-S boots
fine:
#if 0
if (!devclass_get_device(devclass_find(eisa), 0)) {
child = device_add_child(dev, eisa, 0);
if (child == NULL)
panic(nexus_attach eisa);
device_probe_and_attach(child);
}
#endif
I saw a related post on Google, dating back to 2000. It was the same
deal, except it was bombing out on the ISA bus probe. The guy's solution
was to substitute nexus_add_child for device_add_child, although that
sounds like an ugly hack, and it's probably wrong.
FWIR, I never saw the on motherboard message printed; I only saw the
eisa0: EISA bus before the fatal trap occured. I know it's possible to
step through the entire probe/attach routines after doing boot -d, but it got
a little tedious. Too many low-level asm statements to step through.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Ifconfig config of gif tunnels
On Sun, Oct 13, 2002 at 01:05:27PM -0400, Trish Lynch wrote: On Sun, 13 Oct 2002, Adrian Wontroba wrote: Did you run mergemaster or otherwise get /etc/rc.network up to date before rebooting? I';ve done something semi-simple to manage things that possibly might get broken by mergemaster. I have a script that backs up critical files (/etc/hosts, /etc/master.passwd, /etc/group, etc), then runs mergemaster where it answers i to all things, then copies the essential files back. Ewww. That kind of defeats the whole purpose of mergemaster(8). The whole idea is for a human to sit at the console and decide what changes need to be made. With your system, you'll lose any changes to master.passwd or group (like the recent addition of the sshd user/group). (Although I'll admit that changing the hosts file is one that I wouldn't mind skipping everytime.) You might as well just copy your files out of the way, run the make commands mergemaster(8) does, and then move the files back. Mergemaster(8) doesn't really buy you anything the way you are using it. Actually, you probably really should be using the '-a' option to mergemaster(8), and then go back later to see what else you need to update. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
