Re: ZFS - hot spares : automatic or not?
On 1/11/2011 11:10 AM, John Hawkes-Reed wrote: On 11/01/2011 03:38, Dan Langille wrote: On 1/4/2011 11:52 AM, John Hawkes-Reed wrote: On 04/01/2011 03:08, Dan Langille wrote: Hello folks, I'm trying to discover if ZFS under FreeBSD will automatically pull in a hot spare if one is required. This raised the issue back in March 2010, and refers to a PR opened in May 2009 * http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007943.html * http://www.freebsd.org/cgi/query-pr.cgi?pr=134491 In turn, the PR refers to this March 2010 post referring to using devd to accomplish this task. http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055686.html Does the above represent the the current state? I ask because I just ordered two more HDD to use as spares. Whether they sit on the shelf or in the box is open to discussion. As far as our testing could discover, it's not automatic. I wrote some Ugly Perl that's called by devd when it spots a drive-fail event, which seemed to DTRT when simulating a failure by pulling a drive. Without such a script, what is the value in creating hot spares? We went through that loop in the office. We're used to the way the Netapps work here, where often one's first notice of a failed disk is a visit from the courier with a replacement. (I'm only half joking) In the end, writing enough perl to swap in the spare disk made much more sense than paging the relevant admin on disk-fail and expecting them to be able to type straight at 4AM. Our thinking is that having a hot spare allows us to do the physical disk-swap in office hours, rather than (for instance) running in a degraded state over a long weekend. If it's of interest, I'll see if I can share the code. I think this very much of interest. :) -- Dan Langille - http://langille.org/ ___ 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: tmpfs is zero bytes (no free space), maybe a zfs bug?
On 19 January 2011 16:02, Kostik Belousov wrote: >> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch >> >> I don't think this is a complete solution but it's a start. If you can, >> try it and see if it helps. > This is not a start, and actually a step in the wrong direction. > Tmpfs is wrong now, but the patch would make the wrongness even bigger. > > Issue is that the current tmpfs calculation should not depend on the > length of the inactive queue or the amount of free pages. This data only > measures the pressure on the pagedaemon, and has absolutely no relation > to the amount of data that can be put into anonymous objects before the > system comes out of swap. > > vm_lowmem handler is invoked in two situations: > - when KVA cannot satisfy the request for the space allocation; > - when pagedaemon have to start the scan. > None of the situations has any direct correlation with the fact that > tmpfs needs to check, that is "Is there enough swap to keep all my > future anonymous memory requests ?". > > Might be, swap reservation numbers can be useful to the tmpfs reporting. > Also might be, tmpfs should reserve the swap explicitely on start, instead > of making attempts to guess how much can be allocated at random moment. Thank you for your explanation! I'm still not very familiar with VM and VFS. Could you also read my report at http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html ? I'm curious about the fact that there is lots of 'free' memory here in the same situation. Do you think that there is something which can be done as a band-aid without a major modification to tmpfs? ___ 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: usb errors with 8 stable
Final verdict... loose usb connection in laptop. Cracked board was breaking connection for both usb ports. Sorry for the noise. > > On Jan 5, 2011 12:38 AM, "Jeremy Chadwick" wrote: > > On Tue, Jan 04, 2011 at 11:37:48PM -0600, Beach Geek wrote: > > Compaq Presario 5xxx 2GHz > FreeBSD 8 ... > > I would start by reviewing the commits for RELENG_8 between the two > timeframes and try to nar... ___ 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: Keyboard repeat issues with Dell Optiplex 980s
On Wednesday 19 January 2011 15:51:41 Steve Polyack wrote: > On 01/19/11 08:48, Steve Polyack wrote: > > On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: > >> On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: > >>> We've recently upgraded a few desktop workstations from Dell > >>> Optiplex 960s to Optiplex 980s. We were running FreeBSD > >>> 8.1-RELEASE. The migration was performed by simply swapping the > >>> drives into the new systems. Immediately after switching people > >>> over, they all began to report bizarre keyboard issues - things like > >>> infinite key repeats (letters, numbers, "enter") for keys they did > >>> not hold down. The key repeats continue indefinitely until another > >>> key is pressed. Occasionally, even mouse input will trigger similar > >>> infinite keyboard input repetition. In addition to the repeat > >>> issue, sometimes physical key-presses are not registered by FreeBSD, > >>> leading to typos and angry developers. > >>> > >>> We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these > >>> systems, and the issue persists. Because of the observed behavior, > >>> I'm thinking that this is due to new hardware in the 980s which > >>> isn't timing or handling interrupts correctly under the FreeBSD > >>> kernel. > >>> > >>> Looking at a 'pciconf -lvb' from each system, I noticed that the 980 > >>> has two USB controllers which probe under ehci(4), while the 960 > >>> (which does not exhibit this problem), enumerates six uhci(4) > >>> controllers and two ehci(4) controllers. To cut to the chase here, > >>> the 960 users' keyboards probe under a USB1.0 uhci(4), while the > >>> 980s only have ehci(4) devices to attach to. > >>> > >>> So, I guess what I'm asking is - has anyone else seen any keyboard > >>> repeat or other USB craziness with ehci(4) ports or otherwise Intel > >>> PCH controllers?Any fellow Optiplex 980 users? I'd be more than > >>> happy to provide pciconf or other output if requested. > >> > >> Try adding the following to /boot/loader.conf then reboot and see if > >> the "excessive repeat" behaviour changes: > >> > >> hint.kbdmux.0.disabled="1" > >> > >> It would also help if you would state exactly what brand/model of > >> keyboard is used. Yes, believe it or not, it matters. dmesg output > >> would be helpful in this case. > > > > The keyboard is also a Dell model - model KB1421, or listed as "Dell > > QuiteKey Keyboard" under dmesg. The same keyboard does not exhibit > > the strange behavior when used with the older model of tower (Optiplex > > 960). > > > > I'll reboot today with the loader.conf hint you provided. I'll let > > > > you guys know if it helps. Thanks! > > The problem still exists with the kbdmux.0.disabled hint. It definitely > took effect, as there is no longer a /dev/kbdmux0, and dmesg lists the > refusal to register the kbdmux module. Any other ideas? We've tried > playing with the hw.usb.ehci.lostinrbug and hw.usb.ehci.no_hs sysctls, > but they don't make a difference either. > > Looking at the ehci(4) man page, this sticks out at me: > BUGS > The driver is not finished and is quite buggy. > > There is currently no support for isochronous transfers. For FreeBSD 8+ this is not true. Probably the manpage has not been updated. Hence you are seeing a different number of UHCI controllers, this looks like an ACPI problem. USB keyboards usually require a UHCI to enumerate. The EHCI can only enumerate High Speed devices. --HPS ___ 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: tmpfs is zero bytes (no free space), maybe a zfs bug?
On Wed, Jan 19, 2011 at 11:39:41AM +0100, Ivan Voras wrote: > On 19/01/2011 11:09, Attila Nagy wrote: > >On 01/19/11 09:46, Jeremy Chadwick wrote: > >>On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: > >>>I first noticed this problem on machines with more memory (32GB > >>>eg.), but now it happens on 4G machines too: > >>>tmpfs 0B 0B 0B > >>>100% /tmp > >>>FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 > >>>22:11:54 CET 2011 > >>> > >>>Maybe it's related, that I use zfs on these machines... > >>> > >>>Sometimes it grows and shrinks, but generally there is no space even > >>>for a small file, or a socket to create. > >>http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html > >> > >> > >Oh crap. :( > > > >I hope somebody can find the time to look into this, it's pretty > >annoying... > > http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch > > I don't think this is a complete solution but it's a start. If you can, > try it and see if it helps. This is not a start, and actually a step in the wrong direction. Tmpfs is wrong now, but the patch would make the wrongness even bigger. Issue is that the current tmpfs calculation should not depend on the length of the inactive queue or the amount of free pages. This data only measures the pressure on the pagedaemon, and has absolutely no relation to the amount of data that can be put into anonymous objects before the system comes out of swap. vm_lowmem handler is invoked in two situations: - when KVA cannot satisfy the request for the space allocation; - when pagedaemon have to start the scan. None of the situations has any direct correlation with the fact that tmpfs needs to check, that is "Is there enough swap to keep all my future anonymous memory requests ?". Might be, swap reservation numbers can be useful to the tmpfs reporting. Also might be, tmpfs should reserve the swap explicitely on start, instead of making attempts to guess how much can be allocated at random moment. pgptpHEpyasZg.pgp Description: PGP signature
Re: Keyboard repeat issues with Dell Optiplex 980s
On 01/19/11 08:48, Steve Polyack wrote: On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, "enter") for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the "excessive repeat" behaviour changes: hint.kbdmux.0.disabled="1" It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. The keyboard is also a Dell model - model KB1421, or listed as "Dell QuiteKey Keyboard" under dmesg. The same keyboard does not exhibit the strange behavior when used with the older model of tower (Optiplex 960). I'll reboot today with the loader.conf hint you provided. I'll let you guys know if it helps. Thanks! The problem still exists with the kbdmux.0.disabled hint. It definitely took effect, as there is no longer a /dev/kbdmux0, and dmesg lists the refusal to register the kbdmux module. Any other ideas? We've tried playing with the hw.usb.ehci.lostinrbug and hw.usb.ehci.no_hs sysctls, but they don't make a difference either. Looking at the ehci(4) man page, this sticks out at me: BUGS The driver is not finished and is quite buggy. There is currently no support for isochronous transfers. ___ 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: Keyboard repeat issues with Dell Optiplex 980s
On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, "enter") for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the "excessive repeat" behaviour changes: hint.kbdmux.0.disabled="1" It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. The keyboard is also a Dell model - model KB1421, or listed as "Dell QuiteKey Keyboard" under dmesg. The same keyboard does not exhibit the strange behavior when used with the older model of tower (Optiplex 960). I'll reboot today with the loader.conf hint you provided. I'll let you guys know if it helps. Thanks! ___ 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: Keyboard repeat issues with Dell Optiplex 980s
On 01/19/11 08:48, Steve Polyack wrote: On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, "enter") for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the "excessive repeat" behaviour changes: hint.kbdmux.0.disabled="1" It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. The keyboard is also a Dell model - model KB1421, or listed as "Dell QuiteKey Keyboard" under dmesg. The same keyboard does not exhibit the strange behavior when used with the older model of tower (Optiplex 960). I'll reboot today with the loader.conf hint you provided. I'll let you guys know if it helps. Thanks! I forgot to attach my dmesg - here it is! Copyright (c) 1992-2011 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 8.2-RC2 #1: Mon Jan 17 12:10:53 EST 2011 root@galvatron:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4082315264 (3893 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 3.0 on pci0 pci1: on pcib1 vgapci0: port 0xdc80-0xdcff mem 0xf600-0xf6ff,0xe000-0xefff,0xf000-0xf1ff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] hdac0: mem 0xf7dfc000-0xf7df irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pci0: at device 8.0 (no driver attached) pci0: at device 8.1 (no driver attached) pci0: at device 8.2 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) em0: port 0xecc0-0xecdf mem 0xf7fe-0xf7ff,0xf7fdc000-0xf7fdcfff irq 21 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 84:2b:2b:a5:d0:45 ehci0: mem 0xf7fdd000-0xf7fdd3ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 hdac1: mem 0xff87c000-0xff87 irq 16 at device 27.0 on pci0 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] pcib2: irq 16 at
Gpart and gmirror 8.2 from 18 januari
Hello all, i used to have disk configured with gpart and gmirror. But with the latest 8.2, my server will not boot anymore if i label the disk with gmirror. Gpart status Name Status Components ad4p1 OK ad4 Then gpart list ad4 Geom name: ad4 state: OK fwheads: 16 fwsectors: 63 last: 488397134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad4p1 Mediasize: 65536 (64K) Sectorsize: 512 Mode: r0w0e0 rawuuid: 91d53f12-bf3b-11df-a74d-18a905477e61 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ad4p2 Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e1 rawuuid: b2266ed2-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 2147483648 offset: 82944 type: freebsd-ufs index: 2 end: 4194465 start: 162 3. Name: ad4p3 Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e0 rawuuid: cf4a2a91-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: (null) length: 4294967296 offset: 2147566592 type: freebsd-swap index: 3 end: 12583073 start: 4194466 4. Name: ad4p4 Mediasize: 21474836480 (20G) Sectorsize: 512 Mode: r1w1e1 rawuuid: d980f19c-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 21474836480 offset: 6442533888 type: freebsd-ufs index: 4 end: 54526113 start: 12583074 5. Name: ad4p5 Mediasize: 10737418240 (10G) Sectorsize: 512 Mode: r1w1e1 rawuuid: e11bebff-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 10737418240 offset: 27917370368 type: freebsd-ufs index: 5 end: 75497633 start: 54526114 6. Name: ad4p6 Mediasize: 211404544512 (197G) Sectorsize: 512 Mode: r1w1e1 rawuuid: e70a8e2a-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 211404544512 offset: 38654788608 type: freebsd-ufs index: 6 end: 488397134 start: 75497634 Consumers: 1. Name: ad4 Mediasize: 250059350016 (233G) Sectorsize: 512 Mode: r5w5e9 Then i do a gmirror label -v -b load gm0 /dev/ad4 Edit /etc/fstab And change /dev/ad4px to /dev/mirror/gm0px I reboot, and it hangs when tring to Mount the root device. I get an error about an corrupt gpt label. I can correct this with the fixit option from the live cd If i do gpart status from the live cd i get Name Status Components ad4p1 CORRUPT ad4 ufsid/4b9545d7d72d5019p1 CORRUPT ufsid/4b9545d7d72d5019 if a do a gpart list from the fixit cd i get Geom name: ad4 state: CORRUPT fwheads: 16 fwsectors: 63 last: 488397134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad4p1 Mediasize: 65536 (64K) Sectorsize: 512 Mode: r0w0e0 rawuuid: 91d53f12-bf3b-11df-a74d-18a905477e61 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ad4p2 Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r0w0e0 rawuuid: b2266ed2-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 2147483648 offset: 82944 type: freebsd-ufs index: 2 end: 4194465 start: 162 3. Name: ad4p3 Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r0w0e0 rawuuid: cf4a2a91-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: (null) length: 4294967296 offset: 2147566592 type: freebsd-swap index: 3 end: 12583073 start: 4194466 4. Name: ad4p4 Mediasize: 21474836480 (20G) Sectorsize: 512 Mode: r0w0e0 rawuuid: d980f19c-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 21474836480 offset: 6442533888 type: freebsd-ufs index: 4 end: 54526113 start: 12583074 5. Name: ad4p5 Mediasize: 10737418240 (10G) Sectorsize: 512 Mode: r0w0e0 rawuuid: e11bebff-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 10737418240 offset: 27917370368 type: freebsd-ufs index: 5 end: 75497633 start: 54526114 6. Name: ad4p6 Mediasize: 211404544512 (197G) Sectorsize: 512 Mode: r0w0e0 rawuuid: e70a8e2a-bf3b-11df-a74d-18a905477e61 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 211404544512 offset: 38654788608 type: freebsd-ufs index: 6 end: 488397134 start: 75497634 Consumers: 1. Name: ad4 Mediasize: 250059350016 (233G) Sec
Re: tmpfs is zero bytes (no free space), maybe a zfs bug?
On 19/01/2011 11:09, Attila Nagy wrote: On 01/19/11 09:46, Jeremy Chadwick wrote: On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: I first noticed this problem on machines with more memory (32GB eg.), but now it happens on 4G machines too: tmpfs 0B 0B 0B 100% /tmp FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 22:11:54 CET 2011 Maybe it's related, that I use zfs on these machines... Sometimes it grows and shrinks, but generally there is no space even for a small file, or a socket to create. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html Oh crap. :( I hope somebody can find the time to look into this, it's pretty annoying... http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch I don't think this is a complete solution but it's a start. If you can, try it and see if it helps. ___ 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: tmpfs is zero bytes (no free space), maybe a zfs bug?
On 01/19/11 09:46, Jeremy Chadwick wrote: On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: I first noticed this problem on machines with more memory (32GB eg.), but now it happens on 4G machines too: tmpfs 0B 0B 0B 100%/tmp FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 22:11:54 CET 2011 Maybe it's related, that I use zfs on these machines... Sometimes it grows and shrinks, but generally there is no space even for a small file, or a socket to create. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html Oh crap. :( I hope somebody can find the time to look into this, it's pretty annoying... ___ 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-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
On 19.01.2011 15:00, Lev Serebryakov wrote: > Hello, Eugene. > You wrote 19 января 2011 г., 11:44:01: > >> There is known instability in em(4) driver in 8.2-RELEASE, >> it may panic due to some lack of NULL pointer checks. >> You should update to RELENG_8 containting fix and retest. > uname -v > FreeBSD 8.2-PRERELEASE #5: Sat Jan 8 14:38:46 MSK 2011 > > It is built about hour after cvsup. Yes, I've missed it's PRERELEASE already. Backtrace points to the problem in em_local_timer() fixed in CURRENT 7 days ago, take a look: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c#rev1.65 I run my servers with this commit backported manually as it has not been MFC'd yet. Eugene Grosbein ___ 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-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
Hello, Eugene. You wrote 19 января 2011 г., 11:44:01: > There is known instability in em(4) driver in 8.2-RELEASE, > it may panic due to some lack of NULL pointer checks. > You should update to RELENG_8 containting fix and retest. uname -v FreeBSD 8.2-PRERELEASE #5: Sat Jan 8 14:38:46 MSK 2011 It is built about hour after cvsup. -- // Black Lion AKA Lev Serebryakov ___ 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: tmpfs is zero bytes (no free space), maybe a zfs bug?
On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: > I first noticed this problem on machines with more memory (32GB > eg.), but now it happens on 4G machines too: > tmpfs 0B 0B 0B > 100%/tmp > FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 > 22:11:54 CET 2011 > > Maybe it's related, that I use zfs on these machines... > > Sometimes it grows and shrinks, but generally there is no space even > for a small file, or a socket to create. http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
On 19.01.2011 03:12, Lev Serebryakov wrote: > Hello, Freebsd-stable. > > > One of my servers crashes about once a week, with always same > diagnostics: "kernel trap 12 with interrupts disabled" and in same > process: "swi4: clock" > > It doesn't look as memory failure, as memtest86+ can not find any > errors in 8 passes. > > Also, after this crash server refuse to auto-reboot, last message on > console is "cpu_reset: Stopping other CPUs", and it hangs. > > Kernel config, booting dmesg & results of "savecore" are attached > (bzipped). There is known instability in em(4) driver in 8.2-RELEASE, it may panic due to some lack of NULL pointer checks. You should update to RELENG_8 containting fix and retest. Eugene Grosbein ___ 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"
tmpfs is zero bytes (no free space), maybe a zfs bug?
Hi, I first noticed this problem on machines with more memory (32GB eg.), but now it happens on 4G machines too: tmpfs 0B 0B 0B 100% /tmp FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 22:11:54 CET 2011 Maybe it's related, that I use zfs on these machines... Sometimes it grows and shrinks, but generally there is no space even for a small file, or a socket to create. ___ 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-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
Hello, Jeremy. You wrote 19 января 2011 г., 0:46:54: > CC'ing Jack Vogel of Intel, as this looks like it could be something the > em(4) driver might be tickling. I do see it in the stack trace shortly > before the crash. In the interim, can you please provide output from the > following command: > # pciconf -lbcv > And include only the entries relevant to your emX devices. em0@pci0:0:25:0:class=0x02 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfea4, size 131072, enabled bar [14] = type Memory, range 32, base 0xfea79000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 09[e0] = vendor (length 6) Intel cap 2 version 0 It is on-board LAN on Q35-based MoBo (ASUS P5E-VM DO) > As for the "the server refuses to auto-reboot": that may be a separate > problem. You might try toggling the hw.acpi.disable_on_reboot and > hw.acpi.handle_reboot sysctls (check what values they have on your > system first) to see if there's any improvement. Both are zero. BTW, manual reboots (reboot && shutdown -r now) and shutdowns (shutdown -p now) works perfectly Ok. -- // Black Lion AKA Lev Serebryakov ___ 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-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
Hello, Eugene. You wrote 19 января 2011 г., 0:30:09: > You have not mentioned what tasks does it perform. Storage of all my data with software RAID5 + torrent-box for 25Mibt/s connection/ -- // Black Lion AKA Lev Serebryakov ___ 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"
