Re: using tip on machine that has COMCONSOLE set to serial
Don Bowman wrote: This may be a dumb question, but I have a situation where machine A and B both have enabled serial console. I'm ssh'ing into A to try and debug a problem on B. I'm trying to use tip, but am getting interference from the fact that A also has a serial console. If i disable the getty, its a bit better. Is there a way to make this work reliably, or am I SOL? Use or modify a getty to require multiple CR's to activate. Or use one that only activates on a break. Best would be to use a getty that respected lock files, needed 2 CR's to start after off-to-on DTR/DCD transition (you will be using a NULL-modem cable), and your tip/cu/whatever program did appropriate locking, and knew how to back off. Then you could put the getty's back-to-back and they would not chat each other to death, and you could call out of the one machine into the other, and your local getty would not eat half the characters. See also uugetty and mgetty in ports. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
latest -CURRENT kernel fails to build
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/pcic/i82365.c /usr/src/sys/dev/pcic/i82365.c: In function `pcic_chip_do_mem_map': /usr/src/sys/dev/pcic/i82365.c:850: error: structure has no member named `offset' /usr/src/sys/dev/pcic/i82365.c:855: error: structure has no member named `offset' /usr/src/sys/dev/pcic/i82365.c: In function `pcic_chip_mem_map': /usr/src/sys/dev/pcic/i82365.c:928: error: structure has no member named `offset' *** Error code 1 Stop in /usr/obj/usr/src/sys/BIGBANG. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [EMAIL PROTECTED] [10:59pm][/home/vince] Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
It seems Joachim Strömbergson wrote: Thanks! I guess I'm too impatient these days... Yes, it works after waiting for about 30 seconds. So a correction, it doesn't hang, it's just slow when detecting :). So now the tousand dollar question becomes What in the boot contains a timeout around 30 seconds, a timout that lately has been committed/ctivated in the kernel code? Well, the ATA driver has just grown more standard compliant :) You *must* hang around for 31secs to wait for slow devices to come ready, according to the ATA specs. Now I've gone to great length before to get around this by using clever heuristics, and I'm getting there again, but there are *so* many crappy devices out there that it takes time to accomodate them all. So if you experience long boot delays or misprobes, please boot verbose and mail me the output from dmesg with a subject of ATA probe fails and a short description of what is wrong, and I'll try to work in a solution for the problem. (And no I wont ever go the white/black-list route as others have gone). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
Joachim Strömbergson wrote: So now the tousand dollar question becomes What in the boot contains a timeout around 30 seconds, a timout that lately has been committed/ctivated in the kernel code? SCSI has one of these; are you compiling with ATAPICAM? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
Aloha! Terry Lambert wrote: Joachim Strömbergson wrote: So now the tousand dollar question becomes What in the boot contains a timeout around 30 seconds, a timout that lately has been committed/ctivated in the kernel code? SCSI has one of these; are you compiling with ATAPICAM? Nope. No ATAPICAM anywhere near my system. .-) Note that the changes to the src that triggered this appeared quite recently, somewhere between 2003-09-01 and 2003-09-16, according to my builds and reboots. I think Sören is on the right track that it's related to ATA probe timeout. I checked the cvs logs and there are new timeout code that relates to ATA probing. I will do a verbose reboot and get the interesting dmesg part to him. -- Med vänlig hälsning, Cheers! Joachim Strömbergson Joachim Strömbergson - ASIC designer, nice to *cute* animals. snail: phone: mail web: Sävenäsgatan 5A+46 31 - 27 98 47 [EMAIL PROTECTED] 416 72 Göteborg+46 733 75 97 02 www.ludd.luth.se/~watchman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
In message [EMAIL PROTECTED], Bruce Evans writes: This is either disk corruption or an ffs bug. ffs passes the garbage block number 0xe5441ae9720 to bread. GEOM then handles this austerely by panicing. Garbage block numbers, including negative ones, can possibly be created by applications seeking to preposterous offsets, so they should not be handled with panics. They most certainly should! If the range checking in any filesystem is not able to catch these cases I insist that GEOM do so with a panic. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Still problems with ATAPI
(dmesg.boot attached) ATAng will no longer recognize the DVD-ROM device on ata1-master. This is without atapicam. The CD-RW drive at ata1-slave is OK, and is being assigned to acd0 now. Incidentally, when did the hw.ata.* sysctls change? 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 #1: Wed Sep 17 01:15:08 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL Preloaded elf kernel /boot/kernel/kernel at 0xa0459000. Preloaded elf module /boot/modules/ipfw.ko at 0xa0459200. Preloaded elf module /boot/modules/miibus.ko at 0xa04592ac. Preloaded elf module /boot/modules/if_fxp.ko at 0xa0459358. Preloaded elf module /boot/modules/snd_pcm.ko at 0xa0459404. Preloaded elf module /boot/modules/snd_es137x.ko at 0xa04594b4. Preloaded elf module /boot/modules/random.ko at 0xa0459564. Preloaded elf module /boot/modules/acpi.ko at 0xa0459610. Preloaded elf module /boot/modules/aio.ko at 0xa04596bc. Preloaded elf module /boot/modules/lpt.ko at 0xa0459768. Preloaded elf module /boot/modules/ppi.ko at 0xa0459814. Calibrating clock(s) ... i8254 clock: 1193271 Hz Timecounter i8254 frequency 1193271 Hz quality 0 Calibrating TSC clock ... TSC clock: 998142849 Hz CPU: AMD Athlon(tm) Processor (998.14-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x622 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc040AMIE,DSP,3DNow! Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00482000 - 0x1f6c9fff, 522485760 bytes (127560 pages) avail memory = 516546560 (492 MB) bios32: Found BIOS32 Service Directory header at 0xa00f7a70 bios32: Entry = 0xfd6d0 (a00fd6d0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6d0+0x11e pnpbios: Found PnP BIOS data at 0xa00f7a40 pnpbios: Entry = f:9a6a Rev = 1.0 pnpbios: OEM ID 46b1110e Other BIOS signatures found: mem: memory I/O Pentium Pro MTRR support enabled null: null device, zero device random: entropy source npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x80006004 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=70061022) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xa00fdf20 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 03A 0x04 3 4 5 6 7 10 11 12 14 15 slot 1 03B 0x01 3 4 5 6 7 10 11 12 14 15 slot 1 03C 0x02 3 4 5 6 7 10 11 12 14 15 slot 1 03D 0x03 3 4 5 6 7 10 11 12 14 15 slot 2 04A 0x01 3 4 5 6 7 10 11 12 14 15 slot 2 04B 0x02 3 4 5 6 7 10 11 12 14 15 slot 2 04C 0x03 3 4 5 6 7 10 11 12 14 15 slot 2 04D 0x04 3 4 5 6 7 10 11 12 14 15 slot 3 09A 0x02 3 4 5 6 7 10 11 12 14 15 slot 3 09B 0x03 3 4 5 6 7 10 11 12 14 15 slot 3 09C 0x04 3 4 5 6 7 10 11 12 14 15 slot 3 09D 0x01 3 4 5 6 7 10 11 12 14 15 slot 4 06A 0x03 3 4 5 6 7 10 11 12 14 15 slot 4 06B 0x04 3 4 5 6 7 10 11 12 14 15 slot 4 06C 0x01 3 4 5 6 7 10 11 12 14 15 slot 4 06D 0x02 3 4 5 6 7 10 11 12 14 15 slot 5 0 15A 0x04 3 4 5 6 7 10 11 12 14 15 slot 5 0 15B 0x01 3 4 5 6 7 10 11 12 14 15 slot 5 0 15C 0x02 3 4 5 6 7 10 11 12 14 15 slot 5 0 15D 0x03 3 4 5 6 7 10 11 12 14 15 embedded0 12A 0x01 3 4 5 6 7 10 11 12 14 15 embedded07A 0x01 3 4 5 6 7 10 11 12 14 15 embedded07D 0x04 3 4 5 6 7 10 11 12 14 15 embedded00A 0x01 3 4 5 6 7 9 10 11 12 14 15 embedded00B 0x02 3 4 5 6 7 9 10 11 12 14 15 embedded00C 0x03 3 4 5 6 7 9 10 11 12 14 15 embedded00D 0x04 3 4 5 6 7 9 10 11 12 14 15 embedded01A 0x02 3 4 5 6 7 10 11 12 14 15 embedded01B 0x03 3 4 5 6 7 10 11 12 14 15 embedded15A 0x02 3 4 5 6 7 10 11 12 14 15 embedded15B 0x03 3 4 5 6 7 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 0, max = 16777214, width = 16777214 ACPI timer looks BAD min = 1, max = 16777215, width = 16777214 ACPI timer looks BAD min = 0, max =
Re: Still problems with ATAPI
It seems Conrad J. Sabatier wrote: ATAng will no longer recognize the DVD-ROM device on ata1-master. This is without atapicam. The CD-RW drive at ata1-slave is OK, and is being assigned to acd0 now. OK, from you dmesg: ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0xd0 err=0x04 lsb=0x00 msb=0x00 ata1-slave: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata1-master: stat=0xd0 err=0x04 lsb=0x00 msb=0x00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 mask=03 stat0=00 stat1=10 devices=0xcATAPI_SLAVE,ATAPI_MASTER Here we se that the probe code correctly identifies both ATAPI devices. ata1: spurious interrupt - status=0x50 error=0x00 ata1-slave: pio=0x0c wdma=0x22 udma=0x cable=40pin ata1-master: pio=0x0c wdma=0x22 udma=0x46 cable=80pin ata1: spurious interrupt - status=0x58 error=0x00 Above we see the problems begin with those spurious interrupts, since they have gathered status and error the ATA channel was NOT active when they occured, ie they have not been asked to do anything, and that is probably why the next phase of the probe fails... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is either disk corruption or an ffs bug. ffs passes the garbage block number 0xe5441ae9720 to bread. GEOM then handles this austerely by panicing. Garbage block numbers, including negative ones, can possibly be created by applications seeking to preposterous offsets, so they should not be handled with panics. They most certainly should! If the range checking in any filesystem is not able to catch these cases I insist that GEOM do so with a panic. What is wrong with returning an IO error? I always hated panics because of filesystem corruptions. An alternative would be to just bring that filesystem down. Its easy to panic a whole system with a bogus filesystem on a removeable media. -- 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: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
In message [EMAIL PROTECTED], Bernd Walter writes: On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is either disk corruption or an ffs bug. ffs passes the garbage block number 0xe5441ae9720 to bread. GEOM then handles this austerely by panicing. Garbage block numbers, including negative ones, can possibly be created by applications seeking to preposterous offsets, so they should not be handled with panics. They most certainly should! If the range checking in any filesystem is not able to catch these cases I insist that GEOM do so with a panic. What is wrong with returning an IO error? I always hated panics because of filesystem corruptions. An alternative would be to just bring that filesystem down. Its easy to panic a whole system with a bogus filesystem on a removeable media. I hate panics too, but this would be an indication of a serious filesystem error, so a panic is in order. Otherwise we would be unlikely to ever receive a report which would allow us to fix the problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
On Wed, Sep 17, 2003 at 10:30:15AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bernd Walter writes: On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is either disk corruption or an ffs bug. ffs passes the garbage block number 0xe5441ae9720 to bread. GEOM then handles this austerely by panicing. Garbage block numbers, including negative ones, can possibly be created by applications seeking to preposterous offsets, so they should not be handled with panics. They most certainly should! If the range checking in any filesystem is not able to catch these cases I insist that GEOM do so with a panic. What is wrong with returning an IO error? I always hated panics because of filesystem corruptions. An alternative would be to just bring that filesystem down. Its easy to panic a whole system with a bogus filesystem on a removeable media. I hate panics too, but this would be an indication of a serious filesystem error, so a panic is in order. Otherwise we would be unlikely to ever receive a report which would allow us to fix the problem. Don't you think that people will report them if the filesystem is automatically unmounted? Accepted that's not an option for the GEOM point and that panicing here can be good to fix range checking in the filesystem. -- 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: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
In message [EMAIL PROTECTED], Bernd Walter writes: Don't you think that people will report them if the filesystem is automatically unmounted? We can't sensibly do that. Accepted that's not an option for the GEOM point and that panicing here can be good to fix range checking in the filesystem. That's the point: Our filesystems should be robust. If they're not they should be fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Mike Jakubik [EMAIL PROTECTED] writes: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Apparently, yes. No. 3.6.1 has the same bug, and 3.7 isn't out yet. 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: Release Engineering Status Report
David Rhodus [EMAIL PROTECTED] writes: On Tuesday, September 16, 2003, at 11:54 AM, Dag-Erling Smørgrav wrote: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Umm, yeah, so after today are we going to get a new import into RELENG_4 before 4.9 is pushed out the door ? No, OpenSSH 3.7 will not be ready in time for 4.9. Both -CURRENT and -STABLE have already been patched, BTW, so you needn't worry. 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: Release Engineering Status Report
On Wed, 17 Sep 2003 10:57:58 +0200, Dag-Erling Smrgrav [EMAIL PROTECTED] wrote: Mike Jakubik [EMAIL PROTECTED] writes: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Apparently, yes. No. 3.6.1 has the same bug, and 3.7 isn't out yet. http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/64.html Cheers, Mezz DES -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-17, Guillaume écrivait : + if (atapi_dma atp-channel-dma + (atp-param-config ATA_DRQ_MASK) != ATA_DRQ_INTR) + atp-setmode(atadev, ATA_DMA_MAX); + else + atp-setmode(atadev, ATA_PIO_MAX); Ahem. Replace atadev with atp on both lines... Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make installworld trouble
After doing a fresh cvsup of the RELENG_5_1 branch, and a successfull make buildworld, make buildkernel, make installkernel - I get the following error when issueing a make installworld: -- Installing everything.. -- cd /usr/src; make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo $COPYRIGHT osreldate.h;echo #ifdef _KERNEL osreldate.h; echo '#error osreldate.h cannot be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h; echo \#'undef __FreeBSD_version' osreldate.h;echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 I can see that a couple of other users on this list have expirienced this problem, but no solution has been posted. Any ideas ? /mich -- Best Regards, Michael L. Hostbaek [EMAIL PROTECTED] - http://www.FreeBSD.org */ PGP-key available upon request /* pgp0.pgp Description: PGP signature
Re: ATAng hangs with kernel from september 15
Soren Schmidt [EMAIL PROTECTED] writes: Well, the ATA driver has just grown more standard compliant :) You *must* hang around for 31secs to wait for slow devices to come ready, according to the ATA specs. Now I've gone to great length before to get around this by using clever heuristics, and I'm getting there again, but there are *so* many crappy devices out there that it takes time to accomodate them all. Is there any way you can postpone the device initialization so you can do them in paralell? Or make the length of the wait configurable, like SCSI_DELAY? 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: Release Engineering Status Report
Jeremy Messenger [EMAIL PROTECTED] writes: On Wed, 17 Sep 2003 10:57:58 +0200, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: No. 3.6.1 has the same bug, and 3.7 isn't out yet. http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/64.html We use OpenSSH-portable, which lags a little behind. 3.7.1p1 seems to have been released late last evening, but it hasn't hit the mirrors yet. In any case, 3.7.1p1 will not hit -STABLE until it has spent at least a month in -CURRENT. 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: ATAng hangs with kernel from september 15
It seems Dag-Erling Smørgrav wrote: Soren Schmidt [EMAIL PROTECTED] writes: Well, the ATA driver has just grown more standard compliant :) You *must* hang around for 31secs to wait for slow devices to come ready, according to the ATA specs. Now I've gone to great length before to get around this by using clever heuristics, and I'm getting there again, but there are *so* many crappy devices out there that it takes time to accomodate them all. Is there any way you can postpone the device initialization so you can do them in paralell? That wont help anything here, this is pre device init stuff.. Or make the length of the wait configurable, like SCSI_DELAY? That would be a gross hack, the spec says to wait 31 secs and thats it, if you want to wait shorter go ahead and change your local sources, but we need to find a real solution (and I will get there, I just need enough datapoints to find the right solution)... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make installworld trouble
Michael L. Hostbaek (mich) writes: touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 Seems to be a date problem - sorry for jumping the gun. /mich -- Best Regards, Michael L. Hostbaek [EMAIL PROTECTED] - http://www.FreeBSD.org */ PGP-key available upon request /* pgp0.pgp Description: PGP signature
[current tinderbox] failure on ia64/ia64
TB --- 2003-09-17 09:32:24 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-09-17 09:32:24 - 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-09-17 09:35:35 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-17 10:39:01 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Sep 17 10:39:01 GMT 2003 Kernel build for GENERIC completed on Wed Sep 17 10:54:46 GMT 2003 TB --- 2003-09-17 10:54:46 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-17 10:54:46 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Sep 17 10:54:46 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strtoul.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strtouq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strvalid.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13
Re: acd0 vs cd0 (ATAPICAM)
On Wed, 17 Sep 2003, Thomas Quinot wrote: Le 2003-09-17, Guillaume écrivait : + if (atapi_dma atp-channel-dma + (atp-param-config ATA_DRQ_MASK) != ATA_DRQ_INTR) + atp-setmode(atadev, ATA_DMA_MAX); + else + atp-setmode(atadev, ATA_PIO_MAX); Ahem. Replace atadev with atp on both lines... Thomas. The patch seems to work, my cd0 and cd1 lines in the dmesg now report 33.000 MB/s insetad of 3.300 MB/s. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-17, Bryan Liesner écrivait : The patch seems to work, my cd0 and cd1 lines in the dmesg now report 33.000 MB/s insetad of 3.300 MB/s. OK, good, so that's one half of the problem resolved. Now, can you test whether the actual performances are improved or still slow? Thomas. -- [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 sparc64/sparc64
TB --- 2003-09-17 11:04:41 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-09-17 11:04:41 - 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-09-17 11:06:35 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-17 12:00:07 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Sep 17 12:00:07 GMT 2003 Kernel build for GENERIC completed on Wed Sep 17 12:09:08 GMT 2003 TB --- 2003-09-17 12:09:08 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-17 12:09:08 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Sep 17 12:09:08 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strtoul.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strtouq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strvalid.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/net/bpf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
Base packaging
I've got a prototype setup that packages the base tree. It turned out to
be very simple. It needs a lot more polishing and testing but it looks
like this can definitely be made to work with just some tidying up and
re-arranging of our existing make files. I've succesfully created
packages of /sbin by adding the following to /usr/src/sbin/Makefile
--
PORTNAME= FreeBSD-sbin
PORTVERSION= 1.0
COMMENT=sbin
CATEGORIES=misc
--
host# pkg_info -Im FreeBSD\*
FreeBSD-sbin-1.0sbin
host#
Patches below:
Similar patches are needed in bsd.lib.mk and bsd.prog.mk
if you need to create packages in leaf directories. I've
tested that but not included the diffs here since it's
more likely a package would be at a higher directory level.
*** bsd.subdir.mk Wed Sep 17 12:47:11 2003
--- new.subdir.mk Wed Sep 17 13:07:01 2003
***
*** 90,95
.if !target(afterinstall)
afterinstall:
.endif
! install: beforeinstall realinstall afterinstall
! .ORDER: beforeinstall realinstall afterinstall
.endif
--- 90,99
.if !target(afterinstall)
afterinstall:
.endif
! .if defined(PORTNAME)
! .include bsd.syspkg.mk
! .else
! install: beforeinstall realinstall afterinstall fake-pkg
! .ORDER: beforeinstall realinstall afterinstall fake-pkg
! .endif
.endif
---
# bsd.syspkg.mk
LOCALBASE=/
WRKDIR=${.OBJDIR}
NO_WRKSUBDIR=YES
NO_CHECKSUM=YES
NO_BUILD=YES
fetch:
extract:
patch:
configure:
install: beforeinstall realinstall afterinstall generate-plist fake-pkg
.include bsd.own.mk
.include ${PORTSDIR}/Mk/bsd.port.mk
intY has scanned this email for all known viruses (www.inty.com)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Base packaging
Paul Richards wrote: I've got a prototype setup that packages the base tree. It turned out to be very simple. It needs a lot more polishing and testing but it looks like this can definitely be made to work with just some tidying up and re-arranging of our existing make files. I've succesfully created packages of /sbin by adding the following to /usr/src/sbin/Makefile -- PORTNAME= FreeBSD-sbin PORTVERSION= 1.0 COMMENT=sbin CATEGORIES=misc -- Good ... we might get rid of dummy packages? like this: http://people.freebsd.org/~dinoex/ports/base-kerberos/ kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [EMAIL PROTECTED],[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: using tip on machine that has COMCONSOLE set to serial
From: Terry Lambert [mailto:[EMAIL PROTECTED] Don Bowman wrote: This may be a dumb question, but I have a situation where machine A and B both have enabled serial console. I'm ssh'ing into A to try and debug a problem on B. I'm trying to use tip, but am getting interference from the fact that A also has a serial console. If i disable the getty, its a bit better. Is there a way to make this work reliably, or am I SOL? Use or modify a getty to require multiple CR's to activate. Or use one that only activates on a break. Best would be to use a getty that respected lock files, needed 2 CR's to start after off-to-on DTR/DCD transition (you will be using a NULL-modem cable), and your tip/cu/whatever program did appropriate locking, and knew how to back off. Then you could put the getty's back-to-back and they would not chat each other to death, and you could call out of the one machine into the other, and your local getty would not eat half the characters. See also uugetty and mgetty in ports. What i ended up doing which worked OK was to changed /etc/ttys on the machine i wanted to run tip on to comment out the 'ttyd0' line, and HUP init. I then installed 'minicom' port, and used it. The machine i was running it on has to be quiescent so no kernel printfs occur. minicom used /dev/cuaa0. Bruce Evans suggested using 'db' to poke a '0xc3' into the kernel printf start to make it return right away, if this were a bigger problem for me I would give that a try. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: latest -CURRENT kernel fails to build
pcic and newcard are an unsupported combination. take pcic out of your kernel. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP/STATUS: network locking
On Tue, Sep 16, 2003 at 09:29:07AM -0700, Sam Leffler wrote:
Please send me your kernel config and tell me again exactly what fails. I
will try to reproduce your problem.
Sam
After your yesterday/today commits, I got panic while doing netstat -an. On
the kernel from about two days ago, with manually added patches, the netstat
command render system unusable (with netstat process in LOCK state, or, in
other cases - (swi8: tty:sio clock) process in LOCK state). System has:
dc0: 3Com OfficeConnect 10/100B port 0xe400-0xe4ff mem 0xe900-0xe90003ff
irq 10 at device 18.0 on pci0
rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem 0xe9001000-0xe90010ff
irq 12 at device 19.0 on pci0
It acts as a home router to my DSL line (over PPPoE).
If there's any other information I may provide, please let me know.
Kernel config attached
Cheers,
Wiktor Niesiobdzki
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018a11b
stack pointer = 0x10:0xcebaeae4
frame pointer = 0x10:0xcebaeaf8
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 = 2914 (sshd)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 2236 2236
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018a11b
stack pointer = 0x10:0xcd751c88
frame pointer = 0x10:0xcd751c9c
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 = 23 (irq12: rl0)
trap number = 12
panic: page fault
Uptime: 1h59m32s
Dumping 256 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0194ef0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc01952d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc02a9e56 in trap_fatal (frame=0xcd751c48, eva=0) at
/usr/src/sys/i386/i386/trap.c:818
#4 0xc02a9493 in trap (frame=
{tf_fs = -1072037864, tf_es = 16, tf_ds = -847970288, tf_edi = 4, tf_esi = 16,
tf_ebp = -847962980, tf_isp = -847963020, tf_ebx = 0, tf_edx = -1070828335, tf_ecx =
-1030343792, tf_eax = 16, tf_trapno = 12, tf_err = 0, tf_eip = -1072127717, tf_cs = 8,
tf_eflags = 66195, tf_esp = 1242790725, tf_ss = 66572650}) at
/usr/src/sys/i386/i386/trap.c:251
#5 0xc02997a8 in calltrap () at {standard input}:102
#6 0xc018a559 in _mtx_lock_sleep (m=0x10, opts=0, file=0x0, line=0) at
/usr/src/sys/kern/kern_mutex.c:635
#7 0xc017f014 in ithread_loop (arg=0xc0eac600) at /usr/src/sys/kern/kern_intr.c:533
#8 0xc017dcc1 in fork_exit (callout=0xc017ee50 ithread_loop, arg=0x0, frame=0x0) at
/usr/src/sys/kern/kern_fork.c:796
(kgdb) fr 6
#6 0xc018a559 in _mtx_lock_sleep (m=0x10, opts=0, file=0x0, line=0) at
/usr/src/sys/kern/kern_mutex.c:635
635 propagate_priority(td);
(kgdb) l 635
630 * Save who we're blocked on.
631 */
632 td-td_blocked = m;
633 td-td_lockname = m-mtx_object.lo_name;
634 TD_SET_LOCK(td);
635 propagate_priority(td);
636
637 if (LOCK_LOG_TEST(m-mtx_object, opts))
638 CTR3(KTR_LOCK,
639 _mtx_lock_sleep: p %p blocked on [%p] %s, td, m,
(kgdb) fr 4
#4 0xc02a9493 in trap (frame=
{tf_fs = -1072037864, tf_es = 16, tf_ds = -847970288, tf_edi = 4, tf_esi = 16,
tf_ebp = -847962980, tf_isp = -847963020, tf_ebx = 0, tf_edx = -1070828335, tf_ecx =
-1030343792, tf_eax = 16, tf_trapno = 12, tf_err = 0, tf_eip = -1072127717, tf_cs = 8,
tf_eflags = 66195, tf_esp = 1242790725, tf_ss = 66572650}) at
/usr/src/sys/i386/i386/trap.c:251
251 trap_fatal(frame, eva);
(kgdb) p/x frame.tf_eip
$1 = 0xc018a11b
(kgdb) disass 0xc018a11b
Dump of assembler code for function propagate_priority:
0xc018a090 propagate_priority:push %ebp
0xc018a091 propagate_priority+1: mov%esp,%ebp
0xc018a093 propagate_priority+3: push %edi
0xc018a094 propagate_priority+4: push %esi
0xc018a095 propagate_priority+5: push %ebx
0xc018a096 propagate_priority+6: sub$0x8,%esp
0xc018a099 propagate_priority+9: mov0x8(%ebp),%ecx
0xc018a09c propagate_priority+12: movzbl 0xdd(%ecx),%esi
0xc018a0a3 propagate_priority+19: mov0x5c(%ecx),%ebx
0xc018a0a6 propagate_priority+22: lea0x0(%esi),%esi
0xc018a0a9 propagate_priority+25:
Re: Base packaging
Paul Richards writes: I've got a prototype setup that packages the base tree. It turned out to be very simple. It needs a lot more polishing and testing but it looks like this can definitely be made to work with just some tidying up and re-arranging of our existing make files. I've succesfully created packages of /sbin by adding the following to /usr/src/sbin/Makefile -- PORTNAME= FreeBSD-sbin PORTVERSION= 1.0 COMMENT=sbin CATEGORIES=misc -- ... etc. This is excellent! However, I suspect that a marginally better place to use these would be in the make distribute target that make release uses. This way, the files are already separated out into directory structures, and it may be easier to build complex pkg-plist's with find(1). ALSO, it may be easier to make more fine-grained packages (DISTRIBUTION=foo) with this. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Base packaging
On Wed, 2003-09-17 at 15:45, Mark Murray wrote: Paul Richards writes: I've got a prototype setup that packages the base tree. It turned out to be very simple. It needs a lot more polishing and testing but it looks like this can definitely be made to work with just some tidying up and re-arranging of our existing make files. I've succesfully created packages of /sbin by adding the following to /usr/src/sbin/Makefile -- PORTNAME= FreeBSD-sbin PORTVERSION= 1.0 COMMENT=sbin CATEGORIES=misc -- ... etc. This is excellent! However, I suspect that a marginally better place to use these would be in the make distribute target that make release uses. This way, the files are already separated out into directory structures, and it may be easier to build complex pkg-plist's with find(1). ALSO, it may be easier to make more fine-grained packages (DISTRIBUTION=foo) with this. I looked into this originally so that I could use the standard BSD make includes for a project in work but I needed some way to have install wrappered so that any files installed by my project were registered in a package. Therefore, I wouldn't want it restricted to just FreeBSD release scripts since I want to be able to use it outside of the FreeBSD tree. I was thinking of adding an option to install so it registers the file in a plist rather than actually doing the install. A seperate make plist target could then be used as a helper target to automate the generation of plists. If we want to get even more resilient, we could pass a plist file to install and have install abort if the file to install is missing from the plist e.g. return an out of date package error or something. Paul. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP/STATUS: network locking
On Tue, Sep 16, 2003 at 09:29:07AM -0700, Sam Leffler wrote: Please send me your kernel config and tell me again exactly what fails. I will try to reproduce your problem. Sam After your yesterday/today commits, I got panic while doing netstat -an. On the kernel from about two days ago, with manually added patches, the netstat command render system unusable (with netstat process in LOCK state, or, in other cases - (swi8: tty:sio clock) process in LOCK state). You cannot mix+match the commits and the patches. You also, if I recall, were only applying some of the patches and not all of them. I'm not sure this can work. I haven't looked at the config you sent me; will try today. I think that unless you can track my changes through p4 it may be problematic using the patches. I'll see about updating the patches based on the current CVS. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
On Tue, Sep 16, 2003 at 06:11:01PM +0200, Harti Brandt wrote: On Tue, 16 Sep 2003, Richard Nyberg wrote: RNAt Thu, 11 Sep 2003 14:44:55 +0200 (CEST), RNHarti Brandt wrote: RN Hi, RN RN I just tried to upgrade one of my systems from a static root from july to RN an actual dynamic root. The installworld went fine 'til the place where RN /bin/test is installed. At that point the installation stopped with ELF RN interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not RN populated yet. RN RNMe too :( RNTo get installworld back on track I used cp under linux emulation to RNcopy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that RNmake installworld completed successfully. Or you could cd into /usr/obj/usr/src/rescue/rescue and do ./rescue cp ... (as long as you have a working shell) Which of course exists in /rescue too. -gordon pgp0.pgp Description: PGP signature
Yesterday -CURRENT doesn't work on my CD-RW and SCSI HD (Re: )
Err, for some reason the email client ate my subject.. On Wed, 17 Sep 2003 11:59:46 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: Last night, I CVSup'ed and did the buildworld/kernel stuff. Then, I reboot and I get the busy signal like forever, it looks like the HD is spinning forever for no reason. Also, the ATAng can't find my Teac CD-RW.. Here are three attaches.. dmesg-ataog.txt is old kernel sometime before ATAng went in the 5.1-CURRENT tree. FreeBSD mezz.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Aug 23 01:09:03 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 dmesg-atang.txt and pciconf.txt are from last night 5.1-CURRENT. Please, let me know if there is something else I can do.. Soon, I am going to boot into the yesterday -CURRENT, I think I saw more error with SCSI stuff and I will try to collect them. If I get them and I will reply in here with the more info. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
At Wed, 17 Sep 2003 09:54:42 -0700, Gordon Tetlow wrote: [1 text/plain; us-ascii (quoted-printable)] On Tue, Sep 16, 2003 at 06:11:01PM +0200, Harti Brandt wrote: On Tue, 16 Sep 2003, Richard Nyberg wrote: RNAt Thu, 11 Sep 2003 14:44:55 +0200 (CEST), RNHarti Brandt wrote: RN Hi, RN RN I just tried to upgrade one of my systems from a static root from july to RN an actual dynamic root. The installworld went fine 'til the place where RN /bin/test is installed. At that point the installation stopped with ELF RN interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not RN populated yet. RN RNMe too :( RNTo get installworld back on track I used cp under linux emulation to RNcopy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that RNmake installworld completed successfully. Or you could cd into /usr/obj/usr/src/rescue/rescue and do ./rescue cp ... (as long as you have a working shell) Ah! I wondered why only found the rescue binary there and no cp or mv. I didn't quite get it... :) Which of course exists in /rescue too. No because it wasn't installed yet. -Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:
On Wed, 17 Sep 2003 11:59:46 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: Last night, I CVSup'ed and did the buildworld/kernel stuff. Then, I reboot and I get the busy signal like forever, it looks like the HD is spinning forever for no reason. Also, the ATAng can't find my Teac CD-RW.. Here are three attaches.. dmesg-ataog.txt is old kernel sometime before ATAng went in the 5.1-CURRENT tree. FreeBSD mezz.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Aug 23 01:09:03 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 dmesg-atang.txt and pciconf.txt are from last night 5.1-CURRENT. Please, let me know if there is something else I can do.. Soon, I am going to boot into the yesterday -CURRENT, I think I saw more error with SCSI stuff and I will try to collect them. If I get them and I will reply in here with the more info. Ok, I have collected them.. I get the errors when I copied many files to the different place.. === (da0:ahc0:0:0:0): tagged openings now 59 (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Request Requeued (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Queue Full (da0:ahc0:0:0:0): tagged openings now 50 (da0:ahc0:0:0:0): Retrying Command (da0:ahc0:0:0:0): Queue Full (da0:ahc0:0:0:0): tagged openings now 49 (da0:ahc0:0:0:0): Retrying Command [...goes on...] === Cheers, Mezz Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [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-09-17 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-09-17 16:00:01 - 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-09-17 16:01:51 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-17 17:04:50 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Sep 17 17:04:50 GMT 2003 Kernel build for GENERIC completed on Wed Sep 17 17:16:41 GMT 2003 TB --- 2003-09-17 17:16:41 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-17 17:16:41 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Sep 17 17:16:41 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/libkern/strtoul.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/libkern/strtouq.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/libkern/strvalid.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/net/bpf.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
Re: Base packaging
On Wednesday, September 17, 2003, at 04:27 pm, Paul Richards wrote: I was thinking of adding an option to install so it registers the file in a plist rather than actually doing the install. A seperate make plist target could then be used as a helper target to automate the generation of plists. I think the NetBSD guys have already done something like this. Luke Mewburn (IIRC) mentioned this in his 'cross building' talk at BSDCon. N ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
here is my vmstat -i output: interrupt total rate stray irq01 0 stray irq71 0 npx0 irq131 0 ata0 irq1492143 2 ata1 irq15 20 0 uhci0 irq11 1 0 pcm0 irq936 0 rl0 irq1011 0 rl1 irq11 77987 2 fdc0 irq6 1 0 atkbd0 irq16946 0 clk irq03180967 99 rtc irq84071093127 Total 7429208233 apart from some icq sharing it seems to be ok, doesnt it ? i turned of acpi on startup an voila :) : gdm starts two times faster as before (!) (30s - 15-17s) can anyone explain me why, pls ? and the other question is: do i really need acpi ? i run a desktop system so suspend/resume is not interesting for me. does fbsd/acpi supend the disk when the system idles ? (linux does not) thx seb On Sat, 2003-09-13 at 15:28, Max Laier wrote: Interrupts?! Check $vmstat -i ACPI? Try disableing it. I have a VIA chipset as well and my ata IRQs just went crazy when used with ACPI. GL (...) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
(...) hi, I agree with the general concensus that this shows all the symptoms of a network or DNS problem - though the switch from SIS to nVidia may have disturbed X. Did you change any system configuration (hostname etc) when you moved the disk? Is the 'production' environment identical network-wise to your test environment? Have you re-configured X to use the different video card? when i moved the disk i didn't change any network setting. the only difference is that the prod. system has two network cards (both realtek). i first configured X to use the native nvidia driver but now i am running the X11 builtin nvidia driver. Seems to make no difference in performance for me. How are you starting gdm, gnome2 etc? I gather gdm isn't started via /etc/ttys but manually from a vty. I presume you are using gdm to start X. i start gdm using /usr/X11R6/etc/rc.d/gdm.sh as mentioned in docs. to give u some numbers: -starting gdm takes 30 s from command line to login screen (see last post: only 15s with acpi disabled (why?) ) -starting gnome2 takes 25 s from login until nautilus has drawn the desktop i guess this is not really fast, isnt it ? Can you log in from a second system? If so, what is happening during the startup delay? Does top show the system is very heavily loaded or doing nothing (all processes waiting)? good idea i havnt tried this yet. i ll do theses days ... Before you start gdm, can you ping your system by hostname? Are there any other hostname mentioned in your gdm configuration file? Can you ping them all? i looked at the /usr/X11R6/etc/gdm/gdm.conf file but i havnt found any hostname specific setting. what exactly shall i look for ? Have you checked your /etc/nsswitch.conf and /etc/resolv.conf? Is the output from 'ifconfig -a' and 'netstat -r' correct? after i have fixed some bugs in named config now ipconfig -a and netstat -r output is ok and both answer in no time (means to timeout). Have a look through all the files in /var/log that have been updated recently and check for errors - especially XFree86.0.log, daemon and messages. Have a look in the gdm log file (I'm not sure where this is by default). Are there any messages on either the console or vty from which you started gdm? (Use Ctrl-Alt-Fn to get from X to vtyn and then Alt-Fn to switch between vtys. You can use ScrollLock and PgUp/PgDn/Up/Down to scroll back. Press ScrollLock again to get back to normal). i had a first look at the config files u named but i could not see any interesting error or warning. i will check this in detail later. Is any part of your system NFS-mounted? Is X using a fontserver? Are all these servers responding? currently i do not run nfs (client/server) or fontserver. Are you running a GENERIC or custom kernel? Do you have any firewall functions enabled? i use a custom kernel. i have removed some scsi devices cause i am running an ide system. and i moved this debugging stuff. the firewall is not running on startup cause i use a dial up connection. btw: the mozilla-firebird performance problem mention earlier seems to be something different: firebird launches relativly fast and as soon as running i can us the menus and everything which is reachable via mouse. but as soon as i use the keyboard (e.g. typing an internet addr) or switch the window into background and back into foreground moz-firebird hangs for minutes (!). but this only happens the first time after start. when it runs it performs rather good i will try to build a new version these days and will see what happens ... thx for ur hints seb Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Bad performance
From: sebastian ssmoller [mailto:[EMAIL PROTECTED] ... i turned of acpi on startup an voila :) : gdm starts two times faster as before (!) (30s - 15-17s) can anyone explain me why, pls ? I wonder how hot your processor is? perhaps ACPI is throttling the clock back, either duty cycle or frequency. In your bios you can set the power mode, perhaps you can set 'full power always'. lmmon might show something. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Bad performance
On Wed, 2003-09-17 at 20:16, Don Bowman wrote: From: sebastian ssmoller [mailto:[EMAIL PROTECTED] ... i turned of acpi on startup an voila :) : gdm starts two times faster as before (!) (30s - 15-17s) can anyone explain me why, pls ? I wonder how hot your processor is? perhaps ACPI is throttling the clock back, either duty cycle or frequency. In your bios you can set the power mode, perhaps you can set 'full power always'. lmmon might show something. here is my lmmon output. Motherboard Temp Voltages 255C / 491F / 528KVcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1:0 rpm+12.0V: +15.938V 2:0 rpm-12.0V: -15.938V 3:0 rpm- 5.0V: -6.654V i'm not sure whether this output is correct : 255 C ?? so this should be a reason for acpi to throttling the cpu, doesnt it ? :) can u give me a hint how to correct these values ? (cause hardware is ok this should be a software/config probem (?) thx seb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yesterday -CURRENT doesn't work on my CD-RW and SCSI HD (Re: )
On Wed, 17 Sep 2003 11:59:46 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: Last night, I CVSup'ed and did the buildworld/kernel stuff. Then, I reboot and I get the busy signal like forever, it looks like the HD is spinning forever for no reason. Also, the ATAng can't find my Teac CD-RW.. Strange, I cvsupped/rebuilt last night as well. I haven't been seeing the outright hangs on boot that people are talking about, but I am still having problems getting both of my ATAPI devices to attach properly. I got a response from Soren re: my last dmesg report; sounded like maybe he had an idea what to do about the ATAPI problem at least crossing fingers. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SMP kernel panic with traceback
I'm getting crashes when trying to debug mozilla (under KSE).
The panic message is panic: absolutely cannot call smp_ipi_shootdown
with interrupts already disabled. Attached is the trace.
Any ideas?
--
Dan Eischen
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
panic messages:
---
panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
cpuid = 0; lapic.id = 0100
Stack backtrace:
boot() called on cpu#0
syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown
with interrupts already disabled
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 2m44s
Dumping 512 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
Reading symbols from /boot/kernel/green_saver.ko...done.
Loaded symbols for /boot/kernel/green_saver.ko
#0 doadump () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:240
#1 0xc02d52ab in boot (howto=260) at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:372
#2 0xc02d56b6 in panic () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:550
#3 0xc0443b39 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
at /opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2396
#4 0xc0443df9 in smp_invlpg_range (addr1=0, addr2=0)
at /opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2527
#5 0xc0445fe8 in pmap_invalidate_range (pmap=0xc0599280, sva=3512557568, eva=1)
at /opt/FreeBSD/src/src/sys/i386/i386/pmap.c:719
#6 0xc04463bd in pmap_qenter (sva=3512557568, m=0xdd6ad884, count=0)
at /opt/FreeBSD/src/src/sys/i386/i386/pmap.c:968
#7 0xc0321de8 in vm_hold_load_pages (bp=0xce65ddf0, from=3512557568, to=3512573952)
at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:3594
#8 0xc0320381 in allocbuf (bp=0xce65ddf0, size=16384) at
/opt/FreeBSD/src/src/sys/kern/vfs_bio.c:2767
#9 0xc032001c in geteblk (size=16384) at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:2649
#10 0xc031c702 in bwrite (bp=0x4000) at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:815
#11 0xc031d1bc in bawrite (bp=0x0) at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:1139
#12 0xc03261e9 in vop_stdfsync (ap=0xdd6ad9dc) at
/opt/FreeBSD/src/src/sys/kern/vfs_default.c:742
#13 0xc029ae40 in spec_fsync (ap=0xdd6ad9dc) at
/opt/FreeBSD/src/src/sys/fs/specfs/spec_vnops.c:417
#14 0xc029a118 in spec_vnoperate (ap=0x0) at
/opt/FreeBSD/src/src/sys/fs/specfs/spec_vnops.c:122
#15 0xc03e4797 in ffs_sync (mp=0xc4196200, waitfor=2, cred=0xc150df00, td=0xc05351e0)
at vnode_if.h:627
#16 0xc03324fb in sync (td=0xc05351e0, uap=0x0) at
/opt/FreeBSD/src/src/sys/kern/vfs_syscalls.c:142
#17 0xc02d4dff in boot (howto=256) at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:281
#18 0xc02d56b6 in panic () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:550
#19 0xc0443b39 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
at /opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2396
#20 0xc0443dba in smp_invlpg (addr=0) at
/opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2514
#21 0xc0445f63 in pmap_invalidate_page (pmap=0x1, va=3715026944)
at /opt/FreeBSD/src/src/sys/i386/i386/pmap.c:691
#22 0xc0447651 in pmap_remove_all (m=0xc0cffda8) at
/opt/FreeBSD/src/src/sys/i386/i386/pmap.c:1783
#23 0xc04057e2 in vm_object_page_remove (object=0xc056fd20, start=120814, end=120815,
clean_only=0)
at /opt/FreeBSD/src/src/sys/vm/vm_object.c:1749
#24 0xc03ff89e in vm_map_delete (map=0xc082f000, start=3226926368, end=3715031040)
at /opt/FreeBSD/src/src/sys/vm/vm_map.c:2190
#25 0xc03ffae8 in vm_map_remove (map=0xc082f000, start=3715026944, end=3715031040)
at /opt/FreeBSD/src/src/sys/vm/vm_map.c:2243
#26 0xc03fbe82 in kmem_free (map=0x0, addr=0, size=4096) at
/opt/FreeBSD/src/src/sys/vm/vm_kern.c:240
---Type return to continue, or q return to quit---
#27 0xc044a690 in user_ldt_free (td=0xc082f000) at
/opt/FreeBSD/src/src/sys/i386/i386/sys_machdep.c:363
#28 0xc044d226 in cpu_exit (td=0x0) at
/opt/FreeBSD/src/src/sys/i386/i386/vm_machdep.c:275
#29 0xc02be454 in exit1 (td=0xc464dab0, rv=5) at
/opt/FreeBSD/src/src/sys/kern/kern_exit.c:484
#30 0xc02da09c in sigexit () at /opt/FreeBSD/src/src/sys/kern/kern_sig.c:2422
#31 0xc02d8523 in trapsignal (td=0xc464dab0, sig=5, code=0)
at /opt/FreeBSD/src/src/sys/kern/kern_sig.c:1550
#32 0xc044b386 in trap (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 257, tf_ebp =
-1077943800, tf_isp = -580199052, tf_ebx = 671717336, tf_edx = 1, tf_ecx = 0, tf_eax =
Re: Yesterday -CURRENT doesn't work on my CD-RW and SCSI HD (Re: )
On Wed, 17 Sep 2003 13:27:28 -0500, Conrad J. Sabatier [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2003 11:59:46 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: Last night, I CVSup'ed and did the buildworld/kernel stuff. Then, I reboot and I get the busy signal like forever, it looks like the HD is spinning forever for no reason. Also, the ATAng can't find my Teac CD-RW.. Strange, I cvsupped/rebuilt last night as well. I haven't been seeing the outright hangs on boot that people are talking about, but I am still having problems getting both of my ATAPI devices to attach properly. Well, it doesn't hangs but I can surf around and fireup Gnome2 while I get the crazy busy singal light on at all the time. There are no crazy CPU/Memory in the ps/top, but just 90%-100% idle. I am pretty clueless on this one, so I am stick to the old 5.1-CURRENT for now until someone know what's wrong with my problem. I have four kernels under /boot, two of them have debug enable and I am willing to do anything. I got a response from Soren re: my last dmesg report; sounded like maybe he had an idea what to do about the ATAPI problem at least crossing fingers. :-) I hope, -CURRENT will get stable sometime soon same as before. :-) Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
On Sat, Sep 13, 2003 at 06:05:59PM +0200, sebastian ssmoller wrote: as mentioned: really bad performace occurs when lauching mozilla, gaim, gnome2, etc. ... when mozilla is running the perfomance seems to be ok ... possibly a bit too slow but i do not know how to proof this (?) I discovered a while back that most GNOME stuff (including daemons and whatnot), for some strange reason, will try to connect to port 111 (sunrpc) on startup. Try enabling rpcbind and see what happens. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
On Wed, Sep 17, 2003 at 08:31:52PM +0200, sebastian ssmoller wrote: Motherboard Temp Voltages 255C / 491F / 528KVcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1:0 rpm+12.0V: +15.938V 2:0 rpm-12.0V: -15.938V 3:0 rpm- 5.0V: -6.654V i'm not sure whether this output is correct : 255 C ?? so this should be a reason for acpi to throttling the cpu, doesnt it ? 0 rpm? Are you sure your fans are working? As for cpu throttling try the following troutmask:kargl[225] sysctl -a | grep acpi.cpu hw.acpi.cpu.max_speed: 2 hw.acpi.cpu.current_speed: 2 hw.acpi.cpu.performance_speed: 2 hw.acpi.cpu.economy_speed: 1 -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
On Wed, 2003-09-17 at 20:42, Steve Kargl wrote: On Wed, Sep 17, 2003 at 08:31:52PM +0200, sebastian ssmoller wrote: Motherboard Temp Voltages 255C / 491F / 528KVcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1:0 rpm+12.0V: +15.938V 2:0 rpm-12.0V: -15.938V 3:0 rpm- 5.0V: -6.654V i'm not sure whether this output is correct : 255 C ?? so this should be a reason for acpi to throttling the cpu, doesnt it ? 0 rpm? Are you sure your fans are working? yes i am :) but the question is why fbsd doesnt see this ? the hardware is set up properly (cause bios displays correct rpm/temp etc) ... As for cpu throttling try the following troutmask:kargl[225] sysctl -a | grep acpi.cpu hw.acpi.cpu.max_speed: 2 hw.acpi.cpu.current_speed: 2 hw.acpi.cpu.performance_speed: 2 hw.acpi.cpu.economy_speed: 1 i will try this thx seb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic ipfw with smp -current (as of this morning)
I get these in less than 20min. config is pretty close to GENERIC except turned on SMP and APIC_IO. Turned off INET6. Any advice? recursed on non-recursive lock (sleep mutex) IPFW static rules @ /usr/src /sys/netinet/ip_fw2.c:1492 first acquired @ /usr/src/sys/netinet/ip_fw2.c:1492 panic: recurse cpuid = 0; lapic.id = boot() called on cpu#0 syncing disks, buffers remaining... 6594 6590 6590 6590 6590 vmcore.15 * panic: recurse panic messages: --- dmesg: kvm_read: --- Reading symbols from /usr/obj/usr/src/sys/PASODOBLE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/PASODOBLE/modules/usr/src/sys/modules/acpi/acpi.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0335a3b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0335e46 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc035b963 in witness_lock (lock=0xc060f448, flags=8, file=0xc052ebc5 /usr/src/sys/netinet/ip_fw2.c, line=1492) at /usr/src/sys/kern/subr_witness.c:722 #4 0xc032bdfa in _mtx_lock_flags (m=0xc060cd7c, opts=0, file=0xc05799ec $\205SÀ\t, line=-1067387832) at /usr/src/sys/kern/kern_mutex.c:336 #5 0xc03c57db in ipfw_chk (args=0xe5ae0a74) at /usr/src/sys/netinet/ip_fw2.c:1492 #6 0xc03caaee in ip_output (m0=0xc678b000, opt=0xc678b0c8, ro=0xe5ae0b14, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:770 #7 0xc03c8576 in icmp_send (m=0xc678b000, opts=0x0, rt=0x0) at /usr/src/sys/netinet/ip_icmp.c:771 #8 0xc03c84a2 in icmp_reflect (m=0xc678b000) at /usr/src/sys/netinet/ip_icmp.c:732 #9 0xc03c7c35 in icmp_error (n=0xc678ed00, type=-965168952, code=3, dest=0, destifp=0x0) at /usr/src/sys/netinet/ip_icmp.c:230 #10 0xc03c547c in send_reject (args=0xe5ae0c70, code=0, offset=0, ip_len=60) at /usr/src/sys/netinet/ip_fw2.c:1246 #11 0xc03c643b in ipfw_chk (args=0xe5ae0c70) at /usr/src/sys/netinet/ip_fw2.c:2032 #12 0xc03c8b90 in ip_input (m=0xc678ed00) at /usr/src/sys/netinet/ip_input.c:494 #13 0xc03ab622 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:236 #14 0xc0321ee2 in ithread_loop (arg=0xc6769200) at /usr/src/sys/kern/kern_intr.c:534 #15 0xc0320eaf in fork_exit (callout=0xc0321d60 ithread_loop, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:796 (kgdb) ** vmcore.14 not valdid sorry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
On Wed, Sep 17, 2003 at 08:31:52PM +0200, sebastian ssmoller wrote: On Wed, 2003-09-17 at 20:16, Don Bowman wrote: I wonder how hot your processor is? perhaps ACPI is throttling the clock back, either duty cycle or frequency. In your bios you can set the power mode, perhaps you can set 'full power always'. lmmon might show something. here is my lmmon output. Motherboard Temp Voltages 255C / 491F / 528KVcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1:0 rpm+12.0V: +15.938V 2:0 rpm-12.0V: -15.938V 3:0 rpm- 5.0V: -6.654V i'm not sure whether this output is correct : 255 C ?? Obviously, lmmon does not know how to read your environment monitoring data. For teperature on an ACPI enabled machine: http://people.freebsd.org/~hmp/acpi_temp.c -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
I've got a Netgear WAG511 (Atheros 5212-based card) and a Netgear FWAG114 wireless router. I've been trying to get the card and the router talking under FreeBSD. (Both 802.11a and 802.11g work fine under Windows on the same machine.) I'm using -current from September 15th. Anyway, whenever I try to get the card talking to the router, which is running WEP (128 bit keys) on both the a and b/g sides, I get: ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] Here's what the ifconfig looks like: ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether [ card mac address ] media: IEEE 802.11 Wireless Ethernet autoselect mode 11a (OFDM/6Mbps) status: no carrier ssid [my ssid] 1:[my ssid] channel -1 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:128-bit wepkey 2:128-bit wepkey 3:128-bit wepkey 4:128-bit I've verified and re-verified, via cut-and-paste from the router setup screen, that the WEP key is correct. Good news+bad news. I just committed a fix to ifconfig to correctly handle 128-bit WEP keys. I'm not sure how you thought you were setting your key up but ifconfig was barfing on anything more than 104 bits. FWIW ifconfig wrongly indicated keys 5 bytes (40 bits) were 128-bit keys; I also fixed that so ifconfig now indicates keys are 40-, 104-, or 128-bit according to their length. Beware also that wicontrol displays WEP keys longer than 104 bits zero-padded; I believe this is because of limitations in the RID API for fetching keys. Someone else may want to investigate that issue. The bad news is that with 128-bit keys installed I'm getting decryption errors at the AP. Actually, I'm seeing errors for any length key so it's likely a botch in the WEP frame construction in the driver. I've run out of time to look at this right now and will have to investigate later. Anyway, I can't get the ath(4) driver to talk to the router when it is running WEP. I have been able to get it to talk 802.11g to the router without WEP enabled, though. I tried setting the authmode to shared via ifconfig, but from looking at ieee80211_ioctl.c: # if 0 case IEEE80211_IOC_AUTHMODE: sc-wi_authmode = ireq-i_val; break; # endif i.e. I get EINVAL back. Is WEP supposed to work in -current? authmode is not relevant. WEP worked at one time; I seem to have broken it. As I said above I will have to look at it later. In a separate issue, the ath(4) driver can't see the 802.11a side of the wireless router at all when it is running in 108Mbps turbo mode. If I drop it down to 54Mbps, it sees it. (Works fine in Windows.) Is the ath(4) driver supposed to support the 108Mbps turbo mode? I was able to associate with an Atheros AP with turbo mode enabled but didn't get any higher throughput. I'm investigating this. FWIW I enabled turbo mode with: ifconfig ath0 mediaopt turbo I verified turbo mode was in use by disabling it on either station or AP side and with things mismatched the station/AP couldn't see each other. With turbo mode enabled on each side I was able to associate and communicate as normal; but netperf throughput was identical to the non-turbo setup. I'm asking Atheros folks for clarification on this--I may need to do some additional setup work to enable turbo operation. This is actually the first time I've tried turbo mode... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP kernel panic with traceback
On Wed, 17 Sep 2003, Daniel Eischen wrote:
I'm getting crashes when trying to debug mozilla (under KSE).
The panic message is panic: absolutely cannot call smp_ipi_shootdown
with interrupts already disabled. Attached is the trace.
Any ideas?
% (kgdb) bt
% #0 doadump () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:240
% #1 0xc02d52ab in boot (howto=260) at
/opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:372
% #2 0xc02d56b6 in panic () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:550
% #3 0xc0443b39 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
% at /opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2396
% #4 0xc0443df9 in smp_invlpg_range (addr1=0, addr2=0)
% at /opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2527
% #5 0xc0445fe8 in pmap_invalidate_range (pmap=0xc0599280, sva=3512557568, eva=1)
% at /opt/FreeBSD/src/src/sys/i386/i386/pmap.c:719
% #6 0xc04463bd in pmap_qenter (sva=3512557568, m=0xdd6ad884, count=0)
% at /opt/FreeBSD/src/src/sys/i386/i386/pmap.c:968
% #7 0xc0321de8 in vm_hold_load_pages (bp=0xce65ddf0, from=3512557568, to=3512573952)
% at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:3594
% #8 0xc0320381 in allocbuf (bp=0xce65ddf0, size=16384) at
/opt/FreeBSD/src/src/sys/kern/vfs_bio.c:2767
% #9 0xc032001c in geteblk (size=16384) at
/opt/FreeBSD/src/src/sys/kern/vfs_bio.c:2649
% #10 0xc031c702 in bwrite (bp=0x4000) at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:815
% #11 0xc031d1bc in bawrite (bp=0x0) at /opt/FreeBSD/src/src/sys/kern/vfs_bio.c:1139
% #12 0xc03261e9 in vop_stdfsync (ap=0xdd6ad9dc) at
/opt/FreeBSD/src/src/sys/kern/vfs_default.c:742
% #13 0xc029ae40 in spec_fsync (ap=0xdd6ad9dc) at
/opt/FreeBSD/src/src/sys/fs/specfs/spec_vnops.c:417
% #14 0xc029a118 in spec_vnoperate (ap=0x0) at
/opt/FreeBSD/src/src/sys/fs/specfs/spec_vnops.c:122
% #15 0xc03e4797 in ffs_sync (mp=0xc4196200, waitfor=2, cred=0xc150df00,
td=0xc05351e0) at vnode_if.h:627
% #16 0xc03324fb in sync (td=0xc05351e0, uap=0x0) at
/opt/FreeBSD/src/src/sys/kern/vfs_syscalls.c:142
% #17 0xc02d4dff in boot (howto=256) at
/opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:281
% #18 0xc02d56b6 in panic () at /opt/FreeBSD/src/src/sys/kern/kern_shutdown.c:550
% #19 0xc0443b39 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
% at /opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2396
% #20 0xc0443dba in smp_invlpg (addr=0) at
/opt/FreeBSD/src/src/sys/i386/i386/mp_machdep.c:2514
% #21 0xc0445f63 in pmap_invalidate_page (pmap=0x1, va=3715026944)
% at /opt/FreeBSD/src/src/sys/i386/i386/pmap.c:691
% #22 0xc0447651 in pmap_remove_all (m=0xc0cffda8) at
/opt/FreeBSD/src/src/sys/i386/i386/pmap.c:1783
% #23 0xc04057e2 in vm_object_page_remove (object=0xc056fd20, start=120814,
end=120815, clean_only=0)
% at /opt/FreeBSD/src/src/sys/vm/vm_object.c:1749
% #24 0xc03ff89e in vm_map_delete (map=0xc082f000, start=3226926368, end=3715031040)
% at /opt/FreeBSD/src/src/sys/vm/vm_map.c:2190
% #25 0xc03ffae8 in vm_map_remove (map=0xc082f000, start=3715026944, end=3715031040)
% at /opt/FreeBSD/src/src/sys/vm/vm_map.c:2243
% #26 0xc03fbe82 in kmem_free (map=0x0, addr=0, size=4096) at
/opt/FreeBSD/src/src/sys/vm/vm_kern.c:240
% ---Type return to continue, or q return to quit---
% #27 0xc044a690 in user_ldt_free (td=0xc082f000) at
/opt/FreeBSD/src/src/sys/i386/i386/sys_machdep.c:363
% #28 0xc044d226 in cpu_exit (td=0x0) at
/opt/FreeBSD/src/src/sys/i386/i386/vm_machdep.c:275
% #29 0xc02be454 in exit1 (td=0xc464dab0, rv=5) at
/opt/FreeBSD/src/src/sys/kern/kern_exit.c:484
% #30 0xc02da09c in sigexit () at /opt/FreeBSD/src/src/sys/kern/kern_sig.c:2422
% #31 0xc02d8523 in trapsignal (td=0xc464dab0, sig=5, code=0)
% at /opt/FreeBSD/src/src/sys/kern/kern_sig.c:1550
% #32 0xc044b386 in trap (frame=
% {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 257, tf_ebp =
-1077943800, tf_isp = -580199052, tf_ebx = 671717336, tf_edx = 1, tf_ecx = 0, tf_eax =
671728984, tf_trapno = 3, tf_err = 0, tf_eip = 671620737, tf_cs = 31, tf_eflags = 646,
tf_esp = -1077943860, tf_ss = 47})
% at /opt/FreeBSD/src/src/sys/i386/i386/trap.c:623
% #33 0xc04338b8 in calltrap () at {standard input}:103
% ---Can't read userspace from dump, or kernel process---
Eeek. Looks like I forgot an attachment to i386/machdep.c 1.468 2001/08/13
(use interrupt gates instead of trap gates for breakpoint and trace traps).
Keeping interrupts disabled is only correct for these traps if they are
from kernel mode. It's surprising how few problems this has caused.
%%%
Index: trap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v
retrieving revision 1.256
diff -u -2 -r1.256 trap.c
--- trap.c 15 Aug 2003 15:20:27 - 1.256
+++ trap.c 16 Aug 2003 00:32:07 -
@@ -275,4 +318,5 @@
case T_BPTFLT: /* bpt instruction fault */
case T_TRCTRAP: /* trace trap */
+
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
Bernd Walter wrote this message on Wed, Sep 17, 2003 at 10:27 +0200: On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is either disk corruption or an ffs bug. ffs passes the garbage block number 0xe5441ae9720 to bread. GEOM then handles this austerely by panicing. Garbage block numbers, including negative ones, can possibly be created by applications seeking to preposterous offsets, so they should not be handled with panics. They most certainly should! If the range checking in any filesystem is not able to catch these cases I insist that GEOM do so with a panic. What is wrong with returning an IO error? I always hated panics because of filesystem corruptions. An alternative would be to just bring that filesystem down. Its easy to panic a whole system with a bogus filesystem on a removeable media. If you're file system is so hosed that it does this, then panicing is the only safe thing to do. You don't know what continued operation will do to the filesytem, and you might end up losing more data. It is not unresonable to put parameter restrictions on function calls. It is not much different from enforcing that a pointer is not NULL when being passed as an argument. -- 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: Base packaging
On Wed, Sep 17, 2003 at 06:53:41PM +0100, Nik Clayton wrote: On Wednesday, September 17, 2003, at 04:27 pm, Paul Richards wrote: I was thinking of adding an option to install so it registers the file in a plist rather than actually doing the install. A seperate make plist target could then be used as a helper target to automate the generation of plists. I think the NetBSD guys have already done something like this. Luke Mewburn (IIRC) mentioned this in his 'cross building' talk at BSDCon. Yeah, I've been looking at that. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP kernel panic with traceback
On Thu, 18 Sep 2003, Bruce Evans wrote: On Wed, 17 Sep 2003, Daniel Eischen wrote: I'm getting crashes when trying to debug mozilla (under KSE). The panic message is panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled. Attached is the trace. Any ideas? Eeek. Looks like I forgot an attachment to i386/machdep.c 1.468 2001/08/13 (use interrupt gates instead of trap gates for breakpoint and trace traps). Keeping interrupts disabled is only correct for these traps if they are from kernel mode. It's surprising how few problems this has caused. %%% Index: trap.c === RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.256 diff -u -2 -r1.256 trap.c --- trap.c15 Aug 2003 15:20:27 - 1.256 +++ trap.c16 Aug 2003 00:32:07 - @@ -275,4 +318,5 @@ case T_BPTFLT: /* bpt instruction fault */ case T_TRCTRAP: /* trace trap */ + enable_intr(); frame.tf_eflags = ~PSL_T; i = SIGTRAP; %%% Thanks, I'll try it tonight when I get access to the box again. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compiler Woes (was: Re: RAM Recommendations for a VIA Mainboard?)
On Tue, 2003-09-16 at 18:48, Matthias Andree wrote: Scott Reese [EMAIL PROTECTED] writes: Though I'm not sure if RAM is my problem because I'm not getting Sig 11 errors. I keep getting extremely consistent internal compiler errors pretty much whenever I try to build *anything*. I've tried to buildkernel about 16 times today and each time I get stuck here (or very near here): /usr/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_run_data_fifo': /usr/src/sys/dev/aic7xxx/aic79xx.c:787: error: unrecognizable insn: [...] /usr/src/sys/dev/aic7xxx/aic79xx.c:787: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8345 An internal compiler error (ICE for short) can also be a compiler bug if it happens in the same place consistently. I recall other ICE Subject lines, but ignored the corresponding posts; the list archives may help you. Heh. Most of those messages were probably from me desperately seeking assistance of any kind (quick check confirms this). :) If you need to be sure what it is, rsync your source code and compiler to a different computer with similar OS and hardware and try there. If it fails in the same place, it's VERY unlikely to be the RAM. I do not have another machine I can use to test on, unfortunately. Upon attempting to buildkernel a couple more times today, I get the exact same ICE in the exact same place on the exact same snippet of code. I'm starting to lean towards a compiler bug or a bug in the FreeBSD implementation of gcc. If you've been running cvsup -s for a while, trying to run it once without -s might be useful in case some alteration went unnoticed by cvsup (haven't seen that so far, and it's an old recommendation, not sure if it still holds). I haven't been running cvsup -s. I just run the command line 'cvsup -g -L 2 source' (source being the name of my sup file). I'm currently installing the gcc33 package to see if this alleviates any of my difficulties. I was also wondering if there was a way to build the system with an older compiler (like, say, 3.1)? I had these same problems with 3.2.1 so I wondered if going back to an earlier version would eliminate the issue. Thanks, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
On Wed, Sep 17, 2003 at 12:52:03PM -0700, John-Mark Gurney wrote: Bernd Walter wrote this message on Wed, Sep 17, 2003 at 10:27 +0200: On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is either disk corruption or an ffs bug. ffs passes the garbage block number 0xe5441ae9720 to bread. GEOM then handles this austerely by panicing. Garbage block numbers, including negative ones, can possibly be created by applications seeking to preposterous offsets, so they should not be handled with panics. They most certainly should! If the range checking in any filesystem is not able to catch these cases I insist that GEOM do so with a panic. What is wrong with returning an IO error? I always hated panics because of filesystem corruptions. An alternative would be to just bring that filesystem down. Its easy to panic a whole system with a bogus filesystem on a removeable media. If you're file system is so hosed that it does this, then panicing is the only safe thing to do. You don't know what continued operation will do to the filesytem, and you might end up losing more data. You don't do anything to a filesystem if you force umount it on detected inconsistencies, but your system is still up. In which way could the filesystem further harmed? I have a bunch of MO media and also get media which were written by others - currently the only way to be safe is to fsck every media bevor mounting to not panic the system by just reading a removeable media. I have no clue on about how hard it is to implement, but I can't see anything wrong from the idea itself. As I already wrote in another mail - panicing inside GEOM sounds OK, because the FS shouldn't try to access unavailable blocks. It is not unresonable to put parameter restrictions on function calls. It is not much different from enforcing that a pointer is not NULL when being passed as an argument. It is different - if a pointer is NULL then we have a software problem. If the filesystem is broken then the software might be OK and the cause could even be outside your own system. -- 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]
What's happened to CDIOCREADAUDIO friends?
Hello,
We used to have this ioctl in old ATA/ATAPI driver (and still do in
sys/cdio.h); apparently, it's no longer there with ATAng. Is this a bug or
feature? And if this was planned what's going to replace it? As it is,
this change has broken cdparanoia cooked ioctls interface (BTW, that's why
it doesn't work without root privileges), xmms and xine CDDA support and
perhaps several more ports. Oh, incidentaly, cdparanoia (at least) is
broken under -CURRENT in yet another way: it still looks for
/dev/{acd,cd,mcd}%c -
ports/audio/cdparanoia/files/patch-interface-scan_devices.c
- which aren't there after cloning removal).
Regards,
Vladimir
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current troubles on Dell Latitude C600
Tried JSNAP's 20030917 build, still the same: with softupdates on I get a panic when extreacting base, with softupdates off everything is OK. Any ideas? Olev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
Bernd Walter wrote this message on Wed, Sep 17, 2003 at 22:27 +0200: If you're file system is so hosed that it does this, then panicing is the only safe thing to do. You don't know what continued operation will do to the filesytem, and you might end up losing more data. You don't do anything to a filesystem if you force umount it on detected inconsistencies, but your system is still up. In which way could the filesystem further harmed? I have a bunch of MO media and also get media which were written by others - currently the only way to be safe is to fsck every media bevor mounting to not panic the system by just reading a removeable media. I have no clue on about how hard it is to implement, but I can't see anything wrong from the idea itself. there is nothing wrong with the idea, but implementation is difficult. As far as GEOM is considered, it just gets data read/write requests from various backing objects, but has no idea what fs or even if it is an fs that is trying to access the block. It could be broken swap code, or some person's custom kernel web server, etc. GEOM just can't know how to behave in these cases. As I already wrote in another mail - panicing inside GEOM sounds OK, because the FS shouldn't try to access unavailable blocks. Exactly. It is not unresonable to put parameter restrictions on function calls. It is not much different from enforcing that a pointer is not NULL when being passed as an argument. It is different - if a pointer is NULL then we have a software problem. If the filesystem is broken then the software might be OK and the cause could even be outside your own system. If the filesystem is broken, then we still have a software bug for not asserting that the properties of the fs is maintained. If/when we ever support user mounting fs's, we need to make sure that the fs doesn't do wacky things and provide a way to escelate permissions or crash the box. -- 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 troubles on Dell Latitude C600
Olev wrote: Tried JSNAP's 20030917 build, still the same: with softupdates on I get a panic when extreacting base, with softupdates off everything is OK. Any ideas? Olev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] I can confirm I get the same on an old laptop I was trying. I just installed it with softupdates switched off and assumed it was my laptop being a bitch as it's traditionally done weird things in the past. I happened to take a photo of the screen at the time, though unfortunatly I didn't take a photo of a backtrace :) I can't help any further with debugging though because as I mentioned I just installed it without softupdates and it's working fine now. http://xtaz.co.uk/mobilecam/images/20030913150500.jpg Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
rc.subr jail devfs handling
Hi, I'm running a jail on -CURRENT with jail_enable=YES jail_list=myjail jail_myjail_rootdir=/home/myjail ... in /etc/rc.conf. I already filed a PR with a patch: PR bin/56748: jail devfs handling broken http://www.freebsd.org/cgi/query-pr.cgi?pr=56748 the problem is that I still can't get the /dev/console links right. Can someone with a little devfs knowledge point me in the right direction? Thanks Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compiler Woes (was: Re: RAM Recommendations for a VIA Mainboard?)
On Wed, Sep 17, 2003 at 01:21:39PM -0700, Scott Reese wrote: On Tue, 2003-09-16 at 18:48, Matthias Andree wrote: Scott Reese [EMAIL PROTECTED] writes: Though I'm not sure if RAM is my problem because I'm not getting Sig 11 errors. I keep getting extremely consistent internal compiler errors pretty much whenever I try to build *anything*. I've tried to buildkernel about 16 times today and each time I get stuck here (or very near here): An internal compiler error (ICE for short) can also be a compiler bug if it happens in the same place consistently. I recall other ICE Subject lines, but ignored the corresponding posts; the list archives may help you. Heh. Most of those messages were probably from me desperately seeking assistance of any kind (quick check confirms this). :) Most of those older posts were concerned with people who added -march=p4 or -march=athlon to CFLAGS. Those problems have been fixed with the latest GCC update in the source tree. I was also wondering if there was a way to build the system with an older compiler (like, say, 3.1)? I had these same problems with 3.2.1 so I wondered if going back to an earlier version would eliminate the issue. Going backwards with the compiler probably won't help. Have you tried installing 4.8 on this system. I still suspect you have a hardware problem. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI S3 battery drain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I reported this serveral times and no one seemed to be able to reproduce the problem, and I couldn't figure out what wasn't being shutoff. FInally I think that I figured it out. The display is the thing that is not being shutoff. The reason I missed this is because the backlight would shutoff and unless you look really close you can't tell that the display is still active. Not sure if this helps anyone, but it is one step closer. http://www.freebsd.org/cgi/query-pr.cgi?pr=56024 - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/aNUTxqA5ziudZT0RAsOIAJ47ZurYfae+4adG0hLAmfvzxyrNFACfQA/A c2zl38WWJbxbGORKQGiMvLg= =V6Ei -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vm_fault:
Hi. I get this panic on a system with kernel/world from 03 September. Usually i only run X and xawtv on that system but when i wanted to make world today i got the panic: Kris Kennaway reported something IMHO similar on 07/31/03 panic: vm_fault: fault on nofault entry, addr: deadc000 Debugger(panic) Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0 db trace Debugger(c03c1cf1,c043fd00,c03d3c82,e929f9e4,100) at Debugger+0x4d panic(c03d3c82,deadc000,1,e929fa80,e929fa70) at panic+0xcc vm_fault(c082f000,deadc000,1,0,c5db65f0) at vm_fault+0x1187 trap_pfault(e929fb48,0,deadc1e6,c03d958f,deadc1e6) at trap_pfault+0x163 trap(18,10,10,0,d222036c) at trap+0x2ca calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0328512, esp = 0xe929fb88, ebp = 0xe929fbb0 --- getdirtybuf(c5ebc8bc,0,1,1,e929fbe8) at getdirtybuf+0x22 flush_deplist(c5ebccc4,1,e929fbe8,e929fbec,0) at flush_deplist+0x32 flush_inodedep_deps(c5c63000,28c4,c040d6ac,c5eefb68,124) at flush_inodedep_deps+0x89 softdep_sync_metadata(e929fca8,0,c03d2cc0,124,0) at softdep_sync_metadata+0x7e ffs_fsync(e929fca8,0,c03c9837,ad8,0) at ffs_fsync+0x3a9 fsync(c5db65f0,e929fd14,c03d958f,3eb,1) at fsync+0x166 syscall(2f,2f,2f,80a1000,0) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (95, FreeBSD ELF32, fsync), eip = 0x2814ca0f, esp = 0xbfbff90c, ebp = 0xbfbff928 --- db Are there additional infos required ? Regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault:
On Wed, 17 Sep 2003, Florian C. Smeets wrote: Hi. I get this panic on a system with kernel/world from 03 September. Usually i only run X and xawtv on that system but when i wanted to make world today i got the panic: This was fixed recently. Can you cvsup and rebuild? Kris Kennaway reported something IMHO similar on 07/31/03 panic: vm_fault: fault on nofault entry, addr: deadc000 Debugger(panic) Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0 db trace Debugger(c03c1cf1,c043fd00,c03d3c82,e929f9e4,100) at Debugger+0x4d panic(c03d3c82,deadc000,1,e929fa80,e929fa70) at panic+0xcc vm_fault(c082f000,deadc000,1,0,c5db65f0) at vm_fault+0x1187 trap_pfault(e929fb48,0,deadc1e6,c03d958f,deadc1e6) at trap_pfault+0x163 trap(18,10,10,0,d222036c) at trap+0x2ca calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0328512, esp = 0xe929fb88, ebp = 0xe929fbb0 --- getdirtybuf(c5ebc8bc,0,1,1,e929fbe8) at getdirtybuf+0x22 flush_deplist(c5ebccc4,1,e929fbe8,e929fbec,0) at flush_deplist+0x32 flush_inodedep_deps(c5c63000,28c4,c040d6ac,c5eefb68,124) at flush_inodedep_deps+0x89 softdep_sync_metadata(e929fca8,0,c03d2cc0,124,0) at softdep_sync_metadata+0x7e ffs_fsync(e929fca8,0,c03c9837,ad8,0) at ffs_fsync+0x3a9 fsync(c5db65f0,e929fd14,c03d958f,3eb,1) at fsync+0x166 syscall(2f,2f,2f,80a1000,0) at syscall+0x253 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (95, FreeBSD ELF32, fsync), eip = 0x2814ca0f, esp = 0xbfbff90c, ebp = 0xbfbff928 --- db Are there additional infos required ? Regards, flo ___ [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]
[current tinderbox] failure on ia64/ia64
TB --- 2003-09-17 21:28:02 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-09-17 21:28:02 - 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-09-17 21:31:28 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-17 22:34:53 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Sep 17 22:34:53 GMT 2003 Kernel build for GENERIC completed on Wed Sep 17 22:50:46 GMT 2003 TB --- 2003-09-17 22:50:46 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-17 22:50:46 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Sep 17 22:50:46 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strtoul.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strtouq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/libkern/strvalid.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13
Re: Compiler Woes (was: Re: RAM Recommendations for a VIA Mainboard?)
On Wed, 2003-09-17 at 14:37, Steve Kargl wrote: On Wed, Sep 17, 2003 at 01:21:39PM -0700, Scott Reese wrote: On Tue, 2003-09-16 at 18:48, Matthias Andree wrote: Scott Reese [EMAIL PROTECTED] writes: Though I'm not sure if RAM is my problem because I'm not getting Sig 11 errors. I keep getting extremely consistent internal compiler errors pretty much whenever I try to build *anything*. I've tried to buildkernel about 16 times today and each time I get stuck here (or very near here): An internal compiler error (ICE for short) can also be a compiler bug if it happens in the same place consistently. I recall other ICE Subject lines, but ignored the corresponding posts; the list archives may help you. Heh. Most of those messages were probably from me desperately seeking assistance of any kind (quick check confirms this). :) Most of those older posts were concerned with people who added -march=p4 or -march=athlon to CFLAGS. Those problems have been fixed with the latest GCC update in the source tree. I just tried to buildworld with gcc-3.3.1_20030804 (the one in the tree is from 20030711 I believe) installed as a package and while I did no longer receive the dreaded ICE that I'm now so familiar with, I did get the following error: In file included from /usr/src/lib/libthr/thread/thr_private.h:61, from /usr/src/lib/libthr/thread/thr_printf.c:41: /usr/src/include/stdio.h:55: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/i386-portbld-freebsd5.1/3.3.1/include/stdarg.h:105: warning: `va_list' previously declared here *** Error code 1 Stop in /usr/src/lib/libthr. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I'm not sure how to fix that, but this snapshot seems to be working better despite the fact that I still can't buildworld or kernel. I was also wondering if there was a way to build the system with an older compiler (like, say, 3.1)? I had these same problems with 3.2.1 so I wondered if going back to an earlier version would eliminate the issue. Going backwards with the compiler probably won't help. Have you tried installing 4.8 on this system. I still suspect you have a hardware problem. What would that hardware problem be? This is what is driving me crazy. I'm running around beating my head against the wall trying to figure out what is wrong and no matter where I turn, I cannot get a definitive answer nor can I even find out how I might come across a definitive answer. I have not tried installing 4.8 on this system. The thought had crossed my mind, but I wanted to stay with 5.x since I've been running it since 5.0-RELEASE. Besides, if I do have a hardware problem what difference would installing 4.8 make? -Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
On Tue, 16 Sep 2003, Morten Rodal wrote: So this brings up the question, is there a known problem with debugging multi-threaded applications (which use libkse) that can cause a panic? I will bring home my laptop, and will be able to use a serial debugger if that would help anyone willing to trace this down. Probably :) This came up at the developer summit. We do need to upgrade/make significant changes to gdb for it to understand threaded debugging. The panics might be interesting as it might be tickling other issues, but before we can really debug threaded apps we need a new gdb. -- 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]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-09-17 23:00:42 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-09-17 23:00:42 - 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-09-17 23:04:01 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-17 23:57:36 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Sep 17 23:57:36 GMT 2003 Kernel build for GENERIC completed on Thu Sep 18 00:06:42 GMT 2003 TB --- 2003-09-18 00:06:42 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-18 00:06:42 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Sep 18 00:06:42 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strtoul.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strtouq.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/strvalid.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/net/bpf.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
Re: acd0 vs cd0 (ATAPICAM)
Le Mer 17/09/2003 à 07:40, Thomas Quinot a écrit : Le 2003-09-17, Bryan Liesner écrivait : The patch seems to work, my cd0 and cd1 lines in the dmesg now report 33.000 MB/s insetad of 3.300 MB/s. OK, good, so that's one half of the problem resolved. Now, can you test whether the actual performances are improved or still slow? The patch does nothing for me. Same results... and cd0 is still slow. Guillaume ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
getfacl long groupnames (getfacl: test: Cannot allocate memory) (fwd)
Hi, it looks like getfacl has problems with long groupnames: add a group named averylonggroupname touch acl-test setfacl -m g:averylonggroupname:rw acl-test bash-2.05b# getfacl acl-test #file:acl-test #owner:0 #group:2000 getfacl: acl-test: Cannot allocate memory this seems to be a problem with getfacl, because viewing this file from windows via SAMBA makes no problems, i.e. I can see the averylonggroupname group with access-rights. I'm running 5.1-RELEASE, bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-rel deleted it's own MBR
Hi all, big mysterious bug is lingering somwhere. (Machine: C3, 256MB, 2x 30GB 2,5 IDE, SIL0680 controller) One of my drives failed with the following recovered from messages: Sep 16 01:47:44 tek kernel: ad4: WRITE command timeout tag=0 serv=0 - resetting Sep 16 01:47:45 tek kernel: ata2: resetting devices .. Sep 16 01:47:45 tek kernel: ad4: removed from configuration Sep 16 01:47:45 tek kernel: ar0: WARNING - mirror lost Sep 16 01:47:45 tek kernel: ad4: deleted from ar0 disk0 Sep 16 01:47:45 tek kernel: done This was at 1:47 but the machine ran until about 5:30. Then it died (no message!) When I tried to reboot, BIOS complained about missing MBR. And indeed, when I opened the server and connected the drives to another box, BOTH drives had no partition table I got a correct bsdlabel from both, ad6 and ad6s1. How can this happen? Bug in ata? Bug in GEOM? Nobody was loged in and also nobody can log in so the machine deleted it. That's really sure! My fix was to use the fixit CD and wrote a new one with: fdisk -I -B -b /boot/boot1 ar0 fdisk -u ar0 (to change the starting sector from 63 to 0) fsck found a few errors but the server is up and running again. Søren: I remember you're planning better RAID management support. Will it be possible to control the ar0 by the controller's BIOS in the future? When I rebuilt the array with the BIOS (which took 6 hours!) FreeBSD still reported a degraded RAID1! This was really annoying Thanks, -Harry pgp0.pgp Description: signature
Re: SMP kernel panic with traceback
On Thu, 18 Sep 2003, Bruce Evans wrote: On Wed, 17 Sep 2003, Daniel Eischen wrote: I'm getting crashes when trying to debug mozilla (under KSE). The panic message is panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled. Attached is the trace. Any ideas? Eeek. Looks like I forgot an attachment to i386/machdep.c 1.468 2001/08/13 (use interrupt gates instead of trap gates for breakpoint and trace traps). Keeping interrupts disabled is only correct for these traps if they are from kernel mode. It's surprising how few problems this has caused. This patch seems to fix the problem. Care to commit it? Thanks! -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
sebastian ssmoller wrote: On Wed, 2003-09-17 at 20:16, Don Bowman wrote: From: sebastian ssmoller [mailto:[EMAIL PROTECTED] ... i turned of acpi on startup an voila :) : gdm starts two times faster as before (!) (30s - 15-17s) can anyone explain me why, pls ? I wonder how hot your processor is? perhaps ACPI is throttling the clock back, either duty cycle or frequency. In your bios you can set the power mode, perhaps you can set 'full power always'. lmmon might show something. here is my lmmon output. Motherboard Temp Voltages 255C / 491F / 528KVcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1:0 rpm+12.0V: +15.938V 2:0 rpm-12.0V: -15.938V 3:0 rpm- 5.0V: -6.654V i'm not sure whether this output is correct : 255 C ?? so this should be a reason for acpi to throttling the cpu, doesnt it ? :) can u give me a hint how to correct these values ? (cause hardware is ok this should be a software/config probem (?) I wonder if lmmon is unaware that acpi provides temperatures in deciKelvins, not Kelvins. 25.5C would be a much more reasonable value, though my system typically runs in the 40-50C range. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad performance
On Wed, Sep 17, 2003 at 08:19:38PM +0200, sebastian ssmoller wrote: (...) btw: the mozilla-firebird performance problem mention earlier seems to be something different: firebird launches relativly fast and as soon as running i can us the menus and everything which is reachable via mouse. but as soon as i use the keyboard (e.g. typing an internet addr) or switch the window into background and back into foreground moz-firebird hangs for minutes (!). but this only happens the first time after start. when it runs it performs rather good i will try to build a new version these days and will see what happens ... Sounds like you just need to disable Find as you type in mozilla (does anyone actually *use* this feature???). -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: latest -CURRENT kernel fails to build
On Wed, 17 Sep 2003, M. Warner Losh wrote: pcic and newcard are an unsupported combination. take pcic out of your kernel. Warner Thanks Warner... Somehow I had the #device pcic like the generic kernel but guess I had to force write the kernel config file. Probably would be a good idea to remove the pcic line in the GENERIC kernel even though it's commented out. Now, the kernel fails to build here which is related to the ath(4) driver. cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel.debug if_ath.o: In function `ath_attach': /usr/src/sys/dev/ath/if_ath.c:192: undefined reference to `ath_hal_attach' if_ath.o: In function `ath_tx_start': /usr/src/sys/dev/ath/if_ath.c:1873: undefined reference to `ath_hal_computetxtime' /usr/src/sys/dev/ath/if_ath.c:1899: undefined reference to `ath_hal_computetxtime' /usr/src/sys/dev/ath/if_ath.c:1903: undefined reference to `ath_hal_computetxtime' /usr/src/sys/dev/ath/if_ath.c:1906: undefined reference to `ath_hal_computetxtime' if_ath.o: In function `ath_getchannels': /usr/src/sys/dev/ath/if_ath.c:2463: undefined reference to `ath_hal_init_channels' /usr/src/sys/dev/ath/if_ath.c:2476: undefined reference to `ath_hal_mhz2ieee' if_ath.o: In function `ath_attach': /usr/src/sys/dev/ath/if_ath.c:186: undefined reference to `sysctl__hw_ath_children' /usr/src/sys/dev/ath/if_ath.c:192: undefined reference to `sysctl__hw_ath_children' /usr/src/sys/dev/ath/if_ath.c:199: undefined reference to `sysctl__hw_ath_children' /usr/src/sys/dev/ath/if_ath.c:215: undefined reference to `sysctl__hw_ath_children' /usr/src/sys/dev/ath/if_ath.c:224: undefined reference to `sysctl__hw_ath_children' if_ath.o:/usr/src/sys/dev/ath/if_ath.c:231: more undefined references to `sysctl__hw_ath_children' follow if_ath_pci.o: In function `ath_pci_probe': /usr/src/sys/dev/pci/pcivar.h:203: undefined reference to `ath_hal_probe' *** Error code 1 Stop in /usr/obj/usr/src/sys/BIGBANG. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. [EMAIL PROTECTED] [4:18pm][/usr/src] Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2674] ACPI S3 battery drain
On Wed, 17 Sep 2003, Anish Mistry wrote: I reported this serveral times and no one seemed to be able to reproduce the problem, and I couldn't figure out what wasn't being shutoff. FInally I think that I figured it out. The display is the thing that is not being shutoff. The reason I missed this is because the backlight would shutoff and unless you look really close you can't tell that the display is still active. Not sure if this helps anyone, but it is one step closer. http://www.freebsd.org/cgi/query-pr.cgi?pr=56024 Just a short heads-up. I have been focusing attention on fixing panics first and will eventually get around to other problem reports. I have been logging reports but not working on them. -Nate ___ [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-09-18 04:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-09-18 04:00:01 - 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-09-18 04:01:51 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-18 05:04:44 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Thu Sep 18 05:04:44 GMT 2003 Kernel build for GENERIC completed on Thu Sep 18 05:16:32 GMT 2003 TB --- 2003-09-18 05:16:32 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-18 05:16:32 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Sep 18 05:16:32 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/libkern/strtoul.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/libkern/strtouq.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/libkern/strvalid.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/net/bpf.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
