whats best pracfive for ZFS on a whole disc these days ?
just about to build a new ZFS based system and I was wondering what the recommended way to dedicate a whole disc to ZFS is these days. Should I just give it 'da1', 'da2' etc as I have done in the past, or is it better to use GPT to create a partition over the whole disc, which is marked as being for freebsd-zfs ? Not that I have had any problems with simply using bare drives, but the phrase 'dangerously dedicated' does keep nagging at me, hence considering the GPT route :-) cheers, -pete. ___ 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"
Modbus Serial - Modbus TCP/IP
This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. ___ 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: Possible scheduler (SCHED_ULE) bug?
Jaime Bozza a écrit : The additional information I have (over the PR) is that: 1) Files over 64K cause the problem, not just larger files I thought it was over 1 MB or so. But maybe I'm wrong. ISTR that I couldn't trigger it with some images of around 70K. I discovered it originally with a 72K file. After some tests, I found a 63K file worked and a 65K file didn't. When I get back into the office, I can test the actual boundary (65535, 65536, 65537, etc), but 64K seems pretty logical. 2) switching over to SCHED_4BSD eliminates the problem - system no longer locks. I will have to test this. This is indeed interesting... 3) 7.2 amd64 doesn't have the problem - Tested a similar configuration and was not able to duplicate on amd64 at all. I can replicate this problem on FreeBSD 7.2/amd64 reliably. I haven't tried larger files - Maybe the boundary is different on amd64? Doing some quick tests right now, I was able to upload a 100MB file without a problem, but this is an AMD64 system with SMP, plus the filesystem is all ZFS, so there are too many things different. I'll have to setup a system that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I can say I'm not having a problem there. Jaime I had the same issue using 7.1 amd64, with ZFS, no SMP. Not really sure what is the size boundary. I can't really test either, as the machine is remote. But I confirm that each tentative upload of certain relatively 'big' files (around 1MB) with wordpress hanged the system before I switched from sendfile to writev. I might do some test on amd64 7.2 with no SMP if it can be of any use ? Arnaud ___ 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: Possible scheduler (SCHED_ULE) bug?
Arnaud Houdelette wrote: > I had the same issue using 7.1 amd64, with ZFS, no SMP. > Not really sure what is the size boundary. I can't really test either, > as the machine is remote. > But I confirm that each tentative upload of certain relatively 'big' > files (around 1MB) with wordpress hanged the system before I switched > from sendfile to writev. > > I might do some test on amd64 7.2 with no SMP if it can be of any use ? > > Arnaud I can confirm it happens without SMP on 7.2 and amd64. If you can give it a try though, well, the more information the better. Any boundary information, even approximate (well, mostly testing if 64K is the boundary or if 1 MB or so is) would probably be good, too. -- Jacob Myers | Website: http://whotookspaz.org Network Admin, Wilcox Technologies | Public key: 186A424A Using FreeBSD since 2007| Public shell: http://bit.ly/42iGCR Answer a fool according to his folly, lest he be wise in his own conceit -- Proverbs, 26:5 signature.asc Description: OpenPGP digital signature
NULL-pointer reference in ulpt
I didn't get any replies to my previous report, so I'm trying again. I frequently get a kernel-panic after printing something to my USB printer (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a NULL-pointer for xfer from ulpt_tick(). System is a 7.2-STABLE, last updated on Sep 15. I just did a make update, but there were no changes to ulpt.c. The core-summary is available from http://solfertje.student.utwente.nl/~dalroi/core.txt Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4ae5a9e512191499454227! ___ 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 and SATA Port Multipliers
Alexander Motin wrote: Steve Polyack wrote: Alexander Motin wrote: You can try this patch against today's HEAD: http://people.freebsd.org/~mav/cam-ata.20091022.patch I tried the patch this morning against a fresh checkout of HEAD. Immediately after boot only one device per PM was detected (I have two hooked up at the moment, 5 drives on one, 1 on the other). However, about two minutes later all of the drives showed up! camcontrol also rescans the entire bus *very* quickly now, and discovers all changes (new/missing disks and port multipliers). Here's some verbose info from /var/log/messages immediately after boot: Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is ss 0800 rs 0800 es sts 801b2000 serr Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout status=0001 Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested What was before that? Can you send me full verbose boot messages? Here's a full dmesg from today using the 10/22/2009 head and patch. It actually failed to detect all but one of 6 drives this time. I'm about to try today's head and patch. I'll let you know how it goes. 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 9.0-CURRENT #2: Thu Oct 22 10:34:44 EDT 2009 Preloaded elf kernel "/boot/kernel/kernel" at 0x809e7000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x809e7260. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133421704 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x1000 - 0x00093fff, 602112 bytes (147 pages) 0x00a16000 - 0xb60f, 3043926016 bytes (743146 pages) 0xbf78e000 - 0xbf78, 8192 bytes (2 pages) 0x0001 - 0x00013ffe, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: <061909 APIC1420> INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 0097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 0097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 0097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 0097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 0097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 0097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 0097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 0097) ACPI: DMAR 0xbf79e0c0 00120 (v1AMI OEMDMAR 0001 MSFT 0097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 0097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 0097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 0097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 0097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LI
RE: Possible scheduler (SCHED_ULE) bug?
From: Jacob Myers [mailto:ja...@whotookspaz.org] > Arnaud Houdelette wrote: > > I had the same issue using 7.1 amd64, with ZFS, no SMP. > > Not really sure what is the size boundary. I can't really test > either, > > as the machine is remote. > > But I confirm that each tentative upload of certain relatively 'big' > > files (around 1MB) with wordpress hanged the system before I switched > > from sendfile to writev. > > > > I might do some test on amd64 7.2 with no SMP if it can be of any use > ? > > > > Arnaud > > I can confirm it happens without SMP on 7.2 and amd64. If you can give > it a try though, well, the more information the better. Any boundary > information, even approximate (well, mostly testing if 64K is the > boundary or if 1 MB or so is) would probably be good, too. I haven't tested the specific boundaries yet, but I will do that shortly. I *was* able to get a crash dump on the i386 system - Will post the details shortly. My amd64 system is a test system with ZFS, so I couldn't get a crash dump. Trying to work around that. On both systems, I used a 72K file (73,688 bytes) to test. Both systems would "lock up", and then a few seconds later kdb would come up. It wasn't an immediate thing, at least not on the i386 system. I wasn't able to watch the amd64 system since it's too far away to time. Jaime ___ 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 and SATA Port Multipliers
Steve Polyack wrote: > I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 -- Alexander Motin ___ 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: Possible scheduler (SCHED_ULE) bug?
Sincerely, Jaime Bozza MindSites Group, LLC From: Dylan Cochran [mailto:heliocent...@gmail.com] > Superficially, this seams identical to a deadlock I reported for > 7.1-RC1. Would you mind compiling a kernel with these options: > > > KDB: stack backtrace: > db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 > hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 > lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c > Xtimerint() at Xtimerint+0x1f > --- interrupt, eip = 0xc07ff29d, esp = 0xe66e0b48, ebp = 0xe66e0c34 --- > kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d > do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at > do_sendfile+0xb1 > sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 > syscall(e66e0d38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = > 0xbfbfc7cc, ebp = 0xbfbfe848 --- > KDB: enter: watchdog timeout > > You can type 'reboot' to reboot the machine (in my case, panic would > not work, so a useful dump wasn't in the cards) Different offset on mine, but of course I'm using a different kernel. kern_sendfile+0x6ad do_sendfile+0xb1 sendfile+0x13 Luckily, I was able to get a panic, so I have all the files necessary to debug. Here's the backtrace: (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc07f2c57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07f2f62 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0497e47 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:446 #4 0xc04985bc in db_command (last_cmdp=0xc0ca9154, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xc04986ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xc049a17d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc081fdf6 in kdb_trap (type=3, code=0, tf=0xc72e2a5c) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xc0b01b9b in trap (frame=0xc72e2a5c) at /usr/src/sys/i386/i386/trap.c:692 #9 0xc0ae58fb in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc081ff7a in kdb_enter_why (why=0xc0b677b2 "watchdog", msg=0xc0b7ef1d "watchdog timeout") at cpufunc.h:60 #11 0xc07b0cad in hardclock (usermode=0, pc=3229966301) at /usr/src/sys/kern/kern_clock.c:640 #12 0xc0aedf1c in lapic_handle_timer (frame=0xc72e2afc) at /usr/src/sys/i386/i386/local_apic.c:785 #13 0xc0ae5edf in Xtimerint () at apic_vector.s:108 #14 0xc0855fdd in kern_sendfile (td=0xc771db40, uap=0xc72e2cfc, hdr_uio=0x0, trl_uio=0x0, compat=0) at atomic.h:160 #15 0xc0856d31 in do_sendfile (td=0xc771db40, uap=0xc72e2cfc, compat=0) at /usr/src/sys/kern/uipc_syscalls.c:1775 #16 0xc0856dd3 in sendfile (td=0xc771db40, uap=0xc72e2cfc) at /usr/src/sys/kern/uipc_syscalls.c:1746 #17 0xc0b01365 in syscall (frame=0xc72e2d38) at /usr/src/sys/i386/i386/trap.c:1094 #18 0xc0ae5960 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #19 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) This is all a bit new to me (debugging, etc), so let me know if you need anything else! Jaime ___ 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: Possible scheduler (SCHED_ULE) bug?
From: Kostik Belousov [mailto:kostik...@gmail.com]
> Can you look up the source line for kern_sendfile+0x90d in your
> kernel ? Do kgdb kernel.debug, then execute "list *(kern_sendfile+0x90d)".
In my case, it was kern_sendfile+0x6ad (rebuilt with RELENG_7 this weekend).
Here's the output:
(kgdb) list *(kern_sendfile+0x6ad)
0xc0855fdd is in kern_sendfile (atomic.h:160).
155 static __inline int
156 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
157 {
158 u_char res;
159
160 __asm __volatile(
161 " " MPLOCKED ""
162 " cmpxchgl %2,%1 ;"
163 " sete%0 ;"
164 "1: "
Not much to go on there. I posted a backtrace in a previous email, but the
relevant sections (I think) are:
#14 0xc0855fdd in kern_sendfile (td=0xc771db40, uap=0xc72e2cfc, hdr_uio=0x0,
trl_uio=0x0, compat=0) at atomic.h:160
#15 0xc0856d31 in do_sendfile (td=0xc771db40, uap=0xc72e2cfc, compat=0) at
/usr/src/sys/kern/uipc_syscalls.c:1775
#16 0xc0856dd3 in sendfile (td=0xc771db40, uap=0xc72e2cfc) at
/usr/src/sys/kern/uipc_syscalls.c:1746
#17 0xc0b01365 in syscall (frame=0xc72e2d38) at
/usr/src/sys/i386/i386/trap.c:1094
#18 0xc0ae5960 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262
#19 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
I'm still going to test the specific boundary, but if there's more information
I can give, let me know!
Jaime
___
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: MCP55 SATA solution to test
2009/10/25 Alexander Motin : > Hi. > > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. > > Attached patch solves problem for that machine. Testers are welcome. Confirmed this also fixes the SATA detection on my MSI K9N Neo on 9.0-CURRENT. Please commit :) ___ 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 and SATA Port Multipliers
Alexander Motin wrote: Steve Polyack wrote: I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 Here's a dmesg from todays head and your patch from this morning. It's still only sensing one disk over the two PMs. Forcing SATA1/1.5Gbps operation didn't change anything. 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 9.0-CURRENT #4: Mon Oct 26 10:01:55 EDT 2009 Preloaded elf kernel "/boot/kernel/kernel" at 0x809e7000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x809e7260. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133419836 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x1000 - 0x00093fff, 602112 bytes (147 pages) 0x00a16000 - 0xb60f, 3043926016 bytes (743146 pages) 0xbf78e000 - 0xbf78, 8192 bytes (2 pages) 0x0001 - 0x00013ffe, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: <061909 APIC1420> INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 0097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 0097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 0097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 0097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 0097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 0097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 0097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 0097) ACPI: DMAR 0xbf79e0c0 00120 (v1AMI OEMDMAR 0001 MSFT 0097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 0097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 0097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 0097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 0097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x1000 VER: 0x00060015 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001000f pcm: 0x00010400 nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 ACPI timer: 1/1 1/0 1/0 1/2 0/459 1/2 1/0 1/0 1/0 1/0 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0:Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1:Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Val
Re: FreeBSD and SATA Port Multipliers
Steve Polyack wrote: Alexander Motin wrote: Steve Polyack wrote: I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 Here's a dmesg from todays head and your patch from this morning. It's still only sensing one disk over the two PMs. Forcing SATA1/1.5Gbps operation didn't change anything. I should also note that if I do a 'camcontrol rescan', the first PM (with 5 physical drives attached, none detected) will vanish. Physically unplugging and reconnecting the device does the same. COMMAND=/sbin/camcontrol rescan all siisch0: Timeout on slot 29 siisch0: siis_timeout is ss 2000 rs 2000 es sts 801f2000 serr siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=0123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=0001 (aprobe0:siisch0:0:15:0): Command timed out (aprobe0:siisch0:0:15:0): error 5 (aprobe0:siisch0:0:15:0): Retries Exhausted (pass0:siisch0:0:15:0): lost device (pass0:siisch0:0:15:0): removing device entry (pmp0:siisch0:0:15:0): lost device siisch0: Timeout on slot 30 siisch0: siis_timeout is ss 4000 rs 4000 es sts 801f serr siisch0: ready wait time=1ms siisch0: ready wait time=1ms (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=0123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=0001 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command (aprobe0:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 1706 PMP freeze: 0 PM ports: 5 PM RESET 0 skipping PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done PM connect done PM status: 0 - 0123 PM status: 1 - PM status: 2 - PM status: 3 - PM status: 4 - PMP release: 0 ___ 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: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64
>> Hello all
>> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6
>> server.
>> It fails to detect the Broadcom network interface.
>>
>>
>>
>> Pciconf -lv gives me the following.
>>
>> no...@pci0:4:0:0:class=0x02 card=0x705d10c
chip=0x165b14e4
>> rev=0x10
>> hdr=0x00
>>
>> vendor = 'Broadcom Corporation'
>> class= network
>>
>> Subclass = Ethernet
>>
>>
>>
>> Is there something I can do, other than install an other network
card?
>I think you can just patch the bge(4) driver to add support for your
>adapter.
>It looks like a BCM5723 from the PCI ID. Support for it was just added
in
>9.0 as part of change 197832, but I suspect it might not need all the
other
>patches from that change. Try this diff:
>Index: if_bgereg.h
>===
>--- if_bgereg.h(revision 197831)
>+++ if_bgereg.h(revision 197832)
>@@ -2101,6 +2123,7 @@
> #define BCOM_DEVICEID_BCM5720 0x1658
> #define BCOM_DEVICEID_BCM5721 0x1659
> #define BCOM_DEVICEID_BCM5722 0x165A
>+#define BCOM_DEVICEID_BCM5723 0x165B
> #define BCOM_DEVICEID_BCM5750 0x1676
> #define BCOM_DEVICEID_BCM5750M 0x167C
> #define BCOM_DEVICEID_BCM5751 0x1677
>Index: if_bge.c
>===
>--- if_bge.c (revision 197831)
>+++ if_bge.c (revision 197832)
>@@ -170,6 +170,7 @@
> { BCOM_VENDORID,BCOM_DEVICEID_BCM5720 },
> { BCOM_VENDORID,BCOM_DEVICEID_BCM5721 },
> { BCOM_VENDORID,BCOM_DEVICEID_BCM5722 },
>+ { BCOM_VENDORID,BCOM_DEVICEID_BCM5723 },
> { BCOM_VENDORID,BCOM_DEVICEID_BCM5750 },
> { BCOM_VENDORID,BCOM_DEVICEID_BCM5750M },
> { BCOM_VENDORID,BCOM_DEVICEID_BCM5751 },
Like I said in my first answer, the device is detected with these lines.
Only if I enable the device it can not boot.
If I boot with the inserted em0 interface and the change in the rc.conf
file the em0 into bge0 and do a /etc/netstart, the systems hangs, only a
power cycle can reclaim the server.
I have installed FreeBSD 9.0Current on the machine and here it works
fine
I saw a commit from Bjoern A. Zeeb which describe the hang, but do not
know if this can be reverted back to 8.x before the release.
svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb
regards, and thank you for your time.
cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry)
Johan Hendriks
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date:
10/25/09 19:57:00
___
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: whats best pracfive for ZFS on a whole disc these days ?
On Mon, 2009-10-26 at 11:19 +, Pete French wrote: > just about to build a new ZFS based system and I was wondering > what the recommended way to dedicate a whole disc to ZFS is > these days. Should I just give it 'da1', 'da2' etc as I have > done in the past, or is it better to use GPT to create a > partition over the whole disc, which is marked as > being for freebsd-zfs ? > > Not that I have had any problems with simply using bare > drives, but the phrase 'dangerously dedicated' does keep > nagging at me, hence considering the GPT route :-) Others may have different opinions, but if your drives are dedicated to zfs and you don't intend to try and boot from them, I see no reason not to continue giving the whole disk to zfs. robert. > cheers, > > -pete. > ___ > 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" -- Robert Noland FreeBSD ___ 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: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64
On Mon, 26 Oct 2009 15:49:37 +0100 "Johan Hendriks" mentioned: > I saw a commit from Bjoern A. Zeeb which describe the hang, but do not > know if this can be reverted back to 8.x before the release. > > svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb > > regards, and thank you for your time. > cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) > I believe bz's patch should fix it for you. You can either apply it by hand, or disable ASF mode by putting the following into /boot/loader.conf: hw.bge.allow_asf=0 The latter will be off by default in 8.0, but this change was not done by the point when RC1 was branched. It should be disabled by default in RC2 though, when it will be ready. -- Stanislav Sedov ST4096-RIPE pgp8uvkKHR1n9.pgp Description: PGP signature
Re: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64
On Friday 23 October 2009 11:17:33 am Johan Hendriks wrote:
>
> On Thursday 22 October 2009 11:07:23 am Johan Hendriks wrote:
> >> Hello all
> >> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6
> >> server.
> >> It fails to detect the Broadcom network interface.
> >>
> >>
> >>
> >> Pciconf -lv gives me the following.
> >>
> >> no...@pci0:4:0:0:class=0x02 card=0x705d10c
> chip=0x165b14e4
> >> rev=0x10
> >> hdr=0x00
> >>
> >> vendor = 'Broadcom Corporation'
> >> class= network
> >>
> >> Subclass = Ethernet
> >>
> >>
> >>
> >> Is there something I can do, other than install an other network
> card?
>
> >I think you can just patch the bge(4) driver to add support for your
> >adapter.
> >It looks like a BCM5723 from the PCI ID. Support for it was just added
> in
> >9.0 as part of change 197832, but I suspect it might not need all the
> other
> >patches from that change. Try this diff:
>
> >Index: if_bgereg.h
> >===
> >--- if_bgereg.h (revision 197831)
> >+++ if_bgereg.h (revision 197832)
> >@@ -2101,6 +2123,7 @@
> > #define BCOM_DEVICEID_BCM5720 0x1658
> > #define BCOM_DEVICEID_BCM5721 0x1659
> > #define BCOM_DEVICEID_BCM5722 0x165A
> >+#define BCOM_DEVICEID_BCM5723 0x165B
> > #define BCOM_DEVICEID_BCM5750 0x1676
> > #define BCOM_DEVICEID_BCM5750M 0x167C
> > #define BCOM_DEVICEID_BCM5751 0x1677
> >Index: if_bge.c
> >===
> >--- if_bge.c (revision 197831)
> >+++ if_bge.c (revision 197832)
> >@@ -170,6 +170,7 @@
> > { BCOM_VENDORID,BCOM_DEVICEID_BCM5720 },
> > { BCOM_VENDORID,BCOM_DEVICEID_BCM5721 },
> > { BCOM_VENDORID,BCOM_DEVICEID_BCM5722 },
> >+{ BCOM_VENDORID,BCOM_DEVICEID_BCM5723 },
> > { BCOM_VENDORID,BCOM_DEVICEID_BCM5750 },
> > { BCOM_VENDORID,BCOM_DEVICEID_BCM5750M },
> > { BCOM_VENDORID,BCOM_DEVICEID_BCM5751 },
>
>
> Ok done that, and the card is found, only the server is not very stable
> right now.
> It does not continue the boot.
> It stops at setting the hostname
>
> Setting hostname: server01.mydomain.local
>
> And it stays there.
Can you tell what it is doing (with Ctrl-T, or perhaps including ddb and
breaking into ddb and using 'ps')?
--
John Baldwin
___
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: Possible scheduler (SCHED_ULE) bug?
From: Arnaud Houdelette [mailto:arnaud.houdele...@tzim.net] > I haven't tried larger files - Maybe the boundary is different on amd64? > Doing some quick tests > right now, I was able to upload a 100MB file without a problem, but this is > an AMD64 system with SMP, > plus the filesystem is all ZFS, so there are too many things different. I'll > have to setup a system > that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I > can say I'm not having a > problem there. > > > > Jaime > > > I had the same issue using 7.1 amd64, with ZFS, no SMP. > Not really sure what is the size boundary. I can't really test either, > as the machine is remote. > But I confirm that each tentative upload of certain relatively 'big' > files (around 1MB) with wordpress hanged the system before I switched > from sendfile to writev. > > I might do some test on amd64 7.2 with no SMP if it can be of any use ? > > Arnaud I was able to duplicate the problem on 7.2-STABLE amd64 no SMP - Problem didn't seem to happen with SMP on. While I wasn't able to get a crash dump, the crash looked similar. Jaime ___ 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: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64
>> I saw a commit from Bjoern A. Zeeb which describe the hang, but do not >> know if this can be reverted back to 8.x before the release. >> >> svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb >> >> regards, and thank you for your time. >> cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) >> >I believe bz's patch should fix it for you. You can either apply it >by hand, or disable ASF mode by putting the following into >/boot/loader.conf: >hw.bge.allow_asf=0 >The latter will be off by default in 8.0, but this change was not done by >the point when RC1 was branched. It should be disabled by default in RC2 >though, when it will be ready. On my system sysctl -a | grep hw.bge.allow_asf gives me the value 0 hw.bge.allow_asf: 0 So it is off, I did try the patch from bz but it still hangs. Maybe I did not apply it the right way, because I did it by hand. can you provide me a patch file? Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 ___ 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: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64
>> >> Ok done that, and the card is found, only the server is not very stable >> right now. >> It does not continue the boot. >> It stops at setting the hostname >> >> Setting hostname: server01.mydomain.local >> >> And it stays there. >Can you tell what it is doing (with Ctrl-T, or perhaps including ddb and >breaking into ddb and using 'ps')? I can not do anything. If I boot with a em0 interface, he finds the bge0 interface, but when I activate the driver by changing ifconfig_em0 to ifconfig_bge0 in /etc/rc.conf, and do a /etc/netstart I get the following. devd already running? (pid=703) Setting hostuuid: b032ac21-056a-de11-9e59-19c320fc2231 Setting hosted: 0xe51c1df3 This is it, can not switch consoles, can not use keyboard at all, CAPS is not working anymore. and the health led in front of the server turns from green to flashing red. Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 ___ 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"
8.0-RC2
I just got this via csup, guess we are getting close, excellent. Brian ___ 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: NULL-pointer reference in ulpt
On Mon, 26 Oct 2009 14:51:23 +0100, Alban Hertroys wrote: I didn't get any replies to my previous report, so I'm trying again. I frequently get a kernel-panic after printing something to my USB printer (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a NULL-pointer for xfer from ulpt_tick(). System is a 7.2-STABLE, last updated on Sep 15. I just did a make update, but there were no changes to ulpt.c. The core-summary is available from http://solfertje.student.utwente.nl/~dalroi/core.txt Alban Hertroys Can you try this in 8.0? The USB stack is very different there (and much better in a lot of ways). Ronald. ___ 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: 8.0: glabel on a gjournaled FS is broken
Oliver Lehmann wrote: [glabel with gjournaled device not working] So should I create a PR for that since none responded to that topic? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ 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: Some questions about da0 on USB2 (recent bad behaviour)
On Sat, Oct 24, 2009 at 07:07:00PM +, b. f. wrote: > >That is: it seems to work fine for some fraction of a minute > >(doesn't seem to be longer than a minute, anyway), and then > >stops completely for several minutes (processes reading or > >writing sit in "D" state in ps) and then starts again, after > >logging "Request completed with CAM_REQ_CMP_ERR\nRetrying > >Command". > > In the past week or so, Alexander Motin (m...@freebsd.org) and Andrew > Thompson (thom...@freebsd.org) have made a number of related changes > to cam and usb in the P4 repository, and in 9-CURRENT. Some of these > may address your problem. I'm not sure when they will be back-ported > to 8.X. You may wish to try out the latest version of -CURRENT, to > see if it solves your problem(s); or to contact them. I've done this, and it seems to have worked. It seems possible that the bulk throughput (measured by systat while doing a cat /backup/bigfile >/dev/null) might even have increased a bit, but maybe not. The big improvement is that the transfer isn't pausing any more. No more CAM_REQ_CMP_ERR messages. Thanks b. f. for the suggestion, and thanks Alexander and Andrew for the fixes! I haven't run -current for, probably, ten years, and the occasional messages about lock-order-reversals worry me a bit, but don't seem to be doing any harm. Should I report them? In a PR? Please count this message as a vote for MFC'ing those cam and usb changes to 8-STABLE. Cheers, -- Andrew ___ 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: Some questions about da0 on USB2 (recent bad behaviour)
On 10/26/09, Andrew Reilly wrote: > On Sat, Oct 24, 2009 at 07:07:00PM +, b. f. wrote: ... > > I haven't run -current for, probably, ten years, and the > occasional messages about lock-order-reversals worry me a bit, > but don't seem to be doing any harm. Should I report them? In > a PR? > Some of them are known, and are either harmless or a false positive. If you get an LOR, you can check to see if a similar LOR has already been noted on Bjoern Zeeb's page: http://sources.zabbadoz.net/freebsd/lor.html If it hasn't, send him an email with the LOR, and the circumstances under which it arose, as described on that page. Don't forget that there is a lot of debugging code enabled by default under -CURRENT (which at this point is still pretty close to 8-STABLE, and will be until after the release of 8.0, so it ought to be fairly stable). If you feel confident about the safety of using -CURRENT, and want to get the best performance, disable the debugging code as described in /usr/src/UPDATING. > Please count this message as a vote for MFC'ing those cam and > usb changes to 8-STABLE. > I'm guessing that these changes will make it into 8.0, or at least 8-STABLE, fairly soon; but mav@, thompsa@, and re@ will know more. b. ___ 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"
uart(4) on stable/7
I am interested in using uart(4) instead of sio(4) on stable/7, to ease our eventual transition to stable/8 or CURRENT. I added device uart and changed up /boot/device.hints (there were no entries in /etc/ttys that mentioned sio), and I get something that boots and has messages on the console, up to the login prompt. There's no login prompt, though. I can ssh to my box, echo to /dev/console appears on the console; messages on reboot appear on the console, just not the login prompt. Does anyone know what else I may be missing to use uart(4)? Also, we have some boot scripts locally that will try to set machdep.conspeed based on hardware type; uart(4) doesn't seem to expose a sysctl by that name. How does the uart driver for stable/7 deal with differing console speeds? The hints in /boot/device.hints, obtained by s/sio/uart: hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x90" hint.uart.0.irq="4" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" hint.uart.2.at="isa" hint.uart.2.disabled="1" hint.uart.2.port="0x3E8" hint.uart.2.irq="5" hint.uart.3.at="isa" hint.uart.3.disabled="1" hint.uart.3.port="0x2E8" hint.uart.3.irq="9" Thanks, matthew ___ 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: uart(4) on stable/7
On Mon, Oct 26, 2009 at 02:57:42PM -0700, Matthew Fleming wrote: > I am interested in using uart(4) instead of sio(4) on stable/7, to ease > our eventual transition to stable/8 or CURRENT. I added device uart and > changed up /boot/device.hints (there were no entries in /etc/ttys that > mentioned sio) ... It doesnt mention sio but you do need to change ttyd* to ttyu*, which are the sio and uart tty devices respectively. Andrew ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Mon, October 26, 2009 13:38, Robert Noland wrote: > On Mon, 2009-10-26 at 11:19 +, Pete French wrote: >> just about to build a new ZFS based system and I was wondering >> what the recommended way to dedicate a whole disc to ZFS is >> these days. Should I just give it 'da1', 'da2' etc as I have >> done in the past, or is it better to use GPT to create a >> partition over the whole disc, which is marked as >> being for freebsd-zfs ? >> >> Not that I have had any problems with simply using bare >> drives, but the phrase 'dangerously dedicated' does keep >> nagging at me, hence considering the GPT route :-) > > Others may have different opinions, but if your drives are dedicated to > zfs and you don't intend to try and boot from them, I see no reason not > to continue giving the whole disk to zfs. hear somewhere (current@ or stable@) that this may give hard time in case of disk replacement. I may not find exact the same size and trouble may com from this. never tried though. please correct me if I'm wrong. matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: uart(4) on stable/7
On Oct 26, 2009, at 2:57 PM, Matthew Fleming wrote: I can ssh to my box, echo to /dev/console appears on the console; messages on reboot appear on the console, just not the login prompt. Does anyone know what else I may be missing to use uart(4)? As Andrew pointed put, you need to update /etc/ttys as well. Also, we have some boot scripts locally that will try to set machdep.conspeed based on hardware type; uart(4) doesn't seem to expose a sysctl by that name. How does the uart driver for stable/7 deal with differing console speeds? uart(4) has 2 approaches for this: 1) you don't specify a speed -- in this case uart(4) will simply re-use the speed that hardware is programmed for. 2) You do specify a speed - uart(4) will reprogram the the console speed based on the hw.uart.console tunable. Note that for compatibility with sio(4) hints can be used as well. Use hint.uart.0.baud=9600 to set the console speed to 9600 baud. There's no compiled-in console speed. The compiled-in default (in a way) is to use the speed the hardware is programmed for. -- Marcel Moolenaar xcl...@mac.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"
Re: whats best pracfive for ZFS on a whole disc these days ?
On Mon, 26 Oct 2009, Pete French wrote: > just about to build a new ZFS based system and I was wondering > what the recommended way to dedicate a whole disc to ZFS is > these days. Should I just give it 'da1', 'da2' etc as I have > done in the past, or is it better to use GPT to create a > partition over the whole disc, which is marked as > being for freebsd-zfs ? > > Not that I have had any problems with simply using bare > drives, but the phrase 'dangerously dedicated' does keep > nagging at me, hence considering the GPT route :-) I put GPT's on mine and reserved a few Gb on each so I could swap/dump on them (4Gb on each - overkill but kept them all the same size). Unfortunately it appears ZFS doesn't search for GPT partitions so if you have them and swap the drives around you need to fix it up manually. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: whats best pracfive for ZFS on a whole disc these days ?
> Unfortunately it appears ZFS doesn't search for GPT partitions so if you > have them and swap the drives around you need to fix it up manually. When I used raw disk or GPT partitions, if disk order was changed the pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all that had to be done is export/import the pool. After the pool has been re-imported it was back to ONLINE. Now I'm using GPT labels (gpart -l) specifically because that avoids issues with disk order or driver change. The pool I've built from GPT labels has survived several migrations between different controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX (ahci) and multiple drive permutations without any manual intervention at all. All that was done on 8-RC1/amd64. I have also successfully imported the pool on OpenSolaris and back again on FreeBSD. --Artem ___ 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"
