* Re: [net-2.6 PATCH] igb: use correct bits to identify if managability is enabled
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100326031506.10368.40559.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:15:06 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> igb was previously checking the wrong bits in the MANC register to determine
> if managability was enabled. As a result it was incorrectly powering down and
> resetting the phy when it didn't need to.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] benet: Fix compile warnnings in drivers/net/benet/be_ethtool.c
From: David Miller @ 2010-03-27 15:32 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: wzt.wzt, linux-kernel, netdev, linux-drivers, sathyap
In-Reply-To: <20100326171616.GA20879@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Fri, 26 Mar 2010 22:46:18 +0530
> On 26/03/10 14:12 +0800, wzt.wzt@gmail.com wrote:
>> Fix the following warnings:
>>
>> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>>
>> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
>
> I would suggest using be2net instead of benet during the commit.
> be2net: Fix compile warnnings in drivers/net/benet/be_ethtool.c
>
> Acked-by: Ajit Khaparde <ajitk@serverengines.com>
Well, you cannot be surprised that people will use "benet"
since that is the name of the directory the driver lives
under. It is not even referred to as "be2net" in the
MAINTAINERS entry.
I'm applying this fix as-is.
^ permalink raw reply
* Re: [PATCH v2] Add MSG_WAITFORONE flag to recvmmsg
From: David Miller @ 2010-03-27 15:29 UTC (permalink / raw)
To: acme; +Cc: blblack, netdev, drepper, linux-kernel
In-Reply-To: <20100327140717.GN3625@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Sat, 27 Mar 2010 11:07:17 -0300
> Em Fri, Mar 26, 2010 at 08:54:28PM -0700, David Miller escreveu:
>> From: Brandon L Black <blblack@gmail.com>
>> Date: Fri, 26 Mar 2010 21:18:03 -0500
>>
>> >
>> > From: Brandon L Black <blblack@gmail.com>
>> >
>> > Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
>> > When this flag is specified for a blocking socket, recvmmsg()
>> > will only block until at least 1 packet is available. The
>> > default behavior is to block until all vlen packets are
>> > available. This flag has no effect on non-blocking sockets
>> > or when used in combination with MSG_DONTWAIT.
>> >
>> > Signed-off-by: Brandon L Black <blblack@gmail.com>
>>
>> Arnaldo, please review this, thanks.
>
> I'm ok with it.
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Regression in virtio_net causing kernel BUG when running under VirtualBox (bisected)
From: Thomas Müller @ 2010-03-27 14:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Thomas Müller
[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]
Hello,
I'm running Linux under VirtualBox 3.1.6 with a single virtual CPU
without any third party drivers.
Commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399
(virtio_net: Defer skb allocation in receive path)
caused a regression which results in a kernel bug and subsequent
hang at every boot.
I have attached the complete output during boot.
Please CC me on reply as I'm not subscribed to the mailing lists.
Best regards,
Thomas
------------[ cut here ]------------
kernel BUG at include/linux/scatterlist.h:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/tty/tty56/uevent
CPU 0
Pid: 299, comm: modprobe Not tainted 2.6.33-rc5-00614-g9ab86bb #15 /VirtualBox
RIP: 0010:[<ffffffffa0026271>] [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP: 0000:ffff88007a615bd8 EFLAGS: 00010286
RAX: ffffea0001ac86b0 RBX: ffff88007a615c18 RCX: 0000000087654321
RDX: 0000000000000246 RSI: ffff88007a6fa2b0 RDI: ffff88007a6fa2b0
RBP: ffff88007a615bf8 R08: 0000000000000020 R09: 0000000000000640
R10: ffff88007a615c08 R11: ffff88007d098000 R12: ffff88007a6fa2b0
R13: 000000000000000a R14: 0000160000000000 R15: ffff88007a615c98
FS: 00007f9d6b27c700(0000) GS:ffff880004a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fec3fcd72c0 CR3: 000000007a43c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 299, threadinfo ffff88007a614000, task ffff88007b8b2470)
Stack:
ffff88007a615bf8 ffff88007a6fa280 ffff88007a615c18 ffff88007b980880
<0> ffff88007a615c88 ffffffffa0026a08 ffff88007a615c18 ffffffff8107d5c1
<0> ffff88007a615c48 0000000000000246 0000000000000010 ffff88007b980000
Call Trace:
[<ffffffffa0026a08>] add_recvbuf_small+0x66/0xac [virtio_net]
[<ffffffff8107d5c1>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81454932>] ? mutex_unlock+0xe/0x10
[<ffffffff813ccae6>] ? __rtnl_unlock+0x15/0x17
[<ffffffffa0026b55>] try_fill_recv+0x107/0x155 [virtio_net]
[<ffffffff813ccacf>] ? rtnl_unlock+0xe/0x10
[<ffffffffa0026f6b>] virtnet_probe+0x3c8/0x46f [virtio_net]
[<ffffffffa0026151>] ? skb_recv_done+0x0/0x3f [virtio_net]
[<ffffffffa002610d>] ? skb_xmit_done+0x0/0x44 [virtio_net]
[<ffffffffa000007c>] ? add_status+0x32/0x3a [virtio]
[<ffffffffa00002df>] virtio_dev_probe+0xb7/0xdb [virtio]
[<ffffffff812e30a3>] driver_probe_device+0xed/0x21a
[<ffffffff812e322d>] __driver_attach+0x5d/0x81
[<ffffffff812e31d0>] ? __driver_attach+0x0/0x81
[<ffffffff812e2507>] bus_for_each_dev+0x59/0x8e
[<ffffffff812e2e2a>] driver_attach+0x1e/0x20
[<ffffffff812e2a4a>] bus_add_driver+0xd8/0x242
[<ffffffff812e3534>] driver_register+0x9e/0x10f
[<ffffffffa000b000>] ? init+0x0/0x12 [virtio_net]
[<ffffffffa0000441>] register_virtio_driver+0x27/0x2a [virtio]
[<ffffffffa000b010>] init+0x10/0x12 [virtio_net]
[<ffffffff8100207d>] do_one_initcall+0x72/0x18a
[<ffffffff8108b116>] sys_init_module+0xd8/0x23a
[<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
Code: 49 89 f4 e8 f2 ce 00 e1 48 c1 e8 0c 48 b9 00 00 00 00 00 ea ff ff 48 8b 53 08 48 6b c0 38 48
01 c8 b9 21 43 65 87 48 39 0b 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 41 81 e4 ff 0f
RIP [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP <ffff88007a615bd8>
---[ end trace 0110e718da6da1ad ]---
[-- Attachment #2: boot.txt --]
[-- Type: text/plain, Size: 18065 bytes --]
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.33-rc5-00614-g9ab86bb (thomas@Rawhide-virt) (gcc version 4.4.3 20100226 (Red Hat 4.4.3-8) (GCC) ) #15 SMP Sat Mar 27 14:09:46 CET 2010
Command line: ro root=UUID=5bd27a38-a65f-451b-ad4d-096afb2dff69 LANG=de_DE.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1 vga=0x307 console=tty0 console=ttyS0,9600n8
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
BIOS-e820: 000000007fff0000 - 0000000080000000 (ACPI data)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
NX (Execute Disable) protection: active
DMI 2.5 present.
No AGP bridge found
last_pfn = 0x7fff0 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
CPU MTRRs all blank - virtualized system.
found SMP MP-table at [ffff88000009fff0] 9fff0
init_memory_mapping: 0000000000000000-000000007fff0000
RAMDISK: 37c37000 - 37fef3d1
ACPI: RSDP 00000000000e0000 00024 (v02 VBOX )
ACPI: XSDT 000000007fff0030 00034 (v01 VBOX VBOXXSDT 00000001 ASL 00000061)
ACPI: FACP 000000007fff00f0 000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061)
ACPI: DSDT 000000007fff0270 01A0C (v01 VBOX VBOXBIOS 00000002 INTL 20050309)
ACPI: FACS 000000007fff01f0 00040
ACPI: APIC 000000007fff0230 00040 (v02 VBOX VBOXAPIC 00000001 ASL 00000061)
No NUMA configuration found
Faking a node at 0000000000000000-000000007fff0000
Bootmem setup node 0 0000000000000000-000000007fff0000
NODE_DATA [000000000000a000 - 0000000000022fff]
bootmap [0000000000023000 - 0000000000032fff] pages 10
(12 early reservations) ==> bootmem [0000000000 - 007fff0000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000]
#1 [0001000000 - 00029b3020] TEXT DATA BSS ==> [0001000000 - 00029b3020]
#2 [0037c37000 - 0037fef3d1] RAMDISK ==> [0037c37000 - 0037fef3d1]
#3 [00029b4000 - 00029b4071] BRK ==> [00029b4000 - 00029b4071]
#4 [000009fc00 - 000009fff0] BIOS reserved ==> [000009fc00 - 000009fff0]
#5 [000009fff0 - 00000a0000] MP-table mpf ==> [000009fff0 - 00000a0000]
#6 [00000a0000 - 00000e1160] BIOS reserved ==> [00000a0000 - 00000e1160]
#7 [00000e1230 - 0000100000] BIOS reserved ==> [00000e1230 - 0000100000]
#8 [00000e1160 - 00000e1230] MP-table mpc ==> [00000e1160 - 00000e1230]
#9 [0000001000 - 0000003000] TRAMPOLINE ==> [0000001000 - 0000003000]
#10 [0000003000 - 0000007000] ACPI WAKEUP ==> [0000003000 - 0000007000]
#11 [0000008000 - 000000a000] PGTABLE ==> [0000008000 - 000000a000]
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x0000009f
0: 0x00000100 -> 0x0007fff0
ACPI: PM-Timer IO Port: 0x4008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 1 CPUs, 0 hotplug CPUs
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 80000000 (gap: 80000000:7ffc0000)
Booting paravirtualized kernel on bare hardware
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_node_ids:1
PERCPU: Embedded 478 pages/cpu @ffff880004a00000 s1927256 r8192 d22440 u2097152
pcpu-alloc: s1927256 r8192 d22440 u2097152 alloc=1*2097152
pcpu-alloc: [0] 0
Built 1 zonelists in Node order, mobility grouping on. Total pages: 516903
Policy zone: DMA32
Kernel command line: ro root=UUID=5bd27a38-a65f-451b-ad4d-096afb2dff69 LANG=de_DE.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1 vga=0x307 console=tty0 console=ttyS0,9600n8
PID hash table entries: 4096 (order: 3, 32768 bytes)
Checking aperture...
No AGP bridge found
Memory: 2035136k/2097088k available (4471k kernel code, 388k absent, 61564k reserved, 7461k data, 2744k init)
SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:4352 nr_irqs:256
Console: colour dummy device 80x25
console [tty0] enabled
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8191
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 6367 kB
per task-struct memory footprint: 2688 bytes
allocated 20971520 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Fast TSC calibration using PIT
Detected 2969.177 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 5938.35 BogoMIPS (lpj=2969177)
Security Framework initialized
SELinux: Initializing.
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Initializing cgroup subsys blkio
mce: CPU supports 0 MCE banks
using mwait in idle threads.
Performance Events: unsupported p6 CPU model 23 no PMU driver, software events only.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 29k freed
ACPI: Core revision 20091214
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 21066 entries in 83 pages
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
CPU0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz stepping 06
Brought up 1 CPUs
Total of 1 processors activated (5938.35 BogoMIPS).
devtmpfs: initialized
regulator: core version 0.5
Time: 14:29:24 Date: 03/27/10
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci_root PNP0A03:00: ignoring host bridge windows from ACPI; boot with "pci=use_crs" to use them
ACPI: PCI Interrupt Link [LNKA] (IRQs *5 9 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 9 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 9 *10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *9 10 11)
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
Switching to clocksource tsc
kstop/0 used greatest stack depth: 6424 bytes left
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 6 devices
ACPI: ACPI bus type pnp unregistered
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 10, 4718592 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
UDP hash table entries: 1024 (order: 5, 163840 bytes)
UDP-Lite hash table entries: 1024 (order: 5, 163840 bytes)
NET: Registered protocol family 1
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: Activating ISA DMA hang workarounds
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3808k freed
DMA-API: preallocated 32768 debug entries
DMA-API: debugging enabled by kernel config
platform rtc_cmos: registered platform RTC device (no PNP device found)
Intel PCLMULQDQ-NI instructions are not detected.
audit: initializing netlink socket (disabled)
type=2000 audit(1269700164.597:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
EXT4-fs: Unable to register as ext3 (-16)
msgmni has been set to 3982
cryptomgr_test used greatest stack depth: 5880 bytes left
cryptomgr_test used greatest stack depth: 5592 bytes left
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
pci-stub: invalid id string ""
vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90000d00000, using 2560k, total 32768k
vesafb: mode is 1280x1024x8, linelength=1280, pages=5
vesafb: scrolling: redraw
vesafb: Pseudocolor: size=8:8:8:8, shift=0:0:0:0
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
ACPI: AC Adapter [AC] (on-line)
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
ÿserial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input2
ahci 0000:00:0d.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
ahci: SSS flag set, parallel bus scan disabled
ahci 0000:00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
ahci 0000:00:0d.0: flags: 64bit ncq stag only ccc
scsi0 : ahci
ata1: SATA max UDMA/133 abar m8192@0xf0406000 port 0xf0406100 irq 21
scsi1 : ata_piix
scsi2 : ata_piix
ata2: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xd000 irq 14
ata3: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xd008 irq 15
Fixed MDIO Bus: probed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:0b.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
ehci_hcd 0000:00:0b.0: EHCI Host Controller
ehci_hcd 0000:00:0b.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0b.0: irq 19, io mem 0xf0405000
ehci_hcd 0000:00:0b.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.33-rc5-00614-g9ab86bb ehci_hcd
usb usb1: SerialNumber: 0000:00:0b.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:06.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
ohci_hcd 0000:00:06.0: OHCI Host Controller
ohci_hcd 0000:00:06.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:06.0: irq 22, io mem 0xf0404000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.33-rc5-00614-g9ab86bb ohci_hcd
usb usb2: SerialNumber: 0000:00:06.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 8 ports detected
uhci_hcd: USB Universal Host Controller Interface driver
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, 114 bytes nvram
device-mapper: uevent: version 1.0.3
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4
device-mapper: ioctl: 4.16.0-ioctl (2009-11-05) initialised: dm-devel@redhat.com
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 17
registered taskstats version 1
No TPM chip found, activating TPM-bypass!
Magic number: 2:421:486
rtc_cmos rtc_cmos: setting system clock to 2010-03-27 14:29:25 UTC (1269700165)
Initalizing network drop monitor service
ata3.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133
ata3.00: configured for UDMA/100
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133
ata1.00: 104857600 sectors, multi 128: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA VBOX HARDDISK 1.0 PQ: 0 ANSI: 5
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 2:0:0:0: CD-ROM VBOX CD-ROM 1.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 104857600 512-byte logical blocks: (53.6 GB/50.0 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sr0: scsi3-mmc drive: 32x/32x xa/form2 tray
Uniform CD-ROM driver Revision: 3.20
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sr 2:0:0:0: Attached scsi generic sg1 type 5
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
Freeing unused kernel memory: 2744k freed
Write protecting the kernel read-only data: 10240k
Freeing unused kernel memory: 1652k freed
Freeing unused kernel memory: 1880k freed
mknod used greatest stack depth: 5424 bytes left
dracut: dracut-005-1.fc14
udevd used greatest stack depth: 5048 bytes left
udev: starting version 151
dracut: Starting plymouth daemon
^[%Gscsi_id used greatest stack depth: 4192 bytes left
virtio-pci 0000:00:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
async/2 used greatest stack depth: 3800 bytes left
^[%GEXT4-fs (sda3): mounted filesystem with ordered data mode
dracut: Mounted root filesystem /dev/sda3
dracut: Switching root
Welcome to Fedora
Press 'I' to enter interactive startup.
udev starten: ------------[ cut here ]------------
kernel BUG at include/linux/scatterlist.h:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/tty/tty56/uevent
CPU 0
Pid: 299, comm: modprobe Not tainted 2.6.33-rc5-00614-g9ab86bb #15 /VirtualBox
RIP: 0010:[<ffffffffa0026271>] [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP: 0000:ffff88007a615bd8 EFLAGS: 00010286
RAX: ffffea0001ac86b0 RBX: ffff88007a615c18 RCX: 0000000087654321
RDX: 0000000000000246 RSI: ffff88007a6fa2b0 RDI: ffff88007a6fa2b0
RBP: ffff88007a615bf8 R08: 0000000000000020 R09: 0000000000000640
R10: ffff88007a615c08 R11: ffff88007d098000 R12: ffff88007a6fa2b0
R13: 000000000000000a R14: 0000160000000000 R15: ffff88007a615c98
FS: 00007f9d6b27c700(0000) GS:ffff880004a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fec3fcd72c0 CR3: 000000007a43c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 299, threadinfo ffff88007a614000, task ffff88007b8b2470)
Stack:
ffff88007a615bf8 ffff88007a6fa280 ffff88007a615c18 ffff88007b980880
<0> ffff88007a615c88 ffffffffa0026a08 ffff88007a615c18 ffffffff8107d5c1
<0> ffff88007a615c48 0000000000000246 0000000000000010 ffff88007b980000
Call Trace:
[<ffffffffa0026a08>] add_recvbuf_small+0x66/0xac [virtio_net]
[<ffffffff8107d5c1>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81454932>] ? mutex_unlock+0xe/0x10
[<ffffffff813ccae6>] ? __rtnl_unlock+0x15/0x17
[<ffffffffa0026b55>] try_fill_recv+0x107/0x155 [virtio_net]
[<ffffffff813ccacf>] ? rtnl_unlock+0xe/0x10
[<ffffffffa0026f6b>] virtnet_probe+0x3c8/0x46f [virtio_net]
[<ffffffffa0026151>] ? skb_recv_done+0x0/0x3f [virtio_net]
[<ffffffffa002610d>] ? skb_xmit_done+0x0/0x44 [virtio_net]
[<ffffffffa000007c>] ? add_status+0x32/0x3a [virtio]
[<ffffffffa00002df>] virtio_dev_probe+0xb7/0xdb [virtio]
[<ffffffff812e30a3>] driver_probe_device+0xed/0x21a
[<ffffffff812e322d>] __driver_attach+0x5d/0x81
[<ffffffff812e31d0>] ? __driver_attach+0x0/0x81
[<ffffffff812e2507>] bus_for_each_dev+0x59/0x8e
[<ffffffff812e2e2a>] driver_attach+0x1e/0x20
[<ffffffff812e2a4a>] bus_add_driver+0xd8/0x242
[<ffffffff812e3534>] driver_register+0x9e/0x10f
[<ffffffffa000b000>] ? init+0x0/0x12 [virtio_net]
[<ffffffffa0000441>] register_virtio_driver+0x27/0x2a [virtio]
[<ffffffffa000b010>] init+0x10/0x12 [virtio_net]
[<ffffffff8100207d>] do_one_initcall+0x72/0x18a
[<ffffffff8108b116>] sys_init_module+0xd8/0x23a
[<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
Code: 49 89 f4 e8 f2 ce 00 e1 48 c1 e8 0c 48 b9 00 00 00 00 00 ea ff ff 48 8b 53 08 48 6b c0 38 48 01 c8 b9 21 43 65 87 48 39 0b 74 04 <0f> 0b eb fe f6 c2 01 74 04 0f 0b eb fe 83 e2 03 41 81 e4 ff 0f
RIP [<ffffffffa0026271>] sg_set_buf+0x46/0x74 [virtio_net]
RSP <ffff88007a615bd8>
---[ end trace 0110e718da6da1ad ]---
^[%Gparport_pc 00:05: reported by Plug and Play ACPI
ppdev: user-space parallel port driver
udevd-work[270]: '/sbin/modprobe -b virtio:d00000001v00001AF4' unexpected exit with status 0x000b
[ OK ]
Rechnername Rawhide-virt einstellen: [ OK ]
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Arnaldo Carvalho de Melo @ 2010-03-27 14:26 UTC (permalink / raw)
To: Brandon Black; +Cc: Chris Friesen, linux-kernel, netdev
In-Reply-To: <84621a61003270619p6b4fe81bi24bb1961aba77ffb@mail.gmail.com>
Em Sat, Mar 27, 2010 at 08:19:09AM -0500, Brandon Black escreveu:
> On Wed, Mar 24, 2010 at 2:55 PM, Brandon Black <blblack@gmail.com> wrote:
> > On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@nortel.com> wrote:
> >> Consider the case where you want to do some other useful work in
> >> addition to running your network server. Every cpu cycle spent on the
> >> network server is robbed from the other work. In this scenario you want
> >> to handle packets as efficiently as possible, so the timeout-based
> >> behaviour is better since it is more likely to give you multiple packets
> >> per syscall.
> >
> > That's a good point, I tend to tunnelvision on the dedicated server
> > scenario. I should probably have a user-level option for
> > timeout-based operation as well, since the decision here gets to the
> > systems admin/engineering level and will be situational.
>
> I've been playing with the timeout argument to recvmmsg as well now,
> and I'm struggling to see how one would ever use it correctly with the
> current implementation. It seems to rely on the assumption of a
> never-ending stream of tightly-spaced input packets? It seems like it
As said by somebody else in this recent discussion (perhaps Chris), it
is based on the maximum latency acceptable.
If minimum latency is desired, use a zero timeout and get as many
packets get queued up while the application is processing the last
batch.
If instead more packets are desired per batch and some latency is
acceptable, use a timeout.
10 Gbit/s interfaces were the target but results with simple app
published when the syscall was posted initially showed that even on 1
1 Gbit/s eth this helped.
> was meant for usage on blocking sockets. Given a blocking socket with
> timeout 0 (infinite), and a recvmmsg timeout of 100us, if you had a
> very steady stream of input packets, it recvmmsg would pull in all of
> them that it could within a max timeframe of (100us +
> time_to_execute_one_recvmsg). However, any disruption to the input
> stream for a time-window of N would result in delaying some
> already-received packets by N. For example, consider the case that 2
> packets are already queued when you invoke recvmmsg(), but then the
> next packet doesn't arrive for another 300ms. In this scenario, you'd
> end up with recvmmsg() blocking for 300ms and then returning all 3
> packets, two of which have been delayed way beyond the specified
> timeout.
And that is a use case that is fixed by your patch, thanks, now we cover
more use cases :-)
- Arnaldo
^ permalink raw reply
* Re: Does Realtek RTL8110S and RTL8100C work ?
From: Jan Ceuleers @ 2010-03-27 14:12 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hoiqcr$dhl$1@dough.gmane.org>
Markus Feldmann wrote:
> Thanks for you answer Jan,
>
> do you know the developer e-mail adress?
> So 1000Mbit/s is not possible at the moment, but does it work stable?
>
> regards Markus
Markus,
You misunderstood. The first of the interfaces I listed is operating at 1Gbit/s; the second is only operating at 100Mbit/s because the device it is connected to (on the other end of the Ethernet cable) is not capable of anything faster.
I have no reliability issues with these network interfaces. Note though that my mainboard is quite low-end (Via C7 1.5GHz), so that the network interfaces never really get stressed.
Jan
^ permalink raw reply
* Re: [PATCH v2] Add MSG_WAITFORONE flag to recvmmsg
From: Arnaldo Carvalho de Melo @ 2010-03-27 14:07 UTC (permalink / raw)
To: David Miller; +Cc: blblack, netdev, drepper, linux-kernel
In-Reply-To: <20100326.205428.44779758.davem@davemloft.net>
Em Fri, Mar 26, 2010 at 08:54:28PM -0700, David Miller escreveu:
> From: Brandon L Black <blblack@gmail.com>
> Date: Fri, 26 Mar 2010 21:18:03 -0500
>
> >
> > From: Brandon L Black <blblack@gmail.com>
> >
> > Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
> > When this flag is specified for a blocking socket, recvmmsg()
> > will only block until at least 1 packet is available. The
> > default behavior is to block until all vlen packets are
> > available. This flag has no effect on non-blocking sockets
> > or when used in combination with MSG_DONTWAIT.
> >
> > Signed-off-by: Brandon L Black <blblack@gmail.com>
>
> Arnaldo, please review this, thanks.
I'm ok with it.
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
- Arnaldo
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Brandon Black @ 2010-03-27 13:19 UTC (permalink / raw)
To: Chris Friesen, Arnaldo Carvalho de Melo; +Cc: linux-kernel, netdev
In-Reply-To: <84621a61003241255i74282f53v3bb0111808895401@mail.gmail.com>
On Wed, Mar 24, 2010 at 2:55 PM, Brandon Black <blblack@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@nortel.com> wrote:
>> Consider the case where you want to do some other useful work in
>> addition to running your network server. Every cpu cycle spent on the
>> network server is robbed from the other work. In this scenario you want
>> to handle packets as efficiently as possible, so the timeout-based
>> behaviour is better since it is more likely to give you multiple packets
>> per syscall.
>
> That's a good point, I tend to tunnelvision on the dedicated server
> scenario. I should probably have a user-level option for
> timeout-based operation as well, since the decision here gets to the
> systems admin/engineering level and will be situational.
I've been playing with the timeout argument to recvmmsg as well now,
and I'm struggling to see how one would ever use it correctly with the
current implementation. It seems to rely on the assumption of a
never-ending stream of tightly-spaced input packets? It seems like it
was meant for usage on blocking sockets. Given a blocking socket with
timeout 0 (infinite), and a recvmmsg timeout of 100us, if you had a
very steady stream of input packets, it recvmmsg would pull in all of
them that it could within a max timeframe of (100us +
time_to_execute_one_recvmsg). However, any disruption to the input
stream for a time-window of N would result in delaying some
already-received packets by N. For example, consider the case that 2
packets are already queued when you invoke recvmmsg(), but then the
next packet doesn't arrive for another 300ms. In this scenario, you'd
end up with recvmmsg() blocking for 300ms and then returning all 3
packets, two of which have been delayed way beyond the specified
timeout.
-- Brandon
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Andi Kleen @ 2010-03-27 13:11 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andi Kleen, David Miller, netdev, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1003261231410.30253@router.home>
On Fri, Mar 26, 2010 at 12:33:07PM -0500, Christoph Lameter wrote:
> Here is a pgm.7 manpage describing how the socket API could look like for
> a PGM implementation.
>
> I dumped the RM_* based socket options from the other OS since most of the
> options were unusable.
I did a quick read and the manpage/interface seem reasonable to me.
You changed the parameter struct fields to lower case. While
that looks definitely more Linuxy than before does it mean programs
have to #ifdef this? It might be good idea to have at least some
optional compat header that #defines.
-Andi
^ permalink raw reply
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Wolfram Sang @ 2010-03-27 12:57 UTC (permalink / raw)
To: Bryan Wu
Cc: s.hauer, gerg, amit.kucheria, netdev, kernel-team, linux-kernel,
linux-arm-kernel
In-Reply-To: <1269597052-10104-1-git-send-email-bryan.wu@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On Fri, Mar 26, 2010 at 05:50:52PM +0800, Bryan Wu wrote:
> BugLink: http://bugs.launchpad.net/bugs/457878
>
> - removed old MII phy control code
> - add phylib supporting
> - add ethtool interface to make user space NetworkManager works
>
> Tested on Freescale i.MX51 Babbage board.
Sadly, I have problems here booting a custom board:
...
FEC Ethernet Driver
fec_enet_mii_bus: probed
eth0: Freescale FEC PHY driver [SMSC LAN8700] (mii_bus:phy_addr=0:1f, irq=-1)
... (That's fine, so far)
PHY: 0:1f - Link is Up - 100/Full
... (also nice)
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x2c0/0x2e0()
NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Modules linked in:
[<c001f8d4>] (unwind_backtrace+0x0/0xe4) from [<c002d1d0>] (warn_slowpath_common+0x4c/0x80)
[<c002d1d0>] (warn_slowpath_common+0x4c/0x80) from [<c002d240>] (warn_slowpath_fmt+0x28/0x38)
[<c002d240>] (warn_slowpath_fmt+0x28/0x38) from [<c01be32c>] (dev_watchdog+0x2c0/0x2e0)
[<c01be32c>] (dev_watchdog+0x2c0/0x2e0) from [<c0038740>] (run_timer_softirq+0x1c0/0x274)
[<c0038740>] (run_timer_softirq+0x1c0/0x274) from [<c0032f98>] (__do_softirq+0x8c/0x120)
[<c0032f98>] (__do_softirq+0x8c/0x120) from [<c00330b0>] (irq_exit+0x84/0xa0)
[<c00330b0>] (irq_exit+0x84/0xa0) from [<c001a040>] (asm_do_IRQ+0x40/0x8c)
[<c001a040>] (asm_do_IRQ+0x40/0x8c) from [<c001ab8c>] (__irq_svc+0x4c/0x8c)
Exception stack(0xc02c3f78 to 0xc02c3fc0)
3f60: 00000000 0005317f
3f80: 0005217f 60000013 c02c2000 c02db7ec c02c59c4 c02c59b8 a0018270 41069264
3fa0: a001823c 00000000 600000d3 c02c3fc0 c001ba8c c001ba98 60000013 ffffffff
[<c001ab8c>] (__irq_svc+0x4c/0x8c) from [<c001ba98>] (default_idle+0x2c/0x34)
[<c001ba98>] (default_idle+0x2c/0x34) from [<c001bfac>] (cpu_idle+0x90/0xc8)
[<c001bfac>] (cpu_idle+0x90/0xc8) from [<c000898c>] (start_kernel+0x234/0x2c0)
[<c000898c>] (start_kernel+0x234/0x2c0) from [<a0008034>] (0xa0008034)
---[ end trace ce1c823381bff119 ]---
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
eth0: tx queue full!.
...
I just threw the patch on top of 2.6.33.1, after picking
633e7533cec78b99d806248e832fc83e689d2453 (fec: fix uninitialized rx buffer
usage), too. Just needed to adapt the Kconfig entry, the patch for fec.c went
smooth. So, I doubt the slightly older kernel is the problem (but will check
net-next somewhen later)? Using the "old" method for the LAN8700, I get a
working eth0, so the hardware should work in general. I will have a closer look
on Monday, this was just a quick try. If you happen to have pointers where to
start, this is appreciated.
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 12:32 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <20100327122642.GA5165@electric-eye.fr.zoreil.com>
François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
>> It seems that adding single printk between writing MAC0 and MAC4 fixes it.
>> I guess it needs a bit of delay between the writes or something.
>
> Can you test with a single RTL_R32 after each MACx write ?
Adding reading back of the written value fixes it too. Though, disassembly
says that it added an extra instructions also (needs to load the 'high' from
stack before writing it) so the added delay is probably slightly more than
just the io read.
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 12:26 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADF738.2060600@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> It seems that adding single printk between writing MAC0 and MAC4 fixes it.
> I guess it needs a bit of delay between the writes or something.
Can you test with a single RTL_R32 after each MACx write ?
--
Ueimor
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 12:25 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADF738.2060600@iki.fi>
Timo Teräs wrote:
> François Romieu wrote:
>> Timo Teräs <timo.teras@iki.fi> :
>> [...]
>>> I don't think this would do anything. The high part is recorded
>>> correctly always.
>>> It's the 'low' part that gets discarded. I can do similar test if
>>> writing it
>>> more times will help. Will post results soon.
>>
>> You may check whether writing MAC4 before MAC0 makes a difference
>> or not as well.
>
> It seems that adding single printk between writing MAC0 and MAC4 fixes it.
> I guess it needs a bit of delay between the writes or something.
Oh, and writing MAC4 first seems to fix it too.
- Timo
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 12:16 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <20100327120358.GA5114@electric-eye.fr.zoreil.com>
François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
>> I don't think this would do anything. The high part is recorded correctly always.
>> It's the 'low' part that gets discarded. I can do similar test if writing it
>> more times will help. Will post results soon.
>
> You may check whether writing MAC4 before MAC0 makes a difference
> or not as well.
It seems that adding single printk between writing MAC0 and MAC4 fixes it.
I guess it needs a bit of delay between the writes or something.
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: Jan Engelhardt @ 2010-03-27 12:14 UTC (permalink / raw)
To: David Miller; +Cc: schwab, tony.luck, netdev
In-Reply-To: <20100324.203249.97351120.davem@davemloft.net>
On Thursday 2010-03-25 04:32, David Miller wrote:
>From: Jan Engelhardt
>Date: Thu, 25 Mar 2010 00:17:01 +0100 (CET)
>
>> No more unaligned messages - but is this [using void*]
>> an acceptable solution?
>
>We already rely on this elsewhere, particularly in the
>xfrm_user code.
Ok, here's it. (We're also getting rid of the double-obtain statistics
that was mentioned in the initial submission.)
Please apply this one, or pull, or cherry-pick from
git://dev.medozas.de/linux net
parent b79d1d54cf0672f764402fe4711ef5306f917bd3 (v2.6.34-rc1-1275-gb79d1d5)
commit c5c57d7c7837858aa499610a3ee760b39f1de937
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Wed Mar 24 19:52:43 2010 +0100
net: fix unaligned access in IFLA_STATS64
Tony Luck observes that the original IFLA_STATS64 submission causes
unaligned accesses. This is because nla_data() returns a pointer to a
memory region that is only aligned to 32 bits. Do some memcpying to
workaround this.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
net/core/rtnetlink.c | 54 +++++++++++++++++++++---------------------
1 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ffc6cf3..ed0766f 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -602,36 +602,38 @@ static void copy_rtnl_link_stats(struct rtnl_link_stats *a,
a->tx_compressed = b->tx_compressed;
}
-static void copy_rtnl_link_stats64(struct rtnl_link_stats64 *a,
- const struct net_device_stats *b)
+static void copy_rtnl_link_stats64(void *v, const struct net_device_stats *b)
{
- a->rx_packets = b->rx_packets;
- a->tx_packets = b->tx_packets;
- a->rx_bytes = b->rx_bytes;
- a->tx_bytes = b->tx_bytes;
- a->rx_errors = b->rx_errors;
- a->tx_errors = b->tx_errors;
- a->rx_dropped = b->rx_dropped;
- a->tx_dropped = b->tx_dropped;
-
- a->multicast = b->multicast;
- a->collisions = b->collisions;
-
- a->rx_length_errors = b->rx_length_errors;
- a->rx_over_errors = b->rx_over_errors;
- a->rx_crc_errors = b->rx_crc_errors;
- a->rx_frame_errors = b->rx_frame_errors;
- a->rx_fifo_errors = b->rx_fifo_errors;
- a->rx_missed_errors = b->rx_missed_errors;
-
- a->tx_aborted_errors = b->tx_aborted_errors;
- a->tx_carrier_errors = b->tx_carrier_errors;
- a->tx_fifo_errors = b->tx_fifo_errors;
- a->tx_heartbeat_errors = b->tx_heartbeat_errors;
- a->tx_window_errors = b->tx_window_errors;
-
- a->rx_compressed = b->rx_compressed;
- a->tx_compressed = b->tx_compressed;
+ struct rtnl_link_stats64 a;
+
+ a.rx_packets = b->rx_packets;
+ a.tx_packets = b->tx_packets;
+ a.rx_bytes = b->rx_bytes;
+ a.tx_bytes = b->tx_bytes;
+ a.rx_errors = b->rx_errors;
+ a.tx_errors = b->tx_errors;
+ a.rx_dropped = b->rx_dropped;
+ a.tx_dropped = b->tx_dropped;
+
+ a.multicast = b->multicast;
+ a.collisions = b->collisions;
+
+ a.rx_length_errors = b->rx_length_errors;
+ a.rx_over_errors = b->rx_over_errors;
+ a.rx_crc_errors = b->rx_crc_errors;
+ a.rx_frame_errors = b->rx_frame_errors;
+ a.rx_fifo_errors = b->rx_fifo_errors;
+ a.rx_missed_errors = b->rx_missed_errors;
+
+ a.tx_aborted_errors = b->tx_aborted_errors;
+ a.tx_carrier_errors = b->tx_carrier_errors;
+ a.tx_fifo_errors = b->tx_fifo_errors;
+ a.tx_heartbeat_errors = b->tx_heartbeat_errors;
+ a.tx_window_errors = b->tx_window_errors;
+
+ a.rx_compressed = b->rx_compressed;
+ a.tx_compressed = b->tx_compressed;
+ memcpy(v, &a, sizeof(a));
}
static inline int rtnl_vfinfo_size(const struct net_device *dev)
@@ -734,8 +736,6 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
sizeof(struct rtnl_link_stats64));
if (attr == NULL)
goto nla_put_failure;
-
- stats = dev_get_stats(dev);
copy_rtnl_link_stats64(nla_data(attr), stats);
if (dev->netdev_ops->ndo_get_vf_config && dev->dev.parent) {
--
# Created with git-export-patch
^ permalink raw reply related
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 12:03 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADF01E.9090906@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> I don't think this would do anything. The high part is recorded correctly always.
> It's the 'low' part that gets discarded. I can do similar test if writing it
> more times will help. Will post results soon.
You may check whether writing MAC4 before MAC0 makes a difference
or not as well.
--
Ueimor
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: =?unknown-8bit?B?RnJhbsOnb2lz?= Romieu @ 2010-03-27 11:57 UTC (permalink / raw)
To: Robert Hancock
Cc: =?unknown-8bit?B?77+9?= Engel, David Miller, torvalds,
linux-kernel, netdev
In-Reply-To: <4BAD65A0.7090309@gmail.com>
Robert Hancock <hancockrwd@gmail.com> :
[...]
> I suppose a publicly accessible datasheet for these chips is too
> much to hope for ?
I was granted access to some documentation for the 8169 and the 8168c
during the "please ask gently and don't disseminate" era then
experienced "the legal department forbids it" for the 8102.
hayeswang at realtek.com is quite supportive though.
--
Ueimor
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 11:46 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <20100327114059.GA3432@electric-eye.fr.zoreil.com>
François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
>> I did some more testing, and added debugging info to rtl_rar_set(). It would
>> appear that even if I write any mac address (with ifconfig) and reread the
>> MAC0..MAC5 register, the first four bytes get zeroed. So it would sounds like
>> the hardware is faulty, or that the rtl_rar_set function is buggy.
>>
>> Any suggestions to fix this ?
>
> Try something like the patch below and please send a complete lspci -vvv.
Attached at the end.
> I wonder what the bus controler looks like.
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 9d3ebf3..5db357a 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -2814,6 +2814,7 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
> void __iomem *ioaddr = tp->mmio_addr;
> u32 high;
> u32 low;
> + int i;
>
> low = addr[0] | (addr[1] << 8) | (addr[2] << 16) | (addr[3] << 24);
> high = addr[4] | (addr[5] << 8);
> @@ -2822,7 +2823,17 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
>
> RTL_W8(Cfg9346, Cfg9346_Unlock);
> RTL_W32(MAC0, low);
> - RTL_W32(MAC4, high);
> + for (i = 0; i < 16; i++) {
> + u32 read;
> +
> + RTL_W32(MAC4, high);
> + read = RTL_R32(MAC4);
> + if (read != high) {
> + printk(KERN_ERR PFX
> + "failure %02d: read = 0x%08x, write = 0x%08x\n",
> + i, read, high);
> + }
> + }
> RTL_W8(Cfg9346, Cfg9346_Lock);
>
> spin_unlock_irq(&tp->lock);
I don't think this would do anything. The high part is recorded correctly always.
It's the 'low' part that gets discarded. I can do similar test if writing it
more times will help. Will post results soon.
- Timo
00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
Subsystem: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+ INTx-
Latency: 8
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Capabilities: [80] AGP version 3.5
Status: RQ=8 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: agpgart-via
00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fb000000-fcffffff
Prefetchable memory behind bridge: f4000000-f7ffffff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR+ <PERR+
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
Subsystem: Jetway Information Co., Ltd. Device 10ec
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at f200 [size=256]
Region 1: Memory at fdfff000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at 3c000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: r8169
00:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (8000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at fdffe000 (32-bit, non-prefetchable) [size=2K]
Region 1: I/O ports at ff00 [size=128]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: firewire_ohci
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
Subsystem: Jetway Information Co., Ltd. Device 10ec
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at f000 [size=256]
Region 1: Memory at fdffd000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at 3c020000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: r8169
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
Subsystem: Jetway Information Co., Ltd. Device 10ec
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at ec00 [size=256]
Region 1: Memory at fdffc000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at 3c040000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: r8169
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Interrupt: pin B routed to IRQ 20
Region 0: I/O ports at fe00 [size=8]
Region 1: I/O ports at fd00 [size=4]
Region 2: I/O ports at fc00 [size=8]
Region 3: I/O ports at fb00 [size=4]
Region 4: I/O ports at fa00 [size=16]
Region 5: I/O ports at ee00 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: sata_via
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Interrupt: pin A routed to IRQ 20
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
Region 4: I/O ports at f900 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pata_via
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 21
Region 4: I/O ports at f800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: uhci_hcd
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 21
Region 4: I/O ports at f700 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: uhci_hcd
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at f600 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: uhci_hcd
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at f500 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: uhci_hcd
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 21
Region 0: Memory at fdffb000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci_hcd
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
Subsystem: VIA Technologies, Inc. DFI KT600-AL / Soltek SL-B9D-FGR Motherboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: Jetway Information Co., Ltd. Device 4170
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 22
Region 0: I/O ports at ea00 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: VIA 82xx Audio
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
Subsystem: VIA Technologies, Inc. VT6102 [Rhine II] Embeded Ethernet Controller on VT8235
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (750ns min, 2000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at e800 [size=256]
Region 1: Memory at fdffa000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: via-rhine
01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller])
Subsystem: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 [S3 UniChrome Pro]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (500ns min)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at f4000000 (32-bit, prefetchable) [size=64M]
Region 1: Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at fc000000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] AGP version 3.0
Status: RQ=256 Iso- ArqSz=0 Cal=7 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 11:40 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADDDB7.4010005@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> I did some more testing, and added debugging info to rtl_rar_set(). It would
> appear that even if I write any mac address (with ifconfig) and reread the
> MAC0..MAC5 register, the first four bytes get zeroed. So it would sounds like
> the hardware is faulty, or that the rtl_rar_set function is buggy.
>
> Any suggestions to fix this ?
Try something like the patch below and please send a complete lspci -vvv.
I wonder what the bus controler looks like.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9d3ebf3..5db357a 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2814,6 +2814,7 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
void __iomem *ioaddr = tp->mmio_addr;
u32 high;
u32 low;
+ int i;
low = addr[0] | (addr[1] << 8) | (addr[2] << 16) | (addr[3] << 24);
high = addr[4] | (addr[5] << 8);
@@ -2822,7 +2823,17 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
RTL_W8(Cfg9346, Cfg9346_Unlock);
RTL_W32(MAC0, low);
- RTL_W32(MAC4, high);
+ for (i = 0; i < 16; i++) {
+ u32 read;
+
+ RTL_W32(MAC4, high);
+ read = RTL_R32(MAC4);
+ if (read != high) {
+ printk(KERN_ERR PFX
+ "failure %02d: read = 0x%08x, write = 0x%08x\n",
+ i, read, high);
+ }
+ }
RTL_W8(Cfg9346, Cfg9346_Lock);
spin_unlock_irq(&tp->lock);
^ permalink raw reply related
* [PATCH net-next-2.6] ipv6 fib: Use "Sweezle" to optimize addr_bit_test().
From: YOSHIFUJI Hideaki @ 2010-03-27 11:24 UTC (permalink / raw)
To: davem; +Cc: yoshfuji, netdev
addr_bit_test() is used in various places in IPv6 routing table
subsystem. It checks if the given fn_bit is set,
where fn_bit counts bits from MSB in words in network-order.
fn_bit : 0 .... 31 32 .... 64 65 .... 95 96 ....127
fn_bit >> 5 gives offset of word, and (~fn_bit & 0x1f) gives
count from LSB in the network-endian word in question.
fn_bit >> 5 : 0 1 2 3
~fn_bit & 0x1f: 31 .... 0 31 .... 0 31 .... 0 31 .... 0
Thus, the mask was generated as htonl(1 << (~fn_bit & 0x1f)).
This can be optimized by "sweezle" (See include/asm-generic/bitops/le.h).
In little-endian,
htonl(1 << bit) = 1 << (bit ^ BITOP_BE32_SWIZZLE)
where
BITOP_BE32_SWIZZLE is (0x1f & ~7)
So,
htonl(1 << (~fn_bit & 0x1f)) = 1 << ((~fn_bit & 0x1f) ^ (0x1f & ~7))
= 1 << ((~fn_bit ^ ~7) & 0x1f)
= 1 << ((~fn_bit ^ BITOP_BE32_SWIZZLE) & 0x1f)
In big-endian, BITOP_BE32_SWIZZLE is equal to 0.
1 << ((~fn_bit ^ BITOP_BE32_SWIZZLE) & 0x1f)
= 1 << ((~fn_bit) & 0x1f)
= htonl(1 << (~fn_bit & 0x1f))
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
net/ipv6/ip6_fib.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 2f98479..68119ef 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -127,12 +127,23 @@ static __inline__ u32 fib6_new_sernum(void)
/*
* test bit
*/
+#if defined(__LITTLE_ENDIAN)
+# define BITOP_BE32_SWIZZLE (0x1F & ~7)
+#else
+# define BITOP_BE32_SWIZZLE 0
+#endif
static __inline__ __be32 addr_bit_set(void *token, int fn_bit)
{
__be32 *addr = token;
-
- return htonl(1 << ((~fn_bit)&0x1F)) & addr[fn_bit>>5];
+ /*
+ * Here,
+ * 1 << ((~fn_bit ^ BITOP_BE32_SWIZZLE) & 0x1f)
+ * is optimized version of
+ * htonl(1 << ((~fn_bit)&0x1F))
+ * See include/asm-generic/bitops/le.h.
+ */
+ return (1 << ((~fn_bit ^ BITOP_BE32_SWIZZLE) & 0x1f)) & addr[fn_bit >> 5];
}
static __inline__ struct fib6_node * node_alloc(void)
--
1.5.6.5
^ permalink raw reply related
* r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 10:28 UTC (permalink / raw)
To: Francois Romieu, Ivan Vecera, netdev
It seems that my r8169 mac address is lost when r8169 module is reloaded,
or system is soft rebooted. Hard power reset recovers the mac address again.
The commit cc098dc705895f6b0109b7e8e026ac2b8ae1c0a1 (r8169: restore mac addr
in rtl8169_remove_one and rtl_shutdown) seems to have broken it. The first four
bytes of mac address go zeroes because of this.
I did some more testing, and added debugging info to rtl_rar_set(). It would
appear that even if I write any mac address (with ifconfig) and reread the
MAC0..MAC5 register, the first four bytes get zeroed. So it would sounds like
the hardware is faulty, or that the rtl_rar_set function is buggy.
Any suggestions to fix this?
The hardware in question is a 3-in-1 NIC. Each three PCI devices shows up as
something like:
00:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet [10ec:8167] (rev 10)
Subsystem: Jetway Information Co., Ltd. Device [16f3:10ec]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at f200 [size=256]
Region 1: Memory at fdfff000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at 3c000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: r8169
And the kernel drivers prints the following at startup:
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:09.0: PCI->APIC IRQ transform: INT A -> IRQ 18
r8169 0000:00:09.0: no PCI Express capability
eth0: RTL8169sc/8110sc at 0xf81ae000, 00:30:18:a6:2b:6c, XID 18000000 IRQ 18
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:0b.0: PCI->APIC IRQ transform: INT A -> IRQ 19
r8169 0000:00:0b.0: no PCI Express capability
eth1: RTL8169sc/8110sc at 0xf81b2000, 00:30:18:a6:2b:6d, XID 18000000 IRQ 19
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:0c.0: PCI->APIC IRQ transform: INT A -> IRQ 16
r8169 0000:00:0c.0: no PCI Express capability
eth2: RTL8169sc/8110sc at 0xf81b6000, 00:30:18:a6:2b:6e, XID 18000000 IRQ 16
- Timo
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: J�rn Engel @ 2010-03-27 6:38 UTC (permalink / raw)
To: Robert Hancock; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <4BAD65A0.7090309@gmail.com>
On Fri, 26 March 2010 19:55:44 -0600, Robert Hancock wrote:
>
> Well, that one's 36 bits, but it's unclear whether that driver would
> actually be likely to access anything over 4GB. It's possible that
> there's just some general problem with 64-bit DMA on that machine.
That may very well be. I've had trouble using a PCIe card in that
machine as well. "Solution" was to buy a different computer. Sad, I
know, but not my money.
> The fact that even stuff like lspci and MII is breaking seems odd,
> though. It could be that model of card doesn't like the PCIDAC register
> bit being set (maybe it means something different on that model, or
> something).
>
> I suppose a publicly accessible datasheet for these chips is too much to
> hope for?
Which chips?
J�rn
^ permalink raw reply
* [PATCH] e1000e: typo corrections
From: Joe Perches @ 2010-03-27 6:16 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, netdev, gospo, bruce.w.allan
In-Reply-To: <20100326.210555.251082007.davem@davemloft.net>
Here are the other miscellaneous corrections
done by an earlier larger suggested patch now
made unnecessary by a less invasive change.
Correct a few missing newlines from logging
messages and a typo fix. Fix speed/duplex
logging message.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/e1000e/82571.c | 2 +-
drivers/net/e1000e/ich8lan.c | 6 +++---
drivers/net/e1000e/lib.c | 21 +++++++++------------
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/net/e1000e/82571.c b/drivers/net/e1000e/82571.c
index 712ccc6..4b0016d 100644
--- a/drivers/net/e1000e/82571.c
+++ b/drivers/net/e1000e/82571.c
@@ -323,7 +323,7 @@ static s32 e1000_init_mac_params_82571(struct e1000_adapter *adapter)
}
/*
- * Initialze device specific counter of SMBI acquisition
+ * Initialize device specific counter of SMBI acquisition
* timeouts.
*/
hw->dev_spec.e82571.smb_counter = 0;
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 8b5e157..5059c22 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -1622,7 +1622,7 @@ static s32 e1000_flash_cycle_init_ich8lan(struct e1000_hw *hw)
/* Check if the flash descriptor is valid */
if (hsfsts.hsf_status.fldesvalid == 0) {
e_dbg("Flash descriptor invalid. "
- "SW Sequencing must be used.");
+ "SW Sequencing must be used.\n");
return -E1000_ERR_NVM;
}
@@ -1671,7 +1671,7 @@ static s32 e1000_flash_cycle_init_ich8lan(struct e1000_hw *hw)
hsfsts.hsf_status.flcdone = 1;
ew16flash(ICH_FLASH_HSFSTS, hsfsts.regval);
} else {
- e_dbg("Flash controller busy, cannot get access");
+ e_dbg("Flash controller busy, cannot get access\n");
}
}
@@ -1822,7 +1822,7 @@ static s32 e1000_read_flash_data_ich8lan(struct e1000_hw *hw, u32 offset,
continue;
} else if (hsfsts.hsf_status.flcdone == 0) {
e_dbg("Timeout error - flash cycle "
- "did not complete.");
+ "did not complete.\n");
break;
}
}
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index a8b2c0d..b0d2a60 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -1262,24 +1262,21 @@ s32 e1000e_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed, u16 *dup
u32 status;
status = er32(STATUS);
- if (status & E1000_STATUS_SPEED_1000) {
+ if (status & E1000_STATUS_SPEED_1000)
*speed = SPEED_1000;
- e_dbg("1000 Mbs, ");
- } else if (status & E1000_STATUS_SPEED_100) {
+ else if (status & E1000_STATUS_SPEED_100)
*speed = SPEED_100;
- e_dbg("100 Mbs, ");
- } else {
+ else
*speed = SPEED_10;
- e_dbg("10 Mbs, ");
- }
- if (status & E1000_STATUS_FD) {
+ if (status & E1000_STATUS_FD)
*duplex = FULL_DUPLEX;
- e_dbg("Full Duplex\n");
- } else {
+ else
*duplex = HALF_DUPLEX;
- e_dbg("Half Duplex\n");
- }
+
+ e_dbg("%u Mbps, %s Duplex\n",
+ *speed == SPEED_1000 ? 1000 : *speed == SPEED_100 ? 100 : 10,
+ *duplex == FULL_DUPLEX ? "Full" : "Half");
return 0;
}
^ permalink raw reply related
* Re: Null dereference in uli526x_rx_packet()
From: Grant Grundler @ 2010-03-27 6:08 UTC (permalink / raw)
To: David Miller; +Cc: grundler, kyle, netdev, error27
In-Reply-To: <20100326.202125.238456279.davem@davemloft.net>
On Fri, Mar 26, 2010 at 08:21:25PM -0700, David Miller wrote:
> From: Grant Grundler <grundler@parisc-linux.org>
> Date: Sun, 7 Feb 2010 00:15:40 -0700
>
> > On Sat, Mar 28, 2009 at 11:59:31PM -0700, David Miller wrote:
> > ...
> >> > Patch below looks right to me. Clobbering the skb is certainly wrong.
> >> >
> >> > Acked-by: Grant Grundler <grundler@parisc-linux.org>
> >>
> >> It looks correct to me, can we get a proper submission with
> >> signoffs etc.?
> >
> > Dave,
> > Looks like this patch was never resubmitted.
> >
> > Kyle, can you look at http://lists.openwall.net/netdev/2009/03/27/117
> > and resubmit the code you had then with my "Acked-by" added please?
> >
> > Or if you don't want to touch it, let me know and I'll resurrect it.
>
> I got tired of waiting for this resubmission (a month and a half) and
> just applied the most recent version of the patch to net-2.6.
>
> It looked correct to me too.
Thank you!
grant
^ permalink raw reply
* Re: [PATCH v2] Add MSG_WAITFORONE flag to recvmmsg
From: Eric Dumazet @ 2010-03-27 6:00 UTC (permalink / raw)
To: Brandon L Black
Cc: netdev, David S. Miller, Arnaldo Carvalho de Melo, Ulrich Drepper,
linux-kernel
In-Reply-To: <20100327021803.GA10866@xpc.home>
Le vendredi 26 mars 2010 à 21:18 -0500, Brandon L Black a écrit :
> From: Brandon L Black <blblack@gmail.com>
>
> Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
> When this flag is specified for a blocking socket, recvmmsg()
> will only block until at least 1 packet is available. The
> default behavior is to block until all vlen packets are
> available. This flag has no effect on non-blocking sockets
> or when used in combination with MSG_DONTWAIT.
>
> Signed-off-by: Brandon L Black <blblack@gmail.com>
>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 7b3aae2..354cc56 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -255,6 +255,7 @@ struct ucred {
> #define MSG_ERRQUEUE 0x2000 /* Fetch message from error queue */
> #define MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
> #define MSG_MORE 0x8000 /* Sender will send more */
> +#define MSG_WAITFORONE 0x10000 /* recvmmsg(): block until 1+ packets avail */
>
> #define MSG_EOF MSG_FIN
>
> diff --git a/net/socket.c b/net/socket.c
> index 769c386..f55ffe9 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -2135,6 +2135,10 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
> break;
> ++datagrams;
>
> + /* MSG_WAITFORONE turns on MSG_DONTWAIT after one packet */
> + if (flags & MSG_WAITFORONE)
> + flags |= MSG_DONTWAIT;
> +
> if (timeout) {
> ktime_get_ts(timeout);
> *timeout = timespec_sub(end_time, *timeout);
> --
^ 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