Re: Many processes stuck in zfs

[Alexander Leidinger]

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

[Greg Byshenk]

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

[Andrew Hotlab]

> 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)

[Pawel Jakub Dawidek]

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

[Pierre Beyssac]

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

[Jeremy Chadwick]

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

[Pierre Beyssac]

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

[Jeremy Chadwick]

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

[Pierre Beyssac]

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

[Pyun YongHyeon]

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

[Pierre Beyssac]

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

[Miroslav Lachman]

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)

[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.

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

[Steve Polyack]

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

[Alexander Motin]

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

[Pyun YongHyeon]

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

[Pierre Beyssac]

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

[Alexander Motin]

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

[Jeremy Chadwick]

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

[Pyun YongHyeon]

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)

[Kai Gallasch]

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)

[Alexander Motin]

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

[Pyun YongHyeon]

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

[Brandon Gooch]

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?

[Weongyo Jeong]

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"