Re: build broken by usbdivar.h 1.40
--On Tuesday, July 15, 2003 22:31:38 -0500 Larry Rosenman <[EMAIL PROTECTED]> wrote: ===> netgraph/bluetooth/ubt cc -O -pipe -mcpu=pentiumpro -g -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/blueto ot h/include -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/blueto ot h/drivers/ubt -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/blueto ot h/include -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/blueto ot h/drivers/ubt -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c In file included from /usr/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:48: @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" *** Error code 1 After John-Mark's last commit I have a good kernel, for those keeping score. Thanks John-Mark for the quick fix(es). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
Tim Kientzle wrote this message on Tue, Jul 15, 2003 at 22:19 -0700: > John-Mark Gurney wrote: > >Harald Schmalzbauer wrote this message on Wed, Jul 16, 2003 at 02:58 +0200: > > > >>Let's see what Tim can contribute to this topic, since he also claimed to > >>have problems with "mountroot>" > > > >I have a possible patch that might address people's problems with > >mountroot. > > > >http://people.FreeBSD.org/~jmg/vfs_mount.diff > > I'm certain this won't address the problem > I saw. I was not using a serial console, > and I was not overflowing the buffer. > (So stripping parity bits and enforcing > buffer sizes won't help.) a) this effects all consoles, not just serial b) this doesn't just effect overflowing the buffer.. the return of -1 was being invalidated by c = cngetc() & 0177. You can't get -1 return on that. -- John-Mark Gurney Voice: +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]"
Re: Big and ugly bug in 5.1-release
On Wed, 16 Jul 2003, Harald Schmalzbauer wrote: > I'm experimenting with 5.1-REL for some weeks and during that time I had > some mysterious hangs which I didn't take serious because I modified > /usr/src/sys/cam/scsi/scsi_da.c to support my CF-Card-Reader. > But now I saw exactly the same problem on my brand new (and cosidered by > hardware extremely different) fileserver. > > The machine freezes for about one minute and then reboots itself withut any > error message. Sounds like its panicking and making a crashdump. Do you have console access? Can you perhaps compile with 'options DDB' and get on the console when it dies? If it worked right you should see the panic message and have a db> prompt. > It happens when I do a "/stand/sysinstall" or a "sysctl -a" If this is an i386 machine, I'd begin to suspect bad memory. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
John-Mark Gurney wrote: Harald Schmalzbauer wrote this message on Wed, Jul 16, 2003 at 02:58 +0200: Let's see what Tim can contribute to this topic, since he also claimed to have problems with "mountroot>" I have a possible patch that might address people's problems with mountroot. http://people.FreeBSD.org/~jmg/vfs_mount.diff I'm certain this won't address the problem I saw. I was not using a serial console, and I was not overflowing the buffer. (So stripping parity bits and enforcing buffer sizes won't help.) Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, Jul 15, 2003 at 10:11:03PM -0700, Marcel Moolenaar wrote: > On Tue, Jul 15, 2003 at 06:09:08PM -0700, Kris Kennaway wrote: > > > > > > > > > > It's not a machine problem if it only happens to the sparc64 build - > > > > > the same machine runs all the other -CURRENT tinderboxen except > > > > > powerpc. > > > > > > > > It does not only happen to sparc64. I've seen it fail for all but > > > > i386 and pc98, I think. > > > > > > i386 and pc98 have failed too (random example: July 5). > > > > > > > It's been doing this for weeks now. I wonder if this is a malloc > > debugging problem that was introduced somehow. > > malloc, you say? I have build failures in XFree4-clients because > rman coredumps and I have a backtrace full of free() frames... > > Coincidence? Some of the XFree86 utilities contain malloc bugs..rman in particular has been dumping core on certain ports for a couple of years. I tried to track it down once but couldn't find it. Kris pgp0.pgp Description: PGP signature
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, Jul 15, 2003 at 06:09:08PM -0700, Kris Kennaway wrote: > > > > > > > > It's not a machine problem if it only happens to the sparc64 build - > > > > the same machine runs all the other -CURRENT tinderboxen except > > > > powerpc. > > > > > > It does not only happen to sparc64. I've seen it fail for all but > > > i386 and pc98, I think. > > > > i386 and pc98 have failed too (random example: July 5). > > > > It's been doing this for weeks now. I wonder if this is a malloc > debugging problem that was introduced somehow. malloc, you say? I have build failures in XFree4-clients because rman coredumps and I have a backtrace full of free() frames... Coincidence? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
Harald Schmalzbauer wrote: Let's see what Tim can contribute to this topic, since he also claimed to have problems with "mountroot>" I installed FreeBSD (I think it was 5.0-RELEASE) on a hard disk attached to ad0. It worked, I tested it. I reconnected the hard disk to a separate IDE controller as ad4. The kernel booted, failed to mount root (as expected), and presented a "mountroot>" prompt. If I typed something invalid, the system rebooted. If I typed something valid, I got a "mountroot>" prompt again. In short, nothing I did would coerce the kernel into actually mounting root. Finally, I put the disk back on ad0, edited /etc/fstab and moved it back to ad4. That worked just fine. In short, "mountroot>" seems to do nothing if the kernel's initial attempt fails. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build broken by usbdivar.h 1.40
--On Tuesday, July 15, 2003 19:21:13 -0700 John-Mark Gurney <[EMAIL PROTECTED]> wrote: Larry Rosenman wrote this message on Tue, Jul 15, 2003 at 21:10 -0500: the fresh cvsup died in the same place, obviously. :-) Ok, this has been fixed and I have also fixed a few of the other usb modules that suffered the same problems. Builds should be working again. Looks like you missed at least one: ===> netgraph/bluetooth/ubt cc -O -pipe -mcpu=pentiumpro -g -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetoot h/include -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetoot h/drivers/ubt -Wall -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetoot h/include -I/usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetoot h/drivers/ubt -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c In file included from /usr/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:48: @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" *** Error code 1 Stop in /usr/src/sys/modules/netgraph/bluetooth/ubt. *** Error code 1 Stop in /usr/src/sys/modules/netgraph/bluetooth. *** Error code 1 Stop in /usr/src/sys/modules/netgraph. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/LERLAPTOP. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ^C [1] + Exit 1make kernel >& makekern.out lerlaptop# -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: escalation stage 2 [was:RE: Big and ugly bug in 5.1-release]
Julian Elischer wrote: > On Wed, 16 Jul 2003, Harald Schmalzbauer wrote: > > > Now after resetting the machine which was hung by "sysinstall" it claims > > that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see > dmesg below) > > mirrored by what? By ata. It is reognized as ar0 after setting it up in the controller's BIOS (in contrast to the DC-133 which needs to be configured with atacontrol for beeing recognized by the kernel with ar0) > > > Now the controller warns me that one drive is bad (which in fact is > > definatley not) and allows me to select "continue boot" > > Th controller is not controlled by FreeBSD. > If the controller says the drive is bad when you are in the BIOS, > Then it is bad. It's not. Like I said I did dozends of test before and whenever it claimd the harddrive to be bad a simple channel change (ad4 got ad6 and vice versa) solved this "error" message. But I also lost data, so this is no option rigth now!!! > > > > That's what I do and after kernel probing the machine reboots with the > > folowing error (well, this takes some time to typewrite it from > my monchrome > > screen): > > If you have another computer nearby, connect the serial cables together > (with a null-modem cable) and put > > console="comconsole" > > in file > /boot/loader.conf > > then your output will occur on the serial port . > then you will not have to type in the information. That'd work if boot2 would detect the serial console or with -h or the "dual flag". I had some experience with FreeBSD kernel and serial console the last fiew weeks (on a Soekris box) but not on a headless system. You see, I'm really in trouble Thank you, -Harry > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x10 > > fault code= supervisor read, page not present > > instruction pinter= 0x8:0xc014a0a6 > > stack pointer= 0x10:0xcce65bd8 > > frame pointer= 0x10:0xcce65c58 > > codesegment = base 0x0, limit 0xf type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags= interrupt enabled, resume, IOPL=0 > > current process = 4(g_down) > > trap number = 12 > > panic: page fault > > > > Then it reboots! > > > > Now please give me a hint what to do. This is my brand new > fileserver which > > collected all improtant data from the last decade and since > it's brand new I > > didn't manage any backup. > > When testing the hardware (unplugging one drive while the machine was > > running) I had the same error but I thought that would never > happen under > > normal circumstances. > > > > If sysinstall breakes a RAID1 server 5.1-RELEASE should be immediately > > replaced by a corrected version! > > FreeBSD 5.1 is a 'testing' release. you are warned not to use it for > production. If you do use it you must know how to upgrade your system > from there to correct bugs that may occur. > > > The message above comes from 'geom' which is the disk > handling code. It has had some work done recently so it may be that the > author ([EMAIL PROTECTED]) can help you, but it seens to me that you may > really have a disk problem. > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build broken by usbdivar.h 1.40
Larry Rosenman wrote this message on Tue, Jul 15, 2003 at 21:10 -0500: > the fresh cvsup died in the same place, obviously. :-) Ok, this has been fixed and I have also fixed a few of the other usb modules that suffered the same problems. Builds should be working again. > >>/usr/src/sys/dev/usb/if_aue.c > >>In file included from /usr/src/sys/dev/usb/if_aue.c:86: > >>@/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" > > > >Ok, this is what I need. Thanks. > > > >Fix to come shortly. -- John-Mark Gurney Voice: +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]"
FW: escalation stage 2 [was:RE: Big and ugly bug in 5.1-release]
*snip* > > Now the controller warns me that one drive is bad (which in fact is > > definatley not) and allows me to select "continue boot" > > If the controler says it's bad, it may well be. > > > Now please give me a hint what to do. This is my brand new > fileserver which > > collected all improtant data from the last decade and since > it's brand new I > > didn't manage any backup. > > When testing the hardware (unplugging one drive while the machine was > > running) I had the same error but I thought that would never > happen under > > normal circumstances. > > Are those disks installed in hotswap enclosures (they usually have > a keyswitch)? If not you probably hosed your disk. ATA is not > hotswapable! You are right that unplugging a _non-hotswappable_ ATA-disk isn't the best way to try out things but that was my only chance to test (BTW: with the Dawicontrol DC-133 (SIL0680) I had no problem, although FreeBSD completely ignored the BIOS-RAID settings) But now my current problem is that it's no longer any test environment, like mentioned it's my fileserver which crashed because I issued "/stand/sysinstall". Nad not only that it crashed the running environment it lso crashed the HPT372 RAID1. I think I can remember somone reporting a similar problem (with RAID-crash after a machine-crash) some time ago but I can't remember any answer/statement. For clarification: I did lots of tests with this controller and drives _before_ trusting my fileserver. But now I have a crash produced by software (the os, FreeBSD) which formerly I clould only produce by hardware misstreatment. One sulution would be to delete the RAID configuration in the controler's BIOS and set up another system on the (after that again available ad4) to backup data from ad6 but that's not really the intention af a RAID1 setup. Especially not on a server OS like FreeBSD Thanks, -Harry > > -- Brooks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build broken by usbdivar.h 1.40
Thanks, John-Mark. the fresh cvsup died in the same place, obviously. :-) LER --On Tuesday, July 15, 2003 19:09:26 -0700 John-Mark Gurney <[EMAIL PROTECTED]> wrote: Larry Rosenman wrote this message on Tue, Jul 15, 2003 at 21:06 -0500: I'm seeing the same thing, re-cvsup'd, and the kernel build is still running, but here is where mine died: ===> aue cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/usb/if_aue.c In file included from /usr/src/sys/dev/usb/if_aue.c:86: @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" Ok, this is what I need. Thanks. Fix to come shortly. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build broken by usbdivar.h 1.40
Larry Rosenman wrote this message on Tue, Jul 15, 2003 at 21:06 -0500: > I'm seeing the same thing, re-cvsup'd, and the kernel build is still > running, but here is where mine died: > > ===> aue > cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc > -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings > -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -fformat-extensions -std=c99 -c > /usr/src/sys/dev/usb/if_aue.c > In file included from /usr/src/sys/dev/usb/if_aue.c:86: > @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" Ok, this is what I need. Thanks. Fix to come shortly. -- John-Mark Gurney Voice: +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]"
Re: build broken by usbdivar.h 1.40
--On Tuesday, July 15, 2003 19:04:17 -0700 John-Mark Gurney <[EMAIL PROTECTED]> wrote: Pawel Worach wrote this message on Wed, Jul 16, 2003 at 03:51 +0200: @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" Could you please include more information? like what file? I just completed a build of usb (module) w/o problems. I'm seeing the same thing, re-cvsup'd, and the kernel build is still running, but here is where mine died: ===> aue cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/usb/if_aue.c In file included from /usr/src/sys/dev/usb/if_aue.c:86: @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" *** Error code 1 Stop in /usr/src/sys/modules/aue. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/LERLAPTOP. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. $ I'll post again if it dies again. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build broken by usbdivar.h 1.40
Pawel Worach wrote this message on Wed, Jul 16, 2003 at 03:51 +0200: > @/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" Could you please include more information? like what file? I just completed a build of usb (module) w/o problems. -- John-Mark Gurney Voice: +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]"
Re: escalation stage 2 [was:RE: Big and ugly bug in 5.1-release]
On Wed, 16 Jul 2003, Harald Schmalzbauer wrote: > Now after resetting the machine which was hung by "sysinstall" it claims > that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see dmesg below) mirrored by what? > Now the controller warns me that one drive is bad (which in fact is > definatley not) and allows me to select "continue boot" Th controller is not controlled by FreeBSD. If the controller says the drive is bad when you are in the BIOS, Then it is bad. > That's what I do and after kernel probing the machine reboots with the > folowing error (well, this takes some time to typewrite it from my monchrome > screen): If you have another computer nearby, connect the serial cables together (with a null-modem cable) and put console="comconsole" in file /boot/loader.conf then your output will occur on the serial port . then you will not have to type in the information. > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x10 > fault code= supervisor read, page not present > instruction pinter= 0x8:0xc014a0a6 > stack pointer=0x10:0xcce65bd8 > frame pointer=0x10:0xcce65c58 > 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 = 4(g_down) > trap number = 12 > panic: page fault > > Then it reboots! > > Now please give me a hint what to do. This is my brand new fileserver which > collected all improtant data from the last decade and since it's brand new I > didn't manage any backup. > When testing the hardware (unplugging one drive while the machine was > running) I had the same error but I thought that would never happen under > normal circumstances. > > If sysinstall breakes a RAID1 server 5.1-RELEASE should be immediately > replaced by a corrected version! FreeBSD 5.1 is a 'testing' release. you are warned not to use it for production. If you do use it you must know how to upgrade your system from there to correct bugs that may occur. The message above comes from 'geom' which is the disk handling code. It has had some work done recently so it may be that the author ([EMAIL PROTECTED]) can help you, but it seens to me that you may really have a disk problem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: escalation stage 2 [was:RE: Big and ugly bug in 5.1-release]
On Wed, Jul 16, 2003 at 03:47:25AM +0200, Harald Schmalzbauer wrote: > Now after resetting the machine which was hung by "sysinstall" it claims > that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see dmesg below) > Now the controller warns me that one drive is bad (which in fact is > definatley not) and allows me to select "continue boot" If the controler says it's bad, it may well be. > Now please give me a hint what to do. This is my brand new fileserver which > collected all improtant data from the last decade and since it's brand new I > didn't manage any backup. > When testing the hardware (unplugging one drive while the machine was > running) I had the same error but I thought that would never happen under > normal circumstances. Are those disks installed in hotswap enclosures (they usually have a keyswitch)? If not you probably hosed your disk. ATA is not hotswapable! -- Brooks pgp0.pgp Description: PGP signature
build broken by usbdivar.h 1.40
@/dev/usb/usbdivar.h:127: error: syntax error before "bus_dma_tag_t" -Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FFS_ROOT is gone?
John-Mark Gurney wrote: > Harald Schmalzbauer wrote this message on Wed, Jul 16, 2003 at > 02:58 +0200: > > Let's see what Tim can contribute to this topic, since he also > claimed to > > have problems with "mountroot>" > > I have a possible patch that might address people's problems with > mountroot. > > http://people.FreeBSD.org/~jmg/vfs_mount.diff > > try seeing if this patch improves things for you guys. Thanks a lot, I'll try this patch if i got my fileserver running back again. I hope this will ever be since there is my soekris image stored. Currently I don't have the time reproducing all teh stuff again. Thank you, -Harry > > -- > 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]"
escalation stage 2 [was:RE: Big and ugly bug in 5.1-release]
Now after resetting the machine which was hung by "sysinstall" it claims that ad4 (one of two mirrored 30GB 2.5" disks" was absent (see dmesg below) Now the controller warns me that one drive is bad (which in fact is definatley not) and allows me to select "continue boot" That's what I do and after kernel probing the machine reboots with the folowing error (well, this takes some time to typewrite it from my monchrome screen): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code= supervisor read, page not present instruction pinter= 0x8:0xc014a0a6 stack pointer= 0x10:0xcce65bd8 frame pointer= 0x10:0xcce65c58 codesegment = base 0x0, limit 0xf type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 4(g_down) trap number = 12 panic: page fault Then it reboots! Now please give me a hint what to do. This is my brand new fileserver which collected all improtant data from the last decade and since it's brand new I didn't manage any backup. When testing the hardware (unplugging one drive while the machine was running) I had the same error but I thought that would never happen under normal circumstances. If sysinstall breakes a RAID1 server 5.1-RELEASE should be immediately replaced by a corrected version! (Controller is a Dawicontrol DC-100 with HPT372 chipset and 2.343 BIOS, the original 2.34 BIOS didn't work at all with FreeBSD (while it did with Windows98)) The machine is the VIA Fileserver like dmesg'ed below Best regards, -Harry P.S: Now it has not only ad6 in the following message but also ad4 (and that always has been the reason for the panic during my testings!) (watch out the four ad4 and only two ad6) Opened disk ad4 -> 1 Opened disk ad4 -> 1 Opened disk ad4 -> 1 Opened disk ad4 -> 1 Opened disk ad6 -> 1 Opened disk ad6 -> 1 > Dear all, > > I'm experimenting with 5.1-REL for some weeks and during that time I had > some mysterious hangs which I didn't take serious because I modified > /usr/src/sys/cam/scsi/scsi_da.c to support my CF-Card-Reader. > But now I saw exactly the same problem on my brand new (and cosidered by > hardware extremely different) fileserver. > > The machine freezes for about one minute and then reboots itself > withut any > error message. > It happens when I do a "/stand/sysinstall" or a "sysctl -a" > > This is VERY ugly because when my fileserver dies my workstation also died > (home was nfs-mounted) > > I'm no developer, but if someone tells me what to do I'll help > solving that > BUG. > > Here is some info about my two machines (which are running 5.1-release and > showed the same bug): > > VIA FIleserver > > FreeBSD 5.1-RELEASE #2: Fri Jul 4 14:02:06 CEST 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPIA > Preloaded elf kernel "/boot/kernel/kernel" at 0xc04c. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04c01f4. > Timecounter "i8254" frequency 1192944 Hz > Timecounter "TSC" frequency 800032401 Hz > CPU: VIA C3 Samuel 2 (800.03-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x67a Stepping = 10 > Features=0x803035 > real memory = 266272768 (253 MB) > avail memory = 253374464 (241 MB) > VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc00c8ac8 (c0008ac8) > VESA: Copyright 1998 TRIDENT MICROSYSTEMS INC. > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > pcibios: BIOS version 2.10 > Using $PIR table, 5 entries at 0xc00fdc70 > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI-safe" frequency 3579545 Hz > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_cpu0: port 0x530-0x537 on acpi0 > acpi_tz0: port 0x530-0x537 on acpi0 > acpi_button0: on acpi0 > pcib0: port > 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcf > f on acpi0 > pci0: on pcib0 > agp0: mem 0xd000-0xd3ff at device > 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pci1: at device 0.0 (no driver attached) > isab0: at device 17.0 on pci0 > isa0: on isab0 > atapci0: port 0xc000-0xc00f at > device 17.1 on > pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > uhci0: port 0xc400-0xc41f irq 5 at device 17.2 > on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xc800-0xc81f irq 5 at device 17.3 > on pci0 > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > pci0: at device 17.4 (no driver attached) > pcm0: port > 0xd400-0xd403,0xd000-0xd003,0xcc00-0xccff irq 12 > at device 17.5 on pci0 > pcm0: > vr0: port 0xd800-0xd8ff mem > 0xd800-0xd800
Re: FFS_ROOT is gone?
Harald Schmalzbauer wrote this message on Wed, Jul 16, 2003 at 02:58 +0200: > Let's see what Tim can contribute to this topic, since he also claimed to > have problems with "mountroot>" I have a possible patch that might address people's problems with mountroot. http://people.FreeBSD.org/~jmg/vfs_mount.diff try seeing if this patch improves things for you guys. -- John-Mark Gurney Voice: +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]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, Jul 15, 2003 at 09:35:18PM +0200, Thomas Moestl wrote: > On Tue, 2003/07/15 at 12:04:56 -0700, Marcel Moolenaar wrote: > > On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: > > > Marcel Moolenaar <[EMAIL PROTECTED]> writes: > > > > It needs to be analyzed because cross-builds should not fail. Do > > > > we have a machine problem? What exactly is dumping core? Is it > > > > gzip or some binary started immediately after it? If it's gzip, > > > > is there a relation with the recent compiler warning about strncmp? > > > > > > It's not a machine problem if it only happens to the sparc64 build - > > > the same machine runs all the other -CURRENT tinderboxen except > > > powerpc. > > > > It does not only happen to sparc64. I've seen it fail for all but > > i386 and pc98, I think. > > i386 and pc98 have failed too (random example: July 5). > > - Thomas It's been doing this for weeks now. I wonder if this is a malloc debugging problem that was introduced somehow. Kris pgp0.pgp Description: PGP signature
Patches for XFree86 for FreeBSD/amd64
I have the X server up and running on my machine at work, I'm currently using it in a desktop configuration (although not my primary desktop yet because I still need to have a place to finish off some kernel optimizations). The first patch is against ports/x11/XFree86-4-libraries: http://people.freebsd.org/~peter/amd64-libraries.diff The second is against ports/x11-servers/XFree86-4-server: http://people.freebsd.org/~peter/amd64-server.diff You need to patch both, because the imake config files come from the libraries port and is used in the server build. I've submitted these to the port maintainer, so hopefully something might get committed soon. Most of the rest of the diffs are to either add amd64 support to the FreeBSD configuration, or to fix XFree86 bugs where they assume that all amd64 systems are implicitly Linux based. These patches are very minimal and really need somebody with more knowledge of the XFree86 internals to go over them. But it should be enough to get up and running to play around with it. I'm using a MGA G450 at work FWIW. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FFS_ROOT is gone?
Bernd Walter wrote: > > On Wed, Jul 16, 2003 at 02:38:18AM +0200, Harald Schmalzbauer wrote: > > *snip* > > > > > > The machine rebooted. No matter if I did "?" or any "ufs:xxYz". It's > > > > behaviour was like "empty line". > > > > > > That's the normal behavour if the line can't be parsed. > > > IIRC you can't correct typos on that line. > > > Even if a line corrected with backspace looks good - it is not. > > > > I'm very sure that I had a few attempts without any misstype > because I tried > > that some dozends and I was aware that I didn't use any backspace > > Another chance might be garbadge that went in. > E.g. I had a terminal server sending stop bytes when the kernel starts, > because the network was a bit to slow. > You'll never see those bytes because they are non-printable, but they > are there. That's really possible because my connection was a 38400 serial with a 3 meter cable. I had lots of line mesh with that connection. But it would mean that *all* my attempts had line failures, which could be possible but like I said they were near countless, so chances are good that at least one was correct?!?!? Let's see what Tim can contribute to this topic, since he also claimed to have problems with "mountroot>" > > -- > B.Walter BWCThttp://www.bwct.de > [EMAIL PROTECTED] [EMAIL PROTECTED] > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Big and ugly bug in 5.1-release
Dear all, I'm experimenting with 5.1-REL for some weeks and during that time I had some mysterious hangs which I didn't take serious because I modified /usr/src/sys/cam/scsi/scsi_da.c to support my CF-Card-Reader. But now I saw exactly the same problem on my brand new (and cosidered by hardware extremely different) fileserver. The machine freezes for about one minute and then reboots itself withut any error message. It happens when I do a "/stand/sysinstall" or a "sysctl -a" This is VERY ugly because when my fileserver dies my workstation also died (home was nfs-mounted) I'm no developer, but if someone tells me what to do I'll help solving that BUG. Here is some info about my two machines (which are running 5.1-release and showed the same bug): VIA FIleserver FreeBSD 5.1-RELEASE #2: Fri Jul 4 14:02:06 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPIA Preloaded elf kernel "/boot/kernel/kernel" at 0xc04c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04c01f4. Timecounter "i8254" frequency 1192944 Hz Timecounter "TSC" frequency 800032401 Hz CPU: VIA C3 Samuel 2 (800.03-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x67a Stepping = 10 Features=0x803035 real memory = 266272768 (253 MB) avail memory = 253374464 (241 MB) VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc00c8ac8 (c0008ac8) VESA: Copyright 1998 TRIDENT MICROSYSTEMS INC. npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 5 entries at 0xc00fdc70 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_tz0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xc400-0xc41f irq 5 at device 17.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 5 at device 17.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 17.4 (no driver attached) pcm0: port 0xd400-0xd403,0xd000-0xd003,0xcc00-0xccff irq 12 at device 17.5 on pci0 pcm0: vr0: port 0xd800-0xd8ff mem 0xd800-0xd8ff irq 10 at device 18.0 on pci0 vr0: Ethernet address: 00:40:63:c2:9d:af miibus0: on vr0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xec00-0xecff,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc07 irq 11 at device 20.0 on pci0 ata2: at 0xdc00 on atapci1 ata3: at 0xe400 on atapci1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A orm0: at iomem 0xd-0xd9fff,0xcc000-0xc,0xc-0xcbfff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ad6: 28615MB [58140/16/63] at ata3-master UDMA100 acd0: MODE_SENSE_BIG trying to write on read buffer acd0: MODE_SENSE_BIG - NO SENSE asc=0x00 ascq=0x00 error=0x04 acd0: CDROM at ata1-slave PIO4 ar0: WARNING - mirror lost ar0: 28615MB [3647/255/63] status: DEGRADED subdisks: disk0 READY on ad6 at ata3-master Opened disk ad6 -> 1 Opened disk ad6 -> 1 Opened disk ad6 -> 1 Opened disk ad6 -> 1 Mounting root from ufs:/dev/ar0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted # Intel Workstation ## FreeBSD 5.1-RELEASE #2: Tue Jul 8 01:08:36 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel "/boot/kernel/kernel" at 0xc04c7000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04c721c. Timecounter "i8254" frequency 1193267 Hz Timecounter "TSC" frequency 737075599 Hz CPU: Intel Pentium III (737.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 267300864 (254 MB) avail memory = 254337024 (242 MB) Pentium Pro MTRR support enabled VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc03f8922 (122) VESA: Intel(R) 810, Intel(R) 815 Chipset Video BIOS npx0: on motherboard npx0: INT 16
Re: FFS_ROOT is gone?
On Wed, Jul 16, 2003 at 02:38:18AM +0200, Harald Schmalzbauer wrote: > *snip* > > > > The machine rebooted. No matter if I did "?" or any "ufs:xxYz". It's > > > behaviour was like "empty line". > > > > That's the normal behavour if the line can't be parsed. > > IIRC you can't correct typos on that line. > > Even if a line corrected with backspace looks good - it is not. > > I'm very sure that I had a few attempts without any misstype because I tried > that some dozends and I was aware that I didn't use any backspace Another chance might be garbadge that went in. E.g. I had a terminal server sending stop bytes when the kernel starts, because the network was a bit to slow. You'll never see those bytes because they are non-printable, but they are there. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FFS_ROOT is gone?
*snip* > > The machine rebooted. No matter if I did "?" or any "ufs:xxYz". It's > > behaviour was like "empty line". > > That's the normal behavour if the line can't be parsed. > IIRC you can't correct typos on that line. > Even if a line corrected with backspace looks good - it is not. I'm very sure that I had a few attempts without any misstype because I tried that some dozends and I was aware that I didn't use any backspace *snip* > > booting the kernel with only boot0, no loader. > > > > Has this feature been intentionally removed? > > The loader sets variables that are required for the kernel to run > such as reading device.hints. > You can still compile the variables staticaly into the kernel and > directly use boot2 (boot0 is the bootmanager). Ahhh, of course there is a new device.hint. Ok. I'll try that some time. (boot0 was wrong, I meant the stage taht usually loads the loader, like you said boot0!) Thanks, -Harry > > -- > B.Walter BWCThttp://www.bwct.de > [EMAIL PROTECTED] [EMAIL PROTECTED] > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bug in devinfo -u: 'open if_tun units'
I've found what looks like it might be a bug in devinfo - listing resources by type, there are far too many 'open if_tun unit' resources: there are over 126,000 lines, repeating 0 (root0) 1-32767 (root0) for about 500 lines, before there's another 'open if_tun units:' header. The file produced by 'devinfo -u > devinfo.log' is 2MB. I've got 2 if_tun interfaces running. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
On Wed, Jul 16, 2003 at 01:47:59AM +0200, Harald Schmalzbauer wrote: > Bernd Walter wrote: > > On Tue, Jul 15, 2003 at 12:22:31PM -0700, Tim Kientzle wrote: > > > Harald Schmalzbauer wrote: > > > >The problem is solved. It was stupid, but I thought why should > > I have to > > > >set > > > >/ in /etc/fstab when the filesystem isn't mounted yet, so the > > file can't be > > > >read. > > > >But it seems the kernel reads this file "loader-like" *before* the > > > >filesystem is mounted. > > > > > > I believe that the loader actually reads this file (it > > > has to be able to locate and read files from UFS anyway > > > in order to load the kernel) and passes the root f/s > > > information to the kernel when it boots. This should > > > probably be documented in fstab(5) > > > > You can pass a filesystem at the loader prompt: > > vfs.root.mountfrom="" > > > > > >Considering the above to be correct I can't understand the > > ability to enter > > > >e. g. ufs:/dev/ad0a at "mountroot>" when it doesn't work. > > > > > > I've also been stung by the fact that the > > > "mountroot>" prompt is broken. > > > I looked briefly at the code, but the > > > bug is not particularly obvious. > > > > At least it wasn't broken a while ago. > > What happens exactly after entering the correct device? > > The machine rebooted. No matter if I did "?" or any "ufs:xxYz". It's > behaviour was like "empty line". That's the normal behavour if the line can't be parsed. IIRC you can't correct typos on that line. Even if a line corrected with backspace looks good - it is not. > That was mine dunno about Tim's > > Regarding loader reades /etc/fstab: Of course loader and even boot can read > from ufs but I verified that current device was disk0s1 (where my 165-ID > was) and also something like root-mount was set to disk0s1. > > Next thing is that boot0 could'nt boot my kernel (5.1-release). > Some time ago I built a little accesspoint with 4.6 and there was no problem > booting the kernel with only boot0, no loader. > > Has this feature been intentionally removed? The loader sets variables that are required for the kernel to run such as reading device.hints. You can still compile the variables staticaly into the kernel and directly use boot2 (boot0 is the bootmanager). -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Broadcom NetXtreme BCM5705M support
Of all the gin joints in all the towns in all the world, Boris Georgiev had to walk into mine and say: > Hi Bill, > > Sorry for the previous e-mail, but have in mind that I'm trying to cooperate > by testing your drivers and > I am not aware of the rules for declaring a hardware problem in the mailing > lists. The only way I can send > you the messages from the kernel is if I rewrite them from the console. I know that. But that's a small price to pay for free driver development. :) > Here is the information that you requested: > > bge0: mem > 0x9000-0x9000 irq 11 at device 14.0 on pci2 > bge0: firmware handshake timed out > bge0: RX CPU self-diagnostics failed! > bge0: chip initialization failed > device_probe_and_attach: bge0 attach returned 6 > > If you need more detailed information, I can send it to you on request. Ok, the firmware handshake does not really load any firmware. This just checks that the firmware on the NIC has responded to a reset and is back up and running. The error here is due to the fact that the firmware initialization seems to take longer on the 5705, so the timeout has to be increased. Thanks for a couple of other people, I have made changes to deal with this. Please download the latest driver code from the same URL (http://www.freebsd.org/~wpaul/Broadcom/5705). This should fix the problem with the timeout, as well as a few other things. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FFS_ROOT is gone?
Bernd Walter wrote: > On Tue, Jul 15, 2003 at 12:22:31PM -0700, Tim Kientzle wrote: > > Harald Schmalzbauer wrote: > > >The problem is solved. It was stupid, but I thought why should > I have to > > >set > > >/ in /etc/fstab when the filesystem isn't mounted yet, so the > file can't be > > >read. > > >But it seems the kernel reads this file "loader-like" *before* the > > >filesystem is mounted. > > > > I believe that the loader actually reads this file (it > > has to be able to locate and read files from UFS anyway > > in order to load the kernel) and passes the root f/s > > information to the kernel when it boots. This should > > probably be documented in fstab(5) > > You can pass a filesystem at the loader prompt: > vfs.root.mountfrom="" > > > >Considering the above to be correct I can't understand the > ability to enter > > >e. g. ufs:/dev/ad0a at "mountroot>" when it doesn't work. > > > > I've also been stung by the fact that the > > "mountroot>" prompt is broken. > > I looked briefly at the code, but the > > bug is not particularly obvious. > > At least it wasn't broken a while ago. > What happens exactly after entering the correct device? The machine rebooted. No matter if I did "?" or any "ufs:xxYz". It's behaviour was like "empty line". That was mine dunno about Tim's Regarding loader reades /etc/fstab: Of course loader and even boot can read from ufs but I verified that current device was disk0s1 (where my 165-ID was) and also something like root-mount was set to disk0s1. Next thing is that boot0 could'nt boot my kernel (5.1-release). Some time ago I built a little accesspoint with 4.6 and there was no problem booting the kernel with only boot0, no loader. Has this feature been intentionally removed? Best regards, -Harry > > -- > B.Walter BWCThttp://www.bwct.de > [EMAIL PROTECTED] [EMAIL PROTECTED] > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Trouble with ACPI and ASUS MB
On Wed, Jul 16, 2003 at 12:57:38AM +0200, Stefan E?er wrote: > On 2003-07-14 20:33 -0400, Scott Robbins <[EMAIL PROTECTED]> wrote: > > I installed 5.1 RELEASE on a box with an ASUS A7A266 motherboard. Not > > > > > > > > ACPI power-off failed - timeout > > The operating system has halted > > Press any key to reboot > > Try > > sysctl hw.acpi.disable_on_poweroff=0 Bingo. That fixed it, thank you so much. Most sincerely, -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Riley: Way I heard it. You were all peaceable now. You didn't by any chance go and lose that pesky soul again, did you? Angel: Don't push me, boy. Riley: Now what possibly could've happened with Buffy that would make you lose your soul? Angel: That'd be between me and her. Riley: Where do you think you're going? Angel: Going to see an old girlfriend. pgp0.pgp Description: PGP signature
Re: Trouble with ACPI and ASUS MB
On 2003-07-14 20:33 -0400, Scott Robbins <[EMAIL PROTECTED]> wrote: > I installed 5.1 RELEASE on a box with an ASUS A7A266 motherboard. Not > having done enough reading, I had put device apm in the kernel and added > apmd_enable="YES" to /etc/rc.conf. > > The box wouldn't turn off in response to shutdown -p. I then looked > through NOTES and added device acpi, which fixed the problem. > > However, on IRC, someone with far more knowledge than myself mentioned > that this could be dangerous. As it is a test box, he asked that I cvsup > CURRENT and see if adding > > acpi_load="YES" to /boot/loader.conf (and removing the apm stuff, as > well as the device acpi) would fix the problem. > > It didn't. For the heck of it, I then tried recompiling the kernel with > the device acpi put back in, despite the possible dangers, but it didn't > work either. kldstat shows that the acip module is loaded. The error > that I get is ACPI timed out. > > ACPI power-off failed - timeout > The operating system has halted > Press any key to reboot Try sysctl hw.acpi.disable_on_poweroff=0 and put the assignment into /etc/sysctl.conf, if it makes a difference ... (It does, on my system ...) Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
At Tue, 15 Jul 2003 11:54:06 -0700,
David O'Brien wrote:
> Much, much better if you can point to the specific GCC source code file
> where this is handled.
May this help you?
waterblue% cat exp.c
int
main(int argc, char** argv)
{
int exp = 5;
return 0;
}
waterblue% cc -Wshadow -c exp.c
exp.c: In function `main':
exp.c:4: warning: declaration of `exp' shadows a global declaration
:0: warning: shadowed declaration is here
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
On Tue, Jul 15, 2003 at 12:22:31PM -0700, Tim Kientzle wrote: > Harald Schmalzbauer wrote: > >The problem is solved. It was stupid, but I thought why should I have to > >set > >/ in /etc/fstab when the filesystem isn't mounted yet, so the file can't be > >read. > >But it seems the kernel reads this file "loader-like" *before* the > >filesystem is mounted. > > I believe that the loader actually reads this file (it > has to be able to locate and read files from UFS anyway > in order to load the kernel) and passes the root f/s > information to the kernel when it boots. This should > probably be documented in fstab(5) You can pass a filesystem at the loader prompt: vfs.root.mountfrom="" > >Considering the above to be correct I can't understand the ability to enter > >e. g. ufs:/dev/ad0a at "mountroot>" when it doesn't work. > > I've also been stung by the fact that the > "mountroot>" prompt is broken. > I looked briefly at the code, but the > bug is not particularly obvious. At least it wasn't broken a while ago. What happens exactly after entering the correct device? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Broadcom NetXtreme BCM5705M support
Hi Bill, Sorry for the previous e-mail, but have in mind that I'm trying to cooperate by testing your drivers and I am not aware of the rules for declaring a hardware problem in the mailing lists. The only way I can send you the messages from the kernel is if I rewrite them from the console. Here is the information that you requested: bge0: mem 0x9000-0x9000 irq 11 at device 14.0 on pci2 bge0: firmware handshake timed out bge0: RX CPU self-diagnostics failed! bge0: chip initialization failed device_probe_and_attach: bge0 attach returned 6 If you need more detailed information, I can send it to you on request. Boris Georgiev > Uh > > First of all, the driver does not load any firmware into the chip. > > Second, you're not supposed to tell me your interpretation of what > happened: you're supposed to cut&paste the messages into an e-mail > so that I can see for myself what happened. > > Please show me all of the information that led you to your conclusion > that this alleged firmware upload failed. > > > It gave me out > > an timeout message and didn't load the driver at all. I am sorry that at > > this time I cannot send > > the exact message from the kernel, but the notbook is at my office, so I > > will post it > > tomorrow if the output will help for finding out what the problem is. > > Best regards, > > Ok, note to all reading this: if I ask for information and you don't > have the information available, don't bother sending me an e-mail > just to tell me that you don't have the information available. Wait > until you do have the information available, and then e-mail me. You'll > save precious time and electrons. > > -Bill ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Marcel Moolenaar <[EMAIL PROTECTED]> writes: > It does not only happen to sparc64. I've seen it fail for all but > i386 and pc98, I think. Interestingly, the latest sparc64 tinderbox succeeded. > The first question is: what process is dumping core. I think > you'll find that with dmesg(8). [EMAIL PROTECTED] ~% bzgrep dumped /var/log/messages* /var/log/messages:Jul 15 14:04:24 cueball kernel: pid 6864 (make), uid 722: exited on signal 4 (core dumped) /var/log/messages.0.bz2:Jul 14 07:53:19 cueball kernel: pid 44991 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.1.bz2:Jul 12 05:49:04 cueball kernel: pid 6340 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.1.bz2:Jul 12 13:31:23 cueball kernel: pid 69880 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.1.bz2:Jul 12 14:14:47 cueball kernel: pid 57456 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.2.bz2:Jul 9 14:08:23 cueball kernel: pid 4991 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.2.bz2:Jul 10 07:34:54 cueball kernel: pid 36133 (make), uid 722: exited on signal 10 (core dumped) /var/log/messages.3.bz2:Jul 6 18:08:46 cueball kernel: pid 43705 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.3.bz2:Jul 6 18:48:30 cueball kernel: pid 11632 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.3.bz2:Jul 7 19:29:31 cueball kernel: pid 94081 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 4 16:39:11 cueball kernel: pid 43256 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 5 15:09:59 cueball kernel: pid 24880 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 5 15:50:31 cueball kernel: pid 3662 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 6 03:26:28 cueball kernel: pid 45681 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.4.bz2:Jul 6 04:09:28 cueball kernel: pid 24332 (make), uid 722: exited on signal 11 (core dumped) /var/log/messages.5.bz2:Jul 3 16:13:22 cueball kernel: pid 7543 (make), uid 722: exited on signal 10 (core dumped) [EMAIL PROTECTED] ~% id uid=722(des) gid=722(des) groups=722(des) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, Jul 15, 2003 at 09:35:43PM +0200, Harti Brandt wrote: > On Tue, 15 Jul 2003, Marcel Moolenaar wrote: > > MM>On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: > MM> > MM>> There's not much more I can say about it until I see the full > MM>> log from the next run; the last one broke at a different point. > MM> > MM>The first question is: what process is dumping core. I think > MM>you'll find that with dmesg(8). > > For more than one week the sparc build dumps core at different points > while compressing man pages. Perhaps a gzip problem? Likely, but not guaranteed. I don't know if gzip has finish if the coredump happens. I don't even know if the tinderboxes are parallel. The point is that I can not explain the failure as being caused by cross-build bugs if it's gzip. Since I did a cross-build yesterday without problems, but also without rescue I can not entirely rule out that rescue still has a cross-build bug. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, 15 Jul 2003, Thomas Moestl wrote: TM>On Tue, 2003/07/15 at 12:04:56 -0700, Marcel Moolenaar wrote: TM>> On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: TM>> > Marcel Moolenaar <[EMAIL PROTECTED]> writes: TM>> > > It needs to be analyzed because cross-builds should not fail. Do TM>> > > we have a machine problem? What exactly is dumping core? Is it TM>> > > gzip or some binary started immediately after it? If it's gzip, TM>> > > is there a relation with the recent compiler warning about strncmp? TM>> > TM>> > It's not a machine problem if it only happens to the sparc64 build - TM>> > the same machine runs all the other -CURRENT tinderboxen except TM>> > powerpc. TM>> TM>> It does not only happen to sparc64. I've seen it fail for all but TM>> i386 and pc98, I think. TM> TM>i386 and pc98 have failed too (random example: July 5). But sparc64 fails quite regularily when gziping man pages. The others are more random. Since about the same time I have dumping core make during make universe on my i386. The core shows differnt signals (4, 10, even SIGILL), but always in vfork(). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, 15 Jul 2003, Marcel Moolenaar wrote: MM>On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: MM> MM>> There's not much more I can say about it until I see the full MM>> log from the next run; the last one broke at a different point. MM> MM>The first question is: what process is dumping core. I think MM>you'll find that with dmesg(8). For more than one week the sparc build dumps core at different points while compressing man pages. Perhaps a gzip problem? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, 2003/07/15 at 12:04:56 -0700, Marcel Moolenaar wrote: > On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: > > Marcel Moolenaar <[EMAIL PROTECTED]> writes: > > > It needs to be analyzed because cross-builds should not fail. Do > > > we have a machine problem? What exactly is dumping core? Is it > > > gzip or some binary started immediately after it? If it's gzip, > > > is there a relation with the recent compiler warning about strncmp? > > > > It's not a machine problem if it only happens to the sparc64 build - > > the same machine runs all the other -CURRENT tinderboxen except > > powerpc. > > It does not only happen to sparc64. I've seen it fail for all but > i386 and pc98, I think. i386 and pc98 have failed too (random example: July 5). - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
On Tue, 15 Jul 2003, Tim Kientzle wrote: > David O'Brien wrote: > > Gordon, 'make world' times have climbed up to over 1 hour on a machine > > that used to do it in 25 minutes. Can you please commit to understanding > > how /resuce is build and optimizing it ... > > Just out of curiosity, I timed 'buildworld' to > see what impact /rescue really has. These are > all approximate timings on my desktop machine: > > without /rescue: 47:30 > with original /rescue: 50:12 > with optimized /rescue: 50:10 My machine is a laptop and thus disk IO is a killer. Your numbers are much better than what I've seen. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FFS_ROOT is gone?
Harald Schmalzbauer wrote: The problem is solved. It was stupid, but I thought why should I have to set / in /etc/fstab when the filesystem isn't mounted yet, so the file can't be read. But it seems the kernel reads this file "loader-like" *before* the filesystem is mounted. I believe that the loader actually reads this file (it has to be able to locate and read files from UFS anyway in order to load the kernel) and passes the root f/s information to the kernel when it boots. This should probably be documented in fstab(5) Considering the above to be correct I can't understand the ability to enter e. g. ufs:/dev/ad0a at "mountroot>" when it doesn't work. I've also been stung by the fact that the "mountroot>" prompt is broken. I looked briefly at the code, but the bug is not particularly obvious. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overdone rescue cleaning as part of buildworld?
David O'Brien wrote: Gordon, 'make world' times have climbed up to over 1 hour on a machine that used to do it in 25 minutes. Can you please commit to understanding how /resuce is build and optimizing it ... Just out of curiosity, I timed 'buildworld' to see what impact /rescue really has. These are all approximate timings on my desktop machine: without /rescue: 47:30 with original /rescue: 50:12 with optimized /rescue: 50:10 Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, Jul 15, 2003 at 09:00:17PM +0200, Dag-Erling Sm?rgrav wrote: > Marcel Moolenaar <[EMAIL PROTECTED]> writes: > > It needs to be analyzed because cross-builds should not fail. Do > > we have a machine problem? What exactly is dumping core? Is it > > gzip or some binary started immediately after it? If it's gzip, > > is there a relation with the recent compiler warning about strncmp? > > It's not a machine problem if it only happens to the sparc64 build - > the same machine runs all the other -CURRENT tinderboxen except > powerpc. It does not only happen to sparc64. I've seen it fail for all but i386 and pc98, I think. > There doesn't seem to be anything wrong with the sources > either. I tend to agree. > There's not much more I can say about it until I see the full > log from the next run; the last one broke at a different point. The first question is: what process is dumping core. I think you'll find that with dmesg(8). -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Marcel Moolenaar <[EMAIL PROTECTED]> writes: > It needs to be analyzed because cross-builds should not fail. Do > we have a machine problem? What exactly is dumping core? Is it > gzip or some binary started immediately after it? If it's gzip, > is there a relation with the recent compiler warning about strncmp? It's not a machine problem if it only happens to the sparc64 build - the same machine runs all the other -CURRENT tinderboxen except powerpc. There doesn't seem to be anything wrong with the sources either. There's not much more I can say about it until I see the full log from the next run; the last one broke at a different point. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Tue, Jul 15, 2003 at 07:50:06PM +0200, Dag-Erling Sm?rgrav wrote: > Harti Brandt <[EMAIL PROTECTED]> writes: > > Is there any specific reason that the sparc64 tinderbox permanently dumps > > core? I have no problem here to build world on my sparcs. > > Remember, this is a cross-build... It needs to be analyzed because cross-builds should not fail. Do we have a machine problem? What exactly is dumping core? Is it gzip or some binary started immediately after it? If it's gzip, is there a relation with the recent compiler warning about strncmp? In other words: what the fuck is going on and why doesn't anybody do something about it? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: FFS_ROOT is gone?
Bernd Walter wrote: > On Sat, Jul 12, 2003 at 02:22:41AM +0200, Harald Schmalzbauer wrote: > > Hello, > > > > my kernel (5.1-REL) can't mount root (mountroot>) on my CF-card although > > it's booting fine and I can mount the card on my USB card reader. > > I had a look at GENERIC and saw that I didn't miss the option > FFS_ROOT but > > it doesn't exist any longer. > > Any ideas why I can't mount root? > > Any messages? > -can't mount- ist sparse input. > Does it mount the volume without being rootfs? The problem is solved. It was stupid, but I thought why should I have to set / in /etc/fstab when the filesystem isn't mounted yet, so the file can't be read. But it seems the kernel reads this file "loader-like" *before* the filesystem is mounted. Considering the above to be correct I can't understand the ability to enter e. g. ufs:/dev/ad0a at "mountroot>" when it doesn't work. But everything is fine now, thank you for your answer. Best regards, -Harry > > -- > B.Walter BWCThttp://www.bwct.de > [EMAIL PROTECTED] [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: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
On Tue, Jul 15, 2003 at 07:59:43AM +0200, Harti Brandt wrote: > I would call this a compiler bug. It shouldn't declare exp(3) when you > don't include math.h. As I understand the standard the names in math.h are > only reserved when you include math.h. I remember that an earlier version > of gcc had this bug, that was fixed then. Probably they unfixed it again. > > What's the chance of getting this fixed? Much, much better if you can point to the specific GCC source code file where this is handled. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-07-15 17:20:54 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-07-15 17:20:54 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 17:22:59 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. [...] gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/strsep.3 > strsep.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/strspn.3 > strspn.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/strstr.3 > strstr.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/strtok.3 > strtok.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/strxfrm.3 > strxfrm.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/swab.3 > swab.3.gz gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libc/string/wcscoll.3 > wcscoll.3.gz Illegal instruction (core dumped) *** Error code 132 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-07-15 18:04:24 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 18:04:24 - ERROR: failed to build world TB --- 2003-07-15 18:04:24 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Harti Brandt <[EMAIL PROTECTED]> writes: > Is there any specific reason that the sparc64 tinderbox permanently dumps > core? I have no problem here to build world on my sparcs. Remember, this is a cross-build... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help diagnosing NIS breakage ?
> > > > On a client bound to this server, please do: > > > > % ypwhich -m > > > > > > Thanks for getting back to me on this. First off, apologies if I'd > > > failed to mention the server before...Now, on a -CURRENT NIS client > > > (with rev 1.81 > > > getpwent.c): > > > $ ypwhich -m > > > shadow dc3 > > > passwd.byuid dc3 > > [...] > > > > Ok, so it does support the YPPROC_MASTER procedure. Let's try > > something a little different. This time, do: > > > > % ypwhich -m master.passwd.byname > > > > And show the results. Might as well try ypwhich -m > > master.passwd.byuid too, though the result will probably be the same. > > > OkUsing getpwent.c v1.82 with your diff: > > # id robin > id: robin: no such user > # ypwhich -m master.passwd.byname > dc3 > # ypwhich -m master.passwd.byuid > dc3 [...] AGH Ok, first, whoever is responsible for this NIS server implementation is an idiot. It appears the YPPROC_MASTER procedure does no argument validation and always returns success even for maps that don't exist. This is why revision 1.182 fails in your case: using yp_master() to check for the master.passwd maps succeeds, which makes the code think it should be doing master.passwd lookups (which ultimately fail when the actual lookup is performed). Fortunately, it looks like YPPROC_ORDER works correctly: [EMAIL PROTECTED] [~]$ ypwhich GCDC2.gc.nat [EMAIL PROTECTED] [~]$ ypwhich -m master.passwd.byname dc3 [EMAIL PROTECTED] [~]$ yppoll master.passwd.byname yppoll: no such map master.passwd.byname. Reason: No such map in server's domain [EMAIL PROTECTED] [~]$ yppoll passwd.byname Map passwd.byname has order number 10683. Wed Dec 31 21:58:03 1969 The master server is dc3. Second, I'm an idiot because I made a mistake in the patch I provided: the nis_map() function should return NS_UNAVAIL if yp_order() fails, rather than falling through and returning NS_SUCCESS all the time. I uploaded a new diff, please test this instead: http://www.freebsd.org/~wpaul/getpwent.diff Thanks for providing me access to this machine, it helped me realize where I'd gone wrong in my patch. If this works for you, and if nobody objects, I will check it in. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = "If stupidity were a handicap, you'd have the best parking spot." = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DEVICE_POLLING not in NOTES?
On Tue, Jul 15, 2003 at 06:01:49PM +0200, Roderick van Domburg wrote: > Is there any particular reason DEVICE_POLLING is no longer available > in NOTES? (Or should I say isn't linted any more? :-) It still > appears to be available in fxp et al. It is in /usr/src/sys/i386/conf/NOTES rev 1.1089 and ends up in LINT... -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-07-15 17:01:54 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-07-15 17:01:54 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 17:03:44 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `do_challenge': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_radius/pam_radius.c:206: warning: passing arg 1 of `free' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-07-15 17:20:54 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 17:20:54 - ERROR: failed to build world TB --- 2003-07-15 17:20:54 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Buildworld fails in 5.1
Just installed 5.1 yesterday, cvsuped using the . tag, and src-all /etc/make.conf untouched. I attempted to buildworld and I get the following ranlib libc_pic.a ranlib libc.a ranlib libc_p.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libc.a /usr/obj/usr/sr c/i386/usr/lib sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libc_p.a /usr/obj/usr/ src/i386/usr/lib sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 libc.so.5 /usr/obj/u sr/src/i386/usr/lib ln -fs libc.so.5 /usr/obj/usr/src/i386/usr/lib/libc.so sh /usr/src/tools/install.sh -o root -g wheel -m 444 libc_pic.a /usr/obj/usr/s rc/i386/usr/lib 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Did not see an open pr or anything mentioned in mailing lists. Is this a known issue and should I file a pr, or is there a hack/workaround to fix this? Thanks rwz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-07-15 16:42:12 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-15 16:42:12 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 16:44:31 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include >>> stage 4: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -mcpu=pentiumpro -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `do_challenge': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_radius/pam_radius.c:206: warning: passing arg 1 of `free' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-07-15 17:01:53 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 17:01:53 - ERROR: failed to build world TB --- 2003-07-15 17:01:53 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on amd64/amd64
TB --- 2003-07-15 16:22:15 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-15 16:22:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 16:24:11 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `do_challenge': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_radius/pam_radius.c:206: warning: passing arg 1 of `free' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-07-15 16:42:11 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 16:42:11 - ERROR: failed to build world TB --- 2003-07-15 16:42:11 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SMP page update
I was wondering whether the SMPng page at http://www.freebsd.org/smp is updated as those features are added. Because it seems like no feature update for long. For instance is the preemptible kernel going to be a part of 5.x series or going to be left to 6.x? Thanks... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-07-15 16:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-15 16:00:00 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 16:03:29 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `do_challenge': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_radius/pam_radius.c:206: warning: passing arg 1 of `free' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-07-15 16:22:14 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 16:22:14 - ERROR: failed to build world TB --- 2003-07-15 16:22:14 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DEVICE_POLLING not in NOTES?
Is there any particular reason DEVICE_POLLING is no longer available in NOTES? (Or should I say isn't linted any more? :-) It still appears to be available in fxp et al. Regards, Roderick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
Is there any specific reason that the sparc64 tinderbox permanently dumps core? I have no problem here to build world on my sparcs. harti On Mon, 14 Jul 2003, Tinderbox wrote: T>TB --- 2003-07-14 11:12:19 - starting CURRENT tinderbox run for sparc64/sparc64 T>TB --- 2003-07-14 11:12:19 - checking out the source tree T>TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 T>TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src T>TB --- 2003-07-14 11:14:29 - building world T>TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src T>TB --- /usr/bin/make -B buildworld T Building an up-to-date make(1) T Rebuilding the temporary build tree T stage 1: legacy release compatibility shims T stage 1: bootstrap tools T stage 2: cleaning up the object tree T stage 2: rebuilding the object tree T stage 2: build tools T stage 3: cross tools T stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include T stage 4: building libraries T stage 4: make dependencies T stage 4: building everything.. T>[...] T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getnetent.3 > getnetent.3.gz T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getprotoent.3 > getprotoent.3.gz T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/getservent.3 > getservent.3.gz T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/hesiod.3 > hesiod.3.gz T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/if_indextoname.3 > if_indextoname.3.gz T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/inet.3 > inet.3.gz T>gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libc/net/inet_net.3 > inet_net.3.gz T>Bus error (core dumped) T>*** Error code 138 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. T>*** Error code 1 T> T>Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. T>TB --- 2003-07-14 11:53:19 - /usr/bin/make returned exit code 1 T>TB --- 2003-07-14 11:53:19 - ERROR: failed to build world T>TB --- 2003-07-14 11:53:19 - tinderbox aborted T> T>___ T>[EMAIL PROTECTED] mailing list T>http://lists.freebsd.org/mailman/listinfo/freebsd-current T>To unsubscribe, send any mail to "[EMAIL PROTECTED]" T>___ T>[EMAIL PROTECTED] mailing list T>http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 T>To unsubscribe, send any mail to "[EMAIL PROTECTED]" T> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI problem?
hi, the motherboard is Intel STL2, which works fine with 4.8-stable. just tried 5.1-current and it hangs on boot: BIOS drive A: is disk0 BIOS drive C: is disk1 PXE version 2.1, real mode entry point @9d3a:0106 BIOS 637kB/785344kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Tue Jul 15 17:13:47 IDT 2003) pxe_open: server addr: 132.65.16.23 pxe_open: server path: /roots/FreeBSD/i386-5.1 pxe_open: gateway ip: 132.65.16.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x42d0f4 data=0x78094+0x829e0 syms=[0x4+0x56520+0x4+0x65c75] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x39c14 data=0x1638+0xf68 syms=[0x4+0x5990+0x4+0x75d9] Copyright (c) 1992-2003 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 5.1-CURRENT #2: Tue Jun 24 15:51:59 IDT 2003 [EMAIL PROTECTED]:/r+d/obj/r+d/src/sys/HUJI Preloaded elf kernel "/boot/kernel/kernel" at 0xc073. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0730244. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 933074142 Hz CPU: Intel Pentium III (933.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 805240832 (767 MB) avail memory = 774459392 (738 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x404-0x407 on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-217.-7C) acpi_tz0: _ACx value is absurd, ignored (-247.-7C) acpi_tz1: on acpi0 acpi_tz1: _CRT value is absurd, ignored (-217.-7C) acpi_tz1: _ACx value is absurd, ignored (-247.-7C) acpi_tz2: on acpi0 acpi_tz2: _CRT value is absurd, ignored (-217.-7C) acpi_tz2: _ACx value is absurd, ignored (-247.-7C) acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTA is routed to irq 11 pcib0: slot 3 INTA is routed to irq 9 pcib0: slot 6 INTA is routed to irq 5 pcib0: slot 15 INTA is routed to irq 9 pci0: at device 2.0 (no driver attached) fxp0: port 0x1400-0x143f mem 0xf910-0xf91f,0xf9001000-0xf9001fff irq 9 at device 3.0 on pci0 fxp0: Ethernet address 00:d0:b7:b6:90:53 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto em0: port 0x1440-0x145f mem 0xf902-0xf903,0xf904-0xf905 irq 5 at device 6.0 on pci0 em0: Speed:N/A Duplex:N/A isab0: port 0x580-0x58f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1460-0x146f,0x374-0x377,0x170-0x177 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: mem 0xf9002000-0xf9002fff irq 9 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on acpi0 pci1: on pcib1 pcib1: slot 4 INTA is routed to irq 9 pcib1: slot 4 INTB is routed to irq 10 ahc0: port 0x1800-0x18ff mem 0xfb00-0xfb000fff irq 9 at device 4.0 on pci1 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x2000-0x20ff mem 0xfb001000-0xfb001fff irq 10 at device 4.1 on pci1 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 acpi_ec0: port 0xca7,0xca6 on acpi0 ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error: Could not release ACPI Global Lock, AE_BAD_PARAMETER ACPI-0340: *** Error:
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| | | | | bus handling is | | | | |
Re: ``Resource temporarily unavailable'' in vi
On Tue, 2003-07-15 at 13:45, Sheldon Hearn wrote: > It's expected if you don't have a process filesystem mounted on /proc. > > kldload procfs > mount_procfs /dev/procfs /proc Doh! I should have RTFM. Apologies. truss(1) : It does this by stopping and restarting the process being monitored via procfs(5) Thanks anyway. -- byron Bus error -- driver executed. signature.asc Description: This is a digitally signed message part
Re: ``Resource temporarily unavailable'' in vi
On (2003/07/15 13:35), Byron Schlemmer wrote: > Being the curious person that I am, I tried the following from the truss > manpage : > > % truss /bin/echo hello > truss: cannot open /proc/1805/mem: No such file or directory > truss: cannot open /proc/curproc/mem: No such file or directory > > Is this expected behaviour on -CURRENT or is it just me? It's expected if you don't have a process filesystem mounted on /proc. kldload procfs mount_procfs /dev/procfs /proc Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
On Tue, 2003-07-15 at 09:09, Terry Lambert wrote: > > One way to track this down, if it's that repeatable for everyone, > would be to open another terminal window, get the pid of the > program that's going to do this, and then: > > truss -p | grep "Resource temp" > > ...or just let it run to completion, and you'll get some context, > too, in your scrollback buffer. Being the curious person that I am, I tried the following from the truss manpage : % truss /bin/echo hello truss: cannot open /proc/1805/mem: No such file or directory truss: cannot open /proc/curproc/mem: No such file or directory Is this expected behaviour on -CURRENT or is it just me? More information : % ls -al /proc total 4 dr-xr-xr-x 2 root wheel 512 Jan 16 22:26 . drwxr-xr-x 17 root wheel 512 Jul 11 18:46 .. % file `which truss` /usr/bin/truss: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.0.1, dynamically linked (uses shared libs), stripped % uname -a FreeBSD nemesis.work 5.1-RELEASE FreeBSD 5.1-RELEASE #5: Fri Jun 27 12:52:43 SAST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEMESIS i386 -- byron Bus error -- driver executed. signature.asc Description: This is a digitally signed message part
Re: acpi: iasl errors
On Tue, 15 Jul 2003 12:43:21 + (UTC) [EMAIL PROTECTED] (David Hill) wrote: > Hello - > I am trying to create a custom acpi dsdt for my Dell Inspiron 2650. Does anyone > know how to correct these Errors and Warnings? > > Thanks > David > > wind# acpidump -o dell.dsdt > dell.asl > wind# iasl -d dell.dsdt > wind# iasl dell.dsl > > Intel ACPI Component Architecture > ASL Optimizing Compiler / AML Disassembler version 20030522 [Jul 15 2003] > Copyright (C) 2000 - 2003 Intel Corporation > Supports ACPI Specification Revision 2.0b > > dell.dsl 132: Method (\_WAK, 1, NotSerialized) > Warning 2026 - ^ Reserved method must return a value (_WAK) > > dell.dsl 1019: SRST, 1, > Error1051 -^ Access width of Field Unit extends beyond > region limit > > dell.dsl 1022: ACPW, 1 > Error1051 -^ Access width of Field Unit extends beyond > region limit > > dell.dsl 2373: Field (ERAM, AnyAcc, Lock, Preserve) > Error1048 - ^ Host Operation Region requires > ByteAcc access > > dell.dsl 2874: Name (PBUF, Buffer (0x14) > Warning 2079 - Statement is unreachable ^ > > ASL Input: dell.dsl - 3644 lines, 136006 bytes, 1734 keywords > Compilation complete. 3 Errors, 2 Warnings, 0 Remarks, 388 Optimizations > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" Nevermind, I fixed it :) http://www.cpqlinux.com/acpi-howto.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
acpi: iasl errors
Hello - I am trying to create a custom acpi dsdt for my Dell Inspiron 2650. Does anyone know how to correct these Errors and Warnings? Thanks David wind# acpidump -o dell.dsdt > dell.asl wind# iasl -d dell.dsdt wind# iasl dell.dsl Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20030522 [Jul 15 2003] Copyright (C) 2000 - 2003 Intel Corporation Supports ACPI Specification Revision 2.0b dell.dsl 132: Method (\_WAK, 1, NotSerialized) Warning 2026 - ^ Reserved method must return a value (_WAK) dell.dsl 1019: SRST, 1, Error1051 -^ Access width of Field Unit extends beyond region limit dell.dsl 1022: ACPW, 1 Error1051 -^ Access width of Field Unit extends beyond region limit dell.dsl 2373: Field (ERAM, AnyAcc, Lock, Preserve) Error1048 - ^ Host Operation Region requires ByteAcc access dell.dsl 2874: Name (PBUF, Buffer (0x14) Warning 2079 - Statement is unreachable ^ ASL Input: dell.dsl - 3644 lines, 136006 bytes, 1734 keywords Compilation complete. 3 Errors, 2 Warnings, 0 Remarks, 388 Optimizations ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ACPI / HP Omnibook 500
Hi all. After a a long time I tried ACPI again with -CURRENT as of yesterday. On my HP Omnibook 500 I still have problems using ACPI. The machine works fine, but I have the annoying problem, that I cannot see the battery level (well, mostly).I think this is mainly a problem with the DSDT,it's borken as so often. I have no real clue about ASL and so I was able to change my DSDT in the way that a) I could compile it using iasl and b) I can see the battery level at least when switching from acline to battery or vice versa - but I'm not really able to fix it in terms of "I understand what I'm doing here". Sorry for the mail being very long, but I try to provide as much information as possible here. I'd even be willing to give people interested in debugging this an account on the machine and then have a phone session (to plug/unplug power and change DSDTs or whatever is needed). You'll find the asl files here: original: http://the.addict.de/~ob/hp500.asl changed:http://the.addict.de/~ob/hp500-ob.asl The dmesg output for booting both cases can be found here: original: http://the.addict.de/~ob/dmesg-orig.out changed DSDT: http://the.addict.de/~ob/dmesg-ob.out I have hw.acpi.verbose=1 The details in the behaviour of the machine when booting with the original DSDT: The machine says to have acline, although it's running on battery. I have one battery. The battery is charged somewhat about 50% (I can see this when booting with APM). The battery display gives no values. sysctl hw.acpi says the folloing: hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 1 hw.acpi.disable_on_poweroff: 1 hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 8 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3162 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3582 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3782 hw.acpi.thermal.tz0._ACx: 3432 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.acline: 1 hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 3 hw.acpi.battery.info_expire: 5 After 5 Minutes of uptime I see no change. I have the following ACPI errors in the console: acpi_cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_cmbat1: battery initialization start acpi_cmbat2: battery initialization start acpi_cmbat0: battery initialization failed, giving up acpi_ec0: EcCommand: no response to 0x81 ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_.SMRD] (Node 0xc25dd520), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_.SMSL] (Node 0xc25dd4c0), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_._Q09] (Node 0xc25dd420), AE_NO_HARDWARE_RESPONSE acpi_cmbat1: battery initialization failed, giving up acpi_cmbat2: battery initialization failed, giving up When plugging power in the following error messages appear: acpi_ec0: EcCommand: no response to 0x80 ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE acpi_ec0: EcCommand: no response to 0x80 ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_.SMRD] (Node 0xc25dd520), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.BAT1.UPBI] (Node 0xc25e0ec0), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.BAT1.CHBP] (Node 0xc25e0e40), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_.SMSL] (Node 0xc25dd4c0), AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_._Q09] (Node 0xc25dd420), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcCommand: no response to 0x80 ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_._Q20] (Node 0xc25dd400), AE_AML_NO_RETURN_VALUE nothing changes in sysctl hw.acpi when unplugging power again, there are notable changes: acpi_ec0: EcCommand: no response to 0x80 ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE acpi_ec0: EcCommand: no response to 0x80 ACPI-0438
Re: [-CURRENT tinderbox] failure on i386/i386
- Tinderbox's Original Message - > >>> Building an up-to-date make(1) > >>> Kernel build for LINT started on Tue Jul 15 07:38:30 GMT 2003 > [...] > dbdisply.o: In function `AcpiDbDisplayArguments': > dbdisply.o(.text+0x69c): undefined reference to `AcpiDmDisplayArguments' > dbdisply.o: In function `AcpiDbDisplayResults': > dbdisply.o(.text+0x772): undefined reference to `AcpiDmDisplayInternalObject' > dbdisply.o: In function `AcpiDbDisplayResultObject': > dbdisply.o(.text+0x99c): undefined reference to `AcpiDmDisplayInternalObject' > dbdisply.o: In function `AcpiDbDisplayArgumentObject': > dbdisply.o(.text+0xa0c): undefined reference to `AcpiDmDisplayInternalObject' > *** Error code 1 > This is also occuring during the build of an amd64 kernel. Has anyone looked at this yet? While removing the kernel debugger fixes the link issue, I think having the debugger present is rather useful at this point :-) -john ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
Mark Murray wrote: > Mikhail Teterin writes: > > Every once in a while, a vi-session dies on me with: > > > > input: Resource temporarily unavailable > > > > What does it mean, why does it happen, and how can I prevent it? > > > > Thanks a lot! > > > > -mi > > > > P.S. Running recent -current. > > I'm seeing this on current. I use bash, and the machine is not > loaded. The heaviest process is spamassassin. There isn't even X running > on the box. This caught my eye as I think I saw a simlar message on one of my boxes ( I run 4.5 4.7 4.8 & 5.1 here) for me it was a 10M ether coax connector I'd forgotten to rotate tight (it was just sitting on), causing amd problems to a crontab job, for you maybe your $HOME/.nexrc is on another machine with intermittent net failure. Whatever the cause of your problem, How to trace: Too often on FreeBSD lists one sees error messages treated as great mysteries, but they're often not ! Perhaps we all forget at times but" "Use The Source" ! The curse of Microsfoft "No Source Here" does not apply :-) Use find & grep (I use my script: http://berklix.com/~jhs/bin/.csh/Grep ) Grep "Resource temporarily unavailable" ) contrib/isc-dhcp/common/errwarn.c: return "Resource temporarily unavailable"; contrib/isc-dhcp/omapip/errwarn.c: return "Resource temporarily unavailable"; contrib/sendmail/mail.local/mail.local.c: case EAGAIN: /* Resource temporarily unavailable */ contrib/sendmail/src/conf.c:case EAGAIN: /* Resource temporarily unavailable */ lib/libc/gen/errlst.c:"Resource temporarily unavailable", /* 35 - EAGAIN */ lib/libc/sys/intro.2:.It Er 35 EAGAIN Em "Resource temporarily unavailable" . share/examples/mdoc/example.3:Resource temporarily unavailable. sys/i386/isa/pcvt/pcvt_sup.c: * will cause an EAGAIN (resource temporarily unavailable) to be returned. sys/sys/errno.h:#define EAGAIN 35 /* Resource temporarily unavailable */ Grep on your current; tweak each text occurence differently, EG add a debug number, make world; then you can report &/or investigate where error originates. - Julian Stacey Freelance Systems Engineer, Unix & Net Consultant, Munich. Ihr Rauchen => mein allergischer Kopfschmerz ! Schnupftabak probieren. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1, new warnings with
David Leimbach wrote: > >Gcc needs a #pragma to disable specific warnings as a one-shot. > > > >This was discussed in detail on the GCC mailing list. > > True... but I don't think I was talking about a one-shot disabling > of the message. > > I was thinking more about how a compliant C++ compiler can determine > the signedness of a datatype without type introspection or type > metadata available at compile time. [which seems to be what > numeric_limits is all about doesn't it?] I don't think there's a good answer available that's also portable. What you need is an implementation that doesn't care about the signedness of the type. You could do some really ugly tricks that would work. For example, calling a helper function with the same argument twice, and setting one of the arguments to zero, and using *that* to do the compare (the types would always match). using two compares swapping the values would tell you what you needed. You'd probably want to mark the helper private, or at least protected, and call it something like "_docompare" to put it in the implementation space. As I said... really ugly tricks. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SV: current iso snapshots
-Ursprungligt meddelande- Fran: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Brooks Davis http://snapshots.jp.freebsd.org/ Or http://snapshots.se.freebsd.org Matt Douhan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-07-15 09:44:13 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-15 09:44:13 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 09:46:47 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `do_challenge': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius/pam_radius.c:206: warning: passing arg 1 of `free' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-07-15 10:04:04 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 10:04:04 - ERROR: failed to build world TB --- 2003-07-15 10:04:04 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-07-15 09:22:47 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-07-15 09:22:47 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 09:25:54 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4: building libraries [...] ===> lib/libpam/modules/pam_permit cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_permit/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_permit/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_permit/pam_permit.c building static pam_permit library ranlib libpam_permit.a ===> lib/libpam/modules/pam_radius cc -O -pipe -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_radius/../../../../contrib/openpam/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_radius/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_radius/pam_radius.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_radius/pam_radius.c: In function `do_challenge': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_radius/pam_radius.c:206: warning: passing arg 1 of `free' discards qualifiers from pointer target type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules/pam_radius. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpam. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-07-15 09:44:12 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 09:44:12 - ERROR: failed to build world TB --- 2003-07-15 09:44:12 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
Mark Murray wrote: > Mikhail Teterin writes: > > Every once in a while, a vi-session dies on me with: > > > > input: Resource temporarily unavailable > > > > What does it mean, why does it happen, and how can I prevent it? > > I'm seeing this on current. I use bash, and the machine is not > loaded. The heaviest process is spamassassin. There isn't even X running > on the box. One way to track this down, if it's that repeatable for everyone, would be to open another terminal window, get the pid of the program that's going to do this, and then: truss -p | grep "Resource temp" ...or just let it run to completion, and you'll get some context, too, in your scrollback buffer. Knowing what system call is failing would be very helpful toward tracking the problem down. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
On Mon, Jul 14, 2003 at 10:46:43PM +0200, Andreas Klemm wrote: > On Mon, Jul 14, 2003 at 10:38:44PM +0200, Thorsten Greiner wrote: > > > > You can work around this by unsetting SESSION_MANAGER in your > > > > environment. I have no idea what the root cause is... > > > > > > Where can I get rid of this variable ? I see no easy way. > > > Currently I use gvim as default text editor within KDE > > > environment ... > > > > > > In an xterm or such I could disable it, but how for KDE ?? > > > > As far as I understand it, this variable is set by the session management of the > > respective desktop (KDE in your case, GNOME in mine). Maybe you can workaround the > > problem by using a small shell script which unsets SESSION_MANAGER and than calls > > gvim? > > Yes I will try to write a wrapper script around gvim. > This way ... > > mv vim vim.bin > cat > vim <<- EOF > unset SESSION_MANAGER > vim.bin > EOF > chmod 555 vim > FWIW, the new behaviour of vim is caused by patch 6.2.015. I added 015 to BADPATCHES in the ports Makefile and reinstalled. gvim works as usual now. Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SSH Secure Shell 3.2.3 with openldap fails
Hi, I am trying to use openldap with nss_ldap and pam_ldap. I have the login, imap-uw and xdm working fine. But, it fails to work with SSH Secure Shell 3.2.3. I am using FreeBSD 5.1-CURRENT #0: Thu Jul 3 13:01:40 PDT 2003. With ldap in nsswitch.conf, I get the following: Jul 15 01:13:43 man-97-187 sshd[460]: connection from "169.229.97.187" Jul 15 01:13:57 man-97-187 sshd[9368]: Wrong password given for user 'lou'. Jul 15 01:14:04 man-97-187 sshd[9368]: Local disconnected: Connection closed. Jul 15 01:14:04 man-97-187 sshd[9368]: connection lost: 'Connection closed.' Without ldap in nsswitch.conf, I get the following: Jul 15 01:13:12 man-97-187 sshd[460]: connection from "169.229.97.187" Jul 15 01:13:16 man-97-187 sshd[9349]: User lou's local password accepted. Jul 15 01:13:16 man-97-187 sshd[9349]: Password authentication for user lou accepted. Jul 15 01:13:16 man-97-187 sshd[9349]: User lou, coming from man-97-187.Reshall.Berkeley.EDU, authenticated. Jul 15 01:13:16 man-97-187 sshd2[9357]: Now running on lou's privileges. --- Lou ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ed0 pccard device broken in current
Hello anybody, I'm experiencing the same problems that Mark described here http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1049372+0+/usr/local/www/db/text/2003/freebsd-current/20030706.freebsd-current with my edN-pccard on a kernel cvsupped on sunday. Shortly after mounting my build directory via NFS I get ed: packets buffered, but transmitter idle. and the interface hangs. The Kernel from 5.1-RELEASE (FreeBSD uran.wg-net 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003) works fine. Since the last change in if_ed-Code was about three months ago, I am also suspecting a problem with pccardd code. If I will still experience the problem next weekend, I will build several kernels in order to find out exactly when ed stopped working. Since I am one of those Java/Ruby/Python/SQL-guys, this is all I can do. Bye Matt -- Mattias Schlenker / Tel 0851 9441369 oder 0160 7352988 Freyunger Str. 42 / http://webweaver.de/ilw/ 94034 Passau / http://webweaver.de/mattias/ ++ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Process stats wrong under ULE
On Mon, Jul 14, 2003 at 11:16:14PM -0700, Kris Kennaway wrote: > I'm seeing the following kind of behaviour under ULE on a UP machine > (kernel updated earlier this evening). Notice that the total CPU% > adds up to way more than 100%; indeed one single process is allegedly > using more than 100% CPU, and (not clear from the top(1) output) the > processes that are sleeping do not have their CPU% updated until the > next time they run. > > Kris Also, there still appears to be a problem with nice processes. I run a nice 20 dnetc client, and it is interfering with the ability to play movies with mplayer at nice -10. The movie plays in spurts, as if it is still relinquishing the CPU to dnetc for fractions of a second. Killing dnetc restores mplayer performance. This is not a problem with SCHED_4BSD. Kris pgp0.pgp Description: PGP signature
Re: Process stats wrong under ULE
On Tue, Jul 15, 2003 at 09:08:24AM +0200, Ian Freislich wrote: > Kris Kennaway wrote: > > I'm seeing the following kind of behaviour under ULE on a UP machine > > (kernel updated earlier this evening). Notice that the total CPU% > > adds up to way more than 100%; indeed one single process is allegedly > > using more than 100% CPU, and (not clear from the top(1) output) the > > processes that are sleeping do not have their CPU% updated until the > > next time they run. > > Jeff is aware of this and has said it is on his list of things to > fix. Not sure where on his list it is though. OK, thanks! Kris pgp0.pgp Description: PGP signature
Re: Vim: Caught deadly signal BUS (after -current update withnewgcc)
Thorsten Greiner wrote: > As far as I understand it, this variable is set by the session management > of the respective desktop (KDE in your case, GNOME in mine). Maybe you > can workaround the problem by using a small shell script which unsets > SESSION_MANAGER and than calls gvim? Probably it would be better to fix the bug. 8-) 8-). No, I don't use "vim", sorry... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:
On Mon, Jul 14, 2003 at 09:51:25PM +0200, Thorsten Greiner wrote: > Andreas wrote: > > [EMAIL PROTECTED] ~ vim > > Vim: Caught deadly signal BUS > > Vim: Finished. > > Bus error (core dumped) > > You can work around this by unsetting SESSION_MANAGER in your > environment. I have no idea what the root cause is... > Thanks, this works for me. At least I can use gvim again. Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-07-15 06:18:18 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-15 06:18:18 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-15 06:20:28 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-15 07:24:08 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Building an up-to-date make(1) >>> Kernel build for GENERIC started on Tue Jul 15 07:24:08 GMT 2003 >>> Kernel build for GENERIC completed on Tue Jul 15 07:38:29 GMT 2003 TB --- 2003-07-15 07:38:29 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-15 07:38:29 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Building an up-to-date make(1) >>> Kernel build for LINT started on Tue Jul 15 07:38:30 GMT 2003 [...] dbdisply.o: In function `AcpiDbDisplayArguments': dbdisply.o(.text+0x69c): undefined reference to `AcpiDmDisplayArguments' dbdisply.o: In function `AcpiDbDisplayResults': dbdisply.o(.text+0x772): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayResultObject': dbdisply.o(.text+0x99c): undefined reference to `AcpiDmDisplayInternalObject' dbdisply.o: In function `AcpiDbDisplayArgumentObject': dbdisply.o(.text+0xa0c): undefined reference to `AcpiDmDisplayInternalObject' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-07-15 07:50:58 - /usr/bin/make returned exit code 1 TB --- 2003-07-15 07:50:58 - ERROR: failed to build lint kernel TB --- 2003-07-15 07:50:58 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Process stats wrong under ULE
Kris Kennaway wrote: > I'm seeing the following kind of behaviour under ULE on a UP machine > (kernel updated earlier this evening). Notice that the total CPU% > adds up to way more than 100%; indeed one single process is allegedly > using more than 100% CPU, and (not clear from the top(1) output) the > processes that are sleeping do not have their CPU% updated until the > next time they run. Jeff is aware of this and has said it is on his list of things to fix. Not sure where on his list it is though. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DDNS strangeness
Tom Parquette wrote: > > Hi. I'm not sure if this belongs somewhere else but I'm starting here > since these are 5.x systems. > Please CC me on any replies. I subscribe to the digest format (makes > replying difficult.) TIA. > > I have DDNS running between my house server and what will become an X > desktop. > They are both 5.x at different maintenance levels. > I have it updating the DNS server as I expect when I boot the X desktop. > If I have to boot the server, e.g. my town's unpredictable power, the X > desktop machine cannot re-add itself to my DNS. man nsupdate -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Belkin USB2serial F5U103
Guenter Doerrhoefer wrote: > According to the release note the Belkin F5U103 should be supported. I > could not get it to operate, the device is recognized but cannot be > configured. Anyone got the Belkin to cooperate with 5.2-current? > > We tried several other adapters (not mentioned in the release note) and > found that they work without problems: > M-CAB USB-serial adapter cable and M-CAB USB2.0-serial adapter cable > > Hint for programming: The port UCOMn mounted by the USBA-driver must > remain open after settings are made, otherwise the settings are lost > when port is closed. You should contact Belkin. In the past, they have bent over backward to be compatible with FreeBSD; they even revised their firmware in their KVM switches to deal with FreeBSDs overly anal keyboard probing code. Some people on these lists don't like their products, but IMO they've always been a friend to FreeBSD. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
