Re: panic: pmap_zero_page: CMAP3 busy
On 11 Oct, Steve Kargl wrote: Upgrade tonight (7pm PST) and received the following on rebooting panic: pmap_zero_page: CMAP3 busy Unfortunately, this system does not have a serial console and the panic locked it up tight. Only a hard reset brought the system back. I was just about to type make installworld when I got this message I checked the commit logs and didn't see any recent commits that looked suspicious, and since I do have a serial console I decided to throw caution to the wind and give the new kernel a try. Other than an annoyingly long pause while GEOM waits for my SCSI cdrom drive to figure out that it is empty (which has been noted in another thread), my system booted without any problems. My kernel has everything commited to the present time except: tjr 2003/10/11 21:25:26 PDT FreeBSD src repository Modified files: sys/i386/ibcs2 ibcs2_misc.c ibcs2_signal.c ibcs2_socksys.c ibcs2_util.c ibcs2_util.h imgact_coff.c Log: Fix a multitude of security bugs in the iBCS2 emulator: - Return NULL instead of returning memory outside of the stackgap in stackgap_alloc() (FreeBSD-SA-00:42.linux) - Check for stackgap_alloc() returning NULL in ibcs2_emul_find(); other calls to stackgap_alloc() have not been changed since they are small fixed-size allocations. - Replace use of strcpy() with strlcpy() in exec_coff_imgact() to avoid buffer overflow - Use strlcat() instead of strcat() to avoid a one byte buffer overflow in ibcs2_setipdomainname() - Use copyinstr() instead of copyin() in ibcs2_setipdomainname() to ensure that the string is null-terminated - Avoid integer overflow in ibcs2_setgroups() and ibcs2_setgroups() by checking that gidsetsize argument is non-negative and no larger than NGROUPS_MAX. - Range-check signal numbers in ibcs2_wait(), ibcs2_sigaction(), ibcs2_sigsys() and ibcs2_kill() to avoid accessing array past the end (or before the start) Revision ChangesPath 1.52 +21 -3 src/sys/i386/ibcs2/ibcs2_misc.c 1.32 +7 -2 src/sys/i386/ibcs2/ibcs2_signal.c 1.19 +5 -3 src/sys/i386/ibcs2/ibcs2_socksys.c 1.17 +4 -2 src/sys/i386/ibcs2/ibcs2_util.c 1.17 +4 -1 src/sys/i386/ibcs2/ibcs2_util.h 1.61 +1 -1 src/sys/i386/ibcs2/imgact_coff.c Maybe this problem only affects certain hardware. Here is my dmesg.boot for comparison: 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 #28: Sat Oct 11 21:58:42 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERICSMB Preloaded elf kernel /boot/kernel/kernel at 0xc0a8f000. Preloaded elf module /boot/kernel/aout.ko at 0xc0a8f244. Preloaded elf module /boot/kernel/acpi.ko at 0xc0a8f2f0. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1900+ (1608.23-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 1073676288 (1023 MB) avail memory = 1033592832 (985 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: GBTAWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fdc30 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 10 INTA is routed to irq 11 pcib0: slot 12 INTA is routed to irq 15 agp0: AMD 761 host to AGP bridge port 0xc000-0xc003 mem 0xef02-0xef020fff,0xe800-0xebff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 1:5 INTA BIOS irq 15 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xc400-0xc40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xc800-0xc81f irq 10 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhub0: port
Re: panic: pmap_zero_page: CMAP3 busy
On Sat, 11 Oct 2003, Don Lewis wrote: On 11 Oct, Steve Kargl wrote: Upgrade tonight (7pm PST) and received the following on rebooting panic: pmap_zero_page: CMAP3 busy Unfortunately, this system does not have a serial console and the panic locked it up tight. Only a hard reset brought the system back. I was just about to type make installworld when I got this message I checked the commit logs and didn't see any recent commits that looked suspicious, and since I do have a serial console I decided to throw caution to the wind and give the new kernel a try. I had this very same panic which happened right after commits to locore.s and machdep.c. Reverting back to the previous versions (with everything else up-to-date) let it boot without panicking. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: pmap_zero_page: CMAP3 busy
On Sun, 2003-10-12 at 02:02, Don Lewis wrote: On 11 Oct, Steve Kargl wrote: Upgrade tonight (7pm PST) and received the following on rebooting panic: pmap_zero_page: CMAP3 busy Unfortunately, this system does not have a serial console and the panic locked it up tight. Only a hard reset brought the system back. I was just about to type make installworld when I got this message I checked the commit logs and didn't see any recent commits that looked suspicious, and since I do have a serial console I decided to throw caution to the wind and give the new kernel a try. See my previous email dated Sat, 11 Oct 2003 01:39:20 -0400 on the subject. It looks like the problem may have to do with CPU type (PIII in my case). My P4 laptop has the same -CURRENT, and does not experience the problem. It may also be noteworthy that I have CPU_ENABLE_SSE on my PIII as well. Joe Other than an annoyingly long pause while GEOM waits for my SCSI cdrom drive to figure out that it is empty (which has been noted in another thread), my system booted without any problems. My kernel has everything commited to the present time except: tjr 2003/10/11 21:25:26 PDT FreeBSD src repository Modified files: sys/i386/ibcs2 ibcs2_misc.c ibcs2_signal.c ibcs2_socksys.c ibcs2_util.c ibcs2_util.h imgact_coff.c Log: Fix a multitude of security bugs in the iBCS2 emulator: - Return NULL instead of returning memory outside of the stackgap in stackgap_alloc() (FreeBSD-SA-00:42.linux) - Check for stackgap_alloc() returning NULL in ibcs2_emul_find(); other calls to stackgap_alloc() have not been changed since they are small fixed-size allocations. - Replace use of strcpy() with strlcpy() in exec_coff_imgact() to avoid buffer overflow - Use strlcat() instead of strcat() to avoid a one byte buffer overflow in ibcs2_setipdomainname() - Use copyinstr() instead of copyin() in ibcs2_setipdomainname() to ensure that the string is null-terminated - Avoid integer overflow in ibcs2_setgroups() and ibcs2_setgroups() by checking that gidsetsize argument is non-negative and no larger than NGROUPS_MAX. - Range-check signal numbers in ibcs2_wait(), ibcs2_sigaction(), ibcs2_sigsys() and ibcs2_kill() to avoid accessing array past the end (or before the start) Revision ChangesPath 1.52 +21 -3 src/sys/i386/ibcs2/ibcs2_misc.c 1.32 +7 -2 src/sys/i386/ibcs2/ibcs2_signal.c 1.19 +5 -3 src/sys/i386/ibcs2/ibcs2_socksys.c 1.17 +4 -2 src/sys/i386/ibcs2/ibcs2_util.c 1.17 +4 -1 src/sys/i386/ibcs2/ibcs2_util.h 1.61 +1 -1 src/sys/i386/ibcs2/imgact_coff.c Maybe this problem only affects certain hardware. Here is my dmesg.boot for comparison: 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 #28: Sat Oct 11 21:58:42 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERICSMB Preloaded elf kernel /boot/kernel/kernel at 0xc0a8f000. Preloaded elf module /boot/kernel/aout.ko at 0xc0a8f244. Preloaded elf module /boot/kernel/acpi.ko at 0xc0a8f2f0. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1900+ (1608.23-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 1073676288 (1023 MB) avail memory = 1033592832 (985 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: GBTAWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fdc30 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 10 INTA is routed to irq 11 pcib0: slot 12 INTA is routed to irq 15 agp0: AMD 761 host to AGP bridge port 0xc000-0xc003 mem 0xef02-0xef020fff,0xe800-0xebff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 1:5 INTA BIOS irq 15 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xc400-0xc40f at device 7.1 on pci0 ata0: at
Re: panic: pmap_zero_page: CMAP3 busy
On Sun, Oct 12, 2003 at 02:35:21AM -0400, Joe Marcus Clarke wrote: On Sun, 2003-10-12 at 02:02, Don Lewis wrote: On 11 Oct, Steve Kargl wrote: Upgrade tonight (7pm PST) and received the following on rebooting panic: pmap_zero_page: CMAP3 busy Unfortunately, this system does not have a serial console and the panic locked it up tight. Only a hard reset brought the system back. I was just about to type make installworld when I got this message I checked the commit logs and didn't see any recent commits that looked suspicious, and since I do have a serial console I decided to throw caution to the wind and give the new kernel a try. See my previous email dated Sat, 11 Oct 2003 01:39:20 -0400 on the subject. It looks like the problem may have to do with CPU type (PIII in my case). My P4 laptop has the same -CURRENT, and does not experience the problem. It may also be noteworthy that I have CPU_ENABLE_SSE on my PIII as well. Ditto with PIII and CPU_ENABLE_SSE. I was able to get a traceback, but I didn't bother to write it down. I can do so if necessary. CPU: Pentium III/Pentium III Xeon/Celeron (497.44-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Kris pgp0.pgp Description: PGP signature
Interrupt statistics?
Does anyone have recent statistics for interrupt latency and arrival timings? I am very interested in our idle load characteristics. It seems most systems I've analyzed have an average idle interrupt rate of about 225 per second, dominated by the clk and rtc interrupts as shown below. clk irq099/sec rtc irq8 127/sec Since these are both clocks, I assume the arrival of their interrupts are equally spaced and not correlated to each other. How much latency do the handlers for these have? Are there any system processes which generate repetitive bursts of very short tasks? If so, how long do those tasks take? The reason why I ask is I'm coming up with a default policy for CPU sleep states which can have as high a latency as a few hundred microseconds. On an idle system, this should be fine although it does add to the latency for the above clock handlers. But I also need to be able to demote quickly to short sleep states (e.g., HLT) if the system is becoming active to decrease response times. Thanks for any info, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass(4)/uhci(4) REALLY slow
Nate Lawson wrote this message on Tue, Sep 30, 2003 at 17:34 -0700: 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec which is still well under the USB 1.1 max speed. If you get 1.2MB/sec (megabytes), then you have hit the max of USB 1.1, the max speed of USB 1.1 is 12mbits/sec. -- 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: panic: pmap_zero_page: CMAP3 busy
On Sun, 2003-10-12 at 02:41, Kris Kennaway wrote: On Sun, Oct 12, 2003 at 02:35:21AM -0400, Joe Marcus Clarke wrote: On Sun, 2003-10-12 at 02:02, Don Lewis wrote: On 11 Oct, Steve Kargl wrote: Upgrade tonight (7pm PST) and received the following on rebooting panic: pmap_zero_page: CMAP3 busy Unfortunately, this system does not have a serial console and the panic locked it up tight. Only a hard reset brought the system back. I was just about to type make installworld when I got this message I checked the commit logs and didn't see any recent commits that looked suspicious, and since I do have a serial console I decided to throw caution to the wind and give the new kernel a try. See my previous email dated Sat, 11 Oct 2003 01:39:20 -0400 on the subject. It looks like the problem may have to do with CPU type (PIII in my case). My P4 laptop has the same -CURRENT, and does not experience the problem. It may also be noteworthy that I have CPU_ENABLE_SSE on my PIII as well. Ditto with PIII and CPU_ENABLE_SSE. I was able to get a traceback, but I didn't bother to write it down. I can do so if necessary. The above mentioned email (subject PANIC with tonight's -CURRENT) has the DDB trace (though it might not be very useful), and my machine is: CPU: Intel Pentium III (748.28-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MXX,FXSR,SSE 640 MB RAM FreeBSD 5.1-CURRENT #11: Sat Oct 11 01:26:41 EDT 2003 Joe CPU: Pentium III/Pentium III Xeon/Celeron (497.44-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Kris -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
panic: pmap_zero_page: CMAP3 busy
afd0: REMOVABLE IOMEGA ZIP 250 ATAPI at ata1-master PIO3 acd0: CDROM SAMSUNG SC-148P at ata3-master PIO4 panic: pmap_zero_page: CMAP3 busy Debugger(panic) Stopped at 0xc062f644 = Debugger+0x54: xchgl %ebx,0xc0736c24 = in_Debugger.0 db trace Debugger(c0689675,c06e18c0,c069daaf,d88b1cb4,100) at 0xc062f644 = Debugger+0x54 panic(c069daaf,c0c61cb8,d88b1cd4,c05fe7aa,c0c61cb8) at 0xc04fa865 = panic+0xd5 pmap_zero_page_idle(c0c61cb8,0,c0699a1e,6b,c4402260) at 0xc063db4c = pmap_zero_page_idle+0x1c vm_page_zero_idle(c452e618,0,c0699a1e,97,d88b1d0c) at 0xc05fe7aa = vm_page_zero_idle+0x9a vm_pagezero(0,d88b1d48,c068719b,314,36208a1) at 0xc05fe98e = vm_pagezero+0xee fork_exit(c05fe8a0,0,d88b1d48) at 0xc04e5a7f = fork_exit+0xcf fork_trampoline() at 0xc0630ddc = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd88b1d7c, ebp = 0 --- db -- 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]
panic with -current kernel ata_timeout
with a -current cvsup I'm getting a kernel panic during boot: ata_timout soft_clock ithread fork_exit fork_trampoline __trap 0x1 -- Chris Christoph Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: pmap_zero_page: CMAP3 busy
Joe Marcus Clarke [EMAIL PROTECTED] writes: See my previous email dated Sat, 11 Oct 2003 01:39:20 -0400 on the subject. It looks like the problem may have to do with CPU type (PIII in my case). My P4 laptop has the same -CURRENT, and does not experience the problem. It may also be noteworthy that I have CPU_ENABLE_SSE on my PIII as well. My new P4 consistently panics at boot (immediately before, or while, starting init) with pmap_zero_page: CMAP3 busy with both SMP and UP kernels built from fresh sources. It boots fine with a three days old SMP kernel. CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2411.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs 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]
What's up with the IP stack?
I've just built and installed a new kernel, the first since Aug 6th. There appears to be a problem with the IP stack. What happens is that everything is fine for a few hours, and then the IP stack stops working. I can no longer ping anything on the local network, my default route drops out (which is probably dhclient's doing). Perhaps it is ARP that is broken, it's hard to tell. All I know is that I need to reboot to make it work again. Is anyone else experiencing this kind of problem? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
Re: What's up with the IP stack?
It seems Josef Karthauser wrote: I've just built and installed a new kernel, the first since Aug 6th. There appears to be a problem with the IP stack. What happens is that everything is fine for a few hours, and then the IP stack stops working. I can no longer ping anything on the local network, my default route drops out (which is probably dhclient's doing). Perhaps it is ARP that is broken, it's hard to tell. All I know is that I need to reboot to make it work again. Is anyone else experiencing this kind of problem? Do you have dummynet included in the kernel ? That has been broken for me since sam's latest commit as a backout of ip_dummynet.c fixes the problem for me... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
no kernel output after update
OS was -current from 8th Feb and I updated to recent one today. Now I have a new world, but forced to keep with the Feb kernel, because the new kernel gives absolutely no output. Console should be on vga. I already tried switching to a vga card and to disable int routing, because I often saw problems with this kind of configuration. [63]cicely6# cat /boot/device.hints hint.fdc.0.at=isa hint.fdc.0.port=0x3F0 hint.fdc.0.irq=6 hint.fdc.0.drq=2 hint.fd.0.at=fdc0 hint.fd.0.drive=0 hint.fd.1.at=fdc0 hint.fd.1.drive=1 hint.ata.0.at=isa hint.ata.0.port=0x1F0 hint.ata.0.irq=14 hint.ata.1.at=isa hint.ata.1.port=0x170 hint.ata.1.irq=15 hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x060 hint.atkbd.0.at=atkbdc hint.atkbd.0.irq=1 hint.atkbd.0.flags=0x1 hint.vga.0.at=isa hint.sc.0.at=isa hint.sc.0.flags=0x100 hint.npx.0.at=nexus hint.npx.0.port=0x0F0 hint.npx.0.irq=13 hint.sio.0.at=isa hint.sio.0.port=0x3F8 #hint.sio.0.flags=0x10 hint.sio.0.irq=4 hint.sio.1.at=isa hint.sio.1.port=0x2F8 hint.sio.1.irq=3 hint.sio.2.at=isa hint.sio.2.port=0x3E8 hint.sio.2.irq=11 hint.sio.3.at=isa hint.sio.3.port=0x2E8 hint.sio.3.irq=10 hint.ppc.0.at=isa hint.ppc.1.at=isa #hint.ppc.0.irq=7 hint.isic.0.at=isa hint.isic.0.port=0x340 hint.isic.0.irq=5 hint.isic.0.flags=4 [65]cicely6# cat /usr/src/sys/i386/conf/CICELY6 machine i386 cpu I586_CPU ident CICELY6 maxusers32 makeoptions DEBUG=-g options SCHED_4BSD #optionsSCHED_ULE options INET options INET6 options MROUTING options IPSEC options IPSEC_ESP options IPSEC_DEBUG options FFS options UFS_DIRHASH #Improve performance on big directories options SOFTUPDATES options NFSCLIENT options PROCFS options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000 options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET options BRIDGE device random #optionsDDB #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsWITNESS device isa device pci device ata device atadisk device atkbdc device atkbd device vga device sc device npx device sio device ppc device ppbus device lpt device de device loop device ether device tun device pty device gif device faith device bpf device md options AVM_A1 device isic device i4bq921 device i4bq931 device i4b device i4btrc4 device i4bctl device i4brbch 4 device i4btel2 #device i4bipr4 options IPR_VJ device i4bisppp 6 device sppp #device i4bing4 options NETGRAPH#netgraph(4) system options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_BRIDGE options NETGRAPH_CISCO options NETGRAPH_ECHO options NETGRAPH_ETHER options NETGRAPH_FRAME_RELAY options NETGRAPH_GIF options NETGRAPH_GIF_DEMUX options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_IP_INPUT options NETGRAPH_KSOCKET options NETGRAPH_L2TP options NETGRAPH_LMI # MPPC compression requires proprietary files (not included) #optionsNETGRAPH_MPPC_COMPRESSION options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_ONE2MANY options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_RFC1490 options NETGRAPH_SOCKET options NETGRAPH_SPLIT options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC #device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) #device udbp# USB Double Bulk Pipe devices device ugen# Generic device uhid# Human Interface Devices device ulpt# Printer device ucom device uftdi device uplcom device uvscom [64]cicely6# dmesg Copyright (c) 1992-2003 The FreeBSD Project. Copyright
Re: ad0: WARNING - WRITE_DMA recovered from missing interrupt
On Sat, Oct 11, 2003 at 04:05:36PM -0500, Derek Ragona wrote: What type of drive is in your dell? I get this same error with an SATA drive and adapter. ad0: 28615MB IC25N030ATDA04-0 [58140/16/63] at ata0-master UDMA100 I believe it's an IBM Travelstar . -- Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de -Derek At 07:22 PM 10/11/2003 +0200, C. Kukulies wrote: ad0: WARNING - WRITE_DMA recovered from missing interrupt Got this on my Dell Inspiron 8000 while dhclient was running interactively and wi0: busy bit won't clear was happening. At the moment with a recently cvsuped -current wi0 on my gateway (PCI-PCMCIA adapter card) seems to be broken as well as this everlasting wi0: busy bit won't clear thing which breaks WLAN on my Dell Inspiron for weeks now. ___ [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-mobile 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]
[Build Error]:: pccard
Hi all there haves been some problems with the pccard* for like 2 weeks i have not been abel to compile the kernel. fest it was the pccardvar.h was mising this:: // in pccard_mem_handle longoffset; /* mapped Offset on card */ #define PCCARD_MEM_ATTR 1 #define PCCARD_MEM_COMMON 2 but now i cant find the problem.. any one else haveing this prob?. -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Build Error]:: pccard
On Sun, Oct 12, 2003 at 03:37:44PM +, Sebastian Yepes F. [ESN] wrote: Hi all there haves been some problems with the pccard* for like 2 weeks i have not been abel to compile the kernel. fest it was the pccardvar.h was mising this:: Did you follow all the instructions in UPDATING? I have been building GENERIC successfully from source over the past 2 weeks with a rolling cvs checkout from my local repository mirror. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Build Error]:: pccard
On Sun, 12 Oct 2003 14:43:59 +0100 Bruce M Simpson [EMAIL PROTECTED] wrote: On Sun, Oct 12, 2003 at 03:37:44PM +, Sebastian Yepes F. [ESN] wrote: Hi all there haves been some problems with the pccard* for like 2 weeks i have not been abel to compile the kernel. fest it was the pccardvar.h was mising this:: Did you follow all the instructions in UPDATING? I have been building GENERIC successfully from source over the past 2 weeks with a rolling cvs checkout from my local repository mirror. BMS mm i ahev must of not seen the UPDATEING info.. i have just looked at it and don't see any info related to the pccard dev. what are the instructions -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's up with the IP stack?
On Sun, Oct 12, 2003 at 02:48:01PM +0200, Soren Schmidt wrote: It seems Josef Karthauser wrote: I've just built and installed a new kernel, the first since Aug 6th. There appears to be a problem with the IP stack. What happens is that everything is fine for a few hours, and then the IP stack stops working. I can no longer ping anything on the local network, my default route drops out (which is probably dhclient's doing). Perhaps it is ARP that is broken, it's hard to tell. All I know is that I need to reboot to make it work again. Is anyone else experiencing this kind of problem? Do you have dummynet included in the kernel ? That has been broken for me since sam's latest commit as a backout of ip_dummynet.c fixes the problem for me... No, I've not got dummynet in there. My current kernel config is: machine i386 cpu I586_CPU cpu I686_CPU ident GENIUS maxusers0 hints GENIUS.hints #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols #optionsCPU_ENABLE_SSE #enables SSE/MMX2 instructions support. options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options NETGRAPH #optionsBRIDGE # Debugging for use in -current options DDB #Enable the kernel debugger #optionsINVARIANTS #Enable calls of extra sanity checking #optionsINVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #optionsWITNESS #Enable checks to detect deadlocks and cycles #optionsWITNESS_SKIPSPIN#Don't run witness on spinlocks for speed #optionsBUS_DEBUG options USB_DEBUG #optionsDIAGNOSTIC device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver options VESA device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_HISTORY_SIZE=3000# number of history buffer lines device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support
Re: ATAng still causing a lot of pain.
Further details: The ATA drive in questions is: ad0: 114473MB WDC WD1200JB-00DUA3 [232581/16/63] at ata0-master PIO4 The PIO4 comes from booting with 'hw.ata.ata_dma=0'; it would otherwise be UDMA66. Basically, if I use atacontrol to set that channel to WDMA2 or below, then I get no errors (but performance is awful). At UDMA2 I been to see TIMEOUT - WRITE_DMA and TIMEOUT - READ_DMA messages, but the system recovers. At UDMA4 and above, the kernel panics. -- Kirk Strauser 94 outdated ports on the box, 94 outdated ports. Portupgrade one, an hour 'til done, 82 outdated ports on the box. pgp0.pgp Description: PGP signature
Re: [Build Error]:: pccard
In message: [EMAIL PROTECTED] Sebastian Yepes F. [ESN] [EMAIL PROTECTED] writes: : i have just looked at it and don't see any info related to the pccard dev. : what are the instructions building both pcic and pccard in your kernel config? If so, don't do that. It is broken. pcic cannot possibly work, even if I fix the trivial compile problem. I have some changes in my p4 tree, but they aren't cooked yet. Your best bet is to simply remove pcic from your kernel config file. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interrupt statistics?
In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : Does anyone have recent statistics for interrupt latency and arrival : timings? In -stable I know that we service fast interrupts in 10us on a 666MHz machine 99.2% of the time. I don't know about non-fast interrupts, but other results suggest that we'd do 99+% in less than 100us. This is to the first instruction of the ISR. The ISRs that I've been running typically run for 2us (since they do 30 instructions plus 2 ISA I/Os). I've not made similar measurments for -current, but those numbers do represent at least some level of 'goal' to shoot for. : I am very interested in our idle load characteristics. It seems : most systems I've analyzed have an average idle interrupt rate of about : 225 per second, dominated by the clk and rtc interrupts as shown below. : : clk irq099/sec : rtc irq8 127/sec : : Since these are both clocks, I assume the arrival of their interrupts are : equally spaced and not correlated to each other. How much latency do the : handlers for these have? Are there any system processes which generate : repetitive bursts of very short tasks? If so, how long do those tasks : take? These are clock interrupts. One is used for timing the system (clk), while the other is used for profiling the system. They are asynchronous to each other so that the profiling can profile more effectively. On my systems with higher HZ setting, the clk interrupts will happen more often, obviously. : The reason why I ask is I'm coming up with a default policy for CPU sleep : states which can have as high a latency as a few hundred microseconds. On : an idle system, this should be fine although it does add to the latency : for the above clock handlers. But I also need to be able to demote : quickly to short sleep states (e.g., HLT) if the system is becoming active : to decrease response times. The important thig with the time keeping devices is not to loose interrupts, since that's how we tick out time. On non-idle systems, there's issues with latency on the ticks, but on idle systems there wouldn't be. 100us of latency would effecively limit HZ to 5000 or so (I think that the Nyquist limit would apply, otherwise it is 1). Some time units have a wrap around that makes 100Hz impossible and faster rates must be used. If you are going into a CPU state that's low, it might make sense to increase the tick time, but I'm sure phk would have things to say about that and its wisdom (or lack there of). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interrupt statistics?
On Sat, 11 Oct 2003, Nate Lawson wrote: Does anyone have recent statistics for interrupt latency and arrival timings? I am very interested in our idle load characteristics. It seems According to machdep.siots, fast interrupt handler latency on an old Celeron266 is about 10 usec (max) for short runs under favourable circumstances (idle system and no hoggish fast interrupt handlers). General interrupt latency can be huge (many msec), since some interrupt handlers are blocked by Giant and Giant can be held for a long time. most systems I've analyzed have an average idle interrupt rate of about 225 per second, dominated by the clk and rtc interrupts as shown below. clk irq099/sec rtc irq8 127/sec Since these are both clocks, I assume the arrival of their interrupts are equally spaced and not correlated to each other. How much latency do the handlers for these have? About 10 usec (max), as above, since they are fast interrupt handlers (except in my version). In fact they are the main source of interrupt latency (for other interrupts) on idle systems. Are there any system processes which generate repetitive bursts of very short tasks? If so, how long do those tasks take? I haven't noticed any significant sources of such (I don't use any nonstandard hardware or sound cards). Every system that I've looked at (mainly my own and freebsd.org ones) has amazingly low interrupt activity, with more rtc+clk interrupts than all others combined (except transiently). The reason why I ask is I'm coming up with a default policy for CPU sleep states which can have as high a latency as a few hundred microseconds. On an idle system, this should be fine although it does add to the latency for the above clock handlers. But I also need to be able to demote quickly to short sleep states (e.g., HLT) if the system is becoming active to decrease response times. At least on i386's, the latency for clock interrupts is unimportant (except possibly when kern.timecounter.hardware = i8254) since interrupts are not used directly for timekeeping. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
cd0 errors during probe?
Can I assume that the following error messages are erronous because cd0 appears to function without any problems? There is a CD in the drive. cd0 at ahc0 bus 0 target 4 lun 0 cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [129875 x 2048 byte records] (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retries Exhausted (cd0:ahc0:0:4:0): cddone: got error 0x5 back (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retries Exhausted (cd0:ahc0:0:4:0): cddone: got error 0x5 back (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retries Exhausted (cd0:ahc0:0:4:0): cddone: got error 0x5 back (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB:
[current tinderbox] failure on alpha/alpha
TB --- 2003-10-12 16:00:02 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-12 16:00:02 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-10-12 16:00:02 - 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-10-12 16:01:58 - 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-10-12 17:05: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 Sun Oct 12 17:05:50 GMT 2003 Kernel build for GENERIC completed on Sun Oct 12 17:17:39 GMT 2003 TB --- 2003-10-12 17:17:39 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-12 17:17:39 - 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 Sun Oct 12 17:17:39 GMT 2003 [...] rmd160.o(.text+0x50): multiple definition of `RMD160Update' rmd160.o(.text+0x50): first defined here rmd160.o: In function `RMD160Transform': rmd160.o(.text+0x370): multiple definition of `RMD160Transform' rmd160.o(.text+0x370): first defined here rmd160.o: In function `RMD160Final': rmd160.o(.text+0x1c0): multiple definition of `RMD160Final' rmd160.o(.text+0x1c0): first defined here *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-10-12 17:28:44 - /usr/bin/make returned exit code 1 TB --- 2003-10-12 17:28:44 - ERROR: failed to build lint kernel TB --- 2003-10-12 17:28:44 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Build Error]:: pccard
In message: [EMAIL PROTECTED] Sebastian Yepes F. [ESN] [EMAIL PROTECTED] writes: : i have just looked at it and don't see any info related to the pccard dev. : what are the instructions building both pcic and pccard in your kernel config? If so, don't do that. It is broken. pcic cannot possibly work, even if I fix the trivial compile problem. I have some changes in my p4 tree, but they aren't cooked yet. Your best bet is to simply remove pcic from your kernel config file. That's good to know. My laptop seems to vaguely work with pcic(it has a intel compatibility mode). Will pcic support cardbus at all? Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's up with the IP stack?
On Sun, 12 Oct 2003, Josef Karthauser wrote: On Sun, Oct 12, 2003 at 02:48:01PM +0200, Soren Schmidt wrote: It seems Josef Karthauser wrote: I've just built and installed a new kernel, the first since Aug 6th. There appears to be a problem with the IP stack. What happens is that everything is fine for a few hours, and then the IP stack stops working. I can no longer ping anything on the local network, my default route drops out (which is probably dhclient's doing). Perhaps it is ARP that is broken, it's hard to tell. All I know is that I need to reboot to make it work again. Is anyone else experiencing this kind of problem? Do you have dummynet included in the kernel ? That has been broken for me since sam's latest commit as a backout of ip_dummynet.c fixes the problem for me... No, I've not got dummynet in there. My current kernel config is: I experienced this a week ago. I found that ifconfig'ing the interface down and back up again fixed the problem. I've since reverted to a kernel compiled on September 25th. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Build Error]:: pccard
In message: [EMAIL PROTECTED] Stuart Walsh [EMAIL PROTECTED] writes: : In message: [EMAIL PROTECTED] : Sebastian Yepes F. [ESN] [EMAIL PROTECTED] writes: : : i have just looked at it and don't see any info related to the pccard : dev. : : what are the instructions : : building both pcic and pccard in your kernel config? If so, don't do : that. It is broken. pcic cannot possibly work, even if I fix the : trivial compile problem. I have some changes in my p4 tree, but they : aren't cooked yet. Your best bet is to simply remove pcic from your : kernel config file. : : : That's good to know. My laptop seems to vaguely work with pcic(it has a : intel compatibility mode). Will pcic support cardbus at all? Nope. It can't. pcic is for ISA bridges, none of which can support CardBus. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's up with the IP stack?
On Sunday 12 October 2003 11:03 am, Andre Guibert de Bruet wrote: On Sun, 12 Oct 2003, Josef Karthauser wrote: On Sun, Oct 12, 2003 at 02:48:01PM +0200, Soren Schmidt wrote: It seems Josef Karthauser wrote: I've just built and installed a new kernel, the first since Aug 6th. There appears to be a problem with the IP stack. What happens is that everything is fine for a few hours, and then the IP stack stops working. I can no longer ping anything on the local network, my default route drops out (which is probably dhclient's doing). Perhaps it is ARP that is broken, it's hard to tell. All I know is that I need to reboot to make it work again. Is anyone else experiencing this kind of problem? Do you have dummynet included in the kernel ? That has been broken for me since sam's latest commit as a backout of ip_dummynet.c fixes the problem for me... No, I've not got dummynet in there. My current kernel config is: I experienced this a week ago. I found that ifconfig'ing the interface down and back up again fixed the problem. I've since reverted to a kernel compiled on September 25th. It would be good to know more details; I still don't have much to go on. Try to identify, for example, if the problem is specific to a particular device/interface or feature you're using (e.g dummynet). If you have ddb in your system, then when the system gets into a bad state break into the debugger and look for threads that are blocked on locks. If you have witness in your kernel then show locks would also be useful. If you don't have witness in your system then rebuild your kernel with it. The most recent round of changes were to lock the routing table. These went in 10/3 and were extensive. They could easily be the problem but w/o more info I can't really help. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interrupt statistics?
On Sun, Oct 12, 2003 at 09:55:03AM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : Does anyone have recent statistics for interrupt latency and arrival : timings? In -stable I know that we service fast interrupts in 10us on a 666MHz machine 99.2% of the time. I don't know about non-fast interrupts, but other results suggest that we'd do 99+% in less than 100us. This is to the first instruction of the ISR. The ISRs that I've been running typically run for 2us (since they do 30 instructions plus 2 ISA I/Os). From the serial application I did recently I know that writing 8 bytes at 19200bps could pause the output for 286us and 429us after 5 bytes in about 50% tries with 16C552 ISA hardware. Given the fact we get the interrupt before the last stop bit goes out the real latency in handling is a multiple of this. However - this was with an old current and I can retry with a recent one once I get over the no kernel output problem. If things should be acurate I can modify ISA hardware with a micro- controller to do real measurements on a socket 7 HX board. -- 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: no kernel output after update
On Sun, Oct 12, 2003 at 03:23:46PM +0200, Bernd Walter wrote: OS was -current from 8th Feb and I updated to recent one today. Now I have a new world, but forced to keep with the Feb kernel, because the new kernel gives absolutely no output. Console should be on vga. I already tried switching to a vga card and to disable int routing, because I often saw problems with this kind of configuration. I was told by someone else with the same problem that a kernel from 3. October still worked for him. -- 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]
[current tinderbox] failure on i386/i386
TB --- 2003-10-12 18:35:24 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-12 18:35:24 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-10-12 18:35:24 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-12 18:37:40 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/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/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-12 19:35:03 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Oct 12 19:35:03 GMT 2003 Kernel build for GENERIC completed on Sun Oct 12 19:49:21 GMT 2003 TB --- 2003-10-12 19:49:21 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-12 19:49:21 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Oct 12 19:49:21 GMT 2003 [...] rmd160.o(.text+0x70): multiple definition of `RMD160Update' rmd160.o(.text+0x70): first defined here rmd160.o: In function `RMD160Transform': rmd160.o(.text+0x2c0): multiple definition of `RMD160Transform' rmd160.o(.text+0x2c0): first defined here rmd160.o: In function `RMD160Final': rmd160.o(.text+0x190): multiple definition of `RMD160Final' rmd160.o(.text+0x190): first defined here *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-10-12 20:01:41 - /usr/bin/make returned exit code 1 TB --- 2003-10-12 20:01:41 - ERROR: failed to build lint kernel TB --- 2003-10-12 20:01:41 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: Bluetooth patch is about to be committed
Dear Hackers, In the next few hours i will be committing Bluetooth patch. The patch was reviewed by M. Warner Losh [EMAIL PROTECTED] and John Hay [EMAIL PROTECTED] After commit i will re-cvsup my system and will do a full buildworld (could take 4-6 hours) to make sure everything works. Expect bumps :) Please feel free to contact me if you have bluetooth/build problems and believe that it is my fault :) thanks, max __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cd0 errors during probe?
On Sun, Oct 12, 2003 at 10:26:54 -0700, Steve Kargl wrote: Can I assume that the following error messages are erronous because cd0 appears to function without any problems? There is a CD in the drive. cd0 at ahc0 bus 0 target 4 lun 0 cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [129875 x 2048 byte records] (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) Looks like GEOM is trying to read the first sector of the CD, but since it's likely an audio CD, it doesn't quite work. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE status; interactivity fixed? nice uninvestigated, HTT broken
I commited a fix that would have caused all of the jerky behaviors under some load. I was not able to reproduce this problem with kde running afterwards. I'm going to look into the reports of some problems with nice, although I suspect that they could have been caused by the same issues. HTT is awaiting some jhb fixes which are awaiting some UMA fixes. I'll give an update on that later. Cheers, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-10-12 20:01:41 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-12 20:01:41 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-10-12 20:01:41 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-12 20:03:50 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/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/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-12 21:01:12 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Oct 12 21:01:12 GMT 2003 Kernel build for GENERIC completed on Sun Oct 12 21:13:05 GMT 2003 TB --- 2003-10-12 21:13:05 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-12 21:13:05 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Oct 12 21:13:05 GMT 2003 [...] rmd160.o(.text+0x70): multiple definition of `RMD160Update' rmd160.o(.text+0x70): first defined here rmd160.o: In function `RMD160Transform': rmd160.o(.text+0x2c0): multiple definition of `RMD160Transform' rmd160.o(.text+0x2c0): first defined here rmd160.o: In function `RMD160Final': rmd160.o(.text+0x190): multiple definition of `RMD160Final' rmd160.o(.text+0x190): first defined here *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-10-12 21:23:32 - /usr/bin/make returned exit code 1 TB --- 2003-10-12 21:23:32 - ERROR: failed to build lint kernel TB --- 2003-10-12 21:23:32 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cd0 errors during probe?
On Sun, Oct 12, 2003 at 02:51:50PM -0600, Kenneth D. Merry wrote: On Sun, Oct 12, 2003 at 10:26:54 -0700, Steve Kargl wrote: Can I assume that the following error messages are erronous because cd0 appears to function without any problems? There is a CD in the drive. cd0 at ahc0 bus 0 target 4 lun 0 cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [129875 x 2048 byte records] (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) Looks like GEOM is trying to read the first sector of the CD, but since it's likely an audio CD, it doesn't quite work. Yes, it is an audio CD. I suspected that it was a transient GEOM/CAM issue, but wanted to make sure before I needlessly replaced the cdrom drive. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seeing system-lockups on recent current
I'm seeing similar lockups, however they started shortly after the new ATA code was committed. The lockups usually occur when there's a lot of ATA activity, e.g. filesystem or fsck. At the moment I can only guess as to what the problem might be (missing interrupt is my most educated guesss) but keeping the amount of ATA I/O to a minimum does help the situation. Both machines which have suffered the problem have intel chipsets. One is a 12 year old P120 (I cannot recall the exact chipset) and the other is a PIII with an 815E chipset. On a couple of occasions I had systat running and noticed that buffers in use climbed until the system just froze, responding only to pings. In all cases all filesystems were generally clean just with the dirty bit set, except for filesystem on an ATA drive (/var or /export) which required considerable cleanup. Filesystems that reside on SCSI devices have yet to exhibit any symptoms, e.g. requiring anything more than resetting the dirty bit. Due to this problem I've yet to complete a portupgrade, something I've been trying to complete over the last four weeks, as it usually hangs the system within 12 hours. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ In message [EMAIL PROTECTED], Garance A Drosihn writes: For the past week or so, I have been having a frustrating time with my freebsd-current/i386 system. It is a dual Athlon system. It has been running -current just fine since December, with me updating the OS every week or two. I did not update it for most of September, and then went to update it to pick up the recent round of security-related fixes. My first update run picked up a change which caused system panics. Other people were also seeing that panic, and it wasn't long before updates were committed to current to fix that problem. However, ever since then my -current system has very frequently locked up. Totally locked. The only way to get it back is a hardware reset. I have rebuilt the system at least a dozen times since then. I have built it with snapshots of /usr/src from Sept 12th to Oct 8th (which is what it's running at the moment). I have dropped back to a single-CPU kernel. I turned off X (in /etc/ttys) so that doesn't start up at all. All those attempts to get a reliable 5.x-system have not worked. Sometimes the system will crash in the middle of a buildworld, other times it will crash while it's basically idle and the monitor is turned off. One time it crashed in the middle of an installworld -- right when it was replacing /lib files. Boy was that a headache to recover from! On the same PC, in a different DOS partition, is a 4.x-stable system. If I boot into 4.x, I have no problems. I fire up all the servers that I run, start buildworlds, run cvsup's, and even had all the 5.x partitions mounted and was running a infinite-loop that MD5'd every file in the 5.x system. I had all of that going on at the same time, and the system is fine. While in the 4.x system, I've removed /usr/src on the 5.x system and recreated it, just in case there were some files corrupted in there. And once the problems started, I made a point of always removing all of /usr/obj/usr/src before starting the buildworld, in case there were corrupted files in there. I still have a few things I want to try. And I know it could still be a hardware problem (although it bugs me that it fails so consistently on 5.x and never fails on 4.x). Perhaps it is just some disk-corruption problem that occurred during the first few panics. But I thought I'd at least mention it, and see if anyone else has been having similar problems. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot hang: ata1: resetting devices .. done (5.1-CURRENT, IBM T30)
In the last episode (Oct 08), Robert Ferguson said: I see this problem as well. I'm running on a T40, with a DVD/CDRW in the ultrabay, and -CURRENT as of this morning. At boot, it hangs immediately after ad0: 35174MB IC25N040ATCS05-0 [71465/16/63] at ata0-master UDMA100 ata1: resetting devices .. done Backing out the most recent checkin to sys/dev/ata/ata-queue.c (i.e. reverting to version 1.6) makes the problem go away. I upgraded from an Oct 1 - Oct 12 kernel and saw the same hang. Backing out r1.6 fixed it for me too. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cd0 errors during probe?
On Sun, Oct 12, 2003 at 14:29:38 -0700, Steve Kargl wrote: On Sun, Oct 12, 2003 at 02:51:50PM -0600, Kenneth D. Merry wrote: On Sun, Oct 12, 2003 at 10:26:54 -0700, Steve Kargl wrote: Can I assume that the following error messages are erronous because cd0 appears to function without any problems? There is a CD in the drive. cd0 at ahc0 bus 0 target 4 lun 0 cd0: TOSHIBA CD-ROM XM-6401TA 1001 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [129875 x 2048 byte records] (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): BLANK CHECK asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): Retrying Command (per Sense Data) Looks like GEOM is trying to read the first sector of the CD, but since it's likely an audio CD, it doesn't quite work. Yes, it is an audio CD. I suspected that it was a transient GEOM/CAM issue, but wanted to make sure before I needlessly replaced the cdrom drive. There's nothing wrong with your drive, most likely. I suppose it plays audio CDs and reads data CDs okay? If so, it's nothing to worry about. Back when the cd(4) driver used the old slice code, it had a function, cdfirsttrackisdata(), that figured out whether the first track was an audio or data track. It would set the flags in the disk structure accordingly to tell the slice code whether or not to attempt to read a disklabel from the CD. The code in -stable still works that way. My guess is that we need something similar again to tell GEOM not to attempt to read the first sector of the CD when it's not a data CD. Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot hang: ata1: resetting devices .. done (5.1-CURRENT, IBM T30)
Quoting Dan Nelson [EMAIL PROTECTED]: In the last episode (Oct 08), Robert Ferguson said: I see this problem as well. I'm running on a T40, with a DVD/CDRW in the ultrabay, and -CURRENT as of this morning. At boot, it hangs immediately after ad0: 35174MB IC25N040ATCS05-0 [71465/16/63] at ata0-master UDMA100 ata1: resetting devices .. done Backing out the most recent checkin to sys/dev/ata/ata-queue.c (i.e. reverting to version 1.6) makes the problem go away. I upgraded from an Oct 1 - Oct 12 kernel and saw the same hang. Backing out r1.6 fixed it for me too. me too Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot hang: ata1: resetting devices .. done (5.1-CURRENT, IBMT30)
Backing out the most recent checkin to sys/dev/ata/ata-queue.c (i.e. reverting to version 1.6) makes the problem go away. I upgraded from an Oct 1 - Oct 12 kernel and saw the same hang. Backing out r1.6 fixed it for me too. me too Anyone tried going forward to 1.8? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR in dummynet
map02# uname -a FreeBSD map02.modrany.czf 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 12 22:33:45 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ROUTER i386 Oct 13 00:25:32 map02 kernel: lock order reversal Oct 13 00:25:32 map02 kernel: 1st 0xc301f194 inp (inp) @ /usr/src/sys/netinet/tcp_usrreq.c:363 Oct 13 00:25:32 map02 kernel: 2nd 0xc095cc80 dummynet (dummynet) @ /usr/src/sys/netinet/ip_dummynet.c:1135 Oct 13 00:25:33 map02 kernel: Stack backtrace: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cd0 errors during probe?
In message [EMAIL PROTECTED], Kenneth D. Merry writes: Back when the cd(4) driver used the old slice code, it had a function, cdfirsttrackisdata(), that figured out whether the first track was an audio or data track. It would set the flags in the disk structure accordingly to tell the slice code whether or not to attempt to read a disklabel from the CD. The code in -stable still works that way. My guess is that we need something similar again to tell GEOM not to attempt to read the first sector of the CD when it's not a data CD. Or do what the atapi-cd code does: indicate the true sector size (2352 bytes) and use whatever read audio command is appropriate for that situation. I'm somewhat [1] unhappy that the atapi-cd and the scsi_cd present multitrack CD's in two different ways, and from a POLA [2] perspective I must say that the /dev/acd%dt%02d devices do make a lot of sense. Poul-Henning [1] Not terribly because I seldomly use it myself, but the inconsistency still bothers me. [2] Your POLA may vary. -- 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]
panic: softdep_deallocate_dependencies: dangling deps
My notebook was a little bit panic this night. After rebooting I found this message in my system log: panic: softdep_deallocate_dependencies: dangling deps ? Regards, Oliver Fischer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic with cdrecord -- anybody else seeing this? [backtrace obtained]
Hi all, forgive me if I give incomplete information. This is the first time
I've created a debugging kernel and gotten a dump after a panic, so I might not
have done everything right.
Ever since the tail end of July it seems, any time I've tried to burn a CD with
cdrecord (cdrtools 2.0.3 from ports) I get a panic
vm_fault_copy_wired: page missing
General busy-ness and the thought that somebody will see it too and fix it
has prevented me from caring too much about it until now, but it seems it's
still there in the kernel from Oct 11th, and I figured I might as well try to
provide somebody some information ..
My h/w: Abit IC7 i875-based system with one S-ATA disk sitting on ata2 and one
DVD burner sitting on ata0. I have a Tekram DC-390U controller which attaches
to the CD-ROM, CDRW in question, and a tape drive.
I temporarily booted a kernel/modules (with $module_path correctly set at the
loader) built from Oct 11th and saw the same panic, and here's what gdb says
about it:
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: vm_fault_copy_wired: page missing
panic messages:
---
panic: vm_fault_copy_wired: page missing
cpuid = 0; lapic.id =
panic: from debugger
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 6m3s
ata0: spurious interrupt - status=0x51 error=0x04
Dumping 1023 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 512 528 544 560 576 592 608 624 640 656 672 688
704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
Reading symbols from
/usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/WHALE/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /boot/kernel/snd_ich.ko...done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
#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 0xc050f107 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc050f4b6 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0448c82 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc0448be2 in db_command (last_cmdp=0xc06eea20, cmd_table=0x0,
aux_cmd_tablep=0xc06bce9c, aux_cmd_tablep_end=0xc06bcea0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0448d25 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc044bd25 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc064bf4c in kdb_trap (type=3, code=0, regs=0xec1b5b30)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc0664b0a in trap (frame=
{tf_fs = -333774824, tf_es = -1067122672, tf_ds = -959709168, tf_edi =
-1066719322, tf_esi = 1, tf_ebp = -333751428, tf_isp = -333751460, tf_ebx = 0, tf_edx
= 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1067138475, tf_cs
= 8, tf_eflags = 658, tf_esp = -1066705215, tf_ss = -1066776060})
at /usr/src/sys/i386/i386/trap.c:579
#9 0xc064d948 in calltrap () at {standard input}:103
#10 0xc050f44f in panic (fmt=0xc06b27a6 vm_fault_copy_wired: page missing)
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc06151eb in vm_fault_copy_entry (dst_map=0xc6cc88dc, src_map=0xc6cc83f0,
dst_entry=0xc71fca14, src_entry=0x0) at /usr/src/sys/vm/vm_fault.c:1187
#12 0xc061b491 in vm_map_copy_entry (src_map=0xc6cc83f0, dst_map=0xc6cc88dc,
src_entry=0xc6d41d5c, dst_entry=0xc71fca14) at /usr/src/sys/vm/vm_map.c:2379
#13 0xc061b73e in vmspace_fork (vm1=0xc6cc83f0) at /usr/src/sys/vm/vm_map.c:2494
#14 0xc061676e in vm_forkproc (td=0xc6caad10, p2=0xc72043c8, td2=0xc72005f0,
flags=20) at /usr/src/sys/vm/vm_glue.c:624
#15 0xc04fb6a8 in fork1 (td=0xc6caad10, flags=20, pages=0, procp=0xec1b5cd8)
at /usr/src/sys/kern/kern_fork.c:654
#16 0xc04fa71b in fork (td=0xc6caad10, uap=0xec1b5d10)
at /usr/src/sys/kern/kern_fork.c:102
#17 0xc0665480 in syscall (frame=
Re: panic: softdep_deallocate_dependencies: dangling deps
On Mon, 13 Oct 2003, Oliver Fischer wrote: My notebook was a little bit panic this night. After rebooting I found this message in my system log: panic: softdep_deallocate_dependencies: dangling deps ? When are your sources from? Regards, Oliver Fischer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
On Tuesday 16 September 2003 08:12 pm, Kenneth D. Merry wrote: 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 ] I just committed a fix to the ath driver for the WEP problem; let me know if you have any more trouble. I verified 40-, 104-, and 128-bit WEP keys work for me. As a bonus I also sped up WEP traffic through the driver. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
_mtx_assert() panic
One of the package machines died with this, running -current from a few days ago. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc055ea8e stack pointer = 0x10:0xd9c029c8 frame pointer = 0x10:0xd9c029e8 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 = 6332 (pkg_create) kernel: type 12 trap, code=0 Stopped at _mtx_assert+0x4e: movl0x1c(%ebx),%eax db trace _mtx_assert(0,1,c073fd34,dd2,ff) at _mtx_assert+0x4e vfs_bio_clrbuf(ceb9dca0,2,0,d9c02a38,ceb9dca0) at vfs_bio_clrbuf+0x1fd ufs_strategy(d9c02b08,d9c02b34,c05b6967,d9c02b08,0) at ufs_strategy+0xce ufs_vnoperate(d9c02b08,0,0,8000,0) at ufs_vnoperate+0x18 cluster_read(c5c4cdb0,1ce5df0,0,2,0) at cluster_read+0x487 ffs_read(d9c02be0,1020002,c5081e40,1ff,d9c02c7c) at ffs_read+0x2f0 vn_read(c61ae770,d9c02c7c,c53a4880,0,c5081e40) at vn_read+0x1a2 dofileread(c5081e40,c61ae770,5,bfbfe4a0,400) at dofileread+0xd9 read(c5081e40,d9c02d10,c0755a1e,3ed,3) at read+0x6b syscall(2f,1002f,bfbf002f,0,1cd5df0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (3, FreeBSD ELF32, read), eip = 0x28210b6f, esp = 0xbfbfe39c, ebp = 0xbfbfe8b8 --- db pgp0.pgp Description: PGP signature
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Sun, Oct 12, 2003 at 06:32:21PM -0700, John Reynolds wrote: Hi all, forgive me if I give incomplete information. This is the first time I've created a debugging kernel and gotten a dump after a panic, so I might not have done everything right. Ever since the tail end of July it seems, any time I've tried to burn a CD with cdrecord (cdrtools 2.0.3 from ports) I get a panic vm_fault_copy_wired: page missing General busy-ness and the thought that somebody will see it too and fix it has prevented me from caring too much about it until now, but it seems it's still there in the kernel from Oct 11th, and I figured I might as well try to provide somebody some information .. Thanks..Alan made a commit which he thought might have fixed this, but someone else also claimed it did not. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 Kris pgp0.pgp Description: PGP signature
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Sunday, October 12, Kris Kennaway wrote: ] Thanks..Alan made a commit which he thought might have fixed this, but someone else also claimed it did not. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 Kris Is there any more information that I can provide which might help a VM guru out there figure out what has gone awry? BTW: I've tried the cdrtools-devel port as well thinking it was cdrecord's fault, but even the latest devel version panics with the same panic message. I can provide full boot -v dmesg output or anything else that somebody wants/needs. For what it's worth, I do NOT have atapicam compiled into or loaded into this system, though I was planning on it in the future so that cdrecord good grok my recently acquired DVD burner. -Jr -- John Jennifer Reynolds johnjen at reynoldsnet.orgwww.reynoldsnet.org Structural / Physical Design - ICG/PNG SCD jreynold at sedona.ch.intel.com Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! Unix is user friendly, it's just particular about the friends it chooses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS-UP: SADB_X_AALG_RIPEMD160HMAC was changed
Hi, I've just corrected the value of SADB_X_AALG_RIPEMD160HMAC from 9 to 8. If you are using IPsec stuff, it breaks binary compatibility. When updating your kernel, you need to update libipsec, setkey, racoon and isakmpd appropriately. Sincerely, ---BeginMessage--- ume 2003/10/12 21:54:51 PDT FreeBSD src repository Modified files: lib/libipsec pfkey_dump.c sys/conf files sys/net pfkeyv2.h sys/netinet6 ah_core.c usr.sbin/setkey setkey.8 token.l Log: - support AES XCBC MAC for AH - correct SADB_X_AALG_RIPEMD160HMAC to 8 Obtained from: KAME Revision ChangesPath 1.10 +3 -0 src/lib/libipsec/pfkey_dump.c 1.831 +3 -2 src/sys/conf/files 1.10 +2 -1 src/sys/net/pfkeyv2.h 1.18 +7 -0 src/sys/netinet6/ah_core.c 1.26 +2 -0 src/usr.sbin/setkey/setkey.8 1.7 +1 -0 src/usr.sbin/setkey/token.l ---End Message--- -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Sun, Oct 12, 2003 at 09:49:59PM -0700, John Reynolds wrote: [ On Sunday, October 12, Kris Kennaway wrote: ] Thanks..Alan made a commit which he thought might have fixed this, but someone else also claimed it did not. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 Kris Is there any more information that I can provide which might help a VM guru out there figure out what has gone awry? BTW: I've tried the cdrtools-devel port as well thinking it was cdrecord's fault, but even the latest devel version panics with the same panic message. The backtrace might be enough (I was waiting on the PR author to provide one), but alan will ask if he needs more information. Kris pgp0.pgp Description: PGP signature
Re: ULE status; interactivity fixed? nice uninvestigated, HTT broken
Jeff Roberson wrote: I commited a fix that would have caused all of the jerky behaviors under some load. I was not able to reproduce this problem with kde running afterwards. It think it seems better (hard to be sure) but the issue is still there for me. GNOME/Metacity Single Processor Athlon Tbird IDE Disk USB Mouse (moused running) AGP Radeon 9000 (using drm) -Wade ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Sun, Oct 12, 2003 at 09:18:08PM -0700, Kris Kennaway wrote: On Sun, Oct 12, 2003 at 06:32:21PM -0700, John Reynolds wrote: Hi all, forgive me if I give incomplete information. This is the first time I've created a debugging kernel and gotten a dump after a panic, so I might not have done everything right. Ever since the tail end of July it seems, any time I've tried to burn a CD with cdrecord (cdrtools 2.0.3 from ports) I get a panic vm_fault_copy_wired: page missing General busy-ness and the thought that somebody will see it too and fix it has prevented me from caring too much about it until now, but it seems it's still there in the kernel from Oct 11th, and I figured I might as well try to provide somebody some information .. Thanks..Alan made a commit which he thought might have fixed this, but someone else also claimed it did not. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56380 And http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57611 The latter is a bit more detailed and correct (it's not limited to ATAPI burners). It also doesn't seem to be limited to cdrecord, the latest ntpd also causes a panic when using mlockall(2) as reported on this list, however the backtrace looks different. Btw., the cdrtools-devel port contains a workaround. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE status; interactivity fixed? nice uninvestigated, HTT broken
On 2003-10-13 01:33 -0400, Wade Majors wrote: Jeff Roberson wrote: I commited a fix that would have caused all of the jerky behaviors under some load. I was not able to reproduce this problem with kde running afterwards. It think it seems better (hard to be sure) but the issue is still there for me. GNOME/Metacity Single Processor Athlon Tbird IDE Disk USB Mouse (moused running) AGP Radeon 9000 (using drm) -Wade After updating to revision 1.58 of src/sys/kern/sched_ule.c and giving my system a good run for a few hours, things seem much better. There is still lag, but it is only occasional and rarely as severe as before. Windowmaker, TBird 1200, IDE disk, PS/2 mouse, NVIDIA driver. Probably not as taxing as Wade's GNOME setup. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel compile problem: Stop in /usr/src/sys/crypto/des/arch/i386/des_enc.S
preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:1822:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:1859:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:1896:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:1933:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:1972:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2009:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2046:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2083:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2120:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2157:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2194:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2231:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2268:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2305:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2342:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2379:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2416:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2453:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2490:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2527:11: invalid preprocessing directive #Round /usr/src/sys/crypto/des/arch/i386/des_enc.S:2565:11: invalid preprocessing directive #Fixup /usr/src/sys/crypto/des/arch/i386/des_enc.S:2586:11: invalid preprocessing directive #Load /usr/src/sys/crypto/des/arch/i386/des_enc.S:2591:11: invalid preprocessing directive #IP /usr/src/sys/crypto/des/arch/i386/des_enc.S:2650:11: invalid preprocessing directive #FP /usr/src/sys/crypto/des/arch/i386/des_enc.S:2705:11: invalid preprocessing directive #Load /usr/src/sys/crypto/des/arch/i386/des_enc.S:2710:11: invalid preprocessing directive #IP /usr/src/sys/crypto/des/arch/i386/des_enc.S:2769:11: invalid preprocessing directive #FP *** Error code 1 Stop in /usr/src/sys/modules/smbfs. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/MAJIN-20031012. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This occurs both when using the generic and my custom kernel config, after a full cvsup and make buildworld/installworld, and attempting to bring myself up from the kernel circa 5.0-RC3. So, I guess I've a pair of questions: first, has anyone else encountered this problem, and know how to fix it? And second, is there a way to force reuse of already-compiled code between kernel compiles? Tho machine that's having this error is a P2-266, and takes somewhat over an hour to get to this point each time. - -- Michael Langwiser [EMAIL PROTECTED] ICQ: 18483276 AIM: Mandoric 1.802.823.5668 ll public keys at http://bakudon.net/pubkey.txt web:http://bakudon.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/ij1dS7Zmr7GPAqURAtNqAKCPipyYsrHECWUzQHVTUGzMfVg9JgCfcsH0 PKa5GKqsPyQEnwJpD/le/zc= =HIQG -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
