* Re: IPV6_RTHDR with a type-0 routing header
From: Rémi Denis-Courmont @ 2009-08-20 11:29 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev
In-Reply-To: <20090820111152.GA20295@uio.no>
On Thu, 20 Aug 2009 13:11:52 +0200, "Steinar H. Gunderson"
<sgunderson@bigfoot.com> wrote:
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not
> type-2;
> should that really be right? I found the following commit:
RT0 headers have been deprecated by IETF. The kernel refuses to use then on
purpose.
--
Rémi Denis-Courmont
^ permalink raw reply
* Re: IPV6_RTHDR with a type-0 routing header
From: Jens Rosenboom @ 2009-08-20 11:29 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: brian.haley, davem, netdev, shanwei
In-Reply-To: <20090820111152.GA20295@uio.no>
On Thu, 2009-08-20 at 13:11 +0200, Steinar H. Gunderson wrote:
> Hi,
>
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not type-2;
> should that really be right? I found the following commit:
>
> http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
>
> However, it only seems to change EPERM into EINVAL. I don't see any
> reasonable explanation why it should not be simply success; in fact, RFC 3452
> only seems to talk about using type-0 headers with this option.
>
> Any ideas?
How about RFC5095?
^ permalink raw reply
* Re: zorro8390: Fix read buffer overflow in zorro8390_init_one()
From: Geert Uytterhoeven @ 2009-08-20 11:53 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev, Linux Kernel Mailing List, linux-m68k
In-Reply-To: <200908182159.n7ILxX3d013229@hera.kernel.org>
On Tue, Aug 18, 2009 at 23:59, Linux Kernel Mailing
List<linux-kernel@vger.kernel.org> wrote:
> Gitweb: http://git.kernel.org/linus/be12159b24c532b4b48bdec5a543336438faa132
> Commit: be12159b24c532b4b48bdec5a543336438faa132
> Parent: 5e33b719c8fcccfedc1d25167826a0f93fe6c5a1
> Author: roel kluin <roel.kluin@gmail.com>
> AuthorDate: Sun Aug 9 04:00:25 2009 +0000
> Committer: David S. Miller <davem@davemloft.net>
> CommitDate: Sun Aug 9 21:46:53 2009 -0700
>
> zorro8390: Fix read buffer overflow in zorro8390_init_one()
>
> Prevent read from cards[-1] when no card was found.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/zorro8390.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/zorro8390.c b/drivers/net/zorro8390.c
> index 37c84e3..81c753a 100644
> --- a/drivers/net/zorro8390.c
> +++ b/drivers/net/zorro8390.c
> @@ -120,6 +120,9 @@ static int __devinit zorro8390_init_one(struct zorro_dev *z,
> for (i = ARRAY_SIZE(cards)-1; i >= 0; i--)
> if (z->id == cards[i].id)
> break;
> + if (i < 0)
> + return -ENODEV;
> +
> board = z->resource.start;
> ioaddr = board+cards[i].offset;
> dev = alloc_ei_netdev();
That case can never happen, as zorro8390_init_one() won't be called
without a matching ID.
But probably the information in struct card_info should be stored in
zorro8390_zorro_tbl[].driver_data,
so we can remove cards[] and the look up.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Strange network timeouts w/ 2.6.30.5
From: Walt Holman @ 2009-08-20 11:54 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <1359163732.51250769223038.JavaMail.root@mail.holmansrus.com>
[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]
----- "Krzysztof Halasa" <khc@pm.waw.pl> wrote:
> > Since patching to 2.6.30.5 I'm experiencing periodic timeouts on my
> > e100 which is used as my WAN interface on a server/router box.
> Nothing
> > is reported in any logs and eventually the traffic resumes. It
> seems
> > to happen at fairly regular intervals, although I've not timed
> them.
> > The timeouts last for approx. 60-120 seconds and then traffic
> resumes
> > normally with no hint of what happened.
>
> x86-64, intel P965...
>
> Can you provide "dmesg" output, please?
>
> I wonder what additional side effect did the patch cause. Streaming
> allocs on such x86 should already be coherent, no?
>
> Perhaps you have more than 2 GB RAM (or so) and swiotlb has to
> provide
> buffering? I think of something like:
>
> - the driver does "sync for CPU" and examines status
> - the descriptor is tested to be still empty
> - meanwhile e100 chip changes the status in the descriptor
> - the driver does "sync for device" (it's what the patch added)
> - at this point swiotlb doesn't know the descriptor is clean and
> writes
> it out, thus dropping the change done by the e100 chip.
>
> Does the above seem plausible? I admit I'm not swiotlb expert, it's
> a pure guess that it simply and blindly moves data in and out.
>
> If that's the case, I don't really know how could it work without the
> patch in question. Perhaps the timings were just right?
>
> What can we do with it? Rewriting to use consistent allocs, of
> course.
> Temporarily adding #ifdef CONFIG_ARM around the
> pci_dma_sync_single_for_device()? Not sure if other archs were
> affected.
>
> The root problem is that the driver shouldn't use streaming
> allocations
> for its descriptors (they are written from both sides
> simultaneously).
> Only skb->data can be streaming.
> --
> Krzysztof Halasa
Hi Krzystof,
dmesg is attached. This box does have >2GB Ram (6GB total). The dmesg will show e100 init'd 3 times since the first is the stock modprobe, 2nd was forced with use_io and the 3rd modprobe was after reverting the patch.
-Walt
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 60717 bytes --]
[ 0.000000] Linux version 2.6.30-patched-r5 (root@waltsputer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #1 SMP PREEMPT Wed Aug 19 17:51:30 CDT 2009
[ 0.000000] Command line: root=/dev/mapper/vg0-root ro resume=/dev/vg0/swap splash vga=791 elevator=deadline
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 0000000000098000 (usable)
[ 0.000000] BIOS-e820: 0000000000098000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000cffb0000 (usable)
[ 0.000000] BIOS-e820: 00000000cffb0000 - 00000000cffbe000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000cffbe000 - 00000000cfff0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000cfff0000 - 00000000d0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 00000001b0000000 (usable)
[ 0.000000] DMI present.
[ 0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0x1b0000 max_arch_pfn = 0x100000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-protect
[ 0.000000] E0000-EFFFF write-through
[ 0.000000] F0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 1B0000000 mask FF0000000 uncachable
[ 0.000000] 1 base 1C0000000 mask FC0000000 uncachable
[ 0.000000] 2 base 000000000 mask E00000000 write-back
[ 0.000000] 3 base 0D0000000 mask FF0000000 uncachable
[ 0.000000] 4 base 0E0000000 mask FE0000000 uncachable
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820 update range: 00000000d0000000 - 0000000100000000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0xcffb0 max_arch_pfn = 0x100000000
[ 0.000000] init_memory_mapping: 0000000000000000-00000000cffb0000
[ 0.000000] 0000000000 - 00cfe00000 page 2M
[ 0.000000] 00cfe00000 - 00cffb0000 page 4k
[ 0.000000] kernel direct mapping tables up to cffb0000 @ 10000-16000
[ 0.000000] init_memory_mapping: 0000000100000000-00000001b0000000
[ 0.000000] 0100000000 - 01b0000000 page 2M
[ 0.000000] kernel direct mapping tables up to 1b0000000 @ 14000-1c000
[ 0.000000] RAMDISK: 37a3a000 - 37fef4b7
[ 0.000000] ACPI: RSDP 00000000000f93a0 00014 (v00 ACPIAM)
[ 0.000000] ACPI: RSDT 00000000cffb0000 00038 (v01 M S I OEMRSDT 12000701 MSFT 00000097)
[ 0.000000] ACPI: FACP 00000000cffb0200 00084 (v02 M S I OEMFACP 12000701 MSFT 00000097)
[ 0.000000] ACPI: DSDT 00000000cffb0440 052CE (v01 0AAAA 0AAAA000 00000000 INTL 20051117)
[ 0.000000] ACPI: FACS 00000000cffbe000 00040
[ 0.000000] ACPI: APIC 00000000cffb0390 0006C (v01 M S I OEMAPIC 12000701 MSFT 00000097)
[ 0.000000] ACPI: MCFG 00000000cffb0400 0003C (v01 M S I OEMMCFG 12000701 MSFT 00000097)
[ 0.000000] ACPI: OEMB 00000000cffbe040 00061 (v01 M S I AMI_OEM 12000701 MSFT 00000097)
[ 0.000000] ACPI: SSDT 00000000cffbe9d0 00A7C (v01 DpgPmm CpuPm 00000012 INTL 20051117)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] (8 early reservations) ==> bootmem [0000000000 - 01b0000000]
[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
[ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000]
[ 0.000000] #2 [0000200000 - 0000730ca8] TEXT DATA BSS ==> [0000200000 - 0000730ca8]
[ 0.000000] #3 [0037a3a000 - 0037fef4b7] RAMDISK ==> [0037a3a000 - 0037fef4b7]
[ 0.000000] #4 [0000098000 - 0000100000] BIOS reserved ==> [0000098000 - 0000100000]
[ 0.000000] #5 [0000731000 - 0000731133] BRK ==> [0000731000 - 0000731133]
[ 0.000000] #6 [0000010000 - 0000014000] PGTABLE ==> [0000010000 - 0000014000]
[ 0.000000] #7 [0000014000 - 0000017000] PGTABLE ==> [0000014000 - 0000017000]
[ 0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[ 0.000000] [ffffe20000000000-ffffe20005ffffff] PMD -> [ffff880028200000-ffff88002e1fffff] on node 0
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0x00000010 -> 0x00001000
[ 0.000000] DMA32 0x00001000 -> 0x00100000
[ 0.000000] Normal 0x00100000 -> 0x001b0000
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[3] active PFN ranges
[ 0.000000] 0: 0x00000010 -> 0x00000098
[ 0.000000] 0: 0x00000100 -> 0x000cffb0
[ 0.000000] 0: 0x00100000 -> 0x001b0000
[ 0.000000] On node 0 totalpages: 1572664
[ 0.000000] DMA zone: 56 pages used for memmap
[ 0.000000] DMA zone: 1442 pages reserved
[ 0.000000] DMA zone: 2478 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 14280 pages used for memmap
[ 0.000000] DMA32 zone: 833512 pages, LIFO batch:31
[ 0.000000] Normal zone: 9856 pages used for memmap
[ 0.000000] Normal zone: 711040 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x808
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] SMP: Allowing 4 CPUs, 2 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 24
[ 0.000000] PM: Registered nosave memory: 0000000000098000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e3000
[ 0.000000] PM: Registered nosave memory: 00000000000e3000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000cffb0000 - 00000000cffbe000
[ 0.000000] PM: Registered nosave memory: 00000000cffbe000 - 00000000cfff0000
[ 0.000000] PM: Registered nosave memory: 00000000cfff0000 - 00000000d0000000
[ 0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000fee00000
[ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ffb00000
[ 0.000000] PM: Registered nosave memory: 00000000ffb00000 - 0000000100000000
[ 0.000000] Allocating PCI resources starting at d4000000 (gap: d0000000:2ee00000)
[ 0.000000] NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 25 pages at ffff880028034000, static data 70176 bytes
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1547030
[ 0.000000] Kernel command line: root=/dev/mapper/vg0-root ro resume=/dev/vg0/swap splash vga=791 elevator=deadline
[ 0.000000] Initializing CPU#0
[ 0.000000] NR_IRQS:384
[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[ 0.000000] Fast TSC calibration using PIT
[ 0.000000] Detected 2400.190 MHz processor.
[ 0.000999] Console: colour dummy device 80x25
[ 0.000999] console [tty0] enabled
[ 0.000999] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.000999] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.000999] Checking aperture...
[ 0.000999] No AGP bridge found
[ 0.000999] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.000999] Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000
[ 0.000999] software IO TLB at phys 0x20000000 - 0x24000000
[ 0.000999] Memory: 6101284k/7077888k available (3010k kernel code, 787232k absent, 188416k reserved, 1325k data, 384k init)
[ 0.000999] SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.001009] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.38 BogoMIPS (lpj=2400190)
[ 0.001041] Security Framework initialized
[ 0.001049] SELinux: Disabled at boot.
[ 0.001059] Mount-cache hash table entries: 256
[ 0.001198] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.001204] CPU: L2 cache: 4096K
[ 0.001210] CPU: Physical Processor ID: 0
[ 0.001214] CPU: Processor Core ID: 0
[ 0.001224] CPU0: Thermal monitoring enabled (TM2)
[ 0.001230] using mwait in idle threads.
[ 0.001251] ACPI: Core revision 20090320
[ 0.008759] Setting APIC routing to flat
[ 0.008998] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.019119] CPU0: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
[ 0.019996] Booting processor 1 APIC 0x1 ip 0x6000
[ 0.000999] Initializing CPU#1
[ 0.000999] Calibrating delay using timer specific routine.. 4798.99 BogoMIPS (lpj=2399499)
[ 0.000999] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 0.000999] CPU: L2 cache: 4096K
[ 0.000999] CPU: Physical Processor ID: 0
[ 0.000999] CPU: Processor Core ID: 1
[ 0.000999] CPU1: Thermal monitoring enabled (TM2)
[ 0.000999] x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
[ 0.091152] CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
[ 0.091206] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[ 0.092012] Brought up 2 CPUs
[ 0.092018] Total of 2 processors activated (9599.37 BogoMIPS).
[ 0.092085] net_namespace: 1712 bytes
[ 0.092085] NET: Registered protocol family 16
[ 0.092085] ACPI: bus type pci registered
[ 0.092993] dca service started, version 1.8
[ 0.093020] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[ 0.093027] PCI: Not using MMCONFIG.
[ 0.093031] PCI: Using configuration type 1 for base access
[ 0.095028] bio: create slab <bio-0> at 0
[ 0.096550] ACPI: EC: Look up EC in DSDT
[ 0.105318] ACPI: Interpreter enabled
[ 0.105325] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.105351] ACPI: Using IOAPIC for interrupt routing
[ 0.105406] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[ 0.108911] PCI: MCFG area at e0000000 reserved in ACPI motherboard resources
[ 0.118543] PCI: Using MMCONFIG at e0000000 - efffffff
[ 0.128037] ACPI Warning (tbutils-0246): Incorrect checksum in table [OEMB] - 3D, should be 34 [20090320]
[ 0.128162] ACPI: No dock devices found.
[ 0.128370] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 0.128400] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[ 0.128400] pci 0000:00:01.0: PME# disabled
[ 0.128400] pci 0000:00:1a.0: reg 20 io port: [0xac00-0xac1f]
[ 0.128400] pci 0000:00:1a.1: reg 20 io port: [0xa880-0xa89f]
[ 0.128400] pci 0000:00:1a.7: reg 10 32bit mmio: [0xfbfffc00-0xfbffffff]
[ 0.128400] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
[ 0.128400] pci 0000:00:1a.7: PME# disabled
[ 0.128400] pci 0000:00:1b.0: reg 10 64bit mmio: [0xfbff8000-0xfbffbfff]
[ 0.128400] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.128400] pci 0000:00:1b.0: PME# disabled
[ 0.128400] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.128400] pci 0000:00:1c.0: PME# disabled
[ 0.129027] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[ 0.129034] pci 0000:00:1c.4: PME# disabled
[ 0.129087] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[ 0.129094] pci 0000:00:1c.5: PME# disabled
[ 0.129135] pci 0000:00:1d.0: reg 20 io port: [0xa800-0xa81f]
[ 0.129178] pci 0000:00:1d.1: reg 20 io port: [0xa480-0xa49f]
[ 0.129220] pci 0000:00:1d.2: reg 20 io port: [0xa400-0xa41f]
[ 0.129268] pci 0000:00:1d.7: reg 10 32bit mmio: [0xfbfff800-0xfbfffbff]
[ 0.129312] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[ 0.129319] pci 0000:00:1d.7: PME# disabled
[ 0.129426] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
[ 0.129436] pci 0000:00:1f.0: quirk: region 0480-04bf claimed by ICH6 GPIO
[ 0.129443] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0a00 (mask 00ff)
[ 0.129501] pci 0000:00:1f.2: reg 10 io port: [0xa080-0xa087]
[ 0.129507] pci 0000:00:1f.2: reg 14 io port: [0xa000-0xa003]
[ 0.129512] pci 0000:00:1f.2: reg 18 io port: [0x9c00-0x9c07]
[ 0.129517] pci 0000:00:1f.2: reg 1c io port: [0x9880-0x9883]
[ 0.129522] pci 0000:00:1f.2: reg 20 io port: [0x9800-0x981f]
[ 0.129527] pci 0000:00:1f.2: reg 24 32bit mmio: [0xfbfff000-0xfbfff7ff]
[ 0.129551] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.129557] pci 0000:00:1f.2: PME# disabled
[ 0.129581] pci 0000:00:1f.3: reg 10 32bit mmio: [0xfbffec00-0xfbffecff]
[ 0.129596] pci 0000:00:1f.3: reg 20 io port: [0x400-0x41f]
[ 0.129637] pci 0000:01:00.0: reg 10 32bit mmio: [0xfd000000-0xfdffffff]
[ 0.129644] pci 0000:01:00.0: reg 14 64bit mmio: [0xd0000000-0xdfffffff]
[ 0.129652] pci 0000:01:00.0: reg 1c 64bit mmio: [0xfc000000-0xfcffffff]
[ 0.129657] pci 0000:01:00.0: reg 24 io port: [0xbc00-0xbc7f]
[ 0.129661] pci 0000:01:00.0: reg 30 32bit mmio: [0xfe8e0000-0xfe8fffff]
[ 0.129712] pci 0000:00:01.0: bridge io port: [0xb000-0xbfff]
[ 0.129715] pci 0000:00:01.0: bridge 32bit mmio: [0xfc000000-0xfe8fffff]
[ 0.129719] pci 0000:00:01.0: bridge 64bit mmio pref: [0xd0000000-0xdfffffff]
[ 0.129842] pci 0000:03:00.0: reg 24 32bit mmio: [0xfe9fe000-0xfe9fffff]
[ 0.129851] pci 0000:03:00.0: reg 30 32bit mmio: [0xfe9e0000-0xfe9effff]
[ 0.129880] pci 0000:03:00.0: PME# supported from D3hot
[ 0.129889] pci 0000:03:00.0: PME# disabled
[ 0.129940] pci 0000:03:00.1: reg 10 io port: [0xcc00-0xcc07]
[ 0.129949] pci 0000:03:00.1: reg 14 io port: [0xc880-0xc883]
[ 0.129957] pci 0000:03:00.1: reg 18 io port: [0xc800-0xc807]
[ 0.129965] pci 0000:03:00.1: reg 1c io port: [0xc480-0xc483]
[ 0.129974] pci 0000:03:00.1: reg 20 io port: [0xc400-0xc40f]
[ 0.130064] pci 0000:00:1c.4: bridge io port: [0xc000-0xcfff]
[ 0.130067] pci 0000:00:1c.4: bridge 32bit mmio: [0xfe900000-0xfe9fffff]
[ 0.130125] pci 0000:04:00.0: reg 10 io port: [0xd800-0xd8ff]
[ 0.130145] pci 0000:04:00.0: reg 18 64bit mmio: [0xfeaff000-0xfeafffff]
[ 0.130166] pci 0000:04:00.0: reg 30 32bit mmio: [0xfeac0000-0xfeadffff]
[ 0.130209] pci 0000:04:00.0: supports D1 D2
[ 0.130211] pci 0000:04:00.0: PME# supported from D1 D2 D3hot D3cold
[ 0.130220] pci 0000:04:00.0: PME# disabled
[ 0.130266] pci 0000:00:1c.5: bridge io port: [0xd000-0xdfff]
[ 0.130270] pci 0000:00:1c.5: bridge 32bit mmio: [0xfea00000-0xfeafffff]
[ 0.130303] pci 0000:05:00.0: reg 10 32bit mmio: [0xfebff000-0xfebfffff]
[ 0.130309] pci 0000:05:00.0: reg 14 io port: [0xec00-0xec3f]
[ 0.130315] pci 0000:05:00.0: reg 18 32bit mmio: [0xfebc0000-0xfebdffff]
[ 0.130333] pci 0000:05:00.0: reg 30 32bit mmio: [0xfebe0000-0xfebeffff]
[ 0.130350] pci 0000:05:00.0: supports D1 D2
[ 0.130352] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.130359] pci 0000:05:00.0: PME# disabled
[ 0.130397] pci 0000:05:04.0: reg 10 32bit mmio: [0xfebfe800-0xfebfefff]
[ 0.130403] pci 0000:05:04.0: reg 14 io port: [0xe880-0xe8ff]
[ 0.130442] pci 0000:05:04.0: supports D2
[ 0.130444] pci 0000:05:04.0: PME# supported from D2 D3hot D3cold
[ 0.130451] pci 0000:05:04.0: PME# disabled
[ 0.130493] pci 0000:00:1e.0: transparent bridge
[ 0.130500] pci 0000:00:1e.0: bridge io port: [0xe000-0xefff]
[ 0.130503] pci 0000:00:1e.0: bridge 32bit mmio: [0xfeb00000-0xfebfffff]
[ 0.130524] pci_bus 0000:00: on NUMA node 0
[ 0.130529] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.130668] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
[ 0.130773] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
[ 0.130834] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT]
[ 0.130892] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P9._PRT]
[ 0.145066] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[ 0.145189] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 0.145312] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 *14 15)
[ 0.145433] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 0.145553] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[ 0.145673] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 *15)
[ 0.145793] ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 7 10 11 12 14 15)
[ 0.146068] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *7 10 11 12 14 15)
[ 0.146126] SCSI subsystem initialized
[ 0.146126] libata version 3.00 loaded.
[ 0.146126] usbcore: registered new interface driver usbfs
[ 0.146126] usbcore: registered new interface driver hub
[ 0.146126] usbcore: registered new device driver usb
[ 0.146126] PCI: Using ACPI for IRQ routing
[ 0.155043] pnp: PnP ACPI init
[ 0.155058] ACPI: bus type pnp registered
[ 0.159165] pnp: PnP ACPI: found 17 devices
[ 0.159171] ACPI: ACPI bus type pnp unregistered
[ 0.159182] system 00:01: iomem range 0xfed14000-0xfed19fff has been reserved
[ 0.159193] system 00:0a: ioport range 0xa10-0xaef has been reserved
[ 0.159199] system 00:0a: ioport range 0xae0-0xaef has been reserved
[ 0.159208] system 00:0b: ioport range 0x4d0-0x4d1 has been reserved
[ 0.159214] system 00:0b: ioport range 0x800-0x87f has been reserved
[ 0.159221] system 00:0b: ioport range 0x480-0x4bf has been reserved
[ 0.159227] system 00:0b: iomem range 0xfed1c000-0xfed1ffff has been reserved
[ 0.159234] system 00:0b: iomem range 0xfed20000-0xfed8ffff has been reserved
[ 0.159243] system 00:0d: iomem range 0xffc00000-0xffefffff has been reserved
[ 0.159252] system 00:0e: iomem range 0xfec00000-0xfec00fff could not be reserved
[ 0.159260] system 00:0e: iomem range 0xfee00000-0xfee00fff has been reserved
[ 0.159269] system 00:0f: iomem range 0xe0000000-0xefffffff has been reserved
[ 0.159278] system 00:10: iomem range 0x0-0x9ffff could not be reserved
[ 0.159284] system 00:10: iomem range 0xc0000-0xcffff has been reserved
[ 0.159290] system 00:10: iomem range 0xe0000-0xfffff could not be reserved
[ 0.159297] system 00:10: iomem range 0x100000-0xcfffffff could not be reserved
[ 0.164187] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
[ 0.164194] pci 0000:00:01.0: IO window: 0xb000-0xbfff
[ 0.164201] pci 0000:00:01.0: MEM window: 0xfc000000-0xfe8fffff
[ 0.164207] pci 0000:00:01.0: PREFETCH window: 0x000000d0000000-0x000000dfffffff
[ 0.164217] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
[ 0.164223] pci 0000:00:1c.0: IO window: disabled
[ 0.164230] pci 0000:00:1c.0: MEM window: disabled
[ 0.164236] pci 0000:00:1c.0: PREFETCH window: disabled
[ 0.164245] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:03
[ 0.164251] pci 0000:00:1c.4: IO window: 0xc000-0xcfff
[ 0.164259] pci 0000:00:1c.4: MEM window: 0xfe900000-0xfe9fffff
[ 0.164266] pci 0000:00:1c.4: PREFETCH window: disabled
[ 0.164274] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:04
[ 0.164280] pci 0000:00:1c.5: IO window: 0xd000-0xdfff
[ 0.164288] pci 0000:00:1c.5: MEM window: 0xfea00000-0xfeafffff
[ 0.164295] pci 0000:00:1c.5: PREFETCH window: disabled
[ 0.164304] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:05
[ 0.164310] pci 0000:00:1e.0: IO window: 0xe000-0xefff
[ 0.164318] pci 0000:00:1e.0: MEM window: 0xfeb00000-0xfebfffff
[ 0.164325] pci 0000:00:1e.0: PREFETCH window: 0x000000f0000000-0x000000f00fffff
[ 0.164342] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.164349] pci 0000:00:01.0: setting latency timer to 64
[ 0.164356] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.164363] pci 0000:00:1c.0: setting latency timer to 64
[ 0.164369] pci 0000:00:1c.4: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.164376] pci 0000:00:1c.4: setting latency timer to 64
[ 0.164382] pci 0000:00:1c.5: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[ 0.164389] pci 0000:00:1c.5: setting latency timer to 64
[ 0.164394] pci 0000:00:1e.0: setting latency timer to 64
[ 0.164398] pci_bus 0000:00: resource 0 io: [0x00-0xffff]
[ 0.164400] pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffffffffffff]
[ 0.164402] pci_bus 0000:01: resource 0 io: [0xb000-0xbfff]
[ 0.164404] pci_bus 0000:01: resource 1 mem: [0xfc000000-0xfe8fffff]
[ 0.164406] pci_bus 0000:01: resource 2 pref mem [0xd0000000-0xdfffffff]
[ 0.164409] pci_bus 0000:03: resource 0 io: [0xc000-0xcfff]
[ 0.164411] pci_bus 0000:03: resource 1 mem: [0xfe900000-0xfe9fffff]
[ 0.164413] pci_bus 0000:04: resource 0 io: [0xd000-0xdfff]
[ 0.164415] pci_bus 0000:04: resource 1 mem: [0xfea00000-0xfeafffff]
[ 0.164417] pci_bus 0000:05: resource 0 io: [0xe000-0xefff]
[ 0.164419] pci_bus 0000:05: resource 1 mem: [0xfeb00000-0xfebfffff]
[ 0.164421] pci_bus 0000:05: resource 2 pref mem [0xf0000000-0xf00fffff]
[ 0.164423] pci_bus 0000:05: resource 3 io: [0x00-0xffff]
[ 0.164425] pci_bus 0000:05: resource 4 mem: [0x000000-0xffffffffffffffff]
[ 0.164438] NET: Registered protocol family 2
[ 0.175320] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.176457] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[ 0.178204] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 0.178762] TCP: Hash tables configured (established 262144 bind 65536)
[ 0.178769] TCP reno registered
[ 0.181438] NET: Registered protocol family 1
[ 0.181507] Trying to unpack rootfs image as initramfs...
[ 0.323858] Freeing initrd memory: 5845k freed
[ 0.327609] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 0.327820] audit: initializing netlink socket (disabled)
[ 0.327837] type=2000 audit(1250706533.327:1): initialized
[ 0.330179] VFS: Disk quotas dquot_6.5.2
[ 0.330232] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.330845] msgmni has been set to 11929
[ 0.330986] alg: No test for stdrng (krng)
[ 0.330996] io scheduler noop registered
[ 0.331003] io scheduler anticipatory registered
[ 0.331008] io scheduler deadline registered (default)
[ 0.331020] io scheduler cfq registered
[ 0.331145] pci 0000:01:00.0: Boot video device
[ 0.331161] pci 0000:05:00.0: Firmware left e100 interrupts enabled; disabling
[ 0.331297] pcieport-driver 0000:00:01.0: irq 24 for MSI/MSI-X
[ 0.331308] pcieport-driver 0000:00:01.0: setting latency timer to 64
[ 0.331440] pcieport-driver 0000:00:1c.0: irq 25 for MSI/MSI-X
[ 0.331451] pcieport-driver 0000:00:1c.0: setting latency timer to 64
[ 0.331610] pcieport-driver 0000:00:1c.4: irq 26 for MSI/MSI-X
[ 0.331621] pcieport-driver 0000:00:1c.4: setting latency timer to 64
[ 0.331783] pcieport-driver 0000:00:1c.5: irq 27 for MSI/MSI-X
[ 0.331794] pcieport-driver 0000:00:1c.5: setting latency timer to 64
[ 0.332185] vesafb: framebuffer at 0xd0000000, mapped to 0xffffc20010100000, using 3072k, total 262144k
[ 0.332194] vesafb: mode is 1024x768x16, linelength=2048, pages=1
[ 0.332200] vesafb: scrolling: redraw
[ 0.332205] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[ 0.344339] Console: switching to colour frame buffer device 128x48
[ 0.355413] fb0: VESA VGA frame buffer device
[ 0.355636] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[ 0.355807] ACPI: Power Button [PWRF]
[ 0.355980] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1
[ 0.356171] ACPI: Power Button [PWRB]
[ 0.356751] ACPI: SSDT 00000000cffbe0b0 00277 (v01 DpgPmm P001Ist 00000011 INTL 20051117)
[ 0.357236] processor ACPI_CPU:00: registered as cooling_device0
[ 0.357773] ACPI: SSDT 00000000cffbe540 00277 (v01 DpgPmm P002Ist 00000012 INTL 20051117)
[ 0.358242] processor ACPI_CPU:01: registered as cooling_device1
[ 0.386443] Non-volatile memory driver v1.3
[ 0.386638] Linux agpgart interface v0.103
[ 0.386823] Floppy drive(s): fd0 is 1.44M
[ 0.401137] FDC 0 is a post-1991 82077
[ 0.403337] brd: module loaded
[ 0.404014] loop: module loaded
[ 0.404170] Driver 'sd' needs updating - please use bus_type methods
[ 0.404356] ahci 0000:00:1f.2: version 3.0
[ 0.404370] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.404572] ahci 0000:00:1f.2: irq 28 for MSI/MSI-X
[ 0.404614] ahci: SSS flag set, parallel bus scan disabled
[ 0.407056] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl RAID mode
[ 0.409668] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part ems
[ 0.412392] ahci 0000:00:1f.2: setting latency timer to 64
[ 0.417770] scsi0 : ahci
[ 0.420629] scsi1 : ahci
[ 0.423454] scsi2 : ahci
[ 0.426301] scsi3 : ahci
[ 0.429142] scsi4 : ahci
[ 0.431992] scsi5 : ahci
[ 0.434936] ata1: SATA max UDMA/133 abar m2048@0xfbfff000 port 0xfbfff100 irq 28
[ 0.437952] ata2: SATA max UDMA/133 abar m2048@0xfbfff000 port 0xfbfff180 irq 28
[ 0.440976] ata3: SATA max UDMA/133 abar m2048@0xfbfff000 port 0xfbfff200 irq 28
[ 0.444013] ata4: SATA max UDMA/133 abar m2048@0xfbfff000 port 0xfbfff280 irq 28
[ 0.447062] ata5: SATA max UDMA/133 abar m2048@0xfbfff000 port 0xfbfff300 irq 28
[ 0.450124] ata6: SATA max UDMA/133 abar m2048@0xfbfff000 port 0xfbfff380 irq 28
[ 0.453221] ahci 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.456436] ahci 0000:03:00.0: JMB361 has only one port, port_map 0x3 -> 0x1
[ 0.470776] ahci 0000:03:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x1 impl SATA mode
[ 0.474236] ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
[ 0.477746] ahci 0000:03:00.0: setting latency timer to 64
[ 0.477851] scsi6 : ahci
[ 0.481451] scsi7 : ahci
[ 0.485072] ata7: SATA max UDMA/133 abar m8192@0xfe9fe000 port 0xfe9fe100 irq 16
[ 0.488833] ata8: DUMMY
[ 0.492673] pata_jmicron 0000:03:00.1: enabling device (0000 -> 0001)
[ 0.496640] pata_jmicron 0000:03:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 0.500622] pata_jmicron 0000:03:00.1: setting latency timer to 64
[ 0.500678] scsi8 : pata_jmicron
[ 0.504633] scsi9 : pata_jmicron
[ 0.508441] ata9: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 17
[ 0.512257] ata10: PATA max UDMA/100 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 17
[ 0.516226] usbmon: debugfs is not available
[ 0.519912] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.523647] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 0.527356] ehci_hcd 0000:00:1a.7: setting latency timer to 64
[ 0.527359] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[ 0.530996] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[ 0.538457] ehci_hcd 0000:00:1a.7: debug port 1
[ 0.541950] ehci_hcd 0000:00:1a.7: cache line size of 32 is not supported
[ 0.541961] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfbfffc00
[ 0.554855] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[ 0.558411] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.561997] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.565629] usb usb1: Product: EHCI Host Controller
[ 0.569276] usb usb1: Manufacturer: Linux 2.6.30-patched-r5 ehci_hcd
[ 0.572945] usb usb1: SerialNumber: 0000:00:1a.7
[ 0.576635] usb usb1: configuration #1 chosen from 1 choice
[ 0.580269] hub 1-0:1.0: USB hub found
[ 0.583778] hub 1-0:1.0: 4 ports detected
[ 0.587391] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 0.590886] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[ 0.590888] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[ 0.594437] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[ 0.601979] ehci_hcd 0000:00:1d.7: debug port 1
[ 0.605636] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
[ 0.605647] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfbfff800
[ 0.618957] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[ 0.622780] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.626570] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.630446] usb usb2: Product: EHCI Host Controller
[ 0.634368] usb usb2: Manufacturer: Linux 2.6.30-patched-r5 ehci_hcd
[ 0.638406] usb usb2: SerialNumber: 0000:00:1d.7
[ 0.642539] usb usb2: configuration #1 chosen from 1 choice
[ 0.646738] hub 2-0:1.0: USB hub found
[ 0.650818] hub 2-0:1.0: 6 ports detected
[ 0.655016] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.659162] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.663271] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[ 0.663274] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[ 0.667340] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[ 0.671519] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000ac00
[ 0.675632] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.679747] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.683850] usb usb3: Product: UHCI Host Controller
[ 0.687932] usb usb3: Manufacturer: Linux 2.6.30-patched-r5 uhci_hcd
[ 0.692019] usb usb3: SerialNumber: 0000:00:1a.0
[ 0.696204] usb usb3: configuration #1 chosen from 1 choice
[ 0.700349] hub 3-0:1.0: USB hub found
[ 0.704385] hub 3-0:1.0: 2 ports detected
[ 0.708483] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
[ 0.712508] uhci_hcd 0000:00:1a.1: setting latency timer to 64
[ 0.712511] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[ 0.716488] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[ 0.720509] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000a880
[ 0.724500] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.728519] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.732578] usb usb4: Product: UHCI Host Controller
[ 0.736643] usb usb4: Manufacturer: Linux 2.6.30-patched-r5 uhci_hcd
[ 0.740710] usb usb4: SerialNumber: 0000:00:1a.1
[ 0.744798] usb usb4: configuration #1 chosen from 1 choice
[ 0.748847] hub 4-0:1.0: USB hub found
[ 0.752815] hub 4-0:1.0: 2 ports detected
[ 0.756878] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 0.760910] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[ 0.760913] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[ 0.764926] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
[ 0.769016] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000a800
[ 0.773048] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.777116] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.781196] usb usb5: Product: UHCI Host Controller
[ 0.785243] usb usb5: Manufacturer: Linux 2.6.30-patched-r5 uhci_hcd
[ 0.789364] usb usb5: SerialNumber: 0000:00:1d.0
[ 0.793539] usb usb5: configuration #1 chosen from 1 choice
[ 0.797670] hub 5-0:1.0: USB hub found
[ 0.801726] hub 5-0:1.0: 2 ports detected
[ 0.805858] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.809940] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[ 0.809943] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[ 0.814003] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
[ 0.818112] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000a480
[ 0.822187] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.826343] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.830484] usb usb6: Product: UHCI Host Controller
[ 0.834574] usb usb6: Manufacturer: Linux 2.6.30-patched-r5 uhci_hcd
[ 0.838706] usb usb6: SerialNumber: 0000:00:1d.1
[ 0.842861] usb usb6: configuration #1 chosen from 1 choice
[ 0.847007] hub 6-0:1.0: USB hub found
[ 0.851041] hub 6-0:1.0: 2 ports detected
[ 0.855171] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 0.859229] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[ 0.859232] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[ 0.863272] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
[ 0.867332] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000a400
[ 0.871376] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.875446] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.879575] usb usb7: Product: UHCI Host Controller
[ 0.883649] usb usb7: Manufacturer: Linux 2.6.30-patched-r5 uhci_hcd
[ 0.887770] usb usb7: SerialNumber: 0000:00:1d.2
[ 0.891913] usb usb7: configuration #1 chosen from 1 choice
[ 0.896049] hub 7-0:1.0: USB hub found
[ 0.900075] hub 7-0:1.0: 2 ports detected
[ 0.904285] usbcore: registered new interface driver libusual
[ 0.908366] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
[ 0.914503] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.918576] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.922711] mice: PS/2 mouse device common for all mice
[ 0.926965] input: PC Speaker as /devices/platform/pcspkr/input/input2
[ 0.931177] rtc_cmos 00:03: RTC can wake from S4
[ 0.935325] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[ 0.939456] rtc0: alarms up to one month, y3k, 114 bytes nvram
[ 0.943610] md: linear personality registered for level -1
[ 0.947745] md: raid0 personality registered for level 0
[ 0.951841] md: raid1 personality registered for level 1
[ 0.955862] md: multipath personality registered for level -4
[ 0.959897] cpuidle: using governor ladder
[ 0.963871] cpuidle: using governor menu
[ 0.968383] usbcore: registered new interface driver hiddev
[ 0.972366] usbcore: registered new interface driver usbhid
[ 0.976248] usbhid: v2.6:USB HID core driver
[ 0.980232] TCP bic registered
[ 0.984054] TCP cubic registered
[ 0.987855] TCP westwood registered
[ 0.991605] TCP highspeed registered
[ 0.995314] TCP hybla registered
[ 0.998936] TCP htcp registered
[ 1.002506] TCP vegas registered
[ 1.006099] TCP veno registered
[ 1.009545] TCP scalable registered
[ 1.012952] TCP lp registered
[ 1.016790] TCP yeah registered
[ 1.020104] TCP illinois registered
[ 1.023438] NET: Registered protocol family 17
[ 1.024617] ata9.00: ATAPI: HL-DT-ST GCE-8527B, 1.04, max UDMA/33
[ 1.024651] ata9.01: ATAPI: TSSTcorpCD/DVDW SH-S182M, SB06, max UDMA/33
[ 1.033976] NET: Registered protocol family 15
[ 1.057894] ata9.00: configured for UDMA/33
[ 1.067893] ata9.01: configured for UDMA/33
[ 1.090351] Switched to high resolution mode on CPU 1
[ 1.091097] Switched to high resolution mode on CPU 0
[ 1.092055] ata7: SATA link down (SStatus 0 SControl 300)
[ 1.092098] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.092641] ata1.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 1.092644] ata1.00: 488397168 sectors, multi 16: LBA48
[ 1.093277] ata1.00: configured for UDMA/133
[ 1.110570] scsi 0:0:0:0: Direct-Access ATA WDC WD2500KS-00M 02.0 PQ: 0 ANSI: 5
[ 1.114714] sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors: (250 GB/232 GiB)
[ 1.118621] sd 0:0:0:0: [sda] Write Protect is off
[ 1.122398] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.122425] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.126401] sda: sda1 sda2
[ 1.147955] sd 0:0:0:0: [sda] Attached SCSI disk
[ 1.469012] usb 5-1: new low speed USB device using uhci_hcd and address 2
[ 1.638977] usb 5-1: New USB device found, idVendor=046d, idProduct=c312
[ 1.642910] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.646869] usb 5-1: Product: USB Multimedia Keyboard
[ 1.650779] usb 5-1: Manufacturer: BTC
[ 1.654709] usb 5-1: configuration #1 chosen from 1 choice
[ 1.676332] input: BTC USB Multimedia Keyboard as /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input3
[ 1.680667] generic-usb 0003:046D:C312.0001: input,hidraw0: USB HID v1.10 Keyboard [BTC USB Multimedia Keyboard] on usb-0000:00:1d.0-1/input0
[ 1.730083] input: BTC USB Multimedia Keyboard as /devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.1/input/input4
[ 1.735029] generic-usb 0003:046D:C312.0002: input,hiddev96,hidraw1: USB HID v1.10 Device [BTC USB Multimedia Keyboard] on usb-0000:00:1d.0-1/input1
[ 1.837016] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.842542] ata2.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 1.847626] ata2.00: 488397168 sectors, multi 16: LBA48
[ 1.853381] ata2.00: configured for UDMA/133
[ 1.880079] scsi 1:0:0:0: Direct-Access ATA WDC WD2500KS-00M 02.0 PQ: 0 ANSI: 5
[ 1.885628] sd 1:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB)
[ 1.891057] sd 1:0:0:0: [sdb] Write Protect is off
[ 1.896471] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1.896503] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.902211] sdb: sdb1 sdb2 < >
[ 1.938583] sd 1:0:0:0: [sdb] Attached SCSI disk
[ 1.954042] usb 5-2: new low speed USB device using uhci_hcd and address 3
[ 2.117937] usb 5-2: New USB device found, idVendor=0764, idProduct=0501
[ 2.123823] usb 5-2: New USB device strings: Mfr=3, Product=1, SerialNumber=0
[ 2.129766] usb 5-2: Product: CP 1350C
[ 2.134998] usb 5-2: Manufacturer: CPS
[ 2.140192] usb 5-2: configuration #1 chosen from 1 choice
[ 2.303066] generic-usb 0003:0764:0501.0003: hiddev97,hidraw2: USB HID v1.10 Device [CPS CP 1350C] on usb-0000:00:1d.0-2/input0
[ 2.521011] usb 6-1: new low speed USB device using uhci_hcd and address 2
[ 2.602053] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.610142] ata3.00: ATA-8: WDC WD5000AAKS-22A7B0, 01.03B01, max UDMA/133
[ 2.616527] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 2.624184] ata3.00: configured for UDMA/133
[ 2.641079] scsi 2:0:0:0: Direct-Access ATA WDC WD5000AAKS-2 01.0 PQ: 0 ANSI: 5
[ 2.647820] sd 2:0:0:0: [sdc] 976773168 512-byte hardware sectors: (500 GB/465 GiB)
[ 2.654327] sd 2:0:0:0: [sdc] Write Protect is off
[ 2.660711] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 2.660743] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.667365] sdc: sdc1 sdc2
[ 2.688278] sd 2:0:0:0: [sdc] Attached SCSI disk
[ 2.708030] usb 6-1: New USB device found, idVendor=046d, idProduct=c00c
[ 2.714495] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.720927] usb 6-1: Product: USB Mouse
[ 2.727287] usb 6-1: Manufacturer: Logitech
[ 2.733699] usb 6-1: configuration #1 chosen from 1 choice
[ 2.758341] input: Logitech USB Mouse as /devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0/input/input5
[ 2.765097] generic-usb 0003:046D:C00C.0004: input,hidraw3: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-0000:00:1d.1-1/input0
[ 3.370015] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3.377091] ata4.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 3.383517] ata4.00: 488397168 sectors, multi 16: LBA48
[ 3.390421] ata4.00: configured for UDMA/133
[ 3.417096] scsi 3:0:0:0: Direct-Access ATA WDC WD2500KS-00M 02.0 PQ: 0 ANSI: 5
[ 3.423381] sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors: (250 GB/232 GiB)
[ 3.429478] sd 3:0:0:0: [sdd] Write Protect is off
[ 3.435479] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[ 3.435517] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 3.441740] sdd: unknown partition table
[ 3.463357] sd 3:0:0:0: [sdd] Attached SCSI disk
[ 4.162015] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 4.168883] ata5.00: ATA-8: WDC WD5000AAKS-00A7B0, 01.03B01, max UDMA/133
[ 4.174963] ata5.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 4.181959] ata5.00: configured for UDMA/133
[ 4.209073] scsi 4:0:0:0: Direct-Access ATA WDC WD5000AAKS-0 01.0 PQ: 0 ANSI: 5
[ 4.215403] sd 4:0:0:0: [sde] 976773168 512-byte hardware sectors: (500 GB/465 GiB)
[ 4.221521] sd 4:0:0:0: [sde] Write Protect is off
[ 4.227559] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
[ 4.227584] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.233837] sde: sde1 sde2
[ 4.246165] sd 4:0:0:0: [sde] Attached SCSI disk
[ 4.938014] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 4.944756] ata6.00: ATA-7: WDC WD2500KS-00MJB0, 02.01C03, max UDMA/133
[ 4.950880] ata6.00: 488397168 sectors, multi 16: LBA48
[ 4.957477] ata6.00: configured for UDMA/133
[ 4.985075] scsi 5:0:0:0: Direct-Access ATA WDC WD2500KS-00M 02.0 PQ: 0 ANSI: 5
[ 4.991370] sd 5:0:0:0: [sdf] 488397168 512-byte hardware sectors: (250 GB/232 GiB)
[ 4.997428] sd 5:0:0:0: [sdf] Write Protect is off
[ 5.003331] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[ 5.003356] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 5.009477] sdf:<5>scsi 8:0:0:0: CD-ROM HL-DT-ST CD-RW GCE-8527B 1.04 PQ: 0 ANSI: 5
[ 5.015575] scsi 8:0:1:0: CD-ROM TSSTcorp CD/DVDW SH-S182M SB06 PQ: 0 ANSI: 5
[ 5.024442] sdf1 sdf2
[ 5.029907] sd 5:0:0:0: [sdf] Attached SCSI disk
[ 5.183707] rtc_cmos 00:03: setting system clock to 2009-08-19 18:28:59 UTC (1250706539)
[ 5.189798] Freeing unused kernel memory: 384k freed
[ 5.318498] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
[ 5.328988] fuse init (API version 7.11)
[ 5.341688] xor: automatically using best checksumming function: generic_sse
[ 5.346127] generic_sse: 8392.000 MB/sec
[ 5.346129] xor: using function: generic_sse (8392.000 MB/sec)
[ 5.346454] async_tx: api initialized (async)
[ 5.364133] raid6: int64x1 1800 MB/s
[ 5.381142] raid6: int64x2 2714 MB/s
[ 5.398149] raid6: int64x4 2078 MB/s
[ 5.415145] raid6: int64x8 1847 MB/s
[ 5.432140] raid6: sse2x1 4210 MB/s
[ 5.449142] raid6: sse2x2 4476 MB/s
[ 5.466130] raid6: sse2x4 7144 MB/s
[ 5.466132] raid6: using algorithm sse2x4 (7144 MB/s)
[ 5.467793] md: raid6 personality registered for level 6
[ 5.467795] md: raid5 personality registered for level 5
[ 5.467797] md: raid4 personality registered for level 4
[ 5.472406] md: raid10 personality registered for level 10
[ 5.615588] Driver 'sr' needs updating - please use bus_type methods
[ 5.622646] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 5.622667] r8169 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 5.622688] r8169 0000:04:00.0: setting latency timer to 64
[ 5.622841] r8169 0000:04:00.0: irq 29 for MSI/MSI-X
[ 5.622952] eth0: RTL8168b/8111b at 0xffffc200100d4000, 00:16:17:d3:d0:e7, XID 38000000 IRQ 29
[ 5.623060] sr0: scsi3-mmc drive: 40x/52x writer cd/rw xa/form2 cdda tray
[ 5.623063] Uniform CD-ROM driver Revision: 3.20
[ 5.623139] sr 8:0:0:0: Attached scsi CD-ROM sr0
[ 5.625511] sr1: scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray
[ 5.625565] sr 8:0:1:0: Attached scsi CD-ROM sr1
[ 5.627819] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 5.627853] sd 1:0:0:0: Attached scsi generic sg1 type 0
[ 5.627888] sd 2:0:0:0: Attached scsi generic sg2 type 0
[ 5.627922] sd 3:0:0:0: Attached scsi generic sg3 type 0
[ 5.627957] sd 4:0:0:0: Attached scsi generic sg4 type 0
[ 5.628005] sd 5:0:0:0: Attached scsi generic sg5 type 0
[ 5.628039] sr 8:0:0:0: Attached scsi generic sg6 type 5
[ 5.628071] sr 8:0:1:0: Attached scsi generic sg7 type 5
[ 5.658545] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[ 5.658548] e100: Copyright(c) 1999-2006 Intel Corporation
[ 5.658577] e100 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 5.701394] e100 0000:05:00.0: PME# disabled
[ 5.701480] e100: eth1: e100_probe: addr 0xfebff000, irq 16, MAC addr 00:02:b3:8d:48:07
[ 5.701509] ohci1394 0000:05:04.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 5.755203] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20] MMIO=[febfe800-febfefff] Max Packet=[2048] IR/IT contexts=[4/8]
[ 5.849984] md: bind<sdc1>
[ 5.877118] md: bind<sdc2>
[ 5.902731] md: bind<sde1>
[ 5.904573] raid1: raid set md2 active with 2 out of 2 mirrors
[ 5.909643] md: bind<sdf1>
[ 5.911421] md: bind<sdf2>
[ 5.932572] md: bind<sde2>
[ 5.933917] md3: setting max_sectors to 128, segment boundary to 32767
[ 5.933921] raid0: looking at sde2
[ 5.933923] raid0: comparing sde2(976350208)<6> with sde2(976350208)
[ 5.933926] raid0: END
[ 5.933927] raid0: ==> UNIQUE
[ 5.933928] raid0: 1 zones
[ 5.933930] raid0: looking at sdc2
[ 5.933932] raid0: comparing sdc2(976350208)<6> with sde2(976350208)
[ 5.933935] raid0: EQUAL
[ 5.933936] raid0: FINAL 1 zones
[ 5.933938] raid0: done.
[ 5.933940] raid0 : md_size is 1952700416 sectors.
[ 5.933942] raid0 : conf->spacing is 1952700416 sectors.
[ 5.933944] raid0 : nb_zone is 1.
[ 5.933945] raid0 : Allocating 8 bytes for hash.
[ 5.958943] md: bind<sda2>
[ 5.959117] md: bind<sda1>
[ 5.979243] md1: setting max_sectors to 128, segment boundary to 32767
[ 5.979247] raid0: looking at sda2
[ 5.979249] raid0: comparing sda2(487990272)<6> with sda2(487990272)
[ 5.979252] raid0: END
[ 5.979253] raid0: ==> UNIQUE
[ 5.979255] raid0: 1 zones
[ 5.979256] raid0: looking at sdf2
[ 5.979258] raid0: comparing sdf2(487990272)<6> with sda2(487990272)
[ 5.979260] raid0: EQUAL
[ 5.979262] raid0: FINAL 1 zones
[ 5.979264] raid0: done.
[ 5.979266] raid0 : md_size is 975980544 sectors.
[ 5.979269] raid0 : conf->spacing is 975980544 sectors.
[ 5.979270] raid0 : nb_zone is 1.
[ 5.979272] raid0 : Allocating 8 bytes for hash.
[ 5.980408] raid1: raid set md0 active with 2 out of 2 mirrors
[ 6.030719] md2: unknown partition table
[ 6.037804] md1: unknown partition table
[ 6.041751] md0: unknown partition table
[ 6.068642] md3: unknown partition table
[ 7.018162] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0010dc00010457f8]
[ 7.061663] PM: Starting manual resume from disk
[ 7.064424] EXT4-fs: barriers enabled
[ 7.074626] kjournald2 starting: pid 3223, dev dm-5:8, commit interval 5 seconds
[ 7.074639] EXT4-fs: delayed allocation enabled
[ 7.074642] EXT4-fs: file extents enabled
[ 7.074788] EXT4-fs: mballoc enabled
[ 7.074802] EXT4-fs: mounted filesystem dm-5 with ordered data mode
[ 8.394730] udev: starting version 141
[ 8.607493] nvidia: module license 'NVIDIA' taints kernel.
[ 8.607498] Disabling lock debugging due to kernel taint
[ 8.634600] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 8.634725] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 8.640466] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 8.994059] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 8.994684] HDA Intel 0000:00:1b.0: irq 30 for MSI/MSI-X
[ 8.994715] HDA Intel 0000:00:1b.0: setting latency timer to 64
[ 9.057771] hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
[ 9.057942] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input6
[ 9.083984] nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 9.083995] nvidia 0000:01:00.0: setting latency timer to 64
[ 9.084354] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 185.18.31 Tue Jul 28 17:52:27 PDT 2009
[ 10.440559] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 10.486046] f71882fg: Found f71882fg chip at 0xa10, revision 32
[ 10.486316] f71882fg f71882fg.2576: Fan: 1 is in duty-cycle mode
[ 10.486320] f71882fg f71882fg.2576: Fan: 2 is in duty-cycle mode
[ 10.486323] f71882fg f71882fg.2576: Fan: 3 is in duty-cycle mode
[ 10.486326] f71882fg f71882fg.2576: Fan: 4 is in duty-cycle mode
[ 10.500843] netconsole: local port 6665
[ 10.500848] netconsole: local IP 192.168.0.1
[ 10.500850] netconsole: interface eth0
[ 10.500852] netconsole: remote port 514
[ 10.500855] netconsole: remote IP 192.168.0.221
[ 10.500857] netconsole: remote ethernet address 00:0d:88:64:b8:d3
[ 10.500861] netconsole: device eth0 not up yet, forcing it
[ 10.501083] r8169: eth0: link up
[ 10.501089] r8169: eth0: link up
[ 10.502309] netconsole: carrier detect appears untrustworthy, waiting 4 seconds
[ 10.704236] e100: eth1 NIC Link is Up 100 Mbps Full Duplex
[ 14.506026] console [netcon0] enabled
[ 14.512246] netconsole: network logging started
[ 14.770052] Adding 3145720k swap on /dev/mapper/vg0-swap. Priority:-1 extents:1 across:3145720k
[ 15.387243] EXT4 FS on dm-5, internal journal on dm-5:8
[ 16.527199] EXT4-fs: barriers enabled
[ 16.536649] kjournald2 starting: pid 5389, dev dm-3:8, commit interval 5 seconds
[ 16.536844] EXT4 FS on dm-3, internal journal on dm-3:8
[ 16.536847] EXT4-fs: delayed allocation enabled
[ 16.536850] EXT4-fs: file extents enabled
[ 16.537244] EXT4-fs: mballoc enabled
[ 16.537260] EXT4-fs: mounted filesystem dm-3 with ordered data mode
[ 16.554360] EXT4-fs: barriers enabled
[ 16.564822] kjournald2 starting: pid 5390, dev dm-0:8, commit interval 5 seconds
[ 16.565007] EXT4 FS on dm-0, internal journal on dm-0:8
[ 16.565010] EXT4-fs: delayed allocation enabled
[ 16.565012] EXT4-fs: file extents enabled
[ 16.567658] EXT4-fs: mballoc enabled
[ 16.567673] EXT4-fs: mounted filesystem dm-0 with ordered data mode
[ 16.578518] EXT4-fs: barriers enabled
[ 16.584093] kjournald2 starting: pid 5391, dev dm-2:8, commit interval 5 seconds
[ 16.584296] EXT4 FS on dm-2, internal journal on dm-2:8
[ 16.584298] EXT4-fs: delayed allocation enabled
[ 16.584300] EXT4-fs: file extents enabled
[ 16.584451] EXT4-fs: mballoc enabled
[ 16.584464] EXT4-fs: mounted filesystem dm-2 with ordered data mode
[ 16.588407] EXT4-fs: barriers enabled
[ 16.591760] kjournald2 starting: pid 5392, dev dm-4:8, commit interval 5 seconds
[ 16.591961] EXT4 FS on dm-4, internal journal on dm-4:8
[ 16.591964] EXT4-fs: delayed allocation enabled
[ 16.591966] EXT4-fs: file extents enabled
[ 16.592052] EXT4-fs: mballoc enabled
[ 16.592065] EXT4-fs: mounted filesystem dm-4 with ordered data mode
[ 16.593618] EXT4-fs: barriers enabled
[ 16.598778] kjournald2 starting: pid 5393, dev dm-7:8, commit interval 5 seconds
[ 16.598976] EXT4 FS on dm-7, internal journal on dm-7:8
[ 16.598979] EXT4-fs: delayed allocation enabled
[ 16.598981] EXT4-fs: file extents enabled
[ 16.599676] EXT4-fs: mballoc enabled
[ 16.599689] EXT4-fs: mounted filesystem dm-7 with ordered data mode
[ 16.613323] kjournald starting. Commit interval 5 seconds
[ 16.662738] EXT3 FS on md2, internal journal
[ 16.662744] EXT3-fs: mounted filesystem with writeback data mode.
[ 17.511110] EXT4-fs: barriers enabled
[ 17.521147] kjournald2 starting: pid 5410, dev dm-10:8, commit interval 5 seconds
[ 17.521332] EXT4 FS on dm-10, internal journal on dm-10:8
[ 17.521335] EXT4-fs: delayed allocation enabled
[ 17.521337] EXT4-fs: file extents enabled
[ 17.522890] EXT4-fs: mballoc enabled
[ 17.522906] EXT4-fs: mounted filesystem dm-10 with ordered data mode
[ 22.347094] Bridge firewalling registered
[ 22.349970] device eth0 entered promiscuous mode
[ 22.352962] br0: port 1(eth0) entering learning state
[ 23.425669] NET: Registered protocol family 10
[ 23.425825] lo: Disabled Privacy Extensions
[ 33.572072] RPC: Registered udp transport module.
[ 33.572074] RPC: Registered tcp transport module.
[ 33.627093] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 33.671003] eth0: no IPv6 routers present
[ 34.065013] br0: no IPv6 routers present
[ 34.343028] eth1: no IPv6 routers present
[ 37.352007] br0: port 1(eth0) entering forwarding state
[ 40.624730] kjournald starting. Commit interval 5 seconds
[ 40.624744] EXT3 FS on loop0, internal journal
[ 40.624748] EXT3-fs: mounted filesystem with writeback data mode.
[ 41.152968] svc: failed to register lockdv1 RPC service (errno 97).
[ 43.016748] Bluetooth: Core ver 2.15
[ 43.018111] NET: Registered protocol family 31
[ 43.018114] Bluetooth: HCI device and connection manager initialized
[ 43.018117] Bluetooth: HCI socket layer initialized
[ 43.030150] Bluetooth: L2CAP ver 2.13
[ 43.030152] Bluetooth: L2CAP socket layer initialized
[ 43.036233] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 43.036236] Bluetooth: BNEP filters: protocol multicast
[ 43.053474] Bluetooth: SCO (Voice Link) ver 0.6
[ 43.053477] Bluetooth: SCO socket layer initialized
[ 43.355260] warning: `dhcpd3' uses 32-bit capabilities (legacy support in use)
[ 46.031969] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 46.032981] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
[ 46.032984] nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
[ 46.032987] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[ 46.171814] Netfilter messages via NETLINK v0.30.
[ 46.175122] ctnetlink v0.93: registering with nfnetlink.
[ 46.274012] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 46.314164] Ebtables v2.0 registered
[ 46.745444] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.756588] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.757862] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.759230] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.760447] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.761479] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.762675] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.763710] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.764928] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.765989] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.788666] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.790720] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.792690] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.794183] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.797501] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 46.808203] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.
[ 51.466763] tun: Universal TUN/TAP device driver, 1.6
[ 51.466771] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 51.554970] device tap0 entered promiscuous mode
[ 51.562932] br0: port 2(tap0) entering learning state
[ 61.943007] tap0: no IPv6 routers present
[ 66.562008] br0: port 2(tap0) entering forwarding state
[ 188.037005] tap1: no IPv6 routers present
[ 604.446194] br0: port 2(tap0) entering disabled state
[ 604.464975] br0: port 2(tap0) entering disabled state
[ 608.171021] br0: port 1(eth0) entering disabled state
[ 608.220021] device eth0 left promiscuous mode
[ 608.220027] br0: port 1(eth0) entering disabled state
[ 608.254047] e100 0000:05:00.0: PCI INT A disabled
[ 610.262158] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[ 610.262163] e100: Copyright(c) 1999-2006 Intel Corporation
[ 610.262203] e100 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 610.262212] e100: 0000:05:00.0: e100_probe: using i/o access mode
[ 610.292593] e100 0000:05:00.0: PME# disabled
[ 610.292928] e100: eth1: e100_probe: addr 0xec00, irq 16, MAC addr 00:02:b3:8d:48:07
[ 610.391181] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 612.701223] e100: eth1 NIC Link is Up 100 Mbps Full Duplex
[ 612.702538] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 623.121006] eth1: no IPv6 routers present
[ 653.265277] device eth0 entered promiscuous mode
[ 653.289450] r8169: eth0: link up
[ 653.291979] br0: port 1(eth0) entering learning state
[ 663.718008] eth0: no IPv6 routers present
[ 663.878004] br0: no IPv6 routers present
[ 668.291009] br0: port 1(eth0) entering forwarding state
[ 1328.222191] br0: port 1(eth0) entering disabled state
[ 1328.253472] device eth0 left promiscuous mode
[ 1328.253479] br0: port 1(eth0) entering disabled state
[ 1336.066201] e100 0000:05:00.0: PCI INT A disabled
[ 1339.306300] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[ 1339.306305] e100: Copyright(c) 1999-2006 Intel Corporation
[ 1339.306345] e100 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 1339.337539] e100 0000:05:00.0: PME# disabled
[ 1339.337699] e100: eth1: e100_probe: addr 0xfebff000, irq 16, MAC addr 00:02:b3:8d:48:07
[ 1339.395030] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 1341.704232] e100: eth1 NIC Link is Up 100 Mbps Full Duplex
[ 1341.705560] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1348.231171] device eth0 entered promiscuous mode
[ 1348.233317] r8169: eth0: link up
[ 1348.237116] br0: port 1(eth0) entering learning state
[ 1358.297129] br0: no IPv6 routers present
[ 1359.157130] eth0: no IPv6 routers present
[ 1363.237131] br0: port 1(eth0) entering forwarding state
[ 1384.161011] br0: port 1(eth0) entering disabled state
[ 1384.194844] device eth0 left promiscuous mode
[ 1384.194850] br0: port 1(eth0) entering disabled state
[ 1384.325211] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 1384.371575] device eth0 entered promiscuous mode
[ 1384.373224] r8169: eth0: link up
[ 1384.377223] br0: port 1(eth0) entering learning state
[ 1395.181005] br0: no IPv6 routers present
[ 1395.239005] eth0: no IPv6 routers present
[ 1395.613990] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 1397.704232] e100: eth1 NIC Link is Up 100 Mbps Full Duplex
[ 1397.705557] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1399.377010] br0: port 1(eth0) entering forwarding state
[ 1407.797005] eth1: no IPv6 routers present
[ 1443.531430] device tap1 entered promiscuous mode
[ 1443.536931] br0: port 2(tap1) entering learning state
[ 1448.309009] tap0: no IPv6 routers present
[ 1453.974007] tap1: no IPv6 routers present
[ 1458.536072] br0: port 2(tap1) entering forwarding state
[43624.334005] tap0: no IPv6 routers present
^ permalink raw reply
* Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
From: Michael S. Tsirkin @ 2009-08-20 12:12 UTC (permalink / raw)
To: Gregory Haskins
Cc: Avi Kivity, Anthony Liguori, Ingo Molnar, Gregory Haskins, kvm,
alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4A8B8F4E.80207@gmail.com>
On Wed, Aug 19, 2009 at 01:36:14AM -0400, Gregory Haskins wrote:
> >> So where is the problem here?
> >
> > If virtio net in guest could be improved instead, everyone would
> > benefit.
>
> So if I whip up a virtio-net backend for vbus with a PCI compliant
> connector, you are happy?
I'm currently worried about venet versus virtio-net guest situation, if
you drop it and switch to virtio net instead that issue's resolved.
I don't have an opinion on vbus versus pci, and I only speak for myself.
--
MST
^ permalink raw reply
* Re: IPV6_RTHDR with a type-0 routing header
From: Steinar H. Gunderson @ 2009-08-20 12:18 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev
In-Reply-To: <7d4abbaea1f1e17050a0e8ffe4917cb8@chewa.net>
On Thu, Aug 20, 2009 at 01:29:09PM +0200, Rémi Denis-Courmont wrote:
>> I've tried attaching a type-0 routing header to my IPv6 packets with
>> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
>> looking at the source, it seems it simply refuses anything that's not
>> type-2;
>> should that really be right? I found the following commit:
> RT0 headers have been deprecated by IETF. The kernel refuses to use then on
> purpose.
Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
to "future routing headers"...
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: IPV6_RTHDR with a type-0 routing header
From: Steinar H. Gunderson @ 2009-08-20 12:39 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev
In-Reply-To: <20090820121820.GA21354@uio.no>
On Thu, Aug 20, 2009 at 02:18:20PM +0200, Steinar H. Gunderson wrote:
> Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
> to "future routing headers"...
It looks like I can use destination options instead, but those don't seem to
be too easy to use either. The kernel seems to demand that I put eight bytes
of padding at the end?
#define ipv6_optlen(p) (((p)->hdrlen+1) << 3)
Why the +1?
FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
If I replace "len" in the setsockopt call by "len + 8", the program runs and
the packets get the right option attached -- but also eight padding bytes.
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: [Bonding-devel] [PATCH net-next-2.6] bonding: introduce primary_lazy option
From: Nicolas de Pesloüan @ 2009-08-20 12:40 UTC (permalink / raw)
To: Jiri Pirko; +Cc: davem, netdev, fubar, bonding-devel
In-Reply-To: <20090818124550.GB3539@psychotron.englab.brq.redhat.com>
Jiri Pirko awrote:
> Mon, Aug 17, 2009 at 10:55:13PM CEST, nicolas.2p.debian@free.fr wrote:
>> Jiri Pirko wrote:
>>> Fri, Aug 14, 2009 at 06:27:03PM CEST, nicolas.2p.debian@free.fr wrote:
>>>> Jiri Pirko wrote:
>>>>> Thu, Aug 13, 2009 at 09:41:02PM CEST, nicolas.2p.debian@free.fr wrote:
>>>>>> Jiri Pirko wrote:
>>>>>>> In some cases there is not desirable to switch back to primary interface when
>>>>>>> it's link recovers and rather stay wiith currently active one. We need to avoid
>>>>>>> packetloss as much as we can in some cases. This is solved by introducing
>>>>>>> primary_lazy option. Note that enslaved primary slave is set as current
>>>>>>> active no matter what.
>>>>>> May I suggest that instead of creating a new option to better define how
>>>>>> the "primary" option is expected to behave for active-backup
>>>>>> mode, we try the "weight" slave option I proposed in the thread
>>>>>> "alternative to primary" earlier this year ?
>>>>>>
>>>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=49D5357E.4020201%40free.fr&forum_name=bonding-devel
>>>>> This link does not work for me :(
>>>> Nor for me... Sourceforge apparently decided to drop the
>>>> bonding-devel list archive just now. 'hope the list archive will be
>>>> back soon.
>>>>
>>>> Originally, the proposed "weight" option for slaves was designed just
>>>> to provide a way to better define which slave should become active
>>>> when the active one just went down. As you know, the current
>>>> "primary" option does not allow for a predictable selection of the
>>>> new active slave when the primary loose connectivity. The new active
>>>> slave is chosen "at random" between the remaining slaves.
>>>>
>>>> After a short thread, involving Jay Vosburg and Andy Gospodarek, we
>>>> end up with a general configuration interface, that provide a way to
>>>> tune many things in slave management :
>>>>
>>>> - Active slave selection in active/backup mode, even in the presence
>>>> of more than two slaves.
>>>> - Active aggregator selection in 802.3ad mode.
>>>> - Load balancing tuning for most load balancing modes.
>>>>
>>>> The sysfs interface would be /sys/class/net/eth0/bonding/weight.
>>>> Writing a number there would give a "user supplied weight" to a
>>>> slave. The speed and link state of the slave would give a "natural
>>>> weight" for the slave. And the "effective weight" would be computed
>>>> every time one of user supplied or natural weight change (upon speed
>>>> or link state changes) and would be used everywhere we need a slave
>>>> weight.
>>>>
>>>> I suggest that :
>>>> - slave's natural weight = speed of the slave if link UP, else 0.
>>>> - slave's effective weight = slave's natural weight * slave's user
>>>> supplied weight.
>>>> - aggregator's effective weight = sum of the effective weights of the
>>>> slaves inside the aggregator.
>>>>
>>>> For the active/backup mode, the exact behavior would be :
>>>>
>>>> - When the active slave disappear, the new active slave is the one
>>>> whose effective weight is the highest.
>>>> - When a slave comes back, it only becomes active if its effective
>>>> weight is strictly higher than the one of the current active slave.
>>>> (This stop the flip-flop risk you stated).
>>>> - To keep the old "primary" option, we simply give a very high user
>>>> supplied weight to the primary slave. Jay suggested :
>>>> #define BOND_PRIMARY_PRIO 0x80000000
>>>> user_supplied_weight &= BOND_PRIMARY_PRIO /* to set the primary */
>>>> user_supplied_weight &= ~BOND_PRIMAY_PRIO /* to clear the primary */
>>>>
>>>> The same apply to aggregator : Every time a slave enter (link UP) or
>>>> leave (link DOWN) an aggregator, the aggregator effective weight is
>>>> recomputed. Then, if an aggregator exist with an strictly higher
>>>> effective weight than the current active one, the new best aggregator
>>>> becomes active.
>>>>
>>>> For others modes, the weight might be used later to tune the load
>>>> balancing logic in some way.
>>>>
>>>> A default value of 1 for slave weight would cause slave speed to be
>>>> used alone, hence the "natural weight".
>>>>
>>> I read your text and also the original list thread and I must say I see no
>>> solution in this "weight" parameter for this issue. Because it's desired for one
>>> link to stay active even if second come up, these 2 must have the same weight.
>>> But imagine 3 links of the same weight. In that case you cannot insure that the
>>> "primary one" will be chosen as active (see my picture in the reply to Jay's
>>> post). Correct me if I'm wrong but for that what I want to fix by primary_lazy
>>> option, your proposed weight option has no effect.
>>>
>>> Therefor I still think the primary_lazy is the only solution now.
>>>
>>> Jirka
>> Hi Jirka,
>>
>> From your previous posts (first one and reply to Jay), I understand that
>> your want to achieve the following behavior :
>>
>> eth0 is primary and active.
>> eth1 is allowed to be active is eth0 is down.
>> Also, eth1 should stay active, even if eth0 comes back up.
>> Switch active to eth0 if eth1 eventually fall down.
>> Switch active to eth2 only if both eth0 and eth1 are down.
>>
>> eth0 eth1 eth2
>> UP(curr) UP UP
>> DOWN UP(curr) UP
>> UP UP(curr) UP
>> UP(curr) DOWN UP
>> DOWN DOWN UP(curr)
>>
>> Using weight, the following setup should give this result :
>>
>> echo 1000 > /sys/class/net/eth0/bonding/weight
>> echo 1000 > /sys/class/net/eth1/bonding/weight
>> echo 1 > /sys/class/net/eth2/bonding/weight
>> echo eth0 > /sys/class/net/bond0/bonding/active_slave
>>
>> I hope this is clear now.
>
> Hmm... I ment the eth1 and eth2 to be the equivalent...
> If eth1 is down (let's say for good) and eth0 comes down, eth2 is
> selected as current active. But when eth0 comes up then eth0 is selected. That
> is not desired.
OK, now I think I really understand your exact requirement.
You want the ability to keep the current active slave active, even if a
better slave comes back up, so the only reason for the active slave to
change would be that the current active slave falls down:
eth0 eth1 eth2
UP(curr) UP UP
DOWN UP(curr) UP
UP UP(curr) UP
UP(curr) DOWN UP
DOWN DOWN UP(curr)
UP DOWN UP(curr) <-
But at the same time, you still need the ability to properly select the
best new active slave when the current one falls down, hence your answer
in reply to Jay's proposal:
> But imagine you have bond with 3 slaves:
> eth0 eth1 eth2
> UP(curr) UP UP
> DOWN UP(curr) UP
> UP UP(curr) UP
> UP DOWN UP(curr)
> eth2 ends up being current active but we prefer eth0 (as
> primary interface).
> This is not desirable and is solved by primary_lazy option.
I think your proposed "primary_lazy" option suffer some limits and
should not be a per bond option but a per slave option.
You are right that some slave should be able to be "sticky" when active,
in order to reduce packets loose when switching. But due to performance
reason, it might be desirable to say that some other slaves are not
"sticky" when active, in the same configuration.
Let's imagine the following configuration :
eth0: 1 Gb/s - primary
eth1: 1 Gb/s
eth2: 100 Mb/s
With "primary_lazy=1, eth2 has a chance to stay active, after eth0
and eth1 both failed at the same time. The risk of loosing a few packets
while switching back from eth2 to eth0 or eth1 might be seen acceptable,
compared to sticking to a 100 Mb/s interface when a 1 Gb/s interface
is available.
Due to eth2 speed, one might want to have the following behavior:
If eth1 is active, keep it active, even if eth0 comes back up. But if
eth2 is active, switch to any better slave right at the time one comes
back up.
I suggest that instead of having a per bond "primary_lazy" option, we
define a per slave option, describing whether this particular slave is
"sticky when active" or not.
The above setup would become :
echo 1 > /sys/class/net/eth0/bonding/sticky_active
echo 1 > /sys/class/net/eth1/bonding/sticky_active
echo 0 > /sys/class/net/eth2/bonding/sticky_active
echo eth0 > /sys/class/net/bond0/bonding/primary
Or may be better, keeping the "weight" idea in mind, a per slave option
"active_weight" that gives the weight of the slave, *when active*.
The effective weight of a slave would become :
effective_slave =
(is_active ? user_supplied_active_weight ? user_supplied_weight) *
natural_weight
# Prefer eth0, then one of eth1 or eth2, then eth3.
echo 1000 > /sys/class/net/eth0/bonding/weight
echo 999 > /sys/class/net/eth1/bonding/weight
echo 999 > /sys/class/net/eth2/bonding/weight
echo 10 > /sys/class/net/eth3/bonding/weight
# Do not switch back to primary eth0 if eth1 or eth2 is active.
echo 1000 > /sys/class/net/eth1/bonding/active_weight
echo 1000 > /sys/class/net/eth2/bonding/active_weight
Every time one changes the user_supplied_weight, then
user_supplied_active_weight must be reset to the same value. This way,
if no special setup is done on active_weight, then the current normal
behavior is achieved.
If none of those options seem acceptable to you, I suggest a third one:
You keep primary_lazy, but with the following values :
# Switch back to primary slaves when it comes back.
echo 0 > /sys/class/net/bond0/bonding/primary_lazy
# Switch back to primary when it comes back, only if the speed of the
# primary slave is higher than the speed of the current active slave.
echo 1 > /sys/class/net/bond0/bonding/primary_lazy
# Stick to the current active slave when the primary slave comes back,
# even if the primary slave speed is higher than the speed of the
# current active slave.
echo 2 > /sys/class/net/bond0/bonding/primary_lazy
You can consider the value as being the level of laziness of the primary.
Nicolas.
>>>>>> Giving the same "weight" to two different slaves means "chose at random
>>>>>> on startup and keep the active one until it fails". And if the "at
>>>>>> random" behavior is not appropriate, one can force the active slave
>>>>>> using what Jay suggested (/sys/class/net/bond0/bonding/active).
>>>>>>
>>>>>> The proposed "weight" slave's option is able to prevent the slaves from
>>>>>> flip-flopping, by stating the fact that two slaves share the same
>>>>>> "primary" level, and may provide several other enhancements as
>>>>>> described in the thread.
>>>>>>
>>>>> Although I cannot reach the thread, this looks interesting. But I'm not sure it
>>>>> has real benefits over primary_lazy option (and it doesn't solve initial curr
>>>>> active slave setup)
>>>> You are right, it doesn't solve the initial active slave selection.
>>>> But why would it be so important to properly select the initial
>>>> active slave, if you feel comfortable with staying with a new active
>>>> slave, after a failure and return of the original active slave ?
>>>> This kind of failures may last for only a few seconds (just
>>>> unplugging and plugging back the wire), and you configuration may
>>>> then stay with the new active slave "forever". If "forever" is
>>>> acceptable, may be "at startup" is acceptable too. :-)
>>>>
>>>> From my point of view (and Andy Gospodarek apparently agreed), the
>>>> real benefits of the weight slave option is that is it more generic
>>>> and allow for later usage in other modes, that we don't anticipate
>>>> for now.
>>>>
>>>> Quoted from a mail from Andy Gospodarek in the original thread :
>>>>
>>>> "I really have no objection to that. Adding this as a base part of
>>>> bonding for a few modes with known features would be a nice start.
>>>> I'm sure others will be kind enough to send suggestions or patches for
>>>> ways this could benefit other modes."
^ permalink raw reply
* netfilter 01/01: xt_quota: fix wrong return value (error case)
From: Patrick McHardy @ 2009-08-20 12:47 UTC (permalink / raw)
To: David S. Miller; +Cc: Netfilter Development Mailinglist, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 179 bytes --]
Hi Dave,
the following patch for 2.6.31 fixes a regression in the xt_quota module
introduced in 2.6.30-rc1, causing a crash when memory allocation fails.
Please apply, thanks.
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 865 bytes --]
commit 53fa59e004cd02b1bd97edff965d063222bd0171
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Thu Aug 13 15:42:17 2009 +0200
netfilter: xt_quota: fix wrong return value (error case)
Success was indicated on a memory allocation failure, thereby causing
a crash due to a later NULL deref.
(Affects v2.6.30-rc1 up to here.)
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_quota.c b/net/netfilter/xt_quota.c
index 98fc190..390b7d0 100644
--- a/net/netfilter/xt_quota.c
+++ b/net/netfilter/xt_quota.c
@@ -52,7 +52,7 @@ static bool quota_mt_check(const struct xt_mtchk_param *par)
q->master = kmalloc(sizeof(*q->master), GFP_KERNEL);
if (q->master == NULL)
- return -ENOMEM;
+ return false;
q->master->quota = q->quota;
return true;
^ permalink raw reply related
* Re: IPV6_RTHDR with a type-0 routing header
From: Jens Rosenboom @ 2009-08-20 12:53 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: Rémi Denis-Courmont, netdev
In-Reply-To: <20090820123926.GA21858@uio.no>
On Thu, 2009-08-20 at 14:39 +0200, Steinar H. Gunderson wrote:
> On Thu, Aug 20, 2009 at 02:18:20PM +0200, Steinar H. Gunderson wrote:
> > Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
> > to "future routing headers"...
>
> It looks like I can use destination options instead, but those don't seem to
> be too easy to use either. The kernel seems to demand that I put eight bytes
> of padding at the end?
>
> #define ipv6_optlen(p) (((p)->hdrlen+1) << 3)
>
> Why the +1?
Because that matches the definition of the hdrlen field in RFC2460.
> FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
> If I replace "len" in the setsockopt call by "len + 8", the program runs and
> the packets get the right option attached -- but also eight padding bytes.
ERROR 404: Not Found.
^ permalink raw reply
* Re: 100Mbit ethernet performance on embedded devices
From: Johannes Stezenbach @ 2009-08-20 12:56 UTC (permalink / raw)
To: Jamie Lokier; +Cc: linux-embedded, netdev
In-Reply-To: <20090819153534.GC30013@shareable.org>
On Wed, Aug 19, 2009 at 04:35:34PM +0100, Jamie Lokier wrote:
> Johannes Stezenbach wrote:
> >
> > TCP RX ~70Mbit/sec (iperf -s on SoC, iperf -c on destop PC)
> > TCP TX ~56Mbit/sec (iperf -s on destop PC, iperf -c o SoC)
> >
> > The CPU load during the iperf test is around
> > 1% user, 44% system, 4% irq, 48% softirq, with 7500 irqs/sec.
> >
> > The kernel used in these measurements does not have iptables
> > support, I think packet filtering will slow it down noticably,
> > but I didn't actually try. The ethernet driver uses NAPI,
> > but it doesn't seem to be a win judging from the irq/sec number.
>
> You should see far fewer interrupts if NAPI was working properly.
> Rather than NAPI not being a win, it looks like it's not active at
> all.
>
> 7500/sec is close to the packet rate, for sending TCP with
> full-size ethernet packages over a 100Mbit ethernet link.
>From debug output I can see that NAPI works in principle, however
the timing seems to be such that ->poll() almost always completes
before the next packet is received. I followed the NAPI_HOWTO.txt
which came with the 2.6.20 kernel. The delay between irq ->
netif_rx_schedule() -> NET_RX_SOFTIRQ -> ->poll() doesn't seem
to be long enough. But of course my understanding of NAPI is
very limited, probably I missed something...
> > What I'm interested in are some numbers for similar hardware,
> > to find out if my hardware and/or ethernet driver can be improved,
> > or if the CPU will always be the limiting factor.
>
> I have a SoC with a 166MHz ARMv4 (ARM7TDMI I think, but I'm not sure),
> and an external RTL8139 100Mbit ethernet chip over the SoC's PCI bus.
>
> It gets a little over 80Mbit/s actual data throughput in both
> directions, running a simple FTP client.
I found one interesting page which defines network driver performance
in terms of "CPU MHz per Mbit".
http://www.stlinux.com/drupal/node/439
I can't really tell from their table how big a win HW csum is, but
what they call "interrupt mitigation optimisations" (IOW: working NAPI)
seems important. (compare the values for STx7105)
If some has an embedded platform with 100Mbit ethernet where they can switch
HW checksum via ethtool and benchmark both under equal conditions, that
would be very interesting.
Thanks
Johannes
^ permalink raw reply
* Re: IPV6_RTHDR with a type-0 routing header
From: Steinar H. Gunderson @ 2009-08-20 13:00 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: Rémi Denis-Courmont, netdev
In-Reply-To: <1250772824.9489.3.camel@fnki-nb00130>
On Thu, Aug 20, 2009 at 02:53:44PM +0200, Jens Rosenboom wrote:
>> It looks like I can use destination options instead, but those don't seem to
>> be too easy to use either. The kernel seems to demand that I put eight bytes
>> of padding at the end?
>>
>> #define ipv6_optlen(p) (((p)->hdrlen+1) << 3)
>>
>> Why the +1?
> Because that matches the definition of the hdrlen field in RFC2460.
Hm, in that case I guess it's glibc that has one too much indeed (I never
write this field).
>> FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
>> If I replace "len" in the setsockopt call by "len + 8", the program runs and
>> the packets get the right option attached -- but also eight padding bytes.
> ERROR 404: Not Found.
Sorry, http://home.samfundet.no/~sesse/v6opt.c
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server
From: Arnd Bergmann @ 2009-08-20 13:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Or Gerlitz
In-Reply-To: <20090820083155.GB5448@redhat.com>
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
> On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote:
> > On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
> > > On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote:
> > > > On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
> > > >
> > > > Leaving that aside for now, you could replace VHOST_NET_SET_SOCKET,
> > > > VHOST_SET_OWNER, VHOST_RESET_OWNER
> > >
> > > SET/RESET OWNER is still needed: otherwise if you share a descriptor
> > > with another process, it can corrupt your memory.
> >
> > How? The point of using user threads is that you only ever access the
> > address space of the thread that called the ioctl.
>
> Think about this example with processes A and B sharing an fd:
> A does SET_USED_ADDRESS
> B does SET_USED_ADDRESS
> A does VHOST_NET_SPLICE
> See how stuff gets written into a random place in memory of A?
Yes, I didn't think of that. It doesn't seem like a big problem
though, because it's a clear misuse of the API (I guess your
current code returns an error for one of the SET_USED_ADDRESS
ioctls), so I would see it as a classic garbage-in garbage-out
case.
It may even work in the case that the sharing of the fd resulted
from a fork, where the address contains the same buffer in both
processes. I can't think of a reason why you would want to use
it like that though.
> > Why would I wake up the threads spuriously? Do you mean for
> > stopping the transmission or something else? I guess a pthread_kill
> > would be enough for shutting it down.
>
> If you kill and restart them you lost priority etc parameters, but maybe.
If you want to restart it, just send a nonfatal signal (SIGUSR1,
SIGRTMIN, ...) instead of a SIGKILL.
> > > More importantly, you lose control of CPU locality. Simply put, a
> > > natural threading model in virtualization is one thread per guest vcpu.
> > > Asking applications to add multiple helper threads just so they can
> > > block forever is wrong, IMO, as userspace has no idea which CPU
> > > they should be on, what priority to use, etc.
> >
> > But the kernel also doesn't know this, you get the same problem in
> > another way. If you have multiple guests running at different priorities,
> > the kernel will use those priorities to do the more important transfers
> > first, while with a global workqueue every guest gets the same priority.
>
> We could create more threads if this becomes a problem. I just think it
> should be transparent to userspace. Possibly it's useful to look at the
> packet header as well to decide on priority: this is something userspace
> can't do.
Being transparent to user space would be nice, I agree. Letting user space
choose would also be nice, e.g. if you want to distribute eight available
hardware queue pairs to three guests in a non-obvious way. The
implementation depends to some degree on how we want to do multiqueue
RX/TX in virtio-net in the long run. For best cache locality and NUMA
behaviour, we might want to have one virtqueue per guest CPU and control
them independently from the host.
Priorities of the packets are dealt with in the packet scheduler for
external interfaces, I guess that is sufficient. I'm not sure if we
need to honor the same priorities for guest-to-guest communication,
my feeling is that we don't need to.
> > You say that the natural model is to have one thread per guest
> > CPU,
>
> Sorry I was not clear. I think userspace should create thread per guest.
> We can create as many as we need for networking but I think this should
> be behind the scenes, so userspace shouldn't bother with host CPUs, it
> will just get it wrong. Think of CPU hotplug, interrupts migrating
> between CPUs, etc ...
Yes, I hope we can avoid letting qemu know about host CPUs.
I'm not sure we can avoid it completely, because something needs
to set physical IRQ affinity and such for the virtual devices
if you want to get the best locality.
> > but you have a thread per host CPU instead. If the numbers
> > are different, you probably lose either way.
>
> The trick I used is to keep as much as possible local
> TX done on the CPU that runs the guest,
> RX done on the CPU that runs the NIC interrupt.
> a smart SMP guest sees which cpu gets interrupts
> from NIC and schedules RX there, and it shouldn't matter
> if the numbers of CPUs are different.
yes, that sounds good.
> > It gets worse if you try to apply NUMA policies.
>
> I believe the best we could do is avoid switching CPUs
> until we know the actual destination.
My point is that the RX data in the guest address space
should be on the same NUMA node that gets the interrupt.
> > > And note that there might be more than one error. I guess, that's
> > > another problem with trying to layer on top of vfs.
> >
> > Why is that different from any other system call?
>
> With other system calls nothing happens while you process the error.
> Here, the guest (other queues) and the network keep running (unless
> there is a thread per queue, maybe we can block a queue, but we both
> agreed above we don't want that).
Well, I would expect error conditions to be fatal for the connections
normally, so blocking the queue is totally fine here IMHO. The ioctl
would never return while a guest is running and connected to a
working NIC.
> > We just return when
> > we hit the first error condition.
>
> If you assume losing the code for the second error condition is OK, why
> is the first one so important? That's why I used a counter (eventfd)
> per virtqueue, on error userspace can scan the ring and poll the socket
> and discover what's wrong, and counter ensures we can detect that error
> happened while we were not looking.
I guess we were talking about different kinds of errors here, and I'm
still not sure which one you are talking about.
Arnd <><
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: IPV6_RTHDR with a type-0 routing header
From: Steinar H. Gunderson @ 2009-08-20 13:11 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: Rémi Denis-Courmont, netdev
In-Reply-To: <20090820130009.GA22183@uio.no>
On Thu, Aug 20, 2009 at 03:00:09PM +0200, Steinar H. Gunderson wrote:
>> Because that matches the definition of the hdrlen field in RFC2460.
> Hm, in that case I guess it's glibc that has one too much indeed (I never
> write this field).
Yes indeed. It's fixed in more recent glibc:
[BZ #5760]
* inet/inet6_opt.c (inet6_opt_init): Fix ip6h_len computation.
Patch by Roland Bless <roland@bless.de>.
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Aviv Greenberg @ 2009-08-20 13:17 UTC (permalink / raw)
To: Bill Fink; +Cc: Andrew Gallatin, netdev
In-Reply-To: <20090820032601.03a628cf.billfink@mindspring.com>
On Thu, Aug 20, 2009 at 10:26, Bill Fink<billfink@mindspring.com> wrote:
> IIRC, under DevCap they indicated MaxPayload 4096 bytes, and under
> DevCtl they indicated MaxPayload 128 bytes and MaxReadReq 4096 bytes,
> and was the same on both the Asus and SuperMicro systems. I will
> doublecheck tomorrow at work. I am not clear on the meanings of
> the different parameters. And is DevCtl for PCI control messages
> and DevCap for actual data transfers or something else?
IIRC DevCap is what the device is capable of, and DevCtl is a control
register that is used to limit the device's PCIe MTU if needed (e.g
chipset limit). MaxPayload is the one used for RX DMA writes, and 128
bytes might be too low. I suggest you double check that.
You have to first figure out if your performance is limited by PCIe
bandwidth, or due to the NUMA stuff.
--
Stephen Leacock - "I detest life-insurance agents: they always argue
that I shall some day die, which is not so." -
http://www.brainyquote.com/quotes/authors/s/stephen_leacock.html
^ permalink raw reply
* Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-08-20 13:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Or Gerlitz
In-Reply-To: <200908201510.54482.arnd@arndb.de>
On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
> On Thursday 20 August 2009, Michael S. Tsirkin wrote:
> > On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
> > > > On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote:
> > > > > On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
> > > > >
> > > > > Leaving that aside for now, you could replace VHOST_NET_SET_SOCKET,
> > > > > VHOST_SET_OWNER, VHOST_RESET_OWNER
> > > >
> > > > SET/RESET OWNER is still needed: otherwise if you share a descriptor
> > > > with another process, it can corrupt your memory.
> > >
> > > How? The point of using user threads is that you only ever access the
> > > address space of the thread that called the ioctl.
> >
> > Think about this example with processes A and B sharing an fd:
> > A does SET_USED_ADDRESS
> > B does SET_USED_ADDRESS
> > A does VHOST_NET_SPLICE
> > See how stuff gets written into a random place in memory of A?
>
> Yes, I didn't think of that. It doesn't seem like a big problem
> though, because it's a clear misuse of the API (I guess your
> current code returns an error for one of the SET_USED_ADDRESS
> ioctls), so I would see it as a classic garbage-in garbage-out
> case.
>
> It may even work in the case that the sharing of the fd resulted
> from a fork, where the address contains the same buffer in both
> processes. I can't think of a reason why you would want to use
> it like that though.
It doesn't matter that I don't want this: allowing 1 process corrupt
another's memory is a security issue. Once you get an fd, you want to
be able to use it without worrying that a bug in another process will
crash yours.
> > > Why would I wake up the threads spuriously? Do you mean for
> > > stopping the transmission or something else? I guess a pthread_kill
> > > would be enough for shutting it down.
> >
> > If you kill and restart them you lost priority etc parameters, but maybe.
>
> If you want to restart it, just send a nonfatal signal (SIGUSR1,
> SIGRTMIN, ...) instead of a SIGKILL.
>
> > > > More importantly, you lose control of CPU locality. Simply put, a
> > > > natural threading model in virtualization is one thread per guest vcpu.
> > > > Asking applications to add multiple helper threads just so they can
> > > > block forever is wrong, IMO, as userspace has no idea which CPU
> > > > they should be on, what priority to use, etc.
> > >
> > > But the kernel also doesn't know this, you get the same problem in
> > > another way. If you have multiple guests running at different priorities,
> > > the kernel will use those priorities to do the more important transfers
> > > first, while with a global workqueue every guest gets the same priority.
> >
> > We could create more threads if this becomes a problem. I just think it
> > should be transparent to userspace. Possibly it's useful to look at the
> > packet header as well to decide on priority: this is something userspace
> > can't do.
>
> Being transparent to user space would be nice, I agree. Letting user space
> choose would also be nice, e.g. if you want to distribute eight available
> hardware queue pairs to three guests in a non-obvious way. The
> implementation depends to some degree on how we want to do multiqueue
> RX/TX in virtio-net in the long run. For best cache locality and NUMA
> behaviour, we might want to have one virtqueue per guest CPU and control
> them independently from the host.
>
> Priorities of the packets are dealt with in the packet scheduler for
> external interfaces, I guess that is sufficient. I'm not sure if we
> need to honor the same priorities for guest-to-guest communication,
> my feeling is that we don't need to.
>
> > > You say that the natural model is to have one thread per guest
> > > CPU,
> >
> > Sorry I was not clear. I think userspace should create thread per guest.
> > We can create as many as we need for networking but I think this should
> > be behind the scenes, so userspace shouldn't bother with host CPUs, it
> > will just get it wrong. Think of CPU hotplug, interrupts migrating
> > between CPUs, etc ...
>
> Yes, I hope we can avoid letting qemu know about host CPUs.
So ... if we need per-host-CPU threads, we'll have to create them
ourselves then.
> I'm not sure we can avoid it completely, because something needs
> to set physical IRQ affinity and such for the virtual devices
> if you want to get the best locality.
>
> > > but you have a thread per host CPU instead. If the numbers
> > > are different, you probably lose either way.
> >
> > The trick I used is to keep as much as possible local
> > TX done on the CPU that runs the guest,
> > RX done on the CPU that runs the NIC interrupt.
> > a smart SMP guest sees which cpu gets interrupts
> > from NIC and schedules RX there, and it shouldn't matter
> > if the numbers of CPUs are different.
>
> yes, that sounds good.
>
> > > It gets worse if you try to apply NUMA policies.
> >
> > I believe the best we could do is avoid switching CPUs
> > until we know the actual destination.
>
> My point is that the RX data in the guest address space
> should be on the same NUMA node that gets the interrupt.
Exactly. And since I know this, I just do the right thing
instead of expecting userspace to do this with taskset and
stuff, which no one seems to get right anyway.
> > > > And note that there might be more than one error. I guess, that's
> > > > another problem with trying to layer on top of vfs.
> > >
> > > Why is that different from any other system call?
> >
> > With other system calls nothing happens while you process the error.
> > Here, the guest (other queues) and the network keep running (unless
> > there is a thread per queue, maybe we can block a queue, but we both
> > agreed above we don't want that).
>
> Well, I would expect error conditions to be fatal for the connections
> normally,
Not necessarily. E.g. one can imagine that userspace wants to handle
access to specific address ranges (framebuffer?) in slow path, and let
kernel handle the rest. A natural way is to make this range generate
access error.
> so blocking the queue is totally fine here IMHO. The ioctl
> would never return while a guest is running and connected to a
> working NIC.
>
> > > We just return when
> > > we hit the first error condition.
> >
> > If you assume losing the code for the second error condition is OK, why
> > is the first one so important? That's why I used a counter (eventfd)
> > per virtqueue, on error userspace can scan the ring and poll the socket
> > and discover what's wrong, and counter ensures we can detect that error
> > happened while we were not looking.
>
> I guess we were talking about different kinds of errors here, and I'm
> still not sure which one you are talking about.
>
> Arnd <><
Non fatal errors. E.g. translation errors probably should be
non-fatal. I can also imagine working around guest bugs in
userspace.
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Strange network timeouts w/ 2.6.30.5
From: Krzysztof Halasa @ 2009-08-20 13:45 UTC (permalink / raw)
To: Walt Holman; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <985009134.71250769263099.JavaMail.root@mail.holmansrus.com>
Walt Holman <walt@holmansrus.com> writes:
> dmesg is attached. This box does have >2GB Ram (6GB total). The dmesg
> will show e100 init'd 3 times since the first is the stock modprobe,
> 2nd was forced with use_io and the 3rd modprobe was after reverting
> the patch.
You most probably can't test without swiotlb (RAM has to be limited to
2 GB or so), can you? That would (dis)prove my theory. Alternatively (or
better), a test on IOMMU-equipped system would do.
Since swiotlb is x86-only thing (though other 64-bit archs may have
something similar), I think the correct work around is to enable the
"for_device" handoff on !X86.
Something like maybe:
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 014dfb6..b610088 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1762,9 +1762,12 @@ static int e100_rx_indicate(struct nic *nic, struct rx *rx,
if (ioread8(&nic->csr->scb.status) & rus_no_res)
nic->ru_running = RU_SUSPENDED;
+#ifndef CONFIG_X86
+ /* FIXME interferes with swiotlb. */
pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
sizeof(struct rfd),
PCI_DMA_BIDIRECTIONAL);
+#endif
return -ENODATA;
}
--
Krzysztof Halasa
^ permalink raw reply related
* [PATCH]gianfar: gfar_remove needs to call unregister_netdev()
From: Toru UCHIYAMA @ 2009-08-20 13:54 UTC (permalink / raw)
To: netdev
This patch solves the problem that the Oops(BUG_ON) occurs by rmmod.
# rmmod gianfar_driver
------------[ cut here ]------------
Kernel BUG at c01fec48 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC837x MDS
Modules linked in: gianfar_driver(-) usb_storage scsi_wait_scan
NIP: c01fec48 LR: c01febf4 CTR: c01feba8
REGS: dec5bd60 TRAP: 0700 Tainted: G W (2.6.31-rc2)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22000424 XER: 20000000
TASK = dec4cac0[1135] 'rmmod' THREAD: dec5a000
GPR00: 00000002 dec5be10 dec4cac0 dfba1820 c035d444 c035d478 ffffffff 00000000
GPR08: 0000002b 00000001 dfba193c 00000001 22000424 10019b34 1ffcb000 00000000
GPR16: 10012008 00000000 bf82ebe0 100017ec bf82ebec bf82ebe8 bf82ebd0 00000880
GPR24: 00000000 bf82ebf0 c03532f0 c03532e4 c036b594 dfba183c dfba1800 dfba1820
NIP [c01fec48] free_netdev+0xa0/0xb8
LR [c01febf4] free_netdev+0x4c/0xb8
Call Trace:
[dec5be10] [c01febf4] free_netdev+0x4c/0xb8 (unreliable)
[dec5be30] [e105f290] gfar_remove+0x50/0x68 [gianfar_driver]
[dec5be40] [c01ec534] of_platform_device_remove+0x30/0x44
[dec5be50] [c0181760] __device_release_driver+0x68/0xc8
[dec5be60] [c0181868] driver_detach+0xa8/0xac
[dec5be80] [c0180814] bus_remove_driver+0x9c/0xd8
[dec5bea0] [c0181efc] driver_unregister+0x60/0x98
[dec5beb0] [c01ec650] of_unregister_driver+0x14/0x24
[dec5bec0] [e10631bc] gfar_exit+0x18/0x4bc [gianfar_driver]
[dec5bed0] [c0047584] sys_delete_module+0x16c/0x228
[dec5bf40] [c00116bc] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff3669c
LR = 0x10000f34
Instruction dump:
409e0024 a07e00c0 7c63f050 4be74429 80010024 bba10014 38210020 7c0803a6
4e800020 68000003 3160ffff 7d2b0110 <0f090000> 38000004 387e01f0 901e01d4
---[ end trace 8c595bcd37230a0f ]---
localhost kernel: ------------[ cut here ]------------
Signed-off-by: uchiyama.toru@jp.fujitsu.com
---
drivers/net/gianfar.c | 1 +
1 files changed, 1 insertion(+)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f8ffcbf..25f1ca4 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -491,6 +491,7 @@ static int gfar_remove(struct of_device *ofdev)
dev_set_drvdata(&ofdev->dev, NULL);
+ unregister_netdev(dev);
iounmap(priv->regs);
free_netdev(priv->ndev);
--
^ permalink raw reply related
* Re: [PATCH] WAN: bit and/or confusion
From: Roel Kluin @ 2009-08-20 14:04 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: Andrew Morton, David Miller, romieu, netdev
In-Reply-To: <m3iqgovrsv.fsf@intrepid.localdomain>
Fix the tests that check whether Frame* bits are not set
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
>> - else if (!(skb->data[pkt_len] | ~(FrameVfr | FrameRab)))
>> + else if (!(skb->data[pkt_len] & (FrameVfr | FrameRab)))
>> dev->stats.rx_length_errors++;
>
> This test requires both FrameVfr and FrameRab to be true (zero). Perhaps
> it should be:
>
>> + else if ((skb->data[pkt_len] & (FrameVfr | FrameRab)) != FrameVfr | FrameRab)
Ok, Francois Romieu, could you test this?
>> else
>> dev->stats.rx_errors++;
>
> rx_errors is incremented only on remaining errors. I think most drivers
> increment rx_errors on all RX errors, and simultaneously rx_*_errors
> when needed.
>
>
> Perhaps something like the following should be better?
>
> u8 status = ~skb->data[pkt_len];
>
> if (status == 0)
> looks_good...;
> else {
> if (status & FrameRab)
> ...
> if (status & FrameVfr)
> ...
> etc.
> rx_errors++;
> }
I don't understand your suggestion - why status == 0? doesn't the patch
below do what you want instead?
Roel
diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
index 8face5d..88534b6 100644
--- a/drivers/net/wan/dscc4.c
+++ b/drivers/net/wan/dscc4.c
@@ -663,12 +663,12 @@ static inline void dscc4_rx_skb(struct dscc4_dev_priv *dpriv,
} else {
if (skb->data[pkt_len] & FrameRdo)
dev->stats.rx_fifo_errors++;
- else if (!(skb->data[pkt_len] | ~FrameCrc))
+ else if (!(skb->data[pkt_len] & FrameCrc))
dev->stats.rx_crc_errors++;
- else if (!(skb->data[pkt_len] | ~(FrameVfr | FrameRab)))
+ else if ((skb->data[pkt_len] & (FrameVfr | FrameRab)) !=
+ FrameVfr | FrameRab)
dev->stats.rx_length_errors++;
- else
- dev->stats.rx_errors++;
+ dev->stats.rx_errors++;
dev_kfree_skb_irq(skb);
}
refill:
^ permalink raw reply related
* Re: [PATCH 2/2] sctp: fix heartbeat count of path failure
From: Vlad Yasevich @ 2009-08-20 14:10 UTC (permalink / raw)
To: Luo Chunbo; +Cc: davem, netdev, linux-sctp
In-Reply-To: <1250732164.6436.9.camel@pek-cluo-desktop>
Luo Chunbo wrote:
> On Wed, 2009-08-19 at 10:48 -0400, Vlad Yasevich wrote:
>> Chunbo Luo wrote:
>>> RFC4960 Section 8.2 defined that the transport should enter INACTIVE
>>> state only when the value in the error counter exceeds the protocol
>>> parameter 'Path.Max.Retrans' of that destination address. This means
>>> that the transport should enter INACTIVE state after pathmaxrxt+1
>>> heartbeats are not acknowledged.
>>>
>>>
>>> Signed-off-by: Chunbo Luo <chunbo.luo@windriver.com>
>> NAK. This patch seems to resurface periodically and I have to keep
>> explaining that it's wrong.
>>
>> Every time we send a HB, we tick up the error count and clear it when
>> the HB-ACK is received. Each HB is separate and not a retransmission,
>> so we once we reach the pathmaxrxt, we've already sent max+1 HB, so we
>> have time out. Walk through the code with some values and you'll see
>> what I mean.
>
> Although we've already sent max+1 HB, but the code set the transport to
> INACTIVE state immediately, which is equal to not sending the max+1 HB
> at all. We should wait for a next period and make sure the max+1 HB was
> not acknowledged.
Ok, I just re-read the section, and although we don't quite wait long
enough to mark the transport DOWN, this patch will cause us to send an
extra HB chunk, thus exceeding pathmaxrxt by 2.
What the spec really says is that an error is incremented when an
outstanding HB is not acknowledged.
So this code needs a bit of a rework. This patch is still NAKed.
-vlad
>
> Chunbo
>
>> -vlad
>>
>>> ---
>>> net/sctp/sm_sideeffect.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index 86426aa..0e2e269 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -447,7 +447,7 @@ static void sctp_do_8_2_transport_strike(struct sctp_association *asoc,
>>> asoc->overall_error_count++;
>>>
>>> if (transport->state != SCTP_INACTIVE &&
>>> - (transport->error_count++ >= transport->pathmaxrxt)) {
>>> + (transport->error_count++ > transport->pathmaxrxt)) {
>>> SCTP_DEBUG_PRINTK_IPADDR("transport_strike:association %p",
>>> " transport IP: port:%d failed.\n",
>>> asoc,
>
^ permalink raw reply
* Re: [PATCH] WAN: bit and/or confusion
From: Krzysztof Halasa @ 2009-08-20 14:25 UTC (permalink / raw)
To: Roel Kluin; +Cc: Andrew Morton, David Miller, romieu, netdev
In-Reply-To: <4A8D57F8.1050106@gmail.com>
Roel Kluin <roel.kluin@gmail.com> writes:
>> Perhaps something like the following should be better?
>>
>> u8 status = ~skb->data[pkt_len];
>>
>> if (status == 0)
>> looks_good...;
>> else {
>> if (status & FrameRab)
>> ...
>> if (status & FrameVfr)
>> ...
>> etc.
>> rx_errors++;
>> }
>
> I don't understand your suggestion - why status == 0? doesn't the patch
> below do what you want instead?
Because I think (didn't read the manual) that these (inverted) bits
represent specific errors. So I suggested inverting them, then treating
as separate error bits, it should be easier to read.
That's only a suggestion of course (unless someone sends me the/a card -
non-returnable "donations" only please - and I can work on it
personally).
IOW all (inverted) bits = 1 => all bits zero after inversion => no
errors. This changes functionality a bit, and would need to be checked.
Otherwise, you could test: if ((status & FrameOk) == 0) then looks_good().
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 8face5d..88534b6 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
> @@ -663,12 +663,12 @@ static inline void dscc4_rx_skb(struct dscc4_dev_priv *dpriv,
> } else {
> if (skb->data[pkt_len] & FrameRdo)
> dev->stats.rx_fifo_errors++;
> - else if (!(skb->data[pkt_len] | ~FrameCrc))
> + else if (!(skb->data[pkt_len] & FrameCrc))
> dev->stats.rx_crc_errors++;
> - else if (!(skb->data[pkt_len] | ~(FrameVfr | FrameRab)))
> + else if ((skb->data[pkt_len] & (FrameVfr | FrameRab)) !=
> + FrameVfr | FrameRab)
> dev->stats.rx_length_errors++;
> - else
> - dev->stats.rx_errors++;
> + dev->stats.rx_errors++;
> dev_kfree_skb_irq(skb);
> }
> refill:
Guess it would do.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server
From: Arnd Bergmann @ 2009-08-20 14:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Or Gerlitz
In-Reply-To: <20090820133817.GA7834@redhat.com>
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
> On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
> > On Thursday 20 August 2009, Michael S. Tsirkin wrote:
>
> It doesn't matter that I don't want this: allowing 1 process corrupt
> another's memory is a security issue. Once you get an fd, you want to
> be able to use it without worrying that a bug in another process will
> crash yours.
Ok, got it. Yes, that would be inacceptable.
> > > If you assume losing the code for the second error condition is OK, why
> > > is the first one so important? That's why I used a counter (eventfd)
> > > per virtqueue, on error userspace can scan the ring and poll the socket
> > > and discover what's wrong, and counter ensures we can detect that error
> > > happened while we were not looking.
> >
> > I guess we were talking about different kinds of errors here, and I'm
> > still not sure which one you are talking about.
> >
> Non fatal errors. E.g. translation errors probably should be
> non-fatal. I can also imagine working around guest bugs in
> userspace.
Ah, so I guess the confusion was that I was worried about
errors coming from the socket file descriptor, while you
were thinking of errors from the guest side, which I did not
expect to happen.
The errors from the socket (or chardev, as that was the
start of the argument) should still fit into the categories
that I mentioned, either they can be handled by the host
kernel, or they are fatal.
I'll read up in your code to see how you handle asynchronous
non-fatal errors from the guest. Intuitively, I'd still
assume that returning the first error should be enough
because it will typically mean that you cannot continue
without fixing it up first, and you might get the next
error immediately after that.
Arnd <><
^ permalink raw reply
* Re: [PATCHv3 2/2] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-08-20 14:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Or Gerlitz
In-Reply-To: <200908201631.37285.arnd@arndb.de>
On Thu, Aug 20, 2009 at 04:31:36PM +0200, Arnd Bergmann wrote:
> On Thursday 20 August 2009, Michael S. Tsirkin wrote:
> > On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
> > > On Thursday 20 August 2009, Michael S. Tsirkin wrote:
> >
> > It doesn't matter that I don't want this: allowing 1 process corrupt
> > another's memory is a security issue. Once you get an fd, you want to
> > be able to use it without worrying that a bug in another process will
> > crash yours.
>
> Ok, got it. Yes, that would be inacceptable.
>
> > > > If you assume losing the code for the second error condition is OK, why
> > > > is the first one so important? That's why I used a counter (eventfd)
> > > > per virtqueue, on error userspace can scan the ring and poll the socket
> > > > and discover what's wrong, and counter ensures we can detect that error
> > > > happened while we were not looking.
> > >
> > > I guess we were talking about different kinds of errors here, and I'm
> > > still not sure which one you are talking about.
> > >
> > Non fatal errors. E.g. translation errors probably should be
> > non-fatal. I can also imagine working around guest bugs in
> > userspace.
>
> Ah, so I guess the confusion was that I was worried about
> errors coming from the socket file descriptor, while you
> were thinking of errors from the guest side, which I did not
> expect to happen.
>
> The errors from the socket (or chardev, as that was the
> start of the argument) should still fit into the categories
> that I mentioned, either they can be handled by the host
> kernel, or they are fatal.
Hmm, are you sure? Imagine a device going away while socket is bound to
it. You get -ENXIO. It's not fatal in a sense that you can bind the
socket to another device and go on, right?
> I'll read up in your code to see how you handle asynchronous
> non-fatal errors from the guest. Intuitively, I'd still
> assume that returning the first error should be enough
> because it will typically mean that you cannot continue
> without fixing it up first, and you might get the next
> error immediately after that.
>
> Arnd <><
Yes, but need to be careful not to lose that next error, and these
errors only block one queue. I handle this by reporting them on an
eventfd, per vq, which userspace can poll.
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
From: Rafael J. Wysocki @ 2009-08-20 14:52 UTC (permalink / raw)
To: Francis Moreau; +Cc: Linux Kernel Mailing List, Kernel Testers List, netdev
In-Reply-To: <38b2ab8a0908200038k2702109bp7e2d4b50e511d365-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday 20 August 2009, Francis Moreau wrote:
> Hello,
>
> On Wed, Aug 19, 2009 at 10:40 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
> > Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
> > Submitter : Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2009-05-03 16:22 (109 days old)
> > References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
> >
>
> It hasn't triggered on 2.6.31-rc5 after a couple of days.
Great, let's assume it's fixed, then.
Thanks,
Rafael
^ permalink raw reply
* Sparc X1 Tulip Issue - NetDev
From: Jim Gifford @ 2009-08-20 14:37 UTC (permalink / raw)
To: netdev
Dave Miller asked me to forward this report here.
I've tried reporting this several times, this issue started with 2.6.24.
It randomly just stops transmitting after receiving after an oops.
This is from a fresh install of a 2.6.30.5 kernel.
[35883.804335] WARNING: at net/sched/sch_generic.c:226
dev_watchdog+0x24c/0x260()
[35883.804351] NETDEV WATCHDOG: eth0 (tulip): transmit timed out
[35883.804362] Modules linked in: tulip bitrev crc32
[35883.804383] Call Trace:
[35883.804406] [0000000000452308] warn_slowpath_fmt+0x28/0x40
[35883.804427] [000000000060420c] dev_watchdog+0x24c/0x260
[35883.804449] [000000000045c520] run_timer_softirq+0x180/0x200
[35883.804473] [00000000004577e8] __do_softirq+0xa8/0x180
[35883.804495] [000000000042a470] do_softirq+0x70/0xa0
[35883.804514] [0000000000457478] irq_exit+0x78/0xa0
[35883.804537] [000000000042f578] timer_interrupt+0x58/0xa0
[35883.804558] [00000000004209d4] tl0_irq14+0x14/0x20
[35883.804582] [00000000004398c8] touch_nmi_watchdog+0x8/0x40
[35883.804607] [000000000074e738] start_kernel+0x278/0x2b4
[35883.804633] [000000000065c344] tlb_fixup_done+0x80/0x9c
[35883.804648] [0000000000000000] (null)
[35883.804659] ---[ end trace 7e1dab9c687ff5bf ]---
[35883.806006] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35891.801619] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35899.797635] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35907.793597] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35915.789526] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
[35923.785595] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20e0000)
Here's the error I got a long time ago with a 2.6.26 kernel
[ 6423.138199] ------------[ cut here ]------------
[ 6423.138230] WARNING: at net/sched/sch_generic.c:219
dev_watchdog+0x250/0x280()
[ 6423.138243] NETDEV WATCHDOG: eth0 (tulip): transmit timed out
[ 6423.138252] Modules linked in: openpromfs tulip
[ 6423.138268] Call Trace:
[ 6423.138285] [00000000005ecf10] dev_watchdog+0x250/0x280
[ 6423.138307] [000000000045f64c] run_timer_softirq+0x16c/0x1e0
[ 6423.138325] [000000000045ab7c] __do_softirq+0x5c/0xe0
[ 6423.138351] [000000000042e3f0] do_softirq+0x70/0xa0
[ 6423.138366] [000000000045a764] irq_exit+0x84/0xc0
[ 6423.138381] [000000000043327c] timer_interrupt+0x5c/0xc0
[ 6423.138400] [00000000004209d4] tl0_irq14+0x14/0x20
[ 6423.138414] [0000000000428040] cpu_idle+0x20/0xc0
[ 6423.138437] [000000000070c8bc] start_kernel+0x27c/0x2c0
[ 6423.138453] [0000000000643744] tlb_fixup_done+0x80/0x9c
[ 6423.138465] [0000000000000000] 0x0
[ 6423.138475] ---[ end trace f5f651c5dad2e555 ]---
Here's one from 2.6.28
[131219.643283] ------------[ cut here ]------------
[131219.643314] WARNING: at net/sched/sch_generic.c:219
dev_watchdog+0x250/0x280()
[131219.643327] NETDEV WATCHDOG: eth0 (tulip): transmit timed out
[131219.643337] Modules linked in: openpromfs tulip
[131219.643353] Call Trace:
[131219.643369] [00000000005ecf10] dev_watchdog+0x250/0x280
[131219.643392] [000000000045f64c] run_timer_softirq+0x16c/0x1e0
[131219.643409] [000000000045ab7c] __do_softirq+0x5c/0xe0
[131219.643435] [000000000042e3f0] do_softirq+0x70/0xa0
[131219.643450] [000000000045a764] irq_exit+0x84/0xc0
[131219.643466] [000000000043327c] timer_interrupt+0x5c/0xc0
[131219.643484] [00000000004209d4] tl0_irq14+0x14/0x20
[131219.643499] [0000000000428050] cpu_idle+0x30/0xc0
[131219.643522] [000000000070c8bc] start_kernel+0x27c/0x2c0
[131219.643538] [0000000000643744] tlb_fixup_done+0x80/0x9c
[131219.643550] [0000000000000000] 0x0
[131219.643560] ---[ end trace b95673019322adce ]---
[131219.644916] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20ec000)
[131227.640686] 0000:00:0c.0: tulip_stop_rxtx() failed (CSR5 0xfc508100
CSR6 0x20ec000)
Here are the other times I reported the issue.
http://kerneltrap.org/mailarchive/linux-net/2008/10/27/3818464
http://marc.info/?l=linux-sparc&m=123195048607500&w=2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox