* Re: Realtek r8168 slow outbound transfer - potential fix/workaround
From: Bruce Cole @ 2007-08-15 7:17 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Gundersen
In-Reply-To: <20070814211954.GA3552@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Bruce Cole <bacole@gmail.com> :
> [...]
>
>> What's the status of this fix? It (or something more refined) seems
>> necessary to correct the current performance problems with this driver.
>>
>
> An explanation or something more refined would be welcome.
>
>
Are you indicating that you need more information on how to reproduce
the problem? I believe the problem is 100% reproducible if you
configure a samba server with a realtek r8111 interface and drag&drop a
file from that server to a windows host on the directly connected lan.
This with both machine's host interfaces reporting 1000mbps full duplex
and a gig-e hub between.
I've just reproduced using a linux client as well, so it would be easy
to compare tcpdumps of the TCP sessions from both ends. Note the
abysmal performance when I transfer *from* the server, but the
performance is fine when I transfer *to* the server:
zpad(root): mount -t cifs -o username=cole //192.168.1.11/u4 /mnt1
Password:
zpad(root): cd /mnt1/test
zpad(root): ls -l t
-rw-r--r-- 1 cole cole 52428800 2007-08-14 23:52 t
zpad(root): date; cp -pr t ~/test/; date
Tue Aug 14 11:57:35 PM
Wed Aug 15 12:01:11 AM
zpad(root): ls -l ~/test/t
-rw-r--r-- 1 cole cole 50M 2007-08-14 23:52 /home/cole/test/t
zpad(root): date; cp -pr ~/test/t tt; date
Wed Aug 15 12:02:11 AM
cp: setting permissions for `tt': Permission denied
Wed Aug 15 12:02:13 AM
zpad(root): ls -l tt
-rwx------ 1 cole cole 52428800 2007-08-14 23:52 tt*
zpad(root):
This test is with the vanilla 2.6.23-rc3 driver with NAPI enabled.
If you're hoping to receive a better fix than the spin wait, I could
probably help with that too but I'd need to see realtek's programming
documentation for this chip.
> [...]
>
>> I can troubleshoot in more detail if that would help get a proper fix
>> developed.
>>
>
> Can you try 2.6.23-rc3 with NAPI enabled and send a complete dmesg +
> /proc/interrupts + ethtool -S output ?
>
Sure, see below:
dmesg:
Linux version 2.6.23-0.104.rc3.fc8
(kojibuilder@xenbuilder2.fedora.redhat.com) (gcc version 4.1.2 20070723
(Red Hat 4.1.2-17)) #1 SMP Mon Aug 13 15:58:43 EDT 2007
Command line: ro root=/dev/sda6 rhgb quiet
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fee0000 (usable)
BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS)
BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data)
BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved)
BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 158) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F6FE0, 0014 (r0 GBT )
ACPI: RSDT 7FEE3040, 003C (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: FACP 7FEE30C0, 0074 (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: DSDT 7FEE3180, 4B36 (r1 GBT GBTUACPI 1000 MSFT 100000C)
ACPI: FACS 7FEE0000, 0040
ACPI: HPET 7FEE7E00, 0038 (r1 GBT GBTUACPI 42302E31 GBTU 98)
ACPI: MCFG 7FEE7E80, 003C (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: APIC 7FEE7D00, 0084 (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: SSDT 7FEE7F00, 015C (r1 PmRef Cpu0Ist 3000 INTL 20040311)
ACPI: SSDT 7FEE8390, 0275 (r1 PmRef CpuPm 3000 INTL 20040311)
No NUMA configuration found
Faking a node at 0000000000000000-000000007fee0000
Entering add_active_range(0, 0, 158) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
Bootmem setup node 0 0000000000000000-000000007fee0000
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0 -> 158
0: 256 -> 524000
On node 0 totalpages: 523902
DMA zone: 96 pages used for memmap
DMA zone: 2488 pages reserved
DMA zone: 1414 pages, LIFO batch:0
DMA32 zone: 12185 pages used for memmap
DMA32 zone: 507719 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 000000000009e000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f0000
swsusp: Registered nosave memory region: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 80000000 (gap: 7ff00000:70100000)
SMP: Allowing 4 CPUs, 2 hotplug CPUs
PERCPU: Allocating 435848 bytes of per cpu data
Built 1 zonelists in Node order. Total pages: 509133
Policy zone: DMA32
Kernel command line: ro root=/dev/sda6 rhgb quiet
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
hpet clockevent registered
TSC calibrated against HPET
time.c: Detected 2800.002 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 16384
... CHAINHASH_SIZE: 8192
memory used by lock dependency info: 1712 kB
per task-struct memory footprint: 2160 bytes
Checking aperture...
Calgary: detecting Calgary via BIOS EBDA area
Calgary: Unable to locate Rio Grande table in EBDA - bailing!
Memory: 2031412k/2096000k available (2473k kernel code, 64196k reserved,
1434k data, 708k init)
SLUB: Genslabs=23, HWalign=64, Order=0-1, MinObjects=4, CPUs=4, Nodes=1
Calibrating delay using timer specific routine.. 5604.00 BogoMIPS
(lpj=2802000)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
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
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU 0/0 -> Node 0
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM2)
lockdep: not fixing up alternatives.
ACPI: Core revision 20070126
Using local APIC timer interrupts.
APIC timer calibration result 21874999
Detected 21.874 MHz APIC timer.
lockdep: not fixing up alternatives.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 5599.77 BogoMIPS
(lpj=2799888)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU1: Thermal monitoring enabled (TM2)
Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz stepping 0b
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
sizeof(vma)=176 bytes
sizeof(page)=96 bytes
sizeof(inode)=1088 bytes
sizeof(dentry)=256 bytes
sizeof(ext3inode)=1488 bytes
sizeof(buffer_head)=104 bytes
sizeof(skbuff)=232 bytes
sizeof(task_struct)=4464 bytes
khelper used greatest stack depth: 6600 bytes left
khelper used greatest stack depth: 6352 bytes left
Time: 23:09:36 Date: 07/14/107
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG at f0000000 - f3ffffff
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S3)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 *14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 9 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
PCI-GART: No AMD northbridge found.
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
hpet0: 4 64-bit timers, 14318180 Hz
ACPI: RTC can wake from S4
Time: tsc clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
pnp: 00:09: ioport range 0x400-0x4bf has been reserved
pnp: 00:0a: iomem range 0xf0000000-0xf3ffffff could not be reserved
pnp: 00:0b: iomem range 0xd5000-0xd7fff has been reserved
pnp: 00:0b: iomem range 0xf0000-0xf7fff could not be reserved
pnp: 00:0b: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0b: iomem range 0xfc000-0xfffff could not be reserved
PCI: Bridge: 0000:00:01.0
IO window: b000-bfff
MEM window: f4000000-f6ffffff
PREFETCH window: e0000000-efffffff
PCI: Bridge: 0000:00:1c.0
IO window: a000-afff
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.4
IO window: c000-cfff
MEM window: f9000000-f90fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.5
IO window: d000-dfff
MEM window: f7000000-f8ffffff
PREFETCH window: 80000000-800fffff
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: f9100000-f91fffff
PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.4 to 64
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.5 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 12, 18874368 bytes)
TCP bind hash table entries: 65536 (order: 10, 4194304 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 3102k freed
khelper used greatest stack depth: 6280 bytes left
audit: initializing netlink socket (disabled)
audit(1187132976.577:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
ksign: Installing public key data
Loading keyring
- Added public key 4C876821E00CB140
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Boot video device is 0000:01:00.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
Allocate Port Service[0000:00:01.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.4 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.4:pcie00]
Allocate Port Service[0000:00:1c.4:pcie02]
Allocate Port Service[0000:00:1c.4:pcie03]
PCI: Setting latency timer of device 0000:00:1c.5 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.5:pcie00]
Allocate Port Service[0000:00:1c.5:pcie02]
Allocate Port Service[0000:00:1c.5:pcie03]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Processor [CPU0] (supports 2 throttling states)
ACPI: SSDT 7FEE8300, 0087 (r1 PmRef Cpu1Ist 3000 INTL 20040311)
ACPI: Processor [CPU1] (supports 2 throttling states)
ACPI Exception (processor_core-0791): AE_NOT_FOUND, Processor Device is
not present [20070126]
ACPI Exception (processor_core-0791): AE_NOT_FOUND, Processor Device is
not present [20070126]
cpuidle: driver acpi_idle failed to attach to cpu 1
cpuidle: driver acpi_idle failed to attach to cpu 0
Generic RTC Driver v1.07
Non-volatile memory driver v1.2
Linux agpgart interface v0.102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 appears to have AUX port disabled, if this is incorrect please
boot with i8042.nopnp
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Magic number: 3:122:201
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing unused kernel memory: 708k freed
Write protecting the kernel read-only data: 1032k
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1a.0 to 64
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e100
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 21 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1a.1 to 64
uhci_hcd 0000:00:1a.1: UHCI Host Controller
uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000e200
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1a.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1a.2 to 64
uhci_hcd 0000:00:1a.2: UHCI Host Controller
uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000e000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000e300
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-1: new full speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000e400
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000e500
usb usb6: configuration #1 chosen from 1 choice
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 2 ports detected
insmod used greatest stack depth: 5272 bytes left
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1a.7 to 64
ehci_hcd 0000:00:1a.7: EHCI Host Controller
ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 7
PCI: cache line size of 32 is not supported by device 0000:00:1a.7
ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf9205000
ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb7: configuration #1 chosen from 1 choice
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 6 ports detected
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 8
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf9204000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb 1-1: USB disconnect, address 2
usb usb8: configuration #1 chosen from 1 choice
hub 8-0:1.0: USB hub found
hub 8-0:1.0: 6 ports detected
insmod used greatest stack depth: 5264 bytes left
SCSI subsystem initialized
libata version 2.21 loaded.
ahci 0000:00:1f.2: version 2.3
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
usb 7-1: new high speed USB device using ehci_hcd and address 2
usb 7-1: configuration #1 chosen from 1 choice
hub 7-1:1.0: USB hub found
hub 7-1:1.0: 2 ports detected
usb 7-1.1: new high speed USB device using ehci_hcd and address 4
ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA
mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci
scsi5 : ahci
ata1: SATA max UDMA/133 cmd 0xffffc2000033a100 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata2: SATA max UDMA/133 cmd 0xffffc2000033a180 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata3: SATA max UDMA/133 cmd 0xffffc2000033a200 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata4: SATA max UDMA/133 cmd 0xffffc2000033a280 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata5: SATA max UDMA/133 cmd 0xffffc2000033a300 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata6: SATA max UDMA/133 cmd 0xffffc2000033a380 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
usb 7-1.1: configuration #1 chosen from 1 choice
hub 7-1.1:1.0: USB hub found
hub 7-1.1:1.0: 4 ports detected
usb 7-1.2: new high speed USB device using ehci_hcd and address 5
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: Maxtor 6H500F0, HA431DD0, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
usb 7-1.2: configuration #1 chosen from 1 choice
usb 1-2: new low speed USB device using uhci_hcd and address 3
ata2: SATA link down (SStatus 0 SControl 300)
usb 1-2: configuration #1 chosen from 1 choice
input: Microsft Microsoft Wireless Optical Desktop® 2.10 as
/class/input/input2
input: USB HID v1.11 Mouse [Microsft Microsoft Wireless Optical Desktop®
2.10] on usb-0000:00:1a.0-2
ata3: SATA link down (SStatus 0 SControl 300)
usb 6-1: new low speed USB device using uhci_hcd and address 2
usb 6-1: configuration #1 chosen from 1 choice
hiddev96: USB HID v1.00 Device [SmartHome SmartHome PowerLinc
Controller] on usb-0000:00:1d.2-1
ata4: SATA link down (SStatus 0 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access ATA Maxtor 6H500F0 HA43 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 >
sd 0:0:0:0: [sda] Attached SCSI disk
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
ahci 0000:03:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
PCI: Setting latency timer of device 0000:03:00.0 to 64
scsi6 : ahci
scsi7 : ahci
ata7: SATA max UDMA/133 cmd 0xffffc2000033c100 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 16
ata8: SATA max UDMA/133 cmd 0xffffc2000033c180 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 16
ata7: SATA link down (SStatus 0 SControl 300)
ata8: SATA link down (SStatus 0 SControl 300)
insmod used greatest stack depth: 3560 bytes left
Initializing USB Mass Storage driver...
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 8:0:0:0: Direct-Access SMSC 223 U HS-CF 3.60 PQ: 0 ANSI: 0
scsi 8:0:0:1: Direct-Access SMSC 223 U HS-MS 3.60 PQ: 0 ANSI: 0
scsi 8:0:0:2: Direct-Access SMSC 223 U HS-SM 3.60 PQ: 0 ANSI: 0
scsi 8:0:0:3: Direct-Access SMSC 223 U HS-SD/MMC 3.60 PQ: 0 ANSI: 0
sd 8:0:0:0: [sdb] Attached SCSI removable disk
sd 8:0:0:1: [sdc] Attached SCSI removable disk
sd 8:0:0:2: [sdd] Attached SCSI removable disk
sd 8:0:0:3: [sde] Attached SCSI removable disk
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: Disabled at runtime.
SELinux: Unregistering netfilter hooks
audit(1187132993.753:2): selinux=0 auid=4294967295
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 8:0:0:0: Attached scsi generic sg1 type 0
sd 8:0:0:1: Attached scsi generic sg2 type 0
sd 8:0:0:2: Attached scsi generic sg3 type 0
sd 8:0:0:3: Attached scsi generic sg4 type 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
Floppy drive(s): fd0 is 1.44M
iTCO_vendor_support: vendor-support=0
FDC 0 is a post-1991 82077
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
iTCO_wdt: failed to reset NO_REBOOT flag, reboot disabled by hardware
iTCO_wdt: No card detected
ACPI: PCI Interrupt 0000:00:1f.3[C] -> GSI 18 (level, low) -> IRQ 18
input: Power Button (FF) as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input4
ACPI: Power Button (CM) [PWRB]
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:04:00.0 to 64
eth0: RTL8168b/8111b at 0xffffc20000340000, 00:1a:4d:47:ec:73, XID
38000000 IRQ 17
ACPI: PCI Interrupt 0000:05:06.0[A] -> GSI 18 (level, low) -> IRQ 18
firewire_ohci: Added fw-ohci device 0000:05:06.0, OHCI version 1.10
ACPI: PCI Interrupt 0000:03:00.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:03:00.1 to 64
scsi9 : pata_jmicron
scsi10 : pata_jmicron
ata9: PATA max UDMA/100 cmd 0x000000000001c000 ctl 0x000000000001c102
bmdma 0x000000000001c400 irq 17
ata10: PATA max UDMA/100 cmd 0x000000000001c200 ctl 0x000000000001c302
bmdma 0x000000000001c408 irq 17
nvidia: module license 'NVIDIA' taints kernel.
firewire_core: created new fw device fw0 (0 config rom retries, S400)
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:01:00.0 to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 100.14.11 Wed Jun 13
16:33:22 PDT 2007
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:1b.0 to 64
hda_codec: Unknown model for ALC882, trying auto-probe from BIOS...
loop: module loaded
lp: driver loaded but no devices found
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
No dock devices found.
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised:
dm-devel@redhat.com
device-mapper: multipath: version 1.0.5 loaded
EXT3 FS on sda6, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda10, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
fuse init (API version 7.8)
Adding 2000052k swap on /dev/sda5. Priority:-1 extents:1 across:2000052k
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
r8169: eth0: link up
r8169: eth0: link up
Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
it87: Found IT8718F chip at 0x290, revision 4
it87: in3 is VCC (+5V)
coretemp coretemp.0: Using undocumented features, absolute temperature
might be wrong!
coretemp coretemp.1: Using undocumented features, absolute temperature
might be wrong!
eth0: no IPv6 routers present
Bridge firewalling registered
=============================================================================
BUG kmalloc-96 (Tainted: P ): Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff810077d36d50-0xffff810077d36d57. First byte 0x0 instead of 0x6b
INFO: Allocated in __nf_ct_ext_add+0x50/0x1bc [nf_conntrack] age=8806
cpu=0 pid=2908
INFO: Freed in __nf_ct_ext_add+0x14b/0x1bc [nf_conntrack] age=4805 cpu=0
pid=2908
INFO: Slab 0xffff8100039f0440 used=18 fp=0xffff810077d36d20
flags=0x700800000000c3
INFO: Object 0xffff810077d36d20 @offset=3360 fp=0xffff810077d36e70
Bytes b4 0xffff810077d36d10: b6 1a fc ff 00 00 00 00 5a 5a 5a 5a 5a 5a
5a 5a ¶.üÿ....ZZZZZZZZ
Object 0xffff810077d36d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d50: 00 00 00 00 00 00 00 00 6b 6b 6b 6b 6b 6b
6b 6b ........kkkkkkkk
Object 0xffff810077d36d60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b a5 kkkkkkkkkkkkkkk¥
Redzone 0xffff810077d36d80: bb bb bb bb bb bb bb
bb »»»»»»»»
Padding 0xffff810077d36dc0: 5a 5a 5a 5a 5a 5a 5a
5a ZZZZZZZZ
Call Trace:
[<ffffffff810978c4>] check_bytes_and_report+0xa3/0xc9
[<ffffffff81097b88>] check_object+0xc5/0x23a
[<ffffffff81098f62>] __slab_alloc+0x41e/0x43b
[<ffffffff88036be0>] :ext3:ext3_htree_store_dirent+0x2a/0xeb
[<ffffffff88036be0>] :ext3:ext3_htree_store_dirent+0x2a/0xeb
[<ffffffff8109a3a4>] __kmalloc+0x61/0xb5
[<ffffffff88036be0>] :ext3:ext3_htree_store_dirent+0x2a/0xeb
[<ffffffff8803e266>] :ext3:htree_dirblock_to_tree+0x103/0x13e
[<ffffffff8803e31d>] :ext3:ext3_htree_fill_tree+0x7c/0x1cb
[<ffffffff81098ec3>] __slab_alloc+0x37f/0x43b
[<ffffffff88036d2d>] :ext3:ext3_readdir+0x8c/0x513
[<ffffffff88036d2d>] :ext3:ext3_readdir+0x8c/0x513
[<ffffffff810aadc0>] filldir+0x0/0xb7
[<ffffffff88036e44>] :ext3:ext3_readdir+0x1a3/0x513
[<ffffffff8109f9f1>] file_move+0x1d/0x49
[<ffffffff810aadc0>] filldir+0x0/0xb7
[<ffffffff81262bb6>] __mutex_lock_slowpath+0x299/0x2a6
[<ffffffff810aadc0>] filldir+0x0/0xb7
[<ffffffff810aaeee>] vfs_readdir+0x77/0xa9
[<ffffffff810ab140>] sys_getdents+0x75/0xbd
[<ffffffff8100bcbe>] system_call+0x7e/0x83
FIX kmalloc-96: Restoring 0xffff810077d36d50-0xffff810077d36d57=0x6b
FIX kmalloc-96: Marking all objects used
virbr0: no IPv6 routers present
interrupts:
CPU0 CPU1
0: 112 1 IO-APIC-edge timer
1: 3310 122 IO-APIC-edge i8042
6: 5 1 IO-APIC-edge floppy
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
16: 14972 17489 IO-APIC-fasteoi uhci_hcd:usb1, ahci, nvidia
17: 12 116 IO-APIC-fasteoi libata, eth0
18: 15068 438 IO-APIC-fasteoi uhci_hcd:usb3,
uhci_hcd:usb6, ehci_hcd:usb7, firewire_ohci
19: 0 0 IO-APIC-fasteoi uhci_hcd:usb5
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 100 100 IO-APIC-fasteoi HDA Intel
23: 1 1 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb8
2299: 7922 3455 PCI-MSI-edge ahci
NMI: 0 0
LOC: 57043 57922
ERR: 0
ethtool (shortly after boot):
NIC statistics:
tx_packets: 137
rx_packets: 38
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 878
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 22
broadcast: 10
multicast: 16
tx_aborted: 0
tx_underrun: 0
(and after some tests):
NIC statistics:
tx_packets: 1273862
rx_packets: 605126
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 878
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 604360
broadcast: 643
multicast: 766
tx_aborted: 0
tx_underrun: 0
^ permalink raw reply
* Re: [2.6 patch] remove Documentation/networking/net-modules.txt
From: Geert Uytterhoeven @ 2007-08-15 7:58 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, jgarzik, netdev, linux-kernel
In-Reply-To: <20070814212604.GW18945@stusta.de>
On Tue, 14 Aug 2007, Adrian Bunk wrote:
> According to git, the only one who touched this file during the last
> 5 years was me when removing drivers...
>
> modinfo offers less ancient information.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
For the m68k net drivers:
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
From: Stefan Richter @ 2007-08-15 8:10 UTC (permalink / raw)
To: Alan Cox; +Cc: Joe Perches, torvalds, netdev, linux-kernel, akpm
In-Reply-To: <20070813185148.16308985@the-village.bc.nu>
Alan Cox wrote:
>> > Actually I think the entire thing is a
>> > bad idea but thats another matter.
> Working off the git tree as it shows who actually is making
> changes/updating stuff recently and why which is a major clue when
> tracing bugs
Adrian Bunk wrote in http://lkml.org/lkml/2007/6/30/107 :
| I don't see how git could tell you to Cc net patches to
| netdev@vger.kernel.org.
Ditto with problem reports.
For example, Cc'ing linux1394-devel on FireWire topics is a lot more
important than Cc'ing me.
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Heiko Carstens @ 2007-08-15 8:18 UTC (permalink / raw)
To: Herbert Xu
Cc: Chris Snook, satyam, clameter, linux-kernel, linux-arch, torvalds,
netdev, akpm, ak, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <E1ILCgh-00052A-00@gondolin.me.apana.org.au>
On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
> Chris Snook <csnook@redhat.com> wrote:
> >
> > Because atomic operations are generally used for synchronization, which requires
> > volatile behavior. Most such codepaths currently use an inefficient barrier().
> > Some forget to and we get bugs, because people assume that atomic_read()
> > actually reads something, and atomic_write() actually writes something. Worse,
> > these are architecture-specific, even compiler version-specific bugs that are
> > often difficult to track down.
>
> I'm yet to see a single example from the current tree where
> this patch series is the correct solution. So far the only
> example has been a buggy piece of code which has since been
> fixed with a cpu_relax.
Btw.: we still have
include/asm-i386/mach-es7000/mach_wakecpu.h: while (!atomic_read(deassert));
include/asm-i386/mach-default/mach_wakecpu.h: while (!atomic_read(deassert));
Looks like they need to be fixed as well.
^ permalink raw reply
* Re: linux kernel 2.6.18-20 bug: rcu_read_unlock in __sock_create
From: Herbert Xu @ 2007-08-15 8:33 UTC (permalink / raw)
To: oleg 123, davem, netdev; +Cc: linux-kernel
In-Reply-To: <af57f1ac0708141130v729fa636k3150673809ec20a8@mail.gmail.com>
oleg 123 <123.oleg@gmail.com> wrote:
>
> There is a bug in __sock_create() function (net/socket.c).
> If an error occur in LSM hook security_socket_post_create, then unneeded
> rcu_read_unlock() is made in __sock_create.
Well spotted! Please cc netdev@vger.kernel.org for networking
issues.
[NET]: Fix unbalanced rcu_read_unlock in __sock_create
The recent RCU work created an unbalanced rcu_read_unlock
in __sock_create. This patch fixes that. Reported by
oleg 123.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/socket.c b/net/socket.c
index ec07703..7d44453 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1168,7 +1168,7 @@ static int __sock_create(int family, int type, int protocol,
module_put(pf->owner);
err = security_socket_post_create(sock, family, type, protocol, kern);
if (err)
- goto out_release;
+ goto out_sock_release;
*res = sock;
return 0;
^ permalink raw reply related
* Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
From: Alan Cox @ 2007-08-15 8:33 UTC (permalink / raw)
To: Stefan Richter; +Cc: Joe Perches, torvalds, netdev, linux-kernel, akpm
In-Reply-To: <46C2B4FE.3080703@s5r6.in-berlin.de>
On Wed, 15 Aug 2007 10:10:38 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> Alan Cox wrote:
> >> > Actually I think the entire thing is a
> >> > bad idea but thats another matter.
>
> > Working off the git tree as it shows who actually is making
> > changes/updating stuff recently and why which is a major clue when
> > tracing bugs
>
> Adrian Bunk wrote in http://lkml.org/lkml/2007/6/30/107 :
> | I don't see how git could tell you to Cc net patches to
> | netdev@vger.kernel.org.
>
> Ditto with problem reports.
>
> For example, Cc'ing linux1394-devel on FireWire topics is a lot more
> important than Cc'ing me.
Tools question. And even if you need to keep a simple set of mappings by
hand for mailing list/files thats a fairly small set of patterns
^ permalink raw reply
* [PATCH] nl80211: remove VLAN type
From: Johannes Berg @ 2007-08-15 9:18 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, John W. Linville, linux-wireless
There is no point in trying to handle source MAC address based VLANs in
the wireless stack, something like "smacvlan" modeled after macvlan
should be sufficient.
Signed-off-by: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
---
We could just not keep the hole as well since people can't really be
using that header yet, but the version we have in previous kernels could
still be shipped somewhere so I think it should be kept compatible.
include/linux/nl80211.h | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
--- wireless-dev.orig/include/linux/nl80211.h 2007-08-15 00:43:06.290200043 +0200
+++ wireless-dev/include/linux/nl80211.h 2007-08-15 00:45:51.860200043 +0200
@@ -207,7 +207,6 @@ enum nl80211_attrs {
* @NL80211_IFTYPE_ADHOC: independent BSS member
* @NL80211_IFTYPE_STATION: managed BSS member
* @NL80211_IFTYPE_AP: access point
- * @NL80211_IFTYPE_AP_VLAN: VLAN interface for access points
* @NL80211_IFTYPE_WDS: wireless distribution interface
* @NL80211_IFTYPE_MONITOR: monitor interface receiving all frames
* @__NL80211_IFTYPE_AFTER_LAST: internal use
@@ -217,13 +216,17 @@ enum nl80211_attrs {
*
*/
enum nl80211_iftype {
- NL80211_IFTYPE_UNSPECIFIED,
- NL80211_IFTYPE_ADHOC,
- NL80211_IFTYPE_STATION,
- NL80211_IFTYPE_AP,
- NL80211_IFTYPE_AP_VLAN,
- NL80211_IFTYPE_WDS,
- NL80211_IFTYPE_MONITOR,
+ NL80211_IFTYPE_UNSPECIFIED = 0,
+ NL80211_IFTYPE_ADHOC = 1,
+ NL80211_IFTYPE_STATION = 2,
+ NL80211_IFTYPE_AP = 3,
+ /*
+ * there was AP_VLAN here but it was never used
+ * keep the number unallocated for the benefit
+ * of those people using old headers
+ */
+ NL80211_IFTYPE_WDS = 5,
+ NL80211_IFTYPE_MONITOR = 6,
/* keep last */
__NL80211_IFTYPE_AFTER_LAST
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Stefan Richter @ 2007-08-15 10:35 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, Chris Snook, Linux Kernel Mailing List,
linux-arch, torvalds, netdev, Andrew Morton, ak, heiko.carstens,
davem, schwidefsky, wensong, horms, wjiang, cfriesen, zlynx,
rpjday, jesper.juhl, segher, Herbert Xu, Paul E. McKenney
In-Reply-To: <alpine.LFD.0.999.0708150417240.6482@enigma.security.iitk.ac.in>
Satyam Sharma wrote:
> [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> the first place? Atomic ops guarantee atomicity, which has nothing
> to do with "volatility" -- users that expect "volatility" from
> atomic ops are the ones who must be fixed instead, IMHO. ]
LDD3 says on page 125: "The following operations are defined for the
type [atomic_t] and are guaranteed to be atomic with respect to all
processors of an SMP computer."
Doesn't "atomic WRT all processors" require volatility?
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply
* [METH] Don't use GFP_DMA for zone allocation.
From: Ralf Baechle @ 2007-08-15 11:53 UTC (permalink / raw)
To: Andrew Morton, Jeff Garzik, netdev, linux-mips
IP32 doesn't even have a ZONE_DMA so no point in using GFP_DMA in any
IP32-specific device driver.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff --git a/drivers/net/meth.c b/drivers/net/meth.c
index 92b403b..32bed6b 100644
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@@ -405,7 +405,7 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
priv->stats.rx_length_errors++;
skb = priv->rx_skbs[priv->rx_write];
} else {
- skb = alloc_skb(METH_RX_BUFF_SIZE, GFP_ATOMIC | GFP_DMA);
+ skb = alloc_skb(METH_RX_BUFF_SIZE, GFP_ATOMIC);
if (!skb) {
/* Ouch! No memory! Drop packet on the floor */
DPRINTK("No mem: dropping packet\n");
^ permalink raw reply related
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Herbert Xu @ 2007-08-15 12:04 UTC (permalink / raw)
To: Stefan Richter
Cc: Satyam Sharma, Christoph Lameter, Chris Snook,
Linux Kernel Mailing List, linux-arch, torvalds, netdev,
Andrew Morton, ak, heiko.carstens, davem, schwidefsky, wensong,
horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl, segher,
Paul E. McKenney
In-Reply-To: <46C2D6F3.3070707@s5r6.in-berlin.de>
On Wed, Aug 15, 2007 at 12:35:31PM +0200, Stefan Richter wrote:
>
> LDD3 says on page 125: "The following operations are defined for the
> type [atomic_t] and are guaranteed to be atomic with respect to all
> processors of an SMP computer."
>
> Doesn't "atomic WRT all processors" require volatility?
Not at all. We also require this to be atomic without any
hint of volatility.
extern int foo;
foo = 4;
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Satyam Sharma @ 2007-08-15 12:31 UTC (permalink / raw)
To: Stefan Richter
Cc: Christoph Lameter, Chris Snook, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, netdev, Andrew Morton, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher, Herbert Xu,
Paul E. McKenney
In-Reply-To: <46C2D6F3.3070707@s5r6.in-berlin.de>
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> > the first place? Atomic ops guarantee atomicity, which has nothing
> > to do with "volatility" -- users that expect "volatility" from
> > atomic ops are the ones who must be fixed instead, IMHO. ]
>
> LDD3 says on page 125: "The following operations are defined for the
> type [atomic_t] and are guaranteed to be atomic with respect to all
> processors of an SMP computer."
>
> Doesn't "atomic WRT all processors" require volatility?
No, it definitely doesn't. Why should it?
"Atomic w.r.t. all processors" is just your normal, simple "atomicity"
for SMP systems (ensure that that object is modified / set / replaced
in main memory atomically) and has nothing to do with "volatile"
behaviour.
"Volatile behaviour" itself isn't consistently defined (at least
definitely not consistently implemented in various gcc versions across
platforms), but it is /expected/ to mean something like: "ensure that
every such access actually goes all the way to memory, and is not
re-ordered w.r.t. to other accesses, as far as the compiler can take
care of these". The last "as far as compiler can take care" disclaimer
comes about due to CPUs doing their own re-ordering nowadays.
For example (say on i386):
(A)
$ cat tp1.c
int a;
void func(void)
{
a = 10;
a = 20;
}
$ gcc -Os -S tp1.c
$ cat tp1.s
...
movl $20, a
...
(B)
$ cat tp2.c
volatile int a;
void func(void)
{
a = 10;
a = 20;
}
$ gcc -Os -S tp2.c
$ cat tp2.s
...
movl $10, a
movl $20, a
...
(C)
$ cat tp3.c
int a;
void func(void)
{
*(volatile int *)&a = 10;
*(volatile int *)&a = 20;
}
$ gcc -Os -S tp3.c
$ cat tp3.s
...
movl $10, a
movl $20, a
...
In (A) the compiler optimized "a = 10;" away, but the actual store
of the final value "20" to "a" was still "atomic". (B) and (C) also
exhibit "volatile" behaviour apart from the "atomicity".
But as others replied, it seems some callers out there depend upon
atomic ops exhibiting "volatile" behaviour as well, so that answers
my initial question, actually. I haven't looked at the code Paul
pointed me at, but I wonder if that "forget(x)" macro would help
those cases. I'd wish to avoid the "volatile" primitive, personally.
Satyam
^ permalink raw reply
* set_multicast_list vs. set_rx_mode
From: Johannes Berg @ 2007-08-15 12:33 UTC (permalink / raw)
To: netdev; +Cc: Patrick McHardy
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Hey,
Is it intentional that in the case where set_rx_mode is assigned, you
still need to assign set_multicast_list even if it won't ever be called
as a flag for SIOCADDMULTI?
I was thinking of converting the wireless code to use set_rx_mode and
assign set_multicast_list only if the underlying hardware supports
multicast filtering, and it seems that is well-supported, but it does
seem a bit weird that set_multicast_list degrades to a flag.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: set_multicast_list vs. set_rx_mode
From: Patrick McHardy @ 2007-08-15 12:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1187181208.3998.44.camel@johannes.berg>
Johannes Berg wrote:
> Is it intentional that in the case where set_rx_mode is assigned, you
> still need to assign set_multicast_list even if it won't ever be called
> as a flag for SIOCADDMULTI?
>
> I was thinking of converting the wireless code to use set_rx_mode and
> assign set_multicast_list only if the underlying hardware supports
> multicast filtering, and it seems that is well-supported, but it does
> seem a bit weird that set_multicast_list degrades to a flag.
Indeed, I missed that. It should check for !dev->set_multicast_list &&
!dev->set_rx_mode before returning -EINVAL.
^ permalink raw reply
* Re: set_multicast_list vs. set_rx_mode
From: Johannes Berg @ 2007-08-15 12:44 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <46C2F2B5.60803@trash.net>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On Wed, 2007-08-15 at 14:33 +0200, Patrick McHardy wrote:
> Johannes Berg wrote:
> > Is it intentional that in the case where set_rx_mode is assigned, you
> > still need to assign set_multicast_list even if it won't ever be called
> > as a flag for SIOCADDMULTI?
> >
> > I was thinking of converting the wireless code to use set_rx_mode and
> > assign set_multicast_list only if the underlying hardware supports
> > multicast filtering, and it seems that is well-supported, but it does
> > seem a bit weird that set_multicast_list degrades to a flag.
>
>
> Indeed, I missed that. It should check for !dev->set_multicast_list &&
> !dev->set_rx_mode before returning -EINVAL.
Ok. Want me to send a patch?
And then the expected behaviour is that set_rx_mode will set
IFF_ALLMULTI if it can't honour the list, right?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [RFC: -mm patch] improve the SSB dependencies
From: Michael Buesch @ 2007-08-15 12:47 UTC (permalink / raw)
To: John W. Linville
Cc: Adrian Bunk, Johannes Berg, Andrew Morton, Linux Netdev List
In-Reply-To: <20070815004035.GL7198@tuxdriver.com>
On Wednesday 15 August 2007 02:40:35 John W. Linville wrote:
> On Mon, Aug 13, 2007 at 12:44:02AM +0200, Adrian Bunk wrote:
> > On Sun, Aug 12, 2007 at 02:00:26PM +0200, Michael Buesch wrote:
> > > Ok, I'll give it a try, with small modifications.
> >
> > Thanks.
> >
> > > On Sunday 12 August 2007, Adrian Bunk wrote:
> > > > Additional changes in this patch:
> > > > - small help text changes
> > > > - B44_PCI is no longer usr visible (automatically enabled when possible)
> > >
> > > I think we want that to be selectable, as it's not needed
> > > on some embedded devices. And we need to save memory there.
> > >...
> >
> > Makes sense, but then:
> >
> > config B44_PCI
> > bool "Broadcom 440x PCI device support" if EMBEDDED
> > ...
> > default y
> > ...
> >
> > I don't care about how many options we present if CONFIG_EMBEDDED=y, but
> > for the normal CONFIG_EMBEDDED=n case we should not bother the user with
> > this option.
>
> Was all this resolved? Was there another patch? If so, I missed it...
I am going to send one, soon.
--
Greetings Michael.
^ permalink raw reply
* Re: set_multicast_list vs. set_rx_mode
From: Johannes Berg @ 2007-08-15 12:55 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <46C2F2B5.60803@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Wed, 2007-08-15 at 14:33 +0200, Patrick McHardy wrote:
> Johannes Berg wrote:
> > Is it intentional that in the case where set_rx_mode is assigned, you
> > still need to assign set_multicast_list even if it won't ever be called
> > as a flag for SIOCADDMULTI?
> >
> > I was thinking of converting the wireless code to use set_rx_mode and
> > assign set_multicast_list only if the underlying hardware supports
> > multicast filtering, and it seems that is well-supported, but it does
> > seem a bit weird that set_multicast_list degrades to a flag.
>
>
> Indeed, I missed that. It should check for !dev->set_multicast_list &&
> !dev->set_rx_mode before returning -EINVAL.
Hmm. We don't really support multiple unicast addresses so I should
probably not use set_rx_mode. What is the meaning of
dev->change_rx_flags? It seems to be called with IFF_ALLMULTI but if it
is assigned and set_multicast_list is not then you also cannot add
multicast addresses via SIOCADDMULTI.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Stefan Richter @ 2007-08-15 13:08 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, Chris Snook, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, netdev, Andrew Morton, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher, Herbert Xu,
Paul E. McKenney
In-Reply-To: <alpine.LFD.0.999.0708151713080.16414@enigma.security.iitk.ac.in>
Satyam Sharma wrote:
> On Wed, 15 Aug 2007, Stefan Richter wrote:
>> Doesn't "atomic WRT all processors" require volatility?
>
> No, it definitely doesn't. Why should it?
>
> "Atomic w.r.t. all processors" is just your normal, simple "atomicity"
> for SMP systems (ensure that that object is modified / set / replaced
> in main memory atomically) and has nothing to do with "volatile"
> behaviour.
>
> "Volatile behaviour" itself isn't consistently defined (at least
> definitely not consistently implemented in various gcc versions across
> platforms), but it is /expected/ to mean something like: "ensure that
> every such access actually goes all the way to memory, and is not
> re-ordered w.r.t. to other accesses, as far as the compiler can take
> care of these". The last "as far as compiler can take care" disclaimer
> comes about due to CPUs doing their own re-ordering nowadays.
>
> For example (say on i386):
[...]
> In (A) the compiler optimized "a = 10;" away, but the actual store
> of the final value "20" to "a" was still "atomic". (B) and (C) also
> exhibit "volatile" behaviour apart from the "atomicity".
>
> But as others replied, it seems some callers out there depend upon
> atomic ops exhibiting "volatile" behaviour as well, so that answers
> my initial question, actually. I haven't looked at the code Paul
> pointed me at, but I wonder if that "forget(x)" macro would help
> those cases. I'd wish to avoid the "volatile" primitive, personally.
So, looking at load instead of store, understand I correctly that in
your opinion
int b;
b = atomic_read(&a);
if (b)
do_something_time_consuming();
b = atomic_read(&a);
if (b)
do_something_more();
should be changed to explicitly forget(&a) after
do_something_time_consuming?
If so, how about the following:
static inline void A(atomic_t *a)
{
int b = atomic_read(a);
if (b)
do_something_time_consuming();
}
static inline void B(atomic_t *a)
{
int b = atomic_read(a);
if (b)
do_something_more();
}
static void C(atomic_t *a)
{
A(a);
B(b);
}
Would this need forget(a) after A(a)?
(Is the latter actually answered in C99 or is it compiler-dependent?)
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Stefan Richter @ 2007-08-15 13:11 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, Chris Snook, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, netdev, Andrew Morton, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher, Herbert Xu,
Paul E. McKenney
In-Reply-To: <46C2FADB.7020407@s5r6.in-berlin.de>
I wrote:
> static inline void A(atomic_t *a)
> {
> int b = atomic_read(a);
> if (b)
> do_something_time_consuming();
> }
>
> static inline void B(atomic_t *a)
> {
> int b = atomic_read(a);
> if (b)
> do_something_more();
> }
>
> static void C(atomic_t *a)
> {
> A(a);
> B(b);
/* ^ typo */
B(a);
> }
>
> Would this need forget(a) after A(a)?
>
> (Is the latter actually answered in C99 or is it compiler-dependent?)
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: Nick Piggin @ 2007-08-15 13:30 UTC (permalink / raw)
To: paulmck
Cc: Herbert Xu, csnook, dhowells, linux-kernel, linux-arch, torvalds,
netdev, akpm, ak, heiko.carstens, davem, schwidefsky, wensong,
horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl,
Arnd Bergmann
In-Reply-To: <20070814170128.GA8243@linux.vnet.ibm.com>
Paul E. McKenney wrote:
> On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
>>Maybe it is the safe way to go, but it does obscure cases where there
>>is a real need for barriers.
>
>
> I prefer burying barriers into other primitives.
When they should naturally be there, eg. locking or the RCU primitives,
I agree.
I don't like having them scattered in various "just in case" places,
because it makes both the users and the APIs hard to understand and
change.
Especially since several big architectures don't have volatile in their
atomic_get and _set, I think it would be a step backwards to add them in
as a "just in case" thin now (unless there is a better reason).
>>Many atomic operations are allowed to be reordered between CPUs, so
>>I don't have a good idea for the rationale to order them within the
>>CPU (also loads and stores to long and ptr types are not ordered like
>>this, although we do consider those to be atomic operations too).
>>
>>barrier() in a way is like enforcing sequential memory ordering
>>between process and interrupt context, wheras volatile is just
>>enforcing coherency of a single memory location (and as such is
>>cheaper).
>
>
> barrier() is useful, but it has the very painful side-effect of forcing
> the compiler to dump temporaries. So we do need something that is
> not quite so global in effect.
Yep.
>>What do you think of this crazy idea?
>>
>>/* Enforce a compiler barrier for only operations to location X.
>> * Call multiple times to provide an ordering between multiple
>> * memory locations. Other memory operations can be assumed by
>> * the compiler to remain unchanged and may be reordered
>> */
>>#define order(x) asm volatile("" : "+m" (x))
>
>
> There was something very similar discussed earlier in this thread,
> with quite a bit of debate as to exactly what the "m" flag should
> look like. I suggested something similar named ACCESS_ONCE in the
> context of RCU (http://lkml.org/lkml/2007/7/11/664):
Oh, I missed that earlier debate. Will go have a look.
> #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
>
> The nice thing about this is that it works for both loads and stores.
> Not clear that order() above does this -- I get compiler errors when
> I try something like "b = order(a)" or "order(a) = 1" using gcc 4.1.2.
As Arnd ponted out, order() is not supposed to be an lvalue, but a
statement like the rest of our memory ordering API.
As to your followup question of why to use it over ACCESS_ONCE. I
guess, aside from consistency with the rest of the barrier APIs, you
can use it in other primitives when you don't actually know what the
caller is going to do or if it even will make an access. You could
also use it between calls to _other_ primitives, etc... it just
seems more flexible to me, but I haven't actually used such a thing
in real code...
ACCESS_ONCE doesn't seem as descriptive. What it results in is the
memory location being loaded or stored (presumably once exactly),
but I think the more general underlying idea is a barrier point.
--
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Satyam Sharma @ 2007-08-15 13:47 UTC (permalink / raw)
To: Stefan Richter
Cc: Christoph Lameter, Chris Snook, Linux Kernel Mailing List,
linux-arch, Linus Torvalds, netdev, Andrew Morton, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher, Herbert Xu,
Paul E. McKenney
In-Reply-To: <46C2FADB.7020407@s5r6.in-berlin.de>
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > On Wed, 15 Aug 2007, Stefan Richter wrote:
> >> Doesn't "atomic WRT all processors" require volatility?
> >
> > No, it definitely doesn't. Why should it?
> >
> > "Atomic w.r.t. all processors" is just your normal, simple "atomicity"
> > for SMP systems (ensure that that object is modified / set / replaced
> > in main memory atomically) and has nothing to do with "volatile"
> > behaviour.
> >
> > "Volatile behaviour" itself isn't consistently defined (at least
> > definitely not consistently implemented in various gcc versions across
> > platforms), but it is /expected/ to mean something like: "ensure that
> > every such access actually goes all the way to memory, and is not
> > re-ordered w.r.t. to other accesses, as far as the compiler can take
> > care of these". The last "as far as compiler can take care" disclaimer
> > comes about due to CPUs doing their own re-ordering nowadays.
> >
> > For example (say on i386):
>
> [...]
>
> > In (A) the compiler optimized "a = 10;" away, but the actual store
> > of the final value "20" to "a" was still "atomic". (B) and (C) also
> > exhibit "volatile" behaviour apart from the "atomicity".
> >
> > But as others replied, it seems some callers out there depend upon
> > atomic ops exhibiting "volatile" behaviour as well, so that answers
> > my initial question, actually. I haven't looked at the code Paul
> > pointed me at, but I wonder if that "forget(x)" macro would help
> > those cases. I'd wish to avoid the "volatile" primitive, personally.
>
> So, looking at load instead of store, understand I correctly that in
> your opinion
>
> int b;
>
> b = atomic_read(&a);
> if (b)
> do_something_time_consuming();
>
> b = atomic_read(&a);
> if (b)
> do_something_more();
>
> should be changed to explicitly forget(&a) after
> do_something_time_consuming?
No, I'd actually prefer something like what Christoph Lameter suggested,
i.e. users (such as above) who want "volatile"-like behaviour from atomic
ops can use alternative functions. How about something like:
#define atomic_read_volatile(v) \
({ \
forget(&(v)->counter); \
((v)->counter); \
})
Or possibly, implement these "volatile" atomic ops variants in inline asm
like the patch that Sebastian Siewior has submitted on another thread just
a while back.
Of course, if we find there are more callers in the kernel who want the
volatility behaviour than those who don't care, we can re-define the
existing ops to such variants, and re-name the existing definitions to
somethine else, say "atomic_read_nonvolatile" for all I care.
^ permalink raw reply
* [PATCH] b44: Fix MII interface of the B44 driver
From: Michael Buesch @ 2007-08-15 13:41 UTC (permalink / raw)
To: John Linville; +Cc: Aurelien Jarno, netdev
From: Aurelien Jarno <aurelien@aurel32.net>
The conversion of the B44 driver to SSB bus added the functions
__b44_{read,write}phy functions that have an argument phy_id. This gives
a way to fix the b44_mii_{read,write} functions used for MII interfaces.
The patch below does that. It allows B44 devices with integrated switch
to be configured from userland.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 36724fb..e6883f4 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -300,16 +300,11 @@ static inline int b44_writephy(struct b44 *bp, int reg, u32 val)
}
/* miilib interface */
-/* FIXME FIXME: phy_id is ignored, bp->phy_addr use is unconditional
- * due to code existing before miilib use was added to this driver.
- * Someone should remove this artificial driver limitation in
- * b44_{read,write}phy. bp->phy_addr itself is fine (and needed).
- */
static int b44_mii_read(struct net_device *dev, int phy_id, int location)
{
u32 val;
struct b44 *bp = netdev_priv(dev);
- int rc = b44_readphy(bp, location, &val);
+ int rc = __b44_readphy(bp, phy_id, location, &val);
if (rc)
return 0xffffffff;
return val;
@@ -319,7 +314,7 @@ static void b44_mii_write(struct net_device *dev, int phy_id, int location,
int val)
{
struct b44 *bp = netdev_priv(dev);
- b44_writephy(bp, location, val);
+ __b44_writephy(bp, phy_id, location, val);
}
static int b44_phy_reset(struct b44 *bp)
--
Greetings Michael.
^ permalink raw reply related
* b44: Fix Kconfig dependencies by using select
From: Michael Buesch @ 2007-08-15 13:46 UTC (permalink / raw)
To: John Linville; +Cc: netdev
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-dev-new/drivers/net/Kconfig
===================================================================
--- wireless-dev-new.orig/drivers/net/Kconfig 2007-08-11 00:49:28.000000000 +0200
+++ wireless-dev-new/drivers/net/Kconfig 2007-08-15 15:29:36.000000000 +0200
@@ -1454,7 +1454,7 @@ config APRICOT
config B44
tristate "Broadcom 440x/47xx ethernet support"
- depends on HAS_IOMEM
+ depends on SSB_POSSIBLE
select SSB
select MII
help
@@ -1462,27 +1462,28 @@ config B44
or M and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- If you have a Broadcom 440x PCI device (and if you don't
- know, you _do_ have one) you must also select the options
- "EISA, VLB, PCI and on board controllers" above and
- "Broadcom 440x PCI device support" below.
-
To compile this driver as a module, choose M here and read
<file:Documentation/networking/net-modules.txt>. The module will be
called b44.
-config B44_PCI
- bool "Broadcom 440x PCI device support"
- depends on B44 && NET_PCI
+# Auto-select SSB PCI-HOST support, if possible
+config B44_PCI_AUTOSELECT
+ bool
+ depends on B44 && SSB_PCIHOST_POSSIBLE
select SSB_PCIHOST
+ default y
+
+# Auto-select SSB PCICORE driver, if possible
+config B44_PCICORE_AUTOSELECT
+ bool
+ depends on B44 && SSB_DRIVER_PCICORE_POSSIBLE
select SSB_DRIVER_PCICORE
default y
- help
- Support for Broadcom 440x PCI devices.
- Say Y, unless you know what you are doing.
- If you say N here I will _not_ listen to your
- bugreports!
+config B44_PCI
+ bool
+ depends on B44_PCI_AUTOSELECT && B44_PCICORE_AUTOSELECT
+ default y
config FORCEDETH
tristate "nForce Ethernet support"
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Stefan Richter @ 2007-08-15 13:53 UTC (permalink / raw)
To: Heiko Carstens
Cc: Herbert Xu, Chris Snook, satyam, clameter, linux-kernel,
linux-arch, torvalds, netdev, akpm, ak, davem, schwidefsky,
wensong, horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl,
segher
In-Reply-To: <20070815081841.GA16551@osiris.boeblingen.de.ibm.com>
On 8/15/2007 10:18 AM, Heiko Carstens wrote:
> On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
>> Chris Snook <csnook@redhat.com> wrote:
>> >
>> > Because atomic operations are generally used for synchronization, which requires
>> > volatile behavior. Most such codepaths currently use an inefficient barrier().
>> > Some forget to and we get bugs, because people assume that atomic_read()
>> > actually reads something, and atomic_write() actually writes something. Worse,
>> > these are architecture-specific, even compiler version-specific bugs that are
>> > often difficult to track down.
>>
>> I'm yet to see a single example from the current tree where
>> this patch series is the correct solution. So far the only
>> example has been a buggy piece of code which has since been
>> fixed with a cpu_relax.
>
> Btw.: we still have
>
> include/asm-i386/mach-es7000/mach_wakecpu.h: while (!atomic_read(deassert));
> include/asm-i386/mach-default/mach_wakecpu.h: while (!atomic_read(deassert));
>
> Looks like they need to be fixed as well.
I don't know if this here is affected:
/* drivers/ieee1394/ieee1394_core.h */
static inline unsigned int get_hpsb_generation(struct hpsb_host *host)
{
return atomic_read(&host->generation);
}
/* drivers/ieee1394/nodemgr.c */
static int nodemgr_host_thread(void *__hi)
{
[...]
for (;;) {
[... sleep until bus reset event ...]
/* Pause for 1/4 second in 1/16 second intervals,
* to make sure things settle down. */
g = get_hpsb_generation(host);
for (i = 0; i < 4 ; i++) {
if (msleep_interruptible(63) ||
kthread_should_stop())
goto exit;
/* Now get the generation in which the node ID's we collect
* are valid. During the bus scan we will use this generation
* for the read transactions, so that if another reset occurs
* during the scan the transactions will fail instead of
* returning bogus data. */
generation = get_hpsb_generation(host);
/* If we get a reset before we are done waiting, then
* start the waiting over again */
if (generation != g)
g = generation, i = 0;
}
[... scan bus, using generation ...]
}
exit:
[...]
}
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Satyam Sharma @ 2007-08-15 14:35 UTC (permalink / raw)
To: Stefan Richter
Cc: Heiko Carstens, Herbert Xu, Chris Snook, clameter,
Linux Kernel Mailing List, linux-arch, Linus Torvalds, netdev,
Andrew Morton, ak, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <46C30540.2070603@s5r6.in-berlin.de>
Hi Stefan,
On Wed, 15 Aug 2007, Stefan Richter wrote:
> On 8/15/2007 10:18 AM, Heiko Carstens wrote:
> > On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
> >> Chris Snook <csnook@redhat.com> wrote:
> >> >
> >> > Because atomic operations are generally used for synchronization, which requires
> >> > volatile behavior. Most such codepaths currently use an inefficient barrier().
> >> > Some forget to and we get bugs, because people assume that atomic_read()
> >> > actually reads something, and atomic_write() actually writes something. Worse,
> >> > these are architecture-specific, even compiler version-specific bugs that are
> >> > often difficult to track down.
> >>
> >> I'm yet to see a single example from the current tree where
> >> this patch series is the correct solution. So far the only
> >> example has been a buggy piece of code which has since been
> >> fixed with a cpu_relax.
> >
> > Btw.: we still have
> >
> > include/asm-i386/mach-es7000/mach_wakecpu.h: while (!atomic_read(deassert));
> > include/asm-i386/mach-default/mach_wakecpu.h: while (!atomic_read(deassert));
> >
> > Looks like they need to be fixed as well.
>
>
> I don't know if this here is affected:
Yes, I think it is. You're clearly expecting the read to actually happen
when you call get_hpsb_generation(). It's clearly not a busy-loop, so
cpu_relax() sounds pointless / wrong solution for this case, so I'm now
somewhat beginning to appreciate the motivation behind this series :-)
But as I said, there are ways to achieve the same goals of this series
without using "volatile".
I think I'll submit a RFC/patch or two on this myself (will also fix
the code pieces listed here).
> /* drivers/ieee1394/ieee1394_core.h */
> static inline unsigned int get_hpsb_generation(struct hpsb_host *host)
> {
> return atomic_read(&host->generation);
> }
>
> /* drivers/ieee1394/nodemgr.c */
> static int nodemgr_host_thread(void *__hi)
> {
> [...]
>
> for (;;) {
> [... sleep until bus reset event ...]
>
> /* Pause for 1/4 second in 1/16 second intervals,
> * to make sure things settle down. */
> g = get_hpsb_generation(host);
> for (i = 0; i < 4 ; i++) {
> if (msleep_interruptible(63) ||
> kthread_should_stop())
> goto exit;
Totally unrelated, but this looks weird. IMHO you actually wanted:
msleep_interruptible(63);
if (kthread_should_stop())
goto exit;
here, didn't you? Otherwise the thread will exit even when
kthread_should_stop() != TRUE (just because it received a signal),
and it is not good for a kthread to exit on its own if it uses
kthread_should_stop() or if some other piece of kernel code could
eventually call kthread_stop(tsk) on it.
Ok, probably the thread will never receive a signal in the first
place because it's spawned off kthreadd which ignores all signals
beforehand, but still ...
[PATCH] ieee1394: Fix kthread stopping in nodemgr_host_thread
The nodemgr host thread can exit on its own even when kthread_should_stop
is not true, on receiving a signal (might never happen in practice, as
it ignores signals). But considering kthread_stop() must not be mixed with
kthreads that can exit on their own, I think changing the code like this
is clearer. This change means the thread can cut its sleep short when
receive a signal but looking at the code around, that sounds okay (and
again, it might never actually recieve a signal in practice).
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/ieee1394/nodemgr.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/ieee1394/nodemgr.c b/drivers/ieee1394/nodemgr.c
index 2ffd534..981a7da 100644
--- a/drivers/ieee1394/nodemgr.c
+++ b/drivers/ieee1394/nodemgr.c
@@ -1721,7 +1721,8 @@ static int nodemgr_host_thread(void *__hi)
* to make sure things settle down. */
g = get_hpsb_generation(host);
for (i = 0; i < 4 ; i++) {
- if (msleep_interruptible(63) || kthread_should_stop())
+ msleep_interruptible(63);
+ if (kthread_should_stop())
goto exit;
/* Now get the generation in which the node ID's we collect
^ permalink raw reply related
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney @ 2007-08-15 14:25 UTC (permalink / raw)
To: Satyam Sharma
Cc: Stefan Richter, Christoph Lameter, Chris Snook,
Linux Kernel Mailing List, linux-arch, Linus Torvalds, netdev,
Andrew Morton, ak, heiko.carstens, davem, schwidefsky, wensong,
horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl, segher,
Herbert Xu
In-Reply-To: <alpine.LFD.0.999.0708151906330.16414@enigma.security.iitk.ac.in>
On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
> On Wed, 15 Aug 2007, Stefan Richter wrote:
> > Satyam Sharma wrote:
> > > On Wed, 15 Aug 2007, Stefan Richter wrote:
> > >> Doesn't "atomic WRT all processors" require volatility?
> > >
> > > No, it definitely doesn't. Why should it?
> > >
> > > "Atomic w.r.t. all processors" is just your normal, simple "atomicity"
> > > for SMP systems (ensure that that object is modified / set / replaced
> > > in main memory atomically) and has nothing to do with "volatile"
> > > behaviour.
> > >
> > > "Volatile behaviour" itself isn't consistently defined (at least
> > > definitely not consistently implemented in various gcc versions across
> > > platforms), but it is /expected/ to mean something like: "ensure that
> > > every such access actually goes all the way to memory, and is not
> > > re-ordered w.r.t. to other accesses, as far as the compiler can take
> > > care of these". The last "as far as compiler can take care" disclaimer
> > > comes about due to CPUs doing their own re-ordering nowadays.
> > >
> > > For example (say on i386):
> >
> > [...]
> >
> > > In (A) the compiler optimized "a = 10;" away, but the actual store
> > > of the final value "20" to "a" was still "atomic". (B) and (C) also
> > > exhibit "volatile" behaviour apart from the "atomicity".
> > >
> > > But as others replied, it seems some callers out there depend upon
> > > atomic ops exhibiting "volatile" behaviour as well, so that answers
> > > my initial question, actually. I haven't looked at the code Paul
> > > pointed me at, but I wonder if that "forget(x)" macro would help
> > > those cases. I'd wish to avoid the "volatile" primitive, personally.
> >
> > So, looking at load instead of store, understand I correctly that in
> > your opinion
> >
> > int b;
> >
> > b = atomic_read(&a);
> > if (b)
> > do_something_time_consuming();
> >
> > b = atomic_read(&a);
> > if (b)
> > do_something_more();
> >
> > should be changed to explicitly forget(&a) after
> > do_something_time_consuming?
>
> No, I'd actually prefer something like what Christoph Lameter suggested,
> i.e. users (such as above) who want "volatile"-like behaviour from atomic
> ops can use alternative functions. How about something like:
>
> #define atomic_read_volatile(v) \
> ({ \
> forget(&(v)->counter); \
> ((v)->counter); \
> })
Wouldn't the above "forget" the value, throw it away, then forget
that it forgot it, giving non-volatile semantics?
> Or possibly, implement these "volatile" atomic ops variants in inline asm
> like the patch that Sebastian Siewior has submitted on another thread just
> a while back.
Given that you are advocating a change (please keep in mind that
atomic_read() and atomic_set() had volatile semantics on almost all
platforms), care to give some example where these historical volatile
semantics are causing a problem?
> Of course, if we find there are more callers in the kernel who want the
> volatility behaviour than those who don't care, we can re-define the
> existing ops to such variants, and re-name the existing definitions to
> somethine else, say "atomic_read_nonvolatile" for all I care.
Do we really need another set of APIs? Can you give even one example
where the pre-existing volatile semantics are causing enough of a problem
to justify adding yet more atomic_*() APIs?
Thanx, Paul
^ 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