APIC-UP related panic
Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! The only thing I have are these lines from /var/log/messages: (attached the different dmesgs) Nov 5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d Nov 5 13:41:40 cale kernel: stack pointer = 0x10:0xcdc9dbe0 Nov 5 13:41:40 cale kernel: frame pointer = 0x10:0xcdc9dbe4 Nov 5 13:41:40 cale kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1 Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap Nov 5 13:41:40 cale kernel: Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 5 13:41:40 cale kernel: giving up on 1022 buffers Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s Nov 5 13:41:40 cale kernel: Shutting down ACPI Nov 5 13:41:40 cale kernel: stray irq9 Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 13:41:40 cale kernel: Rebooting... 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: Tue Nov 4 22:18:02 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel /boot/kernel/kernel at 0xc09c1000. Preloaded elf module /boot/kernel/linux.ko at 0xc09c1244. Preloaded elf module /boot/kernel/nvidia.ko at 0xc09c12f0. ACPI APIC Table: D815EA EA81510A Timecounter i8254 frequency 1183576 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07600e2 (122) VESA: NVIDIA acpi0: D815EA D815EPFV on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci2: PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib2 fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2 uhub2: 4 ports with 4 removable, self powered ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01,
yppasswd fails on 5.1 box
Yppasswd fails on my 5.1 box (has always worked on 4.5 to 5.0) with yppasswd: pam_chauthtok(): error in service module There's also a syslog message: Nov 4 22:54:54 *** yppasswd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: ***: RPC: Program not registered Yet rpcinfo -p shows: 191 udp821 yppasswdd 191 tcp 1010 yppasswdd Any suggestions? -- __ Guy Van Sanden http://unixmafia.port5.com Registered Linux user #249404 - September 1997 __ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Intel I440GX+
Hi, I have a test server here that runs -CURRENT, just cvs'd to the latest and greatest. Well, it doesn't seem to like my ACPI is my guess. Once it display's the motherboard's ACPI it panic's and reboots. I'll have to of course go back to an old kernel since I stupidly tookout the debugger. This isn't my normal email address also so if you could send reply's to this email address. I was wondering most of all if anyone else with an Intel I440GX+ P2-450 roughly was experiencing problems? Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem before. Quite rare. Thanks -- Scott Likens [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel I440GX+
On Thu, 6 Nov 2003, Scott Likens wrote: ... Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem before. I hope you are using P3s, or Xeon CPUs not P2s, since P2s are not able to cache memory above 512MB, which means that things will be real slow. Quite rare. Thanks -- Scott Likens [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]
current panics
Hi, I got panic during the boot: ioapic0: Changing APIC ID to 2 ioapic0 Version 0.3 irqs 0-23 on motherboard panic: Can't find ExtINT pin to route through! cpuid=0; Is it known problem ? -Kirill pgp0.pgp Description: PGP signature
Re: Improvements to fsck performance in -current ...?
Kevin Oberman wrote: To get to UFS2, you must newfs the partition. I don't know of nay other way. The basic improvement in UFS2 is the expansion of many fields to 64 bits to allow for much larger structures. While newfs in V5.1 and CURRENT defaults to UFS2, there are no problems continuing to run UFS1 file systems. Extended attributes, ACL and MAC do not work well on UFS1. I've tried, a decided it was just not worth the pain (particularly since that was rwatson's general feeling about it too). -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [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]
we want GB2312 and GBK
Traditionally, FreeBSD just support EUC as the standard locale of chinese language, but in fact we use GB2312 and GBK, even GB18030 in P.R.China, so I think the GB2312 and GBK should be included in the base system in order to support chinease ideally. Of course, if GB18030 could be well supported I think it is better:) Best Regards, bfdream EDA Lab, Circuits and Systems Division, Department of Electronic Engineering, Tsinghua University, Beijing, P.R.China. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bus error
Hi, Hi today, cvsup'ed my source and build world ... and now get an so called Bus error while i want to su, anyone know about it (or fixed it) I think the best is to build debugging version of su: # cd /usr/src/usr.bin/su # make clean # make depend # set CFLAGS=$CFLAGS -g # make # install -o root -g wheel -m 4555 -fschg /usr/obj/usr/src/usr.bin/su/su /usr/bin ( 'make install' will strip the binary and all the nice debug info is gone) Now run su in the debugger, and will probably get a core dump: gdb /usr/bin/su 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...(no debugging symbols found)... (gdb) run Starting program: /usr/bin/su When it crashes, get a backtrace (in gdb: `bt full' and post it here). Simon signature.asc Description: Digital signature
Re: Bus error
# set CFLAGS=$CFLAGS -g # make Arg! Please use # make CFLAGS='-O -g' instead. signature.asc Description: Digital signature
devfs.conf and bpf devices
Hello, I've appended lines in /etc/devfs.conf. permbpf00660 permbpf10660 permfd0 0660 But when bpf1 is created for tcpdumping tun0 (user-ppp) it gets the permissions 0600. Any ideas why this can be? Running -current from about a week ago. I noticed that /etc/default/rc.conf mentions this: grep devfs /etc/defaults/rc.conf devfs_rulesets=/etc/defaults/devfs.rules /etc/devfs.rules # Files containing # devfs(8) rules. devfs_system_ruleset= # The name of a ruleset to apply to /dev Should devfs.conf be renamed to devfs.rules? Greetings, Ronald. PS: Tell me if this should be asked on -questions first. -- Ronald Klop Amsterdam, The Netherlands ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Wed, 5 Nov 2003, John Baldwin wrote: JB JBOn 05-Nov-2003 Harti Brandt wrote: JB On Tue, 4 Nov 2003, John Baldwin wrote: JB JB JB JB JBOn 04-Nov-2003 Harti Brandt wrote: JB JB On Tue, 4 Nov 2003, Harti Brandt wrote: JB JB JB JB HBOn Tue, 4 Nov 2003, John Baldwin wrote: JB JB HB JB JB HBJB JB JB HBJBOn 04-Nov-2003 Harti Brandt wrote: JB JB HBJB JB JB HBJB Hi, JB JB HBJB JB JB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB JB HBJB worked until yesterday, but with the new interrupt code it doesn't boot JB JB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB JB HBJB fault. I suspect a race condition in the interrupt handling. My config JB JB HBJB file has JB JB HBJB JB JB HBJB options SMP JB JB HBJB device apic JB JB HBJB options HZ=1000 JB JB HBJB JB JB HBJBOk, I can try to reproduce. JB JB HBJB JB JB HBJB Device configuration finished. JB JB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 JB JB HBJB Timecounters cpuid = 0; apic id = 00 JB JB HBJB instruction pointer = 0x8:0xc048995d JB JB HBJB stack pointer = 0x10:0xc0821bf4 JB JB HBJB frame pointercpuid = 0; apic id = 00 JB JB HBJB JB JB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from JB JB HBJB cpu_critical_exit. JB JB HBJB JB JB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. JB JB HBJBIt might be helpful to figure what type of fault you are actually getting. JB JB HB JB JB HBtf_err is 0, tf_trapno is 30 (decimal). JB JB JB JB More information: JB JB JB JB I have replaced all the reserved vectors with individual ones, that set JB JB tf_err to the index (vector number). It appears the the vector number is JB JB 39 decimal. What does that mean? JB JB JB JBIRQ 7. JB JBCan you post a verbose dmesg? Also, can you try both with and without JB JBACPI? JB JB Attached are both dmesgs. JB JB More datapoints: JB JB I had the parallel port (irq7) and the second sio disabled in the BIOS. JB After enabling both I now get a panic in lapic_handle_intr: Couldn't get JB vector from ISR! After fetching the relevant docs from intel I checked the JB registers of the apic pointed to by lapic. The interrupt taken is JB Xapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How JB may that happen? As I understand ISR are the interrupts that have been JB delivered to the CPU so if it is interrupted a bit should be set, correct? JB JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Thanks, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compaq Proliant 2500 - freebsd 5.1 install problems
I`m trying to get FreeBSD 5.1 installed, but sysinstall never shows. The last info I get is /stand/sysinstall running as init on vty0 and it stops. It dont do anything more. FreeBSD 4.8(and 4.9 i guess, havent tried yet) works. Any sollution? Btw, I have set the OS to be 'Other' in BIOS. -- Med vennlig hilsen / Best regards Christer Solskogen http://dtz.cjb.net - http://carebears.mine.nu Cheap, but not as cheap as your girlfriend! -Spider Jerusalem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new interrupts not working for me
On 06-Nov-2003 Peter Schultz wrote: John Baldwin wrote: On 05-Nov-2003 Peter Schultz wrote: I have a Tyan S1832DL w/dual pii 350s and it's not able to boot. Seems to be having trouble with my adaptec scsi controller, I get a whole bunch of output like this hand transcribed bit, it comes after waiting 15 seconds for scsi devices to settle: ahc0 timeout SCB already complete interrupts may not be functioning Infinite interrupt loop INTSTAT=0(probe3:ahc0:0:3:0): SCB 0x6 - timed out Anyone else seeing this? There are probably 100+ related lines of output, I'll have to configure serial debugging if you need to see it. The dmesg output excluding all the ahc0 errors would help figure out why your interrupts aren't working. However, I just committed a patch that might fix your problem. Now the kernel just dies and the machine reboots right in the beginning when it's setting up the ACPI/APIC stuff. Of course, with ACPI off, there's no apparent problem with the kernel. Ok. Did the old kernel break before with ACPI turned off? It should have. By the way, I've committed a fix for the ACPI breakage. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
g++ problem
I tried to compile a virus-scanner for Linux that allows for scanning Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and such). http://www.enyo.de/fw/software/doscan Compilation fails with the following: kukuboo2k# gmake g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ -MMD -MF src/doscan.d \ -c -o src/doscan.o src/doscan.cc In file included from src/doscan.cc:28: /usr/local/include/getopt.h:115: error: declaration of C function `int getopt() ' conflicts with /usr/include/unistd.h:377: error: previous declaration `int getopt(int, char* const*, const char*)' here gmake: *** [src/doscan.o] Error 1 I wonder where /usr/local/include comes from. If I remove that it compiles smoothly. Sorry, if this would turn out to be not -current specific. -- Chris Christoph P. U. 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]
Kernel memory leak in ATAPI/CAM or ATAng?
I have learned a bit more about the problems I have been having with the DVD drive on my T30 laptop. When I have run the drive for an extended time (like 2 or 3 hours), I invariably have my system lock up because it can't malloc kernel memory for the ATAPI/CAM or ATA device. (Usually it's both.) The only recovery seems to be to reboot the system. I suspect a memory leak because it seems to be linked to total amount of data transferred, even in multiple invocations of the program. Of course, once the kernel grabs VM, I guess it generally does not actually release it, but it should re-use the existing allocation and not keep allocating more. I posted my config and dmesg files yesterday. I have tried tuning KVM_SIZE stuff with no real success, just the loss of the ability to run with APM loaded. (This is possibly due to mis-tuning.) Any ideas on where I can look for more information? I'm going to try doing some monitoring with vmstat while running to see if I can spot anything, but I am not sure just what I am looking for. The VM system is not something I know much about, but I did read Terry Lambert's excellent message to current on KVM tuning and I'm hoping that this might help, but, if there really is a memory leak, tuning will not fix it. FWIW, this problem did not exist a few month ago prior to ATAng. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel memory leak in ATAPI/CAM or ATAng?
On Thu, 6 Nov 2003, Kevin Oberman wrote: I have learned a bit more about the problems I have been having with the DVD drive on my T30 laptop. When I have run the drive for an extended time (like 2 or 3 hours), I invariably have my system lock up because it can't malloc kernel memory for the ATAPI/CAM or ATA device. (Usually it's both.) The only recovery seems to be to reboot the system. Is it possible to drop to DDB and generate a coredump at that point? If so, you can run vmstat on the core to look at memory use statistics in a post-mortem way. As to what to look for: big numbers is about the limit of what I can suggest, I'm afraid :-). Usually the activity of choice is to compare vmstat statistics (with -m and -z) during normal operation and when the leak has occurred, and look for any marked differences. It's worth observing that there are two failure modes here that appear almost identical: (1) a memory leak resulting in address space exhaustion for the kernel, and (2) a tunable maximum allocation being too high for the available address space. Note that (2) isn't a leak, simply a poorly tuned value. We've noticed a number of tuned memory limits were set when memory sizes on systems were much lower, and so we've had to readjust the tuning parameters for large memory systems. Likewise, a number of problems were observed when PAE was introduced, as some of the tuning parameters scaled with the amount of physical memory, not with the addressable space for the kernel. So we probably want to be on the look out for both of these possibilities. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drm, irqs, etc.
On 06-Nov-2003 Eric Anholt wrote: On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote: first, i apologize... i didn't think i'd get real answers on -questions so i'm posting this here. i realize 5.x isn't really stable yet, but i hope it's close enough to be relevant. ;) i've got XFree86 4.3.0 installed, from the X-4 meta port. that went smoothly. using the mga driver with a matrox g450 (dual head). no dri on head 2 as expected, but again no obvious problems. what i've noticed (this is 5.1-p8) is that after X has been running for awhile, trying to exit X causes a hang. at first i thought it was some program under X not exiting properly (that's what it looks like), but i've reproduced the same behavior with nothing but X running. if i start X and then exit immediately, everything is fine. this seems to only happen after X runs for a week or more. the one thing i noticed, was some interesting behavior wrt drm and it's claimed IRQ. before starting X (after a reboot), `ps ax|grep irq` shows: 19 ?? WL 0:00.00 (irq9: pcm0 acpi0) 20 ?? WL 0:00.10 (irq14: ata0) 21 ?? WL 0:00.00 (irq15: ata1) 22 ?? WL 0:00.00 (irq10: fxp0) 23 ?? WL 0:00.00 (irq6: fdc0) 24 ?? WL 0:00.01 (irq1: atkbd0) the same from within X shows, 19 ?? WL 0:00.00 (irq9: pcm0 acpi0) 20 ?? WL 0:01.05 (irq14: ata0) 21 ?? WL 0:00.00 (irq15: ata1) 22 ?? WL 0:00.02 (irq10: fxp0) 23 ?? WL 0:00.00 (irq6: fdc0) 24 ?? WL 0:00.08 (irq1: atkbd0) 25 ?? WL 0:00.09 (irq12: psm0) 690 ?? WL 0:00.12 (irq11: drm0) and once exiting X (immediately, when it exits without hanging), 19 ?? WL 0:00.00 (irq9: pcm0 acpi0) 20 ?? WL 0:01.04 (irq14: ata0) 21 ?? WL 0:00.00 (irq15: ata1) 22 ?? WL 0:00.02 (irq10: fxp0) 23 ?? WL 0:00.00 (irq6: fdc0) 24 ?? WL 0:00.07 (irq1: atkbd0) 25 ?? WL 0:00.06 (irq12: psm0) 690 ?? WL 0:00.08 (irq11:) is irq11 not being freed? or is that normal behavior? i've double checked by X config, but i may have something wrong. i've read various web pages and XFree's suggestions about configuring the g450... but, again, i may have overlooked something. This is correct. Current currently doesn't try to destroy ithreads when they lose all their handlers. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: yppasswd fails on 5.1 box
hi, Yppasswd fails on my 5.1 box (has always worked on 4.5 to 5.0) with yppasswd: pam_chauthtok(): error in service module 5.1 Release or 5.1 CURRENT ? I've fixed several errors since 5.1R so it should work now in CURRENT. There's also a syslog message: Nov 4 22:54:54 *** yppasswd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: ***: RPC: Program not registered Yet rpcinfo -p shows: 191 udp821 yppasswdd 191 tcp 1010 yppasswdd You are missing the following entry (just use rpcinfo without -p) 19 1 local /var/run/ypasswdd.sock Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, 6 Nov 2003 16:55:00 +0100 (CET) C. Kukulies [EMAIL PROTECTED] wrote: I tried to compile a virus-scanner for Linux that allows for scanning Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and such). http://www.enyo.de/fw/software/doscan Compilation fails with the following: kukuboo2k# gmake g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ -MMD -MF src/doscan.d \ -c -o src/doscan.o src/doscan.cc In file included from src/doscan.cc:28: /usr/local/include/getopt.h:115: error: declaration of C function `int getopt() ' conflicts with /usr/include/unistd.h:377: error: previous declaration `int getopt(int, char* const*, const char*)' here gmake: *** [src/doscan.o] Error 1 I wonder where /usr/local/include comes from. If I remove that it compiles smoothly. Uhm, from you command line? What _this_ has to do with a compiler? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: APIC-UP related panic
On 06-Nov-2003 Harald Schmalzbauer wrote: Hello, I have one reproducable panic with sources from 04. Nov when enabling device apic in the kernel. While building OpenOffice about 1 1/2 hours after start the system reboots. This is absolutely reproducable. Removing device apic from the kernel solves the problem! The only thing I have are these lines from /var/log/messages: (attached the different dmesgs) Nov 5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d Nov 5 13:41:40 cale kernel: stack pointer = 0x10:0xcdc9dbe0 Nov 5 13:41:40 cale kernel: frame pointer = 0x10:0xcdc9dbe4 Nov 5 13:41:40 cale kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1 Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap Nov 5 13:41:40 cale kernel: Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 5 13:41:40 cale kernel: giving up on 1022 buffers Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s Nov 5 13:41:40 cale kernel: Shutting down ACPI Nov 5 13:41:40 cale kernel: stray irq9 Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 13:41:40 cale kernel: Rebooting... Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: current panics
On 06-Nov-2003 Kirill Ponomarew wrote: Hi, I got panic during the boot: ioapic0: Changing APIC ID to 2 ioapic0 Version 0.3 irqs 0-23 on motherboard panic: Can't find ExtINT pin to route through! cpuid=0; Is it known problem ? No, can you provide a boot -v dmesg? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: current panics
Hi, On Thu, Nov 06, 2003 at 11:34:06AM -0500, John Baldwin wrote: Is it known problem ? No, can you provide a boot -v dmesg? You fixed it by your last commit of src/sys/i386/acpica/madt.c,v 1.4 No panic now ;-) -Kirill pgp0.pgp Description: PGP signature
Re: g++ problem
On Thu, Nov 06, 2003 at 11:28:28AM -0500, Alexander Kabaev wrote: On Thu, 6 Nov 2003 16:55:00 +0100 (CET) C. Kukulies [EMAIL PROTECTED] wrote: I tried to compile a virus-scanner for Linux that allows for scanning Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and such). http://www.enyo.de/fw/software/doscan Compilation fails with the following: kukuboo2k# gmake g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ -MMD -MF src/doscan.d \ -c -o src/doscan.o src/doscan.cc In file included from src/doscan.cc:28: /usr/local/include/getopt.h:115: error: declaration of C function `int getopt() ' conflicts with /usr/include/unistd.h:377: error: previous declaration `int getopt(int, char* const*, const char*)' here gmake: *** [src/doscan.o] Error 1 I wonder where /usr/local/include comes from. If I remove that it compiles smoothly. Uhm, from you command line? What _this_ has to do with a compiler? This happens with g++ 3.x when the devel/libgnugetopt port is installed and both its getopt.h and the base unistd.h are included. There are several ports that have workarounds for this issue. I have a patch for devel/libgnugetopt at ftp://ftp.zeist.de/pub/patches/devel_libgnugetopt.diff that should fix this issue by updating to the latest sources. In my opinion the right thing to do is however to also include getopt_long_only() in libc and not only getopt_long() so one can get rid of the devel/libgnugetopt port. I have a patch for this at ftp://ftp.zeist.de/pub/patches/src_getopt_long_only.diff When I have time I'll continue testing of both and eventually submit PRs. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, 6 Nov 2003 17:44:59 +0100 Marius Strobl [EMAIL PROTECTED] wrote: This happens with g++ 3.x ... This will happen with g++ 3.x, 2.x, 1.x and future 4.x too. I.e. the GCC is not at fault and the subject of the original message is misleading. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Random reboots on -CURRENT of 20031105
Hi all, Last night I cvsup-ed to -CURRENT and built world and kernel. Today this machine rebooted alot by itself, with absolutely no load on it whatsoever. I dont know how to determine what is causing the reboots, so if anyone can give me a hint, it would be greatly appreciated. This machine acts as a router/firewall. I know that this is not a hardware problem, seeing that for the last few months this machine was running pretty much stable under heavy load (building test kernels, compiling source code, etc) with 5.1-RELEASE. /var/log/messages does not really say anything. :( Attached is my dmesg output and my kernel config. If you need any other info please drop me a mail. Thank you! dmesg: 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 #0: Thu Nov 6 01:13:55 SAST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL Preloaded elf kernel /boot/kernel/kernel at 0xc06cf000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,MMX,FXSR real memory = 134217728 (128 MB) avail memory = 124952576 (119 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fded0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:8 INTA BIOS irq 11 pci_cfgintr: 0:10 INTA BIOS irq 10 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 0:1 INTA routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C596 UDMA33 controller port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, USB at device 7.2 (no driver attached) pci0: bridge, HOST-PCI at device 7.3 (no driver attached) xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xe800-0xe87f mem 0xdf80-0xdf80007f irq 11 at device 8.0 on pci0 xl0: Ethernet address: 00:50:da:45:92:81 miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: multimedia, audio at device 10.0 (no driver attached) orm0: Option ROMs at iomem 0xc8000-0xc87ff,0xc-0xc7fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0501 can't assign resources (port) Timecounter TSC frequency 501140354 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 1000 packets/entry by default GEOM: create disk ad0 dp=0xc1c48370 ad0: 2014MB ST32122A [4092/16/63] at ata0-master UDMA33 acd0: CDROM CD-ROM 50X at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted uhci0: VIA 83C572 USB controller port 0xe400-0xe41f at device 7.2 on pci0 uhci0: Could not allocate irq device_probe_and_attach: uhci0 attach returned 6 uhci0: VIA 83C572 USB controller port 0xe400-0xe41f at device 7.2 on pci0 uhci0: Could not allocate irq device_probe_and_attach: uhci0 attach returned 6 uhci0: VIA 83C572 USB controller port 0xe400-0xe41f at device 7.2 on pci0 uhci0: Could not allocate irq device_probe_and_attach: uhci0 attach returned 6 Kernel Config: firewall% cat /usr/src/sys/i386/conf/FIREWALL machine i386 cpu I686_CPU ident FIREWALL maxusers0 options SCHED_4BSD #4BSD scheduler options INET#InterNETworking #optionsINET6 #IPv6
Re: new interrupts not working for me
John Baldwin wrote: On 06-Nov-2003 Peter Schultz wrote: John Baldwin wrote: On 05-Nov-2003 Peter Schultz wrote: I have a Tyan S1832DL w/dual pii 350s and it's not able to boot. Seems to be having trouble with my adaptec scsi controller, I get a whole bunch of output like this hand transcribed bit, it comes after waiting 15 seconds for scsi devices to settle: ahc0 timeout SCB already complete interrupts may not be functioning Infinite interrupt loop INTSTAT=0(probe3:ahc0:0:3:0): SCB 0x6 - timed out Anyone else seeing this? There are probably 100+ related lines of output, I'll have to configure serial debugging if you need to see it. The dmesg output excluding all the ahc0 errors would help figure out why your interrupts aren't working. However, I just committed a patch that might fix your problem. Now the kernel just dies and the machine reboots right in the beginning when it's setting up the ACPI/APIC stuff. Of course, with ACPI off, there's no apparent problem with the kernel. Ok. Did the old kernel break before with ACPI turned off? It should have. By the way, I've committed a fix for the ACPI breakage. The new interrupt kernels I've built have worked fine with ACPI off. The immediate crash is fixed, but now I'm back to the trouble with my SCSI controller. I'll try to get the output from that to you. Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, 6 Nov 2003, Marius Strobl wrote: MSOn Thu, Nov 06, 2003 at 11:28:28AM -0500, Alexander Kabaev wrote: MS On Thu, 6 Nov 2003 16:55:00 +0100 (CET) MS C. Kukulies [EMAIL PROTECTED] wrote: MS MS I tried to compile a virus-scanner for Linux that allows for scanning MS Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and MS such). MS MS http://www.enyo.de/fw/software/doscan MS MS Compilation fails with the following: MS MS kukuboo2k# gmake MS g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ MS -MMD -MF src/doscan.d \ MS -c -o src/doscan.o src/doscan.cc MS In file included from src/doscan.cc:28: MS /usr/local/include/getopt.h:115: error: declaration of C function `int MS getopt() MS ' conflicts with MS /usr/include/unistd.h:377: error: previous declaration `int MS getopt(int, char* MS const*, const char*)' here MS gmake: *** [src/doscan.o] Error 1 MS MS I wonder where /usr/local/include comes from. If I remove that it MS compiles smoothly. MS MS Uhm, from you command line? What _this_ has to do with a compiler? MS MS MSThis happens with g++ 3.x when the devel/libgnugetopt port is installed MSand both its getopt.h and the base unistd.h are included. There are MSseveral ports that have workarounds for this issue. MSI have a patch for devel/libgnugetopt at MSftp://ftp.zeist.de/pub/patches/devel_libgnugetopt.diff MSthat should fix this issue by updating to the latest sources. MSIn my opinion the right thing to do is however to also include MSgetopt_long_only() in libc and not only getopt_long() so one can get MSrid of the devel/libgnugetopt port. I have a patch for this at MSftp://ftp.zeist.de/pub/patches/src_getopt_long_only.diff MSWhen I have time I'll continue testing of both and eventually submit MSPRs. getopt.h is broken. It should not define a Posix reserved name or the application should not use any of the interfaces in unistd.h. You cannot have both. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, Nov 06, 2003 at 11:51:12AM -0500, Alexander Kabaev wrote: On Thu, 6 Nov 2003 17:44:59 +0100 Marius Strobl [EMAIL PROTECTED] wrote: This happens with g++ 3.x ... This will happen with g++ 3.x, 2.x, 1.x and future 4.x too. I.e. the GCC is not at fault and the subject of the original message is misleading. It's at least not fatal with g++ 2.95.4 on 4-stable, that's what I meant. But yes, GCC is not at fault. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 06-Nov-2003 Harti Brandt wrote: JBI figured out what is happenning I think. You are getting a spurious JBinterrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register JBlists pending interrupts still waiting to be serviced. Try using JB'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if JBthe spurious IRQ 7 interrupts go away. Ok, that seems to help. Interesting although why do these interrupts happen only with a larger HZ and when the kernel is doing printfs (this machine has a serial console). I have also not tried to disable SIO2 and the parallel port. Can you also try turning mixed mode back on and using http://www.FreeBSD.org/~jhb/patches/spurious.patch You should get some stray IRQ 7's in the vmstat -i output as well as a few printf's to the kernel console. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Trouble booting a SMP kernel
I need a little help diagnosing a problem booting a 5.1-RELEASE SMP kernel. The GENERIC kernel boots just fine. When I boot a GENERIC kernel with SMP enabled the boot fails early in the boot process. The text from the console is below: Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 AP #1 (PHY #1) failed! panic y/n? [y] n snip APIC_IO: Testing 8254 interrupt delivery [system is locks up at this point, no more messages] Also fails to boot a FreeBSD 4.4 SMP kernel, which leads me to beleive it's a hardware problem. Is this indicative of a failed processor or is it the motherboard? Hardware is a Tyan Thunder LE-T, BIOS v1.06, Dual Pentium III 1133 MHz, 2GB RAM. Any advise on diagnosing the problem is greatly appreciated. -- Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble booting a SMP kernel
On Thu, Nov 06, 2003 at 09:53:58AM -0800, Scott R. Sewall wrote: I need a little help diagnosing a problem booting a 5.1-RELEASE SMP kernel. The GENERIC kernel boots just fine. When I boot a GENERIC kernel with SMP enabled the boot fails early in the boot process. The text from the console is below: Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 AP #1 (PHY #1) failed! panic y/n? [y] n snip APIC_IO: Testing 8254 interrupt delivery [system is locks up at this point, no more messages] Also fails to boot a FreeBSD 4.4 SMP kernel, which leads me to beleive it's a hardware problem. Is this indicative of a failed processor or is it the motherboard? Hardware is a Tyan Thunder LE-T, BIOS v1.06, Dual Pentium III 1133 MHz, 2GB RAM. Any advise on diagnosing the problem is greatly appreciated. -- Scott No advice, but I experienced this exact problem last night. I'm running a Tyan Tiger LE motherboard, 2x PIII 733, 512M RAM and various other bits. It hangs in the exact same spot as yours does, which isn't surprising considering both motherboards use essentially the same chipset. This machine has ran with 4.x in the past, as well as an older 5-CURRENT, but I don't have timeframes for either. I'm fairly certain it's not a hardware problem. Google turns up a few other people with the same problem, so I don't think we're alone. I was going to fire off an e-mail to the lists today, but figured it would be best just to chime in with a me too since you've already got one in. Thanks, Josh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: yppasswd fails on 5.1 box
On Thu, 2003-11-06 at 17:27, Martin Blapp wrote: hi, Yppasswd fails on my 5.1 box (has always worked on 4.5 to 5.0) with yppasswd: pam_chauthtok(): error in service module 5.1 Release or 5.1 CURRENT ? I've fixed several errors since 5.1R so it should work now in CURRENT. I'm on 5.1-RELEASE I still need to upgrade, I have the sources via cvsup, but it will be my first build/installworld ... There's also a syslog message: Nov 4 22:54:54 *** yppasswd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: ***: RPC: Program not registered Yet rpcinfo -p shows: 191 udp821 yppasswdd 191 tcp 1010 yppasswdd You are missing the following entry (just use rpcinfo without -p) 191 local /var/run/ypasswdd.sock I don't have that one, it does show: 600191local /var/run/yppasswdsock - unknown Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- -- __ Guy Van Sanden http://unixmafia.port5.com Registered Linux user #249404 - September 1997 __ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed behaving badly?
walt [EMAIL PROTECTED] writes: I got this nonsensical error from sed while trying to update python: /usr/bin/sed -i.bak -e 's,/usr/doc/python-docs-,/usr/local/share/doc/python,g' /usr/ports/lang/python/work/Python-2.3.2/Lib/pydoc.py sed: /usr/ports/lang/python/work/Python-2.3.2/Lib/pydoc.py: No such file or directory But the file DOES exist, and furthermore the same port compiles just fine on -CURRENT from November 1. I think the recent changes to sed may have broken something, but I don't know how, exactly. I introduced a bug a couple of days ago, and fixed it a few hours later. Just update and rebuild sed. 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]
savecore changed?
Hi all, I have a -CURRENT kernel that panics the moment it starts booting, and I have to use another kernel to boot properly (GENERIC). The problem is that I want to dump the core from the faulty kernel, and I see that savecore no longer support a -N flag like in 4.X? How do I save the core in -CURRENT from a different kernel? UPDATING does not mention any change in savecore. :( Any help appreciated. Thank you Jaco van Tonder Magic Developer :: Premsoft Development (Pty) Ltd Direct: +27 11 312 2122 :: Fax: +27 11 312 2122 :: Mobile: +27 83 417 5424 Email: [EMAIL PROTECTED] :: Web: http://www.premsoft.co.za/ PGP: http://www.premsoft.co.za/jaco/jaco_premsoft.asc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ssh port forwarding changed under 5-CURRENT vs. STABLE?
I've searched the archives and perused manpages and config files yet can't figure out why this isn't working: - I'm trying to port forward from a remote machine to my laptop, something I did without a problem using 4-STABLE - If I do: ssh -v -N -4 -L8000:www.freebsd.org:80 myserver.net where myserver.net is a machine with Internet access, I could expect that connecting to 127.0.0.1 port 8000 on my laptop would port forward packets to/from www.freebsd.org:80 However, ssh seems to be having trouble binding to port 8000 locally (and I've tried port 5, 57000, 2000 and all behave similarly): debug1: Connections to local port 8000 forwarded to remote address www.freebsd.org:80 debug1: Local forwarding listening on 127.0.0.1 port 8000. bind: Can't assign requested address channel_setup_fwd_listener: cannot listen to port: 8000 Could not request local forwarding. and I can't see any reason why the binding would fail: hilbert[ttyp1]:aditya~ sysctl net.inet.ip.portrange.reservedlow net.inet.ip.portrange.reservedlow: 0 hilbert[ttyp1]:aditya~ sysctl net.inet.ip.portrange.reservedhigh net.inet.ip.portrange.reservedhigh: 1023 what am I missing? Thanks, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR
I've been getting a lot of this kind of error from my cdrom drive on a variety of disks recently: acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR sensekey=ILLEGAL REQUEST error=1ILLEGAL_LENGTH acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR sensekey=ILLEGAL REQUEST error=1ILLEGAL_LENGTH acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR sensekey=MEDIUM ERROR error=0 Is this a bug in the new atapi code or an indication of a hardware fault that's just developed? Joe p.s.: FreeBSD genius.tao.org.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #135: Tue Nov 4 02:01:14 GMT 2003 [EMAIL PROTECTED]:/stable/usr/obj/current/usr/src/sys/GENIUS i386 -- 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
Manual root filesystem specification - '?' - panic
Hi, '?' should show list of possible boot devices but this doesn't seem to work with a src update from around 20031105-2024 UTC: --- cut --- ... Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input mountroot ? panic: Root mount failed, startup aborted. syncing disks, buffers remaining... done Uptime: 1m23s Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. Rebooting... --- cut --- I tired multiple ties to ensure I only have a '?' as very first character and only entered ? enter via serial console. Any ideas ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: yppasswd fails on 5.1 box
Hi, I'm on 5.1-RELEASE I still need to upgrade, I have the sources via cvsup, but it will be my first build/installworld ... 5.1R is broken. You should upgrade :) Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
BOOTP endless loop if no root path given
Hi, when pxe-booting a kernel compiled with following options [ for the following log this had been a kernel from 20031030-1748 UTC including PR 57328 if it hadn't already been commited at that time ] options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFS_ROOT#NFS usable as /, requires NFSCLIENT options BOOTP # Use BOOTP to obtain IP address/hostname # Requires NFSCLIENT and NFS_ROOT options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info options BOOTP_NFSV3 # Use NFS v3 to NFS mount root options BOOTP_COMPAT# Workaround for broken bootp daemons. options BOOTP_WIRED_TO=fxp0 # Use interface fxp0 for BOOTP and a badly configured bootp(dhcp) server will result in endless(?) loop to get root path from bootp server: Sending DHCP Discover packet from interface fxp0 (xx:xx:xx:xx:xx:xx) Received DHCP Offer packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) Sending DHCP Request packet from interface fxp0 (xx:xx:xx:xx:xx:xx) Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (no root path) DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 ... another nn times ... DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 DHCP/BOOTP timeout for server 255.255.255.255 Received DHCP Ack packet on fxp0 from aa.bbb.cc.ddd (accepted) (got root path) fxp0 at aa.bb.ccc.dda server aa.bbb.cc.ddd server name aa.bbb.cc.ddd boot file path/boot/pxeboot subnet mask 255.255.255.224 router aa.bb.ccc.dda rootfs aa.bbb.cc.ddd:/path/tftp/pxetest hostname pxetest Questions: a) with such a setup would it be possible to tell the kernel to get rootfs from a local filesystem ? giving option root-path ufs:ad0s1a or s.th. like that will not work from what I have seen. b) shouldn't the above timeout somewhen and try to fall back to other possible rootfs'es or as a last escape reboot ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel I440GX+
On Thu, 2003-11-06 at 03:27, Tom wrote: On Thu, 6 Nov 2003, Scott Likens wrote: ... Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem before. I hope you are using P3s, or Xeon CPUs not P2s, since P2s are not able to cache memory above 512MB, which means that things will be real slow. No, Dual P2 Xeons. Thanks but no thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?
On Thu, Nov 06, 2003 at 01:43:43PM -0800, Aditya wrote: debug1: Connections to local port 8000 forwarded to remote address www.freebsd.org:80 debug1: Local forwarding listening on 127.0.0.1 port 8000. bind: Can't assign requested address channel_setup_fwd_listener: cannot listen to port: 8000 Could not request local forwarding. and I can't see any reason why the binding would fail: Is something else (e.g. another ssh session) already bound to that port? Kris pgp0.pgp Description: PGP signature
Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?
On Thu, Nov 06, 2003 at 03:29:21PM -0800, Kris Kennaway wrote: On Thu, Nov 06, 2003 at 01:43:43PM -0800, Aditya wrote: debug1: Connections to local port 8000 forwarded to remote address www.freebsd.org:80 debug1: Local forwarding listening on 127.0.0.1 port 8000. bind: Can't assign requested address channel_setup_fwd_listener: cannot listen to port: 8000 Could not request local forwarding. and I can't see any reason why the binding would fail: Is something else (e.g. another ssh session) already bound to that port? nope -- and I've tried all sorts of ports other than 8000 too: hilbert[ttyp1]:aditya~ netstat -an | grep -i LIST hilbert[ttyp1]:aditya~ hilbert[ttyp1]:aditya~ sockstat -4 USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS aditya ssh1289 3 tcp4 66.117.144.206:54376 66.117.144.211:22 root dhclient 1287 5 udp4 *:68 *:* Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Undelivered Mail Returned to Sender
Kris, it looks like Pacbell/Prodigy are rejecting mail sent to [EMAIL PROTECTED] that is forwarded by your gandi.net forwarding... Adi On Fri, Nov 07, 2003 at 12:31:51AM +0100, Mail Delivery System wrote: Content-Description: Notification This is the Postfix program at host glenlivet.gandi.net. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to postmaster If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program [EMAIL PROTECTED]: host pbimail3.prodigy.net[207.115.63.108] said: 553 5.3.0 DNSBL:To request removal of,[62.80.122.197],send and E-mail to [EMAIL PROTECTED] (in reply to MAIL FROM command) Content-Description: Delivery error report Reporting-MTA: dns; glenlivet.gandi.net Arrival-Date: Fri, 7 Nov 2003 00:31:50 +0100 (CET) Final-Recipient: rfc822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host pbimail3.prodigy.net[207.115.63.108] said: 553 5.3.0 DNSBL:To request removal of,[62.80.122.197],send and E-mail to [EMAIL PROTECTED] (in reply to MAIL FROM command) Content-Description: Undelivered Message Date: Thu, 6 Nov 2003 15:31:48 -0800 From: Aditya [EMAIL PROTECTED] To: Kris Kennaway [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ssh port forwarding changed under 5-CURRENT vs. STABLE? In-Reply-To: [EMAIL PROTECTED] On Thu, Nov 06, 2003 at 03:29:21PM -0800, Kris Kennaway wrote: On Thu, Nov 06, 2003 at 01:43:43PM -0800, Aditya wrote: debug1: Connections to local port 8000 forwarded to remote address www.freebsd.org:80 debug1: Local forwarding listening on 127.0.0.1 port 8000. bind: Can't assign requested address channel_setup_fwd_listener: cannot listen to port: 8000 Could not request local forwarding. and I can't see any reason why the binding would fail: Is something else (e.g. another ssh session) already bound to that port? nope -- and I've tried all sorts of ports other than 8000 too: hilbert[ttyp1]:aditya~ netstat -an | grep -i LIST hilbert[ttyp1]:aditya~ hilbert[ttyp1]:aditya~ sockstat -4 USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS aditya ssh1289 3 tcp4 66.117.144.206:54376 66.117.144.211:22 root dhclient 1287 5 udp4 *:68 *:* Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel I440GX+
Scott Likens wrote: On Thu, 2003-11-06 at 03:27, Tom wrote: On Thu, 6 Nov 2003, Scott Likens wrote: ... Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem before. I hope you are using P3s, or Xeon CPUs not P2s, since P2s are not able to cache memory above 512MB, which means that things will be real slow. No, Dual P2 Xeons. Hmmm ? Are you sure ? I own an L440GX+ and Xeon's do not fit on it. You might have either an MS440GX or a C440GX, the former being a workstation board (with AGP), the later an entry level server board if there are PII Xeon CPU's on it. Regards Roberto ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel memory leak in ATAPI/CAM or ATAng?
Date: Thu, 6 Nov 2003 11:23:30 -0500 (EST) From: Robert Watson [EMAIL PROTECTED] On Thu, 6 Nov 2003, Kevin Oberman wrote: I have learned a bit more about the problems I have been having with the DVD drive on my T30 laptop. When I have run the drive for an extended time (like 2 or 3 hours), I invariably have my system lock up because it can't malloc kernel memory for the ATAPI/CAM or ATA device. (Usually it's both.) The only recovery seems to be to reboot the system. Is it possible to drop to DDB and generate a coredump at that point? If so, you can run vmstat on the core to look at memory use statistics in a post-mortem way. As to what to look for: big numbers is about the limit of what I can suggest, I'm afraid :-). Usually the activity of choice is to compare vmstat statistics (with -m and -z) during normal operation and when the leak has occurred, and look for any marked differences. It's worth observing that there are two failure modes here that appear almost identical: (1) a memory leak resulting in address space exhaustion for the kernel, and (2) a tunable maximum allocation being too high for the available address space. Note that (2) isn't a leak, simply a poorly tuned value. We've noticed a number of tuned memory limits were set when memory sizes on systems were much lower, and so we've had to readjust the tuning parameters for large memory systems. Likewise, a number of problems were observed when PAE was introduced, as some of the tuning parameters scaled with the amount of physical memory, not with the addressable space for the kernel. So we probably want to be on the look out for both of these possibilities. Well, I have no details to this point, but 'vmstat -m' makes the problem obvious. The amount of kernel memory allocated to ATA request climbs forever and after enough data is transferred, it runs out of KVM. This is a continual leak, and monitoring it on the running system makes it pretty clear that something is leaking. I don't think (2) is the issue. Because the field allocated in vmstat are not large enough, this is a bit hard to read. The field all merge into some REALLY large numbers. After reboot, it is 5K. When running mencode I see this increasing at a rate of a bit under 1.9 MB per minute. It does not look like a tuning issue. No matter how big KVM is allowed to grow, it's only a matter of time until it is gone. I am going to do some testing to see what operations seem to causse this. I assume it does not happen all of the time or everyone would have seen it. I suspect it only happens with ATAPI/CAM activity, possibly only with simultaneous ATA and ATAPI/COM activity. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make install fails on 11.pm cst current cvs..
I cvsup at 11 pm CST. It compiles fine however make installworld fails with: #make installworld mkdir -p /tmp/install.M8ngJOCi for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep l n make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic; do cp `which $prog` /tmp/install.M8ngJOCi; done cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE = GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj /usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386 /legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/ src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/ i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/tmp /install.M8ngJOCi make -f Makefile.inc1 reinstall -- Making hierarchy -- cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc;make distrib-dirs mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /var mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p / cd /; rm -f /sys; ln -s usr/src/sys sys cd /usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /usr/share/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done cd /usr/share/openssl/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; wh ile [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done cd /usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* . cd /usr/share/nls; set - `grep ^[a-zA-Z] /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done -- Installing everything.. -- cd /usr/src; make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh touch: not found *** Error code 127 Stop in /usr/src/include. *** 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. Thanks in adv. system i386 athlon -- Neal Hamilton Jr. [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: savecore changed?
On Thu, 6 Nov 2003, Jaco H. van Tonder wrote: Hi all, I have a -CURRENT kernel that panics the moment it starts booting, and I have to use another kernel to boot properly (GENERIC). The problem is that I want to dump the core from the faulty kernel, and I see that savecore no longer support a -N flag like in 4.X? How do I save the core in -CURRENT from a different kernel? UPDATING does not mention any change in savecore. :( savecore won't recover the old kernel? Can't say I've ever had that problem. Can you show error messages? -CURRENT savecore no longer grabs kernel.0, so it shouldn't matter what the running kernel is. -- 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]
Fwd: make install fails on 11.pm cst current cvs..
sorry it was 11 am. On Thu, 06 Nov 2003 17:00:04 -0800, Neal Hamilton Jr. [EMAIL PROTECTED] said: I cvsup at 11 pm CST. It compiles fine however make installworld fails with: #make installworld mkdir -p /tmp/install.M8ngJOCi for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep l n make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic; do cp `which $prog` /tmp/install.M8ngJOCi; done cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE = GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj /usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386 /legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/ src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/ i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/tmp /install.M8ngJOCi make -f Makefile.inc1 reinstall -- Making hierarchy -- cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc;make distrib-dirs mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p / mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /var mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p / cd /; rm -f /sys; ln -s usr/src/sys sys cd /usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /usr/share/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done cd /usr/share/openssl/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; wh ile [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done cd /usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* . cd /usr/share/nls; set - `grep ^[a-zA-Z] /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done -- Installing everything.. -- cd /usr/src; make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh touch: not found *** Error code 127 Stop in /usr/src/include. *** 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. Thanks in adv. system i386 athlon -- Neal Hamilton Jr. [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail... -- Neal Hamilton Jr. [EMAIL PROTECTED] -- http://www.fastmail.fm - Access your email from home and the web ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Morten Johansen wrote: Scott Long wrote: One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). Scott I can reproduce the problem consistently on my machine, by moving the mouse around, while executing e.g this command in a xterm: dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync when the sync'ing sets in the mouse attacks. It is very likely due to interrupt latency. I'd be happy to test any clever patches. Morten Wow. You are completly right! By using a MTX_SPIN mutex instead, and marking the interrupt handler INTR_MPSAFE | INTR_FAST, my problem goes away. I am no longer able to reproduce the mouse attack. I have not noticed any side-effects of this. Could there be any? I will file a PR with an updated patch, unless you think it's a better idea to rearrange the driver. Probably the locking could be done better anyway. Morten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APIC-UP related panic
On Thursday 06 November 2003 17:33, John Baldwin wrote: On 06-Nov-2003 Harald Schmalzbauer wrote: *SCHNIP* Nov 5 13:41:40 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 13:41:40 cale kernel: trap number= 30 Nov 5 13:41:40 cale kernel: panic: unknown/reserved trap Nov 5 13:41:40 cale kernel: Nov 5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 Nov 5 13:41:40 cale kernel: giving up on 1022 buffers Nov 5 13:41:40 cale kernel: Uptime: 1h38m28s Nov 5 13:41:40 cale kernel: Shutting down ACPI Nov 5 13:41:40 cale kernel: stray irq9 Nov 5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 13:41:40 cale kernel: Rebooting... Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch It's my pleasure to do so, but these days I have to move some furniture to pay my rent. Expect feedback at ~Sat., 15.00 UTC. I hope so. Thanks a lot, -Harry pgp0.pgp Description: signature
HEADSUP: GCC 3.3.3 snapshot is coming.
Hello all, in preparation for coming code freeze I am going to import a GCC 3.3.3 post-release snapshot. This is supposed to be a minor update with no major functionality or code changes, but it does contain some fixes our sparc64 and amd64 users would like to have prior 5.2-release ships. Unortunately, some of these fixes did not make into GCC 3.3.3-release, hence the snapshot. This will take about two hours, please hold your updates until an 'all clear' message is posted here. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: GCC 3.3.3 snapshot is coming.
On Thu, Nov 06, 2003 at 06:19:40PM -0800, Alexander Kabaev wrote: This will take about two hours, please hold your updates until an 'all clear' message is posted here. Done. ___ [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-11-07 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-07 05:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-07 05: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-11-07 05:02:21 - 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 [...] from /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/cc_tools/hconfig.h:2, from /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/cp/decl.c:33: /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/config/alpha/freebsd.h:81:1: warning: this is the location of the previous definition /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/cp/decl.c: In function `find_binding': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/cp/decl.c:2373: warning: return makes pointer from integer without a cast /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/cp/decl.c: In function `grok_reference_init': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/cp/decl.c:7961: error: too few arguments to function `initialize_reference' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/cc1plus. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-11-07 05:07:58 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-07 05:07:58 - TB --- ERROR: failed to build world TB --- 2003-11-07 05:07:58 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel I440GX+
Roberto de Iriarte wrote: Scott Likens wrote: On Thu, 2003-11-06 at 03:27, Tom wrote: On Thu, 6 Nov 2003, Scott Likens wrote: ... Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem before. I hope you are using P3s, or Xeon CPUs not P2s, since P2s are not able to cache memory above 512MB, which means that things will be real slow. No, Dual P2 Xeons. Hmmm ? Are you sure ? I own an L440GX+ and Xeon's do not fit on it. You might have either an MS440GX or a C440GX, the former being a workstation board (with AGP), the later an entry level server board if there are PII Xeon CPU's on it. Only first PIIs had L2 cache which was unable to store data located beyond 512Mb memory boundary (233-300MHz, Klamath), and some of them even didn't support ECC for L2 cache. All the next PIIs (333-450MHz, Deschutes) had L2 cache with ECC, capable of all 4Gb. So PIIs are not so bad as some people may think. Besides, L2 cache of PIIXeons and some PIIIXeons (Drake Tanner) is slow because it is off-core, regardless of running at full core speed. --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- 2003-11-07 05:07:59 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-07 05:07:59 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-11-07 05:07:59 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-07 05:09:54 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/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 [...] cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/co! ntrib/gcc/cp/call.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/co! ntrib/gcc/cp/class.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/co! ntrib/gcc/cp/cvt.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/co! ntrib/gcc/cp/decl.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/cp/decl.c: In function `find_binding': /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/contrib/gcc/cp/decl.c:2373: warning: return
[current tinderbox] failure on i386/i386
TB --- 2003-11-07 05:15:59 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-07 05:15:59 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-07 05:15:59 - 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-11-07 05:17:58 - 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 [...] cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/call.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/class.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/cvt.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/decl.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/decl.c: In function `find_binding': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/decl.c:2373: warning: return makes pointer from integer without a cast /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/decl.c: In function `grok_reference_init': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/contrib/gcc/cp/decl.c:7961: error: too few
[current tinderbox] failure on i386/pc98
TB --- 2003-11-07 05:23:58 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-07 05:23:58 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-07 05:23:58 - 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-11-07 05:25:57 - 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 [...] cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/call.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/class.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/cvt.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr\ -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/decl.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/decl.c: In function `find_binding': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/decl.c:2373: warning: return makes pointer from integer without a cast /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/contrib/gcc/cp/decl.c: In function `grok_reference_init':
[current tinderbox] failure on ia64/ia64
TB --- 2003-11-07 05:31:58 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-07 05:31:58 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-07 05:31:58 - 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-11-07 05:33:55 - 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 [...] cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/call.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/class.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/cvt.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/decl.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/decl.c: In function `find_binding': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/decl.c:2373: warning: return makes pointer from integer without a cast /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gcc/cp/decl.c: In function
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-07 05:39:32 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-07 05:39:32 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-07 05:39:32 - 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-11-07 05:41:24 - 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 [...] cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sp! arc64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/cp/call.c cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sp! arc64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/cp/class.c cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sp! arc64/src/i386/legacy/usr/include -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gcc/cp/cvt.c cc -O -pipe -DTARGET_CPU_DEFAULT=TARGET_CPU_ultrasparc -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr\ -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I.
Re: 3C940 / Asus P4P800 gigabit LAN driver
:I just tried Jung-uk Kim's driver on -stable and sofar it works OK: : ... and I just ported it to DragonFly and it works fine there too with an ASUS K8V Motherboard. Kudos! -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel I440GX+
On Thu, 2003-11-06 at 21:09, RMH wrote: Roberto de Iriarte wrote: Scott Likens wrote: On Thu, 2003-11-06 at 03:27, Tom wrote: On Thu, 6 Nov 2003, Scott Likens wrote: ... Onboard SCSI, 1gig of ECC, dual P2-450's. Never had this problem before. I hope you are using P3s, or Xeon CPUs not P2s, since P2s are not able to cache memory above 512MB, which means that things will be real slow. No, Dual P2 Xeons. Hmmm ? Are you sure ? I own an L440GX+ and Xeon's do not fit on it. You might have either an MS440GX or a C440GX, the former being a workstation board (with AGP), the later an entry level server board if there are PII Xeon CPU's on it. Only first PIIs had L2 cache which was unable to store data located beyond 512Mb memory boundary (233-300MHz, Klamath), and some of them even didn't support ECC for L2 cache. All the next PIIs (333-450MHz, Deschutes) had L2 cache with ECC, capable of all 4Gb. So PIIs are not so bad as some people may think. Besides, L2 cache of PIIXeons and some PIIIXeons (Drake Tanner) is slow because it is off-core, regardless of running at full core speed. --- Regards, Rhett Also to note, that now the computer boots again with the madt.c 1.4.4 Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client mount options in CURRENT/5.1-
Scott W wrote: mount -tnfs -orw,rsize=8196,wsize=8196,bg,hard,intr,async sol:/export /mnt nfs: -o rsize=: option not supported Try -r 8196 -w 8196 and have a look at man mount_nfs. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client mount options in CURRENT/5.1-
Antoine Jacoutot wrote: Scott W wrote: mount -tnfs -orw,rsize=8196,wsize=8196,bg,hard,intr,async sol:/export /mnt nfs: -o rsize=: option not supported Try -r 8196 -w 8196 and have a look at man mount_nfs. Antoine Definite user error on my part, thanks. I couldn't find anything on hard vs soft mounts however- I'm assuming the default is hard, as there is only a soft (-s) option available on freeBSD? Thanks again, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
[please keep the [EMAIL PROTECTED] cc and excuse formatting -- webmail, and also the typos] Hi, The quick story: after a change of the MB from a GA-7VT600 1393 to a GA-7VT600-L, both with VIA Apollo KT600 / 8237 cipset, my system's preen fsck can't find the superblock on partitions other that / As far as I can say the fs where clean (note however that / was mounted read-only AFAIR). I've googled around half a day and the hole night with no luck. The system was first on a KT400/8235 mobo and i've moved it with no problem. What is different now ? It has been installed with the defaults newfs options. Questions: 1. in-core disklabel means what is read from the disk ? 2. The sizes are OK, the root slice is OK and I can use it, the first FAT32 XP partition is OK and I can boot XP, what makes the diference between / and the others ? 3. If the slightly different BIOS is to blame, how to make the newfs when installing so that I will not have this problem again in the future ? 4. Besides McKusick's paper from 44doc what other sources of information on ufs are there ? 5. And, of course :-/ , how to get my data back ? I can provide a dumpfs and/or ffsinfo, if someone cares to see them (btw, they still are in 5.1 ? as in the on-line man pages thy are not) #fsck -p /dev/ad0s2a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 89827 free (715 frags, 11139 blocks, 0.6% fragmentation) Cannot find file system superblock /dev/ad0s2e: CAN'T CHECK FILE SYSTEM. /dev/ad0s2e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s2e: CANNOT SEEK BLK: -1 /dev/ad0s2e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Cannot find file system superblock /dev/ad0s2f: CAN'T CHECK FILE SYSTEM. /dev/ad0s2f: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s2f: CANNOT SEEK BLK: -1 /dev/ad0s2f: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Cannot find file system superblock /dev/ad0s2d: CAN'T CHECK FILE SYSTEM. /dev/ad0s2d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Cannot find file system superblock /dev/ad0s2g: CAN'T CHECK FILE SYSTEM. /dev/ad0s2g: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s2g: CANNOT SEEK BLK: -1 /dev/ad0s2g: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. A fsck -t ufs ad0s2d gives: ** /dev/ad0s2d Cannot find file system superblock /dev/ad0s2d: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 1048576 and fsck_ffs -b 32 isn't of much help either. *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=232578 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=232578 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 63, size 61432497 (29996 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 61432560, size 173003985 (84474 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # /dev/ad0s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 52428804.2BSD0 0 0 b: 4194304 524288 swap c: 1730039850unused0 0 # raw part, don't edit d: 1048576 47185924.2BSD0 0 0 e: 1048576 57671684.2BSD0 0 0 f: 104857600 68157444.2BSD0 0 0 g: 61330641 1116733444.2BSD0 0 0 The BIOS - LBA reads 14593/255/63 and in dmesg, next to ad0 it is 232578/16/63. If I'm booting with the live CD I get: Offset Size(ST) End 0.63...1 63...6143249761432559 ad0s1 61462560..173003985.23443644ad0s2 234436545..2990234439543unused and the geometry 14593/255/63 Bellow is the tail of boot -v. ata0: pre reset mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ata0-master: ATA 01 a5 ata0: devices=01 ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1: pre reset mask=03 ostat0=50 ostat2=50 ata1-master: ATAPI 14 eb ata1-slave: ATAPI 00 00 ata1: after reset mask=03 stat0=00 stat1=50 ata1-slave: ATA 01 a5 ata1: devices=06 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd on isa0 pcic1: not probed (disabled)
fsck: CANNOT SEEK BLK: -1 (after changing the mainboard)
- Forwarded message from [EMAIL PROTECTED] - Date: Fri, 7 Nov 2003 08:28:23 +0200 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [please keep the [EMAIL PROTECTED] cc and excuse formatting -- webmail, and also the typos] Hi, The quick story: after a change of the MB from a GA-7VT600 1393 to a GA-7VT600-L, both with VIA Apollo KT600 / 8237 cipset, my system's preen fsck can't find the superblock on partitions other that / As far as I can say the fs where clean (note however that / was mounted read-only AFAIR). I've googled around half a day and the hole night with no luck. The system was first on a KT400/8235 mobo and i've moved it with no real problem. What is different now ? It has been installed with the defaults newfs options. Questions: 1. in-core disklabel means what is read from the disk ? 2. The sizes are OK, the root slice is OK and I can use it, the first FAT32 XP partition is OK and I can boot XP, what makes the diference between / and the others ? 3. If the slightly different BIOS is to blame, how to make the newfs when installing so that I will not have this problem again in the future ? 4. Besides McKusick's paper from 44doc what other sources of information on ufs are there ? 5. And, of course :-/ , how to get my data back ? I can provide a dumpfs and/or ffsinfo, if someone cares to see them (btw, they still are in 5.1 ? as in the on-line man pages thy are not) #fsck -p /dev/ad0s2a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 89827 free (715 frags, 11139 blocks, 0.6% fragmentation) Cannot find file system superblock /dev/ad0s2e: CAN'T CHECK FILE SYSTEM. /dev/ad0s2e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s2e: CANNOT SEEK BLK: -1 /dev/ad0s2e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Cannot find file system superblock /dev/ad0s2f: CAN'T CHECK FILE SYSTEM. /dev/ad0s2f: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s2f: CANNOT SEEK BLK: -1 /dev/ad0s2f: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Cannot find file system superblock /dev/ad0s2d: CAN'T CHECK FILE SYSTEM. /dev/ad0s2d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Cannot find file system superblock /dev/ad0s2g: CAN'T CHECK FILE SYSTEM. /dev/ad0s2g: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/ad0s2g: CANNOT SEEK BLK: -1 /dev/ad0s2g: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. A fsck -t ufs ad0s2d gives: ** /dev/ad0s2d Cannot find file system superblock /dev/ad0s2d: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 1048576 and fsck_ffs -b 32 isn't of much help either. *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=232578 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=232578 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 63, size 61432497 (29996 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 61432560, size 173003985 (84474 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # /dev/ad0s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 52428804.2BSD0 0 0 b: 4194304 524288 swap c: 1730039850unused0 0 # raw part, don't edit d: 1048576 47185924.2BSD0 0 0 e: 1048576 57671684.2BSD0 0 0 f: 104857600 68157444.2BSD0 0 0 g: 61330641 1116733444.2BSD0 0 0 The BIOS - LBA reads 14593/255/63 and in dmesg, next to ad0 it is 232578/16/63. If I'm booting with the live CD I get: Offset Size(ST) End 0.63...1 63...6143249761432559 ad0s1 61462560..173003985.23443644ad0s2 234436545..2990234439543unused and the geometry 14593/255/63 Bellow is the tail of boot -v. ata0: pre reset mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ata0-master: ATA 01 a5 ata0: devices=01 ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1: pre reset mask=03 ostat0=50 ostat2=50 ata1-master: ATAPI 14 eb ata1-slave: ATAPI 00 00 ata1: after reset mask=03 stat0=00 stat1=50 ata1-slave: ATA 01 a5 ata1: devices=06 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Silbersack wrote: | On Wed, 5 Nov 2003, [ISO-8859-1] Branko F. Grac(nar wrote: | | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |Mike Silbersack wrote: | || Can you try updating to 5.1-current and see if the situation changes at || all? A lot has changed since 5.1-release. If it's still broken in || 5.1-current, we can take a look into it. || || Thanks, | |I tried today with yesterday's -CURRENT. Same symptoms. No kernel panic, |just lockup. | |Brane | | | Ok, submit a PR with clear details on how to recreate the problem, and | we'll see if someone can take a look into it. I'm too busy to look at it, | but at least putting it in a PR will ensure that it doesn't get too lost. | Once the PR is filed, you might want to try asking on the freebsd-threads | list; it sounds like the issue might be thread-related. | | (Note that your original e-mail might contain enough detail, I'm not | certain; I just skimmed it. Filing a good PR is important either way, | mailing list messages get easily lost.) | Thanks. I already sent pr at 29.10.2003, which is identified by id 'kern/58677'. PR can be viewed at the following url address: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/58677 I think, that this really serious issue, concerning operating system stability. best regards, Brane -BEGIN PGP SIGNATURE- iD8DBQE/qjXifiC/E+t8hPcRAlUUAJ9PsqYXoh6lty2USRISPRyilOJIxwCcCyLr J//Y0OU7K0ODV4n99sMPfzE= =LByr -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
Branko F. Grac(nar wrote: Thanks. I already sent pr at 29.10.2003, which is identified by id 'kern/58677'. PR can be viewed at the following url address: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/58677 I think, that this really serious issue, concerning operating system stability. best regards, Brane Please tell us your Apache configuration, are you using prefork or worker or perchild mode ? If you are using worker mode, which thread library are you using ? this would help us to narrow down problem scope. --- David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
