Re: Many processes stuck in zfs
Quoting Borja Marcos (from Thu, 11 Mar 2010 18:26:09 +0100): Of course CPUs have bugs, I don't doubt it. I was just wondering how I coud reproduce the problem with a different hardware :) That's why I said it was unlikely. Besides, such a low level fault should produce many more problems than such a well defined failure mode, as far as I know. In my case I had a 7.1 system which was running fine. After updating to 7.2 I got deadlocks after some minutes with UFS. Switching to ZFS for the main data partition extended the lifetime to 3-4 hours. After updating ZFS in 7-stable with the code from 8-stable this was extended to 6 hours (periodic daily triggered the problem faster), and after switching to exclusive locks instead of shared locks in ZFS the system survived a night with several jails running periodic daily (but I had to reboot in the morning because apache was not able to serve data anymore). Everything else was working correctly. I would say this was a very narrow problem case. Bye, Alexander. -- Adult, n.: One old enough to know better. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: I broke my SSH to jails after 7.2-8.0 src upgrade
On Thu, Mar 11, 2010 at 08:33:29PM -0800, Garrett Cooper wrote: > I've done a few RELENG_8_0 to STABLE-8 to 9-CURRENT upgrades lately > and mergemaster was goofing up the contents a bit based on the RCS > versions. I had to hand-edit a crapload of stuff going from 8 to 9, > and I still don't trust mergemaster's automatic merging logic because > it goofs up on /etc/group // /etc/passwd still (doesn't merge > anything, discards my info, etc) for starters. > > -a doesn't actually do any merging though, FWIW: [...] I would put in a word for 'mergemaster -F' (or maybe '-iF') in such cases. It doesn't try to automate much, but it allows one to concentrate on actual differences by automating the handling of those files where only the VCS Id is different. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: Jails & 8.0
> Date: Thu, 11 Mar 2010 22:53:43 -0500 > From: st...@ibctech.ca > To: freebsd-stable@freebsd.org > CC: freebsd-j...@freebsd.org > Subject: Jails & 8.0 > > Sorry for the cross-post, but this is a 'thank-you', not a request for help. > > I want to express my sincere appreciation for all of those who made > FreeBSD jails a viable virtual server solution for us who required > multiple IPs, particularly those who demand/require IPv6 support: > > > Not only that, FreeBSD 8 is just absolutely fantastic. Although I've > only been using FreeBSD since 4.3, I never could have dreamt that the OS > would ever have a release that is so close to its core values, but at > the same time so feature rich and stable, particularly for those who > like to use the OS as a network (L2/L3) platform in many cases. > > My hats off. Thanks all! What a tremendous job. > I couldn't agree more: FreeBSD today is really able to bring a tremendous value to a lot of enterprise-grade environments. Coming from a deep Microsoft experience as multi-certified MSFT specialist, I have been playing with FreeBSD since the 6.0-RELEASE, and I must say that FreeBSD is perhaps the best OS when you need to effectively consolidate workloads and administration efforts. The Jail system is simply amazing, and I'm really excited to see how the VIMAGE feature, when it will be released as "producion-ready", will increase even more this value. To meet the always evolving business requirements today, IT pros need a simplified architecture to keep TCP as low as possible, while sustaining more and more workloads. Tools such ezjail, which allow to maintain a lot of jails as they were almost only one, make businesses to obtain a true "consolidation", whom other proprietary and open-sourced OSes are far away to reach. So... thank you very much, to anyone who contributed and still works to make this great project to evolve! I guess to to help you a bit by advocating FreeBSD as much as I can among customers, partners and institutions in my country. But a big work still remains to be done: to bring to BSD technologies the visibility they deserve among IT managers and professionals working in business environments. I'll do my best to make this happen in my country, I hope, also with the support of the FreeBSD Foundation and the BSD Certification Group, whom I'm in the process to make a few proposals to. Sincerely. Andrew _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969___ 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: proliant server lockups with freebsd-amd64-stable (2010-03-10)
On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote: > Hi. > > I have some trouble with an opteron server locking up spontaneously. It looses > all networks connectivity and even through console I can get no shell. > > Lockups occur mostly under disk load (periodic daily, bacula backup > running, make buildworld/buildkernel) and I can provoke them easily. [...] > 4 0 0 0 LL *cissmtx 0xff04ed820c00 [g_down] [...] > 100046 L *cissmtx 0xff04ed820c00 [irq257: ciss0] [...] I was analizing similar problem as potential ZFS bug. It turned out to be bug in ciss(4) and I believe mav@ (CCed) has fix for that. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgprYdmtTUzw3.pgp Description: PGP signature
8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
Hello, I'm having "interrupt storm detected" messages on a Dell Inspiron 580 running up-to-date 8-STABLE (amd64 arch). The interrupts seem to come from one of the atapci controllers, apparently atapci0 (main controller, with a SATA disk and an ATAPI optical drive). ata_interrupt gets called at a variable rate, between 1000-15 times per second, constantly, even when the disk is not used. >From adding debug sysctl code in ata-all.c:ata_interrupt_locked() I have been able to check that: ch->running is NULL (breaks loop in "do we have a running request") ch->state=0 ch->unit=0 ch->devices=1 (ATA_ATA_MASTER) most of the time. Here's attached dmesg output, pciconf -lv output, kernel configuration and vmstat -i output. A -current kernel exhibits the same behaviour. Any hint/idea how to debug this further would be really appreciated... -- Pierre Beyssac p...@fasterix.frmug.org Copyright (c) 1992-2010 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.0-STABLE #14: Fri Mar 12 01:37:24 CET 2010 r...@inspiron:/usr/src/sys/amd64/compile/INSP580 amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0x80a2a000. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0x80a2a240. Preloaded elf obj module "/boot/kernel/usb.ko" at 0x80a2a868. Preloaded elf obj module "/boot/kernel/ukbd.ko" at 0x80a2af10. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2660007980 Hz CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x00a5e000 - 0xbd77, 3167887360 bytes (773410 pages) 0x0001 - 0x00022f12, 5084741632 bytes (1241392 pages) avail memory = 8210997248 (7830 MB) ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target 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 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 0xf9b00 00024 (v2 ACPIAM) ACPI: XSDT 0xbd780100 0006C (v1 DELLFX0920091130 MSFT 0097) ACPI: FACP 0xbd780290 000F4 (v4 DELL FX09 20091130 MSFT 0097) ACPI: DSDT 0xbd780660 05B02 (v2 1 1000 INTL 20051117) ACPI: FACS 0xbd78e000 00040 ACPI: APIC 0xbd780390 0008C (v2 DELL FX09 20091130 MSFT 0097) ACPI: MCFG 0xbd780420 0003C (v1 DELL OEMMCFG 20091130 MSFT 0097) ACPI: SLIC 0xbd780460 00176 (v1 DELLFX0920091130 MSFT 0097) ACPI: OSFR 0xbd7805e0 00080 (v1 DELL FX09 20091130 MSFT 0097) ACPI: OEMB 0xbd78e040 00072 (v1 DELL FX09 20091130 MSFT 0097) ACPI: HPET 0xbd78a660 00038 (v1 DELL OEMHPET 20091130 MSFT 0097) ACPI: ASF! 0xbd78a6a0 00099 (v32 LEGEND I865PASF 0001 INTL 20051117) ACPI: SSDT 0xbd78f6f0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) MADT: Found IO APIC ID 7, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 7 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 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00060015 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001000f pcm: 0x00010400 null: random: VESA: information block 56 45 53 41 00 03 f0 01 00 c0 01 00 00 00 44 00 0010 00 01 00 01 0f 0c 29 01 00 c0 bb 00 00 c0 3a 4d 0020 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 00 00 00 00 01 01 01 03 01 05 01 07 01 10 01 0050 11 01 13 01 14 01 16 01 17 01 19 01 1a 01 0d 01 0060 0e 01 20 01 93 01 95 01 96 01 b3 01 b5 01 b6 01 0070 c3 01 c5 01 c6 01 33 01 35 01 36 01 53 01 55 01 0080 56 01 63 01 65 01 66 01 21 01 22 01 23 01 24 01 0090 43 01 45 01 46 01 73 01 75 01 76 01 83 01 85 01 00a0 86 01 d3 01 d5 01 d6 01 e3 01 e5 01 e6 01 ff ff 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 01:14:09PM +0100, Pierre Beyssac wrote: > I'm having "interrupt storm detected" messages on a Dell Inspiron > 580 running up-to-date 8-STABLE (amd64 arch). The interrupts seem > to come from one of the atapci controllers, apparently atapci0 (main > controller, with a SATA disk and an ATAPI optical drive). I'm a little confused by the kernel output. It appears as if you're using the new SATA-to-CAM layer (ahci.ko) for your SATA disks, rather than the ataahci.ko layer... but I don't see any indication of AHCI being available/used on your southbridge chipset. Possibly this is the source of the problem (specifically, it looks like FreeBSD doesn't have proper device ID knowledge of what this controller is. I believe that's because this system is *very* new, a Core i3/i5/i7 system)? If you disable use of ahci.ko and use the standard ata(4) layer, does the interrupt storm go away? -- | 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"
(fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 05:18:32AM -0800, Jeremy Chadwick wrote: > I'm a little confused by the kernel output. It appears as if you're > using the new SATA-to-CAM layer (ahci.ko) for your SATA disks, rather > than the ataahci.ko layer... but I don't see any indication of AHCI > being available/used on your southbridge chipset. ahci.ko is not compiled in or loaded as a module, however in the course of debugging the problem I added option ATA_CAM, which seems to result in /dev/ada0*. Removing the option to get back to /dev/ad4* doesn't fix the problem. BTW ATA_CAM seems to work fine with generic ATA but not with ataintel. > Possibly this is the source of the problem (specifically, it looks like > FreeBSD doesn't have proper device ID knowledge of what this controller > is. I believe that's because this system is *very* new, a Core i3/i5/i7 > system)? I didn't notice that, you're right! The system is brand new, got it delivered on Tuesday. Another odd thing is that the controllers have differents IDs, 0x3b208086 vs 0x3b268086. I added the IDs to ata-intel.c and it fixes the problem. Preparing a patch. Thanks for the hint! -- Pierre Beyssac p...@fasterix.frmug.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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 05:57:44PM +0100, Pierre Beyssac wrote: > > Possibly this is the source of the problem (specifically, it looks like > > FreeBSD doesn't have proper device ID knowledge of what this controller > > is. I believe that's because this system is *very* new, a Core i3/i5/i7 > > system)? > > I didn't notice that, you're right! The system is brand new, got > it delivered on Tuesday. Another odd thing is that the controllers > have differents IDs, 0x3b208086 vs 0x3b268086. > > I added the IDs to ata-intel.c and it fixes the problem. > > Preparing a patch. Thanks for the hint! > -- > Pierre Beyssacp...@fasterix.frmug.org > --- ata-intel.c.orig 2010-03-12 17:02:00.680011011 +0100 > +++ ata-intel.c 2010-03-12 16:55:54.773702505 +0100 > @@ -156,6 +156,8 @@ > { 0x3a2d8086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > { 0x3a2e8086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > { 0x3a2f8086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > + { 0x3b208086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > + { 0x3b268086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > { ATA_I31244, 0, 0, 2, ATA_SA150, "31244" }, > { ATA_ISCH, 0, 0, 1, ATA_UDMA5, "SCH" }, > { 0, 0, 0, 0, 0, 0}}; I had a chance to review the Intel 5 Series and 3400 Series Chipset document, which is specific to the PCH. The breakdown for those two Device IDs, under Vendor ID 0x8086 (Intel), is: Device ID 0x3b20 - PCH SATA controller - Desktop revision, non-AHCI and non-RAID Mode - Ports 0,1,2,3 Device ID 0x3b26 - PCH SATA controller - Desktop revision, non-AHCI and non-RAID mode - Ports 4,5 So I'm not sure the setting of the INTEL_AHCI flag there is correct for these controllers. mav@ will need to chime in here. Regarding the "dual device IDs": what this means is that ports 0-3 are tied to one device on the PCI bus, and ports 4-5 are tied to another device on the PCI bus. They might have chosen to do this so they could segregate which ports do what or operate differently somehow. mav@ may also want to review the specification since it mentions a bunch of other Device IDs which don't appear to be in the above list: http://www.intel.com/Assets/PDF/specupdate/322170.pdf -- | 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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 09:09:36AM -0800, Jeremy Chadwick wrote: > > + { 0x3b208086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > > + { 0x3b268086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, > Device ID 0x3b20 > - PCH SATA controller > - Desktop revision, non-AHCI and non-RAID Mode > - Ports 0,1,2,3 Great, I was just wondering about the values I put in the fields. So, thanks, non-AHCI. That explains why adding the same ids to ahci.c didn't yeld anything interesting :-). And the PCH name is correct OTOH. > So I'm not sure the setting of the INTEL_AHCI flag there is correct > for these controllers. mav@ will need to chime in here. Probably not, I'll remove it. Thanks. -- Pierre Beyssac p...@fasterix.frmug.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: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 01:14:09PM +0100, Pierre Beyssac wrote: > Hello, > > I'm having "interrupt storm detected" messages on a Dell Inspiron > 580 running up-to-date 8-STABLE (amd64 arch). The interrupts seem > to come from one of the atapci controllers, apparently atapci0 (main > controller, with a SATA disk and an ATAPI optical drive). > > ata_interrupt gets called at a variable rate, between 1000-15 > times per second, constantly, even when the disk is not used. > > >From adding debug sysctl code in ata-all.c:ata_interrupt_locked() > I have been able to check that: > ch->running is NULL (breaks loop in "do we have a running request") > ch->state=0 > ch->unit=0 ch->devices=1 (ATA_ATA_MASTER) most of the time. > > Here's attached dmesg output, pciconf -lv output, kernel configuration > and vmstat -i output. A -current kernel exhibits the same behaviour. > > Any hint/idea how to debug this further would be really appreciated... > -- > Pierre Beyssacp...@fasterix.frmug.org [...] > bge0: mem 0xfbff-0xfbff > irq 17 at device 0.0 on pci3 > bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xfbff > bge0: adjust device control 0x2000 -> 0x5000 > bge0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 50 > bge0: using IRQ 256 for MSI > bge0: CHIP ID 0x57780001; ASIC REV 0x57780; CHIP REV 0x577800; PCI-E > bge0: Disabling fastboot > bge0: Disabling fastboot > miibus0: on bge0 > ukphy0: PHY 1 on miibus0 > ukphy0: OUI 0x00d897, model 0x0019, rev. 1 ^^ This is not related with your interrupt storm issue but something is wrong here. I think brgphy(4) should be used for bge(4). Have no idea why the OUI has a different value. Would you try attached patch and let me know whether brgphy(4) get attached to the PHY? > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: bpf attached > bge0: Ethernet address: 00:25:64:f4:27:26 > bge0: [MPSAFE] > bge0: [FILTER] [...] Index: sys/dev/mii/miidevs === --- sys/dev/mii/miidevs (revision 205052) +++ sys/dev/mii/miidevs (working copy) @@ -81,6 +81,7 @@ oui xxALTIMA 0x000895 Altima Communications oui xxBROADCOM 0x000818 Broadcom Corporation oui xxBROADCOM_ALT1 0x0050ef Broadcom Corporation +oui xxBROADCOM_ALT2 0x00d897 Broadcom Corporation oui xxICS 0x00057d Integrated Circuit Systems oui xxSEEQ 0x0005be Seeq oui xxSIS 0x000760 Silicon Integrated Systems @@ -150,6 +151,7 @@ model xxBROADCOM_ALT1 BCM5784 0x003a BCM5784 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY +model xxBROADCOM_ALT2 BCM57780 0x0019 BCM57780 10/100/1000baseTX PHY model BROADCOM2 BCM5906 0x0004 BCM5906 10/100baseTX PHY /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ Index: sys/dev/mii/brgphy.c === --- sys/dev/mii/brgphy.c (revision 205052) +++ sys/dev/mii/brgphy.c (working copy) @@ -139,6 +139,7 @@ MII_PHY_DESC(xxBROADCOM_ALT1, BCM5784), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709C), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5761), + MII_PHY_DESC(xxBROADCOM_ALT2, BCM57780), MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; ___ 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 interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 09:46:55AM -0800, Pyun YongHyeon wrote: > This is not related with your interrupt storm issue but something > is wrong here. I think brgphy(4) should be used for bge(4). Have no > idea why the OUI has a different value. > Would you try attached patch and let me know whether brgphy(4) > get attached to the PHY? It sort of works (see attached dmesg) but not quite correctly, the ethernet link takes an awful lot of time to negotiate (> 10s) and it negotiates 10 Mbps instead of 100 Mbps previously. The message "Unrecognized OUI for PHY!" seems to indicate something's amiss, maybe I should regenerate some file(s) after applying your patches? -- Pierre Beyssac p...@fasterix.frmug.org Copyright (c) 1992-2010 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.0-STABLE #1: Fri Mar 12 19:02:49 CET 2010 r...@inspiron:/usr/src/sys/amd64/compile/INSP580 amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0x80a2b000. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0x80a2b240. Preloaded elf obj module "/boot/kernel/usb.ko" at 0x80a2b868. Preloaded elf obj module "/boot/kernel/ukbd.ko" at 0x80a2bf10. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2659996160 Hz CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.00-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x00a5f000 - 0xbd77, 3167883264 bytes (773409 pages) 0x0001 - 0x00022f12, 5084741632 bytes (1241392 pages) avail memory = 8210993152 (7830 MB) ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target 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 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 0xf9b00 00024 (v2 ACPIAM) ACPI: XSDT 0xbd780100 0006C (v1 DELLFX0920091130 MSFT 0097) ACPI: FACP 0xbd780290 000F4 (v4 DELL FX09 20091130 MSFT 0097) ACPI: DSDT 0xbd780660 05B02 (v2 1 1000 INTL 20051117) ACPI: FACS 0xbd78e000 00040 ACPI: APIC 0xbd780390 0008C (v2 DELL FX09 20091130 MSFT 0097) ACPI: MCFG 0xbd780420 0003C (v1 DELL OEMMCFG 20091130 MSFT 0097) ACPI: SLIC 0xbd780460 00176 (v1 DELLFX0920091130 MSFT 0097) ACPI: OSFR 0xbd7805e0 00080 (v1 DELL FX09 20091130 MSFT 0097) ACPI: OEMB 0xbd78e040 00072 (v1 DELL FX09 20091130 MSFT 0097) ACPI: HPET 0xbd78a660 00038 (v1 DELL OEMHPET 20091130 MSFT 0097) ACPI: ASF! 0xbd78a6a0 00099 (v32 LEGEND I865PASF 0001 INTL 20051117) ACPI: SSDT 0xbd78f6f0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) MADT: Found IO APIC ID 7, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 7 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 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00060015 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001000f pcm: 0x00010400 null: random: VESA: information block 56 45 53 41 00 03 f0 01 00 c0 01 00 00 00 44 00 0010 00 01 00 01 0f 0c 29 01 00 c0 bb 00 00 c0 3a 4d 0020 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 00 00 00 00 01 01 01 03 01 05 01 07 01 10 01 0050 11 01 13 01 14 01 16 01 17 01 19 01 1a 01 0d 01 0060 0e 01 20 01 93 01 95 01 96 01 b3 01 b5 01 b6 01 0070 c3 01 c5 01 c6 01 33 01 35 01 36 01 53 01 55 01 0080 56 01 63 01 65 01 66 01 21 01 22 01 23 01 24 01 0090 43 01 45 01 46 01 73 01 75 01 76 01 83 01 85 01 00a0 86 01 d3 01 d5 01 d6 01 e3 01 e5 01 e6 01 ff ff 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0110 00 00 00 00 00 00 00 00 00 00
Geom not found: "gm0" / Failed to write sector zero
I just installed 7.3-RC2 amd64 on new server. I created slice s1 (80GB on disk ad4 (500GB), then partitions for system (/, swap, /var, /usr, /tmp) by sysinstall. After base install I created gmirror gm0 as usual (I did it many times). Now I am no longer in datacenter and have only ssh access to this server and I need to create slice s2 with some partitions for data storage, but fdisk failed. fdisk -u /dev/mirror/gm0 At the end, I got this error: Should we write new partition table? [n] y fdisk: Geom not found: "gm0" fdisk: Failed to write sector zero Fdisk failed even if I used sysctl kern.geom.debugflags=16 Question #1 - why 'Geom not found: "gm0"'? Question #2 - is there any way to create slices + partitions on unused space if system is booted from this device? Or is the only way to boot it from some LiveFS / fixit? I found the same question on this list, but without reply http://lists.freebsd.org/pipermail/freebsd-stable/2009-June/050855.html I hope somebody can help / explain it. Miroslav Lachman ___ 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: proliant server lockups with freebsd-amd64-stable (2010-03-10)
Pawel Jakub Dawidek wrote: > On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote: >> I have some trouble with an opteron server locking up spontaneously. It >> looses >> all networks connectivity and even through console I can get no shell. >> >> Lockups occur mostly under disk load (periodic daily, bacula backup >> running, make buildworld/buildkernel) and I can provoke them easily. > [...] >> 4 0 0 0 LL *cissmtx 0xff04ed820c00 [g_down] > [...] >> 100046 L *cissmtx 0xff04ed820c00 [irq257: ciss0] > [...] > > I was analizing similar problem as potential ZFS bug. It turned out to > be bug in ciss(4) and I believe mav@ (CCed) has fix for that. That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make sure you have it. In this case trap stopped process at ciss_get_request(), which indeed called holding cissmtx lock. But there is no place to sleep or loop there, so may be it was just spontaneous. With bugs I was fixing there was a chance to loop indefinitely between ciss and CAM on resource constraint. That increases chance for such situation to be caught. You may try also look what's going on with `top -HS` and `systat -vm 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"
rc.d/rc.subr support for multiple FIBs
With multiple FIB support generally available in FreeBSD 8.0-RELEASE it would be quite beneficial to have the ability to build routing tables in secondary FIBs as well as start certain applications in certain FIBs from within rc.conf(5). I've done some poking around and came across two PRs which implement exactly what I'm looking for: http://www.freebsd.org/cgi/query-pr.cgi?pr=132483 http://www.freebsd.org/cgi/query-pr.cgi?pr=132476 My question is whether there are any plans to commit these into -CURRENT and possibly MFC them to a future 8.x-RELEASE. Having multiple FIBs available has been great so far, it goes hand and hand with Multi-IP Jails. The only thing missing are native methods for constructing the routing tables on boot (Yes, there is rc.local, but I don't want to go there...). Thanks, Steve Polyack ___ 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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
Jeremy Chadwick wrote: > On Fri, Mar 12, 2010 at 05:57:44PM +0100, Pierre Beyssac wrote: >>> Possibly this is the source of the problem (specifically, it looks like >>> FreeBSD doesn't have proper device ID knowledge of what this controller >>> is. I believe that's because this system is *very* new, a Core i3/i5/i7 >>> system)? >> I didn't notice that, you're right! The system is brand new, got >> it delivered on Tuesday. Another odd thing is that the controllers >> have differents IDs, 0x3b208086 vs 0x3b268086. >> >> I added the IDs to ata-intel.c and it fixes the problem. >> >> Preparing a patch. Thanks for the hint! >> -- >> Pierre Beyssac p...@fasterix.frmug.org > >> --- ata-intel.c.orig 2010-03-12 17:02:00.680011011 +0100 >> +++ ata-intel.c 2010-03-12 16:55:54.773702505 +0100 >> @@ -156,6 +156,8 @@ >> { 0x3a2d8086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, >> { 0x3a2e8086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, >> { 0x3a2f8086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, >> + { 0x3b208086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, >> + { 0x3b268086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" }, >> { ATA_I31244, 0, 0, 2, ATA_SA150, "31244" }, >> { ATA_ISCH, 0, 0, 1, ATA_UDMA5, "SCH" }, >> { 0, 0, 0, 0, 0, 0}}; > > I had a chance to review the Intel 5 Series and 3400 Series Chipset > document, which is specific to the PCH. The breakdown for those > two Device IDs, under Vendor ID 0x8086 (Intel), is: > > Device ID 0x3b20 > - PCH SATA controller > - Desktop revision, non-AHCI and non-RAID Mode > - Ports 0,1,2,3 > > Device ID 0x3b26 > - PCH SATA controller > - Desktop revision, non-AHCI and non-RAID mode > - Ports 4,5 > > So I'm not sure the setting of the INTEL_AHCI flag there is correct > for these controllers. mav@ will need to chime in here. Except ICH6 Intel uses separate IDs for AHCI and non-AHCI SATA controller modes. So this flag is not completely correct. But probably it shoudn't be just removed, as it is checked in other place. I know about this and going to handle it later. It's not a problem now. > Regarding the "dual device IDs": what this means is that ports 0-3 are > tied to one device on the PCI bus, and ports 4-5 are tied to another > device on the PCI bus. They might have chosen to do this so they could > segregate which ports do what or operate differently somehow. > > mav@ may also want to review the specification since it mentions a bunch > of other Device IDs which don't appear to be in the above list: > > http://www.intel.com/Assets/PDF/specupdate/322170.pdf Thanks. PS: Check BIOS settings for enabling AHCI mode. -- 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: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 07:21:34PM +0100, Pierre Beyssac wrote: > On Fri, Mar 12, 2010 at 09:46:55AM -0800, Pyun YongHyeon wrote: > > This is not related with your interrupt storm issue but something > > is wrong here. I think brgphy(4) should be used for bge(4). Have no > > idea why the OUI has a different value. > > Would you try attached patch and let me know whether brgphy(4) > > get attached to the PHY? > > It sort of works (see attached dmesg) but not quite correctly, the > ethernet link takes an awful lot of time to negotiate (> 10s) and > it negotiates 10 Mbps instead of 100 Mbps previously. > > The message "Unrecognized OUI for PHY!" seems to indicate something's > amiss, maybe I should regenerate some file(s) after applying your > patches? No, it seems there is other issue in brgphy(4). I noticed brgphy(4) blindly try to set jumbo frame related registers. I guess the PHY may not have the register. Back out previous patch and try this one. Index: sys/dev/mii/miidevs === --- sys/dev/mii/miidevs (revision 205052) +++ sys/dev/mii/miidevs (working copy) @@ -81,6 +81,7 @@ oui xxALTIMA 0x000895Altima Communications oui xxBROADCOM 0x000818Broadcom Corporation oui xxBROADCOM_ALT10x0050efBroadcom Corporation +oui xxBROADCOM_ALT20x00d897Broadcom Corporation oui xxICS 0x00057dIntegrated Circuit Systems oui xxSEEQ 0x0005beSeeq oui xxSIS 0x000760Silicon Integrated Systems @@ -150,6 +151,7 @@ model xxBROADCOM_ALT1 BCM5784 0x003a BCM5784 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY +model xxBROADCOM_ALT2 BCM57780 0x0019 BCM57780 10/100/1000baseTX PHY model BROADCOM2 BCM59060x0004 BCM5906 10/100baseTX PHY /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ Index: sys/dev/mii/brgphy.c === --- sys/dev/mii/brgphy.c(revision 205052) +++ sys/dev/mii/brgphy.c(working copy) @@ -139,6 +139,7 @@ MII_PHY_DESC(xxBROADCOM_ALT1, BCM5784), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709C), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5761), + MII_PHY_DESC(xxBROADCOM_ALT2, BCM57780), MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; @@ -213,6 +214,7 @@ switch (bsc->mii_oui) { case MII_OUI_BROADCOM: case MII_OUI_BROADCOM2: + case MII_OUI_xxBROADCOM_ALT2: break; case MII_OUI_xxBROADCOM: switch (bsc->mii_model) { @@ -1021,7 +1023,8 @@ if (bge_sc->bge_flags & BGE_FLAG_JITTER_BUG) brgphy_fixup_jitter_bug(sc); - brgphy_jumbo_settings(sc, ifp->if_mtu); + if (bge_sc->bge_flags & BGE_FLAG_JUMBO) + brgphy_jumbo_settings(sc, ifp->if_mtu); if (bge_sc->bge_flags & BGE_FLAG_WIRESPEED) brgphy_ethernet_wirespeed(sc); ___ 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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 08:59:32PM +0200, Alexander Motin wrote: > Except ICH6 Intel uses separate IDs for AHCI and non-AHCI SATA > controller modes. So this flag is not completely correct. But probably > it shoudn't be just removed, as it is checked in other place. I know > about this and going to handle it later. It's not a problem now. I was wondering exactly about that given the wording of the Intel document sent by Jeremy... > > http://www.intel.com/Assets/PDF/specupdate/322170.pdf > Thanks. > PS: Check BIOS settings for enabling AHCI mode. Problem is, I can't find any setting to do that, either it's not there or it's well hidden. The BIOS is up-to-date. Could it be possible for Dell to lock the chip in non-AHCI mode? -- Pierre Beyssac p...@fasterix.frmug.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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
Pierre Beyssac wrote: > On Fri, Mar 12, 2010 at 08:59:32PM +0200, Alexander Motin wrote: >> Except ICH6 Intel uses separate IDs for AHCI and non-AHCI SATA >> controller modes. So this flag is not completely correct. But probably >> it shoudn't be just removed, as it is checked in other place. I know >> about this and going to handle it later. It's not a problem now. > > I was wondering exactly about that given the wording of the Intel > document sent by Jeremy... > >>> http://www.intel.com/Assets/PDF/specupdate/322170.pdf >> Thanks. >> PS: Check BIOS settings for enabling AHCI mode. > > Problem is, I can't find any setting to do that, either it's not > there or it's well hidden. The BIOS is up-to-date. Could it be > possible for Dell to lock the chip in non-AHCI mode? It is BIOS job to configure SATA controller mode. It is difficult to do from driver level and very vendor-specific. Yes, it happens sometimes to see BIOSes without AHCI support. -- 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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 08:27:59PM +0100, Pierre Beyssac wrote: > On Fri, Mar 12, 2010 at 08:59:32PM +0200, Alexander Motin wrote: > > Except ICH6 Intel uses separate IDs for AHCI and non-AHCI SATA > > controller modes. So this flag is not completely correct. But probably > > it shoudn't be just removed, as it is checked in other place. I know > > about this and going to handle it later. It's not a problem now. > > I was wondering exactly about that given the wording of the Intel > document sent by Jeremy... > > > > http://www.intel.com/Assets/PDF/specupdate/322170.pdf > > Thanks. > > PS: Check BIOS settings for enabling AHCI mode. > > Problem is, I can't find any setting to do that, either it's not > there or it's well hidden. The BIOS is up-to-date. Could it be > possible for Dell to lock the chip in non-AHCI mode? The system uses the Intel H57 (Ibex) chipset, which is documented here: http://www.intel.com/Products/Desktop/Chipsets/H57/h57-overview.htm The official datasheet is here (~4.4MBytes): http://www.intel.com/Assets/PDF/datasheet/322169.pdf Which does state AHCI is available, however Intel is known for making separate SKUs (revisions/models with different tweaks to the chips) that support different features. Table 1.3 on the PDF outlines what the H57 is capable of: Intel 5 Series Chipset SKUs (Desktop) SKU Name AHCI RAID 0/1/5/10 Support - Q57YesYes H57YesYes< H55YesNo P55YesYes - Intel 3400 Series Chipset SKUs (Server) SKU Name AHCI RAID 0/1/5/10 Support - 3400 No No 3420 YesYes 3450 YesYes - Further within the documentation, it states that for eSATA hot-plug to work, AHCI has to be enabled/in use. That's about all I can discern from the PDF without getting into technical specifics. -- | 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 interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 08:45:24PM +0100, Pierre Beyssac wrote: > On Fri, Mar 12, 2010 at 11:21:44AM -0800, Pyun YongHyeon wrote: > > No, it seems there is other issue in brgphy(4). I noticed brgphy(4) > > blindly try to set jumbo frame related registers. I guess the PHY > > may not have the register. Back out previous patch and try this > > one. > > Thanks, works better (the error message is gone), but still negotiates > at 10baseT/UTP fdx... See attached dmesg.out. Hmm, try this one and let me know it make any differences. Index: sys/dev/mii/miidevs === --- sys/dev/mii/miidevs (revision 205052) +++ sys/dev/mii/miidevs (working copy) @@ -81,6 +81,7 @@ oui xxALTIMA 0x000895Altima Communications oui xxBROADCOM 0x000818Broadcom Corporation oui xxBROADCOM_ALT10x0050efBroadcom Corporation +oui xxBROADCOM_ALT20x00d897Broadcom Corporation oui xxICS 0x00057dIntegrated Circuit Systems oui xxSEEQ 0x0005beSeeq oui xxSIS 0x000760Silicon Integrated Systems @@ -150,6 +151,7 @@ model xxBROADCOM_ALT1 BCM5784 0x003a BCM5784 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY +model xxBROADCOM_ALT2 BCM57780 0x0019 BCM57780 10/100/1000baseTX PHY model BROADCOM2 BCM59060x0004 BCM5906 10/100baseTX PHY /* Cicada Semiconductor PHYs (now owned by Vitesse?) */ Index: sys/dev/mii/brgphy.c === --- sys/dev/mii/brgphy.c(revision 205052) +++ sys/dev/mii/brgphy.c(working copy) @@ -139,6 +139,7 @@ MII_PHY_DESC(xxBROADCOM_ALT1, BCM5784), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5709C), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5761), + MII_PHY_DESC(xxBROADCOM_ALT2, BCM57780), MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; @@ -213,6 +214,7 @@ switch (bsc->mii_oui) { case MII_OUI_BROADCOM: case MII_OUI_BROADCOM2: + case MII_OUI_xxBROADCOM_ALT2: break; case MII_OUI_xxBROADCOM: switch (bsc->mii_model) { @@ -678,16 +680,18 @@ brgphy_mii_phy_auto(struct mii_softc *sc) { struct brgphy_softc *bsc = (struct brgphy_softc *)sc; + uint16_t anar; int ktcr = 0; brgphy_reset(sc); /* Enable flow control in the advertisement register. */ if ((sc->mii_flags & MIIF_HAVEFIBER) == 0) { + anar = PHY_READ(sc, BRGPHY_MII_ANAR) & BRGPHY_ANAR_NP; /* Pause capability advertisement (pause capable & asymmetric) */ PHY_WRITE(sc, BRGPHY_MII_ANAR, BMSR_MEDIA_TO_ANAR(sc->mii_capabilities) | ANAR_CSMA | - BRGPHY_ANAR_ASP | BRGPHY_ANAR_PC); + BRGPHY_ANAR_ASP | BRGPHY_ANAR_PC | anar); } else { PHY_WRITE(sc, BRGPHY_SERDES_ANAR, BRGPHY_SERDES_ANAR_FDX | BRGPHY_SERDES_ANAR_HDX | BRGPHY_SERDES_ANAR_BOTH_PAUSE); @@ -1021,7 +1025,8 @@ if (bge_sc->bge_flags & BGE_FLAG_JITTER_BUG) brgphy_fixup_jitter_bug(sc); - brgphy_jumbo_settings(sc, ifp->if_mtu); + if (bge_sc->bge_flags & BGE_FLAG_JUMBO) + brgphy_jumbo_settings(sc, ifp->if_mtu); if (bge_sc->bge_flags & BGE_FLAG_WIRESPEED) brgphy_ethernet_wirespeed(sc); ___ 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: proliant server lockups with freebsd-amd64-stable (2010-03-10)
Am Fri, 12 Mar 2010 20:38:31 +0200 schrieb Alexander Motin : > Pawel Jakub Dawidek wrote: > > On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote: > >> I have some trouble with an opteron server locking up > >> spontaneously. It looses all networks connectivity and even > >> through console I can get no shell. > >> > >> Lockups occur mostly under disk load (periodic daily, bacula backup > >> running, make buildworld/buildkernel) and I can provoke them > >> easily. > > [...] > >> 4 0 0 0 LL *cissmtx 0xff04ed820c00 > >> [g_down] > > [...] > >> 100046 L *cissmtx 0xff04ed820c00 > >> [irq257: ciss0] > > [...] > > > > I was analizing similar problem as potential ZFS bug. It turned out > > to be bug in ciss(4) and I believe mav@ (CCed) has fix for that. > > That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make > sure you have it. Updating collection src-all/cvs .. .. Edit src/sys/dev/ciss/ciss.c Edit src/sys/dev/ciss/cissvar.h Didn't have it! Must have been just a few hours I missed it, when I built the last kernel. So I will rebuild my kernel and give it a spin later on. > In this case trap stopped process at ciss_get_request(), which indeed > called holding cissmtx lock. But there is no place to sleep or loop > there, so may be it was just spontaneous. With bugs I was fixing there > was a chance to loop indefinitely between ciss and CAM on resource > constraint. That increases chance for such situation to be caught. > > You may try also look what's going on with `top -HS` and `systat -vm > 1`. FYI. Without your patch of ciss.c and cissvar.h a lockup with top -HS and systat -vm running gives following information below. Is there a pattern visible relating to your patch of the ciss driver? Kai. -- vmstat -vm -- 3 usersLoad 0.21 0.36 0.45 Mar 12 21:47 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 2805456 40804 6269932079936 12358k count All 6182560 95796 1136820k 212452 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow 16018 total 491 533 28 576 19 179 174zfodatkbd0 1 ozfod uart0 irq4 12.9%Sys 12.5%Intr 0.1%User 0.0%Nice 74.5%Idle%ozfod ata0 irq14 ||||||||||| daefr uhci0 45 ==+++ prcfr 2000 cpu0: time 87 dtbuf totfr19 bce0 256 Namei Name-cache Dir-cache10 desvn react ciss0 257 Callshits %hits % 40811 numvn pdwak 2000 cpu1: time 17300 frevn pdpgs 2000 cpu4: time intrn 2000 cpu5: time Disks da0 da1 da2 da3 da4 pass0 pass1 4995516 wire 2000 cpu6: time KB/t 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2593276 act1999 cpu7: time tps 0 0 0 0 0 0 0369560 inact 2000 cpu3: time MB/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 9568 cache 2000 cpu2: time %busy 0 0 0 0 0 0 0 12348752 free 1252272 buf --- top -HS last pid: 42561; load averages: 0.35, 0.38, 0.46up 0+11:24:36 21:53:39 658 processes: 13 running, 623 sleeping, 21 waiting, 1 lock CPU: 0.6% user, 0.0% nice, 12.6% system, 25.0% interrupt, 61.8% idle Mem: 2559M Active, 363M Inact, 4892M Wired, 9548K Cache, 1223M Buf, 12G Free Swap: 21G Total, 21G Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 128K CPU33 672:22 100.00% {idle: cpu3} 11 root 171 ki31 0K 128K CPU11 663:50 100.00% {idle: cpu1} 11 root 171 ki31 0K 128K RUN 4 649:18 100.00% {idle: cpu4} 12 root -32- 0K 384K CPU70 6:38 100.00% {swi4: clock} 4 root -8- 0K16K CPU55 1:16 100.00% g_down 12 root -64- 0K 384K CPU20 1:15 100.00% {swi2: cambio} 11 root 171 ki31 0K 128K CPU66 672:13 97.27% {idle: cpu6} 11 root 171 ki31 0K 128K CPU00 622:18 96.29% {idle: cpu0} 11 root 171 ki31 0K 128K RUN 7 676:57 10.99% {idle: cpu7} 2046 zope1 460 468M 379M ucond 6 7:30 1.76% {python} 11 root 171 ki31 0K 128K RUN 5 663:27 0.00% {idle: cpu5} 11 root 171 ki31 0K 128K RUN 2 656:03 0.00% {idle: cpu2} 12 root -68
Re: proliant server lockups with freebsd-amd64-stable (2010-03-10)
Kai Gallasch wrote: > Am Fri, 12 Mar 2010 20:38:31 +0200 > schrieb Alexander Motin : >> Pawel Jakub Dawidek wrote: >>> I was analizing similar problem as potential ZFS bug. It turned out >>> to be bug in ciss(4) and I believe mav@ (CCed) has fix for that. >> That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make >> sure you have it. > > Updating collection src-all/cvs > .. > .. > Edit src/sys/dev/ciss/ciss.c > Edit src/sys/dev/ciss/cissvar.h > > Didn't have it! Must have been just a few hours I missed it, > when I built the last kernel. So I will rebuild my kernel and > give it a spin later on. > >> In this case trap stopped process at ciss_get_request(), which indeed >> called holding cissmtx lock. But there is no place to sleep or loop >> there, so may be it was just spontaneous. With bugs I was fixing there >> was a chance to loop indefinitely between ciss and CAM on resource >> constraint. That increases chance for such situation to be caught. >> >> You may try also look what's going on with `top -HS` and `systat -vm >> 1`. > > FYI. Without your patch of ciss.c and cissvar.h a lockup with top -HS > and systat -vm running gives following information below. Is there a > pattern visible relating to your patch of the ciss driver? May be. You should try, -- 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: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 09:28:52PM +0100, Pierre Beyssac wrote: > On Fri, Mar 12, 2010 at 12:02:24PM -0800, Pyun YongHyeon wrote: > > Hmm, try this one and let me know it make any differences. > > No, still the same, negotiates at 10baseT/UTP. It seems the PHY has no BRGPHY_MII_AUXSTS register as it does not seem to manufactured by Broadcom. Adding a special case to brgphy(4) does not look right. Does ukphy(4) work without problem? If so I think you can live with ukphy(4). ___ 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: rc.d/rc.subr support for multiple FIBs
On Fri, Mar 12, 2010 at 12:44 PM, Steve Polyack wrote: > With multiple FIB support generally available in FreeBSD 8.0-RELEASE it > would be quite beneficial to have the ability to build routing tables in > secondary FIBs as well as start certain applications in certain FIBs from > within rc.conf(5). > > I've done some poking around and came across two PRs which implement exactly > what I'm looking for: > http://www.freebsd.org/cgi/query-pr.cgi?pr=132483 > http://www.freebsd.org/cgi/query-pr.cgi?pr=132476 > > My question is whether there are any plans to commit these into -CURRENT and > possibly MFC them to a future 8.x-RELEASE. Having multiple FIBs available > has been great so far, it goes hand and hand with Multi-IP Jails. The only > thing missing are native methods for constructing the routing tables on boot > (Yes, there is rc.local, but I don't want to go there...). > > Thanks, > Steve Polyack > > ___ > 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 too would love to see this integrated; I've hacked together my own set of rc scripts (elegant in no way) to accomplish something similar on my systems. Also, general documentation regarding multiple FIBs (if that's what they are to be referred to as) in the official docs would be cool -- I'm not knowledgeable enough to do it myself (although I'm a pretty decent hand at "Documentation Testing" :) -Brandon ___ 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 USB wireless support?
On Tue, Feb 16, 2010 at 11:39:53AM +1100, Jeff Dowsley wrote: > Gentles > > I have an old HP Pavillion DV6000 laptop, which has a Broadcom USB > wireless device. Worked under Windows Vista. I installed freeBSD 8- > stable, and see as the last line in dmesg > > ugen2.2: at usbus2 > > Ferreting with google suggests that 8.0 might have usb support for > the ndis wrapper, but I am unable to get any joy either using the HP > bcmwl5 drivers for the DV6000, or in attempting to use the bwi driver. FYI recently OpenBSD commited urndis(4) driver into their tree that looks it could support your device if the device uses Broadcom 4320 chipset. But it looks nobody is working on it to port to FreeBSD. regards, Weongyo Jeong ___ 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"