Re: trap 12
Quoting John Baldwin j...@freebsd.org: On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote: Quoting John Baldwin j...@freebsd.org: On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: Quoting Ian J Hart ianjh...@ntlworld.com: Quoting Ian J Hart ianjh...@ntlworld.com: Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1 def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. [snip dmesg] It took 2 runs of portupgrade -af.Some corruption in the dbs may have to pkg_delete -a. FreeBSD * 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 *...@*:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xf570 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c429b stack pointer = 0x10:0x511e4710 frame pointer = 0x10:0x20 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 69996 (mkdir) trap number = 12 panic: page fault This one does look like a hardware issue from the stack trace. It's hard to know if the first panic you saw was a hardware issue as well without the stack trace information. #7 0x807b706e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0x807c429b in free_pv_entry (pmap=0x80b66c80, pv=Variable pv is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:1905 #9 0x807c4403 in pmap_remove_entry (pmap=Variable pmap is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:2131 #10 0x807c6447 in pmap_remove_pte (pmap=0x80b66c80, ptq=0xaaa8, va=18446744070506639360, ptepde=23601251, free=0x511e4790) at /usr/src/sys/amd64/amd64/pmap.c:2366 #11 0x807cab87 in pmap_remove (pmap=0x80b66c80, sva=18446744070506639360, eva=18446744070506909696) at /usr/src/sys/amd64/amd64/pmap.c:2510 -- John Baldwin The remote backup continues to run so there was definitely some issue there. No more reboots, but it wasn't doing that regularly without some additional load. Hopefully I can swap parts around until I find the offending item. Thanks for your input. I would try running memtest86 to check your RAM. -- John Baldwin It's ECC and was extensively tested when new so I suspect it's something else, but I'll memtest it overnight anyway. Sat at a panic when I went to put the floppy in.No debugger prompt and unresponsive so I power cycled it :( -- ian j hart This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: trap 12
Quoting John Baldwin j...@freebsd.org: On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: Quoting Ian J Hart ianjh...@ntlworld.com: Quoting Ian J Hart ianjh...@ntlworld.com: Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1 def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. [snip dmesg] It took 2 runs of portupgrade -af.Some corruption in the dbs may have to pkg_delete -a. FreeBSD * 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 *...@*:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xf570 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c429b stack pointer = 0x10:0x511e4710 frame pointer = 0x10:0x20 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 69996 (mkdir) trap number = 12 panic: page fault This one does look like a hardware issue from the stack trace. It's hard to know if the first panic you saw was a hardware issue as well without the stack trace information. #7 0x807b706e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0x807c429b in free_pv_entry (pmap=0x80b66c80, pv=Variable pv is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:1905 #9 0x807c4403 in pmap_remove_entry (pmap=Variable pmap is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:2131 #10 0x807c6447 in pmap_remove_pte (pmap=0x80b66c80, ptq=0xaaa8, va=18446744070506639360, ptepde=23601251, free=0x511e4790) at /usr/src/sys/amd64/amd64/pmap.c:2366 #11 0x807cab87 in pmap_remove (pmap=0x80b66c80, sva=18446744070506639360, eva=18446744070506909696) at /usr/src/sys/amd64/amd64/pmap.c:2510 -- John Baldwin The remote backup continues to run so there was definitely some issue there. No more reboots, but it wasn't doing that regularly without some additional load. Hopefully I can swap parts around until I find the offending item. Thanks for your input. -- ian j hart This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: trap 12
Quoting Ian J Hart ianjh...@ntlworld.com: Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1 def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. Some suggestions (off list) that it may not be hardware, so here's the follow up. supermicro 5015b-mt (super X7SBi mobo) Intel Q6600 8GB ECC DDR2 4x Seagate 320GB, two gmirror, two idle. issues so far 1 OK) 7.x doesn't boot without hw.ata.atapi_dma=0. Not recently tested. 2 OK) disks enumerate differently 6.x to 7.x. Painful if you hardwired the providor into your mirror. 3) 6.3 and 7.2 remote dump over ssh fails with 'Disconnecting: Corrupted MAC on input.' 4) On 7.2 (AFAICT from logs) random reboots under load. e.g. the above generated by a portupgrade run. I had dumpdev=none as I hadn't setup rc.early to allow savecore to work. In the interests of full disclosure I should say that this box was migrated from older hardware and then source upgraded from i386 to amd64 (6.3). Only one issue with that, format of accounting file.Upgrade to 7.2 and a rebuild or two since then. This box is our email server and there's no load. An identical box running as a gateway/firewall backup dumps okay and doesn't reboot. That box does drop network connections when running a cvsup server (treelist write), but when configured to pass through these connections (using balance) runs okay. But that's a story for another day as it's still on 6.x. Anyway, I put the two gmirror disks in another chassis and the remote dumps are now completing.This at least does seem to be hardware. Before I moved the two gmirror disks I synced a third disk. I can now test (most of) the original hardware and software. I was unable to make this single disk system crash, so I added two new disks and synced them.Now a 3 disk mirror, one disk idle. I've disabled sendmail and the email server so as not to clash. A portupgrade run caused a crash. I've setup coredumps so I can now test. Remote backup dumps do fail. xmail# kldstat Id Refs AddressSize Name 12 0x8010 bd23e0 kernel 21 0x80cd3000 20608geom_mirror.ko I did have ipfw module loaded, but I got the crash without it so I've removed it (firewall_type=OPEN). Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. dmesg after sig. Thanks -- ian j hart Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 munget...@hostname:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0x80cf5000. Preloaded elf obj module /boot/kernel/geom_mirror.ko at 0x80cf5220. Calibrating clock(s) ... i8254 clock: 1193168 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2394010944 Hz CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 8575127552 (8177 MB) Physical memory chunk(s): 0x1000 - 0x00098fff, 622592 bytes (152 pages) 0x00d27000 - 0xcfe6, 3474231296 bytes (848201 pages) 0x0001 - 0x00021f8b3fff, 4824186880 bytes (1177780 pages) avail memory = 8273580032 (7890 MB) ACPI APIC Table: PTLTD APIC INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE
Re: trap 12
Quoting Ian J Hart ianjh...@ntlworld.com: Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1 def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. [First attempt apparently went into a blackhole. Apologies in you get this twice.] Some suggestions (off list) that it may not be hardware, so here's the follow up. supermicro 5015b-mt (super X7SBi mobo) Intel Q6600 8GB ECC DDR2 4x Seagate 320GB, two gmirror, two idle. issues so far 1 OK) 7.x doesn't boot without hw.ata.atapi_dma=0. Not recently tested. 2 OK) disks enumerate differently 6.x to 7.x. Painful if you hardwired the providor into your mirror. 3) 6.3 and 7.2 remote dump over ssh fails with 'Disconnecting: Corrupted MAC on input.' 4) On 7.2 (AFAICT from logs) random reboots under load. e.g. the above generated by a portupgrade run. I had dumpdev=none as I hadn't setup rc.early to allow savecore to work. In the interests of full disclosure I should say that this box was migrated from older hardware and then source upgraded from i386 to amd64 (6.3). Only one issue with that, format of accounting file.Upgrade to 7.2 and a rebuild or two since then. This box is our email server and there's no load. An identical box running as a gateway/firewall backup dumps okay and doesn't reboot. That box does drop network connections when running a cvsup server (treelist write), but when configured to pass through these connections (using balance) runs okay. But that's a story for another day as it's still on 6.x. Anyway, I put the two gmirror disks in another chassis and the remote dumps are now completing.This at least does seem to be hardware. Before I moved the two gmirror disks I synced a third disk. I can now test (most of) the original hardware and software. I was unable to make this single disk system crash, so I added two new disks and synced them.Now a 3 disk mirror, one disk idle. I've disabled sendmail and the email server so as not to clash. A portupgrade run caused a crash. I've setup coredumps so I can now test. Remote backup dumps do fail. xmail# kldstat Id Refs AddressSize Name 12 0x8010 bd23e0 kernel 21 0x80cd3000 20608geom_mirror.ko I did have ipfw module loaded, but I got the crash without it so I've removed it (firewall_type=OPEN). Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 munget...@hostname:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0x80cf5000. Preloaded elf obj module /boot/kernel/geom_mirror.ko at 0x80cf5220. Calibrating clock(s) ... i8254 clock: 1193168 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2394010944 Hz CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 8575127552 (8177 MB) Physical memory chunk(s): 0x1000 - 0x00098fff, 622592 bytes (152 pages) 0x00d27000 - 0xcfe6, 3474231296 bytes (848201 pages) 0x0001 - 0x00021f8b3fff, 4824186880 bytes (1177780 pages) avail memory = 8273580032 (7890 MB) ACPI APIC Table: PTLTD APIC INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu
Re: What is /boot/kernel/*.symbols?
Quoting Patrick M. Hausen hau...@punkt.de: Hi! On Fri, Jul 03, 2009 at 05:05:08PM +0200, Dimitry Andric wrote: E.g. the debug stuff is put into the .symbols files. The kernel itself still contains the function and data names, though: Understood. Thanks. No, I don't want the kernel to be void of any information ;-) Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I just had an installworld fail due to this (/rescue). Given that many people will have chosen the default root size offered by sysinstall a different build default would seem prudent. In any case sysinstall needs to be updated (1GB?). Let's not put off new users anymore than we have to. -- ian j hart This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
trap 12
Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1 def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. -- ian j hart This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.1-R to RELENG_7 upgrade breaks re nic
On Tuesday 31 March 2009 04:52:54 Steve Wills wrote: Hi, On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: Hi, I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after booting, re0 works for only a short time, then gives re0: PHY read failed over and over. Does anyone have a suggestion on how to debug? I need more information for your hardware revision. Would you show me dmesg output and revision number of if_re.c? For the record, and if anyone else is having this issue, SVN rev 190587 fixes this. Thanks for taking care of it! Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org This seems to fix it for me too. At least I've had no messages for the last hour (usually 6-10/hour). Good work, now let's get this in 7.2. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Monday 09 March 2009 21:00:20 ian j hart wrote: On Monday 09 March 2009 06:08:41 Pyun YongHyeon wrote: On Sun, Mar 08, 2009 at 05:05:12PM +, ian j hart wrote: On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote: On Sat, Mar 07, 2009 at 05:17:57PM +, ian j hart wrote: On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote: On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote: On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x1800. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x9800 (8110SCe) while working chip seems to be 0x1800 (8110SCd) with 0xfc80. FYI... Now armed with the information, I made it work without reverting memory mapped I/O. :-) http://people.freebsd.org/~jkim/re/re.current2.diff http://people.freebsd.org/~jkim/re/re.stable2.diff I like the patch. Since only RTL8169 family uses mask 0xfc80 it would be even better we can limit checking scope for RTL8169SC by comparing PCI device id. I don't know what other side effect would happen if the mask 0xfc80 would be used on 8101/8168 controllers. If the patch works on RTL8169SC would you commit the patch? I'd like to see multiple commits separated by each enhancements as the patch contains several fixes which are not directly related with the issue. Where are we on this? I have a headless firewall box which is not happy with 7.1-RELEASE. I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read failed' errors, although the network did come up, which was an improvement. Is there a patch I can try? http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174proname =A D3RT LAN-G re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x re0: Ethernet address: 00:30:18:ae:1a:1b re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x re1: Ethernet address: 00:30:18:ae:1a:1c re1: [FILTER] re2: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0 re2: Chip rev. 0x1800 re2: MAC rev. 0x re2: Ethernet address: 00:30:18:ae:1a:1d re2: [FILTER] r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:12:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 Have you tried re(4) in HEAD? I had one report that re(4) in HEAD still does not fix the issue so I posted a possible workaround for that. Unfortunately he didn't report back so I don't know whether it was right workaround or not. If re(4) in HEAD does not fix the issue, would you try attached patch and let me know how it goes? Firstly IANAKH, my expertise in this area stops after make kernel. I updated /usr/src/sys/dev/re/if_re.c /usr/src/sys/pci/if_rlreg.h to HEAD And after updating to HEAD did you apply my patch? I still get PHY read failed with and without the patch. That's odd. Another user who has the same controller reports the fix fixed the issue. I also committed the patch to HEAD so would you give it spin again (without applying any patches)? Clarification: Updated the two files listed to HEAD build/install/reboot Still getting PHY read failed Patch file build/install/reboot Still getting PHY read failed If HEAD is the now same as the patched version I can't see how this will be any different, but I'll try it tomorrow. Patched version was the same, excepting the cardbus removal, so it's no surprise it's still broken. Still on cvs here. /usr/src/sys/dev/re/if_re.c rev 1.155 /usr/src/sys/pci/if_rlreg.h rev 1.95 -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Monday 09 March 2009 06:08:41 Pyun YongHyeon wrote: On Sun, Mar 08, 2009 at 05:05:12PM +, ian j hart wrote: On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote: On Sat, Mar 07, 2009 at 05:17:57PM +, ian j hart wrote: On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote: On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote: On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x1800. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x9800 (8110SCe) while working chip seems to be 0x1800 (8110SCd) with 0xfc80. FYI... Now armed with the information, I made it work without reverting memory mapped I/O. :-) http://people.freebsd.org/~jkim/re/re.current2.diff http://people.freebsd.org/~jkim/re/re.stable2.diff I like the patch. Since only RTL8169 family uses mask 0xfc80 it would be even better we can limit checking scope for RTL8169SC by comparing PCI device id. I don't know what other side effect would happen if the mask 0xfc80 would be used on 8101/8168 controllers. If the patch works on RTL8169SC would you commit the patch? I'd like to see multiple commits separated by each enhancements as the patch contains several fixes which are not directly related with the issue. Where are we on this? I have a headless firewall box which is not happy with 7.1-RELEASE. I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read failed' errors, although the network did come up, which was an improvement. Is there a patch I can try? http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174proname=A D3RT LAN-G re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x re0: Ethernet address: 00:30:18:ae:1a:1b re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x re1: Ethernet address: 00:30:18:ae:1a:1c re1: [FILTER] re2: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0 re2: Chip rev. 0x1800 re2: MAC rev. 0x re2: Ethernet address: 00:30:18:ae:1a:1d re2: [FILTER] r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:12:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 Have you tried re(4) in HEAD? I had one report that re(4) in HEAD still does not fix the issue so I posted a possible workaround for that. Unfortunately he didn't report back so I don't know whether it was right workaround or not. If re(4) in HEAD does not fix the issue, would you try attached patch and let me know how it goes? Firstly IANAKH, my expertise in this area stops after make kernel. I updated /usr/src/sys/dev/re/if_re.c /usr/src/sys/pci/if_rlreg.h to HEAD And after updating to HEAD did you apply my patch? I still get PHY read failed with and without the patch. That's odd. Another user who has the same controller reports the fix fixed the issue. I also committed the patch to HEAD so would you give it spin again (without applying any patches)? Clarification: Updated the two files listed to HEAD build/install/reboot Still getting PHY read failed Patch file build/install/reboot Still getting PHY read failed If HEAD is the now same as the patched version I can't see how this will be any different, but I'll try it tomorrow. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote: On Sat, Mar 07, 2009 at 05:17:57PM +, ian j hart wrote: On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote: On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote: On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x1800. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x9800 (8110SCe) while working chip seems to be 0x1800 (8110SCd) with 0xfc80. FYI... Now armed with the information, I made it work without reverting memory mapped I/O. :-) http://people.freebsd.org/~jkim/re/re.current2.diff http://people.freebsd.org/~jkim/re/re.stable2.diff I like the patch. Since only RTL8169 family uses mask 0xfc80 it would be even better we can limit checking scope for RTL8169SC by comparing PCI device id. I don't know what other side effect would happen if the mask 0xfc80 would be used on 8101/8168 controllers. If the patch works on RTL8169SC would you commit the patch? I'd like to see multiple commits separated by each enhancements as the patch contains several fixes which are not directly related with the issue. Where are we on this? I have a headless firewall box which is not happy with 7.1-RELEASE. I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read failed' errors, although the network did come up, which was an improvement. Is there a patch I can try? http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174proname=AD3RT LAN-G re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x re0: Ethernet address: 00:30:18:ae:1a:1b re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x re1: Ethernet address: 00:30:18:ae:1a:1c re1: [FILTER] re2: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0 re2: Chip rev. 0x1800 re2: MAC rev. 0x re2: Ethernet address: 00:30:18:ae:1a:1d re2: [FILTER] r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:12:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 Have you tried re(4) in HEAD? I had one report that re(4) in HEAD still does not fix the issue so I posted a possible workaround for that. Unfortunately he didn't report back so I don't know whether it was right workaround or not. If re(4) in HEAD does not fix the issue, would you try attached patch and let me know how it goes? Firstly IANAKH, my expertise in this area stops after make kernel. I updated /usr/src/sys/dev/re/if_re.c /usr/src/sys/pci/if_rlreg.h to HEAD I still get PHY read failed with and without the patch. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote: On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote: On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote: I found something interesting. I have another RTL8169SC that works perfectly fine without the patch. The hardware revision is 0x1800. After reading Linux driver (drivers/net/r8169c), I realised they use different masks for hardware revisions. With their logic, non-working chip seems to be 0x9800 (8110SCe) while working chip seems to be 0x1800 (8110SCd) with 0xfc80. FYI... Now armed with the information, I made it work without reverting memory mapped I/O. :-) http://people.freebsd.org/~jkim/re/re.current2.diff http://people.freebsd.org/~jkim/re/re.stable2.diff I like the patch. Since only RTL8169 family uses mask 0xfc80 it would be even better we can limit checking scope for RTL8169SC by comparing PCI device id. I don't know what other side effect would happen if the mask 0xfc80 would be used on 8101/8168 controllers. If the patch works on RTL8169SC would you commit the patch? I'd like to see multiple commits separated by each enhancements as the patch contains several fixes which are not directly related with the issue. Where are we on this? I have a headless firewall box which is not happy with 7.1-RELEASE. I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read failed' errors, although the network did come up, which was an improvement. Is there a patch I can try? http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174proname=AD3RTLAN-G re0: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0: Chip rev. 0x1800 re0: MAC rev. 0x re0: Ethernet address: 00:30:18:ae:1a:1b re0: [FILTER] re1: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0 re1: Chip rev. 0x1800 re1: MAC rev. 0x re1: Ethernet address: 00:30:18:ae:1a:1c re1: [FILTER] re2: RealTek 8169SC/8110SC Single-chip Gigabit Ethernet port 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0 re2: Chip rev. 0x1800 re2: MAC rev. 0x re2: Ethernet address: 00:30:18:ae:1a:1d re2: [FILTER] r...@pci0:0:9:0: class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:11:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 r...@pci0:0:12:0:class=0x02 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 Thanks -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote: Hi, When have done this, MySQL is OK but Berkley and PostgreSQL need dump/restore. /glz [sorry I'm a bit late] IIRC system accounting did weird stuff until I adjusted it with rm :) --On February 13, 2009 2:53:13 -0500 Mike Andrews mandr...@bit0.com wrote: Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Denninger wrote: [...] I guess I need to schedule the 2-3 hours of downtime. the reason for this, by the way, is that I have a dbms app on there that is getting too RAM hungry for its own good (its a Quadcore CPU) and I'm up against the RAM limit for 32-bit code. The board will support more but 32-bit code won't; ergo, the only way to get beyond this is to go to 64-bit. Oh wait! One thing you wanted to know is that, some database *can* have different on-disk format for 32-bit and 64-bit binaries. Be sure to have a dump handy. Last time I hit this on a MySQL upgrade between two servers, and I end up using its replication functionality. The operation took longer time than I expected at the beginning. For what it's worth, I did an in-place source upgrade on our MySQL server (for the same lack-of-memory reason) and didn't have any on-disk format problems. In fact later on when troubleshooting data corruption problems that turned out to be bad hardware, I switched between 32-bit and 64-bit mysqld binaries without rebooting or dumping/reimporting the database. BUT... there was no replication involved. It wouldn't surprise me if the binlog or relay logs were in an architecture specific format. InnoDB and MyISAM tables don't appear to be. This was over a year ago though, so test on a scratch box first and you may save yourself a bit of downtime. The upgrade is a pain, and does have a lot of potential foot-shooting, and you have to immediately recompile ALL of your installed ports (and anything else not built from ports) to avoid mixing 32-bit and 64-bit shared libraries... and that rebuilding ports time is where most of your downtime comes from if it's a production box. If you're feeling lucky, the procedure's in the list archives somewhere and the super-short version is you turn your swap partition into a temporary amd64 root filesystem, installworld/kernel into that, boot into that, then mount and installworld/kernel on top of the old i386 root filesystem from there, then boot into it and recompile all your ports (after reclaiming your swap partition for swap). Or, the way I did it last time was to boot into a PXE diskless FreeBSD/amd64 install and use that to mount/install over the i386 stuff. Definitely practice on a scratch system first. :) -- Mike Andrews Server Monkey Fark, Inc mandr...@fark.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ... the future isMobile Goran Lowkrantz goran.lowkra...@ismobile.com System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Upgrade from 32-bit to AMD-64?
On Wednesday 18 February 2009 17:57:16 Karl Denninger wrote: ian j hart wrote: On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote: Hi, When have done this, MySQL is OK but Berkley and PostgreSQL need dump/restore. /glz [sorry I'm a bit late] IIRC system accounting did weird stuff until I adjusted it with rm :) --On February 13, 2009 2:53:13 -0500 Mike Andrews mandr...@bit0.com wrote: Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Denninger wrote: [...] I guess I need to schedule the 2-3 hours of downtime. the reason for this, by the way, is that I have a dbms app on there that is getting too RAM hungry for its own good (its a Quadcore CPU) and I'm up against the RAM limit for 32-bit code. The board will support more but 32-bit code won't; ergo, the only way to get beyond this is to go to 64-bit. Oh wait! One thing you wanted to know is that, some database *can* have different on-disk format for 32-bit and 64-bit binaries. Be sure to have a dump handy. Last time I hit this on a MySQL upgrade between two servers, and I end up using its replication functionality. The operation took longer time than I expected at the beginning. For what it's worth, I did an in-place source upgrade on our MySQL server (for the same lack-of-memory reason) and didn't have any on-disk format problems. In fact later on when troubleshooting data corruption problems that turned out to be bad hardware, I switched between 32-bit and 64-bit mysqld binaries without rebooting or dumping/reimporting the database. BUT... there was no replication involved. It wouldn't surprise me if the binlog or relay logs were in an architecture specific format. InnoDB and MyISAM tables don't appear to be. This was over a year ago though, so test on a scratch box first and you may save yourself a bit of downtime. The upgrade is a pain, and does have a lot of potential foot-shooting, and you have to immediately recompile ALL of your installed ports (and anything else not built from ports) to avoid mixing 32-bit and 64-bit shared libraries... and that rebuilding ports time is where most of your downtime comes from if it's a production box. If you're feeling lucky, the procedure's in the list archives somewhere and the super-short version is you turn your swap partition into a temporary amd64 root filesystem, installworld/kernel into that, boot into that, then mount and installworld/kernel on top of the old i386 root filesystem from there, then boot into it and recompile all your ports (after reclaiming your swap partition for swap). Or, the way I did it last time was to boot into a PXE diskless FreeBSD/amd64 install and use that to mount/install over the i386 stuff. Definitely practice on a scratch system first. :) -- Mike Andrews Server Monkey Fark, Inc mandr...@fark.com I have been able to come up with a procedure that works. It's a while back, but I believe this matches what I did. I built the same major/minor revision, just in case it made any difference. 1. Load a new hard disk with the 64-bit code. Perform a buildworld and buildkernel, and installkernel and installworld to this disk to verify that it will install and run. You now have a base disk to use for migration. 2. Make sure you have a backup (:-)) Not optional. I broke the mirror and took a backup and I actually checked the backup. 3. Boot the migration hard disk as the system disk and mount the subject machine's disk drive(s) under /mnt. 4. Do make DESTDIR=/mnt installkernel and make DESTDIR=/mnt installworld 5. Shut down and disconnect migration disk. 6. Boot SINGLE USER and verify that the system boots, you can fsck -p the disks, and mount them. The system should boot and run. 7. Come up multiuser but with any services necessary to the world offline. Some of your packages may blow up when started. If so, portupgrade SHOULD fix it, but this is not consistent. I had to manually dump the ports tree and rebuild a few installed ports due to what appear to be broken dependancies, but not many. I put ports in rc.conf.local. Makes it simple to disable them all. IIRC I deleted them all and did pkg_add -r, which is quick enough if you don't have X. Save a listing first, of course. Postgresql 32-bit runs fine without recompilation after doing this. It is arguably preferrable to recompile; doing so requires a dump/restore of the data as the 32 and 64-bit code will NOT run off the same binary data store. Attempting to make instalkernel on an in-place basis resulted in a system that booted but failed immediately due to loader conflicts; there was no way to get the rest of the codeset loaded if you make that mistake. The migration disk approach appears to work fine. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http
Re: HP Pavilion dv2000 laptop wont boot off install cd
On Monday 21 July 2008 16:51:11 Carlos A. M. dos Santos wrote: On Mon, Jul 21, 2008 at 9:26 AM, Kevin K [EMAIL PROTECTED] wrote: On Thu, 17 Jul 2008 08:31:37 -0400 Kevin K [EMAIL PROTECTED] wrote: For 7.0-RELEASE, it seemed to hang at Trying to mount root from ufs:/dev/md0. How long did you wait? If you didn't wait 10 or 15 minutes, please do. Various tests / probes take a long time to time out on some hardware. HTH -- Regards, Torfinn Ingolfsen I tried the 7.0-release-amd64 200807 snapshot and it booted (after holding the spacebar @ /boot/loader.conf). I have seen this on some HP notebooks. It seems that the CD drive does not to stabilize on time before booting, leading to some disk read errors. The trick is to press F9 (or F12, depending on the notebook model) to force the BIOS to show the boot device menu. Then, *after the CD drive stop spinning*, choose the boot from CD/DVD option. It stopped at Trying to mount root from ufs:/dev/md0. I waited about 30-45 minutes and it didn't continue from that point -- the keyboard was also unresponsive. Does anyone know if this is a known issue? Try to disable kbdmux before booting. Jump to the loader prompt and type: set hint.kbdmux.0.disabled=1 boot -v -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Can you try set hw.ata.atapi_dma=0 from the loader prompt. It's a long shot but it just might work. As it's a laptop, you might need to do all the other stuff as well. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
On Wednesday 23 July 2008 01:18:35 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is best? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint Item #2 is the easiest. You should really be able to leave the BIOS settings at their defaults (Factory Defaults) and have this system work on FreeBSD. You would think so, although I usually try to buy only obsolete hardware to give the drivers a chance to mature. That saves money too :) Items #2 and #3 are the same. The loader menu option for disabling ACPI simply sets the hint. Okay, that's clearer now. I was probably confusing this with APIC. Anyway, result is. No change. FWIW without ACPI the boot dies at trying to mount md0. No drives appear to be probed (I'd need to double check that). Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. You *absolutely* should have AHCI enabled. There's a lot of reasons why, too. I highly recommend avoiding the SATA Compatible mode. AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because we have many Supermicro boards running those versions which do have AHCI enabled. Please use it, and stick with it. Yes, it does work on 6.3. This thread is tangential to the problem I'm trying to fix. I'm experienced enough to know that noone is going to fix the kldload issue on 6.3. If I can get to 7.0-whatever there's at least some chance someone will look at it. My initial thought was to regression test the CDs. So I tried every one that I had lying around. This included 6.1 and 6.2, neither of which appear to have AHCI support, hence the messing about with the BIOS. [I've now tested 6.0 as well. The CDROM has some issue which results in danger will robinson. Presumably fixed in later versions.] Noone has yet suggested a source for 7.0-CURRENT boot CDROMs so I'm a bit stuck at the moment. Here's added proof that AHCI works fine on 6.3: $ dmesg -a | grep -i ahci atapci1: Intel AHCI controller port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe400-0xe7ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected $ uname -r -s FreeBSD 6.3-PRERELEASE The adX device renumbering is expected. There are workarounds for this, but I recommend you simply enable AHCI. Do not keep toggling it on/off. Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date -- Set to GMT, not local time!!! * Serial ATA -- SATA Controller Mode -- Enhanced -- SATA AHCI -- Enabled * Advanced * Boot Features -- Quiet Mode -- Disabled -- Enable Multimedia Timer -- Enabled * PCI Configuration -- Onboard G-LAN1 OPROM -- Disabled -- Large Disk Access Mode -- Other * Advanced Processor Options -- Intel(R) Virtualization Technology -- Enabled -- C1 Enhanced Mode -- Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Okay, I've had a chance to review
Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
On Wednesday 23 July 2008 01:18:35 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is best? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint Item #2 is the easiest. You should really be able to leave the BIOS settings at their defaults (Factory Defaults) and have this system work on FreeBSD. Items #2 and #3 are the same. The loader menu option for disabling ACPI simply sets the hint. Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. You *absolutely* should have AHCI enabled. There's a lot of reasons why, too. I highly recommend avoiding the SATA Compatible mode. AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because we have many Supermicro boards running those versions which do have AHCI enabled. Please use it, and stick with it. Here's added proof that AHCI works fine on 6.3: $ dmesg -a | grep -i ahci atapci1: Intel AHCI controller port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe400-0xe7ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected $ uname -r -s FreeBSD 6.3-PRERELEASE The adX device renumbering is expected. There are workarounds for this, but I recommend you simply enable AHCI. Do not keep toggling it on/off. Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date -- Set to GMT, not local time!!! * Serial ATA -- SATA Controller Mode -- Enhanced -- SATA AHCI -- Enabled * Advanced * Boot Features -- Quiet Mode -- Disabled -- Enable Multimedia Timer -- Enabled * PCI Configuration -- Onboard G-LAN1 OPROM -- Disabled -- Large Disk Access Mode -- Other * Advanced Processor Options -- Intel(R) Virtualization Technology -- Enabled -- C1 Enhanced Mode -- Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Okay, I've had a chance to review the board manual that comes with the X7SBi. You should set the following: Serial ATA: Enabled Native Mode Operation: Serial ATA SATA AHCI: Enabled SATA AHCI Legacy: Disabled The name SATA AHCI Legacy a horrible name for what it does. The ICH9 itself has support for 6 SATA ports, but (if I remember correctly, based on reading some Intel design documents) there are extra registers you have to tweak to get those ports to work, and the OS has to be fully aware of how to do that. The BIOS option simply disables SATA ports 5 and 6 altogether; the underlying OS never sees them. I'd recommend keeping that setting Disabled (the default) unless you have disks on those ports (I don't see how, since it's a 4-disk system!). I don't think this option is what's causing you problems, though. Multimedia Timer is indeed HPET. Looks like they changed the name to be more reflective of what it actually is. The Large Disk Access mode does appear to be missing from that BIOS, probably for a good reason. I can enable/disable it on our boards
Re: unable to use gmirror on supermicro 5015b-mt
On Tuesday 22 July 2008 16:59:20 ian j hart wrote: These are new boxes. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm core 2 Q6600 CPU 8Gb 667 RAM Boxes were memtested from Fri-Mon okay. 6.3-RELEASE (amd64) installs fine. Build cycle okay. Running (no load) for a week or so. However, when I try to configure gmirror they hang on boot. After some fiddling it appears issuing #kldload geom_mirror hangs the boxes very hard. Ping response stops (after 3), no CAD response, CDROM draw doesn't open! This may well be a foolish thing to do but another (different) amd64 box doesn't hang. I don't believe this to be amd64 specific, I suspect that there's something strange about this hardware. There are very many BIOS options and I feel like I've tried them all without getting anywhere. I'm on holiday this week and I've borrowed a box to test. Any suggestions would be welcome. I'll (re)try anything but I need help to stay focused. Before you ask, no I cannot try 7.0-RELEASE, but that's a whole other thread (which may bear fruit more quickly). I already dropped the RAM to 2Gb and disabled the memory remap in the BIOS. dmesg after sig [AHCI disabled, SATA legacy mode] Thanks As I suspected, no takers :) Fix. In /boot/loader.conf hw.ata.atapi_dma=0 This allows kldload without hang. I'm sure that this fix will allow me to configure a mirror. I'll post back if I'm wrong. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to use gmirror on supermicro 5015b-mt
On Wednesday 23 July 2008 23:06:39 Clifton Royston wrote: On Wed, Jul 23, 2008 at 09:23:52PM +0100, ian j hart wrote: ... As I suspected, no takers :) Fix. In /boot/loader.conf hw.ata.atapi_dma=0 This allows kldload without hang. I'm sure that this fix will allow me to configure a mirror. I'll post back if I'm wrong. OK, but *probably* this is an indicator that you need to either replace the cable (think you said you've tried that) or replace the motherboard. I tried a 40 wire cable. That's a different test than trying a new (80 wire) cable. If the cable is known-good and the other components are known-good, and it won't run with DMA on supported hardware, something is seriously wrong with this particular board and odds are too high that it will die horribly later. What are the odds that I bought five systems with exactly the same fault? To avoid tempting fate I should say I only tried the fix one one box so far. I'm really not that worried tho'. (Not to mention that you'll be hammering your CPU just to get lousy throughput out of it.) Given that the CDROM (DVD if we're being pedantic) will probably get no use at all, ever, I'm not that worried about it's throughput. As you said in the other post, you've already spent hours of your life you won't get back - do you want to sign up for some more hours further down the road? -- Clifton (suddenly questioning why I'm spending hours on mailing lists today) -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
unable to use gmirror on supermicro 5015b-mt
These are new boxes. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm core 2 Q6600 CPU 8Gb 667 RAM Boxes were memtested from Fri-Mon okay. 6.3-RELEASE (amd64) installs fine. Build cycle okay. Running (no load) for a week or so. However, when I try to configure gmirror they hang on boot. After some fiddling it appears issuing #kldload geom_mirror hangs the boxes very hard. Ping response stops (after 3), no CAD response, CDROM draw doesn't open! This may well be a foolish thing to do but another (different) amd64 box doesn't hang. I don't believe this to be amd64 specific, I suspect that there's something strange about this hardware. There are very many BIOS options and I feel like I've tried them all without getting anywhere. I'm on holiday this week and I've borrowed a box to test. Any suggestions would be welcome. I'll (re)try anything but I need help to stay focused. Before you ask, no I cannot try 7.0-RELEASE, but that's a whole other thread (which may bear fruit more quickly). I already dropped the RAM to 2Gb and disabled the memory remap in the BIOS. dmesg after sig [AHCI disabled, SATA legacy mode] Thanks -- ian j hart %dmesg Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:43:02 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP ACPI APIC Table: PTLTD APIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2394.02-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 2145845248 (2046 MB) avail memory = 2059509760 (1964 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 01:41:13) acpi0: PTLTDXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 uhci0: UHCI (generic) USB controller port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller 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 uhci1: UHCI (generic) USB controller port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller 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 uhci2: UHCI (generic) USB controller port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xd8601000-0xd86013ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib3: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci5: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci13: ACPI PCI bus on pcib4 em0: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0x2000-0x201f mem 0xd800-0xd801 irq 16 at device 0.0 on pci13 em0: Ethernet address: 00:30:48:64:22:fa pcib5: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci15: ACPI PCI bus on pcib5 em1: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0x3000-0x301f mem 0xd820-0xd821 irq 17 at device 0.0 on pci15 em1: Ethernet address: 00:30:48:64:22:fb uhci3: UHCI (generic) USB controller port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3
unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Thanks -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is best? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date -- Set to GMT, not local time!!! * Serial ATA -- SATA Controller Mode -- Enhanced -- SATA AHCI -- Enabled * Advanced * Boot Features -- Quiet Mode -- Disabled -- Enable Multimedia Timer -- Enabled * PCI Configuration -- Onboard G-LAN1 OPROM -- Disabled -- Large Disk Access Mode -- Other * Advanced Processor Options -- Intel(R) Virtualization Technology -- Enabled -- C1 Enhanced Mode -- Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Thanks for your help. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
a panic after each and get 2 core dumps, or run the debug commands suggested (either as debug LOR1 / continue / debug LOR2, or debug LOR1 / reboot / continue LOR1 / debug LOR2 - whichever is more appropriate). For the moment I have both hard drives (7.0-STABLE/amd64 and 7.0-RELEASE/i386) and the new motherboard (no serial, but with firewire) as a working computer under my desk. I can prepare for the night-time switch and debug by compiling kernel and/or world and doing some preliminary testing here. If I really need to test null modem console, I can put the hdd in my own desktop and test with another machine. A shot-in-the-dark guess is that something about pf's interactions with the protocol stack is involved here, but unfortunately I suspect we'll need some more information to track it down. Also, could you confirm if you're using any credential-related firewall rules with either ipfw or pf? These would be uid/gid/jail matching rules. As I said above, I don't use any uid/gid/jail rules. Mail with pf.conf and ipfw config incoming shortly after this one. Robert N M Watson Computer Laboratory University of Cambridge [snip] That's quite a complex setup. It would really be interesting to get the trace for the first LOR in order to figure out which code path we are looking at. I have a feeling that it might be the dummynet entry point, but w/o the trace this is only speculation. Working on it. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News I'd like suggestions / comments about the kernel config I'm thinking about for debugging purposes: - take my KERNEL (GENERIC + IPFW - IPv6 and SCTP and wireless), and add: options WITNESS options WITNESS_KDB # only if debug-on-first-warn is wanted options WITNESS_SKIPSPIN options KDB #options KDB_TRACE # not needed since I'll trace anyway? options DDB #options BREAK_TO_DEBUGGER # would that work for my kind of lockup? options MSGBUF_SIZE=409600 Ideally I would like to hear that the manual tracing and debugging with a keyboard console would provide enough info. I'll increase the kernel buffer size to 400k as above, so I don't lose info when I continue and dmesg log.txt. Just as easily, I can try forcing a panic at the LORs and keeping the kernel dumps (with optional debugging in ddb like above). The advantage is that this might andswer supplementary questions after the deed is done. Both the above options should be possible this week. The serial console part may or may not happen this week, and I'm quite positive it will take another week before I find the time to spend 16+ hours on location, waiting for a lockup (which might happen at a busy time and therefore I'll have very little time to do all the debugging). Tips / suggestions are most welcome! Thanks for the help! Alex -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd on a NAT gateway seems to do nothing
On Monday 23 July 2007 20:22:22 Pete French wrote: It's deja-vu all over again. I found my works NTP service was broken on Friday, just after I started my holiday. Interesting to hear from someone also using NAt with a very similar problem. Thanks, I am running -STABLE rather than RELENG, but I suspect I will simply try updating to a later STABLE tomorrow and see if that helps. I'm using IPFW and ipnat, which I believe is somewhat unusual. Ipnat is there to 'fix' the source IP. Don't ask! :-) once you start playing with NAT things can get odd quite fast I have : found! : Anyway; I just did a cleandir x2, rebuild and update to p6, and it's working again. Might be worth a try. I'll try tomorrow, thanks, -pete. Well it could just as easily be the associated reboot, but one hesitates to suggest that on a *nix list :) -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd on a NAT gateway seems to do nothing
On Monday 23 July 2007 13:50:09 Pete French wrote: Just following the similarly names thread with a bit of interest and I decided to check my own ntp setup and, to my surprise, discovered I also have a machine which does nothing. What is more surprising to me is that it has the same config as a number of other machines, all of which work. We have a segment of network which is behind a NAT, and there is a BSD box running 'pf' actiing as the NAT gateway. Running ntpd on the actual NAT box does not work, but running it on the clients the far side of the NAT does, or on clients the live side of the NAT. I should probably exolain that the NAT goes onto another network which is also natted, though that NAT is out of my control. The ntp.conf file looks like this on all machines: disable auth enable ntp driftfile /etc/ntp.drift server 10.17.19.0 server 195.40.0.250 server 158.43.128.33 server 158.43.128.66 server 158.43.192.66 The time servers there are for easynet, pipex and an internal machine at a remote location. ntpdate on the machine can query all the hosts fine, but ntpdc -p gives: remote local st poll reach delay offsetdisp === =valliere.ns.eas 172.16.1.8 16 640 0.0 0.00 0.0 =turpentine.ratt 172.16.1.8 3 1287 0.01451 -0.007633 1.93823 =ntp2.pipex.net 172.16.1.8 16 640 0.0 0.00 0.0 =ntp0.pipex.net 172.16.1.8 16 640 0.0 0.00 0.0 =ntp1.pipex.net 172.16.1.8 16 640 0.0 0.00 0.0 As you can see, it can only reach the internal machine. On other machines behind the NAT it looks like this: remote local st poll reach delay offsetdisp === =valliere.ns.eas 10.50.50.2 2 256 377 0.00577 -0.004396 0.01192 =turpentine.ratt 10.50.50.2 3 256 377 0.01534 -0.004566 0.00482 *ntp2.pipex.net 10.50.50.2 2 256 377 0.00635 -0.004052 0.00899 =ntp0.pipex.net 10.50.50.2 2 256 377 0.00729 -0.002443 0.01395 =ntp1.pipex.net 10.50.50.2 2 256 377 0.00768 -0.002426 0.00951 But those connections are flowing through the NAT box oon which ntpd is not connecting! Any suggestions ? I assume it has something to do with the NAT, but I am not sure what. All other TCP connections out from that machine to external systems work fine, so it is not as if outbound connections from there are not working at all. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] It's deja-vu all over again. I found my works NTP service was broken on Friday, just after I started my holiday. Packets were going out but nothing was coming back. I'm using IPFW and ipnat, which I believe is somewhat unusual. Ipnat is there to 'fix' the source IP. Don't ask! Checking the logs it appears that this broke after I updated from 6.2-RELEASE-p1 to 6.2-RELEASE-p5. I found this in messages. May 30 17:25:31 firewall ntpd[825]: ntpd 4.2.0-a Tue May 29 20:59:19 BST 2007 (1) May 30 17:27:31 firewall ntpd[825]: too many recvbufs allocated (40) ntpq -p would report No Association ID's (from memory) Anyway; I just did a cleandir x2, rebuild and update to p6, and it's working again. Might be worth a try. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is SATA II supported in 6.2-stable?
On Tuesday 06 March 2007 11:06, Artem Kuchin wrote: Hi! I just setup a new machine and while it is supposed to be full SATA II i still see these lines in at kernel init: Mar 6 14:00:09 aaa kernel: ad8: 305245MB Seagate ST3320620AS 3.AAE at ata4-master SATA150 Mar 6 14:00:09 aaa kernel: ad10: 305245MB Seagate ST3320620AS 3.AAE at ata5-master SATA150 IIRC those drives ship jumpered down to SATA150. Worth checking. As you see, it says SATA150 , while the drives are SATA II (which is, as i understand, SATA 300). Both drives are connected to RAID controller and form a mirror raid: Mar 6 14:00:09 aaa kernel: ar0: 305108MB LSILogic v3 MegaRAID RAID1 status: READY Mar 6 14:00:09 aaa kernel: ar0: disk0 READY (master) using ad8 at ata4-master Mar 6 14:00:09 aaa kernel: ar0: disk1 READY (mirror) using ad10 at ata5-master Any idea how to make it work as SATA II? -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is SATA II supported in 6.2-stable?
On Wednesday 07 March 2007 21:45, Jeremy Chadwick wrote: On Wed, Mar 07, 2007 at 09:26:40PM +, ian j hart wrote: On Tuesday 06 March 2007 11:06, Artem Kuchin wrote: Mar 6 14:00:09 aaa kernel: ad8: 305245MB Seagate ST3320620AS 3.AAE at ata4-master SATA150 Mar 6 14:00:09 aaa kernel: ad10: 305245MB Seagate ST3320620AS 3.AAE at ata5-master SATA150 IIRC those drives ship jumpered down to SATA150. Worth checking. That's correct. There's an incredibly tiny jumper on the jumper block which limits the transfer speed to 1.5gbit/sec (SATA150). Remove the jumper and you've got SATA300. The official product manual for this drive: http://www.seagate.com/support/disc/manuals/Desktop/Barracuda%207200.10/100 402371e.pdf 1. You might want to save the jumper. If you ever put the drive on a SATA150 controller, you'll need it. 2. Be gentle it's easy to damage the plastic surrounding the jumper (been there, done that). I'm not sure how fussy Seagate are, but case damage may invalidate your warranty. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nfsmb survey
On Monday 16 October 2006 18:15, Andriy Gapon wrote: In STABLE and upcoming 6.2 (and in CURRENT, of course) there is a new SMB driver for NForce2/3/4 chipsets, nfsmb, developed by Ruslan Ermilov. However, the driver doesn't currently work on all hardware that it is to support. The problem is with choosing proper BAR registers, which, as it seems, might be different for different chipsets/SMB controllers. If you have a system based on NForce2/3/4, could you please share the following information: 1. find out pci handle of your SMB controller: $ pciconf -l | fgrep 0x0c0500 and also note chip field value, it should match 00(64|84|d4|e4|52)10de. E.g.: [EMAIL PROTECTED]:1:1:class=0x0c0500 card=0x1c02147b chip=0x006410de rev=0xa2 hdr=0x00 2. read values in BARs 4 and 5 and also registers 0x50 and 0x54 like follows: $ pciconf -r pci0:1:1 0x20 $ pciconf -r pci0:1:1 0x24 $ pciconf -r pci0:1:1 0x50 $ pciconf -r pci0:1:1 0x54 using your pci handle instead of pci0:1:1, e.g.: $ pciconf -r pci0:1:1 0x20 $ pciconf -r pci0:1:1 0x24 $ pciconf -r pci0:1:1 0x50 1001 $ pciconf -r pci0:1:1 0x54 1041 3. send chip id and register values here. Thank you very much in advance. Tyan Thunder K8WE (S2895) data# pciconf -lv | fgrep 0x0c0500 [EMAIL PROTECTED]:1:1:class=0x0c0500 card=0x289510f1 chip=0x005210de rev=0xa2 hdr=0x00 data# pciconf -r pci0:1:1 0x20 a001 data# pciconf -r pci0:1:1 0x24 a041 data# pciconf -r pci0:1:1 0x50 a001 data# pciconf -r pci0:1:1 0x54 a041 -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kbdmux breaks keyboard LEDs
FreeBSD gamma.private.lan 6.1-RC FreeBSD 6.1-RC #3: Mon Apr 17 15:14:12 BST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOCAL amd64 kbdmux breaks keyboard LEDs. Cosmetic but anoying. Disabling (see man kbdmux) restores normal usage. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1RC1: Unable to select Minimal distribution
On Thursday 13 April 2006 17:03, Jung-uk Kim wrote: On Thursday 13 April 2006 04:47 am, Pieter de Goeje wrote: Hi, I installed FreeBSD 6.1RC1 in qemu. When sysinstall comes to the Choose Distributions screen, I am unable to choose the Minimal distribution. The [ ] stay blank. Also, selecting All doesn't include it either. You may not see 'X' but it is selected. ;-) It seems to be an annoying bug in libdialog. Some releases were okay and some not. I'll look into it when I find some time. Jung-uk Kim ref: http://docs.freebsd.org/cgi/mid.cgi?200603252247.00879.ianjhart Are you sure it's not one of the March 8th commits? Backing out fixes this for me. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1BETA4 sysinstall
Run sysinstall, custom, distributions select minimal No [x] appears. Selecting custom indicates items were selected. Seems to be one of the March 8th commits (sam) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Install bug - 4.9 stable - post install circular reboot
On Monday 12 January 2004 10:48 pm, Doug White wrote: On Tue, 17 Apr 2018, Kevin Berrien wrote: I can confirm an issue posted Dec 3rd, freebsd-stable maillist, titled 4.9 install buglet. I experience this bug running the install (various configurations) 100% of the time. After install, after system reboot, the boot loader comes up with F1: FreeBSD, and reboots continually forever. To test, I made 3 installs without issue using 4.8. So first, I'd like to confirm the bug report, and ask the following. Please qualify reboots continutally forever. It reboots after printing the F1: FreeBSD message, or after you press a key, or what? This sounds like a BIOS issue. boot0 uses only BIOS calls to do its work. Lots of problems like this are also caused by bad drive geometry. What is the partition layout on the disk(s) in the system? Hardware description? Here's my original post for comparison: http://docs.freebsd.org/cgi/mid.cgi?200312031933.25176.ianjhart -- ian j hart http://ars.userfriendly.org/cartoons/?id=20031016 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup with tag=. on src and upgrading (in general)
On Saturday 14 June 2003 3:05 am, Richard Schilling wrote: [snip doco stuff] I don't have the example cvsup files in /usr/share/examples/cvsup. Did I not install a port? --Richard Schilling Anything in /usr/share should be part of the base distro. Ports (mostly) install into /usr/local. IIRC one of the recent releases had these files missing. A full system rebuild should fix this, see /usr/src/UPDATING -- ian j hart Quoth the raven, bite me! Salem Saberhagen (Episode LXXXI: The Phantom Menace) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup with tag=. on src and upgrading (in general)
On Saturday 14 June 2003 3:09 am, Richard Schilling wrote: As for /usr/local/etc/cvsup, I did create it because the documentation used that directory in the examples for CVSup's status files. I also practiced uploading to a non-/usr directory first just to build confidence. I just used that directory because after reading it in the documentation I knew I'd remember it. Changed the base, however to my own staging area. Here's the example from the documentation: # Putting it all together: Here is the entire supfile for our example: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all --Richard Schilling So this fetches the src for CURRENT. In your original post you said you wanted to review changes/diffs. This will not allow you to do that because you only have a snapshot of the source. To put this another way, you have nothing to diff against. Also forgot to say that the simplest way to fetch a local copy of the repository is to install the cvsup-mirror port. Disable its cron job and run the update script whenever you need to. -- ian j hart Quoth the raven, bite me! Salem Saberhagen (Episode LXXXI: The Phantom Menace) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPF IPFW
On Saturday 01 February 2003 1:38 am, Andrew Thompson wrote: Crist J. Clark wrote: On Fri, Jan 31, 2003 at 11:17:10PM +, ian j hart wrote: On Friday 31 January 2003 10:25 pm, Claus Guttesen wrote: Thank you for the info. I guess it's OK that I forward this info to the maintainer of the above mentioned FAQ. regards Claus Har du problemer med din hjemmecomputer? F? hj?lp med Yahoo!s PC-support p? http://dk.shopping.yahoo.com/pcsupport/index.html OTOH if you only need ipnat and not ipfilter you can do this... Don't compile in ipf. Turn on ipnat in rc.conf it will run after all the ipfw rules. I use this to fix-up packet source addreses. e.g. (warning from memory) map rl0 from my-ip/32 to any port 25 - alias-ip/32 So outgoing email traffic appears to come from the alias IP. [Don't ask, you don't want to know]. ipf(8) and ipnat(8) are the userland commands to interface with the same code in the kernel. You can't separate them. If you define IPFILTER in your kernel configuration, you get both, even if you only use one. If you load ipf.ko, you get both, even if you use only one. ipnat(8) occurs before ipfw(8) for incoming and after ipfw(8) for outgoing whether or not you are using ipf(8) rules. Packets get passed to IPFilter-in-the-kernel (the kernel code that both ipf(8) and ipnat(8) talk to) one place in ip_input.c and once in ip_output.c. The only way to change that is modify the code in those two. (Well, you might be able do do something with tunnels to get the effects, but it's still true for each step of the tunnel(s).) Thanks everyone for your help, The bit I was having trouble with was doing two transparent proxies depending if the user had logged in or not, one to squid, the other to a static page telling them to log in. I have actually reworked my ipfw rules so I dont need ipf anymore and its all working. :) This thread can be dropped unless you all want to discuss the ordering more. IMHO Christ is right. Who's arguing? Your original query was not specific enough. = I am writing an app to do pre-pay internet and are using a combination of ipf and ipfw. I stupidly assumed that ipfw ran before ipf, of course its the other way around. This has put a hurdle in my design, is there an easy way to change the order of the two? or do I need to redesign :( = All I was pointing out is a loophole. If source address munging is what you wanted, I'd have been right :)) -- ian j hart Quoth the raven, bite me! Salem Saberhagen (Episode LXXXI: The Phantom Menace) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Sendmail with SASLv2 starts before saslauthd
Lefteris Tsintjelis wrote:
Scot W. Hetzel wrote:
From: Lefteris Tsintjelis [EMAIL PROTECTED]
When building world in 4.7-stable with sendmail and SASLv2 support,
sendmail complains that there is no SASL running. Problem is that
sendmail starts before saslauthd. Is there a proper way of starting
saslauthd before sendmail starts?
No, you'll need to patch /etc/rc.sendmail and then remove
${prefix}/etc/rc.d/saslauthd.sh.
Maybe you cannot start saslauthd before sendmail, but you
certainly can start sendmail after saslauthd.
/etc/rc.sendmail was designed to be compatible with
usage from ${local_startup}
So, disable sendmail startup by setting
mta_start_script=
in /etc/rc.conf
copy /etc/rc.sendmail to /usr/local/etc/rc.d/whatever.sh
and that's all she wrote.
In 5.0-CURRENT with/RC_NG all you'll need to do is move
${prefix}/etc/rc.d/saslauthd.sh to /etc/rc.d/saslauthd to have saslauthd
start before sendmail (see PR 43673 for RC_NG patch for
security/cyrus-sasl2).
Scot
PS: Attached is an untested patch for rc.sendmail
Thank you Scott. The patch worked out good. It has a problem with
stoping though. It doesn't completly stop sendmail. I'll try and figure
that out.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
--
ian j hart
Quoth the raven, bite me!
Salem Saberhagen (Episode LXXXI: The Phantom Menace)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Compiling a New Kernel
Phil Kernick wrote: Aragon Gouveia wrote: Ideally you should build, install, and boot your new kernel before installing your new world. If your new kernel fails to boot for whatever reason, you can easily boot the old kernel and have a fully functional system again. If you installworld before verifying your new kernel, you could run into worse problems if your new kernel doesn't load and you have to boot the old kernel with your new world. The only problem that I have with this approach, is that I keep all of my source on a vinum raid-5 volume. If I reboot before doing a make installworld, then there is always the possibility that with the new kernel and the old world I may not be able to mount the volume. So I always shutdown but *not* reboot before doing the installworld. Phil. -- _-_|\ Phil Kernick E-Mail: [EMAIL PROTECTED] / \ ROTFL Enterprises Mobile: 041 61 ROTFL \_.-*_/ v Humourist, satirist, and probably a few more 'ists to boot! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message It's early in the morning here :), but if the mount fails, you reboot and load kernel.old. At which point you should be able to mount your source. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA tags and stuff
ian j hart wrote: I can reproduce the tags problem, RELENG_4 built today. Also noticed some weird secondary IDE stuff. Are there any ATA patches I don't know about? Is it worth trying CURRENT? Will do anything (legal) to help solve the problem. I've borrowed the box for the weekend, so fire away. Three IBM-DTLA-307075 rescued from backup duties plus one new IC35L080AVVA07-0. [shown with tags off here] ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA100 ad1: 73308MB IBM-DTLA-307075 [148945/16/63] at ata0-slave UDMA100 ad2: 73308MB IBM-DTLA-307075 [148945/16/63] at ata1-master UDMA100 ad3: 73308MB IBM-DTLA-307075 [148945/16/63] at ata1-slave UDMA100 First tried a LEX BN630LT M/B. Installed 4.6-RELEASE, upgraded to STABLE. Set up vinum RAID10 volume. While formating I had systat -vmstat running. Noticed that while the load appeared the same on all four disks, ad0 and ad1 were at ~5% busy, ad2 and ad3 were at ~50% busy. I posted somthing similar before (20010807). I've swapped the cables around, same result. Tried different cables, same result. All cables are spec length, don't have any shorter. This is a new board - could be a design fault. So I tried a recent gigabyte board, same result. Set tags on. As soon as I load the vinum volume I get [snip time /kernel] ad2: READ command timeout tag=0 serv=0 - resetting ad2: invalidating queued requests ad2: timeout waiting for cmd=00 s=d0 e=04 ad2: flush queue failed ata1: resetting devices .. ad2: invalidating queued requests ad2: DMA limited to UDMA33, non-ATA66 cable or device ad3: invalidating queued requests done ad2: no request for tag=0 ad2: invalidating queued requests So far only ad2 and ad3 fail. A thought occurs. There could be a master/slave problem with the firmware in the DTLA drives, which is fixed in the IC35. I'll swap the IDE cables on the M/B and see what happens. Maybe I'd better sleep first, I'm rambling. BTW, this is NOT a vinum problem. I get the same problem on normal volumes (but only on ad2 ad3). This is just a *neat* way of loading the drives. Pass the pointy hat. I'd used the IBM feature tool to disable the write cache, but only on two of the three *old* drives. Enabling wc fixes the systat load reading and the tags error. The worse thing is there was a post with all the clues in (on wednesday), and I still didn't get it. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: XFree86 faster!?
Oliver Fromme wrote: Craig Boston [EMAIL PROTECTED] wrote: On Thu, 2002-06-27 at 14:44, Johannes Hofmann wrote: I just upgraded from 4.6 Release to -STABLE (Jun 27 21:42:28). My X feels much snappier now. Any ideas what might cause that? my 0.02 euro My perception is that it went slower at RC time, then back to normal post release. Have you filed a PR on this? I'm sure this is an issue that we would like to get resolved by 4.7-RELEASE if at all possible. First of all -- yes, I noticed the sarcasm. While the speed improvement that Johannes experienced is certainly desirable and should not be reversed, it _is_ somewhat important to find out what caused it. Because if the cause is unknown, then it could disappear one day (maybe at the next update), rendering the system slower again, and you wouldn't be able to do anything about it because you have no clue what it is. For what it's worth, I have no clue what it is, either. For the above reason, it is always preferable to know the causes for any changes in system behaviour, no matter if it changes in a positive or negative way. Computers are not magic, and software is not voodoo. Everything has a cause. Regards Oliver PS: Every sufficiently advanced technology is indistinguishable from magic. (Unfortunately I don't remember who said that.) That'll be Arthur C. Clarke. His third law, in Profiles of the future for example. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: restricted mode access list and ypbind problems
Mark Nipper wrote: I'm running 4.5-STABLE currently and was curious about the -S flag to ypbind. Trying to use it, as the handbook recommends, when running an NIS master server as a client, does not seem to work. I've tried using -S domain,localhost and -S domain,127.0.0.1 but both result in: --- Apr 12 10:01:33 hostname ypbind[27681]: NIS server at x.x.x.x not in restricted mode access list -- rejecting. with any sensitive information changed in the above of course. :) Anyway, I ran without flags, and ypbind worked fine. Just thought someone might be able to clarify the use of the -S flag. Use the FQHN rather than localhost. Don't forget to add this to the securenets file on the master (and rebuild). Read up on security through obscurity. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Another possible solution for non-sendmail users
Gregory Neil Shapiro wrote: Given that non-sendmail users will be inconvenienced when upgrading due to the 8.12 changes (need to change sendmail_enable from NO to NONE), I thought it might be better to give them something back for their trouble. As an alternative to sendmail_enable=NONE, why not solve the boot time problem for non-sendmail users completely. The patch moves all of the sendmail startup code from /etc/rc to /etc/rc.sendmail. The source for that script will be kept in src/etc/sendmail/rc.sendmail so make.conf's NO_SENDMAIL will prevent it from being installed. A new rc.conf variable, mta_start_script specifies the script to run to start the user's preferred MTA. For backward compatibility, it will default to /etc/rc.sendmail. The specified script is called out of /etc/rc after checking to make sure it exists. I've also taken the opportunity to use /etc/rc.sendmail in /etc/mail/Makefile to reduce code duplication. A new rc.sendmail.8 man page has also been added which now houses the sendmail_* variable descriptions formerly in rc.conf.5. In a somewhat unrelated note, I also plan on arranging to move the sendmail-specific stuff out of src/etc/mail/ and into src/etc/sendmail so the installation of things like sample sendmail maps, etc. don't clutter a NO_SENDMAIL installation. I'll need to arrange this event with the CVS repomeisters. Hopefully, this change (along with the patch) will make things more palatable for non-sendmail users. The patch is against -CURRENT but should give -STABLE users a good idea of my intentions. It is available at: http://people.freebsd.org/~gshapiro/mta-start Opinions? Brilliant! I suppose you just threw this together :) One small quibble. If I want to set mta_start_script= and run rc.sendmail(.sh) from /usr/local/etc/rc.d shouldn't stop kill both queues? You'd need to add a stop-mtaq obviously. A global restart might be nice too. [If this is mindless drivel, just ignore:- need sleep.] -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Size of / partition?
David Reid wrote: Just cvsup'd to stable and I've almost run out of room on /! How big should I create it when I reinstall as I now don't have enough to do another build. bash-2.04$ df -k Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 4958344564 105398%/ /dev/ad0s2f 2646093 1830324 60408275%/usr /dev/ad0s2e 19815 82121001845%/var procfs 440 100%/proc david To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message Here's my 0.02 euro (IDE) disk space is very cheap. dump, repartition and restore is a right royal PITA. FreeBSD systems are long lived. So pick a number and double it. I've been using 256Mb for some time. A minimal install will just fit in 128Mb, at least last time I checked. This gives you an alternative to the live file system CD if your disk gets trashed, and you want to attempt a repair. I usually do my vinum systems this way. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
Matthew Dillon wrote: :... : : There is also the only supports 16MxN RAM feature. : : Maybe I should toss in that I've had spontaneous reboots during heavy : IDE activity both on my desktop (VIA 82C686) and my laptop (Intel : 82443BX). And before that, random disk corruption during heavy SCSI : activity on my old desktop machine (seen with Tekram and Acer : 83C575-based host adapters and a borrowed Adaptec 2940). : :Guys guys, we are talking about known HW issues that causes known :bad behavior, having a system that is flaky can have all kinds of :reasons, I'd risk saying that genuine HW bugs like the 686B bug :is one of the least likely problems... : :The most likely reasons are probably bad/subspec'd RAM, lousy PSU, :bad/subspec'd cabeling, too many performance features enabled, :generally crappy hardware (there are *tons* of that out there), :bad/insufficient cooling, overclocking (even the motherboard makers :overclock pr default nowadays to gain a litte over the competition), : :And do *not* forget bugs/bogons/mistakes in your favorite OS :) : :-Søren Ok, I have more information on Nils problem. First of all, Soren's patch greatly reduced the rate of corruption. It took 25 loops of Nils 'cp' test to generate the corruption. However, Soren's patch did not fiix the corruption. The same exact corruption is occuring. In Nils case it is always the same exact location in VM -- a certain bit (or byte) in the middle of the nfsnode hash table. Hardware watch points indicate that the cpu is NOT modifying this location, so I really doubt that it is a kernel bug. From this and from reading a number of other postings about VIA chipsets I believe that Soren's original patch (which I guess is the official VIA chipset patch) does not completely solve the VIA chipset's problems. I also believe, from reading some of the reference material that has been posted, that this corruption is not limited to the 686[A/B] but may also occur in earlier VIA chipsets. What I would like to do is try forcing the DMA transfer rate to 66 MHz, i.e. UDMA66 or UDMA33, to see if that solves the problem. Soren, could you supply a patch that universally turns off higher UDMA modes? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message I'm out of the loop on this one. I have been unable to reproduce the error for two weeks. I'll try backtracking to see if I can break it again. Summary: System VIA ATA33 (82C586) with UDMA66 drives. 4 disks RAID10 (vinum). Softupdates ON, DMA ON. 1 Upgraded BIOS. Side effect - factory default (safe) settings. 2 This revealed the memory addressing feature, so I swapped the 8chip X 1side SDRAM for an 8cX2s to match the other RAM present. This will wrap - sorry. http://www.azza.com.tw/ftp/specs/MTB-0109-01-00%20'Using%20more%20then%2064Mb%20memory%20with%20VIA%20MVP3%20chipset%20boards'.htm 3 The new BIOS doesn't like the ISA SCSI card and I get a panic on boot. BIOS settings which work put the SB128 on the same IRQ as the network card (rl). 4 Swapped the ISA SCSI card (adv) for a PCI (sym) one. [Only a CDRW on this] 5 Full build (Dec 11). I've thrashed the living daylights out of the drives without so much as a twitch. I enabled the memory performance features - still okay. If I can force an IRQ conflict I'll try that next, followed by the old SCSI card. I'd have to downgrade the BIOS to try the old memory, and anyway it's in another M/C. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-driver
Bob K wrote: On Wed, Dec 12, 2001 at 09:44:56PM +0200, Alex Popa wrote: disk I/O and heavy network I/O (my initial crashes occured when someone was making a large backup over SMB to the server, at about 9M/s disk I can't really offer any sort of useful help on any part of this problem, except for this: Quick poll: How many of you with this problem are running samba? I am. But there's absolutely no load. This is my workstation at home. The only other box is the firewall - FreeBSD of course. I tend to have copies of everything I need at work. For the docs and trial runs. I notice that my network card shares an irq with my SB128. How did that happen? I'll fix this. I've had no crashes last 24 hours, but I thought I'd fixed it once before. -- Bob [EMAIL PROTECTED] | Please don't spill hot things on Bob. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
ian j hart wrote:
ian j hart wrote:
Chad R. Larson wrote:
On Fri, Dec 07, 2001 at 01:33:15PM -0800, Brady Montz wrote:
Yeah, I'm using soft updates too. My crashes are generally the
same as Richards - no panic, just a freeze. Except my screen
doesn't go blank.
For what it's worth, I'm using soft updates on a web server that gets
steady if not heavy use. Built from RELENG_4_3, and no problems at
all.
-crl
--
Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm?
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Me 2 :(
I have a total lockup, screen is not blank (Matrox G400).
I turned off soft updates and did a boot -v and got some
console messages, so this is worth a try. Unfortunately the
messages don't make it to the logs, presumably because the
disk and/or disk subsystem is fubar'd. The one time a got
a spontaineous reboot I was out of the room making coffee
(typical).
Anyway the messages are something like
ad0: READ command timeout tag=0 serv=0 - resetting
ata0: resetting devices .. done
It's not always the same drive.
There were also some of my favorite UDMA ICRC errors, but
I didn't catch those. For those with long memories this is
the same box I've had UDMA problems with before (numerous
posts with UDMA ICRC in subject) but it's been well behaved
since early July. Maybe I haven't pushed it hard enough.
I also got one instance of unexpected soft update inconsisency
while fscking. Maybe this is to be expected if the drive just
dies.
What's interesting is the behavior seems to have changed. On
previous occasions the driver would keep resetting and then
drop to pio mode. Now it seems to lock after the first reset.
I'll try to confirm this behavior.
I set pio mode on all drives and I managed to complete my
torture test.
One more thing. Sometimes there's a clunk from the drive{s)
when it dies. Parking the heads?
FWIW -
VIA ATA33 controller
4x UDMA 66 drives
vinum mirror /var
vinum mirrored stripes /usr
Drat, spoke too soon.
soft updates on, dma off. Hang (in kde) followed by black
screen and reboot. This time vinum died on startup and I
had an anxious 10 minutes starting all the subdisks.
I'd better test the memory. Then I'll try booting from
the backup root in case ad0 is toast. I guess duff hardware is
looking more likely.
I noticed some UDMA errors when rebooting from single
user, which failed to sync 1 block. Of course these scroll
off screen too quick to be readable, but the head parking
noise was again apparent. APM is disabled.
--
ian j hart
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Update:
I couldn't prove the memory faulty but I did discover a useful
factlet which was missed out of the M/B handbook. Apparently
the VIA MVP3 chipset only supports 16MxN RAM when you have
more than 64Mb. This is not what I had. I updated the BIOS and
sure enough the board failed to detect all the RAM. I've
swapped it out. Maybe some update finally tickled the feature
hard enough to cause a panic.
I also did a full build, and this seems to have fixed some
weirdness with md0. Either I cvsup'd at a bad time or (more
likely) I fluffed the mergemester.
I'll thrash the bejesus out of the drives and see what happens.
--
ian j hart
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
Chad R. Larson wrote:
On Fri, Dec 07, 2001 at 01:33:15PM -0800, Brady Montz wrote:
Yeah, I'm using soft updates too. My crashes are generally the
same as Richards - no panic, just a freeze. Except my screen
doesn't go blank.
For what it's worth, I'm using soft updates on a web server that gets
steady if not heavy use. Built from RELENG_4_3, and no problems at
all.
-crl
--
Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm?
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Me 2 :(
I have a total lockup, screen is not blank (Matrox G400).
I turned off soft updates and did a boot -v and got some
console messages, so this is worth a try. Unfortunately the
messages don't make it to the logs, presumably because the
disk and/or disk subsystem is fubar'd. The one time a got
a spontaineous reboot I was out of the room making coffee
(typical).
Anyway the messages are something like
ad0: READ command timeout tag=0 serv=0 - resetting
ata0: resetting devices .. done
It's not always the same drive.
There were also some of my favorite UDMA ICRC errors, but
I didn't catch those. For those with long memories this is
the same box I've had UDMA problems with before (numerous
posts with UDMA ICRC in subject) but it's been well behaved
since early July. Maybe I haven't pushed it hard enough.
I also got one instance of unexpected soft update inconsisency
while fscking. Maybe this is to be expected if the drive just
dies.
What's interesting is the behavior seems to have changed. On
previous occasions the driver would keep resetting and then
drop to pio mode. Now it seems to lock after the first reset.
I'll try to confirm this behavior.
I set pio mode on all drives and I managed to complete my
torture test.
One more thing. Sometimes there's a clunk from the drive{s)
when it dies. Parking the heads?
FWIW -
VIA ATA33 controller
4x UDMA 66 drives
vinum mirror /var
vinum mirrored stripes /usr
--
ian j hart
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
ian j hart wrote:
Chad R. Larson wrote:
On Fri, Dec 07, 2001 at 01:33:15PM -0800, Brady Montz wrote:
Yeah, I'm using soft updates too. My crashes are generally the
same as Richards - no panic, just a freeze. Except my screen
doesn't go blank.
For what it's worth, I'm using soft updates on a web server that gets
steady if not heavy use. Built from RELENG_4_3, and no problems at
all.
-crl
--
Chad R. Larson (CRL15) 602-953-1392 Brother, can you paradigm?
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
DCF, Inc. - 14623 North 49th Place, Scottsdale, Arizona 85254-2207
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Me 2 :(
I have a total lockup, screen is not blank (Matrox G400).
I turned off soft updates and did a boot -v and got some
console messages, so this is worth a try. Unfortunately the
messages don't make it to the logs, presumably because the
disk and/or disk subsystem is fubar'd. The one time a got
a spontaineous reboot I was out of the room making coffee
(typical).
Anyway the messages are something like
ad0: READ command timeout tag=0 serv=0 - resetting
ata0: resetting devices .. done
It's not always the same drive.
There were also some of my favorite UDMA ICRC errors, but
I didn't catch those. For those with long memories this is
the same box I've had UDMA problems with before (numerous
posts with UDMA ICRC in subject) but it's been well behaved
since early July. Maybe I haven't pushed it hard enough.
I also got one instance of unexpected soft update inconsisency
while fscking. Maybe this is to be expected if the drive just
dies.
What's interesting is the behavior seems to have changed. On
previous occasions the driver would keep resetting and then
drop to pio mode. Now it seems to lock after the first reset.
I'll try to confirm this behavior.
I set pio mode on all drives and I managed to complete my
torture test.
One more thing. Sometimes there's a clunk from the drive{s)
when it dies. Parking the heads?
FWIW -
VIA ATA33 controller
4x UDMA 66 drives
vinum mirror /var
vinum mirrored stripes /usr
Drat, spoke too soon.
soft updates on, dma off. Hang (in kde) followed by black
screen and reboot. This time vinum died on startup and I
had an anxious 10 minutes starting all the subdisks.
I'd better test the memory. Then I'll try booting from
the backup root in case ad0 is toast. I guess duff hardware is
looking more likely.
I noticed some UDMA errors when rebooting from single
user, which failed to sync 1 block. Of course these scroll
off screen too quick to be readable, but the head parking
noise was again apparent. APM is disabled.
--
ian j hart
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: fs corruption (ATA / 4.4-REL)
Keith Mitchell wrote: On Mon, Oct 01, 2001 at 10:51:19PM +0100, ian j hart wrote: A re-read of your original post reveals it's a k6 450. Touch the CPU heatsink. If you burn your finger that's the problem :) Its a K6-2 450. The heatsink is fine (not even remotely warm to the touch). All the fans are running correctly and the ambiant temp in the case seems ok. The MB doesn't have the env monitoring stuff so I don't know the exact temps. Seriously tho' there were problems with one of the k6 chips, but it's so long ago I can't remember clearly whether it's the 450. What's the core voltage printed on the chip, and what's the M/B core voltage set to. There should also be a revision number. While you do that I'll see if I can find the info. If I'm correct there were two versions with different core voltages - one of which was suspect. Anyone remember this? I remember something about that. I have the later revision (the one with the 2.2 core voltage).. I don't know what the version of the chip is. The stepping is 12. (it would require me to take the heatsink off and unglue it (from the heatsink compound)). Yeah, I think this is the good one. What brand is the mobo, maybe someone else has one. Its an FIC PA-2013. Never seen one of these, sorry. I did check the IDE cable. I didn't see any problem with it. I replaced it with a brand new cable I had in a box and it didn't make any difference. It should be noted, that I have had FreeBSD on this machine before. It was a while ago (3.2 I believe). But, until now, I haven't done to much with this system. 3.2 installed fine and I didn't have any corruption problems. I haven't gotten very far with 4.4 though... Can't get past compining the stuff in ports. -- Keith Mitchell Email: [EMAIL PROTECTED] PGP key available upon request Well I'm about out of good advice appart from the usual stuff, which you seem to have covered :( Desperation Pull ALL the cards and the LS120 and run from one drive if possible. Beg/borrow/steal an old display card (ISA is good when you're desperate). A bad bus master implementation/duff card could hog the bus. If both drives fail like this you are left with the M/B as prime suspect. This is pretty thin I know. BTW the transfer rate on the Yamaha looks a bit strange. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: UDMA ICRC error reading fsb (?)
Marius Strom wrote: Appologies if I'm telling you what you already know, but for the benefit of the thread, and because this comes up regularly... By dead I mean rapidly increasing numbers of bad sectors on the drive with every write. I replaced the cable to no avail. The hard drive had otherwise functioned well for ~7-8 months. UDMA ICRC errors started popping up ~2 months after installation, and then last night suddenly I was unable to hit a slew of sectors. HD was a WD Caviar 30 Gig. That's not enough info. The interaction between the controller and the HDD is important. Send a dmesg with this drive attached. Unfortunately this is exactly the symptom you get when you have either a cable length or a controller/HDD miss-match. Do the problems go away when you disable UDMA with sysctl? This looks like the same time frame as my problems at home. I suspect that changes to the ata code (ie better UDMA support) tickled a hardware bug. (This is on the VIA UDMA33 chipset). When I replaced these drives the situation got WORSE because the new drives were faster than the old. This eventually lead me to fit very short cables - which fixed the problem. Don't make the mistake of thinking you have fixed your problem untill you verify that the old drive really is scrap. Even then new drives can give you a new set of problems. Assuming you now have the drive copied try #dd if=/dev/zero ... with and without UDMA. Verify the block numbers are the same each time. Make sure you zero the right drive ;) If Maxtor have a test utility you could try that. I had 4 Seagate drives (at work) which were apparently scrap. Two failed the Seagate diagnostic and hit the bin at 9.8m/s/s. Two were OK and worked fine when dropped to pio mode. Cheap and nasty M/B, with early UDMA66 controller! On Sat, Sep 08, 2001 at 02:15:52PM +0100, ian j hart wrote: Marius Strom wrote: FWIW, I had this error and assumed it was cabling. I've spent the last few hours copying data of what is now a dead disk and putting it back on a new disk. YMMV. What do you mean by dead? The way I describe dead being able to copy data off it is a neat trick. eg drive doesn't spin. What did you do about the cabling problem? What hardware do you have? On Fri, Sep 07, 2001 at 11:45:28PM +0100, ian j hart wrote: Dave Uhring wrote: On Friday 07 September 2001 17:04, Randall Hopper wrote: Dave Uhring: |On Thursday 06 September 2001 07:43 pm, Randall Hopper wrote: | What do these messages mean? Are CRCs done by the IDE | controller on DMA transfers and they're coming up wrong? | | ad0s2a: UDMA ICRC error writing fsbn 3283483 of 396704-396713 | (ad0s2 bn 3283483; cn 204 tn 98 sn 49) retrying | |Your drive is dying. Back it up and replace it. I think you are being a tad premature. There have been plenty of posts on this subject, both on stable and hardware. IIRC none of them were bad disks. Randall, 1) post a copy of dmesg so we can see what hardware you have. 2) measure the cable - M/B to drive. Ok, thanks. But what do these messages mean on a technical level? And could these just as well indicate a marginal cable, bad connector, loose connector, or the other hard drive on the controller being a bit flakey? Randall CRC's (16 bit cyclic redundancy check characters) have been done on controllers since we had to use floppies. The first Winchester drive interface I ever designed back in 1979 had a Fairchild 9401 (IIRC) CRC generator chip on it. The writes are failing. You may have marginal cabling or loose or corroded connectors. If you wish to keep using the drive, replace the cable and in doing so your contacts will also wipe clean. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Marius Strom [EMAIL PROTECTED] Professional Geek/Unix System Administrator URL: http://www.marius.org/ http://www.marius.org/marius.pgp 0xF5D89089 *updated 2001-02-26* It is a natural law. Physics tells us that for every action, there must be an equal and opposite reaction. They hate us, we hate them, they hate us back and so, here we are, victims of mathematics. -- Londo, A Voice in the Wilderness I -- ian j hart -- Marius Strom [EMAIL PROTECTED] Professional Geek/Unix System Administrator URL: http://www.marius.org/ http://www.marius.org/marius.pgp 0xF5D89089 *updated 2001-02-26* It is a natural law. Physics tells us that for every action, there must be an equal and opposite reaction. They hate us, we hate them, they hate us back and so, here we are, victims
Re: nfs installworld failure
Dan Pelleg wrote: ian j hart [EMAIL PROTECTED] writes: horio shoichi wrote: ian j hart wrote: hand copied usr.sbin/stallion/bootcode install -c -o root -g wheel -m 444 2681.sys cdk.sys /usr/libdata/stallion install 2681.sys: Permission denied ***Error code 71 /hand copied mounting src and obj -maproot=0 fixes stable cvsup'd this morning (UK mirror) -- ian j hart A Good Thing has happened for you. The deafult NFS server behavior relieves filesystems from many errors by ubiquitous roots on the lan. I think you miss the point - although it is rather a subtle usage of the English language. maproot fixes the problem in the same way that amputation fixes gangrene. That's what the quotes imply. ie. I shouldn't need to do this. As a point of order, can anyone confirm this behavior? My 0.02 euro - this breaks the release. Confirmed; this happens here too. Chmod-ing the usr.sbin/stallion/bootcode/*.sys files to 444 (as root on the NFS server) fixes this. They were 400 for some reason a quick look at the source and cvs log did not reveal. The commits on 2001/08/30 are probably responsible. Taking a guess at the culprits email address. -- Dan Pelleg -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: UDMA ICRC error reading fsb (?)
Dave Uhring wrote: On Saturday 08 September 2001 08:32 am, ian j hart wrote: Dave Uhring wrote: On Friday 07 September 2001 11:48 pm, Marius Strom wrote: FWIW, I had this error and assumed it was cabling. I've spent the last few hours copying data of what is now a dead disk and putting it back on a new disk. YMMV. On Fri, Sep 07, 2001 at 11:45:28PM +0100, ian j hart wrote: Dave Uhring wrote: On Friday 07 September 2001 17:04, Randall Hopper wrote: Dave Uhring: |On Thursday 06 September 2001 07:43 pm, Randall Hopper wrote: | What do these messages mean? Are CRCs done by the | IDE controller on DMA transfers and they're coming up | wrong? | | ad0s2a: UDMA ICRC error writing fsbn 3283483 of | 396704-396713 (ad0s2 bn 3283483; cn 204 tn 98 sn 49) | retrying | |Your drive is dying. Back it up and replace it. I think you are being a tad premature. There have been plenty of posts on this subject, both on stable and hardware. IIRC none of them were bad disks. Randall, 1) post a copy of dmesg so we can see what hardware you have. 2) measure the cable - M/B to drive. Ok, thanks. But what do these messages mean on a technical level? And could these just as well indicate a marginal cable, bad connector, loose connector, or the other hard drive on the controller being a bit flakey? Randall CRC's (16 bit cyclic redundancy check characters) have been done on controllers since we had to use floppies. The first Winchester drive interface I ever designed back in 1979 had a Fairchild 9401 (IIRC) CRC generator chip on it. The writes are failing. You may have marginal cabling or loose or corroded connectors. If you wish to keep using the drive, replace the cable and in doing so your contacts will also wipe clean. -- ian j hart IDE cables which are somewhat too long can cause many problems with data transfer. However, the cable certainly didn't grow in length overnight. It's a new disk, which may be the problem as some hardware combinations have problems. It's also possible the cable was replaced at the same time. I found the problem was load related (at least at first). Maybe the system is now under a heavier load. Sudden onset of the described problems may be due to corrosion of the cable contacts, but it is most likely due to a drive failure. Most modern drives support S.M.A.R.T. and it would be nice if FreeBSD had a utility to detect the drive's complaints. Perhaps it is in the ports, but my weak eyes have failed to see it. most likely: Would your opinion change if it turns out to be a VIA chipset M/B? See also the Lazarus like Re: ad2s1e: UDMA ICRC error reading fsbn... most likely? No, I use one myself (MSI K7T Pro2 A) with no problems whatsoever. Both IDE drives are IBM-DTLA. But I don't use a SB Live, either ;) IIRC that's an 82C686 - different bug to the 82C586B. There seems to be a reluctance to provide dmesg output, which doesn't help. Off on a tangent here - does tagged queuing work? -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Updating RELENG_4_3
cd /usr/src;make update (CVS) pulls down RELENG_4 not RELENG_4_3. There should at least be a warning in UPDATING. Shouldn't this be a variable in make.conf? thinks out loud Hmm. The -r would mean BRANCH would have to be a numeric or symbolic tag. What if you could do: CVSUPDATEFLAGS= -D yesterday That would fix updating during a commit. Or maybe not. Must find a cvs wizard and ask them if the commit time stamps are atomic. /thinks out loud While I'm on the subject, different output for uname -a would be _really_ useful (4.3-SECURITY?). How else can you tell you have RELENG_4_3? Cheers -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup
Fred Gilham wrote:
The practice I am beginning to follow (and what seems to be the most common
practice) is:
a) cvsup weekly
b) check the -stable list daily for any interesting new merges (AKA MFC's)
c) if I see an new security fixes, or anything that sounds like it would
affect my system in a positive manner, build world.
I used to do something like this. But I finally decided that step a)
is unnecessary, and the cvsup should be folded into step c). Why
cvsup weekly if you're not going to build it? A good reason NOT to is
that most of the time your sources won't match your system,
potentially making it harder to debug your system if you have
problems. Another reason is to not bog down the cvsup servers.
Not to mention the fact that you cannot rebuild the kernel until
you {build,install}world. By the principle of an infinite number of
monkeys, you will at some point forget and shoot yourself in the foot.
A local copy of the source repository is the answer to everything(TM).
Useful^n.
My 0.02 euro, don't update source tree without build world.
--
Fred Gilham [EMAIL PROTECTED]
[My tutors] got bored sooner than I, and laid down a general rule
that all statements about languages had to be in a higher level
language. I thereupon asked in what level of language that rule was
formulated. I got a very bad report.-- J. R. Lucas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
--
ian j hart
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: make installworld
Jose Marques wrote: It may be something I did wrong but "make installworld" failed for me this afternoon. The error is: No, it's broken again You're lucky, I'm trying to make release ;-( === games/wargames install -c -o root -g games -m 555 wargames.sh /usr/games/wargames install: wargames.sh: No such file or directory *** Error code 71 Stop. *** Error code 1 etc... Quick fix: cd /usr/src/games/wargames/ cp wargames.sh /usr/obj/usr/src/games/wargames/ and "make installworld" again. Revision 1.7 fixes this - doesn't seem to apply to stable though. Ho Hum! I am running FreeBSD 3.4-Stable and ran CVSup just before the "make buildworld". -- Jose Marques To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message ian j hart - up very late, and rather stressed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Buildworld fails 20000212
The addition of a manpage for games/wargames seems to be broken for stable. Current is okay though. Here is the error message. make: don't know how to make wargames.6. Stop cvsup today feb 12th 2000 ~17:00 GMT ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Roasting Newbies
Thought for the day: From little Newbies do mighty Gurus grow. Some positive stuff on the list for a change; about time. What I cannot understand is why anyone is suprised that stable recieves _inappropriate_ mail. If you track stable you are _REQUIRED_ to subscribe to _THIS_ mailing list. (Yes I am shouting, sorry). My understanding of human nature says this is where any questions are going to get posted. Perhaps something (less dry) in the subscription acknowledgement might help. Justin Wolf is right on track. Ask yourself, why is Linux getting such a lot of press? It's reached critical mass in terms of number of users, thats why. FreeBSD can be the best O/S ever, but if people (aka. Newbies) don't use it, it may not survive. If you/we are going to provide basic help for newbies (myself included), it needs to be friendlier than man. HTML or even info would be better (IMHO). It might also be worth aliasing "help". Before you all run away screaming, I'm suggesting that a level of indirection is useful. This week help might mean man newbie. Next week it could mean info newbie, or whatever. Keeping the user inferface the same is _a_good_thing_. A Friday night Saturday morning ian j hart. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
