* (no subject)
@ 2003-01-12 13:28 Philip K.F. Hölzenspies
2003-01-12 17:57 ` Shawn Starr
2003-01-13 16:37 ` your mail Pete Zaitcev
0 siblings, 2 replies; 669+ messages in thread
From: Philip K.F. Hölzenspies @ 2003-01-12 13:28 UTC (permalink / raw)
To: linux-kernel
Cc: 'Pete Zaitcev', 'Shawn Starr',
'Bayard R. Coolidge'
I do have the following line in my fstab file (Bayard):
none /proc/bus/usb usbfs defaults 0 0
I believe usbdevfs is deprecated (although - should I use it when my
hosthub is picked up by the OHCI driver in stead of the EHCI driver?).
My full dmesg is attached below (Pete), I'ld say the relevant section
is:
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Enabling device 02:08.2 (0014 -> 0016)
PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
MP table.
hcd.c: Found HC with no IRQ. Check BIOS/PCI 02:08.2 setup!
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Enabling device 02:08.0 (0014 -> 0016)
PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
PCI: Enabling device 02:08.1 (0014 -> 0016)
PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver usblp
printer.c: v0.11: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
Does anybody else with the A7M266-D have that "Probably buggy MP table."
For the OHCI 'found device with no IRQ assigned' I don't really get it.
I have all my PCI slots set to auto assign IRQ and I didn't reserve any
IRQ for Legacy Devices, so that shouldn't be the problem.
> I have this board, but the problem is the newer A7M266-D boards have
the USB
> 1.x pins removed.
(Shawn)
I don't know what would be considered a "newer" board, but mine is a
03/07/2002-ASUS-A7M266-D
B.T.W.
I use BIOS rev. 1005.
Regards,
Philip
P.S.
Would configuring the kernel with >1GB mem support remove that
" Warning only 896MB will be used." from my dmesg?
Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11
18:46:51 CET 2003
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003ffec000 (usable)
BIOS-e820: 000000003ffec000 - 000000003ffef000 (ACPI data)
BIOS-e820: 000000003ffef000 - 000000003ffff000 (reserved)
BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
found SMP MP-table at 000f6d10
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 229376
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: ASUS Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 16
Processor #1 Pentium(tm) Pro APIC version 16
I/O APIC #2 Version 17 at 0xFEC00000.
Processors: 2
Kernel command line: BOOT_IMAGE=lfs ro root=305
Initializing CPU#0
Detected 1533.431 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3060.53 BogoMIPS
Memory: 904324k/917504k available (1707k kernel code, 12792k reserved,
604k data, 124k init, 0k highmem)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU0: AMD Athlon(TM) MP 1800+ stepping 02
per-CPU timeslice cutoff: 731.39 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 3060.53 BogoMIPS
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check reporting enabled on CPU#1.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU1: AMD Athlon(TM) MP 1800+ stepping 02
Total of 2 processors activated (6121.06 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22,
2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00170011
....... : max redirection entries: 0017
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 003 03 0 0 0 0 0 1 1 39
02 003 03 0 0 0 0 0 1 1 31
03 003 03 0 0 0 0 0 1 1 41
04 003 03 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 003 03 0 0 0 0 0 1 1 51
07 003 03 0 0 0 0 0 1 1 59
08 003 03 0 0 0 0 0 1 1 61
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 003 03 0 0 0 0 0 1 1 69
0d 003 03 0 0 0 0 0 1 1 71
0e 003 03 0 0 0 0 0 1 1 79
0f 003 03 0 0 0 0 0 1 1 81
10 003 03 1 1 0 1 0 1 1 89
11 000 00 1 0 0 0 0 0 0 00
12 003 03 1 1 0 1 0 1 1 91
13 003 03 1 1 0 1 0 1 1 99
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1533.4929 MHz.
..... host bus clock speed is 266.6942 MHz.
cpu: 0, clocks: 2666942, slice: 888980
CPU0<T0:2666928,T1:1777936,D:12,S:888980,C:2666942>
cpu: 1, clocks: 2666942, slice: 888980
CPU1<T0:2666928,T1:888960,D:8,S:888980,C:2666942>
checking TSC synchronization across CPUs: passed.
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xf0de0, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
PCI->APIC IRQ transform: (B1,I5,P0) -> 16
PCI->APIC IRQ transform: (B2,I5,P0) -> 18
BIOS failed to enable PCI standards compliance, fixing this error.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver v1.1.22 [Flags: R/O]
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
amd768_rng: AMD768 system management I/O registers at 0xE400.
amd768_rng hardware driver 0.1.0 loaded
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
AMD7441: IDE controller on PCI bus 00 dev 39
AMD7441: chipset revision 4
AMD7441: not 100% native mode: will probe irqs later
AMD7441: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD800JB-00CRA1, ATA DISK drive
hdb: WDC WD307AA-00BAA0, ATA DISK drive
hdc: LITEON DVD-ROM LTD163D, ATAPI CD/DVD-ROM drive
hdd: AOPEN CD-RW CRW3248 1.10 20020301, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c03b9124, I/O limit 4095Mb (mask 0xffffffff)
hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63,
UDMA(100)
blk: queue c03b9270, I/O limit 4095Mb (mask 0xffffffff)
hdb: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=3739/255/63,
UDMA(66)
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
Partition check:
hda: hda1 hda2 < hda5 >
hdb: hdb1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
02:05.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0xc800. Vers
LK1.1.16
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected AMD 760MP chipset
agpgart: AGP aperture is 32M @ 0xfc000000
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
es1371: version v0.30 time 18:48:06 Jan 11 2003
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Enabling device 02:08.2 (0014 -> 0016)
PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
MP table.
hcd.c: Found HC with no IRQ. Check BIOS/PCI 02:08.2 setup!
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Enabling device 02:08.0 (0014 -> 0016)
PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
PCI: Enabling device 02:08.1 (0014 -> 0016)
PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
MP table.
usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver usblp
printer.c: v0.11: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 124k freed
^ permalink raw reply [flat|nested] 669+ messages in thread* Re:
2003-01-12 13:28 Philip K.F. Hölzenspies
@ 2003-01-12 17:57 ` Shawn Starr
2003-01-13 16:37 ` your mail Pete Zaitcev
1 sibling, 0 replies; 669+ messages in thread
From: Shawn Starr @ 2003-01-12 17:57 UTC (permalink / raw)
To: Philip K.F. Hölzenspies, linux-kernel
Cc: 'Pete Zaitcev', 'Bayard R. Coolidge'
Same bug I get with 2.4.20 :-(
On Sunday 12 January 2003 8:28 am, Philip K.F. Hölzenspies wrote:
> I do have the following line in my fstab file (Bayard):
>
> none /proc/bus/usb usbfs defaults 0 0
>
> I believe usbdevfs is deprecated (although - should I use it when my
> hosthub is picked up by the OHCI driver in stead of the EHCI driver?).
>
> My full dmesg is attached below (Pete), I'ld say the relevant section
> is:
>
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.
> hcd.c: Found HC with no IRQ. Check BIOS/PCI 02:08.2 setup!
> uhci.c: USB Universal Host Controller Interface driver v1.1
> PCI: Enabling device 02:08.0 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> PCI: Enabling device 02:08.1 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> usb.c: registered new driver hiddev
> usb.c: registered new driver hid
> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
> hid-core.c: USB HID support drivers
> usb.c: registered new driver usblp
> printer.c: v0.11: USB Printer Device Class driver
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> USB Mass Storage support registered.
>
> Does anybody else with the A7M266-D have that "Probably buggy MP table."
>
> For the OHCI 'found device with no IRQ assigned' I don't really get it.
> I have all my PCI slots set to auto assign IRQ and I didn't reserve any
> IRQ for Legacy Devices, so that shouldn't be the problem.
>
> > I have this board, but the problem is the newer A7M266-D boards have
>
> the USB
>
> > 1.x pins removed.
>
> (Shawn)
>
> I don't know what would be considered a "newer" board, but mine is a
> 03/07/2002-ASUS-A7M266-D
>
> B.T.W.
> I use BIOS rev. 1005.
>
> Regards,
>
> Philip
>
> P.S.
> Would configuring the kernel with >1GB mem support remove that
> " Warning only 896MB will be used." from my dmesg?
>
>
>
> Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11
> 18:46:51 CET 2003
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003ffec000 (usable)
> BIOS-e820: 000000003ffec000 - 000000003ffef000 (ACPI data)
> BIOS-e820: 000000003ffef000 - 000000003ffff000 (reserved)
> BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> Warning only 896MB will be used.
> Use a HIGHMEM enabled kernel.
> 896MB LOWMEM available.
> found SMP MP-table at 000f6d10
> hm, page 000f6000 reserved twice.
> hm, page 000f7000 reserved twice.
> hm, page 000f6000 reserved twice.
> hm, page 000f7000 reserved twice.
> On node 0 totalpages: 229376
> zone(0): 4096 pages.
> zone(1): 225280 pages.
> zone(2): 0 pages.
> Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
> OEM ID: ASUS Product ID: PROD00000000 APIC at: 0xFEE00000
> Processor #0 Pentium(tm) Pro APIC version 16
> Processor #1 Pentium(tm) Pro APIC version 16
> I/O APIC #2 Version 17 at 0xFEC00000.
> Processors: 2
> Kernel command line: BOOT_IMAGE=lfs ro root=305
> Initializing CPU#0
> Detected 1533.431 MHz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 3060.53 BogoMIPS
> Memory: 904324k/917504k available (1707k kernel code, 12792k reserved,
> 604k data, 124k init, 0k highmem)
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode cache hash table entries: 65536 (order: 7, 524288 bytes)
> Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
> Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
> CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
> mtrr: detected mtrr type: Intel
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> Intel machine check reporting enabled on CPU#0.
> CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
> CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
> CPU0: AMD Athlon(TM) MP 1800+ stepping 02
> per-CPU timeslice cutoff: 731.39 usecs.
> enabled ExtINT on CPU#0
> ESR value before enabling vector: 00000000
> ESR value after enabling vector: 00000000
> Booting processor 1/1 eip 2000
> Initializing CPU#1
> masked ExtINT on CPU#1
> ESR value before enabling vector: 00000000
> ESR value after enabling vector: 00000000
> Calibrating delay loop... 3060.53 BogoMIPS
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 256K (64 bytes/line)
> Intel machine check reporting enabled on CPU#1.
> CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
> CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
> CPU1: AMD Athlon(TM) MP 1800+ stepping 02
> Total of 2 processors activated (6121.06 BogoMIPS).
> ENABLING IO-APIC IRQs
> Setting 2 in the phys_id_present_map
> ...changing IO-APIC physical APIC ID to 2 ... ok.
> init IO_APIC IRQs
> IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-10, 2-11, 2-17, 2-20, 2-21, 2-22,
> 2-23 not connected.
> ..TIMER: vector=0x31 pin1=2 pin2=0
> number of MP IRQ sources: 16.
> number of IO-APIC #2 registers: 24.
> testing the IO APIC.......................
>
> IO APIC #2......
> .... register #00: 02000000
> ....... : physical APIC id: 02
> .... register #01: 00170011
> ....... : max redirection entries: 0017
> ....... : PRQ implemented: 0
> ....... : IO APIC version: 0011
> .... register #02: 00000000
> ....... : arbitration: 00
> .... IRQ redirection table:
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> 00 000 00 1 0 0 0 0 0 0 00
> 01 003 03 0 0 0 0 0 1 1 39
> 02 003 03 0 0 0 0 0 1 1 31
> 03 003 03 0 0 0 0 0 1 1 41
> 04 003 03 0 0 0 0 0 1 1 49
> 05 000 00 1 0 0 0 0 0 0 00
> 06 003 03 0 0 0 0 0 1 1 51
> 07 003 03 0 0 0 0 0 1 1 59
> 08 003 03 0 0 0 0 0 1 1 61
> 09 000 00 1 0 0 0 0 0 0 00
> 0a 000 00 1 0 0 0 0 0 0 00
> 0b 000 00 1 0 0 0 0 0 0 00
> 0c 003 03 0 0 0 0 0 1 1 69
> 0d 003 03 0 0 0 0 0 1 1 71
> 0e 003 03 0 0 0 0 0 1 1 79
> 0f 003 03 0 0 0 0 0 1 1 81
> 10 003 03 1 1 0 1 0 1 1 89
> 11 000 00 1 0 0 0 0 0 0 00
> 12 003 03 1 1 0 1 0 1 1 91
> 13 003 03 1 1 0 1 0 1 1 99
> 14 000 00 1 0 0 0 0 0 0 00
> 15 000 00 1 0 0 0 0 0 0 00
> 16 000 00 1 0 0 0 0 0 0 00
> 17 000 00 1 0 0 0 0 0 0 00
> IRQ to pin mappings:
> IRQ0 -> 0:2
> IRQ1 -> 0:1
> IRQ3 -> 0:3
> IRQ4 -> 0:4
> IRQ6 -> 0:6
> IRQ7 -> 0:7
> IRQ8 -> 0:8
> IRQ12 -> 0:12
> IRQ13 -> 0:13
> IRQ14 -> 0:14
> IRQ15 -> 0:15
> IRQ16 -> 0:16
> IRQ18 -> 0:18
> IRQ19 -> 0:19
> .................................... done.
> Using local APIC timer interrupts.
> calibrating APIC timer ...
> ..... CPU clock speed is 1533.4929 MHz.
> ..... host bus clock speed is 266.6942 MHz.
> cpu: 0, clocks: 2666942, slice: 888980
> CPU0<T0:2666928,T1:1777936,D:12,S:888980,C:2666942>
> cpu: 1, clocks: 2666942, slice: 888980
> CPU1<T0:2666928,T1:888960,D:8,S:888980,C:2666942>
> checking TSC synchronization across CPUs: passed.
> Waiting on wait_init_idle (map = 0x2)
> All processors have done init_idle
> mtrr: your CPUs had inconsistent fixed MTRR settings
> mtrr: probably your BIOS does not setup all CPUs
> PCI: PCI BIOS revision 2.10 entry at 0xf0de0, last bus=2
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
> PCI->APIC IRQ transform: (B1,I5,P0) -> 16
> PCI->APIC IRQ transform: (B2,I5,P0) -> 18
> BIOS failed to enable PCI standards compliance, fixing this error.
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> NTFS driver v1.1.22 [Flags: R/O]
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> amd768_rng: AMD768 system management I/O registers at 0xE400.
> amd768_rng hardware driver 0.1.0 loaded
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> AMD7441: IDE controller on PCI bus 00 dev 39
> AMD7441: chipset revision 4
> AMD7441: not 100% native mode: will probe irqs later
> AMD7441: disabling single-word DMA support (revision < C4)
> ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
> hda: WDC WD800JB-00CRA1, ATA DISK drive
> hdb: WDC WD307AA-00BAA0, ATA DISK drive
> hdc: LITEON DVD-ROM LTD163D, ATAPI CD/DVD-ROM drive
> hdd: AOPEN CD-RW CRW3248 1.10 20020301, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> blk: queue c03b9124, I/O limit 4095Mb (mask 0xffffffff)
> hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63,
> UDMA(100)
> blk: queue c03b9270, I/O limit 4095Mb (mask 0xffffffff)
> hdb: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=3739/255/63,
> UDMA(66)
> hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> hdd: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
> Partition check:
> hda: hda1 hda2 < hda5 >
> hdb: hdb1
> Floppy drive(s): fd0 is 1.44M
> FDC 0 is a post-1991 82077
> loop: loaded (max 8 devices)
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 02:05.0: 3Com PCI 3c982 Dual Port Server Cyclone at 0xc800. Vers
> LK1.1.16
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 816M
> agpgart: Detected AMD 760MP chipset
> agpgart: AGP aperture is 32M @ 0xfc000000
> SCSI subsystem driver Revision: 1.00
> kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
> es1371: version v0.30 time 18:48:06 Jan 11 2003
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.
> hcd.c: Found HC with no IRQ. Check BIOS/PCI 02:08.2 setup!
> uhci.c: USB Universal Host Controller Interface driver v1.1
> PCI: Enabling device 02:08.0 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin A of device 02:08.0. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> PCI: Enabling device 02:08.1 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin B of device 02:08.1. Probably buggy
> MP table.
> usb-ohci.c: found OHCI device with no IRQ assigned. check BIOS settings!
> usb.c: registered new driver hiddev
> usb.c: registered new driver hid
> hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
> hid-core.c: USB HID support drivers
> usb.c: registered new driver usblp
> printer.c: v0.11: USB Printer Device Class driver
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> USB Mass Storage support registered.
> mice: PS/2 mouse device common for all mice
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 8192 buckets, 64Kbytes
> TCP: Hash tables configured (established 262144 bind 65536)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 124k freed
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-12 13:28 Philip K.F. Hölzenspies
2003-01-12 17:57 ` Shawn Starr
@ 2003-01-13 16:37 ` Pete Zaitcev
1 sibling, 0 replies; 669+ messages in thread
From: Pete Zaitcev @ 2003-01-13 16:37 UTC (permalink / raw)
To: Philip K.F. Hölzenspies; +Cc: linux-kernel
> Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11 18:46:51 CET 2003
> Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
>[...]
> PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
> PCI->APIC IRQ transform: (B1,I5,P0) -> 16
> PCI->APIC IRQ transform: (B2,I5,P0) -> 18
> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.
I am sorry to say, I cannot help you. This is the department
of Manfred, most likely. The 95% bet is that your BIOS is crap,
and you have to poke ASUS. However, you might want to explore
a possiblity of a bug. The best way to do it is to run "mptable"
program to dump the table and then get someone who makes
a sense of the data. Try to figure out who wrote the code
to support AMD IRQ router. He may be the culprit (5%, but...)
http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.i386.rpm
http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.src.rpm
-- Pete
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2024-02-09 12:30 Ulf Hansson
2024-02-14 14:09 ` your mail Konstantin Ryabitsev
0 siblings, 1 reply; 669+ messages in thread
From: Ulf Hansson @ 2024-02-09 12:30 UTC (permalink / raw)
To: keys
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFLeb6sBEADVlCKZoYySp1SEBfgbzAgOujtCw48WIKD3bDV3KJNCgU1lu4ch
y/BJiJLV+oMz8jrhEB1W9sQml3c09/5IB0JnWBRJyxSlxGpJlcHd+FKAFeH9lpRs
C66NGWmmnMWFKoYCpsyvA2PAz6miqdbU7mTKdqaJPuTypEVbl4Mu7LGg5LigtQTK
tIUL15HVMfFfTw0QYsRdxEMiWmF9H1VqLaEmQtzE4basFs1OruWNqKLoKeOBa77H
4H3ZN9DcDgacrFrXtU83ja0QNZgl93l3/Ua4fhXDLsMzG12WSt3BvyHtQWQ9WMjR
2N4wSO5+qu+q8LejFgtU3sBJ8ZQUtsN3YqvOhH0Mh1q+fIOE0XRLSyHvQ6WB7nU5
ATVkYVpKbRU3AHFDj/FpDmkh5P3Kx8R0tBCpFpBw4yh7XIqH8+yo/ZlzX63tt9X9
rS2vIZzDq98GicuNO00HlQMEsE2Tc4d9jZSozKEM+HXg5q1jHCE/v9w/hMxKw5k2
GNYTfakf0nHG+EdG0x8QJ2ExEjoeHfElbm5X1i9mSE9/WtNvDuUAc889YG2LHPyi
tuD2D7hhzcbzu/legPA1OcSdbzSAtlDVh+EMPLG0qv+4NdENgEX+5elf3/o+y8o1
WvoaA8++wfUFEsVe6aQe9QTmNgTMLkw00j/Po3nvGtH9XwqEFV8edlxscwARAQAB
tCRVbGYgSGFuc3NvbiA8dWxmLmhhbnNzb25AbGluYXJvLm9yZz6JAj4EEwECACgF
AlLeb6sCGwMFCQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEP4mhCVz
WIwpwzgQAI/r+EgrGAoI4/sxAhFolRDTRyUQZo+aFv0k5BZ5vKkjc2QMcd6QP27f
KUpZN17CNCmYS4LkX1v4EYbTr/kO/Q289aqXo1d5q8mE1zacwTjeIB1zXxMFEqwV
OEPuyebYloPUdi4jKV2AhHPd25kamF92v9JNKCaOho+Mm+WOMOcat9smJ5jt72Az
PowbHThGsS2SQAmnHLVuZcf778C2F1LEaeRi1luvqMHuJq/jJP5qBIzcDk9lafqu
5bq1ezvepqB3UFvghUUtKfzgtuKhuUB9gh8cyKSqGVmBsbl8ZZ/en4Fa85+JHjke
K1uN4vJTcSuWmhIWUVODjlGm7oRVb3EvcxmPta1QTcVLkpmSSVqqqr+G5wSNd94F
GsT+HpM8Pl/Mj2QT1ODyQKJcVW5xi4ugEsHT/hnEYoGVUmIMzcCYwFJU8b06ieDC
shXjsF7ewr0ZR5kc45s66cQLcoyFH+McEWfM+GLhhsgyHIawIDuPj8sXQ0ewMTMN
QPBAo5zk8MK3UR5fQIhjmzxX/Q+Omlj2iJvNqu5mln+T4YDTiOqcjmEwiMHtf5Lo
Vf/R+PwV+PpB+hplTVBIvukcDrjf532Cl6E8JmmJMqfWaHfoliI4OcFZVsZ2vqfk
HUyvN2iKmS9rjmim4u7AnZlr261tvaEflQMzRa99q3jpjbutI+5viQJUBBMBCgA+
AhsDAh4BAheABQsJCAcDBRUKCQgLBRYCAwEAFiEEugLDXPmKSktSkQsV/iaEJXNY
jCkFAmXGErwFCRxNpJEACgkQ/iaEJXNYjCkOVw//Rhe/QywkfsJDTqT10ToxDKzL
TjzptONezqgEFuVVdNmjWfDEm4aVV1nstPz2J0hb3mcI9X5LtvSJrUr2p1K2Fw5i
x//KrCaWJ6qHdVZotfR8BYK+GIJnPhPYEXjpYG3EjILkXiD3haDuF25VLBwFO45x
Sbhagklnw8IELfWIpgy9eabmos0X/rfap6gvGdMaY9zP+FleL++9NhfDGpOucAiv
Zxvd41Fzw0X5EnriCz3AdH5Tw+oHYU/WJwMn33NL7O+fO4oeZY4hyGysJePTCSlA
RNLI+VjI+A4CTTX9tQYwPSd4bMj+O6QZilnsJkDW2l8WqTDkh+Z6vgUiYFAM6Un2
wkOZP+wAzbT6qj+6iKh5amvNPLvkpz2zetUXnrS8KJXjasQ8doqZNFXVRHrgR46o
3z8jszU2IOwaoRBMQWMsxbWgF8Y04dchtG23XZLmoUfkgG/O5QP4XaliblKgEyVj
r+Z3TFrTyWn3JLCjU1cNyob81iFG/paxtaGQcwYIQEv9O9YvJBM6aUyMucxnUE8y
r2mFSBMNsNmWs17BmzfzagTGmz949r8mA3XBGaAlufQh6DDr5HO+J8QhLJzNPDvS
iHSgHeqP24jpEYPPTkPBi8PC7V5QWSdFMAjmfvjSfHJwNMBPHv10iZNVswhsz6mt
UQ2d3SwHsLWoo6AucyW0JVVsZiBIYW5zc29uIDx1bGYuYy5oYW5zc29uQGdtYWls
LmNvbT6JAlUEEwEKAD8CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEEugLD
XPmKSktSkQsV/iaEJXNYjCkFAmXGEsYFCRxNpJEACgkQ/iaEJXNYjCnyExAAiDw0
75BGVNoPa+nJxKqu6SongzynE6TWXGr19QETRoThn0jD9Li2/2Il2TM+oHdF18kz
Wwv+BMdKy5oEOdWHQqlUHbMh8kv4Cl5fkp7+mecQhXQAezODA9QPQ8x2BBpssQ6I
eLQTCtkEUH/tbSHLb7FLahtxRZscF1+R4cfM+qghuNer9eqaAdiVHjplhSl43JbP
Nt7l0BrE0o0aDVziHREdO5EmzsolIktVLwrHqYneyLc7sutnUuolX8/Q4pSEyo6c
MNeU/0J6ewupw1ZS9o0Clf8mMj2IfE8PBxEBH8KwpcwSU8r7XI1HRYjGlTbSxgk7
uS8N7WtZj4tPVvS0BQtBK6+Sz15jxOd4wXpjTrch/iQLfyqhWbYw2BpZh5ISJAhF
0cULI/RHuW12KkQzAKPEo6EKHkw6zUrHueE4YqRA5WhKU5ShXl12O+KqyS9GG1ok
/8O3AhWCV3oCE+bHlIKngvR5yWrRTEo80rJ7bP2JEFU2yls7/O97xUflEHk2mgMA
WC2fhrwSrnj5GNbx78yXFA4Fd/o04JThpQCrwdW/EykAXLSXHYHtil6od0y2Lg9G
kKYDd+2SyGaHkfo0SC5i7r4vgnlSi8n3ZIBNgQWprru4N4jS2iMNZNcp/hlfuDgU
8JqrkcIeyLkxsT4Wmlyg06qh95XMzB/69o8aZye5Ag0EUt5vqwEQAN1GiksDy1t4
57aQ/4qk7AONeGj51ECXJRUBRCGTqQpclS6UO57OsWPnX0RQL2/leGnGcBjmIQLj
GiNaNN0y3M+itAFJk6ckmXv3GNoRmFvwQTpZP8wV8KREcX6DBC5OnBtwyDZmIYMG
nshN3nMSrWEuiz/DQV0QGWNXwmlAOkmZ5C24IZcCqtDLoBq7HR+l4hSBfRB+CkTa
FIdVkVfRteYni76GgU8NZFDnyF5D3ImbxhD6RVzW3y3cKOolhjGAkwb52CVQTWDd
nVWHS7iFax9mLPnCaZR4Gy+O4ilx5RVE+PCzrgJDPy3puEYS1e5rfL21VgdPlQ+t
PrbPzrDh5J1UAVdNfBtFZk9Fd7rfQMTLL22sciG0XAZsZV+97reI07kUyX7x7ZSq
/y9ERWUWO9YHg+wcPfjg53LFSYnc24VPy1gVfWCmhe3+Gcx8qy/3r3RwsM6+bUXK
4VlxMAkABLtIii8M/LvqhzL+RiFSckZIKqNEILQlN8RqtCyr1MZuO4KZ1GGjw8po
D40eEmugskLDewLVvZSVRs1EIiz1jJT2rV6iwt8qLcEDtKw/Pluld7JjGSl3435/
duOUUz5NP0J7SUw1AhiZggVy+LUoqbyzRUhPCo1D4Q5ro5b+/09r+X51cuUq6r/Z
4G90MoTBEF7fah2wGjTRDdchGbo94kPlABEBAAGJAjwEGAEKACYCGwwWIQS6AsNc
+YpKS1KRCxX+JoQlc1iMKQUCZcYTAAUJHE2k1QAKCRD+JoQlc1iMKYgAD/9qOx/9
zYQ6eDHiDDzza0MQxEhNPubqV8Fb7Jx5LB0FNmHV72EVltwa3sOnoxLT8uvhLae/
sw1LH+bxooFBuFLExZWYF4k7a43xa7hkkASxgDU8dpkaukgirGNKW3uzxbWZ0Yo0
oJ1+D/te8jsRSecLGSD96Dxs6S8T/BLrkC9nc2ztnegvZZ3iO59i1vzOJpVv3E6a
Ii/GduVSJHbZTVHRdkDTE9w1aum7CNRKy1kbrfCn70Lb2sDweRhwGHimN3YvCHPy
lUZGd4TqVVWmbYDnyj2yg1LR7539uQ1oqYb9GqCRFLrgHtJ18cwjb/LAb0nrwCSH
Z0YVDyB1RU3KIcrdk3C30Axj8t9cqJ2wlnf1OMZr+yDYg7hmGyI/4GQDEFLb54BH
ucGzQTaKL741LYwsMnPtM2sD7kZ74P0gKv0VxY90EeTQvW1a00VRDDRD+HOvH0cI
ZjS7tpmCppcEpP/vk943uJZY2nCsaqdLGk0FbUK4IIUgNMaZGNN4FjHccDl0b1ae
v1uRWPnNsxvnkU7EJHHvJC1v72W0KyRkcsuWHsSwSCVAms2VMuSvogCYGK9UO1aN
jx9RsouYxT/2FEbnhVO+YrjBiCjJSoQ+W8Yt3vr7I3c4SPusrWdfIeRJe8u0ofAY
yWUqA2bGFMMQD+AOX+r5siMTtEjwo08KUb8f4A==
=bqZE
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2023-10-16 12:31 Gilbert Adikankwu
2023-10-16 12:34 ` your mail Julia Lawall
0 siblings, 1 reply; 669+ messages in thread
From: Gilbert Adikankwu @ 2023-10-16 12:31 UTC (permalink / raw)
To: Julia Lawall; +Cc: outreachy, gregkh, linux-staging, linux-kernel
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Bcc:
Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
condition tests
Reply-To:
In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
>
>
> On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
>
> > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > around condition tests.
>
> If you need to make any changes to the patch, there is no need to give the
> count of the changes. It doesn't matter if it's 47, 46, 35, etc.
>
> julia
>
Hi Julia,
I added the number because I saw I similar commit on the logs that did
so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
> >
> > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > ---
> > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > 1 file changed, 36 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > index eb63daaca702..e8ddd691b788 100644
> > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > /* SET_FEATURE */
> > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > selector = le16_to_cpu(p_ctrl->wValue);
> > - if ((recipient == USB_RECIP_DEVICE) &&
> > - (selector == USB_DEVICE_TEST_MODE)) {
> > + if (recipient == USB_RECIP_DEVICE &&
> > + selector == USB_DEVICE_TEST_MODE) {
> > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > test_mode = (u32)(wIndex >> 8);
> > _nbu2ss_set_test_mode(udc, test_mode);
> > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > u32 num;
> > u32 data;
> >
> > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > return -EINVAL;
> >
> > num = ep->epnum - 1;
> > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > u32 data;
> >
> > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > return; /* Not Support DMA */
> >
> > num = ep->epnum - 1;
> > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > return; /* VBUS OFF */
> >
> > data = _nbu2ss_readl(&preg->USBSSCONF);
> > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > return; /* Not Support DMA */
> >
> > num = ep->epnum - 1;
> > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > union usb_reg_access temp_32;
> > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> >
> > - if ((length > 0) && (length < sizeof(u32))) {
> > + if (length > 0 && length < sizeof(u32)) {
> > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > for (i = 0 ; i < length ; i++)
> > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > union usb_reg_access temp_32;
> > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> >
> > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > for (i = 0 ; i < i_remain_size ; i++)
> > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > return result;
> > }
> >
> > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > p_buffer += result;
> > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > req->div_len = result;
> > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > req->req.actual += result;
> > i_recv_length -= result;
> >
> > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > p_buffer += result;
> > i_remain_size -= result;
> >
> > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> >
> > req->req.actual += result;
> >
> > - if ((req->req.actual == req->req.length) ||
> > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > + if (req->req.actual == req->req.length ||
> > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > result = 0;
> > }
> >
> > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> >
> > i_buf_size = min((req->req.length - req->req.actual), data_size);
> >
> > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > - (i_buf_size >= sizeof(u32))) {
> > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > + i_buf_size >= sizeof(u32)) {
> > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > } else {
> > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > }
> > }
> > } else {
> > - if ((req->req.actual == req->req.length) ||
> > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > + if (req->req.actual == req->req.length ||
> > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > result = 0;
> > }
> > }
> > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> >
> > num = ep->epnum - 1;
> >
> > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > - (data_size >= sizeof(u32))) {
> > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > + data_size >= sizeof(u32)) {
> > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > } else {
> > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > u8 num;
> > u32 data;
> >
> > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > return;
> >
> > num = (ep_adrs & 0x7F) - 1;
> > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > struct nbu2ss_ep *ep;
> > struct fc_regs __iomem *preg = udc->p_regs;
> >
> > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > if (bstall) {
> > /* Set STALL */
> > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > u8 ep_adrs;
> > int result = -EOPNOTSUPP;
> >
> > - if ((udc->ctrl.wLength != 0x0000) ||
> > - (direction != USB_DIR_OUT)) {
> > + if (udc->ctrl.wLength != 0x0000 ||
> > + direction != USB_DIR_OUT) {
> > return -EINVAL;
> > }
> >
> > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > u8 ep_adrs;
> > int result = -EINVAL;
> >
> > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > return result;
> >
> > length =
> > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > int result = 0;
> > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> >
> > - if ((udc->ctrl.bRequestType != 0x00) ||
> > - (udc->ctrl.wIndex != 0x0000) ||
> > - (udc->ctrl.wLength != 0x0000)) {
> > + if (udc->ctrl.bRequestType != 0x00 ||
> > + udc->ctrl.wIndex != 0x0000 ||
> > + udc->ctrl.wLength != 0x0000) {
> > return -EINVAL;
> > }
> >
> > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > {
> > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> >
> > - if ((udc->ctrl.wIndex != 0x0000) ||
> > - (udc->ctrl.wLength != 0x0000) ||
> > - (udc->ctrl.bRequestType != 0x00)) {
> > + if (udc->ctrl.wIndex != 0x0000 ||
> > + udc->ctrl.wLength != 0x0000 ||
> > + udc->ctrl.bRequestType != 0x00) {
> > return -EINVAL;
> > }
> >
> > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > }
> >
> > #ifdef USE_DMA
> > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > - (req->req.dma != 0))
> > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > + req->req.dma != 0)
> > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > #endif
> >
> > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > mpkt = ep->ep.maxpacket;
> > size = preq->actual % mpkt;
> > if (size > 0) {
> > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > } else {
> > _nbu2ss_epn_in_int(udc, ep, req);
> > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > }
> >
> > ep_type = usb_endpoint_type(desc);
> > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > return -EINVAL;
> > }
> > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > if (udc->vbus_active == 0)
> > return -ESHUTDOWN;
> >
> > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > return -ESHUTDOWN;
> > }
> > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > }
> > }
> >
> > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > - (req->req.dma != 0))
> > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > + req->req.dma != 0)
> > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > #endif
> >
> > --
> > 2.34.1
> >
> >
> >
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-10-16 12:31 Gilbert Adikankwu
@ 2023-10-16 12:34 ` Julia Lawall
2023-10-16 12:42 ` Gilbert Adikankwu
0 siblings, 1 reply; 669+ messages in thread
From: Julia Lawall @ 2023-10-16 12:34 UTC (permalink / raw)
To: Gilbert Adikankwu; +Cc: outreachy, gregkh, linux-staging, linux-kernel
On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> Bcc:
> Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> condition tests
> Reply-To:
> In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
>
> On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> >
> > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > around condition tests.
> >
> > If you need to make any changes to the patch, there is no need to give the
> > count of the changes. It doesn't matter if it's 47, 46, 35, etc.
> >
> > julia
> >
> Hi Julia,
>
> I added the number because I saw I similar commit on the logs that did
> so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
OK, I still think it's pointless... The person who looks at the commit 5
years from now won't care about this information. They care about what
you did and why.
julia
> > >
> > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > ---
> > > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > 1 file changed, 36 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > index eb63daaca702..e8ddd691b788 100644
> > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > /* SET_FEATURE */
> > > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > selector = le16_to_cpu(p_ctrl->wValue);
> > > - if ((recipient == USB_RECIP_DEVICE) &&
> > > - (selector == USB_DEVICE_TEST_MODE)) {
> > > + if (recipient == USB_RECIP_DEVICE &&
> > > + selector == USB_DEVICE_TEST_MODE) {
> > > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > test_mode = (u32)(wIndex >> 8);
> > > _nbu2ss_set_test_mode(udc, test_mode);
> > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > u32 num;
> > > u32 data;
> > >
> > > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > > return -EINVAL;
> > >
> > > num = ep->epnum - 1;
> > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > u32 data;
> > >
> > > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > return; /* Not Support DMA */
> > >
> > > num = ep->epnum - 1;
> > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > return; /* VBUS OFF */
> > >
> > > data = _nbu2ss_readl(&preg->USBSSCONF);
> > > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > return; /* Not Support DMA */
> > >
> > > num = ep->epnum - 1;
> > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > union usb_reg_access temp_32;
> > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > >
> > > - if ((length > 0) && (length < sizeof(u32))) {
> > > + if (length > 0 && length < sizeof(u32)) {
> > > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > for (i = 0 ; i < length ; i++)
> > > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > union usb_reg_access temp_32;
> > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > >
> > > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > for (i = 0 ; i < i_remain_size ; i++)
> > > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > return result;
> > > }
> > >
> > > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > p_buffer += result;
> > > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > req->div_len = result;
> > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > req->req.actual += result;
> > > i_recv_length -= result;
> > >
> > > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > p_buffer += result;
> > > i_remain_size -= result;
> > >
> > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > > req->req.actual += result;
> > >
> > > - if ((req->req.actual == req->req.length) ||
> > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > + if (req->req.actual == req->req.length ||
> > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > result = 0;
> > > }
> > >
> > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > > i_buf_size = min((req->req.length - req->req.actual), data_size);
> > >
> > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > - (i_buf_size >= sizeof(u32))) {
> > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > + i_buf_size >= sizeof(u32)) {
> > > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > } else {
> > > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > }
> > > }
> > > } else {
> > > - if ((req->req.actual == req->req.length) ||
> > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > + if (req->req.actual == req->req.length ||
> > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > result = 0;
> > > }
> > > }
> > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > > num = ep->epnum - 1;
> > >
> > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > - (data_size >= sizeof(u32))) {
> > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > + data_size >= sizeof(u32)) {
> > > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > } else {
> > > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > u8 num;
> > > u32 data;
> > >
> > > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > > return;
> > >
> > > num = (ep_adrs & 0x7F) - 1;
> > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > struct nbu2ss_ep *ep;
> > > struct fc_regs __iomem *preg = udc->p_regs;
> > >
> > > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > if (bstall) {
> > > /* Set STALL */
> > > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > u8 ep_adrs;
> > > int result = -EOPNOTSUPP;
> > >
> > > - if ((udc->ctrl.wLength != 0x0000) ||
> > > - (direction != USB_DIR_OUT)) {
> > > + if (udc->ctrl.wLength != 0x0000 ||
> > > + direction != USB_DIR_OUT) {
> > > return -EINVAL;
> > > }
> > >
> > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > u8 ep_adrs;
> > > int result = -EINVAL;
> > >
> > > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > return result;
> > >
> > > length =
> > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > int result = 0;
> > > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> > >
> > > - if ((udc->ctrl.bRequestType != 0x00) ||
> > > - (udc->ctrl.wIndex != 0x0000) ||
> > > - (udc->ctrl.wLength != 0x0000)) {
> > > + if (udc->ctrl.bRequestType != 0x00 ||
> > > + udc->ctrl.wIndex != 0x0000 ||
> > > + udc->ctrl.wLength != 0x0000) {
> > > return -EINVAL;
> > > }
> > >
> > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > {
> > > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > >
> > > - if ((udc->ctrl.wIndex != 0x0000) ||
> > > - (udc->ctrl.wLength != 0x0000) ||
> > > - (udc->ctrl.bRequestType != 0x00)) {
> > > + if (udc->ctrl.wIndex != 0x0000 ||
> > > + udc->ctrl.wLength != 0x0000 ||
> > > + udc->ctrl.bRequestType != 0x00) {
> > > return -EINVAL;
> > > }
> > >
> > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > }
> > >
> > > #ifdef USE_DMA
> > > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > - (req->req.dma != 0))
> > > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > + req->req.dma != 0)
> > > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > #endif
> > >
> > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > mpkt = ep->ep.maxpacket;
> > > size = preq->actual % mpkt;
> > > if (size > 0) {
> > > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > } else {
> > > _nbu2ss_epn_in_int(udc, ep, req);
> > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > }
> > >
> > > ep_type = usb_endpoint_type(desc);
> > > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > return -EINVAL;
> > > }
> > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > if (udc->vbus_active == 0)
> > > return -ESHUTDOWN;
> > >
> > > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > return -ESHUTDOWN;
> > > }
> > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > }
> > > }
> > >
> > > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > - (req->req.dma != 0))
> > > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > + req->req.dma != 0)
> > > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > #endif
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > >
>
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-10-16 12:34 ` your mail Julia Lawall
@ 2023-10-16 12:42 ` Gilbert Adikankwu
2023-10-16 13:23 ` Julia Lawall
0 siblings, 1 reply; 669+ messages in thread
From: Gilbert Adikankwu @ 2023-10-16 12:42 UTC (permalink / raw)
To: Julia Lawall, outreachy; +Cc: linux-staging, linux-kernel, gregkh
On Mon, Oct 16, 2023 at 02:34:48PM +0200, Julia Lawall wrote:
>
>
> On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
>
> > linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> > Bcc:
> > Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> > condition tests
> > Reply-To:
> > In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
> >
> > On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> > >
> > > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > > around condition tests.
> > >
> > > If you need to make any changes to the patch, there is no need to give the
> > > count of the changes. It doesn't matter if it's 47, 46, 35, etc.
> > >
> > > julia
> > >
> > Hi Julia,
> >
> > I added the number because I saw I similar commit on the logs that did
> > so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
>
> OK, I still think it's pointless... The person who looks at the commit 5
> years from now won't care about this information. They care about what
> you did and why.
>
> julia
>
Ok that make sense. I will revise it. Do I send revision patch now or
later today?
>
> > > >
> > > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > > ---
> > > > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > > 1 file changed, 36 insertions(+), 36 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > > index eb63daaca702..e8ddd691b788 100644
> > > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > > /* SET_FEATURE */
> > > > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > > selector = le16_to_cpu(p_ctrl->wValue);
> > > > - if ((recipient == USB_RECIP_DEVICE) &&
> > > > - (selector == USB_DEVICE_TEST_MODE)) {
> > > > + if (recipient == USB_RECIP_DEVICE &&
> > > > + selector == USB_DEVICE_TEST_MODE) {
> > > > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > > test_mode = (u32)(wIndex >> 8);
> > > > _nbu2ss_set_test_mode(udc, test_mode);
> > > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > u32 num;
> > > > u32 data;
> > > >
> > > > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > > > return -EINVAL;
> > > >
> > > > num = ep->epnum - 1;
> > > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > u32 data;
> > > >
> > > > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > return; /* Not Support DMA */
> > > >
> > > > num = ep->epnum - 1;
> > > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > return; /* VBUS OFF */
> > > >
> > > > data = _nbu2ss_readl(&preg->USBSSCONF);
> > > > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > return; /* Not Support DMA */
> > > >
> > > > num = ep->epnum - 1;
> > > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > > union usb_reg_access temp_32;
> > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > >
> > > > - if ((length > 0) && (length < sizeof(u32))) {
> > > > + if (length > 0 && length < sizeof(u32)) {
> > > > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > > for (i = 0 ; i < length ; i++)
> > > > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > > union usb_reg_access temp_32;
> > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > >
> > > > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > > for (i = 0 ; i < i_remain_size ; i++)
> > > > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > > return result;
> > > > }
> > > >
> > > > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > > p_buffer += result;
> > > > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > > req->div_len = result;
> > > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > > req->req.actual += result;
> > > > i_recv_length -= result;
> > > >
> > > > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > > p_buffer += result;
> > > > i_remain_size -= result;
> > > >
> > > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > > req->req.actual += result;
> > > >
> > > > - if ((req->req.actual == req->req.length) ||
> > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > + if (req->req.actual == req->req.length ||
> > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > result = 0;
> > > > }
> > > >
> > > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > > i_buf_size = min((req->req.length - req->req.actual), data_size);
> > > >
> > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > - (i_buf_size >= sizeof(u32))) {
> > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > + i_buf_size >= sizeof(u32)) {
> > > > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > > } else {
> > > > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > > }
> > > > }
> > > > } else {
> > > > - if ((req->req.actual == req->req.length) ||
> > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > + if (req->req.actual == req->req.length ||
> > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > result = 0;
> > > > }
> > > > }
> > > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > > num = ep->epnum - 1;
> > > >
> > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > - (data_size >= sizeof(u32))) {
> > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > + data_size >= sizeof(u32)) {
> > > > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > > } else {
> > > > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > > u8 num;
> > > > u32 data;
> > > >
> > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > > > return;
> > > >
> > > > num = (ep_adrs & 0x7F) - 1;
> > > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > > struct nbu2ss_ep *ep;
> > > > struct fc_regs __iomem *preg = udc->p_regs;
> > > >
> > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > > if (bstall) {
> > > > /* Set STALL */
> > > > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > > u8 ep_adrs;
> > > > int result = -EOPNOTSUPP;
> > > >
> > > > - if ((udc->ctrl.wLength != 0x0000) ||
> > > > - (direction != USB_DIR_OUT)) {
> > > > + if (udc->ctrl.wLength != 0x0000 ||
> > > > + direction != USB_DIR_OUT) {
> > > > return -EINVAL;
> > > > }
> > > >
> > > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > > u8 ep_adrs;
> > > > int result = -EINVAL;
> > > >
> > > > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > > return result;
> > > >
> > > > length =
> > > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > > int result = 0;
> > > > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> > > >
> > > > - if ((udc->ctrl.bRequestType != 0x00) ||
> > > > - (udc->ctrl.wIndex != 0x0000) ||
> > > > - (udc->ctrl.wLength != 0x0000)) {
> > > > + if (udc->ctrl.bRequestType != 0x00 ||
> > > > + udc->ctrl.wIndex != 0x0000 ||
> > > > + udc->ctrl.wLength != 0x0000) {
> > > > return -EINVAL;
> > > > }
> > > >
> > > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > > {
> > > > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > > >
> > > > - if ((udc->ctrl.wIndex != 0x0000) ||
> > > > - (udc->ctrl.wLength != 0x0000) ||
> > > > - (udc->ctrl.bRequestType != 0x00)) {
> > > > + if (udc->ctrl.wIndex != 0x0000 ||
> > > > + udc->ctrl.wLength != 0x0000 ||
> > > > + udc->ctrl.bRequestType != 0x00) {
> > > > return -EINVAL;
> > > > }
> > > >
> > > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > > }
> > > >
> > > > #ifdef USE_DMA
> > > > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > > - (req->req.dma != 0))
> > > > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > > + req->req.dma != 0)
> > > > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > > #endif
> > > >
> > > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > > mpkt = ep->ep.maxpacket;
> > > > size = preq->actual % mpkt;
> > > > if (size > 0) {
> > > > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > > } else {
> > > > _nbu2ss_epn_in_int(udc, ep, req);
> > > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > }
> > > >
> > > > ep_type = usb_endpoint_type(desc);
> > > > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > > return -EINVAL;
> > > > }
> > > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > if (udc->vbus_active == 0)
> > > > return -ESHUTDOWN;
> > > >
> > > > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > > return -ESHUTDOWN;
> > > > }
> > > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > > }
> > > > }
> > > >
> > > > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > > - (req->req.dma != 0))
> > > > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > > + req->req.dma != 0)
> > > > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > > #endif
> > > >
> > > > --
> > > > 2.34.1
> > > >
> > > >
> > > >
> >
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-10-16 12:42 ` Gilbert Adikankwu
@ 2023-10-16 13:23 ` Julia Lawall
0 siblings, 0 replies; 669+ messages in thread
From: Julia Lawall @ 2023-10-16 13:23 UTC (permalink / raw)
To: Gilbert Adikankwu; +Cc: outreachy, linux-staging, linux-kernel, gregkh
On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> On Mon, Oct 16, 2023 at 02:34:48PM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> >
> > > linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> > > Bcc:
> > > Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> > > condition tests
> > > Reply-To:
> > > In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
> > >
> > > On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> > > >
> > > >
> > > > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> > > >
> > > > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > > > around condition tests.
> > > >
> > > > If you need to make any changes to the patch, there is no need to give the
> > > > count of the changes. It doesn't matter if it's 47, 46, 35, etc.
> > > >
> > > > julia
> > > >
> > > Hi Julia,
> > >
> > > I added the number because I saw I similar commit on the logs that did
> > > so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
> >
> > OK, I still think it's pointless... The person who looks at the commit 5
> > years from now won't care about this information. They care about what
> > you did and why.
> >
> > julia
> >
> Ok that make sense. I will revise it. Do I send revision patch now or
> later today?
You can wait, in case there are other comments.
julia
> >
> > > > >
> > > > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > > > ---
> > > > > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > > > 1 file changed, 36 insertions(+), 36 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > > > index eb63daaca702..e8ddd691b788 100644
> > > > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > > > /* SET_FEATURE */
> > > > > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > > > selector = le16_to_cpu(p_ctrl->wValue);
> > > > > - if ((recipient == USB_RECIP_DEVICE) &&
> > > > > - (selector == USB_DEVICE_TEST_MODE)) {
> > > > > + if (recipient == USB_RECIP_DEVICE &&
> > > > > + selector == USB_DEVICE_TEST_MODE) {
> > > > > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > > > test_mode = (u32)(wIndex >> 8);
> > > > > _nbu2ss_set_test_mode(udc, test_mode);
> > > > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > > u32 num;
> > > > > u32 data;
> > > > >
> > > > > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > > > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > > > > return -EINVAL;
> > > > >
> > > > > num = ep->epnum - 1;
> > > > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > > u32 data;
> > > > >
> > > > > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > > > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > > return; /* Not Support DMA */
> > > > >
> > > > > num = ep->epnum - 1;
> > > > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > > return; /* VBUS OFF */
> > > > >
> > > > > data = _nbu2ss_readl(&preg->USBSSCONF);
> > > > > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > > return; /* Not Support DMA */
> > > > >
> > > > > num = ep->epnum - 1;
> > > > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > > > union usb_reg_access temp_32;
> > > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > > >
> > > > > - if ((length > 0) && (length < sizeof(u32))) {
> > > > > + if (length > 0 && length < sizeof(u32)) {
> > > > > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > > > for (i = 0 ; i < length ; i++)
> > > > > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > > > union usb_reg_access temp_32;
> > > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > > >
> > > > > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > > > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > > > for (i = 0 ; i < i_remain_size ; i++)
> > > > > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > > > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > > > return result;
> > > > > }
> > > > >
> > > > > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > > > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > > > p_buffer += result;
> > > > > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > > > req->div_len = result;
> > > > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > > > req->req.actual += result;
> > > > > i_recv_length -= result;
> > > > >
> > > > > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > > > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > > > p_buffer += result;
> > > > > i_remain_size -= result;
> > > > >
> > > > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > > req->req.actual += result;
> > > > >
> > > > > - if ((req->req.actual == req->req.length) ||
> > > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > > + if (req->req.actual == req->req.length ||
> > > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > > result = 0;
> > > > > }
> > > > >
> > > > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > > i_buf_size = min((req->req.length - req->req.actual), data_size);
> > > > >
> > > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > > - (i_buf_size >= sizeof(u32))) {
> > > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > > + i_buf_size >= sizeof(u32)) {
> > > > > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > > > } else {
> > > > > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > > > }
> > > > > }
> > > > > } else {
> > > > > - if ((req->req.actual == req->req.length) ||
> > > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > > + if (req->req.actual == req->req.length ||
> > > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > > result = 0;
> > > > > }
> > > > > }
> > > > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > > num = ep->epnum - 1;
> > > > >
> > > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > > - (data_size >= sizeof(u32))) {
> > > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > > + data_size >= sizeof(u32)) {
> > > > > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > > > } else {
> > > > > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > > > u8 num;
> > > > > u32 data;
> > > > >
> > > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > > > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > > > > return;
> > > > >
> > > > > num = (ep_adrs & 0x7F) - 1;
> > > > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > > > struct nbu2ss_ep *ep;
> > > > > struct fc_regs __iomem *preg = udc->p_regs;
> > > > >
> > > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > > > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > > > if (bstall) {
> > > > > /* Set STALL */
> > > > > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > > > u8 ep_adrs;
> > > > > int result = -EOPNOTSUPP;
> > > > >
> > > > > - if ((udc->ctrl.wLength != 0x0000) ||
> > > > > - (direction != USB_DIR_OUT)) {
> > > > > + if (udc->ctrl.wLength != 0x0000 ||
> > > > > + direction != USB_DIR_OUT) {
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > > > u8 ep_adrs;
> > > > > int result = -EINVAL;
> > > > >
> > > > > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > > > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > > > return result;
> > > > >
> > > > > length =
> > > > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > > > int result = 0;
> > > > > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> > > > >
> > > > > - if ((udc->ctrl.bRequestType != 0x00) ||
> > > > > - (udc->ctrl.wIndex != 0x0000) ||
> > > > > - (udc->ctrl.wLength != 0x0000)) {
> > > > > + if (udc->ctrl.bRequestType != 0x00 ||
> > > > > + udc->ctrl.wIndex != 0x0000 ||
> > > > > + udc->ctrl.wLength != 0x0000) {
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > > > {
> > > > > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > > > >
> > > > > - if ((udc->ctrl.wIndex != 0x0000) ||
> > > > > - (udc->ctrl.wLength != 0x0000) ||
> > > > > - (udc->ctrl.bRequestType != 0x00)) {
> > > > > + if (udc->ctrl.wIndex != 0x0000 ||
> > > > > + udc->ctrl.wLength != 0x0000 ||
> > > > > + udc->ctrl.bRequestType != 0x00) {
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > > > }
> > > > >
> > > > > #ifdef USE_DMA
> > > > > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > > > - (req->req.dma != 0))
> > > > > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > > > + req->req.dma != 0)
> > > > > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > > > #endif
> > > > >
> > > > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > > > mpkt = ep->ep.maxpacket;
> > > > > size = preq->actual % mpkt;
> > > > > if (size > 0) {
> > > > > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > > > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > > > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > > > } else {
> > > > > _nbu2ss_epn_in_int(udc, ep, req);
> > > > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > > }
> > > > >
> > > > > ep_type = usb_endpoint_type(desc);
> > > > > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > > > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > > > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > > > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > > > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > > > return -EINVAL;
> > > > > }
> > > > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > > if (udc->vbus_active == 0)
> > > > > return -ESHUTDOWN;
> > > > >
> > > > > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > > > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > > > return -ESHUTDOWN;
> > > > > }
> > > > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > > > }
> > > > > }
> > > > >
> > > > > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > > > - (req->req.dma != 0))
> > > > > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > > > + req->req.dma != 0)
> > > > > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > > > #endif
> > > > >
> > > > > --
> > > > > 2.34.1
> > > > >
> > > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2023-05-25 12:01 Murphy Zhou
2023-05-25 12:04 ` your mail Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Murphy Zhou @ 2023-05-25 12:01 UTC (permalink / raw)
To: Linux-Next, linux-xfs, Christoph Hellwig
Hi Christoph,
The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
starts to fail on xfs, not on other fs. It was pass on the previous
tag next-20230519.
After those 2 commits reverted on the top of 0522 tree, it passed.
iomap: update ki_pos in iomap_file_buffered_write
iomap: assign current->backing_dev_info in iomap_file_buffered_write
(the second one was reverted because the first one depends on it)
The test case writev07 forms an iovec with a bad address in the middle,
then writes to the file, expecting a fault return and file not being written.
Now it fails with a fault return but the file has been written.
Looks like it is related to the pos update, could you help to take a look ?
Thanks,
Murphy
[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/writev/writev07.c
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-05-25 12:01 Murphy Zhou
@ 2023-05-25 12:04 ` Christoph Hellwig
2023-05-25 12:45 ` Murphy Zhou
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2023-05-25 12:04 UTC (permalink / raw)
To: Murphy Zhou; +Cc: Linux-Next, linux-xfs, Christoph Hellwig, akpm
On Thu, May 25, 2023 at 08:01:22PM +0800, Murphy Zhou wrote:
> Hi Christoph,
>
> The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
> starts to fail on xfs, not on other fs. It was pass on the previous
> tag next-20230519.
>
> After those 2 commits reverted on the top of 0522 tree, it passed.
>
> iomap: update ki_pos in iomap_file_buffered_write
> iomap: assign current->backing_dev_info in iomap_file_buffered_write
>
> (the second one was reverted because the first one depends on it)
Yes, they are known broken. There has been a v2 on the list already,
which still has issues for fuse, so there will be a v3.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-05-25 12:04 ` your mail Christoph Hellwig
@ 2023-05-25 12:45 ` Murphy Zhou
0 siblings, 0 replies; 669+ messages in thread
From: Murphy Zhou @ 2023-05-25 12:45 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Linux-Next, linux-xfs, akpm
On Thu, May 25, 2023 at 8:04 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, May 25, 2023 at 08:01:22PM +0800, Murphy Zhou wrote:
> > Hi Christoph,
> >
> > The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
> > starts to fail on xfs, not on other fs. It was pass on the previous
> > tag next-20230519.
> >
> > After those 2 commits reverted on the top of 0522 tree, it passed.
> >
> > iomap: update ki_pos in iomap_file_buffered_write
> > iomap: assign current->backing_dev_info in iomap_file_buffered_write
> >
> > (the second one was reverted because the first one depends on it)
>
> Yes, they are known broken. There has been a v2 on the list already,
> which still has issues for fuse, so there will be a v3.
Great! Thank you.
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* [PATCH] maple_tree: Fix a few documentation issues,
@ 2023-05-10 19:01 Thomas Gleixner
2023-05-15 19:27 ` your mail Liam R. Howlett
0 siblings, 1 reply; 669+ messages in thread
From: Thomas Gleixner @ 2023-05-10 19:01 UTC (permalink / raw)
To: LKML; +Cc: Liam R. Howlett, Matthew Wilcox, linux-mm, Shanker Donthineni
The documentation of mt_next() claims that it starts the search at the
provided index. That's incorrect as it starts the search after the provided
index.
The documentation of mt_find() is slightly confusing. "Handles locking" is
not really helpful as it does not explain how the "locking" works. Also the
documentation of index talks about a range, while in reality the index
is updated on a succesful search to the index of the found entry plus one.
Fix similar issues for mt_find_after() and mt_prev().
Remove the completely confusing and pointless "Note: Will not return the
zero entry." comment from mt_for_each() and document @__index correctly.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/maple_tree.h | 4 +---
lib/maple_tree.c | 23 ++++++++++++++++++-----
2 files changed, 19 insertions(+), 8 deletions(-)
--- a/include/linux/maple_tree.h
+++ b/include/linux/maple_tree.h
@@ -659,10 +659,8 @@ void *mt_next(struct maple_tree *mt, uns
* mt_for_each - Iterate over each entry starting at index until max.
* @__tree: The Maple Tree
* @__entry: The current entry
- * @__index: The index to update to track the location in the tree
+ * @__index: The index to start the search from. Subsequently used as iterator.
* @__max: The maximum limit for @index
- *
- * Note: Will not return the zero entry.
*/
#define mt_for_each(__tree, __entry, __index, __max) \
for (__entry = mt_find(__tree, &(__index), __max); \
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -5947,7 +5947,10 @@ EXPORT_SYMBOL_GPL(mas_next);
* @index: The start index
* @max: The maximum index to check
*
- * Return: The entry at @index or higher, or %NULL if nothing is found.
+ * Takes RCU read lock internally to protect the search, which does not
+ * protect the returned pointer after dropping RCU read lock.
+ *
+ * Return: The entry higher than @index or %NULL if nothing is found.
*/
void *mt_next(struct maple_tree *mt, unsigned long index, unsigned long max)
{
@@ -6012,7 +6015,10 @@ EXPORT_SYMBOL_GPL(mas_prev);
* @index: The start index
* @min: The minimum index to check
*
- * Return: The entry at @index or lower, or %NULL if nothing is found.
+ * Takes RCU read lock internally to protect the search, which does not
+ * protect the returned pointer after dropping RCU read lock.
+ *
+ * Return: The entry before @index or %NULL if nothing is found.
*/
void *mt_prev(struct maple_tree *mt, unsigned long index, unsigned long min)
{
@@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
* mt_find() - Search from the start up until an entry is found.
* @mt: The maple tree
* @index: Pointer which contains the start location of the search
- * @max: The maximum value to check
+ * @max: The maximum value of the search range
+ *
+ * Takes RCU read lock internally to protect the search, which does not
+ * protect the returned pointer after dropping RCU read lock.
*
- * Handles locking. @index will be incremented to one beyond the range.
+ * In case that an entry is found @index contains the index of the found
+ * entry plus one, so it can be used as iterator index to find the next
+ * entry.
*
* Return: The entry at or after the @index or %NULL
*/
@@ -6548,7 +6559,9 @@ EXPORT_SYMBOL(mt_find);
* @index: Pointer which contains the start location of the search
* @max: The maximum value to check
*
- * Handles locking, detects wrapping on index == 0
+ * Same as mt_find() except that it checks @index for 0 before
+ * searching. If @index == 0, the search is aborted. This covers a wrap
+ * around of @index to 0 in an iterator loop.
*
* Return: The entry at or after the @index or %NULL
*/
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-05-10 19:01 [PATCH] maple_tree: Fix a few documentation issues, Thomas Gleixner
@ 2023-05-15 19:27 ` Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
0 siblings, 2 replies; 669+ messages in thread
From: Liam R. Howlett @ 2023-05-15 19:27 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
* Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
> The documentation of mt_next() claims that it starts the search at the
> provided index. That's incorrect as it starts the search after the provided
> index.
>
> The documentation of mt_find() is slightly confusing. "Handles locking" is
> not really helpful as it does not explain how the "locking" works.
More locking notes can be found in Documentation/core-api/maple_tree.rst
which lists mt_find() under the "Takes RCU read lock" list. I'm okay
with duplicating the comment of taking the RCU read lock in here.
>Also the
> documentation of index talks about a range, while in reality the index
> is updated on a succesful search to the index of the found entry plus one.
This is a range based tree, so the index is incremented beyond the last
entry which would return the entry. That is, if you search for 5 and
there is an entry at 4-100, the index would be 101 after the search -
or, one beyond the range. If you have single entries at a specific
index, then index would be equal to last and it would be one beyond the
index you found - but only because index == last in this case.
>
> Fix similar issues for mt_find_after() and mt_prev().
>
> Remove the completely confusing and pointless "Note: Will not return the
> zero entry." comment from mt_for_each() and document @__index correctly.
The zero entry concept is an advanced API concept which allows you to
store something that cannot be seen by the mt_* family of users, so it
will not be returned and, instead, it will return NULL. Think of it as
a reservation for an entry that isn't fully initialized. Perhaps it
should read "Will not return the XA_ZERO_ENTRY" ?
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> include/linux/maple_tree.h | 4 +---
> lib/maple_tree.c | 23 ++++++++++++++++++-----
> 2 files changed, 19 insertions(+), 8 deletions(-)
>
> --- a/include/linux/maple_tree.h
> +++ b/include/linux/maple_tree.h
> @@ -659,10 +659,8 @@ void *mt_next(struct maple_tree *mt, uns
> * mt_for_each - Iterate over each entry starting at index until max.
> * @__tree: The Maple Tree
> * @__entry: The current entry
> - * @__index: The index to update to track the location in the tree
> + * @__index: The index to start the search from. Subsequently used as iterator.
> * @__max: The maximum limit for @index
> - *
> - * Note: Will not return the zero entry.
This function "will not return the zero entry", meaning it will return
NULL if xa_is_zero(entry).
> */
> #define mt_for_each(__tree, __entry, __index, __max) \
> for (__entry = mt_find(__tree, &(__index), __max); \
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -5947,7 +5947,10 @@ EXPORT_SYMBOL_GPL(mas_next);
> * @index: The start index
> * @max: The maximum index to check
> *
> - * Return: The entry at @index or higher, or %NULL if nothing is found.
> + * Takes RCU read lock internally to protect the search, which does not
> + * protect the returned pointer after dropping RCU read lock.
> + *
> + * Return: The entry higher than @index or %NULL if nothing is found.
> */
> void *mt_next(struct maple_tree *mt, unsigned long index, unsigned long max)
> {
> @@ -6012,7 +6015,10 @@ EXPORT_SYMBOL_GPL(mas_prev);
> * @index: The start index
> * @min: The minimum index to check
> *
> - * Return: The entry at @index or lower, or %NULL if nothing is found.
> + * Takes RCU read lock internally to protect the search, which does not
> + * protect the returned pointer after dropping RCU read lock.
> + *
> + * Return: The entry before @index or %NULL if nothing is found.
> */
> void *mt_prev(struct maple_tree *mt, unsigned long index, unsigned long min)
> {
> @@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
> * mt_find() - Search from the start up until an entry is found.
> * @mt: The maple tree
> * @index: Pointer which contains the start location of the search
> - * @max: The maximum value to check
> + * @max: The maximum value of the search range
> + *
> + * Takes RCU read lock internally to protect the search, which does not
> + * protect the returned pointer after dropping RCU read lock.
> *
> - * Handles locking. @index will be incremented to one beyond the range.
> + * In case that an entry is found @index contains the index of the found
> + * entry plus one, so it can be used as iterator index to find the next
> + * entry.
What about:
"In case that an entry is found @index contains the last index of the
found entry plus one"
> *
> * Return: The entry at or after the @index or %NULL
> */
> @@ -6548,7 +6559,9 @@ EXPORT_SYMBOL(mt_find);
> * @index: Pointer which contains the start location of the search
> * @max: The maximum value to check
> *
> - * Handles locking, detects wrapping on index == 0
> + * Same as mt_find() except that it checks @index for 0 before
> + * searching. If @index == 0, the search is aborted. This covers a wrap
> + * around of @index to 0 in an iterator loop.
> *
> * Return: The entry at or after the @index or %NULL
> */
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-05-15 19:27 ` your mail Liam R. Howlett
@ 2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
1 sibling, 0 replies; 669+ messages in thread
From: Thomas Gleixner @ 2023-05-15 21:16 UTC (permalink / raw)
To: Liam R. Howlett; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
Liam!
On Mon, May 15 2023 at 15:27, Liam R. Howlett wrote:
> * Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
>>Also the
>> documentation of index talks about a range, while in reality the index
>> is updated on a succesful search to the index of the found entry plus one.
>
> This is a range based tree, so the index is incremented beyond the last
> entry which would return the entry. That is, if you search for 5 and
> there is an entry at 4-100, the index would be 101 after the search -
> or, one beyond the range. If you have single entries at a specific
> index, then index would be equal to last and it would be one beyond the
> index you found - but only because index == last in this case.
Thanks for the explanation
>>
>> Fix similar issues for mt_find_after() and mt_prev().
>>
>> Remove the completely confusing and pointless "Note: Will not return the
>> zero entry." comment from mt_for_each() and document @__index correctly.
>
> The zero entry concept is an advanced API concept which allows you to
> store something that cannot be seen by the mt_* family of users, so it
> will not be returned and, instead, it will return NULL. Think of it as
> a reservation for an entry that isn't fully initialized. Perhaps it
> should read "Will not return the XA_ZERO_ENTRY" ?
That makes actually sense.
>> --- a/include/linux/maple_tree.h
>> +++ b/include/linux/maple_tree.h
>> @@ -659,10 +659,8 @@ void *mt_next(struct maple_tree *mt, uns
>> * mt_for_each - Iterate over each entry starting at index until max.
>> * @__tree: The Maple Tree
>> * @__entry: The current entry
>> - * @__index: The index to update to track the location in the tree
>> + * @__index: The index to start the search from. Subsequently used as iterator.
>> * @__max: The maximum limit for @index
>> - *
>> - * Note: Will not return the zero entry.
>
> This function "will not return the zero entry", meaning it will return
> NULL if xa_is_zero(entry).
Ack.
>> + * Takes RCU read lock internally to protect the search, which does not
>> + * protect the returned pointer after dropping RCU read lock.
>> *
>> - * Handles locking. @index will be incremented to one beyond the range.
>> + * In case that an entry is found @index contains the index of the found
>> + * entry plus one, so it can be used as iterator index to find the next
>> + * entry.
>
> What about:
> "In case that an entry is found @index contains the last index of the
> found entry plus one"
Something like that, yes.
Let me try again.
Thanks,
tglx
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-05-15 19:27 ` your mail Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
@ 2023-05-16 22:47 ` Thomas Gleixner
2023-05-23 13:46 ` Liam R. Howlett
1 sibling, 1 reply; 669+ messages in thread
From: Thomas Gleixner @ 2023-05-16 22:47 UTC (permalink / raw)
To: Liam R. Howlett; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
On Mon, May 15 2023 at 15:27, Liam R. Howlett wrote:
> * Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
>> The documentation of mt_next() claims that it starts the search at the
>> provided index. That's incorrect as it starts the search after the provided
>> index.
>>
>> The documentation of mt_find() is slightly confusing. "Handles locking" is
>> not really helpful as it does not explain how the "locking" works.
>
> More locking notes can be found in Documentation/core-api/maple_tree.rst
> which lists mt_find() under the "Takes RCU read lock" list. I'm okay
> with duplicating the comment of taking the RCU read lock in here.
Without a reference to the actual locking documentation such comments
are not super helpful.
>> Fix similar issues for mt_find_after() and mt_prev().
>>
>> Remove the completely confusing and pointless "Note: Will not return the
>> zero entry." comment from mt_for_each() and document @__index correctly.
>
> The zero entry concept is an advanced API concept which allows you to
> store something that cannot be seen by the mt_* family of users, so it
> will not be returned and, instead, it will return NULL. Think of it as
> a reservation for an entry that isn't fully initialized. Perhaps it
> should read "Will not return the XA_ZERO_ENTRY" ?
>>
>> - *
>> - * Note: Will not return the zero entry.
>
> This function "will not return the zero entry", meaning it will return
> NULL if xa_is_zero(entry).
If I understand correctly, this translates to:
This iterator skips entries, which have been reserved for future use
but have not yet been fully initialized.
Right?
>> @@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
>> * mt_find() - Search from the start up until an entry is found.
>> * @mt: The maple tree
>> * @index: Pointer which contains the start location of the search
>> - * @max: The maximum value to check
>> + * @max: The maximum value of the search range
>> + *
>> + * Takes RCU read lock internally to protect the search, which does not
>> + * protect the returned pointer after dropping RCU read lock.
>> *
>> - * Handles locking. @index will be incremented to one beyond the range.
>> + * In case that an entry is found @index contains the index of the found
>> + * entry plus one, so it can be used as iterator index to find the next
>> + * entry.
>
> What about:
> "In case that an entry is found @index contains the last index of the
> found entry plus one"
Still confusing to the casual reader like me :)
"In case that an entry is found @index is updated to point to the next
possible entry independent whether the found entry is occupying a
single index or a range if indices."
Hmm?
Thanks,
tglx
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2023-05-16 22:47 ` Thomas Gleixner
@ 2023-05-23 13:46 ` Liam R. Howlett
0 siblings, 0 replies; 669+ messages in thread
From: Liam R. Howlett @ 2023-05-23 13:46 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
* Thomas Gleixner <tglx@linutronix.de> [230516 18:48]:
> On Mon, May 15 2023 at 15:27, Liam R. Howlett wrote:
> > * Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
> >> The documentation of mt_next() claims that it starts the search at the
> >> provided index. That's incorrect as it starts the search after the provided
> >> index.
> >>
> >> The documentation of mt_find() is slightly confusing. "Handles locking" is
> >> not really helpful as it does not explain how the "locking" works.
> >
> > More locking notes can be found in Documentation/core-api/maple_tree.rst
> > which lists mt_find() under the "Takes RCU read lock" list. I'm okay
> > with duplicating the comment of taking the RCU read lock in here.
>
> Without a reference to the actual locking documentation such comments
> are not super helpful.
Noted. A reference to the larger document should probably be added.
Thanks.
>
> >> Fix similar issues for mt_find_after() and mt_prev().
> >>
> >> Remove the completely confusing and pointless "Note: Will not return the
> >> zero entry." comment from mt_for_each() and document @__index correctly.
> >
> > The zero entry concept is an advanced API concept which allows you to
> > store something that cannot be seen by the mt_* family of users, so it
> > will not be returned and, instead, it will return NULL. Think of it as
> > a reservation for an entry that isn't fully initialized. Perhaps it
> > should read "Will not return the XA_ZERO_ENTRY" ?
> >>
> >> - *
> >> - * Note: Will not return the zero entry.
> >
> > This function "will not return the zero entry", meaning it will return
> > NULL if xa_is_zero(entry).
>
> If I understand correctly, this translates to:
>
> This iterator skips entries, which have been reserved for future use
> but have not yet been fully initialized.
>
> Right?
Well, that's one use of using the XA_ZERO_ENTRY, but it's really up to
the user to decide why they are adding something that returns NULL in a
specific range for the not-advanced API. It might be worth adding the
XA_ZERO_ENTRY in here, since that's the only special value right now?
>
> >> @@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
> >> * mt_find() - Search from the start up until an entry is found.
> >> * @mt: The maple tree
> >> * @index: Pointer which contains the start location of the search
> >> - * @max: The maximum value to check
> >> + * @max: The maximum value of the search range
> >> + *
> >> + * Takes RCU read lock internally to protect the search, which does not
> >> + * protect the returned pointer after dropping RCU read lock.
> >> *
> >> - * Handles locking. @index will be incremented to one beyond the range.
> >> + * In case that an entry is found @index contains the index of the found
> >> + * entry plus one, so it can be used as iterator index to find the next
> >> + * entry.
> >
> > What about:
> > "In case that an entry is found @index contains the last index of the
> > found entry plus one"
>
> Still confusing to the casual reader like me :)
>
> "In case that an entry is found @index is updated to point to the next
> possible entry independent whether the found entry is occupying a
> single index or a range if indices."
>
> Hmm?
That makes sense to me.
Thanks,
Liam
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2023-04-26 14:35 Bryan O'Donoghue
2023-04-26 20:54 ` your mail Konstantin Ryabitsev
0 siblings, 1 reply; 669+ messages in thread
From: Bryan O'Donoghue @ 2023-04-26 14:35 UTC (permalink / raw)
To: keys
[-- Attachment #2: export.asc --]
[-- Type: text/plain, Size: 3147 bytes --]
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGRJNSgBEADD7Vm2ZFa+v+JGJ2QYTJqQAkqis/uOHkhdFNXqpBarVBd47QU/
DMNU5RxgjedMQEmHoeDbJ6UOpjbrUQ63c5sgG1JbroHJJctwsEI75OOlekMuebEb
jIJBLfgENGwPBMHvpiv5TgCWr0VgYaXfp2eh2LINFywzqj823HiDPibQAXDrjzvF
1ogksi/6cQZs8d4if8YQkLOrYISFouG+eR0nN1I7mUfIddXOWu6lJeTyqbWVurv5
8k2ekIXKaOC9ixLHFbcfYV0hOgRaTwQCB8CYF9nfqZla19iItfsN9QxN+ZdQjcRo
Yipp6HPCMfJlKH7GfaFcW93LKc4DKJ2lVL+pg/OQlythZbjRPY492NG9kZ65aYst
Cs90uhMUEVVPuGUw7wBEku+6IEwZfrbMVKeWzLlPyM4Hv9hM8ktxSmxWsPTPqpBC
8eyeAQLalMELAyVcZlkaCtEcbj7w4l/JkYz+4l37obG8ZD+B34udBUUzMsAJ8foD
FrBh2MOFA3hxD6G90D23mmWsri7pnKA2tZs92aQX7Ee+FbCyg6g5ln62Sq83ZDbf
53DdBs55EVpBadeInWmXhzCHPQx06H+CwTEjShTYIaMmBfrewvYUDKvFTC5iKQhA
EUgt6i94JsbG7NoeqcxkUMcBOEUQ3uCQG1D70ugspgXc0wd3Rimiq6535wARAQAB
tC1CcnlhbiBPJ0Rvbm9naHVlIDxicnlhbi5vZG9ub2dodWVAbGluYXJvLm9yZz6J
Ak4EEwEKADgWIQTmk/sqq6Nt4Rerb7QicTuzoY3IOgUCZEk1KAIbAwULCQgHAgYV
CgkICwIEFgIDAQIeAQIXgAAKCRAicTuzoY3IOqErD/928Y+fOZDK+jZPlQ/LMuk1
PABCwq9mF/BwUMW2bNywO7YE+GaTwGbdSXWfWGj0yPu6A+eLkRAm065GuFJPT3sX
cJNqBYWyEFf3Ug5yv4ydhCDTMoeqd931QP0VZkXxF9ZIaQKZhRONNRs4rImD1/uw
mMW0wxppHjE2c8dsNV4XvLuGrQQsa0M1764wJNSQ+KoIkfAS9P2jhX6ya2k14fFc
jowpyArDvhqUt3aYCgLk1X1aaxeOUYSQ/oPnipnEzm1e8qMZK+8F4Ajx3x3iJm4C
3KsELo9tK+Y5FNHCfSobORRGw2IKo2ByG/Pi4AT/ZdYkSz420VFaLoSBt/123FU8
8wMU1op2svuTtkDos7ckhFncXfF8/UAxME2R7l5dugnoAsFKPHe4jEZ5XntV/brr
+JjOECIpOQXcDV55gZ65UYlAV7TrxeeFCVm8w3Ed9NPFC1QeUfV4P2DEIXm22if3
Yyy3+f+82syg8lIGdILxuavpF7Swhc4fa+zFYe1EoF7+HUlOBhiIXRWvlzX76VC6
IOJFbDNwQwonufHaYzn61KxNScknZcPcsBjfDVPgrNGo4HQ48C8jIXEy1TrbNaYc
gzk7uSM8Y0eXJ4FIH/PPx3UROFKYqx4LAT+63ZjDqLMQfZ5A81V8tSbJn1gQ2qil
v6XMWUzfeQc9kPKg2tRxAbkCDQRkSTUoARAAuTnmWHBS6izRcEE93ajpzI7hdgQO
4U3IRvOEsvIKR5NGcNEs0ngGebwsZ/lVULjN4vYU0LleqVhPBidNXUoZCN3A0F0Z
2Ov8NZdef+2EhQPBVWxFO7JBzhe8Z3ALj+wFtlg8akJjBzU56azW/iJzAobqHVru
dzKoO2b1/CMgVbiAQ+RXjgfN5kY/HqYDU7mw+hXuUV9PbtX1L8xqQQac95oM9rHz
KHHpiVwxTeJnGQsa+THiKze+YET3rCoGHMvOQEJhdrucTv5FpAakKdkOFNel9FFc
kLRKEuWgCzhpFsjQ7xbirQgFUxG9vlk1+q4hMRGNyEqoD6svYEeqbiUSd0oPUJei
oiC3rNMRCNHLVrfZ2J6SCPkxfda08uzSdDQU1/YPjOh8ZtQDMu7WctZ3XO288Z1g
yBR49V7fbFs2w4sQxG+h/enlxqP7fdw1mjUlZjU5huCJielS0oEaIpmUpkugli7x
4WhwLnhK2EbSoz7nLBC0y+ALUOdMlz/Y1l9xRt+bkDhpmf4O4IcIMxgZ0QMLq8rH
DkGaEbsgZZHQPS58T0XE3IP30Q9SNxsruCMXtd2hYtBssf/wohc6JVsTtMg2VYTP
DPIFNZFSXupEJB7jlqpDWJ8ooJfJRLBatbjT5+mVQaMYB7Hs/t+zWYWaJKHyc8O6
WLECNUV5Tdt5EkkAEQEAAYkCNgQYAQoAIBYhBOaT+yqro23hF6tvtCJxO7Ohjcg6
BQJkSTUoAhsMAAoJECJxO7Ohjcg6LuIQALnXt36OUuK43wqw6UYt0cnN6EbUqJHA
pAF5eNFn0jCCB2XELjSzJKJwuNAweowBdabiBniJ+501WIW+ewEsz1uby5fUQjZu
CEsIkuaIluyfUFPb73qrQyAGuusd7teA4WT+/jUku9g7lX5sVoRCrKQPkd16f6Bz
fztyqyjcn43/X5yQI+wlboQ6HuKe/3I3yiOxOgmCHzOawpC9PvhEcKj79RLM3Zz5
Ts5AuHpRX70Jz8Be76LwVFLp5Msx3S24ZTU1lBo2uiJ3xSkay2lTpyVWRPx9vgcw
zxGguOPJQJwsQeLb7wpoJMPpD3ERoaRii7Q7hvmxklpZjhKYWB3dt6nQ497Ek9lo
Crp3MIjRCSDN5xEGffiHks9yTeGMUQwO4tX8RE04uOJPkUY7uCFzFqN6/qeyX3oF
fPgkULMdiHofPAL1OskZSTzGPSfTYRE46NCJw8yoZBQ/oOyWeqaUQbK0wmW/g81w
m8p7LKSGEglMpiX07M1AotgvylN5C8fjbouoK+/RAMsXkk8jba6rPfuuXPaDjCyy
Kn6zSVHETnHW3AJbgVY50T8STpnxayBQvWbCvu+6NOEjXCbyaOJig+5l0zlGN9XH
jdANXC5HnwmyaGRL9YDqJh2nVXVJDincOdQRdKcJjYLqaOAoWrYWSDi1iZGspHBT
DrnOvfMQzzHY
=xAxf
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-04-26 14:35 Bryan O'Donoghue
@ 2023-04-26 20:54 ` Konstantin Ryabitsev
0 siblings, 0 replies; 669+ messages in thread
From: Konstantin Ryabitsev @ 2023-04-26 20:54 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: keys
On Wed, Apr 26, 2023 at 03:35:10PM +0100, Bryan O'Donoghue wrote:
> -----BEGIN PGP PUBLIC KEY BLOCK-----
Hello:
There are no signatures on this key that we recognize, so we cannot include it
into the kernel.org keyring. Please get at least 2 signatures from someone who
is already in the keyring (or has a kernel.org account) and resubmit.
-K
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2023-03-17 16:36 Sumitra Sharma
2023-03-17 16:47 ` your mail Julia Lawall
0 siblings, 1 reply; 669+ messages in thread
From: Sumitra Sharma @ 2023-03-17 16:36 UTC (permalink / raw)
To: Bagas Sanjaya; +Cc: Linux Outreachy, julia.lawall
, fmdefrancesco@gmail.com
Bcc:
Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
Reply-To:
In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> On 3/14/23 19:33, Sumitra Sharma wrote:
> >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> >> (which contains instructions on spinning up Ubuntu VM), so you need to
> >> install your tools (including postfix and mutt) there if you want to
> >> contribute through there. So I think the latter doc should be kept as
> >> is.
> >>
> >
> > Hi
> >
> > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > it.
> >
>
> For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
>
> Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> for now. (But I wish the slug could be better named as LinuxVMSetup).
>
Hi,
Since we discussed all about the outreachyfirstpatchalt only and you
also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
- Open the ~/.muttrc
- Add the information
set sendmail="/usr/bin/esmtp"
set envelope_from=yes
set from="Your Name <my.email@gmail.com>"
set use_from=yes
set edit_headers=yes
# IMAP settings
set imap_user = "username@gmail.com"
set imap_pass = "<mailbox password>"
# SMTP settings
set smtp_url = "smtps://username@smtp.gmail.com"
set smtp_pass = "<mailbox password>"
# Remote Gmail folders
set folder = "imaps://imap.gmail.com/"
set spoolfile = "+INBOX"
set postponed = "+[Gmail]/Drafts"
set record = "+[Gmail]/Sent Mail"
set trash = "+[Gmail]/Trash"
- Where the imap_pass, smtp_pass would be the App password or
the mailbox password.
Regards,
Sumitra
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-17 16:36 Sumitra Sharma
@ 2023-03-17 16:47 ` Julia Lawall
2023-03-17 18:17 ` Sumitra Sharma
2023-03-19 8:09 ` Sumitra Sharma
0 siblings, 2 replies; 669+ messages in thread
From: Julia Lawall @ 2023-03-17 16:47 UTC (permalink / raw)
To: Sumitra Sharma; +Cc: Bagas Sanjaya, Linux Outreachy
On Fri, 17 Mar 2023, Sumitra Sharma wrote:
> , fmdefrancesco@gmail.com
> Bcc:
> Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> Reply-To:
> In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
>
> On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > On 3/14/23 19:33, Sumitra Sharma wrote:
> > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > >> install your tools (including postfix and mutt) there if you want to
> > >> contribute through there. So I think the latter doc should be kept as
> > >> is.
> > >>
> > >
> > > Hi
> > >
> > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > it.
> > >
> >
> > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> >
> > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > for now. (But I wish the slug could be better named as LinuxVMSetup).
> >
>
> Hi,
>
> Since we discussed all about the outreachyfirstpatchalt only and you
> also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
called Set up email. This is followed by some sections related to gmail,
yahoo, etc. So you could find the best place around there for the new
information.
It could be nice to use some subsections, so that one can easily identify
the complete section about email.
I notice also that there seems to be randomly "set up" and "setup". I
have the impression that "set up" is a verb and "setup" is a noun., so it
should be "Set up vim as your default editor" (not Setup...) and it should
be "Gmail setup" (not Gmail set up).
thanks,
julia
>
> 1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
>
> - Open the ~/.muttrc
> - Add the information
>
> set sendmail="/usr/bin/esmtp"
> set envelope_from=yes
> set from="Your Name <my.email@gmail.com>"
> set use_from=yes
> set edit_headers=yes
>
> # IMAP settings
> set imap_user = "username@gmail.com"
> set imap_pass = "<mailbox password>"
>
> # SMTP settings
> set smtp_url = "smtps://username@smtp.gmail.com"
> set smtp_pass = "<mailbox password>"
>
> # Remote Gmail folders
> set folder = "imaps://imap.gmail.com/"
> set spoolfile = "+INBOX"
> set postponed = "+[Gmail]/Drafts"
> set record = "+[Gmail]/Sent Mail"
> set trash = "+[Gmail]/Trash"
>
> - Where the imap_pass, smtp_pass would be the App password or
> the mailbox password.
>
>
> Regards,
>
> Sumitra
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-17 16:47 ` your mail Julia Lawall
@ 2023-03-17 18:17 ` Sumitra Sharma
2023-03-19 8:09 ` Sumitra Sharma
1 sibling, 0 replies; 669+ messages in thread
From: Sumitra Sharma @ 2023-03-17 18:17 UTC (permalink / raw)
To: Julia Lawall; +Cc: Bagas Sanjaya, Linux Outreachy
On Fri, Mar 17, 2023 at 05:47:23PM +0100, Julia Lawall wrote:
>
>
> On Fri, 17 Mar 2023, Sumitra Sharma wrote:
>
> > , fmdefrancesco@gmail.com
> > Bcc:
> > Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> > Reply-To:
> > In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
> >
> > On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > > On 3/14/23 19:33, Sumitra Sharma wrote:
> > > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > > >> install your tools (including postfix and mutt) there if you want to
> > > >> contribute through there. So I think the latter doc should be kept as
> > > >> is.
> > > >>
> > > >
> > > > Hi
> > > >
> > > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > > it.
> > > >
> > >
> > > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> > >
> > > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > > for now. (But I wish the slug could be better named as LinuxVMSetup).
> > >
> >
> > Hi,
> >
> > Since we discussed all about the outreachyfirstpatchalt only and you
> > also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
>
> In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
> called Set up email. This is followed by some sections related to gmail,
> yahoo, etc. So you could find the best place around there for the new
> information.
>
> It could be nice to use some subsections, so that one can easily identify
> the complete section about email.
>
Actually, the only issue I faced was that the outreachyfirstpatch
document do not contain the informatio of how to set your inbox in mutt.
Due to which I was facing issues to send and reply mails. This below
configuration update will enable the inbox at the client side.
How about this...
Under the section "Configure esmtp":
###
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
Note: The imap_pass, smtp_pass would be the App password or
the mailbox password.
set sendmail="/usr/bin/esmtp"
set envelope_from=yes
set from="Your Name <my.email@gmail.com>"
set use_from=yes
set edit_headers=yes
# IMAP settings
set imap_user = "username@gmail.com"
set imap_pass = "<mailbox password>"
# SMTP settings
set smtp_url = "smtps://username@smtp.gmail.com"
set smtp_pass = "<mailbox password>"
# Remote Gmail folders
set folder = "imaps://imap.gmail.com/"
set spoolfile = "+INBOX"
set postponed = "+[Gmail]/Drafts"
set record = "+[Gmail]/Sent Mail"
set trash = "+[Gmail]/Trash"
###
> I notice also that there seems to be randomly "set up" and "setup". I
> have the impression that "set up" is a verb and "setup" is a noun., so it
> should be "Set up vim as your default editor" (not Setup...) and it should
> be "Gmail setup" (not Gmail set up).
>
Okay! I will take care of it. Thank you.
Regards,
Sumitra
> thanks,
> julia
>
> >
> > 1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
> >
> > - Open the ~/.muttrc
> > - Add the information
> >
> > set sendmail="/usr/bin/esmtp"
> > set envelope_from=yes
> > set from="Your Name <my.email@gmail.com>"
> > set use_from=yes
> > set edit_headers=yes
> >
> > # IMAP settings
> > set imap_user = "username@gmail.com"
> > set imap_pass = "<mailbox password>"
> >
> > # SMTP settings
> > set smtp_url = "smtps://username@smtp.gmail.com"
> > set smtp_pass = "<mailbox password>"
> >
> > # Remote Gmail folders
> > set folder = "imaps://imap.gmail.com/"
> > set spoolfile = "+INBOX"
> > set postponed = "+[Gmail]/Drafts"
> > set record = "+[Gmail]/Sent Mail"
> > set trash = "+[Gmail]/Trash"
> >
> > - Where the imap_pass, smtp_pass would be the App password or
> > the mailbox password.
> >
> >
> > Regards,
> >
> > Sumitra
> >
> >
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-17 16:47 ` your mail Julia Lawall
2023-03-17 18:17 ` Sumitra Sharma
@ 2023-03-19 8:09 ` Sumitra Sharma
2023-03-19 8:35 ` Julia Lawall
1 sibling, 1 reply; 669+ messages in thread
From: Sumitra Sharma @ 2023-03-19 8:09 UTC (permalink / raw)
To: sumitraartsy, bagasdotme, julia.lawall, outreachy
On Fri, Mar 17, 2023 at 05:47:23PM +0100, Julia Lawall wrote:
>
>
> On Fri, 17 Mar 2023, Sumitra Sharma wrote:
>
> > , fmdefrancesco@gmail.com
> > Bcc:
> > Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> > Reply-To:
> > In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
> >
> > On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > > On 3/14/23 19:33, Sumitra Sharma wrote:
> > > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > > >> install your tools (including postfix and mutt) there if you want to
> > > >> contribute through there. So I think the latter doc should be kept as
> > > >> is.
> > > >>
> > > >
> > > > Hi
> > > >
> > > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > > it.
> > > >
> > >
> > > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> > >
> > > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > > for now. (But I wish the slug could be better named as LinuxVMSetup).
> > >
> >
> > Hi,
> >
> > Since we discussed all about the outreachyfirstpatchalt only and you
> > also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
>
> In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
> called Set up email. This is followed by some sections related to gmail,
> yahoo, etc. So you could find the best place around there for the new
> information.
>
> It could be nice to use some subsections, so that one can easily identify
> the complete section about email.
>
Actually, the only issue I faced was that the outreachyfirstpatch
document does not contain the information of how one can set their inbox in mutt.
Due to which I had problems to send and reply mails. This below
configuration update will enable the inbox at the client side.
How about this...
Under the section "Configure esmtp":
###
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
Note: The imap_pass, smtp_pass would be the App password or
the mailbox password.
set sendmail="/usr/bin/esmtp"
set envelope_from=yes
set from="Your Name <my.email@gmail.com>"
set use_from=yes
set edit_headers=yes
# IMAP settings
set imap_user = "username@gmail.com"
set imap_pass = "<mailbox password>"
# SMTP settings
set smtp_url = "smtps://username@smtp.gmail.com"
set smtp_pass = "<mailbox password>"
# Remote Gmail folders
set folder = "imaps://imap.gmail.com/"
set spoolfile = "+INBOX"
set postponed = "+[Gmail]/Drafts"
set record = "+[Gmail]/Sent Mail"
set trash = "+[Gmail]/Trash"
###
> I notice also that there seems to be randomly "set up" and "setup". I
> have the impression that "set up" is a verb and "setup" is a noun., so it
> should be "Set up vim as your default editor" (not Setup...) and it should
> be "Gmail setup" (not Gmail set up).
>
Okay! I will take care of it. Thank you.
In addition to this, I would like to bring to your notice that a hyperlink
in outrachyfirstpatch document, under the section "Git post-commit
hooks" does not work and it must be changed.
under Git post-commit hooks; checkpatch.pl:
http://lxr.free-electrons.com/source/scripts/checkpatch.pl
------------------------------------------------------------------
https://elixir.bootlin.com/linux/latest/source/scripts/checkpatch.pl
Regards,
Sumitra
> thanks,
> julia
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-19 8:09 ` Sumitra Sharma
@ 2023-03-19 8:35 ` Julia Lawall
2023-03-19 8:56 ` Sumitra Sharma
0 siblings, 1 reply; 669+ messages in thread
From: Julia Lawall @ 2023-03-19 8:35 UTC (permalink / raw)
To: Sumitra Sharma; +Cc: bagasdotme, outreachy
> Actually, the only issue I faced was that the outreachyfirstpatch
> document does not contain the information of how one can set their inbox in mutt.
> Due to which I had problems to send and reply mails. This below
> configuration update will enable the inbox at the client side.
>
> How about this...
>
> Under the section "Configure esmtp":
>
> ###
> Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
>
> Note: The imap_pass, smtp_pass would be the App password or
> the mailbox password.
>
> set sendmail="/usr/bin/esmtp"
> set envelope_from=yes
> set from="Your Name <my.email@gmail.com>"
> set use_from=yes
> set edit_headers=yes
>
> # IMAP settings
> set imap_user = "username@gmail.com"
> set imap_pass = "<mailbox password>"
>
> # SMTP settings
> set smtp_url = "smtps://username@smtp.gmail.com"
> set smtp_pass = "<mailbox password>"
>
> # Remote Gmail folders
> set folder = "imaps://imap.gmail.com/"
> set spoolfile = "+INBOX"
> set postponed = "+[Gmail]/Drafts"
> set record = "+[Gmail]/Sent Mail"
> set trash = "+[Gmail]/Trash"
> ###
Does this have anything to do with esmpt?
Does "<mailbox password>" mean that you have to put your password in plain
text?
julia
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-19 8:35 ` Julia Lawall
@ 2023-03-19 8:56 ` Sumitra Sharma
2023-03-19 9:02 ` Julia Lawall
0 siblings, 1 reply; 669+ messages in thread
From: Sumitra Sharma @ 2023-03-19 8:56 UTC (permalink / raw)
To: Julia Lawall; +Cc: bagasdotme, outreachy
On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > Actually, the only issue I faced was that the outreachyfirstpatch
> > document does not contain the information of how one can set their inbox in mutt.
> > Due to which I had problems to send and reply mails. This below
> > configuration update will enable the inbox at the client side.
> >
> > How about this...
> >
> > Under the section "Configure esmtp":
> >
> > ###
> > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> >
> > Note: The imap_pass, smtp_pass would be the App password or
> > the mailbox password.
> >
> > set sendmail="/usr/bin/esmtp"
> > set envelope_from=yes
> > set from="Your Name <my.email@gmail.com>"
> > set use_from=yes
> > set edit_headers=yes
> >
> > # IMAP settings
> > set imap_user = "username@gmail.com"
> > set imap_pass = "<mailbox password>"
> >
> > # SMTP settings
> > set smtp_url = "smtps://username@smtp.gmail.com"
> > set smtp_pass = "<mailbox password>"
> >
> > # Remote Gmail folders
> > set folder = "imaps://imap.gmail.com/"
> > set spoolfile = "+INBOX"
> > set postponed = "+[Gmail]/Drafts"
> > set record = "+[Gmail]/Sent Mail"
> > set trash = "+[Gmail]/Trash"
> > ###
>
> Does this have anything to do with esmpt?
>
In the current version of the outreachy firstpatch document the configuration
steps for .esmtp and .muttrc are written under the heading
"Configure esmtp" and also to configure esmtp we are creating the muttrc
file. So, both are linked in a way.
> Does "<mailbox password>" mean that you have to put your password in plain
> text?
>
Yes, but it is always prefered to use the app password for better security.
Regards,
Sumitra
> julia
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-19 8:56 ` Sumitra Sharma
@ 2023-03-19 9:02 ` Julia Lawall
2023-03-19 9:53 ` Sumitra Sharma
0 siblings, 1 reply; 669+ messages in thread
From: Julia Lawall @ 2023-03-19 9:02 UTC (permalink / raw)
To: Sumitra Sharma; +Cc: bagasdotme, outreachy
On Sun, 19 Mar 2023, Sumitra Sharma wrote:
> On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > > Actually, the only issue I faced was that the outreachyfirstpatch
> > > document does not contain the information of how one can set their inbox in mutt.
> > > Due to which I had problems to send and reply mails. This below
> > > configuration update will enable the inbox at the client side.
> > >
> > > How about this...
> > >
> > > Under the section "Configure esmtp":
> > >
> > > ###
> > > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> > >
> > > Note: The imap_pass, smtp_pass would be the App password or
> > > the mailbox password.
> > >
> > > set sendmail="/usr/bin/esmtp"
> > > set envelope_from=yes
> > > set from="Your Name <my.email@gmail.com>"
> > > set use_from=yes
> > > set edit_headers=yes
> > >
> > > # IMAP settings
> > > set imap_user = "username@gmail.com"
> > > set imap_pass = "<mailbox password>"
> > >
> > > # SMTP settings
> > > set smtp_url = "smtps://username@smtp.gmail.com"
> > > set smtp_pass = "<mailbox password>"
> > >
> > > # Remote Gmail folders
> > > set folder = "imaps://imap.gmail.com/"
> > > set spoolfile = "+INBOX"
> > > set postponed = "+[Gmail]/Drafts"
> > > set record = "+[Gmail]/Sent Mail"
> > > set trash = "+[Gmail]/Trash"
> > > ###
> >
> > Does this have anything to do with esmpt?
> >
>
> In the current version of the outreachy firstpatch document the configuration
> steps for .esmtp and .muttrc are written under the heading
> "Configure esmtp" and also to configure esmtp we are creating the muttrc
> file. So, both are linked in a way.
I don't think so. Comfiguring esmtp requires adding some information to
the .muttrc, but people who don't want to configure esmtp may also want to
add information to the .muttrc.
>
> > Does "<mailbox password>" mean that you have to put your password in plain
> > text?
> >
>
> Yes, but it is always prefered to use the app password for better security.
The existing text about sending mesages with mutt says:
identity "my.email@gmail.com"
hostname smtp.gmail.com:587
username "my.email@gmail.com"
password "ThisIsNotARealPassWord"
starttls required
Why not put "ThisIsNotARealPassWord" in your text as well, if that is
what you expect people to do?
That is, when you put something in quotes, the reader doedn't know whether
they are supposed to put exactly the thing that you have put in the quotes
or something else. I guess that for eg "smtps://username@smtp.gmail.com"
they should fill in their real username. But for "<mailbox password>" it
is not clear what is expected.
julia
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2023-03-19 9:02 ` Julia Lawall
@ 2023-03-19 9:53 ` Sumitra Sharma
0 siblings, 0 replies; 669+ messages in thread
From: Sumitra Sharma @ 2023-03-19 9:53 UTC (permalink / raw)
To: Julia Lawall; +Cc: bagasdotme, outreachy
On Sun, Mar 19, 2023 at 10:02:46AM +0100, Julia Lawall wrote:
>
>
> On Sun, 19 Mar 2023, Sumitra Sharma wrote:
>
> > On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > > > Actually, the only issue I faced was that the outreachyfirstpatch
> > > > document does not contain the information of how one can set their inbox in mutt.
> > > > Due to which I had problems to send and reply mails. This below
> > > > configuration update will enable the inbox at the client side.
> > > >
> > > > How about this...
> > > >
> > > > Under the section "Configure esmtp":
> > > >
> > > > ###
> > > > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> > > >
> > > > Note: The imap_pass, smtp_pass would be the App password or
> > > > the mailbox password.
> > > >
> > > > set sendmail="/usr/bin/esmtp"
> > > > set envelope_from=yes
> > > > set from="Your Name <my.email@gmail.com>"
> > > > set use_from=yes
> > > > set edit_headers=yes
> > > >
> > > > # IMAP settings
> > > > set imap_user = "username@gmail.com"
> > > > set imap_pass = "<mailbox password>"
> > > >
> > > > # SMTP settings
> > > > set smtp_url = "smtps://username@smtp.gmail.com"
> > > > set smtp_pass = "<mailbox password>"
> > > >
> > > > # Remote Gmail folders
> > > > set folder = "imaps://imap.gmail.com/"
> > > > set spoolfile = "+INBOX"
> > > > set postponed = "+[Gmail]/Drafts"
> > > > set record = "+[Gmail]/Sent Mail"
> > > > set trash = "+[Gmail]/Trash"
> > > > ###
> > >
> > > Does this have anything to do with esmpt?
> > >
> >
> > In the current version of the outreachy firstpatch document the configuration
> > steps for .esmtp and .muttrc are written under the heading
> > "Configure esmtp" and also to configure esmtp we are creating the muttrc
> > file. So, both are linked in a way.
>
> I don't think so. Comfiguring esmtp requires adding some information to
> the .muttrc, but people who don't want to configure esmtp may also want to
> add information to the .muttrc.
>
Then, why dont we rename the section as "Configure MTA"
then it will go as follows:
> >
> > > Does "<mailbox password>" mean that you have to put your password in plain
> > > text?
> > >
> >
> > Yes, but it is always prefered to use the app password for better security.
>
> The existing text about sending mesages with mutt says:
>
> identity "my.email@gmail.com"
> hostname smtp.gmail.com:587
> username "my.email@gmail.com"
> password "ThisIsNotARealPassWord"
> starttls required
>
> Why not put "ThisIsNotARealPassWord" in your text as well, if that is
> what you expect people to do?
>
> That is, when you put something in quotes, the reader doedn't know whether
> they are supposed to put exactly the thing that you have put in the quotes
> or something else. I guess that for eg "smtps://username@smtp.gmail.com"
> they should fill in their real username. But for "<mailbox password>" it
> is not clear what is expected.
>
###
Configure MTA
Note: These instructions assume you're using esmtp, but if you already have another mail transfer agent (MTA) installed, you do not need to install esmtp. Instead, change the .muttrc file "sendmail" line to be the path to your MTA. Mutt uses ssmtp by default, so if your MTA is ssmtp, you can leave that line out entirely.
First, create a .esmtprc file with the right permissions:
touch ~/.esmtprc
chmod g-rwx ~/.esmtprc
chmod o-rwx ~/.esmtprc
Edit the .esmtprc in your home directory, and add lines like this:
identity "my.email@gmail.com"
hostname smtp.gmail.com:587
username "my.email@gmail.com"
password "ThisIsNotARealPassWord"
starttls required
(For Yahoo mail, replace hostname line with:
hostname smtp.mail.yahoo.com:587
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
Note: The imap_pass, smtp_pass would be the App password or the mailbox password.
set sendmail="/usr/bin/esmtp"
set envelope_from=yes
set from="Your Name <my.email@gmail.com>"
set use_from=yes
set edit_headers=yes
# IMAP settings
set imap_user = "username@gmail.com"
set imap_pass = "<ThisIsNotARealPassWord>"
# SMTP settings
set smtp_url = "smtps://username@smtp.gmail.com"
set smtp_pass = "<ThisIsNotARealPassWord>"
# Remote Gmail folders
set folder = "imaps://imap.gmail.com/"
set spoolfile = "+INBOX"
set postponed = "+[Gmail]/Drafts"
set record = "+[Gmail]/Sent Mail"
set trash = "+[Gmail]/Trash"
###
Regards,
Sumitra
> julia
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2022-02-03 13:41 Harald Hoyer
2022-02-03 14:18 ` your mail Konstantin Ryabitsev
0 siblings, 1 reply; 669+ messages in thread
From: Harald Hoyer @ 2022-02-03 13:41 UTC (permalink / raw)
To: keys
[-- Attachment #2: tt.asc --]
[-- Type: text/plain, Size: 37832 bytes --]
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF586L8BEADxCazcu1Aetijsryp7+BDHMe2CipKcLk9h/DGxW1Bu+jLxJkDN
PPIS5v8AZbQbRzqfaiK0rnpxuhk4iEAKQUxuh6wzgzqshMgB2n+wqobpYqtSn6Um
WQHqspydRj5w1rxV5ikxL/3MCAhZ/FAz6pMgH1j1mtzth1mdb9yyVTEFSLslapCf
bCXVlKSZeH8Hb3t3nL3Uzv925+MkIsq8qrNxe6HUiscm0aKm3jTCACfsqSo33q/W
TSrrDGeNvr9Ke9kJJczVb4pr66M0KVEGSz5aoFGZxAKHMXNJUu/f0H3s8RBXMQ/M
bcwngNpc1f4RVnO2zeCz/GeSwf+00nouD/xjuy2SlpUPMhs4Qp8r7/Vgi2kaO095
SOKc/hCoKspFY0vX3KVsHVIxyPMFTik4dmatQo4cJy4FW/dp3/2kyXf1HAnf0ZnK
2q8/iebylYxVio5X9UQ4hKIWgLUHu29crr515VPfGIidP+KNq6Lq49WAKPyVH1ex
hJSBoRiiSrNpAmYCubvHzZsIbC9UTCl2my1JahnHnSM4u18qwFki1n1Dj0BXof/Q
FjNIJEjN7b5hMaT0/+kIQN4kbMUhN+xR8HqGkQHrYC312ezKL+J7wI3+mIVSlr6I
88n6N8ZDNOPNHAUFBi9/7KiLGFdydAZT/l4gBvop/DTAzmPL9+RfxP3jNwARAQAB
tB9IYXJhbGQgSG95ZXIgPGhhcmFsZEBob3llci54eXo+iQJMBBMBCAA2AhsDAhkB
FiEEfz1kgkrAtrgAnlBQS8CJb7VpNZUFAmH6XXwFCwcJAwIFFQgKAgMDFgECAh4E
AAoJEEvAiW+1aTWV8k0P/A4Y98zzrTdPXBGONyFb3meoDoMihjwhqBXNLqROyk+1
2sI8F+3EVVhYtadZNzw4qMnwm0l6tzAPglJybO9BlcopP2JdQg866P2JftuhxYWO
1y+llDWhrKjj10huOYjLlSFzE58nI0f5cA6QmDsy6xqocum+8FfGnU1eMZkmoxCc
SgsSDtmafjpEehNI6B3L+aZ41HvOyzu9brSqZDvAZ6eDohJ9XrdZddYgXC5jLIyi
hbThAJcTGvJjyNQDR5ydkZh+G3xXc0PZhy+MEyOlQiOPg38R6vkvOZteqgU/0tGj
/fsRYYdb1nOQprnHtjVrc4aVDotC2ZnFCzE5c9bK1cwHK577XBDLfcEIZEWcyT8j
0ztDJ4hS0uHNpyrnfjsgCfkzDGWjMdyRxQ9yNzZHGEo1NAscFtYPYJ4jlswsw905
tUxBkYfDndEUBTdQKdd/k2Oke8LK74pYofXWi+dqh31J4GnIBqdVYKyuHHMpBwik
N5QEKdI0R/vqpqZf/MPUni2RjvlpdzFGL+pI34eu/ImwpdEj5LU1EibGn7CoQLvL
X+flS+dpRPis5v6BeWoAlzFSxFjf7F+GlcB+I5iQcVR9y2QQ53AXKcF7YSiTHnY0
HsTOmq5MGCYcZFE2FoOI2PX+0ka0GMNjpu+EW17LBylkK7loW2VQE9V1mKra+fyI
iQI2BBABCAAgFiEEW5+gspNca+hkAihzqcF2zH+sfVYFAl58+1cCBwAACgkQqcF2
zH+sfVacLg//azmTwc0dwmILhl+WDDTJAOsjm9ModTBY6xcphOt0qHPJ4lHW732i
l6nSVSB439EDEYzuocOn6BFeibvMVsLbGKepehtvJNTBnPBapAiBVpaJ1oVsE7Ow
+8T3saVH2bJgbIS+PVjYy+eN0ssMKxThJhhweIlYgt+z86GpmjkQTQMdklnfisgQ
wyh4RG7vSbAj+ZjcsmG/F7cyP54fqFT+0d4YghxpuLODENmJgUgzIM0sk6aGjH6K
yZWuQ7MqAQpYyMgAVNouQ52xI99Vq4GO6AD1thdrwf5aQ73/O6/QRo8jpZDNHAlO
ZynX1L2dCUPrWkvkIPEMYfNNbTna/+DII7k7A6rHt252019MmntSleDL/R018dDP
eP49sVoiasykOgzRgvq5Cq6K+QbV4VR/0MnXmoZ0M/Fl831jjZpb3RxmP0uqsheh
BIGIzkhSmNyTtZCLMNFy9iC1QrSkT+D+FfQvPhPdi523S86F2VaU6i6YcP/6cG66
oKTEwKI/xY+8qKAi7ifSc/gqg+Jg922RIZln4Fihoas66/7LJZP5sqqocI6ansgb
7OE+SSuFXAxC963HdcJMMFhOpgrmA2ImikV5QDkGcG6n/FJIamdq/zSvSRAz4TZW
81bNbO6elS4cF+gIHw+3eznK/lBIjXhKFkfz3SYNsVyiDU9hYL/A/keJAjMEEAEI
AB0WIQS+X7yMnByfYKTwrq56TzoJ697/JgUCXnz6gQAKCRB6TzoJ697/JmBzD/96
yUtB7NOmhAxuuHi3auZ+hjemGmJRP7c02TqUJ+rZiRbIhAckQepmv6DdEM11RQRa
lSfTugqvEzy13SWddFE540TNWzkrEkExKv5hUTKER3cazIjjrIC50/AXfYVxhdcM
0ZXbfTeqFWrQX6BkIPE8vkFNIh9b8Y1kH3RolvMSHlWpcZ2j3HlDmQEy0+KEjLkF
M8wU9vf3oYXCQBAgw3qE1gudv/1G9c7TJ01piO0jhoF55zNV6KnsB39dSHQB3Mzd
uc2WeVkC9fxNb+TSdc7TUre0IAtWQAMdiHmHXZKWO6/SIhXP17+FqJwLnXPuS28F
DIMGL9Hq0MciOhDd/izdE684lkHjtMQYVMAnRuKHGhL7Mad3NQr66sBoW3jB4e+/
DK3IHC35T2+gsSukN7OhOuhLcW2cJqeF9iUBNcpzc5iHbpUN062WipPC4v/QkI0y
1b4e1ziTGBVAUZAGs0lcCYYodzYC7qsRHVOcrbyzuultAtGDaDQRzziQm0p/zmMa
SCuYR0GFtSszejx35bMzkkA1qh+U5pPzeIyENq78Ps05R+2XeXT8GFv2IE8D6fPX
0CvtAi4d0gpVPDFK9kviNJWX6cwxAKhaGOAnXJj3D0JB2WrwWrU0Fg6Qxv1cJEqB
Y/LErX4YICQO71v/8lw4QM07+Uo476SRUjbFD5qeeYkCMwQQAQgAHRYhBFwlG1/F
TrL4D0B6qsVMozbP61V+BQJefQNrAAoJEMVMozbP61V+r+UP/1ZyQPD2re2xjv0k
UkJG6uprrmxWdsnXe3lyKkO1mYyoazio/0FbLi4ROxg7eBv+TYRajFlKhUx5h2HR
iPgP2u/3Q/toO8lAWJsGDD8UV3QOdwsKHmuAFCCIeBSe5NnoyNX0wf9PGJWvl+LS
1VmkAFdITDvBy388KS0i27UkYIXjkvwPeV1TSdUGs2852cvRp5BOAy2cGXLKSo7D
qXrd6DdcQ6LXJZVDxJvWeWR7UUQfcKPIsABPFz27iIbm6b8PgYI4s17S51wyu0Mi
A4fiEFOuXtw9jOygzGEaqqu3G+NgcMu/67itoXRryyLzItToAzVyNxERDWk4yCii
DZKnO4qe96pDGGZuVrDIMqM1wlysL+gFwlkoG/2IuOcYVC+wHIKOI3ktuhNrFS9C
APGnzbWXtSFiKuYXTv5S9cuTBvDLiVrNxuS1K0th26fXRDdTwo5FMI+za/6g1e+Q
pmz5JMIAlKO3i+Xa9biqbv6VclhisCUiQjY+90dfYXXBD9vBdhu9p1T2pQvEttJz
DDf5OKgAC/TssOyXyJ7Q2LGloX+E5FmUz41tWcfxxgM1NH9BNEf+hdM6dh+z63GE
XOuGC94HEP8cKx/OnUxUJXu0v8p83I3zP7vqsmCqwhYcPiYaHIAtAx8ZLqLNCCkh
9kT+DRGXgKfcS2DLlerisz1TRZUqiQIzBBABCAAdFiEEZH8oZUiU471FcZm+ONu9
yGCSaT4FAl597BkACgkQONu9yGCSaT5Eog/+KVjQuwj5mPmXbQkba1UMqYjRhH+5
VMwy6ir2FqSwXPZEoCKWL9XSeRHkWr8XbbWUp5lJj8fs8PzhFUkYYDPZgcb7om+R
0+E/tRUlGLzR2xTBDd1x/cojPaNJzgKZASexuMqCyofR69sIJlaLa50ps7D48onZ
ymqty0QRclYfTBKcvt56w4sOxiHhKc6dJf0T8eNnM9T918BJC4m7DFAvl9g9pxtY
RRM+fBbx8cZwfdGf5N+XnacMVzUpsbDGjyfzIkzQIsGCT0Yj2pE5DQZE4lniyvk9
zmQhzIYbTiuHw6lufBIwIV75en/Mc/ua19Sfj4t6H8zoaW8aeb8+/vN0UCWQb5Gz
7Xpkv41hgMSv1O7VSWDccecfra5kEKO4ONEKQvNrKpP3zdwRJn8ywM/AdeqhO788
4CYuXlw9mXdoUroW1vsO1h3ulFNz9Zf6OLM+7zxr1rgxHZZL9M6brZXaKUTFD+40
Enp4ZJg+ky7pYgqEM8tSdlG7osGiHr9VCGrMpQJZfz++oXS7fJCjCZ+HdnSK/Yj9
FCOpgqccRt5DV9UC9m5WOG6aPyaq+yTAK/Gw9b1jSgEac+1tCLOPsv3kFPnBQz5w
RLTwcsVTXWMct6ZGilmVU1ru4DMQJ9ydP6Xkivz0X11NPFSqdX7ankoeTWWft4hC
gSZKuIpJhoDgXgGJAjMEEAEIAB0WIQRMluFQD5QhzPgtXcoDTrNwAU3ycAUCXoH2
ZwAKCRADTrNwAU3ycK1eD/9+nJktmWbzfLir1EtmbGhu4bMButQYqQAJZfwSG2DN
YauS8FqpQpAZY46buWDPRhbpGXmTmWCvUkZuQsIHfXdaUaoe5a9OiRGwj/k+WvmC
Tx6yylMHLuus7znnjJLiC4By3OXa/+CDzadvbuhAgDQ6XPzmiE/v/bxAJxHPeq8I
8pW46b4LO3Y2NaIt1cnoknI7tenCx3d5XvEPGEmhtrWF1wYccUA1yEdoWRysQLPm
Cfn4QOOU9EivifylqHfUnQHq0M25v548OtfE19T3da6AfE+G5kx3XPg+n7d5mkeC
oCKN2wKyDhKd1ytXF2hll1J2BUrcN+8z7jDgHs6jGxtMb3GtSLaNFn5C9MH3gqj+
M7DYps4MK8nfP9mQN+FbLyPBQaIXLKqvGbEeqbNJqmi2Mlj5QIp9IiuoWBvgq5Pi
K8GWdKb7dmLTGU1Hk34t77R3w3NgE7tdFHd+RsfdfcxUx3ezdbv6Y+smOG1lYEtl
pX+EchA1/NttdzSfLee+q3XMsrGUm8bQEFVaCsfjl3uRtOpU+g8pmcLwGVdC7qoB
YxFKTDOPELhpEmMkDapzC7bseEHXvvDHojbkK5TAHZARImKPs6/SsaxdWBUzkpI7
JmYW8BYh7dv3tG+9GJXBvcKr5Q8szmXnpuzITJQfwBN8Oxwv9TMKFbjDC2FktBic
qIkCTgQTAQgAOBYhBH89ZIJKwLa4AJ5QUEvAiW+1aTWVBQJefOi/AhsDBQsJCAcC
BhUKCQgLAgQWAgMBAh4BAheAAAoJEEvAiW+1aTWVS+AP+waexdYFtKM1hdMDOOIh
jeiH1VbW9EEL60Kf9LK6hRDH2ZhdH73Y0f6GiiBH618995N2CatE8rDx2/SlMImR
RCoP/d+y0XcUWaH8eAZrCrnijX2FXdzxwAFKJjGfOwClyKLeyKQUCI+U+l8hvqb4
cut+Gcb29+cnNuQml4IF95o1gudd3GMQELRVCUKRqJuZcy0V3DhP0C6rGsEuz1kj
MkPk4xbFlm/mut6m3R3+ZEjCgNagUUz67Lh7UN1HOP2Kk6aCLgflq1rLULUt6AaM
ACFCwT4wtzP2d0KGuX3tCgDqGalaTZB+2Qj0WGWVu1Jtumx7xSgEkQ8fx12yATaB
YzdPFypDanfi6Rwbjp/aczd10yVS1KIxNizpK3wxlpGgu/3hWGUNrdYiipXvgDRI
dvqGrbQF2NCWbZzsua55xlGyI5+j1Y6pa0Q/OTYGAFOAsZgInpazLdrBJ0MGdDhO
QJ7Yy3M1fL7VaAN3OsHYqvmKJAeVTrmIzyGKDXa0Cy/SOWhkIjO21TDNyF9gJcum
OxLivE5g0BbwBndCSKR3ogXlheg2jTp6KKDVxHFvAStMOaI8sQVrZE/xVNUCabEd
CkSkjwU2XUl7E+Z9e0YYE7gU33lHHnwZXWFonL2IkuIU+e23RVNq6hPTVVmqutqd
U6PSwyBYRoVzfCtsruXS26aOtCFIYXJhbGQgSG95ZXIgPGhhcmFsZEBwcm9maWFu
LmNvbT6JAkkEEwEIADMCGwMWIQR/PWSCSsC2uACeUFBLwIlvtWk1lQUCYfpdfAUL
BwkDAgUVCAoCAwMWAQICHgQACgkQS8CJb7VpNZX80w//cbJWOprY0AnkUab4ezv8
dFCO5csa1c1Ii84YY9NITZHIxOKAEpa4w6ndU5q/oL1Rl7UvLfIOfbHM7hVgT+Wp
/Xefy7Dui/2F/IkoQiyXBNmvBAprl2YK7IhZZoA4xAi5MIaT7sy+DbMh7eQwFUoq
VWthhJlyFa0QI2IdTASKZqnD8WPY3psnGgg8XKfkX8Mb7jqOTgwHj0zi/fygAq1F
TyEemyhyZvGnFjuiK7yWHZNdxjAeZT2UG+PK8D2uONG7kUV2ct3bsdoKWfHG1RQF
j5dZXMHpx1PWR/Gc8jnq9+gL/ZTo/B5D2JzddULY8/fwGcQr3k9L2f0h5Yv39UAK
s3XEXIOUgaDZxK3uJlMMZO7uBg9J9MC2oZ8GWeZsU43vwEYktnLoIr4Jc/u0BcCB
OA4RMMYp0WZmI+k/25UA3MpXAk/oroDIb5gqICvU5tqjRoPUCRzxti3o/ID3UYE9
slyNANzVjrc7/U3xfZR9DjUhTkVsCrEw/NjvUsDWD62oYYZnonM0lkfRDTCTmbHk
PlCOKzh2eCRS/6ecbzoYjbcra8n4LfceJA1mO5v1HZXmAAcJDHDlzAZaO+/r4Hzj
IHrhfhAPYM+yeRTWvb1AFSSkpCZXkUPwEvnhXMJRT0y5wSK4kbEcXcJgfVBuu0QR
ZA47c1w5JjisW8GHVuq5GeO0IEhhcmFsZCBIb3llciA8aGFyYWxkQHJlZGhhdC5j
b20+iQJJBBMBCAAzAhsDFiEEfz1kgkrAtrgAnlBQS8CJb7VpNZUFAmH6XXwFCwcJ
AwIFFQgKAgMDFgECAh4EAAoJEEvAiW+1aTWV1m0P/RWRs2eA378k263kB3JNebV3
5iwMFVKKILfE8D+D+zClgrNgiBXMJpDYCAllmCEQQfQK/sLdETTMen3/wOVZ3V6s
1lXtd9uh0ZVj6/jUTrEOAh86ErYIgG7/5MTydvya6S3I/w62k33ways0A3ZAByr+
cfERth2//ROOoEUrQTGCMcfkQEzWjHBPipe5Gr6H1iLMAxcJqrOBg/t+YxEoSaca
Hju4Vz3cUUAZ3EwINnod4Dt2gb71Vi00l//t+k+9n/4sACrc6YrE9AKaIDvbDFVM
z5q4vCtkFcGD9W3Ole7ggLTYlDw5tvOJxpABbmfC+caLOTOXLgy7dqPLYL1OoXh6
SgYH/XDq7i0bFh5gCSFkukb+coJXkfifPFuB04W7eETRjQhy0EppHUBxjZiO9pjU
60H46P283BBMstFzlGClq3eg2tfC8kRsOZ9c5UMJqG3b8oZIlD6LM1qw8MJH4wzv
CTm27yQvJxojDO9q1qBQHiFaUqtiVvZXEK7ceHuBb9NQpf4oRJlAF/+govPJ1QCg
biM/7m8bAN/2/5GRAKzbLOxa5DK2UT19MpjV6Qpgn33PHlAcIHTi3HvfWYjhFo7V
Ow0CL4HmJKDd4372Bma0YqSDpYB/1J+tpK9sQjnIkEMN7t7EX372Kg/ONM4iDRQa
LCpTNYcRqoHhCa+ZPoAZiQI2BBABCAAgFiEEW5+gspNca+hkAihzqcF2zH+sfVYF
Al58+1cCBwAACgkQqcF2zH+sfVZRIg/+MlA7u2vFBSjut5+v0PsTrsci8GrH+8dO
FD7H9ndjQQqp04sC75v6MVprpEdUJfgFncz5UvqZYEuT3w6VrXRx6w48SVvt89Cx
cmaAk/6/SG9XgzgsQ40dEiBzBBApFSf5hlWcTgG4TTxZGl8zssn6jNNu93+EZmDh
j5o69Xxh8LNs3czCGANeEmI/RAi7+IdaTITUXxcL60aRfJ6/DDb0T7WeAivi36OF
4jeGL4rqx5JIF0GenFjc9xVT1gxuRNkQ61L+t0gtY9IFYkkIzmI4Ef/Qw3OPa6Sk
MLSEurGrhBr5XSQEU9coBCYVGYk9KXG8Cgb9fomLlSTLUF5GT0X43jxmfhZHKGYA
XuO1r7O7jczd+9z6uQ/LktrkzhyjHK3AyjXU/4+Cu7GIW16pEIkM90ldVXf71vKv
3WLpPIeycpThaEbp+yvAb7Pu3wnNvOmk1Bk6qaf1R3YSp9Fv+lcVideBUDyp04jQ
+QM0tQKObHqUBbhvkNRSAAnorL2MmC3u7nA2f0/zMHgXGvrpJKf8qkdIRScOD2sc
lt1V2361+/mZUqX18MvbedT7S/Gf+C9+y3RNQ5m2S6eyacedh3ndoZVzYHwWAHse
AnvFEa8u9hsrEAZI7sUWHPbI6yj6U6bFPFpopkAkB7TYdLHhcWKv0f7eAiwcqUXG
wkS5BRFguS6JAjMEEAEIAB0WIQS+X7yMnByfYKTwrq56TzoJ697/JgUCXnz6fAAK
CRB6TzoJ697/JoRpD/9bTfypWfx0ob+QZxx3h5YonZE2RY9TZaGN2fxZBWycnmJp
0cET1gyu/8d33uhKVlOUMWOzNMoHPJ9/51zzJjKH4uiahxshkxpJWpoG8fJLrCH/
pmUp0Tqeb+ve6Srw9mXYq7I9fG74957BkYfUUIM2rY6TDsmURTG63XT8niAwX0Op
EqTf32HcVgkpvJFgA63NJvhulYoG/RlL5ULQtTS+KucStYe/EBGKKnFkhSeku0nb
+B928nWwkokOAVltp3RRviiXCigotekERiFTC3Um9xh0FJfk0RLea1/qomMFD3d3
XVsqvcK6EKb4edVcAt88k3x0XIOlDxzIjK77XHjzoxkRcoy3rkPSf1NuYyuVBPPL
jTa+LVL+RCXy2qY2DkZ8eEOQuQ8XVSH9uwBfKvm9XJHLmfSfOMdvP1oG0ffHtlY2
EsXDappnWgd0GxXA5n+Tu+x+0grk1hiAczGUhxzezGEQr/lSyXQ4OZvP8XKL/8d+
hy6CN7VI3Ix1gzfUR3FMthOBb6vlkjtTtnIRiJ9gCk7q05H2nwJyQ71MM2OrB+mF
zUScjkKmkOp4rbUWm+2gbhOvb2H0P6/atXE2lonHps42sAOvwNhBNWyz8Lz/rK21
bT0jZy26WL3+PHMYv4HbJD8wrIaEq8Mxzw6NqEQIkHCc4LEvnFbIIBQtLPyeQ4kC
MwQQAQgAHRYhBFwlG1/FTrL4D0B6qsVMozbP61V+BQJefQNnAAoJEMVMozbP61V+
hj0P/22ga3Ntm+TxryPaqsrjW7gyJ9FOLfLZXGX/bnicChFAvXJvVZUb85Jp/5WP
xXRyfa2qqN27kT8s+qSBOOQVRaQI7WhLW4D2WeUViyMevLvJQY12dXkWDVcya3ic
yy67aYI5IitSbbJp756WPbezn6cLads+biqu5TprWudgIymWPKRfZavH4Pk/j4ae
nqh/LZJYJxYAZMjGQPOxI1NXz61/G6QPH0i544Ms+J4pyxuVWEm/yrHoXV3L9otj
609rX7p08KCdDKv/73Pz0i0h+trkh0psML3UIQ2KHwlHlySGrRD+ZKU3WmM5JkZw
Eubgex9t8qbk8LAolzwVsaceVy/wRfvoJh7pLx7ay+GVSDBh2sSQG1BTxGzWXXfv
IfwnA79hWCFnRCxiFfnQHq4GoLGfxxeEhhQwTOp6ZtBheQmc6JT0ECJOlm4mChDc
Sp0WVOaquT5JMhdUEOsbWAutdaSsiTfZFT3OThtHHY6UbBcwWE4ttzrNT2Z3l2Xj
2zVsLaP2r/gi6SKDQiUvnbVhFBB0otac85Fon3EIywZR+WJMLhJwmpx3UpsL3yr7
qaC86Vd9uXcfAGSJVrKkyuv4Hy3TOZ69kKhzw1fDJ/ZgNd3PdF7Y3XmzTiu4jS40
XTqxK/7TEbm3E5JpZ1do2qwRr7Npa9PQbQL43dyiDFcJ13kCiF0EEBEIAB0WIQT0
tgzFv3jCIUoxPcsxR9QN2y37KQUCXn3sygAKCRAxR9QN2y37KXfSAJ4w/LJrwd42
LUyDYygUe+1C45GhXgCgmCi83T7Pevx0EvowYuSj9N5T3/GJAjMEEAEIAB0WIQRk
fyhlSJTjvUVxmb44273IYJJpPgUCXn3s2AAKCRA4273IYJJpPvulD/4/dEhZkuCb
lmWA3+mqMMklMaeiucct7rXB0u2PDEqMC8wwVFQ2JiUP4T1WAjKaAsnaTxGSqozL
aZyJ5dJaRZXSCdf2PS9si3iI9O2F3iAhb0gRWbtxiIU7OxoQCFrM3KhG8hHbLhl6
ibnntwBiBhw4iAq3zhPMNAHpP0PZDSGLiYLffBfT7I7i/+43NpGsffjEzQaLO9/V
l1+vOZgw6LsGTtT0sDuKevxOe/9YILVIQq1Y8yAgKFigewUl74pFfMFVsIAalHJx
2pZPDMZ+6Ct0+YGyEK04fa717fnfGTNhZy3Hg79jtXvFNgZgx4DlYbanSPaYuWU1
eL2oTjmvGE68YQCaSo01+ME6pBJb+RqGeRVro6siiIXFcyC2aE1rlc4CDReB8dHV
aRlv9CBpd9LkSJNPwRwcx0joUi48g9rMV/bjGF00PerRPNusnaxC9WqD7esJiM+1
u/jIO89Mu8eMDRfSdxDV0YwsHC2mz1AhEp3at2IFRrhtN1bipRsu7VcBqjrDQIIW
Rs4KGDjBk0Li8G23ozlEtAceM5MqwZ291jVEzfM9Ly9IO0uXONuVRb71fVzkDkf/
eDUS6rxTRv0PRDmFi/em/B8IUm9pd0F7M9/45ANKrqIRYs4sVZKy2qAjcv5Cz/Wl
JndlyhvoFWRPfz54MthkOq/5208betmIMokCTgQTAQgAOBYhBH89ZIJKwLa4AJ5Q
UEvAiW+1aTWVBQJefOuiAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEvA
iW+1aTWVSwkP/1N6be0ZehOAbLTvLpTyIocNJG2JxLw3GheKIhYhOU1Fp4gvbik6
6JZWL3H8AWRpvRKoAP2KC04IDOg6Ci8cEO794tyLtQlUXvVj5B6xqFB8x0OmLqZ/
bk3N1B/DqSj4ka0F9Iqb3N+FXISQDrfcaqcIjCs8pdyDIUjg4j03duvVxbgWTyJ8
jU+WMkbL43HS/fsRaiSbPNMoImSdoMd7uqeArQSXIIrWgy3dxKT70QBKoRSBEwOA
dYiqerLwpHm30PNaVESPbMymXbVCPDfUsGPv3limasFiK62/RL9sgNtYWczyL22j
X+gRvPj/uHxuA5AJKpXUTmFfIbDarfG8i7hCEhFkS2t4Vfo4gnGpfGWHGlZrUnt5
e2nTAsdeQG55Zo26A1eppRuIoTFPufvFVL0oASzLIRMKHxyRnHs1FqGx/qlVqRKt
29wSNAQWOBglxNwOmuNXRqff4FoxMeCYXgNdRoHI8kyLhtxDE+e8Ogibiq+HWbuG
RaOU7jlOtkaJdqr7pkKdYGbrMHhhlY7bY7lhgwz02gtWtWq7NGgfERVTVMck9xvy
SRura7WHGo7M7j1cA1pHx9docJ54O7hPrCcxPmpl1CWi1TfzwPTXHwja5gAFrO8L
G6GjQ8csz45Xi+DRSTerGxaKPNLKWKMYm8zmRdOIR3PTnzqVltWJ3vLRiQIzBBAB
CAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl597BQACgkQONu9yGCSaT57BxAA
km597k3PXxtZIsOhWPhd5eowinOYwsaX1Mnxkihmi9DBaNQHIElwMTNMwLh906W5
iFYTRY7SRfYybI1Kb/vgd6lX0NGF5af5RPAiwEDTDjBdPbrAjq9ANbQuu76t/meB
EQvRfgXUPBtdwld02sHXtuVVQGSF7SUtcdr3XplLBnSmgV7IrQziv51UBN0eyS/S
j05VIkz54daQRIOznEkeNuD/7VV27lnE4ifJchDPqNeFdOxEN9Bxn6ranVxex2jp
8EP6M9fB5agsxSwrQb8tRoBV7Lozq2ZHc2YSyF7ecT7N9+9X9Rgnz13ISwONUX4D
qIvjx1fZJpwzN0vX+RNshq3JszXWDrDX6+871wRT46N4rgG+DMyLIIdUGUFgeK2E
guhd/DQhnC3bZrc3I6XHM5CepiOqY78EWyjeTFw7Fye4MdPqNG09VVm7aPaJdYZa
/GHnILSglxeWCsIN4pwxJdV5RvVNMGsgyon0KGNLXr5qjlMkMXhn7ZS3iX4Zv3tH
0DZNGR2Ae5eBSi7FFg/oh/mV19YQ7TM7J8lWnd+/KBny4hJxf8akY1goWCUuC2NW
G6fGax2RrkYKjChvM4/v70j7dDb+4264mGYiRNslfoUujscMjKXlxfWddBSJAE8k
05t6AxHQDShd4XIDfmCpHeIm1KJm39+zWMWOpAKxkL65AQ0EXnzqywEIAMHIDb4x
38Y+dhF87G5PmInwUD5Zot/PTvxv+aZAgLoHFItRNH16zxLMf76awkrBXceh0WYt
nzqKDALhuk+ZAngQgO2C13bzkru0kCGZJnGirDRbpRirRSeTEMd/kszww8ij+sLP
SSd0fVF+nTJ3yhag+T+34Q4Qr8dw714ghFTn+vn5+XosOZMddDFSjg1j9pQNypcV
qtV9cG6N5g/AH8Rq0KdBCW54TDkE0Yyikq77CP41KDUM5iwF8xihxA97WnV6FX8O
4o/4Al2019q1DARQKCuWaVOSx0kFTnCk3VXXnZee6sV8rn1LzTG6MeUU8QM/bAf+
DcnEWoNEznUDRMcAEQEAAYkDcgQYAQgAJhYhBH89ZIJKwLa4AJ5QUEvAiW+1aTWV
BQJefOrLAhsCBQkDwmcAAUAJEEvAiW+1aTWVwHQgBBkBCAAdFiEEf8VVH3PMixXG
CTkXoR+13wZIBboFAl586ssACgkQoR+13wZIBbrhmAf8C9LyKNwKPGXST5GDYBfE
xFxJt2IKkbcBvnPjiOEs3aDBT+vYJWkTtG5A4JDKsTrwV9VXQ8x+xyArhp6zjx0Y
i8JOgC7e8ogdSV+rCCSIqXllbT/7BdGAP5gMkVVu7ijEpbkO6VUS7H72bT9Ht35U
mAnwf269RZjvmXRz2l3BKzbrzG2OGd3NZfP3zjFQRcNDo75TzCBYPE0Pp3qroq0K
jhVNX4SDhSn2IdDCByaNfSNvMn5zRRlFIMkZwLMuI3nvO6iNzqK6adQYS+lPb8+M
qiTT3XdAsU7ilaZld8RRYWz4dEPbIprBUjxVzFxsPuMpVVeXNwCZczq/2ZDtnA1L
FWqbD/9FArSQRaU0AAY6HAIidyiTWrS11tEiI/oK09uoxyhRQW9VBZIDYKwGPS+k
vTEHSO32NUgQEs05AgAPVSR6cVYoWjHpKEGXZj1OisK4wjxK6mXPXVCEgF2jBV/x
xqMplA/QnJ2G5PiXbbe88iTC3rL0OcIRYGDJLLMvUBW2sUdCHyTgYVZt8uO04qwP
OlJkry/+MbtTL9rqrGRDwUrnT5DeoeyLW6oxcKXQnwnaMK2eGURN4y/4A4Yj00YM
g5gJFflNkVY0u4An7OtekmHmpJ3bbO7MOxp6L9UK7Pzaxk6vPggH6J4V6vJYIc9r
0q8pWU/nZyuMEv/YQMNs9XKPWTW6Vi0dmfUF+u4fwxtEbvjncI87ye/XApMzSuo0
ZJVl8SVwH2CFnP+3u7he3oTQazCOg+tkvsWk2ccO+6h74oTVSH5c/Fxrha+BrmpN
E1/NuzQPRx+PtE+mAh8Bk1IPeV4C0LekYh7HGgKG12oMGVU/wxff5nvtHBP/WLqe
MjomMz2qXc2SYnhWLVpkt9bGH79ItJVkWvRO4ZRIKen5/zGliKcrLVgTjG5X7jAt
izlbU4qSHJfASDrWCAndZyVgopfYeaXB23IQi8pMzYCJF1H8MqjSTiKhSWeXAB1z
vOvVEoEBcFFwrkW1va/MUW0dUOQrS4tc/cqlIhuxMPzQbaCOu4kCNgQoAQgAIBYh
BH89ZIJKwLa4AJ5QUEvAiW+1aTWVBQJegc4fAh0DAAoJEEvAiW+1aTWVSTEQAIdl
TdCrQAUoqvHA/+3UnGmZUizPMISwg6Y8fe30A7CT+TG0Sj+0BJ5tEshhvwvUNzFy
5FN6KmAAvcEHSFzsYDqJxdLwjawg4au2rV3A6+JFDvf+Khx3YvNXpz3VKwMOSNuc
DZ52tqnSF8x94N4CoOg4HSnLTQ77x1NcUb+qGXaiJQNQhN92Tgu6faVGzPeE6sfO
yriBiG3dT82tBGj3Dj5HlgEnkN5msNe7NPbKMEmXF/TCtHaHTcELzhN9SXcaubLW
GzO/kfOwig3IzkYYuxe2fJSONihwp2t13eL7bEZXjoJMAaZHnKsbWCNmFMwjNdlb
hDwgtndSN3cOYEPNb1MMRarCLBA5h3yk4HB7wA0eUPnXeo1jmZMcor+52WAl4gUd
yZ3u74a1GrnC5gxlzwTbweasLS3X6VZnmIX5wPidejZ31IvkVAOSNVWfDelQ0n/X
BXokQSyHc49N6n1tunzuFk4+BwlmwxYwYgjgPezrK9pDTuo+iVlQe7pSN5yUBjqG
6BoxJR40/lDhOYnLXBMP6t6My7Kc1SGwTEm8wqiMzh5QK97oesdB7Kf/tvYnhEEY
bvCyNPT4uWuTMJpnsGyrmcvkwPe/t1eXpBn/evPfMX+TLNbcuwnUbxYPxt/EqGVk
Kx4PppzHb0NktbZyguFvfubOCsWoHe7cmXTkyiYMuQENBF586vkBCAC5KkbujYqY
XPqKx2zbcH/pYLTXBplT6zjsKGqenfEvbWWzypzomnWEHiXYGgEyi7uIcgijvUcr
zVUdGNPdWh5v01rLet4010xA2rjSpkovrkXpVzGxoAwuNKsWbp9F/31evaRo3HvY
yo6BXAkbPuuI2mfXmZXU2lOzBmRLuwb2CZX2ettiBRfJopl6yHsO075ApZi8bdg7
Ktddxg64AJWlfEcD/lREVAmaJbCCjY+vPNB7/dg7bAb3u0uJ6kPgWOlcyTWQ1yPn
0kASvCyY/Shz3K9bON19JeEVHhiLGpbaUyIcPjgPqIFwfTciIVZ4iCqTQS/P+Xjc
9z9rjBK0iCq1ABEBAAGJAjwEGAEIACYWIQR/PWSCSsC2uACeUFBLwIlvtWk1lQUC
Xnzq+QIbDAUJA8JnAAAKCRBLwIlvtWk1lXJaD/9yodf4vRo6GPwwB1WgG7kOydVz
yhRo+aefJ7MoMeb+rFClKh041pkXboI7W1y/r0cqdNFaOJ8V0kv3IfMOMO+2gFGZ
iuX2RwNL1db9G+3qcZARk6lhgBmYrCMceWJfKQPjhnZNMRahryt7HrT5y/SN7OLZ
bN8m4+4DLgw/pvVR13tmDOSJbQNO+jtIYqrqPRwhW+qikASZMp+j1uEi2Q6RUpRN
QsVj3sXaUaRuud7n4ThblWBXxfr3+Z90tZkaPA1EWN23QN2shvoizGGTLCAXuWt6
KU70FgX6h9qQL07OIe3mz0uyJvFD/441uzeF4CBoQGdm4d5parh5by/NUQ1IvdpO
aRiJ2jLCJt3RbyhtOUC5TVjW6+JpE29M/eqAMGKzcrBBWs+iKcoMTvoHrbTREWhI
6wiuGuJZldUhskDZesMD8mbk++20FLeTa9EEIH8wCKf6Xul508ICQOttoSDwuMzL
gT0BCScsGdv3hiLQ+/jGM9tlxUaZ+pjS56V5zuY5MbYjm/H27FXjN8ui1YnFxrWJ
srKC95Yku3SoVvz0AXAIwUaPt9OnU9RHzWXhPHWJlpmFGsCjNlbaTSzZOCFWdnmE
FDeJFawJVleHesy43y6ml+Gc9MRibE9jCf1klLEc8B48d7oQsoKAQ395P/yGRLEs
ARcTrLNBKKTF26nxXIkCNgQoAQgAIBYhBH89ZIJKwLa4AJ5QUEvAiW+1aTWVBQJe
gc4mAh0DAAoJEEvAiW+1aTWV8k8QAOKx73dzKGWBevmhAvytdznL/alJm3qh4ZIC
/Q8sahWHwZEDIetBMoAsVYkL4qQADXP0Iy67E8nBhziNmW2Vy+qDNHjS5eM9Kz4X
tNwm08lg1MnZSaEYQA6o8t/qg4dIFkAJaPBZcIdU+1TP0L/yb4HGu6Ts+1xlQPDE
qbt8Qf41eZkK3WFNxOFt8G6flcJ0XM6SndowcHCvjLyPAOVfm45O4DaX5u/xzJ1T
3K6VCJOWPb8HWKFfJ+TYWcYD281USiR8BkZsizPH/YMJDz6iPR/s1mvjaY15Xrqa
a/ZY4olqb0b3YuvK/9ZkaZ90ff+Ru7WIWj0A8i4W5TsrMx6Xded0uSU2RbU9ujbB
Zlr4HoDItc7VcR7IDRxamUToILFbkMCPUpYFIhVfWVw5Y4l31yAkRI2g9Wxd7dy0
f7PWcg4vF8t33rhmo8jDZXyP99pwoTGGhaOton75TgzwX9WN+1Kbs4q/9y7IxH7F
8QdPM2zwrHfyV9hbevgRM0qEovvf346XWUlUS2NM6XzTazjeFWViW9c3t/rOVQNm
yje6MLZUKANc0AqVWTL18sMNxGHRA7VtUtrxyT07OffjqMQFSHAVaPEVUax2T2JT
ZTQBNHjImLwzyXWwz5gbSbp7FHGpHIDPDGsaOeU4jHu+9XppqJYNz4CRb0SkNz6R
E2D7585TuQENBF586wkBCADCZir2OaQTu+WIjBqlc1dzxSBlWuozlr9U9ntxKNsi
Ylx7LdVGDdoDDDT5QAHul8LA1gNWMNMJd4qhxy09Hc47vDJE8zhUCbJCQHdZXDxm
KQ9DoF1IVi5XCWWZhAG4QVMxX9n1CH12UgXJ5I9qr00tlSmTcS2CfCEAVMquKYYU
q6dNetvXnRXXo9fybhDWHKKFnrRFtfFtHWl3VAq/nDaCgcY/S3elYhXxD1eskYdQ
NGhV7Wr6ar4fXwg328tcD8UoxfMHImhcKqR5/peK567Ocng1+pl4KYIASHFMuWvR
4iMFDARClN1ieXNTCofUoeIy40b8/C6d528mwtuf0TAfABEBAAGJA3IEGAEIACYW
IQR/PWSCSsC2uACeUFBLwIlvtWk1lQUCXnzrCQIbIgUJA8JnAAFACRBLwIlvtWk1
lcB0IAQZAQgAHRYhBBXRmwXX1NlkgFVlWuloQlFImg0wBQJefOsJAAoJEOloQlFI
mg0w/gIH/1iVG8ML0xy0jNc21ktqexyqnsv0BN8wvhDa6cG6sY4xMG0CoerqypLf
p+ZgmWyTFz1ZGdIRLH99o1h3Wm9P5TDTd7gtaNFSxllU7m2Fg9SrAtWlHJsLjGez
08dPK2c7uUYmACH23SZTx+RaasbyZOidZIOYkr92kC+sbcII/AbZ+9Y1yIEmNKuE
Rr2Ka4CL7N9e9vgshCsld536nHXdT33Tn6X4KQ+DQZhRrEEWlSMTvmMmdZz6JQFN
bi3xvM06iaJ3UjTk6+XS25N9MDVVeYn5cGepuc3cHbyxspC0cQlBhmvqDm+kcxP4
Xwr3YORIq1QnCWo9mz7/pqok+fUjP45h1g/+IZC4fIALDHaxl4UrRN1b7vXDrEeW
7GsOaUvgeT+YRX7NkjfsDUDzr+YeblBqY16xw1KeUSf/MFKOBb4+lIGSWy2X9mMn
bqUsuISHSeVwFMt5PQzuKlb38Fr3twKRRvRHkDExz8HAe3U6Hw52p1UNS81Y9Za6
CEhpNzcbbLBeL2dXEax+CKBm1qYo20KRtvEkcY7M0fCquTIVQ9E6GfgGnI8Y4Mnz
OQEFpNUyHdq/rEpGo3DV1XIMgswelfcl9B0759B/Xh0GArwco5xcaQIv8epYrlwx
OsF4LVOFYBEPv9pInF1dJlGlz6oHYXgxY1i1xgFqclc+zF8jKI7SnWzc1Ja/ZDWL
YMKHK4C4AbqIZ1CeH/8YFtSdlE9R84MPzYZVXgo3FXMNHjC0uLOjG7aPXHSw5afx
XsQFdf4djjz81+9ZtRASW/qE+IJQy6szadEfRAgg0BO7w9L4d7CMw8b7cl1pNurn
C8anRjtZfsxZEyScGVC3IBpO2ne3SCUEagZFyfuHLB6ktrU6MgXjICnn4raoy2ia
J5FfdfynnL2Kf99P13VIS9/gNgAezjlmy9sKOboYwr1S/+/FXHUoqk7ztz2JRcBE
ieVpxTlQ9HM6NvqWSH8G3mHGxKCYgFRFcf9grHg6t3TrEyj9O3pCX3UMh9nEna9D
zsUOffNNRx7NR3CJAjYEKAEIACAWIQR/PWSCSsC2uACeUFBLwIlvtWk1lQUCXoHO
JgIdAwAKCRBLwIlvtWk1lYksD/9vgTAdWJ4XTV8+0CaH9ZeIbuS5FX4SlfDbCEOq
h9rssJABppO5tVtBA5AbcI+7BR+sic/QAK90VzwaRa9IsiMloK92FCk+wb6Asq5w
mdwRggGG+b0jjd/27UKBedv8gIDDsJnBsOOUFrmtHQzeJ3tSJ59aBUFGxQ6MVsJx
+lznKqn1KJIpB1KlbxzMNgdEmrYz4c6OsROKlEnzCqZfdYWG/aR/lfnGZqNjIQlI
s56Ou1qdUpoeW/2xRKZIaVz2YWbalSiQf2qESOX8w3qW9DtkBr+PyG99S3THZrYp
WTMXMTGsaGrVnE7rmTBTB43fQyrcsEC53mkzLlPkqLvFean6ipfHYgSKfa1K+mD4
LAd5NyH+Vi3TBXQA8TBzGJtaT+RRi4FEuugR+KHlTufc3MBl6Pbx9+nx+9X9uDlN
xlBLY4pv1rY3mBJnSo5jpVHJ8ER9FQE101KBK/Xdw6e+DLlNCfK0e2dVcF/1OXLq
EqHCKO4SeM9yXVtEba0Zo5y+xCWQnYSYMNAdp2qW4REJlTXXUKJwDaW0Y0/OjQiI
dVtDRbvxz/NJuXJ7++Tcq1S/ywq8i132KfO4Q6F5xRP2K44yeYCyZ82Yxya4SSX2
JUxrKE6SW95s0HJSFZC1fWk4dpQLfSyFlYi2FTxzFvUHEL8hG66xrtYMFJv/hINr
tTd3p7kBDQRefOshAQgAwmYq9jmkE7vliIwapXNXc8UgZVrqM5a/VPZ7cSjbImJc
ey3VRg3aAww0+UAB7pfCwNYDVjDTCXeKocctPR3OO7wyRPM4VAmyQkB3WVw8ZikP
Q6BdSFYuVwllmYQBuEFTMV/Z9Qh9dlIFyeSPaq9NLZUpk3EtgnwhAFTKrimGFKun
TXrb150V16PX8m4Q1hyihZ60RbXxbR1pd1QKv5w2goHGP0t3pWIV8Q9XrJGHUDRo
Ve1q+mq+H18IN9vLXA/FKMXzByJoXCqkef6XiueuznJ4NfqZeCmCAEhxTLlr0eIj
BQwEQpTdYnlzUwqH1KHiMuNG/PwunedvJsLbn9EwHwARAQABiQNyBBgBCAAmFiEE
fz1kgkrAtrgAnlBQS8CJb7VpNZUFAl586yECGyIFCQPCZwABQAkQS8CJb7VpNZXA
dCAEGQEIAB0WIQQZKviVgBoj9EUtRYF2XmKrYpB7NwUCXnzrIQAKCRB2XmKrYpB7
NzHZCACxFQgS+DnFCtdrmE8ziFrPIFSWlla2hM9F5Ttr6Far0MAEJ9JHouNm3o/P
7jfANKNjSmd0woajKGc59/4Y6uwgELh3k6FbN7vtsNIGY9L5R2H64/BDFqOr58Or
Scg2GmqNbzYY0dYC/X3sDEQRg9AY+ufQeQxaLzj6edm8z0brFQInj0bP+BF/IGNr
SZXlxqu09PbfCvVBXQReGtde34VEQaCqIZjeZcfR15M+iNHeBwLeFXHeFEPIyq0V
riQR112s90UsVFKVFKBOvtfNZabNDqVNi2ACwIc7zz9xHqTd2o1OLfgycXKCAT0H
xCT6prhWQkDzoMQlgh1PUCwRiU+4SkAP/jxb6JIhs0guQHS3qHtqmZ199BJw9v3r
pQhuDrOpZYGrXMtEyOkMa2n+hdrH3r4Dw0xiZbmVHm+j5EB+vT9TsZyNk8oexqdn
4BOJMvmPPULz5QXoLlejAiCDefZ398soXrk4Bpb1DP0OndoalttHXIIgLXdJRzdZ
Y29d1jZObKLzM94+WL18rBaO29N+NauPaQpf1Ubm3DkujgKh4hCtf4uMLTKY2CvF
bQzfDhWhWuCmT2jguZNprCEn8fqkVOSk68klzgxjyNhzz7zgjspTYKdK5bZwzh8r
GOwnc9ZfATMxHPi8p4LxeemdOn7RG7NISyLkAFUgy9LqRG0fIT/5PSaxiToNvUC9
cj3EMrTEOZSbSmCP+WiVb7SC2Vin4AtrNjnRcbDwanDpli6c74RhkQ8D67hzRGXu
1MNITXx4a8pqmXIAy+OybyZcO0tXab9B1WMMwY7s5KCd3LapRd5SvmUWkDAAxguF
CRlnG34MxII6E6spa7YQUaLRBB9A1cJtbUTg48nDehuIcu0hTNB80PRRYf1OHn2m
vMGyO6hlQdq7esOTfUSY1AoG442Oe1D0ik7HppPYZgAsr8r35Nb5jxrkmFhcWe3H
jVeHIQBD4enRdcLcQCeaH78SYMeFiNFPy/eNqY+aZv+WzHSi5dkKtXGdGwiXHPV8
njl4xRz9HSNiiQI2BCgBCAAgFiEEfz1kgkrAtrgAnlBQS8CJb7VpNZUFAl6BziYC
HQMACgkQS8CJb7VpNZUdgRAAj/nShWsSVURjIWnTsiw1Eh4HpcS9T+64SfDrbXrq
iGJSwMkPWJ4JnKtX/dIr751IjSpSNCeecIthQ8h5iO2tXO/ccLC/EBcysXDj+PpO
fQzXdspWCZRaWec5ILItqa3t/WDxdrHyF5kWgFqbmnxLjCK6E7Wk7HhMERgosjIT
K8T4R+3WUNwLkkIgRluxcM1HQ903rE726cZRlAlL47Fh8Mrt8vMi8nbU38B58a6s
gL4TrIZHSqPf/VTLMA7n0qSAxPwc6bNoYbqjNzDSTzsmCrL9uC0srgkeFUXWgdm5
ivtiqUK8cVyv4GSqFghXB9jKaWCj6xEVHDe+yqxSFe6RGtf1yNztURwmy9MaO5ls
BE7neO2uEgFiNL/XiAoaDdIZBg+174H9E8NT7xy0Wu1GP5beJdaB/kYLmSREVLqj
nomGcU8rNeqLpNDE2iAU3J/4gbGeF2USTIWjtvsAe9BJw3aVWNRdgtKtmZV0vx6R
jFy0zdyp7hq//NGG50gtZBz5cek0Q98Odu4TJq94EIditqyjlIZ7d0umkQcWiZT5
EheLQKmY207k5gia831H5Jj1IFaH7zU+BW792/qIjjHkavweu1mnLHAnhOwtJy9X
YCVSQ+aS09L235+EIQlcb7EmKsC3DDarHWm0pl4IS8tgxfVxUVMIATqqANYLctVE
D6O5AQ0EXnz0gwEIALkqRu6Niphc+orHbNtwf+lgtNcGmVPrOOwoap6d8S9tZbPK
nOiadYQeJdgaATKLu4hyCKO9RyvNVR0Y091aHm/TWst63jTXTEDauNKmSi+uRelX
MbGgDC40qxZun0X/fV69pGjce9jKjoFcCRs+64jaZ9eZldTaU7MGZEu7BvYJlfZ6
22IFF8mimXrIew7TvkClmLxt2Dsq113GDrgAlaV8RwP+VERUCZolsIKNj6880Hv9
2DtsBve7S4nqQ+BY6VzJNZDXI+fSQBK8LJj9KHPcr1s43X0l4RUeGIsaltpTIhw+
OA+ogXB9NyIhVniIKpNBL8/5eNz3P2uMErSIKrUAEQEAAYkCPAQYAQgAJhYhBH89
ZIJKwLa4AJ5QUEvAiW+1aTWVBQJefPSDAhsMBQkDwmcAAAoJEEvAiW+1aTWVvikP
+wWh1RT0xuvyy8QK31dhTCgNZkn7W/H02G2f9IuSl+AXKlNj56R1ORIvfqD1HwfD
rbyAmVNE4d/DXKN5uujUZwIF8zDmO+8qPSpHz+i1Pn1vSNO+Y13xqCqxNeeduXGu
rSF1qLeNrVKT81rLdUE6PDQV1kyFx0J1gpR4cqI+XKhtwsW8sx9ViTM8cmrHFwdN
iS1suqZChHmZS2mH9dDHKvbplB0I0xLt45/KOon43GQR4VnhZt1HG8NIa3w4QlBZ
PE3C82V19T2EEU3K1GapMhFKuycnt8f8x7lgN6+XJj+wwisYhFmyEt2w7SvRFGr/
grFPiIWKNMjC/utZWjlAig69ya0AzeZfdOEztnkxA6qxgEZ3SA1zAdhoXzSUh3Tt
9N7NMo4fleflIxYnckxRtDsTBDqYqlitkoBXCKYXdopc8bVxFAyiOZV8wjA7XaTx
d/W612UMnMVMA/YahYk20r2imMS1X2ugyceUj7FeFcTkRNmN5YaqXpUze8Bh9ImA
N4+rQ7pirEkyWoUfKnB+1c9chI9e0emVBwTqGziZmbF3IdjPqNs75YoL0IidGqGy
H6uB51DU69TpWWU30MvoNIEPEh5nzkU+A0g56JQRnlcnsTqhs6BoGKe7alcfGhKa
wuFE4Yc6qJ0nohLHg0TouPQMtCxAeist2sUvgPKlx4iiiQI2BCgBCAAgFiEEfz1k
gkrAtrgAnlBQS8CJb7VpNZUFAl6BziYCHQMACgkQS8CJb7VpNZUO6BAAxQJm1+tL
QL5xcqHFqDeJNKPPYsgsTHtewG7hgdZKzuaZdz0Aekuh1xraC7/MNx2lFq4cdbcH
yLozCVe0GaoFyNJPJeyq8L9CCplh5FckMVgnBGmQsodbWJD2jXQZFfw1zYbeisGS
nPyX6v3ShDAkwz+OOPyU6AIOAysPKNzkzpKOWBLXH4QEnXZR1jNvU8ACz2AG9+up
MiVqYUFC6Ib/g6cCTxDcEZdsrjXGHXKwv2M6D3WnE8C+YFQ+J7ooK9sqFuzVR+Uw
rxkkwIsxmZHqOavLJt28eX9KpyvYat9oQAMVWP2h/xQVVZtQoSSh6aweQLLrhC+/
nQh1u6QmGsiWheBnulySUlwxRbEG6TTJFWivYkakrhklwKLeFnFBtmS4h80ESF9r
xU+bat7IfPTpXqW8SKJe/HdDj1IoO+Qmjiez3iTldtJ58ozlxpHLb6Fq2jh9I3At
7HmLpB0cMoctk3hPkMNBrTV/7ND6YxRuujj887WVqqjFxjnlLvNrhcSnACM9dEYi
2nZ8bKvhIdPuG7jPvQRbX9CHdE+cbRjCs3A/WE+Y5+/40VG0Z9Hn1Pngm+lj5OTc
LlwXSmuu3AQ1xXF5vQh5Ph88hDqwCg1SP2LB31ijQTOy2mv1Ufj7rKz6LuPgGoct
7CI1VvSqqw5PHax2JtREgoHFu1VIS/ycoCa5AQ0EXnz0ZwEIANmhcF0GdbrULL4l
J8vWvy91DMusoXrlHFrKeBZaJdodTP6hupkGtKkA0oyczvCDksLz8zFi/vzj/Uhu
brgAVGHwQc+UVVpIcHjKHAbQuFwahLJf61yJRGHrag433waSI4zBljB6/4lCjpTM
oGddszz79GML++HydH/yDVoA4F/yxkbPwVNmU9bQcv5QFrJKGtogB7DS4KIu1Ugk
Y76NdE16d/n/L3JnqGN5hXbptUJGSBGH0rqbIl5rS41wewVyadmu2pdFbAiEp59n
q0mVK0AmSPYVOJP/MlfSCsQmsN8DrPAKcectIsol/cUmy6/toIY3Q+F9YFB6qcWK
O4v3AlkAEQEAAYkDcgQYAQgAJhYhBH89ZIJKwLa4AJ5QUEvAiW+1aTWVBQJefPRn
AhsCBQkDwmcAAUAJEEvAiW+1aTWVwHQgBBkBCAAdFiEEEgm1FJzVAFJ6QpfDLEv2
gMtSltAFAl589GcACgkQLEv2gMtSltBdoQgAwceHcNY2pNXoWHkIV5vAlO5NJFm5
0A2xHmHs1WvQ4kTZ6juf38bT/OhwivTdh3JZ1Byl5fEG6hTEcKe3//Dlse2Fn3sA
j7cIuSFf9Q6pCPsm2wQLaxOKZA92slloQXFwyQ5+ZHfV0UL+0nZR2As82qjfxufy
JUecZZkEItaGqe7tGZusazl5S1cnHrR9Q4pwWR9QXjO0IQIeEYVTBW7M6mDQ7j9n
9WzW/DNQmMNltJKYjR1x5gAMtIbJ3m0dGfmbSD1eTjIj37uSLVGQz/vVkRMQOua8
IMXmIe+nJn0/7ov9OifZBa0U3r6bYX0HxptuZsJvCi/VWLjMxrDdgvavjCEzD/9u
LDkB5dYnISnGLVK37M1NQX5YPTTw3tS0RDumc1JZM61AVLNLN1ilECekQd5IlDoX
qvraNMGJAgP6Oi9SxAP3nTOdkMMxCrMymI+jSOKN6WdoD025vG3LwKmpYJIiwxTg
mwjioelablHFgJ1xUB94HtrussB1YeOR7BHcI24D5fJ6DF90HYaw5QBu0+lGHf05
NPg4HHEMF9Iq4WwwqVzh7lUGj64oRz544G7V5t0wKin8U8dum0I9ZvQY6jg3rpy0
Rn+kLQdZ1dFnG8qI1/wgsJYLrDlUIGBbUgT2bxhInkHeyRImSksWHD5DjEwWFr0Q
xVz+BTDSPtYI78WxSbQCmwAMv2NawI1MJvTMaKFBOCLJZxmukDkfxn4D3gqAW2+G
xIxXHC3oeozrWhdEGzkdoCwopa96zXTThia7uZvyR+Zl/uDnVFS2DOieqSgaN7oe
mKQte4wsRZFwd1qbWb7RI0vN8W7HYhyINVRDU0BzE4WmijJ4yPwEqPMrxoNbiExx
dYo1S+eB+jfh6l4Ll0zjxsJomFfZLPZIWFYepb88DnNrq5OAAvqlAf01hWKtWMDt
gPobAYRgVjG5inevWEtQ1vhSyeHLMqyZZPYkXj4ZcllyBZ+zsO0VGCrqssl0Zbdy
K3A1vA/ED1CEy+vm2mmL1kfz38M60d2x7WA2x/vV2okCNgQoAQgAIBYhBH89ZIJK
wLa4AJ5QUEvAiW+1aTWVBQJegdfZAh0DAAoJEEvAiW+1aTWV+WsQAOy146TTBNhG
HZCzHyJg84n7JRGjv7SX04O7cYzwLETZFm9Nv1yWbTw4UlvhfkXnWJH0Hv669mu3
wHqMiyGNtp6ZUgw/SZ0KDfgiVocDiYM3wiBTASPgrTb5X04rwYt2ie3RgMLpd2IA
FEfcAm2ocUUKfs4aOr8EotBEURtzmL9UJDoAJooeuIZAsi6F17f9vA06GLtlD1YZ
3a3xmta4y+mGFMPERhHGfdUuEeyq3ivWutpT5xms3MRn/6J+eN6eEjTik9F7wiX0
CQT3iMtnuDCxovGg3vEw7Q5S9ia6lQIqqXIyxwOKm9XSNr2N5d5BTwBBGkb99O79
mbnIpFq08fsKROt8kJTafwI7SqQLJHI7dFzLHKtaG/y4DEJn+soQ7RBqf6IRjOu2
6xE1oq86McReRygkBYF68ZFegHZwk6p2nk/OlaaVl/SYW/Fj826Efs7L/uQ43TRJ
KKavs2w7SYM6fPASfdTS76U+C+L+tLq+MxpzAfRyDsmYLNsfF8KsYHGmdwvYDZ7O
CYsXNBoK+dF+5XacT5Dq6w/zQtWsrlQt1JKT82mdLJBH/4d+8Oh9jmqQ305QDyTA
IxKi011kVnh8oUSpj7WOr9Qn+KUzyqB+FG/5R33JBFVLFeWwlGQEZU5t73U0ofiv
mFYZGoSj1C6JzFCgCIbXhV/A0gICwH1WuQENBF589JEBCACTVOG7TilVy3IMEl79
0RZzgk2627v6uiboSlSYnyl5cAk5KRRb9AUk5Hwv3i9/sy4LQnB4z9bbeTX6/o2h
+a4QsNiBEY79AIIgAqf3nq84DLVzdmJe2BGnOyRHNxaSOwoSWZaQgVtLbSfVceRi
P4DaLQzs+Kx00tTUYrVq8m8d8+OD9yz+WAC530AlBFp98fTVWS0KMfeKgCtC+FLZ
giVi5efcg66vIqewZa2KpyIoZf3PDuq7yxHDqcAu2cSLM1vtkskg12y+/VWnC5em
jK3vYZGP+uZcFHxnIwvQfhhjkML4cEow/qGFvR4Izg/z/1oWSF/vijmPvs4GQMME
9vW9ABEBAAGJA3IEGAEIACYWIQR/PWSCSsC2uACeUFBLwIlvtWk1lQUCXnz0kQIb
IgUJA8JnAAFACRBLwIlvtWk1lcB0IAQZAQgAHRYhBIavTvASI9OiUqNUcyjbs49B
moZ7BQJefPSRAAoJECjbs49BmoZ7qooIAIqJdAGZOqxWTLEOHTfIyhmnlv6A//Zz
ggU0AU5EaIIOtBH/sXYDn2plO8du9d/daM7/02M9tIHYINN27iLVmnbDIYAEbJOM
P2XZcmncKtZsoVYZueYmqBDVTqrxoGd95wNK3ju26QATJeoFg37P6RtFFgY3o1mE
pVup2lyivWYTx5/9EEYs3E6piETr8pVYl9Vhh4vAL6d1e5QeusMPJ8I1cQgQ4bix
Dv7XpzZl2GXmrEGJIt+/+OlR5KBLUxJOSNmZj9XE3dmaGWB+0rSqsfRgRxNy1+me
iNX2HDqtu2iUuBdEpOkwVeuimKM8syQq7FAb9wUdWZ00gTAf1qq2df3k9A/8Db/u
YJz5CQUhXBjDq5zG17L4hlDsOPN0/y9flchCQ67a1P4YD34bs7tiF01RyjlSu890
bDhIlii8oabvyoERKw1SuPv5DGpkySzaYEI+2RpegmJ41xnn+bS7thYa595ezfR1
AxmZjqBd+V85h8x3WecZikgs/vwOyiKFOCPWjhCSr6gudsQli3Afc90KWkYvF+y1
iWKrfxwln7IVM/IKSPz+zFT69wJE4ex+LKRXqnQ5I5FUiRFlPoqR0ZG1+3SvLrZx
ksTr/POP4G+vXvxJe4p7pDEUBUuLrIfyRUn/Pk36K3/OLqbNgpQ5T+cBWKE64ByU
4RvqcMtxkt/6pM/lEeQ+DtcZ78EwP5luzjvh19ktCqjW2Uky+tt82fTkkd/E4gRn
xlGt3C78h4X6zudeLkjkZZIcrSzHXDFQd0x9uY6fGgzITaa6tsF9w5kpRaq7hHpS
esKMRIKX7e0hCVPsp41GQCRei5IW3DA5Cig5rLw2pSr12os8JyTdNcnZry+cGWF6
S81YXUNUUg5lJbg7ErpNMDBLUn4+BN5XQnRIbVy28W62EG1b1YVCAjf+MSIxGFEx
4HDkakASl+9GCmsJoYnX5tokfqC++1UKBG4DSqoEL/Aiqc2Sk5bhIO1GEgxcJVdX
e6NUgDxI3emmsKuYDk0xmGnTU2VU6K1a75y3YSGJAjYEKAEIACAWIQR/PWSCSsC2
uACeUFBLwIlvtWk1lQUCXoHX2QIdAwAKCRBLwIlvtWk1lXgKEADcbeM7w23bM0/L
ycxlJydp8OmPhlTnikiIm+ytPcHIL0P1WHXRU7igHvUqLO+4dme89w34ICcvn7n/
OeCWtwAsFATytWKfC6cnX1lYrRHCQNSJCZwoU6Ae5vODl59Edz0N4FbGbijQu/lY
0xuojEEQS8KDEBZrO8EVub+W/6hRHYwn4zJ9mxEh8UoJgfDj6cz2jgaEi1qWn7MW
1RO6fqzcQvRIxks2i7GimwGjtQY1kFIJeWfyBVBfZ/r9R5N66YzlNiyjx7ZI/A/d
AbmvHM/WHj3NpeGKrB6LS4X+m0RTs/A6FW+JUjfoLD0XHGMpCaXx6Trp8nvzu99c
QQQHZwOm07maGDpgciLZz2+rfvJsGrRpCGHZWnautlWx7aGWC8W6BlAd/PxsLMYW
YGlqgS2WZ1PkdqpqR6ce4SSTQvpQ1FlClnE1J4qAfS1Qg7JJup8I09HcLbLAS37k
ZwVOU8ea8KNoNYmLBaJy8EI5JU72Nbqp1QJ0e8dDWW3AO5ux1uohe2oCqjjo4sAe
NpZAvCLmkOw+EXNWnmORuDnMLyPVF5gFl5akZwsnCCygUI6aFCb07lrU/v8TvuqQ
90/a1mZz6zf1V2lkN49i8zArPC27npRxaCcaE8GgnKE1jGxhMnGjNG/g2MhSm601
RmnvZBsci8LXXscaQX2wHEyBXL68o7kCDQRegbhYARAA6LZ2AXftPUizUqHHQaPu
UrPS0H+4C5KcF1W4SY413wlHgq5mdjHvGU4vAIE8+ZpUio4Qh8EwEGnQhtug6pv0
i3lhmV4DP4ZHceu52EU2wAqv9z33lHzUTv419HZt8QaOyZNWgZUCIfPMM3JOEKA5
LrYo3rH9RsmRhRGvHE98oLAR5Tg/AdF//b6bDgUV44765u1uUEPWUyki1wo+kav2
qNtVT2zAncuQFz3frxSPOViyT6Um4+iO+8T2GIAKV6x65sqi3FQukNAFqIp/fdkU
pMFSzCWzKm9Pb3JT8x+5adiMvfBlk8sPk6fJh/zjWuTQBWJd+/LdSMnaiiyFFyfP
FZX18FuZUtF+8Dws7BJKlUC+JonUuu/ZjSduC0wCpcWwtJwMKg5EPXSRAYZqTUQZ
mq0NG5v5/yVBtUW0QCEDcLM9YCWdyxAnSEaRSA8m4evXlw6+HfwK1n79n1qUUl6+
TL1pejB540EoFBd10IdD535Xby7zLitV3trJmYILLGeGpBRAUj2MFLFFGJgfaDM0
m3yR1CbXuO7Ns/8Wyi8dIYV3oP2eliR/9UcTyhtoX2MszYt9hRuUtAf7JRiM/y4e
G7SicnXIgOFS+MdB2Kp9qWX9HZS9AxNBDjOWWFbnjO8gpumnpeMWPvobxIyX/ZK3
rieTAqioCrv2zCDn0tZMA+MAEQEAAYkEcgQYAQgAJhYhBH89ZIJKwLa4AJ5QUEvA
iW+1aTWVBQJegbhYAhsCBQkDwmcAAkAJEEvAiW+1aTWVwXQgBBkBCAAdFiEEYnyG
cuQxb0UaNwNHbQLzIy2c7uoFAl6BuFgACgkQbQLzIy2c7up5mg/+KBvrr/q/ypv/
6w05wCPG2jmsb716v91sBSks/RvQmjHOPrajNKbPki2dHvhFQc4uXYitdcDrqDly
KWolZPUq8kGQ1/O3IqzBYZeCmUVL8jCkBrAClGX2kGeuNvfE3yqsT8YcwnpWwnJx
QNV5ygffL5Rqs3AAZ4kOtfh9UokcYn0MhOmX0FPrFKTsjlgjLb1YVbDreeN1iXWF
FILNIubJRXXUYUQF12bw5+qCLeJ7AaS+sQjHoxoit6bhl2MDBY0f/79Ha5Ms9ctK
lCSNJVEswIouv8CYUgpIaItXjvJbsezewtj3qm3sbfVtEfl/gWpPh1wboKdgbwVa
3Hv4J8BwXj9qw1lWfna02yqFNdvgqazMNbWFGv+esubXyldEAmhzRuI1QcYQnv5T
WbzrKD8CdKVU8zgkl9EMkNe0dG3ufUo/lBYAuTPqKOCbBq8zJfZlKr5DeASb6RYK
3510IDJwg4bB/rE1ljnGN9tc+n6yMpJbaM6snh96zEyyynB/4vfngzF5zngIy2a/
27XVGTZl9MHD6oZsY5PBGzCg+77P/Gso60z15AAeFoVTKyvT9FyOooVTo/N30JXp
/hj3X9rd7Y5CdFUYDDg8/ICGsQ/4L9W8JMz4IBwWVWemDlGcPUAS8gQ8/41tU2xh
pco1lPZHBcoETVji/CsCsGHtjUlBCnzYHw/+K4JXNlPE8+O3ESPk8Ut22vZISubG
BMjHeei/HKaTb9KYaVZlJz50uCuxk+7hEP7+gZfO6mQbEZezpIAbMFylTTPzCeb7
C3nGhwqMmdgWvjfSFwVYZi64/NacImaWfzYVJ0+aKB2A4b+OeYff52OAoWtJC4FE
7R0SCIfSgJXt+yMSx+DjrFat0jRvX3q8guGgLWVEHDrGl5ar+6sC0flJa0ZIyY34
Krp7O90leLnBvasfVhlmNwTelHt7UDumTKPa6RDwdSknGluMA0tXvXtrqYXl7lSv
YKz9p91VHZWUJA39M2xZ2yqKoOOyNiN/v1ctf/s78e2b62HNmuN5OJ7jTa5Sn+l4
u6WmQJCUL3pn1BvMbCju2WRmWbV0OHFx3VuyyKRR7YyMrOaGSn++kdEwHx7jVhBU
XvVD1Q6rqhWeHzyxyEBQZVRIlzPKCw9En0dPQvgfno94h5ApjZruoRIMsLsrcCxl
A7XVn1mYxaIdS0RUj1pEDYCzgu40TTOFtuU0G0dXBjdX6QlzpzUu7wGuG7txT1dM
/aIFnWV7RFtJxnagL23DRixZTNfpRRoRsmXDAVKNT+rxVuckjfrRXgP8WoQEVJ8z
GL907kJ1tSuO7sKz+noIHAjc73wpj4Yif7o2U9pnrfvOXMLvgD67h44c1796EdYW
l1qlczTMdWKphpiJAjYEKAEIACAWIQR/PWSCSsC2uACeUFBLwIlvtWk1lQUCXoHX
2QIdAwAKCRBLwIlvtWk1lRg4D/9r+9qbJhKhtkX3/rIrzZSi8pa0MpRAa+QNI50p
/h0utk3fz0FIRGAOwroigM7kMPk6B0Hzy4RbQcKrMGzdb9BjBuEtl/92bFXCgJ+i
GGtOHrVHlkYx0qVShyQI01PBkmvwgLe2isyqfAQQBsrL+x8ZjO+LcWe8sV4rAokK
+PjpkRZvyNSa+CUaYIVvKM/dbGGLxNXfIlQgN3twbGTXckWdLEZh3ES6QRjqT1yE
uWvSlIX8uTN8NDnntShCJhbQ4PWjbRcs955Vb9PUv2XmwtXgxUU7hOijfvtzjMhF
aovYAjRCwHQKOQl4oj/9D6QfCON7WcYuFjC0UijOyv+XN3F7XZBTkvanUNYLkEeQ
0XyKIaJ2EGALCb7LcFujP9pHxoYgOf8H7Hf/r/aETmuFG34xNioDKG5s3WmCUz58
v0vwt/DBas6ULk0o1J34MJJh9BHr86k0emEncurxBSqCFEgeYshAcfdmfke4BGQd
V2V8l+KeA1+GjP8XLeNeFms6fzngscVf79lAvHNJMbYNZoObarVaCVGHss54R/BO
CVJ3+J7lKNqoGJBcRHhO4iCkNes6zIPM2bHowbl20U7v6GdQyH/Xt/rVwy8vZamQ
9IYpjwIlnJA1FG+osLKN0UUr0BekexBHib8TTAmwWOyzwDbwxKsKHXcENTfrKs2N
cmsi4rkCDQRegcAOARAAu/+CG+oz13jJdpwkpfmuM4SNnS6TfFD32n0yqYmoZfvO
SSDRrWd06uBPvL9fKEKT4IUSfHZ/NLl+2eiIVJyyBlNevKc2Cc3a+rsQCa+T3xyA
zD6JuVBkhcXEji0YYfmsMOJ6FY2l8Wr7UD1smwmmX6/ht8iUEQZHDgrmLpB5EIcD
JhyAJ0LerGFF/ws4VgP1xr4NMbhAqhouqxrmRShZ3AP/j87YRJyj/bXrPLNHrDzU
KW78/xE4VWUs0jH2FAudTqi5s/p3l8/Dapj9pLIP7oqQiDipecA7BXvtXg9jrghr
0eeMjGPQ1P22kQ01jWair38kQ0Uce6qvZP3vASbfzXU5SxYnu1QLKW0uQhaug3ND
mRcO7VCbGlf6dbG4lxSc+zrkY8Atn7mCK2ClqXbDALtxUytxZwyuLEYCgAo0gyhu
NrVxgf9u6Qs2iBJyxrADjGYbrrg5MvxMlKve6cHlUEl5aEKu8u8gC9t9oDC1gOSM
szhF0X1Rh0ctvhlJFrTh2Q1UWtwIKgUcySVD5Q5LmG5WHUp0CndBK5ZKST+sZabb
Ghl1T52as9r8ZydwIkMXSXD/c9tbmquuRecqY122tPm6/9uIlMUmij2j6fcX7/Z/
ez+B/+biErNGGd71YxBmFRPt8VoRnJ+FtIlVkUUC67js8h4WHO6WHVn4HDhfqTEA
EQEAAYkCPAQYAQgAJhYhBH89ZIJKwLa4AJ5QUEvAiW+1aTWVBQJegcAOAhsMBQkD
wmcAAAoJEEvAiW+1aTWVNVEQAKj0B1COtkaX0FvjQTNvWzMYRmPw11SZzAqDNy4r
i5aDNB+jpSELp6tg6o8alYpwYZqG6XSsDIFcLf1RgEweBbmhyQ3wCjYiWdQgNHPz
l7TmRiM6f6zrenCKqmOCVmBVOi/nWiY5bgNs/wmZOmHLr1RLArbHTR5kcIgbWZ87
MYREgBlhRJB6ndvKnZrxlbD7k94OeGMMcVMJA9FVOXpro2fn1WtTrrfvuDeBxpTt
EgChuNTkVu89odzBV/l9S88o4dOnofGXk1On1QoXPxOAGpiu9w9gKIHy+P8PNdlK
GnizyeVjUbGkJJSn+jfJRvYoePQ4PE2+tHwqouXJCKpIgDkGqJkw6MNmkI0oFH6l
lSlTt40K/sE/qV7V2r+bgBbNUWm7mIZMc2H6zhWZUw3H61yPb8Jm1q/snp9H2COq
ysplPttyAIWhZXphz2cn2NarhGoqTbVNyYxAjuYLo4gcohW/3DfR3Q2l1y6Wma+v
QYcRq/0Fl911zzGpBXmRddMQpcgLgnGPXaQsZZFfeOE65eTwFFqYVQe1xrCsg/XR
Fb48QHmAaoe8hrItvFUUIVbcD+/ZiVy8k9rdOniCe4gjAG2c5g24YnOkUEFHrnqT
hW2geHtvQvfJTAx6buVkieG5UW3UYhVL4xKTepkUX5nAc5hqgbdOUd2HJ8U4b5TF
+nySiQI2BCgBCAAgFiEEfz1kgkrAtrgAnlBQS8CJb7VpNZUFAl6B19oCHQMACgkQ
S8CJb7VpNZW8NxAAzAamVR9wfxQsAzrD5E9Yg6j44OqvxVS/GKrbj6Hpf5dLag9c
E1yfDOBd0T2brZU9j1hqOUzOehuBs9FMAv2g/mQ+AqWeWcJ1euU48PKj37xEBjoD
AfUCrnnvcAMFxYALAh/j5d5KdGbtZAeD+GDgoSPbA04tDrndMuwrKKCb8Z41wvL1
dmzr08EVibXLxC/oP2aaL4crD3c4/7vNB3F7cu6bwj8Y+oC3F+A78Jq5l8AH7NDJ
ax4dMse/SKGosMfgo26aflolrUxsnLjiDJ3K6QiIbk6ZvpeO2mbsmyF6qWPTAGqf
FbdnLE7HYWR/yW5cTgwP6JihCo/2+mdY3ZZhBrWM26zDKzlxJk9SG7DB0ebinVFN
GR1G/y4s05DaaLaTdpW3FexgX4ppQaHgjr4MLU7zHNUIyGagseVq9Q2KmxmRJ9pP
RP1lqSUWM1F6qB9oGrZwLLHioWfVMFhoNtRaKLpYSMgr5y4lORsVi/nMm8IC1RYr
pXOyzWv6HhfulGSukI7QIMr8CatWHnNVYTlH2ShbW9eTWI89DkqiOHUrdG4BkEMt
AnU9hVXQ0Z/NdqY/Cqm4pvkobCGHuLu3+c5dQTLiGGtzXRqsavIlBa2P1UcHFwBh
tbwpmydpOiLTejUucz/AXxQTmCB0sCVzlaPb89BFnOagm7WZQtGROZxKKJi5AQ0E
XoHPGgEIAK7iUe0da92HzJOKU5WYN/i4q+nI95mMdUO1PtwjlHHtvSVfgIIsF0FU
rdUCPYvyjqxvn+wEe29jgSjfImVImaBHh9iuCZVnK3JR+q3CrIUYop5zoe82idyA
P+m5YKqd7YcnFKS8DEG9tudhqIA0iZ+Gq1jYLCAIamZjaKtRoVAnxF7sEcphLJ3f
vwDoLX0Mg4tvDGuETQjV5BbP/j8/LTkh8aheeVm6vZotZXET2PSFlH7+cfokb6cn
sTykYNemZkrJLQW0FzaCid5v0vL3ux6XKG3fVSTXUcgSVgJIVIGtYGlPz8nYqMGs
09PUWrcVYf3THP8qvZNU08UGpvlXDeUAEQEAAYkDcgQYAQgAJgIbIhYhBH89ZIJK
wLa4AJ5QUEvAiW+1aTWVBQJh+nbKBQkFWdswAUDAdCAEGQEIAB0WIQSbrYubvRy9
7eNEMpKQDzxJcQhgBAUCXoHPGgAKCRCQDzxJcQhgBEwRB/9b+g4+emSVugf+3TFv
Bri+pUTxNjSAp3BLk6PtzbHoQj4cVqS8nYbxBfImX+tKYh3RcVNOf1RAcd8uk97H
8k3KJHrNUy95j9fdlLXJm0SLlaad4KyP3ewc3At+rUj/yJ+s2J7TRzEAwq8T2CAW
ADAhdqpRQEIThVf0GhY3eICBHF5rxVt1V69sy8dJMVsIlSCod5k8kdB8VkWeSolL
VIUlZz4sYMH144j55XPkNpukd79eQt3kfQz0tVzKuCRVYTSGn7yny5V/oOyn2x40
lj/G0fG1ktB4tbKBD1YZgmq2L0TrdHFc9UUiWAz/TR9sCyT+gfoOneAF7NAEoaL4
h5cKCRBLwIlvtWk1lTOHEADpZkH07qhKt8UqA/UtzXiFa5oX3rpy6Hjavw38AZ6J
N7HcY06KjJSioXYb3GRRIIL76yeuEhXu51/m8fTXBjGKWSWxxllldKmD4j7uDjO2
/mFULBfawPp1j1jovZ/A5ikmdVrwHh6WDTiT+A7tfuqpjRl35l4kqZN7mh/89Tlt
7k6jAGEgihW636p58ATMDZUvrdLH2y/XtnwN6jwWz/2fbFCG+eTdWZNLQwEz4ciw
j4bm8PjqB12yuXUEwvVlxGoCq2PoNMh+KumLVlpVEp7R5yDJvcfoR9uoNjoNxuyt
GPJHuhcxAM8OtdUgNGTDZE5ctJNY5jaL2SHzeggUt/ox+u8cIUMZH10f1lk7ffcz
MhoOgU+ANt1vAyN0TY5WkMmtI/7o1j2xra+MfpTAz5TQ5Q4q5OJ2G7DjS2IVqYq8
SqVJHIiYqj42NPJY6VLlzw/7JHIo3pZRzf8q5giKYXPl1vvnX1MV0KfuuDPN/d3h
+N/tGU5/iAsSHBaG5PY2FmuEtCGFchYGCbEJN7doBVVM82/FbCYLTNvh1+WRL5HG
usaR+QVV+tCnxFzAm5ZRnMCGDRPsJS/S6qU5Sc6dIOUj9CYjSvhqDRvyXb92pfWS
8X45VQtUdQfO4qnaF8L1PBQBH8g97nGmpJO91MDl7uDDiz2ebV+dGnT6Z8TEALh9
a7kBDQRegc78AQgAsnlJ8cyWrMt6Zp94RM94SzZCUuldGGfJo7cFyDqY2pVXqRlP
Px0bxbsP7cU0qbewu6FoQiHv9umylIZabAnlSARrQpza78jhIMiuXpcI3v8/Z4IF
GOsMGh12Ox2RWqL1z/IcTHSBtnNuRNJYIyzDZMRZJOpbX3tkqJxeGQXXQIYat8Js
WZE4p4N+ErRzij97VDKmxXBRs3SPGEbl+Q6K6khb3YB8PsfJz/ArbLh5Dyc8HF6b
Jqm8InBJelI6wTPrZheuej+ColQjchrNeN/FWbDuAgUqRKTBsmjMVEKdlzkUn0jB
EMSecokqNvRkJ+/m+GxlcPJdRiUiqfvi7Rz53QARAQABiQI8BBgBCAAmAhsMFiEE
fz1kgkrAtrgAnlBQS8CJb7VpNZUFAmH6dtIFCQVZ204ACgkQS8CJb7VpNZW2Kg//
RmFI7YtpWJ+tY0HC7I2v5NBnI10cCUh/KO6f6FJ8TpLrGPm351oXKqzfPrG3slZO
awBfRmFXRnwVhdAgngjni+2wayVePlokdSgGNonWh2C6XqWfkwatkZDsdcy9iyW7
9wIYOGrP4DPZZoP1kGPad/f4Nf+NLF2qzoZzPJgu7FCXT1A5QRrc99JDrPqjEBIU
ScoseWM7uJ1OZ7R2g+rNZT9dLLRN/sBZ9bXzcBkKzBflnYyNiYwLOcB0eM4bNNdv
bp8dQDtRMKfdw4vAAdaaAV0RQ3sSApKKz1mLJQCywLUifakA3I0ihRFXBnao7zyt
fDzAWSCywN+gDyREN+mtDglW9PK8TKSCjN9WQDAERxFgOqE21IPJnhHwPB8MVxKb
iiqRbMYppCtZURw31JsmmF/e9AyxTGAPXjKUPbU3tkMXgUYEQGRNHKJJgYmZEc9S
AdBNamla09JARAoX4HHClTc8dJGUoa7+7Y/74dbHaw1TntY8pTtb9/Y5eOfQVUGr
yXltrq7cQl2UN1wkkGKZ5dzUyEhg1czKOMiu2iVTGpRpz2DV9u1doMBVLkP/LmJs
7eLi4UOLk9ehEzqYHbH4+WGtNXXES0IunDE1+yxQYBj2KBNmPL2dx+fQZ8cg9Ot4
SYtpY9WWd4mDQMF6ZdD+KHPgj+JhvNNcFEalet/Y5gi5AQ0EXoHO2gEIAL/OJqy6
m+TfJDpOpv8mJDqA/B0rMNHbpLlbnDpvLHcVgTO2SIYuLzCwUL6Y5auKvBVOZrcz
RM7UOdiPBe+xTuRKhBBqtLxsb4Kg8iJ9wXVrlIR4ko+J+xhQgHsZIxRjjKiZ1F7v
4B0/ydKqUd2iKPp83/6t9Sz7edOurhMCQXKDmGpAFCnfYOszU5yHkpcy84JqTvlN
CjGt+krKGUK6hZWi2e/FYwWB8IZRgLpDaco+ffLUS0Wz1j9mLwflXMuOuGZslh3v
JMDoc8GoOkSdpov69cCio8LVXO76AjaM66aGD7h43eR9vM/lLPSWOGZgqkcE8TT6
w8owu1ZkFb2BRKsAEQEAAYkDcgQYAQgAJgIbAhYhBH89ZIJKwLa4AJ5QUEvAiW+1
aTWVBQJh+nbSBQkFWdtwAUDAdCAEGQEIAB0WIQSGUg3lUEqOqSVcZsSHscmYzhiE
rQUCXoHO2gAKCRCHscmYzhiErQ9bCACpBK/SgZY1yftLhSaHolOvIInoEA+PO8m+
q90w5QlIicdN4O/HgaaOG3H8IZUrSWVOdU4KCISAHwHp2VskR7nbicQJmCGf4a2h
G8GuSz7Z9tacJ5+0ZzmFs+NPE/DxLq662HiyoR0seloBaotynD9NxM/ihOKlO5dO
82SFd8YBiwt+2rQR/0cXrn4U/gcle0HV3l8gE7ds+XvP5Sdea1Ryf/sa16wvaSzq
4dyMzUPQdnRoxGOE+yy5xE462/cpn9TaQShOoNt+Xipl/lRt98wRqXtaz9C4HVxf
2YoVRepkfMeiDRNPXRAAS3keThb7wKvaR1NRcc8Pl1vehNPG6t6ICRBLwIlvtWk1
lUM6D/0W9bPsgRyT92yVh+craV7Br7+f6k50Z8nJe4BNYLCg83w2vh/9yP5lYs6d
RWUfj9Nbs5lytUaM+tj9ZxROCh0FZ1BO0vtVRwj5Swxi/Dgz/bt3Rz/1OEVUR9zl
n1noCaJQWPKW3vyrmkCChzJkC9CJcsgbxQT0mddNNCoPBxwcIHxSUFhtEb0405yq
LwxuknHWZ9dnMKa+oXDsSCB6NVl2eXYCG4VmBxwxn33LbJxpTFm24OS3tBlA/aN/
PsCWHcUt7CYvaoFoqCqgR3igFqArv5emsk8PM8RuICDl9tsviVgwnKZRoAAGNfWZ
oRbaU4Kkc7Yd7epIsq8UccpBgt+e7WtIRNkpIkIfhgN6y2NnFzQaytwAZud8j7TK
13TSeMdGzcA569KN3Ogl8kMGv39/5ZWMrRe8wL2fmseovETqPLnubalAq+HyqS29
qdcFbuJSZXmD+nr9EtEJDopi+5lyw8cjDXQimsjpACc3VLWwT63ki3tV1p5Q4zNS
sSGMmbKQKSQq0v4M4wEAhc8uKu5BpPoyklqEgUm76kx4iPgnWIq3+xaTP4Et1/Ug
Incd517/6+3/gvDMStOeCr5mLzzOtkK2rOe5JOUe+Lyoi7+a0S0DmcwRTvx0bAnu
viukq4Hz9wW1a39FxD25ZHaa84Yvuh1mVNrfgls2vCEGnmAygQ==
=dnGv
-----END PGP PUBLIC KEY BLOCK-----
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <CAP7CzPfLu6mm6f2fon-zez3PW6rDACEH6ihF2aG+1Dc7Zc2WuQ@mail.gmail.com>]
* Re: your mail
[not found] <CAP7CzPfLu6mm6f2fon-zez3PW6rDACEH6ihF2aG+1Dc7Zc2WuQ@mail.gmail.com>
@ 2021-09-13 6:06 ` Willy Tarreau
0 siblings, 0 replies; 669+ messages in thread
From: Willy Tarreau @ 2021-09-13 6:06 UTC (permalink / raw)
To: zhao xc
Cc: tglx, peterz, keescook, mingo, joe, john.garry, song.bao.hua,
linux-kernel
Hi,
On Mon, Sep 13, 2021 at 01:32:51PM +0800, zhao xc wrote:
> Hi maintainer:
> delete blank line between two enum definitions
Could you please make sure to place a subject (and a meaningful one) in
the "subject" field of your e-mails ? There's nothing more annoying than
receiving messages with no subject and having to read them to figure you
were not interested!
Thanks,
Willy
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2021-08-21 8:59 Kari Argillander
2021-08-22 13:13 ` your mail CGEL
0 siblings, 1 reply; 669+ messages in thread
From: Kari Argillander @ 2021-08-21 8:59 UTC (permalink / raw)
To: cgel.zte
Cc: viro, christian.brauner, jamorris, gladkov.alexey, yang.yang29,
tj, paul.gortmaker, linux-fsdevel, linux-kernel, Zeal Robot
Bcc:
Subject: Re: [PATCH] proc: prevent mount proc on same mountpoint in one pid
namespace
Reply-To:
In-Reply-To: <20210821083105.30336-1-yang.yang29@zte.com.cn>
On Sat, Aug 21, 2021 at 01:31:05AM -0700, cgel.zte@gmail.com wrote:
> From: Yang Yang <yang.yang29@zte.com.cn>
>
> Patch "proc: allow to mount many instances of proc in one pid namespace"
> aims to mount many instances of proc on different mountpoint, see
> tools/testing/selftests/proc/proc-multiple-procfs.c.
>
> But there is a side-effects, user can mount many instances of proc on
> the same mountpoint in one pid namespace, which is not allowed before.
> This duplicate mount makes no sense but wastes memory and CPU, and user
> may be confused why kernel allows it.
>
> The logic of this patch is: when try to mount proc on /mnt, check if
> there is a proc instance mount on /mnt in the same pid namespace. If
> answer is yes, return -EBUSY.
>
> Since this check can't be done in proc_get_tree(), which call
> get_tree_nodev() and will create new super_block unconditionally.
> And other nodev fs may faces the same case, so add a new hook in
> fs_context_operations.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
> ---
> fs/namespace.c | 9 +++++++++
> fs/proc/root.c | 15 +++++++++++++++
> include/linux/fs_context.h | 1 +
> 3 files changed, 25 insertions(+)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index f79d9471cb76..84da649a70c5 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2878,6 +2878,7 @@ static int do_new_mount_fc(struct fs_context *fc, struct path *mountpoint,
> static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> int mnt_flags, const char *name, void *data)
> {
> + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
> struct file_system_type *type;
> struct fs_context *fc;
> const char *subtype = NULL;
> @@ -2906,6 +2907,13 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> if (IS_ERR(fc))
> return PTR_ERR(fc);
>
> + /* check if there is a same super_block mount on path*/
> + check_mntpoint = fc->ops->check_mntpoint;
> + if (check_mntpoint)
> + err = check_mntpoint(fc, path);
> + if (err < 0)
> + goto err_fc;
> +
> if (subtype)
> err = vfs_parse_fs_string(fc, "subtype",
> subtype, strlen(subtype));
> @@ -2920,6 +2928,7 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> if (!err)
> err = do_new_mount_fc(fc, path, mnt_flags);
>
> +err_fc:
> put_fs_context(fc);
> return err;
> }
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index c7e3b1350ef8..0971d6b0bec2 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -237,11 +237,26 @@ static void proc_fs_context_free(struct fs_context *fc)
> kfree(ctx);
> }
>
> +static int proc_check_mntpoint(struct fs_context *fc, struct path *path)
> +{
> + struct super_block *mnt_sb = path->mnt->mnt_sb;
> + struct proc_fs_info *fs_info;
> +
> + if (strcmp(mnt_sb->s_type->name, "proc") == 0) {
> + fs_info = mnt_sb->s_fs_info;
> + if (fs_info->pid_ns == task_active_pid_ns(current) &&
> + path->mnt->mnt_root == path->dentry)
> + return -EBUSY;
> + }
> + return 0;
> +}
> +
> static const struct fs_context_operations proc_fs_context_ops = {
> .free = proc_fs_context_free,
> .parse_param = proc_parse_param,
> .get_tree = proc_get_tree,
> .reconfigure = proc_reconfigure,
> + .check_mntpoint = proc_check_mntpoint,
> };
>
> static int proc_init_fs_context(struct fs_context *fc)
> diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> index 6b54982fc5f3..090a05fb2d7d 100644
> --- a/include/linux/fs_context.h
> +++ b/include/linux/fs_context.h
> @@ -119,6 +119,7 @@ struct fs_context_operations {
> int (*parse_monolithic)(struct fs_context *fc, void *data);
> int (*get_tree)(struct fs_context *fc);
> int (*reconfigure)(struct fs_context *fc);
> + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
Don't you think this should be it's own patch. It is after all internal
api change. This also needs documentation. It would be confusing if
someone convert to new mount api and there is one line which just
address some proc stuff but even commit message does not address does
every fs needs to add this.
Documentation is very good shape right now and we are in face that
everyone is migrating to use new mount api so everyting should be well
documented.
> };
>
> /*
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2021-08-21 8:59 Kari Argillander
@ 2021-08-22 13:13 ` CGEL
0 siblings, 0 replies; 669+ messages in thread
From: CGEL @ 2021-08-22 13:13 UTC (permalink / raw)
To: Kari Argillander
Cc: viro, christian.brauner, jamorris, gladkov.alexey, yang.yang29,
tj, paul.gortmaker, linux-fsdevel, linux-kernel, Zeal Robot
O
Sat, Aug 21, 2021 at 11:59:39AM +0300, Kari Argillander wrote:
> Bcc:
> Subject: Re: [PATCH] proc: prevent mount proc on same mountpoint in one pid
> namespace
> Reply-To:
> In-Reply-To: <20210821083105.30336-1-yang.yang29@zte.com.cn>
>
> On Sat, Aug 21, 2021 at 01:31:05AM -0700, cgel.zte@gmail.com wrote:
> > From: Yang Yang <yang.yang29@zte.com.cn>
> >
> > Patch "proc: allow to mount many instances of proc in one pid namespace"
> > aims to mount many instances of proc on different mountpoint, see
> > tools/testing/selftests/proc/proc-multiple-procfs.c.
> >
> > But there is a side-effects, user can mount many instances of proc on
> > the same mountpoint in one pid namespace, which is not allowed before.
> > This duplicate mount makes no sense but wastes memory and CPU, and user
> > may be confused why kernel allows it.
> >
> > The logic of this patch is: when try to mount proc on /mnt, check if
> > there is a proc instance mount on /mnt in the same pid namespace. If
> > answer is yes, return -EBUSY.
> >
> > Since this check can't be done in proc_get_tree(), which call
> > get_tree_nodev() and will create new super_block unconditionally.
> > And other nodev fs may faces the same case, so add a new hook in
> > fs_context_operations.
> >
> > Reported-by: Zeal Robot <zealci@zte.com.cn>
> > Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
> > ---
> > fs/namespace.c | 9 +++++++++
> > fs/proc/root.c | 15 +++++++++++++++
> > include/linux/fs_context.h | 1 +
> > 3 files changed, 25 insertions(+)
> >
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index f79d9471cb76..84da649a70c5 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -2878,6 +2878,7 @@ static int do_new_mount_fc(struct fs_context *fc, struct path *mountpoint,
> > static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> > int mnt_flags, const char *name, void *data)
> > {
> > + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
> > struct file_system_type *type;
> > struct fs_context *fc;
> > const char *subtype = NULL;
> > @@ -2906,6 +2907,13 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> > if (IS_ERR(fc))
> > return PTR_ERR(fc);
> >
> > + /* check if there is a same super_block mount on path*/
> > + check_mntpoint = fc->ops->check_mntpoint;
> > + if (check_mntpoint)
> > + err = check_mntpoint(fc, path);
> > + if (err < 0)
> > + goto err_fc;
> > +
> > if (subtype)
> > err = vfs_parse_fs_string(fc, "subtype",
> > subtype, strlen(subtype));
> > @@ -2920,6 +2928,7 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> > if (!err)
> > err = do_new_mount_fc(fc, path, mnt_flags);
> >
> > +err_fc:
> > put_fs_context(fc);
> > return err;
> > }
> > diff --git a/fs/proc/root.c b/fs/proc/root.c
> > index c7e3b1350ef8..0971d6b0bec2 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -237,11 +237,26 @@ static void proc_fs_context_free(struct fs_context *fc)
> > kfree(ctx);
> > }
> >
> > +static int proc_check_mntpoint(struct fs_context *fc, struct path *path)
> > +{
> > + struct super_block *mnt_sb = path->mnt->mnt_sb;
> > + struct proc_fs_info *fs_info;
> > +
> > + if (strcmp(mnt_sb->s_type->name, "proc") == 0) {
> > + fs_info = mnt_sb->s_fs_info;
> > + if (fs_info->pid_ns == task_active_pid_ns(current) &&
> > + path->mnt->mnt_root == path->dentry)
> > + return -EBUSY;
> > + }
> > + return 0;
> > +}
> > +
> > static const struct fs_context_operations proc_fs_context_ops = {
> > .free = proc_fs_context_free,
> > .parse_param = proc_parse_param,
> > .get_tree = proc_get_tree,
> > .reconfigure = proc_reconfigure,
> > + .check_mntpoint = proc_check_mntpoint,
> > };
> >
> > static int proc_init_fs_context(struct fs_context *fc)
> > diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> > index 6b54982fc5f3..090a05fb2d7d 100644
> > --- a/include/linux/fs_context.h
> > +++ b/include/linux/fs_context.h
> > @@ -119,6 +119,7 @@ struct fs_context_operations {
> > int (*parse_monolithic)(struct fs_context *fc, void *data);
> > int (*get_tree)(struct fs_context *fc);
> > int (*reconfigure)(struct fs_context *fc);
> > + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
>
> Don't you think this should be it's own patch. It is after all internal
> api change. This also needs documentation. It would be confusing if
> someone convert to new mount api and there is one line which just
> address some proc stuff but even commit message does not address does
> every fs needs to add this.
>
> Documentation is very good shape right now and we are in face that
> everyone is migrating to use new mount api so everyting should be well
> documented.
> i
Thanks for your reply!
I will take commit message more carefully next time.
Sinece I am not quit sure about this patch, so I didn't write
Documentation for patch v1. AIViro had made it clear, so this
patch is abondoned.
> > };
> >
> > /*
> > --
> > 2.25.1
> >
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2021-08-16 2:46 Kari Argillander
2021-08-16 12:27 ` your mail Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Kari Argillander @ 2021-08-16 2:46 UTC (permalink / raw)
To: Konstantin Komarov, Christoph Hellwig
Cc: Kari Argillander, ntfs3, linux-kernel, linux-fsdevel,
Pali Rohár, Matthew Wilcox
Date: Mon, 16 Aug 2021 04:08:46 +0300
Subject: [RFC PATCH 0/4] fs/ntfs3: Use new mount api and change some opts
This series modify ntfs3 to use new mount api as Christoph Hellwig wish
for.
https://lore.kernel.org/linux-fsdevel/20210810090234.GA23732@lst.de/
It also modify mount options noatime (not needed) and make new alias
for nls because kernel is changing to use it as described in here
https://lore.kernel.org/linux-fsdevel/20210808162453.1653-1-pali@kernel.org/
I would like really like to get fsparam_flag_no also for no_acs_rules
but then we have to make new name for it. Other possibility is to
modify mount api so it mount option can be no/no_. I think that would
maybe be good change.
I did not quite like how I did nls table loading because now it always
first load default table and if user give option then default table is
dropped and if reconfigure is happening and this was same as before then
it is dropped. I try to make loading in fill_super and fs_reconfigure
but that just look ugly. This is quite readible so I leave it like this.
We also do not mount/remount so often that this probebly does not
matter. It seems that if new mount api had possibility to give default
value for mount option then there is not this kind of problem.
I would hope that these will added top of the now going ntfs3 patch
series. I do not have so many contributions to kernel yet and I would
like to get my name going there so that in future it would be easier to
contribute kernel.
Kari Argillander (4):
fs/ntfs3: Use new api for mounting
fs/ntfs3: Remove unnecesarry mount option noatime
fs/ntfs3: Make mount option nohidden more universal
fs/ntfs3: Add iocharset= mount option as alias for nls=
Documentation/filesystems/ntfs3.rst | 4 -
fs/ntfs3/super.c | 391 ++++++++++++++--------------
2 files changed, 196 insertions(+), 199 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2021-08-16 2:46 Kari Argillander
@ 2021-08-16 12:27 ` Christoph Hellwig
0 siblings, 0 replies; 669+ messages in thread
From: Christoph Hellwig @ 2021-08-16 12:27 UTC (permalink / raw)
To: Kari Argillander
Cc: Konstantin Komarov, Christoph Hellwig, ntfs3, linux-kernel,
linux-fsdevel, Pali Rohár, Matthew Wilcox
On Mon, Aug 16, 2021 at 05:46:59AM +0300, Kari Argillander wrote:
> I would like really like to get fsparam_flag_no also for no_acs_rules
> but then we have to make new name for it. Other possibility is to
> modify mount api so it mount option can be no/no_. I think that would
> maybe be good change.
I don't think adding another no_ alias is a good idea. I'd suggest
to just rename the existing flag before the ntfs3 driver ever hits
mainline.
^ permalink raw reply [flat|nested] 669+ messages in thread
* [PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-PC kernel: [ 466.271037] page:980000025fca4170 count:0 mapcount:0 mapping:980000025a0dca60 index:0x0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271039] flags: 0x1e01fff000000() Feb 6 17:13:13 aaa-PC kernel: [ 466.271042] raw: 0001e01fff000000 0000000000000100 0000000000000200 980000025a0dca60 Feb 6 17:13:13 aaa-PC kernel: [ 466.271044] raw: 0000000000000000 0000000000000000 00000000ffffffff Feb 6 17:13:13 aaa-PC kernel: [ 466.271046] page dumped because: non-NULL mapping Feb 6 17:13:13 aaa-PC kernel: [ 466.271047] Modules linked in: bnep fuse bluetooth ecdh_generic sha256_generic cfg80211 rfkill vfat fat serio_raw uio_pdrv_genirq binfmt_misc ip_tables amdgpu chash radeon r8168 loongson gpu_sched Feb 6 17:13:13 aaa-PC kernel: [ 466.271059] CPU: 3 PID: 9554 Comm: blur_image Tainted: G B 4.19.0-loongson-3-desktop #3036 Feb 6 17:13:13 aaa-PC kernel: [ 466.271061] Hardware name: Haier Kunlun-LS3A4000-LS7A-desktop/Kunlun-LS3A4000-LS7A-desktop, BIOS Kunlun-V4.0.12V4.0 LS3A4000 03/19/2020 Feb 6 17:13:13 aaa-PC kernel: [ 466.271063] Stack : 000000000000007b 000000007400cce0 0000000000000000 0000000000000007 Feb 6 17:13:13 aaa-PC kernel: [ 466.271067] 0000000000000000 0000000000000000 0000000000002a82 ffffffff8202c910 Feb 6 17:13:13 aaa-PC kernel: [ 466.271070] 0000000000000000 0000000000002a82 0000000000000000 ffffffff81e20000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271074] 0000000000000000 ffffffff8021301c ffffffff82040000 6e754b20534f4942 Feb 6 17:13:13 aaa-PC kernel: [ 466.271078] ffff000000000000 0000000000000000 000000007400cce0 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271082] 9800000007155d40 ffffffff81cc5470 0000000000000005 6db6db6db6db0000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271086] 0000000000000003 fffffffffffffffb 0000000000006000 98000002559f4000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271090] 980000024a448000 980000024a44b7f0 9800000007155d50 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271094] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271097] 9800000007155d40 ffffffff802310c4 ffffffff81e70000 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271101] ... Feb 6 17:13:13 aaa-PC kernel: [ 466.271103] Call Trace: Feb 6 17:13:13 aaa-PC kernel: [ 466.271107] [<ffffffff802310c4>] show_stack+0x44/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271110] [<ffffffff819f5158>] dump_stack+0x1d8/0x240 Feb 6 17:13:13 aaa-PC kernel: [ 466.271113] [<ffffffff80491c10>] bad_page+0x210/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271116] [<ffffffff804931c8>] free_pcppages_bulk+0x708/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 46 6.271119] [<ffffffff804980cc>] free_unref_page_list+0x1cc/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271122] [<ffffffff804ad2c8>] release_pages+0x648/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271125] [<ffffffff804f3b48>] tlb_flush_mmu_free+0x88/0x100 Feb 6 17:13:13 aaa-PC kernel: [ 466.271128] [<ffffffff804f8a24>] zap_pte_range+0xa24/0x1480 Feb 6 17:13:13 aaa-PC kernel: [ 466.271132] [<ffffffff804f98b0>] unmap_page_range+0x1f0/0x500 Feb 6 17:13:13 aaa-PC kernel: [ 466.271135] [<ffffffff804fa054>] unmap_vmas+0x154/0x200 Feb 6 17:13:13 aaa-PC kernel: [ 466.271138] [<ffffffff8051190c>] exit_mmap+0x20c/0x380 Feb 6 17:13:13 aaa-PC kernel: [ 466.271142] [<ffffffff802bb9c8>] mmput+0x148/0x300 Feb 6 17:13:13 aaa-PC kernel: [ 466.271145] [<ffffffff802c80d8>] do_exit+0x6d8/0x1900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271148] [<ffffffff802cb288>] do_group_exit+0x88/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271151] [<ffffffff802cb3d8>] sys_exit_group+0x18/0x40 Feb 6 17 :13:13 aaa-PC kernel: [ 466.271155] [<ffffffff8023f954>] syscall_common+0x34/0xa4
@ 2021-04-07 1:27 songqiang
2021-04-07 8:25 ` Huang Rui
0 siblings, 1 reply; 669+ messages in thread
From: songqiang @ 2021-04-07 1:27 UTC (permalink / raw)
To: christian.koenig, ray.huang, airlied, daniel
Cc: dri-devel, linux-kernel, songqiang
Signed-off-by: songqiang <songqiang@uniontech.com>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 14660f723f71..f3698f0ad4d7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
if (++p != pages[i + j])
break;
- if (j == HPAGE_PMD_NR)
+ if (j == HPAGE_PMD_NR) {
order = HPAGE_PMD_ORDER;
+ for (j = 1; j < HPAGE_PMD_NR; ++j)
+ page_ref_dec(pages[i+j]);
+ }
}
#endif
@@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
if (!p)
break;
-
- for (j = 0; j < HPAGE_PMD_NR; ++j)
+ for (j = 0; j < HPAGE_PMD_NR; ++j) {
pages[i++] = p++;
-
+ if (j > 0)
+ page_ref_inc(pages[i-1]);
+ }
npages -= HPAGE_PMD_NR;
}
}
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2021-04-07 1:27 [PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-PC kernel: [ 466.271037] page:980000025fca4170 count:0 mapcount:0 mapping:980000025a0dca60 index:0x0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271039] flags: 0x1e01fff000000() Feb 6 17:13:13 aaa-PC kernel: [ 466.271042] raw: 0001e01fff000000 0000000000000100 0000000000000200 980000025a0dca60 Feb 6 17:13:13 aaa-PC kernel: [ 466.271044] raw: 0000000000000000 0000000000000000 00000000ffffffff Feb 6 17:13:13 aaa-PC kernel: [ 466.271046] page dumped because: non-NULL mapping Feb 6 17:13:13 aaa-PC kernel: [ 466.271047] Modules linked in: bnep fuse bluetooth ecdh_generic sha256_generic cfg80211 rfkill vfat fat serio_raw uio_pdrv_genirq binfmt_misc ip_tables amdgpu chash radeon r8168 loongson gpu_sched Feb 6 17:13:13 aaa-PC kernel: [ 466.271059] CPU: 3 PID: 9554 Comm: blur_image Tainted: G B 4.19.0-loongson-3-desktop #3036 Feb 6 17:13:13 aaa-PC kernel: [ 466.271061] Hardware name: Haier Kunlun-LS3A4000-LS7A-desktop/Kunlun-LS3A4000-LS7A-desktop, BIOS Kunlun-V4.0.12V4.0 LS3A4000 03/19/2020 Feb 6 17:13:13 aaa-PC kernel: [ 466.271063] Stack : 000000000000007b 000000007400cce0 0000000000000000 0000000000000007 Feb 6 17:13:13 aaa-PC kernel: [ 466.271067] 0000000000000000 0000000000000000 0000000000002a82 ffffffff8202c910 Feb 6 17:13:13 aaa-PC kernel: [ 466.271070] 0000000000000000 0000000000002a82 0000000000000000 ffffffff81e20000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271074] 0000000000000000 ffffffff8021301c ffffffff82040000 6e754b20534f4942 Feb 6 17:13:13 aaa-PC kernel: [ 466.271078] ffff000000000000 0000000000000000 000000007400cce0 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271082] 9800000007155d40 ffffffff81cc5470 0000000000000005 6db6db6db6db0000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271086] 0000000000000003 fffffffffffffffb 0000000000006000 98000002559f4000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271090] 980000024a448000 980000024a44b7f0 9800000007155d50 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271094] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271097] 9800000007155d40 ffffffff802310c4 ffffffff81e70000 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271101] ... Feb 6 17:13:13 aaa-PC kernel: [ 466.271103] Call Trace: Feb 6 17:13:13 aaa-PC kernel: [ 466.271107] [<ffffffff802310c4>] show_stack+0x44/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271110] [<ffffffff819f5158>] dump_stack+0x1d8/0x240 Feb 6 17:13:13 aaa-PC kernel: [ 466.271113] [<ffffffff80491c10>] bad_page+0x210/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271116] [<ffffffff804931c8>] free_pcppages_bulk+0x708/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 46 6.271119] [<ffffffff804980cc>] free_unref_page_list+0x1cc/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271122] [<ffffffff804ad2c8>] release_pages+0x648/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271125] [<ffffffff804f3b48>] tlb_flush_mmu_free+0x88/0x100 Feb 6 17:13:13 aaa-PC kernel: [ 466.271128] [<ffffffff804f8a24>] zap_pte_range+0xa24/0x1480 Feb 6 17:13:13 aaa-PC kernel: [ 466.271132] [<ffffffff804f98b0>] unmap_page_range+0x1f0/0x500 Feb 6 17:13:13 aaa-PC kernel: [ 466.271135] [<ffffffff804fa054>] unmap_vmas+0x154/0x200 Feb 6 17:13:13 aaa-PC kernel: [ 466.271138] [<ffffffff8051190c>] exit_mmap+0x20c/0x380 Feb 6 17:13:13 aaa-PC kernel: [ 466.271142] [<ffffffff802bb9c8>] mmput+0x148/0x300 Feb 6 17:13:13 aaa-PC kernel: [ 466.271145] [<ffffffff802c80d8>] do_exit+0x6d8/0x1900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271148] [<ffffffff802cb288>] do_group_exit+0x88/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271151] [<ffffffff802cb3d8>] sys_exit_group+0x18/0x40 Feb 6 17 :13:13 aaa-PC kernel: [ 466.271155] [<ffffffff8023f954>] syscall_common+0x34/0xa4 songqiang
@ 2021-04-07 8:25 ` Huang Rui
0 siblings, 0 replies; 669+ messages in thread
From: Huang Rui @ 2021-04-07 8:25 UTC (permalink / raw)
To: songqiang; +Cc: Koenig, Christian, airlied, daniel, linux-kernel, dri-devel
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
> Signed-off-by: songqiang <songqiang@uniontech.com>
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 14660f723f71..f3698f0ad4d7 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
> if (++p != pages[i + j])
> break;
>
> - if (j == HPAGE_PMD_NR)
> + if (j == HPAGE_PMD_NR) {
> order = HPAGE_PMD_ORDER;
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> + page_ref_dec(pages[i+j]);
> + }
> }
> #endif
>
> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
> if (!p)
> break;
> -
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
> pages[i++] = p++;
> -
> + if (j > 0)
> + page_ref_inc(pages[i-1]);
> + }
> npages -= HPAGE_PMD_NR;
> }
> }
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&reserved=0
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2021-04-07 8:25 ` Huang Rui
0 siblings, 0 replies; 669+ messages in thread
From: Huang Rui @ 2021-04-07 8:25 UTC (permalink / raw)
To: songqiang; +Cc: airlied, dri-devel, Koenig, Christian, linux-kernel
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
> Signed-off-by: songqiang <songqiang@uniontech.com>
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 14660f723f71..f3698f0ad4d7 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
> if (++p != pages[i + j])
> break;
>
> - if (j == HPAGE_PMD_NR)
> + if (j == HPAGE_PMD_NR) {
> order = HPAGE_PMD_ORDER;
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> + page_ref_dec(pages[i+j]);
> + }
> }
> #endif
>
> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
> if (!p)
> break;
> -
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
> pages[i++] = p++;
> -
> + if (j > 0)
> + page_ref_inc(pages[i-1]);
> + }
> npages -= HPAGE_PMD_NR;
> }
> }
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2021-04-07 8:25 ` Huang Rui
@ 2021-04-07 9:25 ` Christian König
-1 siblings, 0 replies; 669+ messages in thread
From: Christian König @ 2021-04-07 9:25 UTC (permalink / raw)
To: Huang Rui, songqiang; +Cc: airlied, daniel, linux-kernel, dri-devel
Thanks Ray for pointing this out. Looks like the mail ended up in my
spam folder otherwise.
Apart from that this patch is a really really big NAK. I can't count how
often I had to reject stuff like this!
Using the page reference for TTM pages is illegal and can lead to struct
page corruption.
Can you please describe why you need that?
Regards,
Christian.
Am 07.04.21 um 10:25 schrieb Huang Rui:
> On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
>
> Please add the description in the commit message and subject.
>
> Thanks,
> Ray
>
>> Signed-off-by: songqiang <songqiang@uniontech.com>
>> ---
>> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> index 14660f723f71..f3698f0ad4d7 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
>> if (++p != pages[i + j])
>> break;
>>
>> - if (j == HPAGE_PMD_NR)
>> + if (j == HPAGE_PMD_NR) {
>> order = HPAGE_PMD_ORDER;
>> + for (j = 1; j < HPAGE_PMD_NR; ++j)
>> + page_ref_dec(pages[i+j]);
>> + }
>> }
>> #endif
>>
>> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
>> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
>> if (!p)
>> break;
>> -
>> - for (j = 0; j < HPAGE_PMD_NR; ++j)
>> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
>> pages[i++] = p++;
>> -
>> + if (j > 0)
>> + page_ref_inc(pages[i-1]);
>> + }
>> npages -= HPAGE_PMD_NR;
>> }
>> }
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&reserved=0
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2021-04-07 9:25 ` Christian König
0 siblings, 0 replies; 669+ messages in thread
From: Christian König @ 2021-04-07 9:25 UTC (permalink / raw)
To: Huang Rui, songqiang; +Cc: airlied, dri-devel, linux-kernel
Thanks Ray for pointing this out. Looks like the mail ended up in my
spam folder otherwise.
Apart from that this patch is a really really big NAK. I can't count how
often I had to reject stuff like this!
Using the page reference for TTM pages is illegal and can lead to struct
page corruption.
Can you please describe why you need that?
Regards,
Christian.
Am 07.04.21 um 10:25 schrieb Huang Rui:
> On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
>
> Please add the description in the commit message and subject.
>
> Thanks,
> Ray
>
>> Signed-off-by: songqiang <songqiang@uniontech.com>
>> ---
>> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> index 14660f723f71..f3698f0ad4d7 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
>> if (++p != pages[i + j])
>> break;
>>
>> - if (j == HPAGE_PMD_NR)
>> + if (j == HPAGE_PMD_NR) {
>> order = HPAGE_PMD_ORDER;
>> + for (j = 1; j < HPAGE_PMD_NR; ++j)
>> + page_ref_dec(pages[i+j]);
>> + }
>> }
>> #endif
>>
>> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
>> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
>> if (!p)
>> break;
>> -
>> - for (j = 0; j < HPAGE_PMD_NR; ++j)
>> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
>> pages[i++] = p++;
>> -
>> + if (j > 0)
>> + page_ref_inc(pages[i-1]);
>> + }
>> npages -= HPAGE_PMD_NR;
>> }
>> }
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2021-04-01 21:16 Bhaumik Bhatt
2021-04-07 6:56 ` your mail Manivannan Sadhasivam
0 siblings, 1 reply; 669+ messages in thread
From: Bhaumik Bhatt @ 2021-04-01 21:16 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, carl.yin,
naveen.kumar, loic.poulain, Bhaumik Bhatt
Subject: [PATCH v8 0/9] Updates to MHI channel handling
MHI specification shows a state machine with support for STOP channel command
and the validity of certain state transitions. MHI host currently does not
provide any mechanism to stop a channel and restart it without resetting it.
There are also times when the device moves on to a different execution
environment while client drivers on the host are unaware of it and still
attempt to reset the channels facing unnecessary timeouts.
This series addresses the above areas to provide support for stopping an MHI
channel, resuming it back, improved documentation and improving upon channel
state machine handling in general.
This set of patches was tested on arm64 and x86_64 architecture.
v8:
-Split the state machine improvements patch to three patches as per review
v7:
-Tested on x86_64 architecture
-Drop the patch "Do not clear channel context more than once" as issue is fixed
differently using "bus: mhi: core: Fix double dma free()"
-Update the commit text to better reflect changes on state machine improvements
v6:
-Dropped the patch which introduced start/stop transfer APIs for lack of users
-Updated error handling and debug prints on channel handling improvements patch
-Improved commit text to better explain certain patches based on review comments
-Removed references to new APIs from the documentation improvement patch
v5:
-Added reviewed-by tags from Hemant I missed earlier
-Added patch to prevent kernel warnings on clearing channel context twice
v4:
-Updated commit text/descriptions and addressed checkpatch checks
-Added context validity check before starting/stopping channels from new API
-Added patch to clear channel context configuration after reset/unprepare
v3:
-Updated documentation for channel transfer APIs to highlight differences
-Create separate patch for "allowing channel to be disabled from stopped state"
v2:
-Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer()
-Added improved documentation to avoid confusion with the new APIs
-Removed the __ prefix from mhi_unprepare_channel() API for consistency.
Bhaumik Bhatt (9):
bus: mhi: core: Allow sending the STOP channel command
bus: mhi: core: Clear context for stopped channels from remove()
bus: mhi: core: Improvements to the channel handling state machine
bus: mhi: core: Update debug messages to use client device
bus: mhi: core: Hold device wake for channel update commands
bus: mhi: core: Clear configuration from channel context during reset
bus: mhi: core: Check channel execution environment before issuing
reset
bus: mhi: core: Remove __ prefix for MHI channel unprepare function
bus: mhi: Improve documentation on channel transfer setup APIs
drivers/bus/mhi/core/init.c | 22 ++++-
drivers/bus/mhi/core/internal.h | 12 +++
drivers/bus/mhi/core/main.c | 190 ++++++++++++++++++++++++----------------
include/linux/mhi.h | 18 +++-
4 files changed, 162 insertions(+), 80 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2021-04-01 21:16 Bhaumik Bhatt
@ 2021-04-07 6:56 ` Manivannan Sadhasivam
0 siblings, 0 replies; 669+ messages in thread
From: Manivannan Sadhasivam @ 2021-04-07 6:56 UTC (permalink / raw)
To: Bhaumik Bhatt
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, carl.yin,
naveen.kumar, loic.poulain
On Thu, Apr 01, 2021 at 02:16:09PM -0700, Bhaumik Bhatt wrote:
> Subject: [PATCH v8 0/9] Updates to MHI channel handling
>
Subject is present in the body ;)
> MHI specification shows a state machine with support for STOP channel command
> and the validity of certain state transitions. MHI host currently does not
> provide any mechanism to stop a channel and restart it without resetting it.
> There are also times when the device moves on to a different execution
> environment while client drivers on the host are unaware of it and still
> attempt to reset the channels facing unnecessary timeouts.
>
> This series addresses the above areas to provide support for stopping an MHI
> channel, resuming it back, improved documentation and improving upon channel
> state machine handling in general.
>
> This set of patches was tested on arm64 and x86_64 architecture.
>
Series applied to mhi-next!
Thanks,
Mani
> v8:
> -Split the state machine improvements patch to three patches as per review
>
> v7:
> -Tested on x86_64 architecture
> -Drop the patch "Do not clear channel context more than once" as issue is fixed
> differently using "bus: mhi: core: Fix double dma free()"
> -Update the commit text to better reflect changes on state machine improvements
>
> v6:
> -Dropped the patch which introduced start/stop transfer APIs for lack of users
> -Updated error handling and debug prints on channel handling improvements patch
> -Improved commit text to better explain certain patches based on review comments
> -Removed references to new APIs from the documentation improvement patch
>
> v5:
> -Added reviewed-by tags from Hemant I missed earlier
> -Added patch to prevent kernel warnings on clearing channel context twice
>
> v4:
> -Updated commit text/descriptions and addressed checkpatch checks
> -Added context validity check before starting/stopping channels from new API
> -Added patch to clear channel context configuration after reset/unprepare
>
> v3:
> -Updated documentation for channel transfer APIs to highlight differences
> -Create separate patch for "allowing channel to be disabled from stopped state"
>
> v2:
> -Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer()
> -Added improved documentation to avoid confusion with the new APIs
> -Removed the __ prefix from mhi_unprepare_channel() API for consistency.
>
> Bhaumik Bhatt (9):
> bus: mhi: core: Allow sending the STOP channel command
> bus: mhi: core: Clear context for stopped channels from remove()
> bus: mhi: core: Improvements to the channel handling state machine
> bus: mhi: core: Update debug messages to use client device
> bus: mhi: core: Hold device wake for channel update commands
> bus: mhi: core: Clear configuration from channel context during reset
> bus: mhi: core: Check channel execution environment before issuing
> reset
> bus: mhi: core: Remove __ prefix for MHI channel unprepare function
> bus: mhi: Improve documentation on channel transfer setup APIs
>
> drivers/bus/mhi/core/init.c | 22 ++++-
> drivers/bus/mhi/core/internal.h | 12 +++
> drivers/bus/mhi/core/main.c | 190 ++++++++++++++++++++++++----------------
> include/linux/mhi.h | 18 +++-
> 4 files changed, 162 insertions(+), 80 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20210322213644.333112726@goodmis.org>]
[parent not found: <20210322212156.440428241@goodmis.org>]
* [PATCH] lib/find_bit: Add find_prev_*_bit functions.
@ 2020-12-02 1:10 Yun Levi
2020-12-02 9:47 ` Andy Shevchenko
0 siblings, 1 reply; 669+ messages in thread
From: Yun Levi @ 2020-12-02 1:10 UTC (permalink / raw)
To: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
andriy.shevchenko, joseph.qi, skalluru, yury.norov, jpoimboe
Cc: linux-kernel, linux-arch
Inspired find_next_*bit function series, add find_prev_*_bit series.
I'm not sure whether it'll be used right now But, I add these functions
for future usage.
Signed-off-by: Levi Yun <ppbuk5246@gmail.com>
---
fs/ufs/util.h | 24 +++---
include/asm-generic/bitops/find.h | 69 ++++++++++++++++
include/asm-generic/bitops/le.h | 33 ++++++++
include/linux/bitops.h | 34 +++++---
lib/find_bit.c | 126 +++++++++++++++++++++++++++++-
5 files changed, 260 insertions(+), 26 deletions(-)
diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 4931bec1a01c..7c87c77d10ca 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -2,7 +2,7 @@
/*
* linux/fs/ufs/util.h
*
- * Copyright (C) 1998
+ * Copyright (C) 1998
* Daniel Pirkl <daniel.pirkl@email.cz>
* Charles University, Faculty of Mathematics and Physics
*/
@@ -263,7 +263,7 @@ extern int ufs_prepare_chunk(struct page *page,
loff_t pos, unsigned len);
/*
* These functions manipulate ufs buffers
*/
-#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size)
+#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size)
extern struct ufs_buffer_head * _ubh_bread_(struct
ufs_sb_private_info *, struct super_block *, u64 , u64);
extern struct ufs_buffer_head * ubh_bread_uspi(struct
ufs_sb_private_info *, struct super_block *, u64, u64);
extern void ubh_brelse (struct ufs_buffer_head *);
@@ -296,7 +296,7 @@ static inline void *get_usb_offset(struct
ufs_sb_private_info *uspi,
unsigned int offset)
{
unsigned int index;
-
+
index = offset >> uspi->s_fshift;
offset &= ~uspi->s_fmask;
return uspi->s_ubh.bh[index]->b_data + offset;
@@ -411,9 +411,9 @@ static inline unsigned _ubh_find_next_zero_bit_(
offset = 0;
}
return (base << uspi->s_bpfshift) + pos - begin;
-}
+}
-static inline unsigned find_last_zero_bit (unsigned char * bitmap,
+static inline unsigned __ubh_find_last_zero_bit(unsigned char * bitmap,
unsigned size, unsigned offset)
{
unsigned bit, i;
@@ -453,7 +453,7 @@ static inline unsigned _ubh_find_last_zero_bit_(
size + (uspi->s_bpf - start), uspi->s_bpf)
- (uspi->s_bpf - start);
size -= count;
- pos = find_last_zero_bit (ubh->bh[base]->b_data,
+ pos = __ubh_find_last_zero_bit(ubh->bh[base]->b_data,
start, start - count);
if (pos > start - count || !size)
break;
@@ -461,7 +461,7 @@ static inline unsigned _ubh_find_last_zero_bit_(
start = uspi->s_bpf;
}
return (base << uspi->s_bpfshift) + pos - begin;
-}
+}
#define ubh_isblockclear(ubh,begin,block)
(!_ubh_isblockset_(uspi,ubh,begin,block))
@@ -483,7 +483,7 @@ static inline int _ubh_isblockset_(struct
ufs_sb_private_info * uspi,
mask = 0x01 << (block & 0x07);
return (*ubh_get_addr (ubh, begin + (block >> 3)) &
mask) == mask;
}
- return 0;
+ return 0;
}
#define ubh_clrblock(ubh,begin,block) _ubh_clrblock_(uspi,ubh,begin,block)
@@ -492,8 +492,8 @@ static inline void _ubh_clrblock_(struct
ufs_sb_private_info * uspi,
{
switch (uspi->s_fpb) {
case 8:
- *ubh_get_addr (ubh, begin + block) = 0x00;
- return;
+ *ubh_get_addr (ubh, begin + block) = 0x00;
+ return;
case 4:
*ubh_get_addr (ubh, begin + (block >> 1)) &= ~(0x0f <<
((block & 0x01) << 2));
return;
@@ -531,9 +531,9 @@ static inline void ufs_fragacct (struct
super_block * sb, unsigned blockmap,
{
struct ufs_sb_private_info * uspi;
unsigned fragsize, pos;
-
+
uspi = UFS_SB(sb)->s_uspi;
-
+
fragsize = 0;
for (pos = 0; pos < uspi->s_fpb; pos++) {
if (blockmap & (1 << pos)) {
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..ca18b2ec954c 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -16,6 +16,20 @@ extern unsigned long find_next_bit(const unsigned
long *addr, unsigned long
size, unsigned long offset);
#endif
+#ifndef find_prev_bit
+/**
+ * find_prev_bit - find the prev set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the prev set bit
+ * If no bits are set, returns @size.
+ */
+extern unsigned long find_prev_bit(const unsigned long *addr, unsigned long
+ size, unsigned long offset);
+#endif
+
#ifndef find_next_and_bit
/**
* find_next_and_bit - find the next set bit in both memory regions
@@ -32,6 +46,22 @@ extern unsigned long find_next_and_bit(const
unsigned long *addr1,
unsigned long offset);
#endif
+#ifndef find_prev_and_bit
+/**
+ * find_prev_and_bit - find the prev set bit in both memory regions
+ * @addr1: The first address to base the search on
+ * @addr2: The second address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the prev set bit
+ * If no bits are set, returns @size.
+ */
+extern unsigned long find_prev_and_bit(const unsigned long *addr1,
+ const unsigned long *addr2, unsigned long size,
+ unsigned long offset);
+#endif
+
#ifndef find_next_zero_bit
/**
* find_next_zero_bit - find the next cleared bit in a memory region
@@ -46,6 +76,20 @@ extern unsigned long find_next_zero_bit(const
unsigned long *addr, unsigned
long size, unsigned long offset);
#endif
+#ifndef find_prev_zero_bit
+/**
+ * find_prev_zero_bit - find the prev cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number of the prev zero bit
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned
+ long size, unsigned long offset);
+#endif
+
#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
/**
@@ -80,6 +124,31 @@ extern unsigned long find_first_zero_bit(const
unsigned long *addr,
#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+#ifndef find_last_bit
+/**
+ * find_last_bit - find the last set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The number of bits to search
+ *
+ * Returns the bit number of the last set bit, or size.
+ */
+extern unsigned long find_last_bit(const unsigned long *addr,
+ unsigned long size);
+#endif
+
+#ifndef find_last_zero_bit
+/**
+ * find_last_zero_bit - find the last cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum number of bits to search
+ *
+ * Returns the bit number of the first cleared bit.
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_last_zero_bit(const unsigned long *addr,
+ unsigned long size);
+#endif
+
/**
* find_next_clump8 - find next 8-bit clump with set bits in a memory region
* @clump: location to store copy of found clump
diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index 188d3eba3ace..d0bd15bc34d9 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -27,6 +27,24 @@ static inline unsigned long
find_first_zero_bit_le(const void *addr,
return find_first_zero_bit(addr, size);
}
+static inline unsigned long find_prev_zero_bit_le(const void *addr,
+ unsigned long size, unsigned long offset)
+{
+ return find_prev_zero_bit(addr, size, offset);
+}
+
+static inline unsigned long find_prev_bit_le(const void *addr,
+ unsigned long size, unsigned long offset)
+{
+ return find_prev_bit(addr, size, offset);
+}
+
+static inline unsigned long find_last_zero_bit_le(const void *addr,
+ unsigned long size)
+{
+ return find_last_zero_bit(addr, size);
+}
+
#elif defined(__BIG_ENDIAN)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
@@ -41,11 +59,26 @@ extern unsigned long find_next_bit_le(const void *addr,
unsigned long size, unsigned long offset);
#endif
+#ifndef find_prev_zero_bit_le
+extern unsigned long find_prev_zero_bit_le(const void *addr,
+ unsigned long size, unsigned long offset);
+#endif
+
+#ifndef find_prev_bit_le
+extern unsigned long find_prev_bit_le(const void *addr,
+ unsigned long size, unsigned long offset);
+#endif
+
#ifndef find_first_zero_bit_le
#define find_first_zero_bit_le(addr, size) \
find_next_zero_bit_le((addr), (size), 0)
#endif
+#ifndef find_last_zero_bit_le
+#define find_last_zero_bit_le(addr, size) \
+ find_prev_zero_bit_le((addr), (size), (size - 1))
+#endif
+
#else
#error "Please fix <asm/byteorder.h>"
#endif
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5b74bdf159d6..124c68929861 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -50,6 +50,28 @@ extern unsigned long __sw_hweight64(__u64 w);
(bit) < (size); \
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
+#define for_each_set_bit_reverse(bit, addr, size) \
+ for ((bit) = find_last_bit((addr), (size)); \
+ (bit) < (size); \
+ (bit) = find_prev_bit((addr), (size), (bit)))
+
+/* same as for_each_set_bit_reverse() but use bit as value to start with */
+#define for_each_set_bit_from_reverse(bit, addr, size) \
+ for ((bit) = find_prev_bit((addr), (size), (bit)); \
+ (bit) < (size); \
+ (bit) = find_prev_bit((addr), (size), (bit - 1)))
+
+#define for_each_clear_bit_reverse(bit, addr, size) \
+ for ((bit) = find_last_zero_bit((addr), (size)); \
+ (bit) < (size); \
+ (bit) = find_prev_zero_bit((addr), (size), (bit)))
+
+/* same as for_each_clear_bit_reverse() but use bit as value to start with */
+#define for_each_clear_bit_from_reverse(bit, addr, size) \
+ for ((bit) = find_prev_zero_bit((addr), (size), (bit)); \
+ (bit) < (size); \
+ (bit) = find_next_zero_bit((addr), (size), (bit - 1)))
+
/**
* for_each_set_clump8 - iterate over bitmap for each 8-bit clump with set bits
* @start: bit offset to start search and to store the current iteration offset
@@ -283,17 +305,5 @@ static __always_inline void __assign_bit(long nr,
volatile unsigned long *addr,
})
#endif
-#ifndef find_last_bit
-/**
- * find_last_bit - find the last set bit in a memory region
- * @addr: The address to start the search at
- * @size: The number of bits to search
- *
- * Returns the bit number of the last set bit, or size.
- */
-extern unsigned long find_last_bit(const unsigned long *addr,
- unsigned long size);
-#endif
-
#endif /* __KERNEL__ */
#endif
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 4a8751010d59..cbe06abd3d21 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -69,6 +69,58 @@ static unsigned long _find_next_bit(const unsigned
long *addr1,
}
#endif
+#if !defined(find_prev_bit) || !defined(find_prev_zero_bit) ||
\
+ !defined(find_prev_bit_le) || !defined(find_prev_zero_bit_le)
|| \
+ !defined(find_prev_and_bit)
+/*
+ * This is a common helper function for find_prev_bit, find_prev_zero_bit, and
+ * find_prev_and_bit. The differences are:
+ * - The "invert" argument, which is XORed with each fetched word before
+ * searching it for one bits.
+ * - The optional "addr2", which is anded with "addr1" if present.
+ */
+static unsigned long _find_prev_bit(const unsigned long *addr1,
+ const unsigned long *addr2, unsigned long nbits,
+ unsigned long start, unsigned long invert, unsigned long le)
+{
+ unsigned long tmp, mask;
+
+ if (unlikely(start >= nbits))
+ return nbits;
+
+ tmp = addr1[start / BITS_PER_LONG];
+ if (addr2)
+ tmp &= addr2[start / BITS_PER_LONG];
+ tmp ^= invert;
+
+ /* Handle 1st word. */
+ mask = BITMAP_LAST_WORD_MASK(start + 1);
+ if (le)
+ mask = swab(mask);
+
+ tmp &= mask;
+
+ start = round_down(start, BITS_PER_LONG);
+
+ while (!tmp) {
+ start -= BITS_PER_LONG;
+ if (start >= nbits)
+ return nbits;
+
+ tmp = addr1[start / BITS_PER_LONG];
+ if (addr2)
+ tmp &= addr2[start / BITS_PER_LONG];
+ tmp ^= invert;
+ }
+
+ if (le)
+ tmp = swab(tmp);
+
+ return start + __fls(tmp);
+}
+#endif
+
+
#ifndef find_next_bit
/*
* Find the next set bit in a memory region.
@@ -81,6 +133,18 @@ unsigned long find_next_bit(const unsigned long
*addr, unsigned long size,
EXPORT_SYMBOL(find_next_bit);
#endif
+#ifndef find_prev_bit
+/*
+ * Find the prev set bit in a memory region.
+ */
+unsigned long find_prev_bit(const unsigned long *addr, unsigned long size,
+ unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, 0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_bit);
+#endif
+
#ifndef find_next_zero_bit
unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
unsigned long offset)
@@ -90,7 +154,16 @@ unsigned long find_next_zero_bit(const unsigned
long *addr, unsigned long size,
EXPORT_SYMBOL(find_next_zero_bit);
#endif
-#if !defined(find_next_and_bit)
+#ifndef find_prev_zero_bit
+unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned long size,
+ unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, ~0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_zero_bit);
+#endif
+
+#ifndef find_next_and_bit
unsigned long find_next_and_bit(const unsigned long *addr1,
const unsigned long *addr2, unsigned long size,
unsigned long offset)
@@ -100,6 +173,16 @@ unsigned long find_next_and_bit(const unsigned long *addr1,
EXPORT_SYMBOL(find_next_and_bit);
#endif
+#ifndef find_prev_and_bit
+unsigned long find_prev_and_bit(const unsigned long *addr1,
+ const unsigned long *addr2, unsigned long size,
+ unsigned long offset)
+{
+ return _find_prev_bit(addr1, addr2, size, offset, 0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_and_bit);
+#endif
+
#ifndef find_first_bit
/*
* Find the first set bit in a memory region.
@@ -141,7 +224,7 @@ unsigned long find_last_bit(const unsigned long
*addr, unsigned long size)
{
if (size) {
unsigned long val = BITMAP_LAST_WORD_MASK(size);
- unsigned long idx = (size-1) / BITS_PER_LONG;
+ unsigned long idx = (size - 1) / BITS_PER_LONG;
do {
val &= addr[idx];
@@ -156,6 +239,27 @@ unsigned long find_last_bit(const unsigned long
*addr, unsigned long size)
EXPORT_SYMBOL(find_last_bit);
#endif
+#ifndef find_last_zero_bit
+unsigned long find_last_zero_bit(const unsigned long *addr, unsigned long size)
+{
+ if (size) {
+ unsigned long val = BITMAP_LAST_WORD_MASK(size);
+ unsigned long idx = (size - 1) / BITS_PER_LONG;
+
+ do {
+ val &= ~addr[idx];
+ if (val)
+ return idx * BITS_PER_LONG + __fls(val);
+
+ val = ~0ul;
+ } while (idx--);
+ }
+
+ return size;
+}
+EXPORT_SYMBOL(find_last_zero_bit);
+#endif
+
#ifdef __BIG_ENDIAN
#ifndef find_next_zero_bit_le
@@ -167,6 +271,15 @@ unsigned long find_next_zero_bit_le(const void
*addr, unsigned
EXPORT_SYMBOL(find_next_zero_bit_le);
#endif
+#ifndef find_prev_zero_bit_le
+unsigned long find_prev_zero_bit_le(const void *addr, unsigned
+ long size, unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, ~0UL, 1);
+}
+EXPORT_SYMBOL(find_prev_zero_bit_le);
+#endif
+
#ifndef find_next_bit_le
unsigned long find_next_bit_le(const void *addr, unsigned
long size, unsigned long offset)
@@ -176,6 +289,15 @@ unsigned long find_next_bit_le(const void *addr, unsigned
EXPORT_SYMBOL(find_next_bit_le);
#endif
+#ifdef find_prev_bit_le
+unsigned long find_prev_bit_le(const void *addr, unsigned
+ long size, unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, 0UL, 1);
+}
+EXPORT_SYMBOL(find_prev_bit_le);
+#endif
+
#endif /* __BIG_ENDIAN */
unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
--
2.29.2
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions.
2020-12-02 1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi
@ 2020-12-02 9:47 ` Andy Shevchenko
2020-12-02 10:04 ` Rasmus Villemoes
0 siblings, 1 reply; 669+ messages in thread
From: Andy Shevchenko @ 2020-12-02 9:47 UTC (permalink / raw)
To: Yun Levi
Cc: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel,
linux-arch
On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote:
> Inspired find_next_*bit function series, add find_prev_*_bit series.
> I'm not sure whether it'll be used right now But, I add these functions
> for future usage.
This patch has few issues:
- it has more things than described (should be several patches instead)
- new functionality can be split logically to couple or more pieces as well
- it proposes functionality w/o user (dead code)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions.
2020-12-02 9:47 ` Andy Shevchenko
@ 2020-12-02 10:04 ` Rasmus Villemoes
2020-12-02 11:50 ` Yun Levi
0 siblings, 1 reply; 669+ messages in thread
From: Rasmus Villemoes @ 2020-12-02 10:04 UTC (permalink / raw)
To: Andy Shevchenko, Yun Levi
Cc: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel,
linux-arch
On 02/12/2020 10.47, Andy Shevchenko wrote:
> On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote:
>> Inspired find_next_*bit function series, add find_prev_*_bit series.
>> I'm not sure whether it'll be used right now But, I add these functions
>> for future usage.
>
> This patch has few issues:
> - it has more things than described (should be several patches instead)
> - new functionality can be split logically to couple or more pieces as well
> - it proposes functionality w/o user (dead code)
Yeah, the last point means it can't be applied - please submit it again
if and when you have an actual use case. And I'll add
- it lacks extension of the bitmap test module to cover the new
functions (that also wants to be a separate patch).
Rasmus
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions.
2020-12-02 10:04 ` Rasmus Villemoes
@ 2020-12-02 11:50 ` Yun Levi
[not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
0 siblings, 1 reply; 669+ messages in thread
From: Yun Levi @ 2020-12-02 11:50 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Andy Shevchenko, dushistov, arnd, akpm, gustavo, vilhelm.gray,
richard.weiyang, joseph.qi, skalluru, yury.norov, jpoimboe,
linux-kernel, linux-arch
Thanks for kind advice. But I'm so afraid to have questions below:
> - it proposes functionality w/o user (dead code)
Actually, I add these series functions to rewrite some of the
resource clean-up routine.
A typical case is ethtool_set_per_queue_coalesce 's rollback label.
Could this usage be an actual use case?
>- it lacks extension of the bitmap test module to cover the new
> functions (that also wants to be a separate patch).
I see, then Could I add some of testcase on lib/test_bitops.c for testing?
On Wed, Dec 2, 2020 at 7:04 PM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> On 02/12/2020 10.47, Andy Shevchenko wrote:
> > On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote:
> >> Inspired find_next_*bit function series, add find_prev_*_bit series.
> >> I'm not sure whether it'll be used right now But, I add these functions
> >> for future usage.
> >
> > This patch has few issues:
> > - it has more things than described (should be several patches instead)
> > - new functionality can be split logically to couple or more pieces as well
> > - it proposes functionality w/o user (dead code)
>
> Yeah, the last point means it can't be applied - please submit it again
> if and when you have an actual use case. And I'll add
>
> - it lacks extension of the bitmap test module to cover the new
> functions (that also wants to be a separate patch).
>
> Rasmus
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2020-09-03 17:36 Barnett, Andy
2020-09-18 7:56 ` your mail Johan Hovold
0 siblings, 1 reply; 669+ messages in thread
From: Barnett, Andy @ 2020-09-03 17:36 UTC (permalink / raw)
To: linux-serial
Title - Edgport/4 compatibility question
Hello there - I am trying to get some legacy EdgePort/4 and 8 devices to work on Linux using Raspberry Pi OS.
I notice in the kernel. org notes, compatibility with Edgeport seems to be a good possibility.
In dmesg I get "usbserial: USB Serial support registered for Edgeport TI 1 port adapter" but no corresponding ttyUSB0-3 being set up.
I also tried adding a folder into lib/firmware called "edgeport" with some firmware I found online but I get multiple "Cannot send clear loopback command" messages in dmesg. This did seem to create ttyUSBs 0-3 but I could not use these devices.
I do not have any problems connecting with a few Keyspan USA-49W devices (which are also referenced in the Compatibility section in the notes) so I think my machine is good.
Apologies in advance - I am not in anyway a Linux expert.
Any guidance or tips would be appreciated!
Thanks
Andy
Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2020-09-03 17:36 Barnett, Andy
@ 2020-09-18 7:56 ` Johan Hovold
0 siblings, 0 replies; 669+ messages in thread
From: Johan Hovold @ 2020-09-18 7:56 UTC (permalink / raw)
To: Barnett, Andy; +Cc: linux-serial
On Thu, Sep 03, 2020 at 05:36:34PM +0000, Barnett, Andy wrote:
> Title - Edgport/4 compatibility question
> Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.
Please resend with a proper Subject line and without the above
disclaimer.
And remember to CC the USB list (linux-usb@vger.kernel.org).
Johan
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
@ 2020-08-05 11:02 Amit Pundir
2020-08-06 22:31 ` Konrad Dybcio
0 siblings, 1 reply; 669+ messages in thread
From: Amit Pundir @ 2020-08-05 11:02 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, John Stultz, Sumit Semwal
Cc: linux-arm-msm, dt, lkml
On Wed, 5 Aug 2020 at 16:21, Amit Pundir <amit.pundir@linaro.org> wrote:
>
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS, USB-C (peripheral),
> microSD card and Vol+/Vol-/power keys. Bluetooth should work
> too but couldn't be verified from adb command line, it is
> verified when enabled from UI with few WIP display patches.
>
> Just like initial db845c support, initializing the SMMU is
> clearing the mapping used for the splash screen framebuffer,
> which causes the device to hang during boot and recovery
> needs a hard power reset. This can be worked around using:
>
> fastboot oem select-display-panel none
>
> To switch ON the display back run:
>
> fastboot oem select-display-panel
>
> But this only works on Beryllium devices running bootloader
> version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> Android-9 based release. Newer bootloader version do not
> support switching OFF the display panel at all. So we need
> a few additional smmu patches (under review) from here to
> boot to shell:
> https://github.com/pundiramit/linux/commits/beryllium-mainline
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> ---
> v4: Added more downstream reserved memory regions. It probably
> need more work, but for now I see adsp/cdsp/wlan remoteprocs
> powering up properly. Also removed the regulator nodes not
> required for the device, as suggested by Bjorn.
Forgot to mention that I added couple of clocks to protected clocks in v4,
which need for display to work.
> v3: Added a reserved-memory region from downstream kernel to fix
> a boot regression with recent dma-pool changes in v5.8-rc6.
> v2: Updated machine compatible string for seemingly inevitable
> future quirks.
>
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383 ++++++++++++++++++++++++++
> 2 files changed, 384 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 0f2c33d611df..3ef1b48bc0cb 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> new file mode 100644
> index 000000000000..0f9f61bf9fa4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +
> +/ {
> + model = "Xiaomi Technologies Inc. Beryllium";
> + compatible = "xiaomi,beryllium", "qcom,sdm845";
> +
> + /* required for bootloader to select correct board */
> + qcom,board-id = <69 0>;
> + qcom,msm-id = <321 0x20001>;
> +
> + aliases {
> + hsuart0 = &uart6;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vol_up_pin_a>;
> +
> + vol-up {
> + label = "Volume Up";
> + linux,code = <KEY_VOLUMEUP>;
> + gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + vreg_s4a_1p8: vreg-s4a-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vreg_s4a_1p8";
> +
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +};
> +
> +&adsp_pas {
> + status = "okay";
> + firmware-name = "qcom/sdm845/adsp.mdt";
> +};
> +
> +&apps_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vreg_l1a_0p875: ldo1 {
> + regulator-min-microvolt = <880000>;
> + regulator-max-microvolt = <880000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l5a_0p8: ldo5 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7a_1p8: ldo7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l12a_1p8: ldo12 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l13a_2p95: ldo13 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2960000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l17a_1p3: ldo17 {
> + regulator-min-microvolt = <1304000>;
> + regulator-max-microvolt = <1304000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l20a_2p95: ldo20 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2968000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l21a_2p95: ldo21 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2968000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l24a_3p075: ldo24 {
> + regulator-min-microvolt = <3088000>;
> + regulator-max-microvolt = <3088000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l25a_3p3: ldo25 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3312000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l26a_1p2: ldo26 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> + };
> +};
> +
> +&cdsp_pas {
> + status = "okay";
> + firmware-name = "qcom/sdm845/cdsp.mdt";
> +};
> +
> +&gcc {
> + protected-clocks = <GCC_QSPI_CORE_CLK>,
> + <GCC_QSPI_CORE_CLK_SRC>,
> + <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
> + <GCC_LPASS_Q6_AXI_CLK>,
> + <GCC_LPASS_SWAY_CLK>;
> +};
> +
> +&gpu {
> + zap-shader {
> + memory-region = <&gpu_mem>;
> + firmware-name = "qcom/sdm845/a630_zap.mbn";
> + };
> +};
> +
> +/* Reserved memory changes from downstream */
> +/delete-node/ &adsp_mem;
> +/delete-node/ &wlan_msa_mem;
> +/delete-node/ &mpss_region;
> +/delete-node/ &venus_mem;
> +/delete-node/ &cdsp_mem;
> +/delete-node/ &mba_region;
> +/delete-node/ &slpi_mem;
> +/delete-node/ &spss_mem;
> +/delete-node/ &rmtfs_mem;
> +/ {
> + reserved-memory {
> + // This removed_region is needed to boot the device
> + // TODO: Find out the user of this reserved memory
> + removed_region: memory@88f00000 {
> + reg = <0 0x88f00000 0 0x1a00000>;
> + no-map;
> + };
> +
> + adsp_mem: memory@8c500000 {
> + reg = <0 0x8c500000 0 0x1e00000>;
> + no-map;
> + };
> +
> + wlan_msa_mem: memory@8e300000 {
> + reg = <0 0x8e300000 0 0x100000>;
> + no-map;
> + };
> +
> + mpss_region: memory@8e400000 {
> + reg = <0 0x8e400000 0 0x7800000>;
> + no-map;
> + };
> +
> + venus_mem: memory@95c00000 {
> + reg = <0 0x95c00000 0 0x500000>;
> + no-map;
> + };
> +
> + cdsp_mem: memory@96100000 {
> + reg = <0 0x96100000 0 0x800000>;
> + no-map;
> + };
> +
> + mba_region: memory@96900000 {
> + reg = <0 0x96900000 0 0x200000>;
> + no-map;
> + };
> +
> + slpi_mem: memory@96b00000 {
> + reg = <0 0x96b00000 0 0x1400000>;
> + no-map;
> + };
> +
> + spss_mem: memory@97f00000 {
> + reg = <0 0x97f00000 0 0x100000>;
> + no-map;
> + };
> +
> + rmtfs_mem: memory@f6301000 {
> + compatible = "qcom,rmtfs-mem";
> + reg = <0 0xf6301000 0 0x200000>;
> + no-map;
> +
> + qcom,client-id = <1>;
> + qcom,vmid = <15>;
> + };
> + };
> +};
> +
> +&mss_pil {
> + status = "okay";
> + firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> +};
> +
> +&pm8998_gpio {
> + vol_up_pin_a: vol-up-active {
> + pins = "gpio6";
> + function = "normal";
> + input-enable;
> + bias-pull-up;
> + qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>;
> + };
> +};
> +
> +&pm8998_pon {
> + resin {
> + compatible = "qcom,pm8941-resin";
> + interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
> + debounce = <15625>;
> + bias-pull-up;
> + linux,code = <KEY_VOLUMEDOWN>;
> + };
> +};
> +
> +&qupv3_id_0 {
> + status = "okay";
> +};
> +
> +&sdhc_2 {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdc2_default_state &sdc2_card_det_n>;
> +
> + vmmc-supply = <&vreg_l21a_2p95>;
> + vqmmc-supply = <&vreg_l13a_2p95>;
> +
> + bus-width = <4>;
> + cd-gpios = <&tlmm 126 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&tlmm {
> + gpio-reserved-ranges = <0 4>, <81 4>;
> +
> + sdc2_default_state: sdc2-default {
> + clk {
> + pins = "sdc2_clk";
> + bias-disable;
> +
> + /*
> + * It seems that mmc_test reports errors if drive
> + * strength is not 16 on clk, cmd, and data pins.
> + */
> + drive-strength = <16>;
> + };
> +
> + cmd {
> + pins = "sdc2_cmd";
> + bias-pull-up;
> + drive-strength = <10>;
> + };
> +
> + data {
> + pins = "sdc2_data";
> + bias-pull-up;
> + drive-strength = <10>;
> + };
> + };
> +
> + sdc2_card_det_n: sd-card-det-n {
> + pins = "gpio126";
> + function = "gpio";
> + bias-pull-up;
> + };
> +};
> +
> +&uart6 {
> + status = "okay";
> +
> + bluetooth {
> + compatible = "qcom,wcn3990-bt";
> +
> + vddio-supply = <&vreg_s4a_1p8>;
> + vddxo-supply = <&vreg_l7a_1p8>;
> + vddrf-supply = <&vreg_l17a_1p3>;
> + vddch0-supply = <&vreg_l25a_3p3>;
> + max-speed = <3200000>;
> + };
> +};
> +
> +&usb_1 {
> + status = "okay";
> +};
> +
> +&usb_1_dwc3 {
> + dr_mode = "peripheral";
> +};
> +
> +&usb_1_hsphy {
> + status = "okay";
> +
> + vdd-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l12a_1p8>;
> + vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
> +
> + qcom,imp-res-offset-value = <8>;
> + qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>;
> + qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>;
> + qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>;
> +};
> +
> +&usb_1_qmpphy {
> + status = "okay";
> +
> + vdda-phy-supply = <&vreg_l26a_1p2>;
> + vdda-pll-supply = <&vreg_l1a_0p875>;
> +};
> +
> +&ufs_mem_hc {
> + status = "okay";
> +
> + reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
> +
> + vcc-supply = <&vreg_l20a_2p95>;
> + vcc-max-microamp = <800000>;
> +};
> +
> +&ufs_mem_phy {
> + status = "okay";
> +
> + vdda-phy-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l26a_1p2>;
> +};
> +
> +&wifi {
> + status = "okay";
> +
> + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
> + vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> +};
> +
> +/* PINCTRL - additions to nodes defined in sdm845.dtsi */
> +
> +&qup_uart6_default {
> + pinmux {
> + pins = "gpio45", "gpio46", "gpio47", "gpio48";
> + function = "qup6";
> + };
> +
> + cts {
> + pins = "gpio45";
> + bias-disable;
> + };
> +
> + rts-tx {
> + pins = "gpio46", "gpio47";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + rx {
> + pins = "gpio48";
> + bias-pull-up;
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 669+ messages in thread* (no subject)
2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir
@ 2020-08-06 22:31 ` Konrad Dybcio
2020-08-13 7:04 ` your mail Bjorn Andersson
0 siblings, 1 reply; 669+ messages in thread
From: Konrad Dybcio @ 2020-08-06 22:31 UTC (permalink / raw)
To: amit.pundir
Cc: agross, bjorn.andersson, devicetree, john.stultz, linux-arm-msm,
linux-kernel, robh+dt, sumit.semwal, Konrad Dybcio
Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
>// This removed_region is needed to boot the device
> // TODO: Find out the user of this reserved memory
> removed_region: memory@88f00000 {
This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
Konrad
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2020-08-06 22:31 ` Konrad Dybcio
@ 2020-08-13 7:04 ` Bjorn Andersson
2020-08-17 17:12 ` Amit Pundir
0 siblings, 1 reply; 669+ messages in thread
From: Bjorn Andersson @ 2020-08-13 7:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: amit.pundir, agross, devicetree, john.stultz, linux-arm-msm,
linux-kernel, robh+dt, sumit.semwal
On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
> Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
>
> >// This removed_region is needed to boot the device
> > // TODO: Find out the user of this reserved memory
> > removed_region: memory@88f00000 {
>
> This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
>
This is in line with what the documentation indicates and then it would
be better to just bump &tz_mem to a size of 0x4900000.
Regards,
Bjorn
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2020-08-13 7:04 ` your mail Bjorn Andersson
@ 2020-08-17 17:12 ` Amit Pundir
2020-08-30 18:58 ` Bjorn Andersson
0 siblings, 1 reply; 669+ messages in thread
From: Amit Pundir @ 2020-08-17 17:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Andy Gross, dt, John Stultz, linux-arm-msm, lkml,
Rob Herring, Sumit Semwal
On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
>
> > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> >
> > >// This removed_region is needed to boot the device
> > > // TODO: Find out the user of this reserved memory
> > > removed_region: memory@88f00000 {
> >
> > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> >
>
> This is in line with what the documentation indicates and then it would
> be better to just bump &tz_mem to a size of 0x4900000.
Hi, so just to be sure that I got this right, you want me to extend
&tz_mem to the size of 0x4900000 from the default size of 0x2D00000 by
including this downstream &removed_region (of size 0x1A00000) +
previously unreserved downstream memory region (of size 0x200000), to
align with the starting address of &qseecom_mem?
I just gave this &tz_mem change a spin and I do not see any obvious
regression in my limited smoke testing (Boots AOSP to UI with
v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
Regards,
Amit Pundir
>
> Regards,
> Bjorn
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2020-08-17 17:12 ` Amit Pundir
@ 2020-08-30 18:58 ` Bjorn Andersson
0 siblings, 0 replies; 669+ messages in thread
From: Bjorn Andersson @ 2020-08-30 18:58 UTC (permalink / raw)
To: Amit Pundir
Cc: Konrad Dybcio, Andy Gross, dt, John Stultz, linux-arm-msm, lkml,
Rob Herring, Sumit Semwal
On Mon 17 Aug 17:12 UTC 2020, Amit Pundir wrote:
> On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
> >
> > > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> > >
> > > >// This removed_region is needed to boot the device
> > > > // TODO: Find out the user of this reserved memory
> > > > removed_region: memory@88f00000 {
> > >
> > > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> > >
> >
> > This is in line with what the documentation indicates and then it would
> > be better to just bump &tz_mem to a size of 0x4900000.
>
> Hi, so just to be sure that I got this right, you want me to extend
> &tz_mem to the size of 0x4900000 from the default size of 0x2D00000 by
> including this downstream &removed_region (of size 0x1A00000) +
> previously unreserved downstream memory region (of size 0x200000), to
> align with the starting address of &qseecom_mem?
>
Yes
Regards,
Bjorn
> I just gave this &tz_mem change a spin and I do not see any obvious
> regression in my limited smoke testing (Boots AOSP to UI with
> v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
>
> Regards,
> Amit Pundir
>
> >
> > Regards,
> > Bjorn
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2020-08-05 10:57 Jacopo Mondi
2020-08-09 15:53 ` your mail Laurent Pinchart
0 siblings, 1 reply; 669+ messages in thread
From: Jacopo Mondi @ 2020-08-05 10:57 UTC (permalink / raw)
To: Hans Verkuil, Sakari Ailus, Laurent Pinchart
Cc: Jacopo Mondi, Linux Media Mailing List, Sowjanya Komatineni,
Ricardo Ribalda Delgado, libcamera-devel
Subject: [PATCH 0/4] media: docs: Document pixel array properties
Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
on how the V4L2 selection targets have to be used in order to access an
image sensor pixel array properties.
The discussion shown how much under-specified that part was, so this is
an attempt to provide a bit documentation for this.
My feeling is that we're hijacking the existing targets for this use case
and we should probably define new ones, considering how few users we have in
mainline of them at the moment.
On top Hans' patch with reworded commit message and minor updates.
For reference, we're using the V4L2 selection targets in libcamera to retrieve
the sensor pixel array properties to be reported to applications for
calibration purposes. The currently defined pixel properties for libcamera
are available here:
https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
Thanks
j
Hans Verkuil (1):
media: i2c: imx219: Selection compliance fixes
Jacopo Mondi (3):
media: docs: Describe pixel array properties
media: docs: Describe targets for sensor properties
media: docs: USe SUBDEV_G_SELECTION for sensor properties
.../userspace-api/media/v4l/dev-subdev.rst | 85 +++++++++++++++++++
.../media/v4l/v4l2-selection-targets.rst | 49 +++++++++++
.../media/v4l/vidioc-subdev-g-selection.rst | 4 +
drivers/media/i2c/imx219.c | 17 ++--
4 files changed, 147 insertions(+), 8 deletions(-)
--
2.27.0
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2020-08-05 10:57 Jacopo Mondi
@ 2020-08-09 15:53 ` Laurent Pinchart
2020-08-10 7:28 ` Jacopo Mondi
0 siblings, 1 reply; 669+ messages in thread
From: Laurent Pinchart @ 2020-08-09 15:53 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Hans Verkuil, Sakari Ailus, Linux Media Mailing List,
Sowjanya Komatineni, Ricardo Ribalda Delgado, libcamera-devel
Hi Jacopo,
On Wed, Aug 05, 2020 at 12:57:17PM +0200, Jacopo Mondi wrote:
> Subject: [PATCH 0/4] media: docs: Document pixel array properties
>
> Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
> on how the V4L2 selection targets have to be used in order to access an
> image sensor pixel array properties.
>
> The discussion shown how much under-specified that part was, so this is
> an attempt to provide a bit documentation for this.
>
> My feeling is that we're hijacking the existing targets for this use case
> and we should probably define new ones, considering how few users we have in
> mainline of them at the moment.
Do you mean you think we should create new targets instead of reusing
the existing ones as you do in this series ? I don't see anything really
wrong in reusing the existing targets, provided we document them
properly, and it's not too much of a hack (that is, the documented
purpose reasonably matches the target name), but maybe I'm missing the
issue.
> On top Hans' patch with reworded commit message and minor updates.
>
> For reference, we're using the V4L2 selection targets in libcamera to retrieve
> the sensor pixel array properties to be reported to applications for
> calibration purposes. The currently defined pixel properties for libcamera
> are available here:
> https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
>
> Thanks
> j
>
> Hans Verkuil (1):
> media: i2c: imx219: Selection compliance fixes
>
> Jacopo Mondi (3):
> media: docs: Describe pixel array properties
> media: docs: Describe targets for sensor properties
> media: docs: USe SUBDEV_G_SELECTION for sensor properties
>
> .../userspace-api/media/v4l/dev-subdev.rst | 85 +++++++++++++++++++
> .../media/v4l/v4l2-selection-targets.rst | 49 +++++++++++
> .../media/v4l/vidioc-subdev-g-selection.rst | 4 +
> drivers/media/i2c/imx219.c | 17 ++--
> 4 files changed, 147 insertions(+), 8 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2020-08-09 15:53 ` your mail Laurent Pinchart
@ 2020-08-10 7:28 ` Jacopo Mondi
2020-08-19 0:36 ` Laurent Pinchart
0 siblings, 1 reply; 669+ messages in thread
From: Jacopo Mondi @ 2020-08-10 7:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Hans Verkuil, Sakari Ailus, Linux Media Mailing List,
Sowjanya Komatineni, Ricardo Ribalda Delgado, libcamera-devel
Hi Laurent,
On Sun, Aug 09, 2020 at 06:53:11PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Aug 05, 2020 at 12:57:17PM +0200, Jacopo Mondi wrote:
> > Subject: [PATCH 0/4] media: docs: Document pixel array properties
> >
> > Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
> > on how the V4L2 selection targets have to be used in order to access an
> > image sensor pixel array properties.
> >
> > The discussion shown how much under-specified that part was, so this is
> > an attempt to provide a bit documentation for this.
> >
> > My feeling is that we're hijacking the existing targets for this use case
> > and we should probably define new ones, considering how few users we have in
> > mainline of them at the moment.
>
> Do you mean you think we should create new targets instead of reusing
> the existing ones as you do in this series ? I don't see anything really
> wrong in reusing the existing targets, provided we document them
> properly, and it's not too much of a hack (that is, the documented
> purpose reasonably matches the target name), but maybe I'm missing the
> issue.
Yes, that's what I meant.
To me, if you have something and you need to document it with "if
applied to X it means Y, if applied to Z it means W etcetc" feels like
we're abusing it. Having sensor's specific targets would make clear
what a target represents without the ambiguities of defining the
symbol semantic depending on the device it applies to (which means
userspace would need to know what kind of device it's dealing with
precisely).
That said, my preference would be using a different API, but see my
reply to your other email for that.
Thanks
j
>
> > On top Hans' patch with reworded commit message and minor updates.
> >
> > For reference, we're using the V4L2 selection targets in libcamera to retrieve
> > the sensor pixel array properties to be reported to applications for
> > calibration purposes. The currently defined pixel properties for libcamera
> > are available here:
> > https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
> >
> > Thanks
> > j
> >
> > Hans Verkuil (1):
> > media: i2c: imx219: Selection compliance fixes
> >
> > Jacopo Mondi (3):
> > media: docs: Describe pixel array properties
> > media: docs: Describe targets for sensor properties
> > media: docs: USe SUBDEV_G_SELECTION for sensor properties
> >
> > .../userspace-api/media/v4l/dev-subdev.rst | 85 +++++++++++++++++++
> > .../media/v4l/v4l2-selection-targets.rst | 49 +++++++++++
> > .../media/v4l/vidioc-subdev-g-selection.rst | 4 +
> > drivers/media/i2c/imx219.c | 17 ++--
> > 4 files changed, 147 insertions(+), 8 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2020-08-10 7:28 ` Jacopo Mondi
@ 2020-08-19 0:36 ` Laurent Pinchart
0 siblings, 0 replies; 669+ messages in thread
From: Laurent Pinchart @ 2020-08-19 0:36 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Hans Verkuil, Sakari Ailus, Linux Media Mailing List,
Sowjanya Komatineni, Ricardo Ribalda Delgado, libcamera-devel
Hi Jacopo,
On Mon, Aug 10, 2020 at 09:28:14AM +0200, Jacopo Mondi wrote:
> On Sun, Aug 09, 2020 at 06:53:11PM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 05, 2020 at 12:57:17PM +0200, Jacopo Mondi wrote:
> > > Subject: [PATCH 0/4] media: docs: Document pixel array properties
> > >
> > > Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
> > > on how the V4L2 selection targets have to be used in order to access an
> > > image sensor pixel array properties.
> > >
> > > The discussion shown how much under-specified that part was, so this is
> > > an attempt to provide a bit documentation for this.
> > >
> > > My feeling is that we're hijacking the existing targets for this use case
> > > and we should probably define new ones, considering how few users we have in
> > > mainline of them at the moment.
> >
> > Do you mean you think we should create new targets instead of reusing
> > the existing ones as you do in this series ? I don't see anything really
> > wrong in reusing the existing targets, provided we document them
> > properly, and it's not too much of a hack (that is, the documented
> > purpose reasonably matches the target name), but maybe I'm missing the
> > issue.
>
> Yes, that's what I meant.
>
> To me, if you have something and you need to document it with "if
> applied to X it means Y, if applied to Z it means W etcetc" feels like
> we're abusing it.
I don't really agree, I think this is common, and I don't really see a
problem. Lots of V4L2 ioctls (or the structures they use) document how
they apply to capture and output devices for instance, and I don't think
that splitting ioctls into _CAPTURE and _OUTPUT variants would help
much.
If you were using a COMPOSE rectangle to specify a crop operation when
used with camera sensors it would of course be an API abuse, but as long
as CROP is crop, I see nothing wrong in differences in details of how
the rectangles apply to different types of devices.
> Having sensor's specific targets would make clear
> what a target represents without the ambiguities of defining the
> symbol semantic depending on the device it applies to (which means
> userspace would need to know what kind of device it's dealing with
> precisely).
Userspace would always need that, in order to pick the applicable
target.
> That said, my preference would be using a different API, but see my
> reply to your other email for that.
>
> > > On top Hans' patch with reworded commit message and minor updates.
> > >
> > > For reference, we're using the V4L2 selection targets in libcamera to retrieve
> > > the sensor pixel array properties to be reported to applications for
> > > calibration purposes. The currently defined pixel properties for libcamera
> > > are available here:
> > > https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
> > >
> > > Thanks
> > > j
> > >
> > > Hans Verkuil (1):
> > > media: i2c: imx219: Selection compliance fixes
> > >
> > > Jacopo Mondi (3):
> > > media: docs: Describe pixel array properties
> > > media: docs: Describe targets for sensor properties
> > > media: docs: USe SUBDEV_G_SELECTION for sensor properties
> > >
> > > .../userspace-api/media/v4l/dev-subdev.rst | 85 +++++++++++++++++++
> > > .../media/v4l/v4l2-selection-targets.rst | 49 +++++++++++
> > > .../media/v4l/vidioc-subdev-g-selection.rst | 4 +
> > > drivers/media/i2c/imx219.c | 17 ++--
> > > 4 files changed, 147 insertions(+), 8 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <CAK9MGy3D5UBf06OY16UW=c+Cybm67x+0kH_OWJkX7ywdQD9CNA@mail.gmail.com>]
* (no subject)
@ 2020-06-24 0:38 shejan shuza
2020-06-24 1:31 ` your mail brian m. carlson
0 siblings, 1 reply; 669+ messages in thread
From: shejan shuza @ 2020-06-24 0:38 UTC (permalink / raw)
To: git
Hi, I have a repository with about 55GB of contents, with binary files
that are less than 100MB each (so no LFS mode) from a project which
has almost filled up an entire hard drive. I am trying to add all of
the contents to a git repo and push it to GitHub but every time I do
git add .
in the folder with my contents after initializing and setting my
remote, git starts caching all the files to .git/objects, making the
.git folder grow in size rapidly. All the files are binaries, so git
cannot stage changes between versions anyway, so there is no reason to
cache versions.
Is there any way, such as editing the git attributes or changing
something about how files are staged in the git repository, to only
just add indexes or references to files in the repository rather than
cache them into the .git folder, while also being able to push all the
data to GitHub?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2020-06-24 0:38 shejan shuza
@ 2020-06-24 1:31 ` brian m. carlson
0 siblings, 0 replies; 669+ messages in thread
From: brian m. carlson @ 2020-06-24 1:31 UTC (permalink / raw)
To: shejan shuza; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]
On 2020-06-24 at 00:38:39, shejan shuza wrote:
> Hi, I have a repository with about 55GB of contents, with binary files
> that are less than 100MB each (so no LFS mode) from a project which
> has almost filled up an entire hard drive. I am trying to add all of
> the contents to a git repo and push it to GitHub but every time I do
>
> git add .
>
> in the folder with my contents after initializing and setting my
> remote, git starts caching all the files to .git/objects, making the
> .git folder grow in size rapidly. All the files are binaries, so git
> cannot stage changes between versions anyway, so there is no reason to
> cache versions.
What you're experiencing is normal; storing files in the .git directory
is how Git keeps track of them. It can't rely on the copies in your
working tree because you can modify those files at any time, and if you
did so, relying on them would corrupt the repository.
Also, note that Git can and does deltify changes between revisions once
the data is packed, regardless of whether the file is binary, but how
well it does so depends on your data. For example, if it's compressed,
it likely doesn't deltify very well, so storing things like compressed
images or zip files using deflate is generally going to result in a
bloated repository.
However, if you don't need versioning for these files, then you don't
need a Git repository. Git is a tool for versioning files, not a
general storage mechanism. You may find a cloud storage bucket or some
other artifact storage service may meet your needs better.
I will also tell you from a practical point of view that almost nobody
(including you) will want to host a 55 GB repository filled with binary
blobs. Usually repacking these repositories is very expensive,
requiring extensive CPU and memory usage for a prolonged time for little
useful benefit.
> Is there any way, such as editing the git attributes or changing
> something about how files are staged in the git repository, to only
> just add indexes or references to files in the repository rather than
> cache them into the .git folder, while also being able to push all the
> data to GitHub?
This is how Git LFS and similar tools, like git-annex, work. Git LFS
will create copies of the objects in your .git directory though, at
least until they're pushed to the server, at which point they can be
pruned. Git LFS has the same limitation as Git here. I'm less familiar
with git-annex, but it is also a popular choice.
However, as mentioned, it sounds like you don't need versioning at all,
so unless you do, Git with Git LFS will be no more suitable for this
than plain Git. If that's the case, I encourage you to explore
alternate solutions.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2020-06-09 11:38 Gaurav Singh
2020-06-09 11:54 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: Gaurav Singh @ 2020-06-09 11:38 UTC (permalink / raw)
To: gaurav1086, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko,
John Fastabend, KP Singh, David S. Miller, Jakub Kicinski,
Jesper Dangaard Brouer,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools),
open list
Please find the patch below.
Thanks and regards,
Gaurav.
From Gaurav Singh <gaurav1086@gmail.com> # This line is ignored.
From: Gaurav Singh <gaurav1086@gmail.com>
Reply-To:
Subject:
In-Reply-To:
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2020-06-09 11:38 Gaurav Singh
@ 2020-06-09 11:54 ` Greg KH
0 siblings, 0 replies; 669+ messages in thread
From: Greg KH @ 2020-06-09 11:54 UTC (permalink / raw)
To: Gaurav Singh
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Andrii Nakryiko, John Fastabend, KP Singh,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools),
open list
On Tue, Jun 09, 2020 at 07:38:38AM -0400, Gaurav Singh wrote:
> Please find the patch below.
>
> Thanks and regards,
> Gaurav.
>
> >From Gaurav Singh <gaurav1086@gmail.com> # This line is ignored.
> From: Gaurav Singh <gaurav1086@gmail.com>
> Reply-To:
> Subject:
> In-Reply-To:
>
>
I think something went wrong in your submission, just use 'git
send-email' to send the patch out.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <526351589195104@mail.yandex.com>]
* Re: your mail
[not found] <526351589195104@mail.yandex.com>
@ 2020-05-11 11:35 ` Heikki Krogerus
[not found] ` <20200511113506.GB2062175-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: Heikki Krogerus @ 2020-05-11 11:35 UTC (permalink / raw)
To: jakub, Andy Shevchenko; +Cc: linux-usb
+Andy
Adding also the linux-usb mailing list.
On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> with cpu interrups causing issues with deeper CPU sleep and increased power
> usage. Also load is always 1 even if machine has nothing to do.
>
> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> device is related with USB and according to datasheet it's "USB Interface IC USB
> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> nothing connected to NUC except power plug and ethernet cable.
>
> Screenshots: https://imgur.com/a/uw9NDCi
>
> How to solve this issue? Could you help me?
My guess is that the IRQ resource is not correct for the PD
controller causing you to see irq flood.
The problem is that the ACPI device entry (the node) on this platform
has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
single ACPI device entry can represent up to 4 USB PD controllers. The
problem is that there is no way to know which IRQ resource belongs to
which I2CSerialBus resource :-(.
Andy, this is one of those multi-instantiate I2C slave devices with
HID INT3515.
The only solution I can think of is that we start maintaining DMI
quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
supply the correct i2c to irq resource mapping for every platform
that has this device(s).
> Kernel version:
>
> Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>
> Bios version:
> FNCML357 Version: 0039 Date: 3/12/2020
> --
> Best regards
> Jakub Bilan
thanks,
--
heikki
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2020-05-06 5:52 Jiaxun Yang
2020-05-07 11:00 ` your mail Thomas Bogendoerfer
0 siblings, 1 reply; 669+ messages in thread
From: Jiaxun Yang @ 2020-05-06 5:52 UTC (permalink / raw)
To: linux-mips
Cc: Jiaxun Yang, clang-built-linux, Maciej W . Rozycki, Fangrui Song,
Kees Cook, Nathan Chancellor, Thomas Bogendoerfer, Paul Burton,
Masahiro Yamada, Jouni Hogander, Kevin Darbyshire-Bryant,
Borislav Petkov, Heiko Carstens, linux-kernel
Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com>
LLD failed to link vmlinux with 64bit load address for 32bit ELF
while bfd will strip 64bit address into 32bit silently.
To fix LLD build, we should truncate load address provided by platform
into 32bit for 32bit kernel.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/786
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
---
V2: Take MaskRay's shell magic.
V3: After spent an hour on dealing with special character issue in
Makefile, I gave up to do shell hacks and write a util in C instead.
Thanks Maciej for pointing out Makefile variable problem.
v4: Finally we managed to find a Makefile method to do it properly
thanks to Kees. As it's too far from the initial version, I removed
Review & Test tag from Nick and Fangrui and Cc instead.
v5: Care vmlinuz as well.
v6: Rename to LIKER_LOAD_ADDRESS
---
arch/mips/Makefile | 13 ++++++++++++-
arch/mips/boot/compressed/Makefile | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index e1c44aed8156..68c0f22fefc0 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -288,12 +288,23 @@ ifdef CONFIG_64BIT
endif
endif
+# When linking a 32-bit executable the LLVM linker cannot cope with a
+# 32-bit load address that has been sign-extended to 64 bits. Simply
+# remove the upper 32 bits then, as it is safe to do so with other
+# linkers.
+ifdef CONFIG_64BIT
+ load-ld = $(load-y)
+else
+ load-ld = $(subst 0xffffffff,0x,$(load-y))
+endif
+
KBUILD_AFLAGS += $(cflags-y)
KBUILD_CFLAGS += $(cflags-y)
-KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
+KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DLINKER_LOAD_ADDRESS=$(load-ld)
KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0)
bootvars-y = VMLINUX_LOAD_ADDRESS=$(load-y) \
+ LINKER_LOAD_ADDRESS=$(load-ld) \
VMLINUX_ENTRY_ADDRESS=$(entry-y) \
PLATFORM="$(platform-y)" \
ITS_INPUTS="$(its-y)"
diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile
index 0df0ee8a298d..3d391256ab7e 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -90,7 +90,7 @@ ifneq ($(zload-y),)
VMLINUZ_LOAD_ADDRESS := $(zload-y)
else
VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
- $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
+ $(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS))
endif
UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS)
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index a5f00ec73ea6..5226cd8e4bee 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -55,7 +55,7 @@ SECTIONS
/* . = 0xa800000000300000; */
. = 0xffffffff80300000;
#endif
- . = VMLINUX_LOAD_ADDRESS;
+ . = LINKER_LOAD_ADDRESS;
/* read-only */
_text = .; /* Text and read-only data */
.text : {
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2020-05-06 5:52 Jiaxun Yang
@ 2020-05-07 11:00 ` Thomas Bogendoerfer
0 siblings, 0 replies; 669+ messages in thread
From: Thomas Bogendoerfer @ 2020-05-07 11:00 UTC (permalink / raw)
To: Jiaxun Yang
Cc: linux-mips, clang-built-linux, Maciej W . Rozycki, Fangrui Song,
Kees Cook, Nathan Chancellor, Paul Burton, Masahiro Yamada,
Jouni Hogander, Kevin Darbyshire-Bryant, Borislav Petkov,
Heiko Carstens, linux-kernel
On Wed, May 06, 2020 at 01:52:45PM +0800, Jiaxun Yang wrote:
> Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
> In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com>
>
> LLD failed to link vmlinux with 64bit load address for 32bit ELF
> while bfd will strip 64bit address into 32bit silently.
> To fix LLD build, we should truncate load address provided by platform
> into 32bit for 32bit kernel.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/786
> Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
> Reviewed-by: Fangrui Song <maskray@google.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> Cc: Maciej W. Rozycki <macro@linux-mips.org>
> ---
> V2: Take MaskRay's shell magic.
>
> V3: After spent an hour on dealing with special character issue in
> Makefile, I gave up to do shell hacks and write a util in C instead.
> Thanks Maciej for pointing out Makefile variable problem.
>
> v4: Finally we managed to find a Makefile method to do it properly
> thanks to Kees. As it's too far from the initial version, I removed
> Review & Test tag from Nick and Fangrui and Cc instead.
>
> v5: Care vmlinuz as well.
>
> v6: Rename to LIKER_LOAD_ADDRESS
> ---
> arch/mips/Makefile | 13 ++++++++++++-
> arch/mips/boot/compressed/Makefile | 2 +-
> arch/mips/kernel/vmlinux.lds.S | 2 +-
> 3 files changed, 14 insertions(+), 3 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2019-11-20 3:49 Han-Wen Nienhuys
2019-11-20 5:30 ` your mail Taylor Blau
0 siblings, 1 reply; 669+ messages in thread
From: Han-Wen Nienhuys @ 2019-11-20 3:49 UTC (permalink / raw)
To: git, Christian Couder, Johannes Schindelin
Hey folks,
I spent the last few weeks cobbling together an implementation of the
reftable format in C and in Go. I thought this would be cool to add to
git-core, but I doubt whether I will have enough time to see such an
effort through. Maybe some of you would want to try integrating it
into the Git-core code base? Example code is here:
https://github.com/google/reftable/blob/master/c/api.h#L153
cheers!
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-11-20 3:49 Han-Wen Nienhuys
@ 2019-11-20 5:30 ` Taylor Blau
2019-11-20 8:05 ` Christian Couder
0 siblings, 1 reply; 669+ messages in thread
From: Taylor Blau @ 2019-11-20 5:30 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git, Christian Couder, Johannes Schindelin
Hi Han-Wen,
On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> Hey folks,
>
> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base? Example code is here:
>
> https://github.com/google/reftable/blob/master/c/api.h#L153
Very exciting, and thanks for your work on this. I haven't taken a
close look at the code yet, so I'm sure taking this further involves a
much more careful examination.
I know that Christian Couder (who you CC-d on this thread) was also
working on this for either GitLab or Booking.com.
Christian -- are you still working on this for either one of those
entities? If so, is there some way to unify these two efforts?
> cheers!
> --
Thanks,
Taylor
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-11-20 5:30 ` your mail Taylor Blau
@ 2019-11-20 8:05 ` Christian Couder
0 siblings, 0 replies; 669+ messages in thread
From: Christian Couder @ 2019-11-20 8:05 UTC (permalink / raw)
To: Taylor Blau; +Cc: Han-Wen Nienhuys, git, Johannes Schindelin
Hi Taylor and Han-Wen,
On Wed, Nov 20, 2019 at 6:30 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> >
> > I spent the last few weeks cobbling together an implementation of the
> > reftable format in C and in Go. I thought this would be cool to add to
> > git-core, but I doubt whether I will have enough time to see such an
> > effort through. Maybe some of you would want to try integrating it
> > into the Git-core code base? Example code is here:
> >
> > https://github.com/google/reftable/blob/master/c/api.h#L153
Interesting!
> Very exciting, and thanks for your work on this. I haven't taken a
> close look at the code yet, so I'm sure taking this further involves a
> much more careful examination.
>
> I know that Christian Couder (who you CC-d on this thread) was also
> working on this for either GitLab or Booking.com.
>
> Christian -- are you still working on this for either one of those
> entities? If so, is there some way to unify these two efforts?
Yeah, I started working on this last year for Booking.com, and I am
now slowly working on it for GitLab. It is not yet finished because it
has been low priority work.
I took a very quick look at Han-Wen's implementation and it looks very
different from mine from the outside. It seems more complete, but
might be less integrated into the Git code base.
Best,
Christian.
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20191026192359.27687-1-frank-w@public-files.de>]
* Re: your mail
[not found] <20191026192359.27687-1-frank-w@public-files.de>
2019-10-26 19:30 ` Greg Kroah-Hartman
@ 2019-10-26 19:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 669+ messages in thread
From: Greg Kroah-Hartman @ 2019-10-26 19:30 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-mediatek, Matthias Brugger, linux-serial, linux-arm-kernel,
linux-kernel
On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one
Odd email with no subject line :(
Plaese fix up and resend.
thanks,
greg k-h-
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2019-10-26 19:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 669+ messages in thread
From: Greg Kroah-Hartman @ 2019-10-26 19:30 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Matthias Brugger, linux-mediatek, linux-arm-kernel, linux-serial,
linux-kernel
On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one
Odd email with no subject line :(
Plaese fix up and resend.
thanks,
greg k-h-
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-10-26 19:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 669+ messages in thread
From: Greg Kroah-Hartman @ 2019-10-26 19:30 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Matthias Brugger, linux-mediatek, linux-arm-kernel, linux-serial,
linux-kernel
On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one
Odd email with no subject line :(
Plaese fix up and resend.
thanks,
greg k-h-
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2019-07-11 20:11 Robert Morgan
2019-07-11 20:18 ` your mail Kevin Daudt
0 siblings, 1 reply; 669+ messages in thread
From: Robert Morgan @ 2019-07-11 20:11 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-07-11 20:11 Robert Morgan
@ 2019-07-11 20:18 ` Kevin Daudt
2019-07-11 20:25 ` Robert Morgan
0 siblings, 1 reply; 669+ messages in thread
From: Kevin Daudt @ 2019-07-11 20:18 UTC (permalink / raw)
To: Robert Morgan; +Cc: git
On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git
You need to send this to majordomo@vger.kernel.org. Sending it to the
git mailing list will not do a lot.
Kevin
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-07-11 20:18 ` your mail Kevin Daudt
@ 2019-07-11 20:25 ` Robert Morgan
0 siblings, 0 replies; 669+ messages in thread
From: Robert Morgan @ 2019-07-11 20:25 UTC (permalink / raw)
To: Kevin Daudt, Robert Morgan, git
Apologies list! Thanks Kevin. That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.
Robert
On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt <me@ikke.info> wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> > subscribe git
>
> You need to send this to majordomo@vger.kernel.org. Sending it to the
> git mailing list will not do a lot.
>
> Kevin
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20190626145238.19708-1-bigeasy@linutronix.de>]
[parent not found: <92179e5f-d73e-974c-774e-09c2813434c0@gmail.com>]
[parent not found: <20190411060536.22409-1-npiggin@gmail.com>]
* Re: your mail
[not found] <20190411060536.22409-1-npiggin@gmail.com>
@ 2019-04-11 10:53 ` Peter Zijlstra
2019-04-12 3:23 ` Nicholas Piggin
0 siblings, 1 reply; 669+ messages in thread
From: Peter Zijlstra @ 2019-04-11 10:53 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Thomas Gleixner, Frederic Weisbecker, Ingo Molnar, linux-kernel
Was this supposed to be patch 6/5 of your previous series?
On Thu, Apr 11, 2019 at 04:05:36PM +1000, Nicholas Piggin wrote:
> Date: Tue, 9 Apr 2019 20:23:16 +1000
> Subject: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC
> CPUs
>
> The nohz idle balancer runs on the lowest idle CPU. This can
> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
> housekeeping CPUs.
>
> HK_FLAG_SCHED is not used for this because it is not set anywhere
> at the moment. This could be folded into HK_FLAG_SCHED once that
> option is fixed.
>
> The problem was observed with increased jitter on an application
> running on CPU0, caused by nohz idle load balancing being run on
> CPU1 (an SMT sibling).
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> kernel/sched/fair.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fdab7eb6f351..d29ca323214d 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
> * - When one of the busy CPUs notice that there may be an idle rebalancing
> * needed, they will kick the idle load balancer, which then does idle
> * load balancing for all the idle CPUs.
> + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
> + * anywhere yet.
> */
>
> static inline int find_new_ilb(void)
> {
> - int ilb = cpumask_first(nohz.idle_cpus_mask);
> + int ilb;
>
> - if (ilb < nr_cpu_ids && idle_cpu(ilb))
> - return ilb;
> + for_each_cpu_and(ilb, nohz.idle_cpus_mask,
> + housekeeping_cpumask(HK_FLAG_MISC)) {
> + if (idle_cpu(ilb))
> + return ilb;
> + }
>
> return nr_cpu_ids;
> }
>
> /*
> - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
> - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
> - * CPU (if there is one).
> + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
> + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
> */
> static void kick_ilb(unsigned int flags)
> {
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2019-04-11 10:53 ` Peter Zijlstra
@ 2019-04-12 3:23 ` Nicholas Piggin
0 siblings, 0 replies; 669+ messages in thread
From: Nicholas Piggin @ 2019-04-12 3:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Frederic Weisbecker, linux-kernel, Ingo Molnar, Thomas Gleixner
Peter Zijlstra's on April 11, 2019 8:53 pm:
> Was this supposed to be patch 6/5 of your previous series?
Dang, I screwed up the headers? Thanks for the ping, I will resend.
It is standalone. It seems more suited to the scheduler tree than the
timers one, but your call.
It is generally of more use when CPU0 is _not_ a housekeeping one,
and that's where I've done most testing, but I don't see any hard
dependency.
Thanks,
Nick
>
> On Thu, Apr 11, 2019 at 04:05:36PM +1000, Nicholas Piggin wrote:
>> Date: Tue, 9 Apr 2019 20:23:16 +1000
>> Subject: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC
>> CPUs
>>
>> The nohz idle balancer runs on the lowest idle CPU. This can
>> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
>> housekeeping CPUs.
>>
>> HK_FLAG_SCHED is not used for this because it is not set anywhere
>> at the moment. This could be folded into HK_FLAG_SCHED once that
>> option is fixed.
>>
>> The problem was observed with increased jitter on an application
>> running on CPU0, caused by nohz idle load balancing being run on
>> CPU1 (an SMT sibling).
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> kernel/sched/fair.c | 16 ++++++++++------
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index fdab7eb6f351..d29ca323214d 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
>> * - When one of the busy CPUs notice that there may be an idle rebalancing
>> * needed, they will kick the idle load balancer, which then does idle
>> * load balancing for all the idle CPUs.
>> + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
>> + * anywhere yet.
>> */
>>
>> static inline int find_new_ilb(void)
>> {
>> - int ilb = cpumask_first(nohz.idle_cpus_mask);
>> + int ilb;
>>
>> - if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> - return ilb;
>> + for_each_cpu_and(ilb, nohz.idle_cpus_mask,
>> + housekeeping_cpumask(HK_FLAG_MISC)) {
>> + if (idle_cpu(ilb))
>> + return ilb;
>> + }
>>
>> return nr_cpu_ids;
>> }
>>
>> /*
>> - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
>> - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
>> - * CPU (if there is one).
>> + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
>> + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
>> */
>> static void kick_ilb(unsigned int flags)
>> {
>> --
>> 2.20.1
>>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20190323171738.GA26736@titus.pi.local>]
* Re: your mail
[not found] <20190323171738.GA26736@titus.pi.local>
@ 2019-03-26 8:42 ` Dan Carpenter
0 siblings, 0 replies; 669+ messages in thread
From: Dan Carpenter @ 2019-03-26 8:42 UTC (permalink / raw)
To: William J. Cunningham; +Cc: gregkh, devel, linux-kernel
On Sat, Mar 23, 2019 at 01:17:38PM -0400, William J. Cunningham wrote:
> >From bb04b0ca982b7042902fffe1377e0e38e83b402b Mon Sep 17 00:00:00 2001
> From: Will Cunningham <wjcunningham7@gmail.com>
> Date: Sat, 23 Mar 2019 12:54:34 -0400
> Subject: [PATCH] Staging: emxx_udc: emxx_udc: Fixed a coding style error
>
> Removed unnecessary parentheses.
>
> Signed-off-by: Will Cunningham <wjcunningham7@gmail.com>
Please fix up the headers and resend.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20190319022012.11051-1-thirtythreeforty@gmail.com>]
* Re: your mail
[not found] <20190319022012.11051-1-thirtythreeforty@gmail.com>
@ 2019-03-20 7:26 ` Greg Kroah-Hartman
0 siblings, 0 replies; 669+ messages in thread
From: Greg Kroah-Hartman @ 2019-03-20 7:26 UTC (permalink / raw)
To: George Hilliard; +Cc: linux-mips, linux-kernel
On Mon, Mar 18, 2019 at 08:20:01PM -0600, George Hilliard wrote:
> Because of this change, the driver now expects a pinctrl device
> reference in the mmc controller's device tree node; without it, it will
> bail out. This could break existing setups that don't specify it
> because it "just worked" up until now. So currently I just let the old
> behavior fall away because this is a staging driver. But if this is a
> problem, the old behavior could be added back as a fallback.
>
> This is version 2 of a patchset that I requested feedback for about a
> month ago. Please review as if they are a new patchset; all the patches
> were rebased several times and a couple new correctness fixes added.
>
> The TODO list is largely unchanged, aside from the couple of TODO
> comments in the code that I have addressed. Ultimately, I think this
> driver could potentially be merged with the "real" mtk-mmc driver as the
> TODO suggests, but someone who is more familiar with the IP core will
> have to do that. Mediatek documentation (that I can find) is very
> sparse.
>
> This is ready to merge if there is no other feedback!
>
> >From George Hilliard <thirtythreeforty@gmail.com> # This line is ignored.
> From: George Hilliard <thirtythreeforty@gmail.com>
> Reply-To:
> Subject: [PATCH v2 00/11] mt7621-mmc: Various correctness fixes
> In-Reply-To:
>
>
No subject for this email?
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2019-03-19 14:41 Maxim Levitsky
2019-03-19 15:22 ` Keith Busch
2019-03-21 16:13 ` Stefan Hajnoczi
0 siblings, 2 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-19 14:41 UTC (permalink / raw)
To: linux-nvme
Cc: Maxim Levitsky, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John
Date: Tue, 19 Mar 2019 14:45:45 +0200
Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
Hi everyone!
In this patch series, I would like to introduce my take on the problem of doing
as fast as possible virtualization of storage with emphasis on low latency.
In this patch series I implemented a kernel vfio based, mediated device that
allows the user to pass through a partition and/or whole namespace to a guest.
The idea behind this driver is based on paper you can find at
https://www.usenix.org/conference/atc18/presentation/peng,
Although note that I stared the development prior to reading this paper,
independently.
In addition to that implementation is not based on code used in the paper as
I wasn't being able at that time to make the source available to me.
***Key points about the implementation:***
* Polling kernel thread is used. The polling is stopped after a
predefined timeout (1/2 sec by default).
Support for all interrupt driven mode is planned, and it shows promising results.
* Guest sees a standard NVME device - this allows to run guest with
unmodified drivers, for example windows guests.
* The NVMe device is shared between host and guest.
That means that even a single namespace can be split between host
and guest based on different partitions.
* Simple configuration
*** Performance ***
Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
and both latency and throughput is very similar to SPDK.
Soon I will test this on a better server and nvme device and provide
more formal performance numbers.
Latency numbers:
~80ms - spdk with fio plugin on the host.
~84ms - nvme driver on the host
~87ms - mdev-nvme + nvme driver in the guest
Throughput was following similar pattern as well.
* Configuration example
$ modprobe nvme mdev_queues=4
$ modprobe nvme-mdev
$ UUID=$(uuidgen)
$ DEVICE='device pci address'
$ echo $UUID > /sys/bus/pci/devices/$DEVICE/mdev_supported_types/nvme-2Q_V1/create
$ echo n1p3 > /sys/bus/mdev/devices/$UUID/namespaces/add_namespace #attach host namespace 1 parition 3
$ echo 11 > /sys/bus/mdev/devices/$UUID/settings/iothread_cpu #pin the io thread to cpu 11
Afterward boot qemu with
-device vfio-pci,sysfsdev=/sys/bus/mdev/devices/$UUID
Zero configuration on the guest.
*** FAQ ***
* Why to make this in the kernel? Why this is better that SPDK
-> Reuse the existing nvme kernel driver in the host. No new drivers in the guest.
-> Share the NVMe device between host and guest.
Even in fully virtualized configurations,
some partitions of nvme device could be used by guests as block devices
while others passed through with nvme-mdev to achieve balance between
all features of full IO stack emulation and performance.
-> NVME-MDEV is a bit faster due to the fact that in-kernel driver
can send interrupts to the guest directly without a context
switch that can be expensive due to meltdown mitigation.
-> Is able to utilize interrupts to get reasonable performance.
This is only implemented
as a proof of concept and not included in the patches,
but interrupt driven mode shows reasonable performance
-> This is a framework that later can be used to support NVMe devices
with more of the IO virtualization built-in
(IOMMU with PASID support coupled with device that supports it)
* Why to attach directly to nvme-pci driver and not use block layer IO
-> The direct attachment allows for better performance, but I will
check the possibility of using block IO, especially for fabrics drivers.
*** Implementation notes ***
* All guest memory is mapped into the physical nvme device
but not 1:1 as vfio-pci would do this.
This allows very efficient DMA.
To support this, patch 2 adds ability for a mdev device to listen on
guest's memory map events.
Any such memory is immediately pinned and then DMA mapped.
(Support for fabric drivers where this is not possible exits too,
in which case the fabric driver will do its own DMA mapping)
* nvme core driver is modified to announce the appearance
and disappearance of nvme controllers and namespaces,
to which the nvme-mdev driver is subscribed.
* nvme-pci driver is modified to expose raw interface of attaching to
and sending/polling the IO queues.
This allows the mdev driver very efficiently to submit/poll for the IO.
By default one host queue is used per each mediated device.
(support for other fabric based host drivers is planned)
* The nvme-mdev doesn't assume presence of KVM, thus any VFIO user, including
SPDK, a qemu running with tccg, ... can use this virtual device.
*** Testing ***
The device was tested with stock QEMU 3.0 on the host,
with host was using 5.0 kernel with nvme-mdev added and the following hardware:
* QEMU nvme virtual device (with nested guest)
* Intel DC P3700 on Xeon E5-2620 v2 server
* Samsung SM981 (in a Thunderbolt enclosure, with my laptop)
* Lenovo NVME device found in my laptop
The guest was tested with kernel 4.16, 4.18, 4.20 and
the same custom complied kernel 5.0
Windows 10 guest was tested too with both Microsoft's inbox driver and
open source community NVME driver
(https://lists.openfabrics.org/pipermail/nvmewin/2016-December/001420.html)
Testing was mostly done on x86_64, but 32 bit host/guest combination
was lightly tested too.
In addition to that, the virtual device was tested with nested guest,
by passing the virtual device to it,
using pci passthrough, qemu userspace nvme driver, and spdk
PS: I used to contribute to the kernel as a hobby using the
maximlevitsky@gmail.com address
Maxim Levitsky (9):
vfio/mdev: add .request callback
nvme/core: add some more values from the spec
nvme/core: add NVME_CTRL_SUSPENDED controller state
nvme/pci: use the NVME_CTRL_SUSPENDED state
nvme/pci: add known admin effects to augument admin effects log page
nvme/pci: init shadow doorbell after each reset
nvme/core: add mdev interfaces
nvme/core: add nvme-mdev core driver
nvme/pci: implement the mdev external queue allocation interface
MAINTAINERS | 5 +
drivers/nvme/Kconfig | 1 +
drivers/nvme/Makefile | 1 +
drivers/nvme/host/core.c | 149 +++++-
drivers/nvme/host/nvme.h | 55 ++-
drivers/nvme/host/pci.c | 385 ++++++++++++++-
drivers/nvme/mdev/Kconfig | 16 +
drivers/nvme/mdev/Makefile | 5 +
drivers/nvme/mdev/adm.c | 873 ++++++++++++++++++++++++++++++++++
drivers/nvme/mdev/events.c | 142 ++++++
drivers/nvme/mdev/host.c | 491 +++++++++++++++++++
drivers/nvme/mdev/instance.c | 802 +++++++++++++++++++++++++++++++
drivers/nvme/mdev/io.c | 563 ++++++++++++++++++++++
drivers/nvme/mdev/irq.c | 264 ++++++++++
drivers/nvme/mdev/mdev.h | 56 +++
drivers/nvme/mdev/mmio.c | 591 +++++++++++++++++++++++
drivers/nvme/mdev/pci.c | 247 ++++++++++
drivers/nvme/mdev/priv.h | 700 +++++++++++++++++++++++++++
drivers/nvme/mdev/udata.c | 390 +++++++++++++++
drivers/nvme/mdev/vcq.c | 207 ++++++++
drivers/nvme/mdev/vctrl.c | 514 ++++++++++++++++++++
drivers/nvme/mdev/viommu.c | 322 +++++++++++++
drivers/nvme/mdev/vns.c | 356 ++++++++++++++
drivers/nvme/mdev/vsq.c | 178 +++++++
drivers/vfio/mdev/vfio_mdev.c | 11 +
include/linux/mdev.h | 4 +
include/linux/nvme.h | 88 +++-
27 files changed, 7375 insertions(+), 41 deletions(-)
create mode 100644 drivers/nvme/mdev/Kconfig
create mode 100644 drivers/nvme/mdev/Makefile
create mode 100644 drivers/nvme/mdev/adm.c
create mode 100644 drivers/nvme/mdev/events.c
create mode 100644 drivers/nvme/mdev/host.c
create mode 100644 drivers/nvme/mdev/instance.c
create mode 100644 drivers/nvme/mdev/io.c
create mode 100644 drivers/nvme/mdev/irq.c
create mode 100644 drivers/nvme/mdev/mdev.h
create mode 100644 drivers/nvme/mdev/mmio.c
create mode 100644 drivers/nvme/mdev/pci.c
create mode 100644 drivers/nvme/mdev/priv.h
create mode 100644 drivers/nvme/mdev/udata.c
create mode 100644 drivers/nvme/mdev/vcq.c
create mode 100644 drivers/nvme/mdev/vctrl.c
create mode 100644 drivers/nvme/mdev/viommu.c
create mode 100644 drivers/nvme/mdev/vns.c
create mode 100644 drivers/nvme/mdev/vsq.c
--
2.17.2
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2019-03-19 14:41 (unknown) Maxim Levitsky
2019-03-19 15:22 ` Keith Busch
@ 2019-03-19 15:22 ` Keith Busch
1 sibling, 0 replies; 669+ messages in thread
From: Keith Busch @ 2019-03-19 15:22 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John Ferlan
On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> -> Share the NVMe device between host and guest.
> Even in fully virtualized configurations,
> some partitions of nvme device could be used by guests as block devices
> while others passed through with nvme-mdev to achieve balance between
> all features of full IO stack emulation and performance.
>
> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> can send interrupts to the guest directly without a context
> switch that can be expensive due to meltdown mitigation.
>
> -> Is able to utilize interrupts to get reasonable performance.
> This is only implemented
> as a proof of concept and not included in the patches,
> but interrupt driven mode shows reasonable performance
>
> -> This is a framework that later can be used to support NVMe devices
> with more of the IO virtualization built-in
> (IOMMU with PASID support coupled with device that supports it)
Would be very interested to see the PASID support. You wouldn't even
need to mediate the IO doorbells or translations if assigning entire
namespaces, and should be much faster than the shadow doorbells.
I think you should send 6/9 "nvme/pci: init shadow doorbell after each
reset" separately for immediate inclusion.
I like the idea in principle, but it will take me a little time to get
through reviewing your implementation. I would have guessed we could
have leveraged something from the existing nvme/target for the mediating
controller register access and admin commands. Maybe even start with
implementing an nvme passthrough namespace target type (we currently
have block and file).
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-19 15:22 ` Keith Busch
0 siblings, 0 replies; 669+ messages in thread
From: Keith Busch @ 2019-03-19 15:22 UTC (permalink / raw)
On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> -> Share the NVMe device between host and guest.
> Even in fully virtualized configurations,
> some partitions of nvme device could be used by guests as block devices
> while others passed through with nvme-mdev to achieve balance between
> all features of full IO stack emulation and performance.
>
> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> can send interrupts to the guest directly without a context
> switch that can be expensive due to meltdown mitigation.
>
> -> Is able to utilize interrupts to get reasonable performance.
> This is only implemented
> as a proof of concept and not included in the patches,
> but interrupt driven mode shows reasonable performance
>
> -> This is a framework that later can be used to support NVMe devices
> with more of the IO virtualization built-in
> (IOMMU with PASID support coupled with device that supports it)
Would be very interested to see the PASID support. You wouldn't even
need to mediate the IO doorbells or translations if assigning entire
namespaces, and should be much faster than the shadow doorbells.
I think you should send 6/9 "nvme/pci: init shadow doorbell after each
reset" separately for immediate inclusion.
I like the idea in principle, but it will take me a little time to get
through reviewing your implementation. I would have guessed we could
have leveraged something from the existing nvme/target for the mediating
controller register access and admin commands. Maybe even start with
implementing an nvme passthrough namespace target type (we currently
have block and file).
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-19 15:22 ` Keith Busch
0 siblings, 0 replies; 669+ messages in thread
From: Keith Busch @ 2019-03-19 15:22 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John Ferlan
On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> -> Share the NVMe device between host and guest.
> Even in fully virtualized configurations,
> some partitions of nvme device could be used by guests as block devices
> while others passed through with nvme-mdev to achieve balance between
> all features of full IO stack emulation and performance.
>
> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> can send interrupts to the guest directly without a context
> switch that can be expensive due to meltdown mitigation.
>
> -> Is able to utilize interrupts to get reasonable performance.
> This is only implemented
> as a proof of concept and not included in the patches,
> but interrupt driven mode shows reasonable performance
>
> -> This is a framework that later can be used to support NVMe devices
> with more of the IO virtualization built-in
> (IOMMU with PASID support coupled with device that supports it)
Would be very interested to see the PASID support. You wouldn't even
need to mediate the IO doorbells or translations if assigning entire
namespaces, and should be much faster than the shadow doorbells.
I think you should send 6/9 "nvme/pci: init shadow doorbell after each
reset" separately for immediate inclusion.
I like the idea in principle, but it will take me a little time to get
through reviewing your implementation. I would have guessed we could
have leveraged something from the existing nvme/target for the mediating
controller register access and admin commands. Maybe even start with
implementing an nvme passthrough namespace target type (we currently
have block and file).
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-19 15:22 ` Keith Busch
(?)
@ 2019-03-19 23:49 ` Chaitanya Kulkarni
-1 siblings, 0 replies; 669+ messages in thread
From: Chaitanya Kulkarni @ 2019-03-19 23:49 UTC (permalink / raw)
To: Keith Busch, Maxim Levitsky
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney ,
Amnon Ilan, Christoph Hellwig, John Ferlan
Hi Keith,
On 03/19/2019 08:21 AM, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
>> -> Share the NVMe device between host and guest.
>> Even in fully virtualized configurations,
>> some partitions of nvme device could be used by guests as block devices
>> while others passed through with nvme-mdev to achieve balance between
>> all features of full IO stack emulation and performance.
>>
>> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
>> can send interrupts to the guest directly without a context
>> switch that can be expensive due to meltdown mitigation.
>>
>> -> Is able to utilize interrupts to get reasonable performance.
>> This is only implemented
>> as a proof of concept and not included in the patches,
>> but interrupt driven mode shows reasonable performance
>>
>> -> This is a framework that later can be used to support NVMe devices
>> with more of the IO virtualization built-in
>> (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I have the code for the NVMeOf target passthru-ctrl, I think we can use
that as it is if you are looking for the passthru for NVMeOF.
I'll post patch-series based on the latest code base soon.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-19 23:49 ` Chaitanya Kulkarni
0 siblings, 0 replies; 669+ messages in thread
From: Chaitanya Kulkarni @ 2019-03-19 23:49 UTC (permalink / raw)
Hi Keith,
On 03/19/2019 08:21 AM, Keith Busch wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
>> -> Share the NVMe device between host and guest.
>> Even in fully virtualized configurations,
>> some partitions of nvme device could be used by guests as block devices
>> while others passed through with nvme-mdev to achieve balance between
>> all features of full IO stack emulation and performance.
>>
>> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
>> can send interrupts to the guest directly without a context
>> switch that can be expensive due to meltdown mitigation.
>>
>> -> Is able to utilize interrupts to get reasonable performance.
>> This is only implemented
>> as a proof of concept and not included in the patches,
>> but interrupt driven mode shows reasonable performance
>>
>> -> This is a framework that later can be used to support NVMe devices
>> with more of the IO virtualization built-in
>> (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I have the code for the NVMeOf target passthru-ctrl, I think we can use
that as it is if you are looking for the passthru for NVMeOF.
I'll post patch-series based on the latest code base soon.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-19 23:49 ` Chaitanya Kulkarni
0 siblings, 0 replies; 669+ messages in thread
From: Chaitanya Kulkarni @ 2019-03-19 23:49 UTC (permalink / raw)
To: Keith Busch, Maxim Levitsky
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney
Hi Keith,
On 03/19/2019 08:21 AM, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
>> -> Share the NVMe device between host and guest.
>> Even in fully virtualized configurations,
>> some partitions of nvme device could be used by guests as block devices
>> while others passed through with nvme-mdev to achieve balance between
>> all features of full IO stack emulation and performance.
>>
>> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
>> can send interrupts to the guest directly without a context
>> switch that can be expensive due to meltdown mitigation.
>>
>> -> Is able to utilize interrupts to get reasonable performance.
>> This is only implemented
>> as a proof of concept and not included in the patches,
>> but interrupt driven mode shows reasonable performance
>>
>> -> This is a framework that later can be used to support NVMe devices
>> with more of the IO virtualization built-in
>> (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I have the code for the NVMeOf target passthru-ctrl, I think we can use
that as it is if you are looking for the passthru for NVMeOF.
I'll post patch-series based on the latest code base soon.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-19 23:49 ` Chaitanya Kulkarni
(?)
@ 2019-03-20 16:44 ` Maxim Levitsky
-1 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:44 UTC (permalink / raw)
To: Chaitanya Kulkarni, Keith Busch
Cc: Fam Zheng, Jens Axboe, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-nvme,
linux-kernel, Keith Busch, Alex Williamson, Christoph Hellwig,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, David S . Miller,
John Ferlan
On Tue, 2019-03-19 at 23:49 +0000, Chaitanya Kulkarni wrote:
> Hi Keith,
> On 03/19/2019 08:21 AM, Keith Busch wrote:
> > On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > > -> Share the NVMe device between host and guest.
> > > Even in fully virtualized configurations,
> > > some partitions of nvme device could be used by guests as block
> > > devices
> > > while others passed through with nvme-mdev to achieve balance
> > > between
> > > all features of full IO stack emulation and performance.
> > >
> > > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > > can send interrupts to the guest directly without a context
> > > switch that can be expensive due to meltdown mitigation.
> > >
> > > -> Is able to utilize interrupts to get reasonable performance.
> > > This is only implemented
> > > as a proof of concept and not included in the patches,
> > > but interrupt driven mode shows reasonable performance
> > >
> > > -> This is a framework that later can be used to support NVMe devices
> > > with more of the IO virtualization built-in
> > > (IOMMU with PASID support coupled with device that supports it)
> >
> > Would be very interested to see the PASID support. You wouldn't even
> > need to mediate the IO doorbells or translations if assigning entire
> > namespaces, and should be much faster than the shadow doorbells.
> >
> > I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> > reset" separately for immediate inclusion.
> >
> > I like the idea in principle, but it will take me a little time to get
> > through reviewing your implementation. I would have guessed we could
> > have leveraged something from the existing nvme/target for the mediating
> > controller register access and admin commands. Maybe even start with
> > implementing an nvme passthrough namespace target type (we currently
> > have block and file).
>
> I have the code for the NVMeOf target passthru-ctrl, I think we can use
> that as it is if you are looking for the passthru for NVMeOF.
>
> I'll post patch-series based on the latest code base soon.
I am very intersing in this code.
Could you explain how your NVMeOF target passthrough works?
Which components of the NVME stack does it involve?
Best regards,
Maxim Levitsky
> >
> > _______________________________________________
> > Linux-nvme mailing list
> > Linux-nvme@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-nvme
> >
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-20 16:44 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:44 UTC (permalink / raw)
On Tue, 2019-03-19@23:49 +0000, Chaitanya Kulkarni wrote:
> Hi Keith,
> On 03/19/2019 08:21 AM, Keith Busch wrote:
> > On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > > -> Share the NVMe device between host and guest.
> > > Even in fully virtualized configurations,
> > > some partitions of nvme device could be used by guests as block
> > > devices
> > > while others passed through with nvme-mdev to achieve balance
> > > between
> > > all features of full IO stack emulation and performance.
> > >
> > > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > > can send interrupts to the guest directly without a context
> > > switch that can be expensive due to meltdown mitigation.
> > >
> > > -> Is able to utilize interrupts to get reasonable performance.
> > > This is only implemented
> > > as a proof of concept and not included in the patches,
> > > but interrupt driven mode shows reasonable performance
> > >
> > > -> This is a framework that later can be used to support NVMe devices
> > > with more of the IO virtualization built-in
> > > (IOMMU with PASID support coupled with device that supports it)
> >
> > Would be very interested to see the PASID support. You wouldn't even
> > need to mediate the IO doorbells or translations if assigning entire
> > namespaces, and should be much faster than the shadow doorbells.
> >
> > I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> > reset" separately for immediate inclusion.
> >
> > I like the idea in principle, but it will take me a little time to get
> > through reviewing your implementation. I would have guessed we could
> > have leveraged something from the existing nvme/target for the mediating
> > controller register access and admin commands. Maybe even start with
> > implementing an nvme passthrough namespace target type (we currently
> > have block and file).
>
> I have the code for the NVMeOf target passthru-ctrl, I think we can use
> that as it is if you are looking for the passthru for NVMeOF.
>
> I'll post patch-series based on the latest code base soon.
I am very intersing in this code.
Could you explain how your NVMeOF target passthrough works?
Which components of the NVME stack does it involve?
Best regards,
Maxim Levitsky
> >
> > _______________________________________________
> > Linux-nvme mailing list
> > Linux-nvme at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-nvme
> >
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-20 16:44 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:44 UTC (permalink / raw)
To: Chaitanya Kulkarni, Keith Busch
Cc: Fam Zheng, Jens Axboe, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-nvme,
linux-kernel, Keith Busch, Alex Williamson, Christoph Hellwig,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney
On Tue, 2019-03-19 at 23:49 +0000, Chaitanya Kulkarni wrote:
> Hi Keith,
> On 03/19/2019 08:21 AM, Keith Busch wrote:
> > On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > > -> Share the NVMe device between host and guest.
> > > Even in fully virtualized configurations,
> > > some partitions of nvme device could be used by guests as block
> > > devices
> > > while others passed through with nvme-mdev to achieve balance
> > > between
> > > all features of full IO stack emulation and performance.
> > >
> > > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > > can send interrupts to the guest directly without a context
> > > switch that can be expensive due to meltdown mitigation.
> > >
> > > -> Is able to utilize interrupts to get reasonable performance.
> > > This is only implemented
> > > as a proof of concept and not included in the patches,
> > > but interrupt driven mode shows reasonable performance
> > >
> > > -> This is a framework that later can be used to support NVMe devices
> > > with more of the IO virtualization built-in
> > > (IOMMU with PASID support coupled with device that supports it)
> >
> > Would be very interested to see the PASID support. You wouldn't even
> > need to mediate the IO doorbells or translations if assigning entire
> > namespaces, and should be much faster than the shadow doorbells.
> >
> > I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> > reset" separately for immediate inclusion.
> >
> > I like the idea in principle, but it will take me a little time to get
> > through reviewing your implementation. I would have guessed we could
> > have leveraged something from the existing nvme/target for the mediating
> > controller register access and admin commands. Maybe even start with
> > implementing an nvme passthrough namespace target type (we currently
> > have block and file).
>
> I have the code for the NVMeOf target passthru-ctrl, I think we can use
> that as it is if you are looking for the passthru for NVMeOF.
>
> I'll post patch-series based on the latest code base soon.
I am very intersing in this code.
Could you explain how your NVMeOF target passthrough works?
Which components of the NVME stack does it involve?
Best regards,
Maxim Levitsky
> >
> > _______________________________________________
> > Linux-nvme mailing list
> > Linux-nvme@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-nvme
> >
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-19 15:22 ` Keith Busch
(?)
@ 2019-03-20 16:30 ` Maxim Levitsky
-1 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:30 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Tue, 2019-03-19 at 09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
I fully agree with that.
Note that to enable PASID support two things have to happen in this vendor.
1. Mature support for IOMMU with PASID support. On Intel side I know that they
only have a spec released and currently the kernel bits to support it are
placed.
I still don't know when a product actually supporting this spec is going to be
released. For other vendors (ARM/AMD/) I haven't done yet a research on state of
PASID based IOMMU support on their platforms.
2. NVMe spec has to be extended to support PASID. At minimum, we need an ability
to assign an PASID to a sq/cq queue pair and ability to relocate the doorbells,
such as each guest would get its own (hardware backed) MMIO page with its own
doorbells. Plus of course the hardware vendors have to embrace the spec. I guess
these two things will happen in collaborative manner.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
I'll do this soon.
Also '5/9 nvme/pci: add known admin effects to augment admin effects log page'
can be considered for immediate inclusion as well, as it works around a flaw
in the NVMe controller badly done admin side effects page with no side effects
(pun intended) for spec compliant controllers (I think so).
This can be fixed with a quirk if you prefer though.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I fully agree with you on that I could have used some of the nvme/target code,
and I am planning to do so eventually.
For that I would need to make my driver, to be one of the target drivers, and I
would need to add another target back end, like you said to allow my target
driver to talk directly to the nvme hardware bypassing the block layer.
Or instead I can use the block backend,
(but note that currently the block back-end doesn't support polling which is
critical for the performance).
Switch to the target code might though have some (probably minor) performance
impact, as it would probably lengthen the critical code path a bit (I might need
for instance to translate the PRP lists I am getting from the virtual controller
to a scattergather list and back).
This is why I did this the way I did, but now knowing that probably I can afford
to loose a bit of performance, I can look at doing that.
Best regards,
Thanks in advance for the review,
Maxim Levitsky
PS:
For reference currently the IO path looks more or less like that:
My IO thread notices a doorbell write, reads a command from a submission queue,
translates it (without even looking at the data pointer) and sends it to the
nvme pci driver together with pointer to data iterator'.
The nvme pci driver calls the data iterator N times, which makes the iterator
translate and fetch the DMA addresses where the data is already mapped on the
its pci nvme device (the mdev driver maps all the guest memory to the nvme pci
device).
The nvme pci driver uses these addresses it receives, to create a prp list,
which it puts into the data pointer.
The nvme pci driver also allocates an free command id, from a list, puts it into
the command ID and sends the command to the real hardware.
Later the IO thread calls to the nvme pci driver to poll the queue. When
completions arrive, the nvme pci driver returns them back to the IO thread.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-20 16:30 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:30 UTC (permalink / raw)
On Tue, 2019-03-19@09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
I fully agree with that.
Note that to enable PASID support two things have to happen in this vendor.
1. Mature support for IOMMU with PASID support. On Intel side I know that they
only have a spec released and currently the kernel bits to support it are
placed.
I still don't know when a product actually supporting this spec is going to be
released. For other vendors (ARM/AMD/) I haven't done yet a research on state of
PASID based IOMMU support on their platforms.
2. NVMe spec has to be extended to support PASID. At minimum, we need an ability
to assign an PASID to a sq/cq queue pair and ability to relocate the doorbells,
such as each guest would get its own (hardware backed) MMIO page with its own
doorbells. Plus of course the hardware vendors have to embrace the spec. I guess
these two things will happen in collaborative manner.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
I'll do this soon.
Also '5/9 nvme/pci: add known admin effects to augment admin effects log page'
can be considered for immediate inclusion as well, as it works around a flaw
in the NVMe controller badly done admin side effects page with no side effects
(pun intended) for spec compliant controllers (I think so).
This can be fixed with a quirk if you prefer though.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I fully agree with you on that I could have used some of the nvme/target code,
and I am planning to do so eventually.
For that I would need to make my driver, to be one of the target drivers, and I
would need to add another target back end, like you said to allow my target
driver to talk directly to the nvme hardware bypassing the block layer.
Or instead I can use the block backend,
(but note that currently the block back-end doesn't support polling which is
critical for the performance).
Switch to the target code might though have some (probably minor) performance
impact, as it would probably lengthen the critical code path a bit (I might need
for instance to translate the PRP lists I am getting from the virtual controller
to a scattergather list and back).
This is why I did this the way I did, but now knowing that probably I can afford
to loose a bit of performance, I can look at doing that.
Best regards,
Thanks in advance for the review,
Maxim Levitsky
PS:
For reference currently the IO path looks more or less like that:
My IO thread notices a doorbell write, reads a command from a submission queue,
translates it (without even looking at the data pointer) and sends it to the
nvme pci driver together with pointer to data iterator'.
The nvme pci driver calls the data iterator N times, which makes the iterator
translate and fetch the DMA addresses where the data is already mapped on the
its pci nvme device (the mdev driver maps all the guest memory to the nvme pci
device).
The nvme pci driver uses these addresses it receives, to create a prp list,
which it puts into the data pointer.
The nvme pci driver also allocates an free command id, from a list, puts it into
the command ID and sends the command to the real hardware.
Later the IO thread calls to the nvme pci driver to poll the queue. When
completions arrive, the nvme pci driver returns them back to the IO thread.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-20 16:30 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:30 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Tue, 2019-03-19 at 09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
I fully agree with that.
Note that to enable PASID support two things have to happen in this vendor.
1. Mature support for IOMMU with PASID support. On Intel side I know that they
only have a spec released and currently the kernel bits to support it are
placed.
I still don't know when a product actually supporting this spec is going to be
released. For other vendors (ARM/AMD/) I haven't done yet a research on state of
PASID based IOMMU support on their platforms.
2. NVMe spec has to be extended to support PASID. At minimum, we need an ability
to assign an PASID to a sq/cq queue pair and ability to relocate the doorbells,
such as each guest would get its own (hardware backed) MMIO page with its own
doorbells. Plus of course the hardware vendors have to embrace the spec. I guess
these two things will happen in collaborative manner.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
I'll do this soon.
Also '5/9 nvme/pci: add known admin effects to augment admin effects log page'
can be considered for immediate inclusion as well, as it works around a flaw
in the NVMe controller badly done admin side effects page with no side effects
(pun intended) for spec compliant controllers (I think so).
This can be fixed with a quirk if you prefer though.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I fully agree with you on that I could have used some of the nvme/target code,
and I am planning to do so eventually.
For that I would need to make my driver, to be one of the target drivers, and I
would need to add another target back end, like you said to allow my target
driver to talk directly to the nvme hardware bypassing the block layer.
Or instead I can use the block backend,
(but note that currently the block back-end doesn't support polling which is
critical for the performance).
Switch to the target code might though have some (probably minor) performance
impact, as it would probably lengthen the critical code path a bit (I might need
for instance to translate the PRP lists I am getting from the virtual controller
to a scattergather list and back).
This is why I did this the way I did, but now knowing that probably I can afford
to loose a bit of performance, I can look at doing that.
Best regards,
Thanks in advance for the review,
Maxim Levitsky
PS:
For reference currently the IO path looks more or less like that:
My IO thread notices a doorbell write, reads a command from a submission queue,
translates it (without even looking at the data pointer) and sends it to the
nvme pci driver together with pointer to data iterator'.
The nvme pci driver calls the data iterator N times, which makes the iterator
translate and fetch the DMA addresses where the data is already mapped on the
its pci nvme device (the mdev driver maps all the guest memory to the nvme pci
device).
The nvme pci driver uses these addresses it receives, to create a prp list,
which it puts into the data pointer.
The nvme pci driver also allocates an free command id, from a list, puts it into
the command ID and sends the command to the real hardware.
Later the IO thread calls to the nvme pci driver to poll the queue. When
completions arrive, the nvme pci driver returns them back to the IO thread.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-20 16:30 ` Maxim Levitsky
(?)
@ 2019-03-20 17:03 ` Keith Busch
-1 siblings, 0 replies; 669+ messages in thread
From: Keith Busch @ 2019-03-20 17:03 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> Or instead I can use the block backend,
> (but note that currently the block back-end doesn't support polling which is
> critical for the performance).
Oh, I think you can do polling through there. For reference, fs/io_uring.c
has a pretty good implementation that aligns with how you could use it.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-20 17:03 ` Keith Busch
0 siblings, 0 replies; 669+ messages in thread
From: Keith Busch @ 2019-03-20 17:03 UTC (permalink / raw)
On Wed, Mar 20, 2019@06:30:29PM +0200, Maxim Levitsky wrote:
> Or instead I can use the block backend,
> (but note that currently the block back-end doesn't support polling which is
> critical for the performance).
Oh, I think you can do polling through there. For reference, fs/io_uring.c
has a pretty good implementation that aligns with how you could use it.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-20 17:03 ` Keith Busch
0 siblings, 0 replies; 669+ messages in thread
From: Keith Busch @ 2019-03-20 17:03 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> Or instead I can use the block backend,
> (but note that currently the block back-end doesn't support polling which is
> critical for the performance).
Oh, I think you can do polling through there. For reference, fs/io_uring.c
has a pretty good implementation that aligns with how you could use it.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-20 17:03 ` Keith Busch
(?)
@ 2019-03-20 17:33 ` Maxim Levitsky
-1 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 17:33 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Wed, 2019-03-20 at 11:03 -0600, Keith Busch wrote:
> On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> > Or instead I can use the block backend,
> > (but note that currently the block back-end doesn't support polling which is
> > critical for the performance).
>
> Oh, I think you can do polling through there. For reference, fs/io_uring.c
> has a pretty good implementation that aligns with how you could use it.
That is exactly my thought. The polling recently got lot of improvements in the
block layer, which migh make this feasable.
I will give it a try.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-20 17:33 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 17:33 UTC (permalink / raw)
On Wed, 2019-03-20@11:03 -0600, Keith Busch wrote:
> On Wed, Mar 20, 2019@06:30:29PM +0200, Maxim Levitsky wrote:
> > Or instead I can use the block backend,
> > (but note that currently the block back-end doesn't support polling which is
> > critical for the performance).
>
> Oh, I think you can do polling through there. For reference, fs/io_uring.c
> has a pretty good implementation that aligns with how you could use it.
That is exactly my thought. The polling recently got lot of improvements in the
block layer, which migh make this feasable.
I will give it a try.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-20 17:33 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-20 17:33 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Wed, 2019-03-20 at 11:03 -0600, Keith Busch wrote:
> On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> > Or instead I can use the block backend,
> > (but note that currently the block back-end doesn't support polling which is
> > critical for the performance).
>
> Oh, I think you can do polling through there. For reference, fs/io_uring.c
> has a pretty good implementation that aligns with how you could use it.
That is exactly my thought. The polling recently got lot of improvements in the
block layer, which migh make this feasable.
I will give it a try.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-19 15:22 ` Keith Busch
@ 2019-04-08 10:04 ` Maxim Levitsky
-1 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-04-08 10:04 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Tue, 2019-03-19 at 09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
Hi!
Sorry to bother you, but any update?
I was somewhat sick for the last week, now finally back in shape to continue
working on this and other tasks I have.
I am studing now the nvme target code and the io_uring to evaluate the
difficultiy of using something similiar to talk to the block device instead of /
in addtion to the direct connection I implemented.
I would be glad to hear more feedback on this project.
I will also soon post the few fixes separately as you suggested.
Best regards,
Maxim Levitskky
^ permalink raw reply [flat|nested] 669+ messages in thread* your mail
@ 2019-04-08 10:04 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-04-08 10:04 UTC (permalink / raw)
On Tue, 2019-03-19@09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
Hi!
Sorry to bother you, but any update?
I was somewhat sick for the last week, now finally back in shape to continue
working on this and other tasks I have.
I am studing now the nvme target code and the io_uring to evaluate the
difficultiy of using something similiar to talk to the block device instead of /
in addtion to the direct connection I implemented.
I would be glad to hear more feedback on this project.
I will also soon post the few fixes separately as you suggested.
Best regards,
Maxim Levitskky
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-19 14:41 (unknown) Maxim Levitsky
2019-03-19 15:22 ` Keith Busch
@ 2019-03-21 16:13 ` Stefan Hajnoczi
1 sibling, 0 replies; 669+ messages in thread
From: Stefan Hajnoczi @ 2019-03-21 16:13 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John Ferlan
[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]
On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> Date: Tue, 19 Mar 2019 14:45:45 +0200
> Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
>
> Hi everyone!
>
> In this patch series, I would like to introduce my take on the problem of doing
> as fast as possible virtualization of storage with emphasis on low latency.
>
> In this patch series I implemented a kernel vfio based, mediated device that
> allows the user to pass through a partition and/or whole namespace to a guest.
>
> The idea behind this driver is based on paper you can find at
> https://www.usenix.org/conference/atc18/presentation/peng,
>
> Although note that I stared the development prior to reading this paper,
> independently.
>
> In addition to that implementation is not based on code used in the paper as
> I wasn't being able at that time to make the source available to me.
>
> ***Key points about the implementation:***
>
> * Polling kernel thread is used. The polling is stopped after a
> predefined timeout (1/2 sec by default).
> Support for all interrupt driven mode is planned, and it shows promising results.
>
> * Guest sees a standard NVME device - this allows to run guest with
> unmodified drivers, for example windows guests.
>
> * The NVMe device is shared between host and guest.
> That means that even a single namespace can be split between host
> and guest based on different partitions.
>
> * Simple configuration
>
> *** Performance ***
>
> Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> and both latency and throughput is very similar to SPDK.
>
> Soon I will test this on a better server and nvme device and provide
> more formal performance numbers.
>
> Latency numbers:
> ~80ms - spdk with fio plugin on the host.
> ~84ms - nvme driver on the host
> ~87ms - mdev-nvme + nvme driver in the guest
You mentioned the spdk numbers are with vhost-user-nvme. Have you
measured SPDK's vhost-user-blk?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-21 16:13 ` Stefan Hajnoczi
0 siblings, 0 replies; 669+ messages in thread
From: Stefan Hajnoczi @ 2019-03-21 16:13 UTC (permalink / raw)
On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> Date: Tue, 19 Mar 2019 14:45:45 +0200
> Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
>
> Hi everyone!
>
> In this patch series, I would like to introduce my take on the problem of doing
> as fast as possible virtualization of storage with emphasis on low latency.
>
> In this patch series I implemented a kernel vfio based, mediated device that
> allows the user to pass through a partition and/or whole namespace to a guest.
>
> The idea behind this driver is based on paper you can find at
> https://www.usenix.org/conference/atc18/presentation/peng,
>
> Although note that I stared the development prior to reading this paper,
> independently.
>
> In addition to that implementation is not based on code used in the paper as
> I wasn't being able at that time to make the source available to me.
>
> ***Key points about the implementation:***
>
> * Polling kernel thread is used. The polling is stopped after a
> predefined timeout (1/2 sec by default).
> Support for all interrupt driven mode is planned, and it shows promising results.
>
> * Guest sees a standard NVME device - this allows to run guest with
> unmodified drivers, for example windows guests.
>
> * The NVMe device is shared between host and guest.
> That means that even a single namespace can be split between host
> and guest based on different partitions.
>
> * Simple configuration
>
> *** Performance ***
>
> Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> and both latency and throughput is very similar to SPDK.
>
> Soon I will test this on a better server and nvme device and provide
> more formal performance numbers.
>
> Latency numbers:
> ~80ms - spdk with fio plugin on the host.
> ~84ms - nvme driver on the host
> ~87ms - mdev-nvme + nvme driver in the guest
You mentioned the spdk numbers are with vhost-user-nvme. Have you
measured SPDK's vhost-user-blk?
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190321/43a43762/attachment.sig>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-21 16:13 ` Stefan Hajnoczi
0 siblings, 0 replies; 669+ messages in thread
From: Stefan Hajnoczi @ 2019-03-21 16:13 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John Ferlan
[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]
On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> Date: Tue, 19 Mar 2019 14:45:45 +0200
> Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
>
> Hi everyone!
>
> In this patch series, I would like to introduce my take on the problem of doing
> as fast as possible virtualization of storage with emphasis on low latency.
>
> In this patch series I implemented a kernel vfio based, mediated device that
> allows the user to pass through a partition and/or whole namespace to a guest.
>
> The idea behind this driver is based on paper you can find at
> https://www.usenix.org/conference/atc18/presentation/peng,
>
> Although note that I stared the development prior to reading this paper,
> independently.
>
> In addition to that implementation is not based on code used in the paper as
> I wasn't being able at that time to make the source available to me.
>
> ***Key points about the implementation:***
>
> * Polling kernel thread is used. The polling is stopped after a
> predefined timeout (1/2 sec by default).
> Support for all interrupt driven mode is planned, and it shows promising results.
>
> * Guest sees a standard NVME device - this allows to run guest with
> unmodified drivers, for example windows guests.
>
> * The NVMe device is shared between host and guest.
> That means that even a single namespace can be split between host
> and guest based on different partitions.
>
> * Simple configuration
>
> *** Performance ***
>
> Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> and both latency and throughput is very similar to SPDK.
>
> Soon I will test this on a better server and nvme device and provide
> more formal performance numbers.
>
> Latency numbers:
> ~80ms - spdk with fio plugin on the host.
> ~84ms - nvme driver on the host
> ~87ms - mdev-nvme + nvme driver in the guest
You mentioned the spdk numbers are with vhost-user-nvme. Have you
measured SPDK's vhost-user-blk?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-21 16:13 ` Stefan Hajnoczi
(?)
@ 2019-03-21 17:07 ` Maxim Levitsky
-1 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-21 17:07 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney, Paolo Bonzini,
Liang Cunming, Liu Changpeng, Fam Zheng, Amnon Ilan, John Ferlan
On Thu, 2019-03-21 at 16:13 +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> >
> > Hi everyone!
> >
> > In this patch series, I would like to introduce my take on the problem of
> > doing
> > as fast as possible virtualization of storage with emphasis on low latency.
> >
> > In this patch series I implemented a kernel vfio based, mediated device
> > that
> > allows the user to pass through a partition and/or whole namespace to a
> > guest.
> >
> > The idea behind this driver is based on paper you can find at
> > https://www.usenix.org/conference/atc18/presentation/peng,
> >
> > Although note that I stared the development prior to reading this paper,
> > independently.
> >
> > In addition to that implementation is not based on code used in the paper
> > as
> > I wasn't being able at that time to make the source available to me.
> >
> > ***Key points about the implementation:***
> >
> > * Polling kernel thread is used. The polling is stopped after a
> > predefined timeout (1/2 sec by default).
> > Support for all interrupt driven mode is planned, and it shows promising
> > results.
> >
> > * Guest sees a standard NVME device - this allows to run guest with
> > unmodified drivers, for example windows guests.
> >
> > * The NVMe device is shared between host and guest.
> > That means that even a single namespace can be split between host
> > and guest based on different partitions.
> >
> > * Simple configuration
> >
> > *** Performance ***
> >
> > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > and both latency and throughput is very similar to SPDK.
> >
> > Soon I will test this on a better server and nvme device and provide
> > more formal performance numbers.
> >
> > Latency numbers:
> > ~80ms - spdk with fio plugin on the host.
> > ~84ms - nvme driver on the host
> > ~87ms - mdev-nvme + nvme driver in the guest
>
> You mentioned the spdk numbers are with vhost-user-nvme. Have you
> measured SPDK's vhost-user-blk?
I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
vhost-user-nvme was always a bit faster but only a bit.
Thus I don't think it makes sense to benchamrk against vhost-user-blk.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-21 17:07 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-21 17:07 UTC (permalink / raw)
On Thu, 2019-03-21@16:13 +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> >
> > Hi everyone!
> >
> > In this patch series, I would like to introduce my take on the problem of
> > doing
> > as fast as possible virtualization of storage with emphasis on low latency.
> >
> > In this patch series I implemented a kernel vfio based, mediated device
> > that
> > allows the user to pass through a partition and/or whole namespace to a
> > guest.
> >
> > The idea behind this driver is based on paper you can find at
> > https://www.usenix.org/conference/atc18/presentation/peng,
> >
> > Although note that I stared the development prior to reading this paper,
> > independently.
> >
> > In addition to that implementation is not based on code used in the paper
> > as
> > I wasn't being able at that time to make the source available to me.
> >
> > ***Key points about the implementation:***
> >
> > * Polling kernel thread is used. The polling is stopped after a
> > predefined timeout (1/2 sec by default).
> > Support for all interrupt driven mode is planned, and it shows promising
> > results.
> >
> > * Guest sees a standard NVME device - this allows to run guest with
> > unmodified drivers, for example windows guests.
> >
> > * The NVMe device is shared between host and guest.
> > That means that even a single namespace can be split between host
> > and guest based on different partitions.
> >
> > * Simple configuration
> >
> > *** Performance ***
> >
> > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > and both latency and throughput is very similar to SPDK.
> >
> > Soon I will test this on a better server and nvme device and provide
> > more formal performance numbers.
> >
> > Latency numbers:
> > ~80ms - spdk with fio plugin on the host.
> > ~84ms - nvme driver on the host
> > ~87ms - mdev-nvme + nvme driver in the guest
>
> You mentioned the spdk numbers are with vhost-user-nvme. Have you
> measured SPDK's vhost-user-blk?
I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
vhost-user-nvme was always a bit faster but only a bit.
Thus I don't think it makes sense to benchamrk against vhost-user-blk.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-21 17:07 ` Maxim Levitsky
0 siblings, 0 replies; 669+ messages in thread
From: Maxim Levitsky @ 2019-03-21 17:07 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney, Paolo Bonzini,
Liang Cunming, Liu Changpeng, Fam Zheng, Amnon Ilan, John Ferlan
On Thu, 2019-03-21 at 16:13 +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> >
> > Hi everyone!
> >
> > In this patch series, I would like to introduce my take on the problem of
> > doing
> > as fast as possible virtualization of storage with emphasis on low latency.
> >
> > In this patch series I implemented a kernel vfio based, mediated device
> > that
> > allows the user to pass through a partition and/or whole namespace to a
> > guest.
> >
> > The idea behind this driver is based on paper you can find at
> > https://www.usenix.org/conference/atc18/presentation/peng,
> >
> > Although note that I stared the development prior to reading this paper,
> > independently.
> >
> > In addition to that implementation is not based on code used in the paper
> > as
> > I wasn't being able at that time to make the source available to me.
> >
> > ***Key points about the implementation:***
> >
> > * Polling kernel thread is used. The polling is stopped after a
> > predefined timeout (1/2 sec by default).
> > Support for all interrupt driven mode is planned, and it shows promising
> > results.
> >
> > * Guest sees a standard NVME device - this allows to run guest with
> > unmodified drivers, for example windows guests.
> >
> > * The NVMe device is shared between host and guest.
> > That means that even a single namespace can be split between host
> > and guest based on different partitions.
> >
> > * Simple configuration
> >
> > *** Performance ***
> >
> > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > and both latency and throughput is very similar to SPDK.
> >
> > Soon I will test this on a better server and nvme device and provide
> > more formal performance numbers.
> >
> > Latency numbers:
> > ~80ms - spdk with fio plugin on the host.
> > ~84ms - nvme driver on the host
> > ~87ms - mdev-nvme + nvme driver in the guest
>
> You mentioned the spdk numbers are with vhost-user-nvme. Have you
> measured SPDK's vhost-user-blk?
I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
vhost-user-nvme was always a bit faster but only a bit.
Thus I don't think it makes sense to benchamrk against vhost-user-blk.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-03-21 17:07 ` Maxim Levitsky
(?)
@ 2019-03-25 16:46 ` Stefan Hajnoczi
-1 siblings, 0 replies; 669+ messages in thread
From: Stefan Hajnoczi @ 2019-03-25 16:46 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney, Paolo Bonzini,
Liang Cunming, Liu Changpeng, Fam Zheng, Amnon Ilan, John Ferlan
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Thu, Mar 21, 2019 at 07:07:38PM +0200, Maxim Levitsky wrote:
> On Thu, 2019-03-21 at 16:13 +0000, Stefan Hajnoczi wrote:
> > On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > >
> > > Hi everyone!
> > >
> > > In this patch series, I would like to introduce my take on the problem of
> > > doing
> > > as fast as possible virtualization of storage with emphasis on low latency.
> > >
> > > In this patch series I implemented a kernel vfio based, mediated device
> > > that
> > > allows the user to pass through a partition and/or whole namespace to a
> > > guest.
> > >
> > > The idea behind this driver is based on paper you can find at
> > > https://www.usenix.org/conference/atc18/presentation/peng,
> > >
> > > Although note that I stared the development prior to reading this paper,
> > > independently.
> > >
> > > In addition to that implementation is not based on code used in the paper
> > > as
> > > I wasn't being able at that time to make the source available to me.
> > >
> > > ***Key points about the implementation:***
> > >
> > > * Polling kernel thread is used. The polling is stopped after a
> > > predefined timeout (1/2 sec by default).
> > > Support for all interrupt driven mode is planned, and it shows promising
> > > results.
> > >
> > > * Guest sees a standard NVME device - this allows to run guest with
> > > unmodified drivers, for example windows guests.
> > >
> > > * The NVMe device is shared between host and guest.
> > > That means that even a single namespace can be split between host
> > > and guest based on different partitions.
> > >
> > > * Simple configuration
> > >
> > > *** Performance ***
> > >
> > > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > > and both latency and throughput is very similar to SPDK.
> > >
> > > Soon I will test this on a better server and nvme device and provide
> > > more formal performance numbers.
> > >
> > > Latency numbers:
> > > ~80ms - spdk with fio plugin on the host.
> > > ~84ms - nvme driver on the host
> > > ~87ms - mdev-nvme + nvme driver in the guest
> >
> > You mentioned the spdk numbers are with vhost-user-nvme. Have you
> > measured SPDK's vhost-user-blk?
>
> I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
> vhost-user-nvme was always a bit faster but only a bit.
> Thus I don't think it makes sense to benchamrk against vhost-user-blk.
It's interesting because mdev-nvme is closest to the hardware while
vhost-user-blk is closest to software. Doing things at the NVMe level
isn't buying much performance because it's still going through a
software path comparable to vhost-user-blk.
From what you say it sounds like there isn't much to optimize away :(.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2019-03-25 16:46 ` Stefan Hajnoczi
0 siblings, 0 replies; 669+ messages in thread
From: Stefan Hajnoczi @ 2019-03-25 16:46 UTC (permalink / raw)
On Thu, Mar 21, 2019@07:07:38PM +0200, Maxim Levitsky wrote:
> On Thu, 2019-03-21@16:13 +0000, Stefan Hajnoczi wrote:
> > On Tue, Mar 19, 2019@04:41:07PM +0200, Maxim Levitsky wrote:
> > > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > >
> > > Hi everyone!
> > >
> > > In this patch series, I would like to introduce my take on the problem of
> > > doing
> > > as fast as possible virtualization of storage with emphasis on low latency.
> > >
> > > In this patch series I implemented a kernel vfio based, mediated device
> > > that
> > > allows the user to pass through a partition and/or whole namespace to a
> > > guest.
> > >
> > > The idea behind this driver is based on paper you can find at
> > > https://www.usenix.org/conference/atc18/presentation/peng,
> > >
> > > Although note that I stared the development prior to reading this paper,
> > > independently.
> > >
> > > In addition to that implementation is not based on code used in the paper
> > > as
> > > I wasn't being able at that time to make the source available to me.
> > >
> > > ***Key points about the implementation:***
> > >
> > > * Polling kernel thread is used. The polling is stopped after a
> > > predefined timeout (1/2 sec by default).
> > > Support for all interrupt driven mode is planned, and it shows promising
> > > results.
> > >
> > > * Guest sees a standard NVME device - this allows to run guest with
> > > unmodified drivers, for example windows guests.
> > >
> > > * The NVMe device is shared between host and guest.
> > > That means that even a single namespace can be split between host
> > > and guest based on different partitions.
> > >
> > > * Simple configuration
> > >
> > > *** Performance ***
> > >
> > > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > > and both latency and throughput is very similar to SPDK.
> > >
> > > Soon I will test this on a better server and nvme device and provide
> > > more formal performance numbers.
> > >
> > > Latency numbers:
> > > ~80ms - spdk with fio plugin on the host.
> > > ~84ms - nvme driver on the host
> > > ~87ms - mdev-nvme + nvme driver in the guest
> >
> > You mentioned the spdk numbers are with vhost-user-nvme. Have you
> > measured SPDK's vhost-user-blk?
>
> I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
> vhost-user-nvme was always a bit faster but only a bit.
> Thus I don't think it makes sense to benchamrk against vhost-user-blk.
It's interesting because mdev-nvme is closest to the hardware while
vhost-user-blk is closest to software. Doing things at the NVMe level
isn't buying much performance because it's still going through a
software path comparable to vhost-user-blk.
From what you say it sounds like there isn't much to optimize away :(.
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190325/f46e8674/attachment.sig>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2019-03-25 16:46 ` Stefan Hajnoczi
0 siblings, 0 replies; 669+ messages in thread
From: Stefan Hajnoczi @ 2019-03-25 16:46 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney, Paolo Bonzini,
Liang Cunming, Liu Changpeng, Fam Zheng, Amnon Ilan, John Ferlan
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Thu, Mar 21, 2019 at 07:07:38PM +0200, Maxim Levitsky wrote:
> On Thu, 2019-03-21 at 16:13 +0000, Stefan Hajnoczi wrote:
> > On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > >
> > > Hi everyone!
> > >
> > > In this patch series, I would like to introduce my take on the problem of
> > > doing
> > > as fast as possible virtualization of storage with emphasis on low latency.
> > >
> > > In this patch series I implemented a kernel vfio based, mediated device
> > > that
> > > allows the user to pass through a partition and/or whole namespace to a
> > > guest.
> > >
> > > The idea behind this driver is based on paper you can find at
> > > https://www.usenix.org/conference/atc18/presentation/peng,
> > >
> > > Although note that I stared the development prior to reading this paper,
> > > independently.
> > >
> > > In addition to that implementation is not based on code used in the paper
> > > as
> > > I wasn't being able at that time to make the source available to me.
> > >
> > > ***Key points about the implementation:***
> > >
> > > * Polling kernel thread is used. The polling is stopped after a
> > > predefined timeout (1/2 sec by default).
> > > Support for all interrupt driven mode is planned, and it shows promising
> > > results.
> > >
> > > * Guest sees a standard NVME device - this allows to run guest with
> > > unmodified drivers, for example windows guests.
> > >
> > > * The NVMe device is shared between host and guest.
> > > That means that even a single namespace can be split between host
> > > and guest based on different partitions.
> > >
> > > * Simple configuration
> > >
> > > *** Performance ***
> > >
> > > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > > and both latency and throughput is very similar to SPDK.
> > >
> > > Soon I will test this on a better server and nvme device and provide
> > > more formal performance numbers.
> > >
> > > Latency numbers:
> > > ~80ms - spdk with fio plugin on the host.
> > > ~84ms - nvme driver on the host
> > > ~87ms - mdev-nvme + nvme driver in the guest
> >
> > You mentioned the spdk numbers are with vhost-user-nvme. Have you
> > measured SPDK's vhost-user-blk?
>
> I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
> vhost-user-nvme was always a bit faster but only a bit.
> Thus I don't think it makes sense to benchamrk against vhost-user-blk.
It's interesting because mdev-nvme is closest to the hardware while
vhost-user-blk is closest to software. Doing things at the NVMe level
isn't buying much performance because it's still going through a
software path comparable to vhost-user-blk.
From what you say it sounds like there isn't much to optimize away :(.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20190225201635.4648-1-hannes@cmpxchg.org>]
* Re: your mail
[not found] <20190225201635.4648-1-hannes@cmpxchg.org>
@ 2019-02-26 23:49 ` Roman Gushchin
0 siblings, 0 replies; 669+ messages in thread
From: Roman Gushchin @ 2019-02-26 23:49 UTC (permalink / raw)
To: up, the, LRU, counts, tracking
Cc: Andrew Morton, Tejun Heo, linux-mm, cgroups, linux-kernel, Kernel Team
On Mon, Feb 25, 2019 at 03:16:29PM -0500, Johannes Weiner wrote:
> [resending, rebased on top of latest mmots]
>
> The memcg LRU stats usage is currently a bit messy. Memcg has private
> per-zone counters because reclaim needs zone granularity sometimes,
> but we also have plenty of users that need to awkwardly sum them up to
> node or memcg granularity. Meanwhile the canonical per-memcg vmstats
> do not track the LRU counts (NR_INACTIVE_ANON etc.) as you'd expect.
>
> This series enables LRU count tracking in the per-memcg vmstats array
> such that lruvec_page_state() and memcg_page_state() work on the enum
> node_stat_item items for the LRU counters. Then it converts all the
> callers that don't specifically need per-zone numbers over to that.
The updated version looks very good* to me!
Please, feel free to use:
Reviewed-by: Roman Gushchin <guro@fb.com>
Looking through the patchset, I have a feeling that we're sometimes
gathering too much data. Perhaps we don't need the whole set
of counters to be per-cpu on both memcg- and memcg-per-node levels.
Merging them can save quite a lot of space. Anyway, it's a separate
topic.
* except "to" and "subject" of the cover letter
Thanks!
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20190204213303.131064-1-matthewgarrett@google.com>]
* (no subject)
@ 2019-01-25 9:47 Furkan DURUL
2019-01-25 11:27 ` your mail Kevin Daudt
0 siblings, 1 reply; 669+ messages in thread
From: Furkan DURUL @ 2019-01-25 9:47 UTC (permalink / raw)
To: git
Hello,
My name is Furkan. I'm a new graduated Electronics and Communication
Engineer in Turkey. In my current workplace, we use Git in all our
projects and I really learned a lot from your Pro Git Book. I would
like to contribute to translation of this book to Turkish. I'm also a
freelance translator and have experience about translation.
Look forward to hear you
Cheers
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2019-01-25 9:47 Furkan DURUL
@ 2019-01-25 11:27 ` Kevin Daudt
0 siblings, 0 replies; 669+ messages in thread
From: Kevin Daudt @ 2019-01-25 11:27 UTC (permalink / raw)
To: Furkan DURUL; +Cc: git
On Fri, Jan 25, 2019 at 12:47:35PM +0300, Furkan DURUL wrote:
> Hello,
> My name is Furkan. I'm a new graduated Electronics and Communication
> Engineer in Turkey. In my current workplace, we use Git in all our
> projects and I really learned a lot from your Pro Git Book. I would
> like to contribute to translation of this book to Turkish. I'm also a
> freelance translator and have experience about translation.
> Look forward to hear you
> Cheers
Hello Furkan,
Welcome to the community. Pro Git is not maintained by the git
community, but is a separate project.
You can find details on how to provide translations here[0]. It looks
from that document that someone started translating the book in Turkish
as well[1].
Kind regards, Kevin
[0]:https://github.com/progit/progit2/blob/master/TRANSLATING.md
[1]:https://github.com/progit/progit2-tr
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2018-12-13 14:09 Sebastian Andrzej Siewior
2018-12-13 14:33 ` your mail Sasha Levin
2018-12-14 7:11 ` Greg KH
0 siblings, 2 replies; 669+ messages in thread
From: Sebastian Andrzej Siewior @ 2018-12-13 14:09 UTC (permalink / raw)
To: stable; +Cc: Peter Zijlstra, Will Deacon, Thomas Gleixner, Daniel Wagner
Hi,
this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
Provide liveness guarantee") for the v4.9 stable tree.
For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
x86.
For v4.9 it has been decided to do a minimal backport of the final fix
(including all its dependencies).
With this backport I can't reproduce the issue in the latest v4.9-RT
tree. I was able to boot (and use) an arm64 box with these patches so it
is not broken in an abvious way.
Sebastian
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2018-12-13 14:09 Sebastian Andrzej Siewior
@ 2018-12-13 14:33 ` Sasha Levin
2018-12-13 14:39 ` Sasha Levin
2018-12-13 14:53 ` Peter Zijlstra
2018-12-14 7:11 ` Greg KH
1 sibling, 2 replies; 669+ messages in thread
From: Sasha Levin @ 2018-12-13 14:33 UTC (permalink / raw)
To: Backport, for, cachelinestarvationonx86
Cc: stable, Peter Zijlstra, Will Deacon, Thomas Gleixner, Daniel Wagner
On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
>Hi,
>
>this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
>Provide liveness guarantee") for the v4.9 stable tree.
>For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
>x86.
>For v4.9 it has been decided to do a minimal backport of the final fix
>(including all its dependencies).
>With this backport I can't reproduce the issue in the latest v4.9-RT
>tree. I was able to boot (and use) an arm64 box with these patches so it
>is not broken in an abvious way.
What about 4.14? I see that at least some of these patches are missing
there.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2018-12-13 14:33 ` your mail Sasha Levin
@ 2018-12-13 14:39 ` Sasha Levin
2018-12-13 15:13 ` Sebastian Andrzej Siewior
2018-12-13 14:53 ` Peter Zijlstra
1 sibling, 1 reply; 669+ messages in thread
From: Sasha Levin @ 2018-12-13 14:39 UTC (permalink / raw)
To: bigeasy
Cc: stable, Peter Zijlstra, Will Deacon, Thomas Gleixner, Daniel Wagner
On Thu, Dec 13, 2018 at 09:33:36AM -0500, Sasha Levin wrote:
>On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
>>Hi,
>>
>>this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
>>Provide liveness guarantee") for the v4.9 stable tree.
>>For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
>>x86.
>>For v4.9 it has been decided to do a minimal backport of the final fix
>>(including all its dependencies).
>>With this backport I can't reproduce the issue in the latest v4.9-RT
>>tree. I was able to boot (and use) an arm64 box with these patches so it
>>is not broken in an abvious way.
>
>What about 4.14? I see that at least some of these patches are missing
>there.
Hrm, there was something really fishy with the headers on your original
mail...
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2018-12-13 14:39 ` Sasha Levin
@ 2018-12-13 15:13 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 669+ messages in thread
From: Sebastian Andrzej Siewior @ 2018-12-13 15:13 UTC (permalink / raw)
To: Sasha Levin
Cc: stable, Peter Zijlstra, Will Deacon, Thomas Gleixner, Daniel Wagner
On 2018-12-13 09:39:46 [-0500], Sasha Levin wrote:
> On Thu, Dec 13, 2018 at 09:33:36AM -0500, Sasha Levin wrote:
> > On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
> > > Hi,
> > >
> > > this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
> > > Provide liveness guarantee") for the v4.9 stable tree.
> > > For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
> > > x86.
> > > For v4.9 it has been decided to do a minimal backport of the final fix
> > > (including all its dependencies).
> > > With this backport I can't reproduce the issue in the latest v4.9-RT
> > > tree. I was able to boot (and use) an arm64 box with these patches so it
> > > is not broken in an abvious way.
> >
> > What about 4.14? I see that at least some of these patches are missing
> > there.
so v4.4 was easy peasy, v4.9 required a little work. So let me worry
about v4.14 and v4.19 next.
> Hrm, there was something really fishy with the headers on your original
> mail...
Interesting and I'm sorry. So infradead.org rejected all of my emails
saying something similar but I have no clue what went wrong.
Sebastian
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2018-12-13 14:33 ` your mail Sasha Levin
2018-12-13 14:39 ` Sasha Levin
@ 2018-12-13 14:53 ` Peter Zijlstra
1 sibling, 0 replies; 669+ messages in thread
From: Peter Zijlstra @ 2018-12-13 14:53 UTC (permalink / raw)
To: Sasha Levin
Cc: Backport, for, cachelinestarvationonx86, stable, Will Deacon,
Thomas Gleixner, Daniel Wagner
On Thu, Dec 13, 2018 at 09:33:36AM -0500, Sasha Levin wrote:
> On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
> > Hi,
> >
> > this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
> > Provide liveness guarantee") for the v4.9 stable tree.
> > For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
> > x86.
> > For v4.9 it has been decided to do a minimal backport of the final fix
> > (including all its dependencies).
> > With this backport I can't reproduce the issue in the latest v4.9-RT
> > tree. I was able to boot (and use) an arm64 box with these patches so it
> > is not broken in an abvious way.
>
> What about 4.14? I see that at least some of these patches are missing
> there.
4.14 can have a simpler backport indeed
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2018-12-13 14:09 Sebastian Andrzej Siewior
2018-12-13 14:33 ` your mail Sasha Levin
@ 2018-12-14 7:11 ` Greg KH
1 sibling, 0 replies; 669+ messages in thread
From: Greg KH @ 2018-12-14 7:11 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: stable, Peter Zijlstra, Will Deacon, Thomas Gleixner, Daniel Wagner
On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
> Hi,
>
> this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
> Provide liveness guarantee") for the v4.9 stable tree.
> For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
> x86.
> For v4.9 it has been decided to do a minimal backport of the final fix
> (including all its dependencies).
> With this backport I can't reproduce the issue in the latest v4.9-RT
> tree. I was able to boot (and use) an arm64 box with these patches so it
> is not broken in an abvious way.
As Peter said, a 4.14 backport would be simpler, but I would prefer to
wait for that before accepting these patches into 4.9.
I don't want people to move from 4.9 to 4.14 and hit a regression right
away. So if we could get a 4.14 backport first, that would be wonderful
and then allow me to take the 4.9 patches.
Seeing patches in 4.9 and 4.19 but not in 4.14 does not make me feel
good :)
And given the horrible header mistakes on this series, I'm going to drop
them to prevent anyone else from having to hand-edit them in order to
get things cleaned up. Please resend this series after you have done
that.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2018-08-27 14:50 Christoph Hellwig
2018-08-31 20:23 ` Paul Burton
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2018-08-27 14:50 UTC (permalink / raw)
To: iommu
Cc: Marek Szyprowski, Robin Murphy, Paul Burton, Greg Kroah-Hartman,
linux-mips, linux-kernel
Subject: [RFC] merge dma_direct_ops and dma_noncoherent_ops
While most architectures are either always or never dma coherent for a
given build, the arm, arm64, mips and soon arc architectures can have
different dma coherent settings on a per-device basis. Additionally
some mips builds can decide at boot time if dma is coherent or not.
I've started to look into handling noncoherent dma in swiotlb, and
moving the dma-iommu ops into common code [1], and for that we need a
generic way to check if a given device is coherent or not. Moving
this flag into struct device also simplifies the conditionally coherent
architecture implementations.
These patches are also available in a git tree given that they have
a few previous posted dependencies:
git://git.infradead.org/users/hch/misc.git dma-direct-noncoherent-merge
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-direct-noncoherent-merge
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2018-08-31 20:23 ` Paul Burton
0 siblings, 0 replies; 669+ messages in thread
From: Paul Burton @ 2018-08-31 20:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman,
linux-mips, linux-kernel
Hi Christoph,
On Mon, Aug 27, 2018 at 04:50:27PM +0200, Christoph Hellwig wrote:
> Subject: [RFC] merge dma_direct_ops and dma_noncoherent_ops
>
> While most architectures are either always or never dma coherent for a
> given build, the arm, arm64, mips and soon arc architectures can have
> different dma coherent settings on a per-device basis. Additionally
> some mips builds can decide at boot time if dma is coherent or not.
>
> I've started to look into handling noncoherent dma in swiotlb, and
> moving the dma-iommu ops into common code [1], and for that we need a
> generic way to check if a given device is coherent or not. Moving
> this flag into struct device also simplifies the conditionally coherent
> architecture implementations.
>
> These patches are also available in a git tree given that they have
> a few previous posted dependencies:
>
> git://git.infradead.org/users/hch/misc.git dma-direct-noncoherent-merge
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-direct-noncoherent-merge
Apart from the nits in patch 2, these look sane to me from a MIPS
perspective, so for patches 1-4:
Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
Thanks,
Paul
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2018-08-31 20:23 ` Paul Burton
0 siblings, 0 replies; 669+ messages in thread
From: Paul Burton @ 2018-08-31 20:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Robin Murphy
Hi Christoph,
On Mon, Aug 27, 2018 at 04:50:27PM +0200, Christoph Hellwig wrote:
> Subject: [RFC] merge dma_direct_ops and dma_noncoherent_ops
>
> While most architectures are either always or never dma coherent for a
> given build, the arm, arm64, mips and soon arc architectures can have
> different dma coherent settings on a per-device basis. Additionally
> some mips builds can decide at boot time if dma is coherent or not.
>
> I've started to look into handling noncoherent dma in swiotlb, and
> moving the dma-iommu ops into common code [1], and for that we need a
> generic way to check if a given device is coherent or not. Moving
> this flag into struct device also simplifies the conditionally coherent
> architecture implementations.
>
> These patches are also available in a git tree given that they have
> a few previous posted dependencies:
>
> git://git.infradead.org/users/hch/misc.git dma-direct-noncoherent-merge
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-direct-noncoherent-merge
Apart from the nits in patch 2, these look sane to me from a MIPS
perspective, so for patches 1-4:
Acked-by: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org> # MIPS parts
Thanks,
Paul
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20180724222212.8742-1-tsotsos@gmail.com>]
* Re: your mail
[not found] <20180724222212.8742-1-tsotsos@gmail.com>
@ 2018-07-25 7:39 ` Greg Kroah-Hartman
0 siblings, 0 replies; 669+ messages in thread
From: Greg Kroah-Hartman @ 2018-07-25 7:39 UTC (permalink / raw)
To: Georgios Tsotsos; +Cc: devel, James Hogan, linux-kernel, Aaro Koskinen
On Wed, Jul 25, 2018 at 01:22:07AM +0300, Georgios Tsotsos wrote:
> Date: Wed, 25 Jul 2018 01:18:58 +0300
> Subject: [PATCH 0/4] Staging: octeon-usb: Fixes and Coding style applied.
>
> Hello,
Somehow your subject here got messed up and put in the bod of the email.
Not a big deal this time, but be more careful next time please.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <2018071901551081442221@163.com>]
* Re: your mail
[not found] <2018071901551081442221@163.com>
@ 2018-07-18 20:04 ` Johan Hovold
0 siblings, 0 replies; 669+ messages in thread
From: Johan Hovold @ 2018-07-18 20:04 UTC (permalink / raw)
To: m13297920107; +Cc: johan, gregkh, linux-usb, linux-kernel, moviesong, billli
On Thu, Jul 19, 2018 at 01:55:12AM +0800, m13297920107@163.com wrote:
> From 14bd57ea5c5fc385bd36b5a3ea5c805337bbc8db Mon Sep 17 00:00:00 2001
> From: Movie Song <MovieSong@aten-itlab.cn>
> Date: Thu, 19 Jul 2018 02:20:48 +0800
> Subject: [PATCH] USB:serial:pl2303:add a new device id for ATEN
Add spaces after the colons (':') in the Subject above, and place a
short commit message here before your SoB.
> Signed-off-by:MovieSong<MovieSong@aten-itlab.cn>
Missing spaces in you SoB as well.
> ---
> drivers/usb/serial/pl2303.c | 2 ++
> drivers/usb/serial/pl2303.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 5d1a193..e41f725 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -52,6 +52,8 @@
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> + { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC232B),
> + .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
> { USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
> { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
> diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
> index fcd7239..26965cc 100644
> --- a/drivers/usb/serial/pl2303.h
> +++ b/drivers/usb/serial/pl2303.h
> @@ -24,6 +24,7 @@
> #define ATEN_VENDOR_ID2 0x0547
> #define ATEN_PRODUCT_ID 0x2008
> #define ATEN_PRODUCT_UC485 0x2021
> +#define ATEN_PRODUCT_UC232B 0x2022
> #define ATEN_PRODUCT_ID2 0x2118
>
> #define IODATA_VENDOR_ID 0x04bb
As I suggested earlier, try sending the patch to yourself first and run
scripts/checkpatch.pl on it. The patch is still whitespace corrupted
(probably by your mail client) as checkpatch would have let you know:
WARNING: Use a single space after Signed-off-by:
#13:
Signed-off-by:MovieSong<MovieSong@aten-itlab.cn>
WARNING: email address 'MovieSong<MovieSong@aten-itlab.cn>' might be better as 'MovieSong <MovieSong@aten-itlab.cn>'
#13:
Signed-off-by:MovieSong<MovieSong@aten-itlab.cn>
WARNING: please, no spaces at the start of a line
#27: FILE: drivers/usb/serial/pl2303.c:55:
+ { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC232B),$
WARNING: please, no spaces at the start of a line
#28: FILE: drivers/usb/serial/pl2303.c:56:
+ .driver_info = PL2303_QUIRK_ENDPOINT_HACK },$
total: 1 errors, 4 warnings, 15 lines checked
git-send-email is convenient for sending patches (e.g. generated with
git-format-patch). Perhaps you can set that up.
One more try?
Thanks,
Johan
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <201807160555.w6G5t9Dc075492@mse.aten.com.tw>]
* Re: your mail
[not found] <201807160555.w6G5t9Dc075492@mse.aten.com.tw>
@ 2018-07-16 10:03 ` Johan Hovold
0 siblings, 0 replies; 669+ messages in thread
From: Johan Hovold @ 2018-07-16 10:03 UTC (permalink / raw)
To: moviesong; +Cc: johan, gregkh, linux-usb, linux-kernel, YorkDai, BillLi
On Mon, Jul 16, 2018 at 09:46:05AM +0800, MovieSong wrote:
> From cff42ec450bdd1fb44dd80564cb622660a9a8071 Mon Sep 17 00:00:00 2001
> From: Movie Song <MovieSong@aten-itlab.cn>
> Date: Fri, 13 Jul 2018 17:46:19 +0800
> Subject: [PATCH] This add a new device for ATEN
>
> Signed-off-by: Movie Song <MovieSong@aten-itlab.cn>
First, your mail still has the legal disclaimer footer which prevents us
from using this patch.
Second, the patch is now inline, but it's unfortunately white-space
damaged (tabs replaces with spaces).
Take a look at
https://marc.info/?l=linux-usb&m=150576193231309
for an example of what the subject and commit message should look like.
Send it to yourself first and make sure it has no legal disclaimer
footers, and that you can apply it using git-am.
> ---
> drivers/usb/serial/pl2303.c | 2 ++
> drivers/usb/serial/pl2303.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 5d1a193..99f7e1f 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -52,6 +52,8 @@
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> + { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
> + .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
And here you add a duplicate entry instead of the one based on the new
id you add.
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
> { USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
> { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
> diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
> index fcd7239..26965cc 100644
> --- a/drivers/usb/serial/pl2303.h
> +++ b/drivers/usb/serial/pl2303.h
> @@ -24,6 +24,7 @@
> #define ATEN_VENDOR_ID2 0x0547
> #define ATEN_PRODUCT_ID 0x2008
> #define ATEN_PRODUCT_UC485 0x2021
> +#define ATEN_PRODUCT_UC232B 0x2022
> #define ATEN_PRODUCT_ID2 0x2118
>
> #define IODATA_VENDOR_ID 0x04bb
Thanks,
Johan
^ permalink raw reply [flat|nested] 669+ messages in thread
* [PATCH V4] xdrstdio_create buffers do not output encoded values on ppc
@ 2018-07-11 15:25 Steve Dickson
2018-07-23 18:43 ` Marc Eshel
0 siblings, 1 reply; 669+ messages in thread
From: Steve Dickson @ 2018-07-11 15:25 UTC (permalink / raw)
To: Libtirpc-devel Mailing List; +Cc: Linux NFS Mailing list
The cause is that the xdr_putlong uses a long to store the
converted value, then passes it to fwrite as a byte buffer.
Only the first 4 bytes are written, which is okay for a LE
system after byteswapping, but writes all zeroes on BE systems.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1261738
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
---
v4: Use UINT32_MAX instead of INT32_MAX in boundary check.
v3: Reworked the bounds checking
v2: Added bounds checking
Changed from unsigned to signed
src/xdr_stdio.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/xdr_stdio.c b/src/xdr_stdio.c
index 4410262..846c7bf 100644
--- a/src/xdr_stdio.c
+++ b/src/xdr_stdio.c
@@ -38,6 +38,7 @@
*/
#include <stdio.h>
+#include <stdint.h>
#include <arpa/inet.h>
#include <rpc/types.h>
@@ -103,10 +104,12 @@ xdrstdio_getlong(xdrs, lp)
XDR *xdrs;
long *lp;
{
+ int32_t mycopy;
- if (fread(lp, sizeof(int32_t), 1, (FILE *)xdrs->x_private) != 1)
+ if (fread(&mycopy, sizeof(int32_t), 1, (FILE *)xdrs->x_private) != 1)
return (FALSE);
- *lp = (long)ntohl((u_int32_t)*lp);
+
+ *lp = (long)ntohl(mycopy);
return (TRUE);
}
@@ -115,8 +118,14 @@ xdrstdio_putlong(xdrs, lp)
XDR *xdrs;
const long *lp;
{
- long mycopy = (long)htonl((u_int32_t)*lp);
+ int32_t mycopy;
+
+#if defined(_LP64)
+ if ((*lp > UINT32_MAX) || (*lp < INT32_MIN))
+ return (FALSE);
+#endif
+ mycopy = (int32_t)htonl((int32_t)*lp);
if (fwrite(&mycopy, sizeof(int32_t), 1, (FILE *)xdrs->x_private) != 1)
return (FALSE);
return (TRUE);
--
2.17.1
^ permalink raw reply related [flat|nested] 669+ messages in thread* (no subject)
2018-07-11 15:25 [PATCH V4] xdrstdio_create buffers do not output encoded values on ppc Steve Dickson
@ 2018-07-23 18:43 ` Marc Eshel
2018-07-23 20:33 ` your mail Bruce Fields
0 siblings, 1 reply; 669+ messages in thread
From: Marc Eshel @ 2018-07-23 18:43 UTC (permalink / raw)
To: Bruce Fields
Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list, linux-nfs-owner
Hi Bruce,
Do you know of any plans to add IETF RFC 8276 - File System Extended
Attributes in NFSv4 to the Linux NFS Client or Server?
Marc.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2018-07-23 18:43 ` Marc Eshel
@ 2018-07-23 20:33 ` Bruce Fields
0 siblings, 0 replies; 669+ messages in thread
From: Bruce Fields @ 2018-07-23 20:33 UTC (permalink / raw)
To: Marc Eshel
Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list, linux-nfs-owner
On Mon, Jul 23, 2018 at 11:43:55AM -0700, Marc Eshel wrote:
> Do you know of any plans to add IETF RFC 8276 - File System Extended
> Attributes in NFSv4 to the Linux NFS Client or Server?
I don't understand why you proposed new protocol without having anyone
in mind to implement it on the platforms where you need it.
Matt Benjamin's expressed interest in the past, but he's got a lot on
his plate so I don't know that we can count on that.
--b.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH v2] staging: rts5208: add check on NULL before dereference
@ 2018-06-13 17:00 Andy Shevchenko
[not found] ` <20180613173128.32384-1-vasilyev@ispras.ru>
0 siblings, 1 reply; 669+ messages in thread
From: Andy Shevchenko @ 2018-06-13 17:00 UTC (permalink / raw)
To: Anton Vasilyev
Cc: Dan Carpenter, Sinan Kaya, Johannes Thumshirn, Gaurav Pathak,
Hannes Reinecke, devel, Linux Kernel Mailing List, ldv-project
On Wed, Jun 13, 2018 at 7:55 PM, Anton Vasilyev <vasilyev@ispras.ru> wrote:
> If rtsx_probe() fails to allocate dev->chip, then NULL pointer
> dereference occurs at release_everything()->rtsx_release_resources().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
You forgot to adjust subject and commit message to the new reality
which is brought by this change.
> Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
> ---
> v2: Add error handling into rtsx_probe based on Dan Carpenter's comment.
> I do not have corresponding hardware, so patch was tested by compilation only.
>
> I faced with inaccuracy at rtsx_remove() and original rtsx_probe():
> there is quiesce_and_remove_host() call with scsi_remove_host() inside,
> whereas release_everything() calls scsi_host_put() after this
> scsi_remove_host() call. This is strange for me.
>
> Also I do not know is it require to check result value of
> rtsx_init_chip() call on rtsx_probe().
> ---
> drivers/staging/rts5208/rtsx.c | 38 +++++++++++++++++++++++-----------
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> index 70e0b8623110..69e6abe14abf 100644
> --- a/drivers/staging/rts5208/rtsx.c
> +++ b/drivers/staging/rts5208/rtsx.c
> @@ -857,7 +857,7 @@ static int rtsx_probe(struct pci_dev *pci,
> dev->chip = kzalloc(sizeof(*dev->chip), GFP_KERNEL);
> if (!dev->chip) {
> err = -ENOMEM;
> - goto errout;
> + goto chip_alloc_fail;
> }
>
> spin_lock_init(&dev->reg_lock);
> @@ -879,7 +879,7 @@ static int rtsx_probe(struct pci_dev *pci,
> if (!dev->remap_addr) {
> dev_err(&pci->dev, "ioremap error\n");
> err = -ENXIO;
> - goto errout;
> + goto ioremap_fail;
> }
>
> /*
> @@ -894,7 +894,7 @@ static int rtsx_probe(struct pci_dev *pci,
> if (!dev->rtsx_resv_buf) {
> dev_err(&pci->dev, "alloc dma buffer fail\n");
> err = -ENXIO;
> - goto errout;
> + goto dma_alloc_fail;
> }
> dev->chip->host_cmds_ptr = dev->rtsx_resv_buf;
> dev->chip->host_cmds_addr = dev->rtsx_resv_buf_addr;
> @@ -915,7 +915,7 @@ static int rtsx_probe(struct pci_dev *pci,
>
> if (rtsx_acquire_irq(dev) < 0) {
> err = -EBUSY;
> - goto errout;
> + goto irq_acquire_fail;
> }
>
> pci_set_master(pci);
> @@ -935,14 +935,14 @@ static int rtsx_probe(struct pci_dev *pci,
> if (IS_ERR(th)) {
> dev_err(&pci->dev, "Unable to start control thread\n");
> err = PTR_ERR(th);
> - goto errout;
> + goto control_thread_fail;
> }
> dev->ctl_thread = th;
>
> err = scsi_add_host(host, &pci->dev);
> if (err) {
> dev_err(&pci->dev, "Unable to add the scsi host\n");
> - goto errout;
> + goto scsi_add_host_fail;
> }
>
> /* Start up the thread for delayed SCSI-device scanning */
> @@ -950,18 +950,16 @@ static int rtsx_probe(struct pci_dev *pci,
> if (IS_ERR(th)) {
> dev_err(&pci->dev, "Unable to start the device-scanning thread\n");
> complete(&dev->scanning_done);
> - quiesce_and_remove_host(dev);
> err = PTR_ERR(th);
> - goto errout;
> + goto scan_thread_fail;
> }
>
> /* Start up the thread for polling thread */
> th = kthread_run(rtsx_polling_thread, dev, "rtsx-polling");
> if (IS_ERR(th)) {
> dev_err(&pci->dev, "Unable to start the device-polling thread\n");
> - quiesce_and_remove_host(dev);
> err = PTR_ERR(th);
> - goto errout;
> + goto scan_thread_fail;
> }
> dev->polling_thread = th;
>
> @@ -970,9 +968,25 @@ static int rtsx_probe(struct pci_dev *pci,
> return 0;
>
> /* We come here if there are any problems */
> -errout:
> +scan_thread_fail:
> + quiesce_and_remove_host(dev);
> +scsi_add_host_fail:
> + complete(&dev->cmnd_ready);
> + wait_for_completion(&dev->control_exit);
> +control_thread_fail:
> + free_irq(dev->irq, (void *)dev);
> + rtsx_release_chip(dev->chip);
> +irq_acquire_fail:
> + dev->chip->host_cmds_ptr = NULL;
> + dev->chip->host_sg_tbl_ptr = NULL;
> + if (dev->chip->msi_en)
> + pci_disable_msi(dev->pci);
> +dma_alloc_fail:
> + iounmap(dev->remap_addr);
> +ioremap_fail:
> + kfree(dev->chip);
> +chip_alloc_fail:
> dev_err(&pci->dev, "%s failed\n", __func__);
> - release_everything(dev);
>
> return err;
> }
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 669+ messages in thread* [PATCH 00/14] Enable SD/MMC on JZ4780 SoCs
@ 2018-03-09 15:12 Ezequiel Garcia
2018-03-09 15:12 ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780 Ezequiel Garcia
0 siblings, 1 reply; 669+ messages in thread
From: Ezequiel Garcia @ 2018-03-09 15:12 UTC (permalink / raw)
To: Ulf Hansson, Paul Cercueil
Cc: linux-mmc, linux-mips, James Hogan, Ezequiel Garcia
This patchset adds support for SD/MMC on JZ4780 based
platforms, such as the MIPS Creator CI20 board.
Most of the work has been done by Alex, Paul and Zubair,
while I've only prepared the upstream submission, cleaned
some patches, and written some commit logs where needed.
All praises should go to them, all rants to me.
The series is based on v4.16-rc4.
Alex Smith (3):
mmc: jz4740: Set clock rate to mmc->f_max rather than JZ_MMC_CLK_RATE
mmc: jz4740: Add support for the JZ4780
mmc: jz4740: Fix race condition in IRQ mask update
Ezequiel Garcia (9):
mmc: jz4780: Order headers alphabetically
mmc: jz4740: Use dev_get_platdata
mmc: jz4740: Introduce devicetree probe
mmc: dt-bindings: add MMC support to JZ4740 SoC
mmc: jz4740: Use dma_request_chan()
MIPS: dts: jz4780: Add DMA controller node to the devicetree
MIPS: dts: jz4780: Add MMC controller node to the devicetree
MIPS: dts: ci20: Enable DMA and MMC in the devicetree
MIPS: configs: ci20: Enable DMA and MMC support
Paul Cercueil (1):
mmc: jz4740: Fix error exit path in driver's probe
Zubair Lutfullah Kakakhel (1):
mmc: jz4740: Reset the device requesting the interrupt
Documentation/devicetree/bindings/mmc/jz4740.txt | 38 ++++
arch/mips/boot/dts/ingenic/ci20.dts | 38 ++++
arch/mips/boot/dts/ingenic/jz4780.dtsi | 54 ++++++
arch/mips/configs/ci20_defconfig | 3 +
drivers/mmc/host/Kconfig | 2 +-
drivers/mmc/host/jz4740_mmc.c | 232 ++++++++++++++++-------
include/dt-bindings/dma/jz4780-dma.h | 49 +++++
7 files changed, 349 insertions(+), 67 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/jz4740.txt
create mode 100644 include/dt-bindings/dma/jz4780-dma.h
--
2.16.2
^ permalink raw reply [flat|nested] 669+ messages in thread
* [PATCH 08/14] mmc: jz4740: Add support for the JZ4780
2018-03-09 15:12 [PATCH 00/14] Enable SD/MMC on JZ4780 SoCs Ezequiel Garcia
@ 2018-03-09 15:12 ` Ezequiel Garcia
2018-03-09 17:51 ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780, Paul Cercueil
0 siblings, 1 reply; 669+ messages in thread
From: Ezequiel Garcia @ 2018-03-09 15:12 UTC (permalink / raw)
To: Ulf Hansson, Paul Cercueil
Cc: linux-mmc, linux-mips, James Hogan, Alex Smith, Ezequiel Garcia
From: Alex Smith <alex.smith@imgtec.com>
Add support for the JZ4780 MMC controller to the jz47xx_mmc driver. There
are a few minor differences from the 4740 to the 4780 that need to be
handled, but otherwise the controllers behave the same. The IREG and IMASK
registers are expanded to 32 bits. Additionally, some error conditions are
now reported in both STATUS and IREG. Writing IREG before reading STATUS
causes the bits in STATUS to be cleared, so STATUS must be read first to
ensure we see and report error conditions correctly.
Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
[Ezequiel: rebase and introduce register accessors]
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
---
drivers/mmc/host/Kconfig | 2 +-
drivers/mmc/host/jz4740_mmc.c | 111 ++++++++++++++++++++++++++++++++++--------
2 files changed, 93 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 620c2d90a646..7dd5169a2dfb 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -767,7 +767,7 @@ config MMC_SH_MMCIF
config MMC_JZ4740
tristate "JZ4740 SD/Multimedia Card Interface support"
- depends on MACH_JZ4740
+ depends on MACH_JZ4740 || MACH_JZ4780
help
This selects support for the SD/MMC controller on Ingenic JZ4740
SoCs.
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 7d4dcce76cd8..bb1b9114ef53 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -1,5 +1,7 @@
/*
* Copyright (C) 2009-2010, Lars-Peter Clausen <lars@metafoo.de>
+ * Copyright (C) 2013, Imagination Technologies
+ *
* JZ4740 SD/MMC controller driver
*
* This program is free software; you can redistribute it and/or modify it
@@ -52,6 +54,7 @@
#define JZ_REG_MMC_RESP_FIFO 0x34
#define JZ_REG_MMC_RXFIFO 0x38
#define JZ_REG_MMC_TXFIFO 0x3C
+#define JZ_REG_MMC_DMAC 0x44
#define JZ_MMC_STRPCL_EXIT_MULTIPLE BIT(7)
#define JZ_MMC_STRPCL_EXIT_TRANSFER BIT(6)
@@ -105,11 +108,15 @@
#define JZ_MMC_IRQ_PRG_DONE BIT(1)
#define JZ_MMC_IRQ_DATA_TRAN_DONE BIT(0)
+#define JZ_MMC_DMAC_DMA_SEL BIT(1)
+#define JZ_MMC_DMAC_DMA_EN BIT(0)
#define JZ_MMC_CLK_RATE 24000000
enum jz4740_mmc_version {
JZ_MMC_JZ4740,
+ JZ_MMC_JZ4750,
+ JZ_MMC_JZ4780,
};
enum jz4740_mmc_state {
@@ -144,7 +151,7 @@ struct jz4740_mmc_host {
uint32_t cmdat;
- uint16_t irq_mask;
+ uint32_t irq_mask;
spinlock_t lock;
@@ -164,8 +171,46 @@ struct jz4740_mmc_host {
* trigger is when data words in MSC_TXFIFO is < 8.
*/
#define JZ4740_MMC_FIFO_HALF_SIZE 8
+
+ void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
+ void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
+ uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
};
+static void jz4750_mmc_write_irq_mask(struct jz4740_mmc_host *host,
+ uint32_t val)
+{
+ return writel(val, host->base + JZ_REG_MMC_IMASK);
+}
+
+static void jz4740_mmc_write_irq_mask(struct jz4740_mmc_host *host,
+ uint32_t val)
+{
+ return writew(val, host->base + JZ_REG_MMC_IMASK);
+}
+
+static void jz4740_mmc_write_irq_reg(struct jz4740_mmc_host *host,
+ uint32_t val)
+{
+ return writew(val, host->base + JZ_REG_MMC_IREG);
+}
+
+static uint32_t jz4740_mmc_read_irq_reg(struct jz4740_mmc_host *host)
+{
+ return readw(host->base + JZ_REG_MMC_IREG);
+}
+
+static void jz4780_mmc_write_irq_reg(struct jz4740_mmc_host *host, uint32_t val)
+{
+ return writel(val, host->base + JZ_REG_MMC_IREG);
+}
+
+/* In the 4780 onwards, IREG is expanded to 32 bits. */
+static uint32_t jz4780_mmc_read_irq_reg(struct jz4740_mmc_host *host)
+{
+ return readl(host->base + JZ_REG_MMC_IREG);
+}
+
/*----------------------------------------------------------------------------*/
/* DMA infrastructure */
@@ -371,7 +416,7 @@ static void jz4740_mmc_set_irq_enabled(struct jz4740_mmc_host *host,
host->irq_mask |= irq;
spin_unlock_irqrestore(&host->lock, flags);
- writew(host->irq_mask, host->base + JZ_REG_MMC_IMASK);
+ host->write_irq_mask(host, host->irq_mask);
}
static void jz4740_mmc_clock_enable(struct jz4740_mmc_host *host,
@@ -422,10 +467,10 @@ static unsigned int jz4740_mmc_poll_irq(struct jz4740_mmc_host *host,
unsigned int irq)
{
unsigned int timeout = 0x800;
- uint16_t status;
+ uint32_t status;
do {
- status = readw(host->base + JZ_REG_MMC_IREG);
+ status = host->read_irq_reg(host);
} while (!(status & irq) && --timeout);
if (timeout == 0) {
@@ -525,7 +570,7 @@ static bool jz4740_mmc_read_data(struct jz4740_mmc_host *host,
void __iomem *fifo_addr = host->base + JZ_REG_MMC_RXFIFO;
uint32_t *buf;
uint32_t d;
- uint16_t status;
+ uint32_t status;
size_t i, j;
unsigned int timeout;
@@ -661,8 +706,25 @@ static void jz4740_mmc_send_command(struct jz4740_mmc_host *host,
cmdat |= JZ_MMC_CMDAT_DATA_EN;
if (cmd->data->flags & MMC_DATA_WRITE)
cmdat |= JZ_MMC_CMDAT_WRITE;
- if (host->use_dma)
- cmdat |= JZ_MMC_CMDAT_DMA_EN;
+ if (host->use_dma) {
+ /*
+ * The 4780's MMC controller has integrated DMA ability
+ * in addition to being able to use the external DMA
+ * controller. It moves DMA control bits to a separate
+ * register. The DMA_SEL bit chooses the external
+ * controller over the integrated one. Earlier SoCs
+ * can only use the external controller, and have a
+ * single DMA enable bit in CMDAT.
+ */
+ if (host->version >= JZ_MMC_JZ4780) {
+ writel(JZ_MMC_DMAC_DMA_EN | JZ_MMC_DMAC_DMA_SEL,
+ host->base + JZ_REG_MMC_DMAC);
+ } else {
+ cmdat |= JZ_MMC_CMDAT_DMA_EN;
+ }
+ } else if (host->version >= JZ_MMC_JZ4780) {
+ writel(0, host->base + JZ_REG_MMC_DMAC);
+ }
writew(cmd->data->blksz, host->base + JZ_REG_MMC_BLKLEN);
writew(cmd->data->blocks, host->base + JZ_REG_MMC_NOB);
@@ -743,7 +805,7 @@ static irqreturn_t jz_mmc_irq_worker(int irq, void *devid)
host->state = JZ4740_MMC_STATE_SEND_STOP;
break;
}
- writew(JZ_MMC_IRQ_DATA_TRAN_DONE, host->base + JZ_REG_MMC_IREG);
+ host->write_irq_reg(host, JZ_MMC_IRQ_DATA_TRAN_DONE);
case JZ4740_MMC_STATE_SEND_STOP:
if (!req->stop)
@@ -773,9 +835,10 @@ static irqreturn_t jz_mmc_irq(int irq, void *devid)
{
struct jz4740_mmc_host *host = devid;
struct mmc_command *cmd = host->cmd;
- uint16_t irq_reg, status, tmp;
+ uint32_t irq_reg, status, tmp;
- irq_reg = readw(host->base + JZ_REG_MMC_IREG);
+ status = readl(host->base + JZ_REG_MMC_STATUS);
+ irq_reg = host->read_irq_reg(host);
tmp = irq_reg;
irq_reg &= ~host->irq_mask;
@@ -784,10 +847,10 @@ static irqreturn_t jz_mmc_irq(int irq, void *devid)
JZ_MMC_IRQ_PRG_DONE | JZ_MMC_IRQ_DATA_TRAN_DONE);
if (tmp != irq_reg)
- writew(tmp & ~irq_reg, host->base + JZ_REG_MMC_IREG);
+ host->write_irq_reg(host, tmp & ~irq_reg);
if (irq_reg & JZ_MMC_IRQ_SDIO) {
- writew(JZ_MMC_IRQ_SDIO, host->base + JZ_REG_MMC_IREG);
+ host->write_irq_reg(host, JZ_MMC_IRQ_SDIO);
mmc_signal_sdio_irq(host->mmc);
irq_reg &= ~JZ_MMC_IRQ_SDIO;
}
@@ -796,8 +859,6 @@ static irqreturn_t jz_mmc_irq(int irq, void *devid)
if (test_and_clear_bit(0, &host->waiting)) {
del_timer(&host->timeout_timer);
- status = readl(host->base + JZ_REG_MMC_STATUS);
-
if (status & JZ_MMC_STATUS_TIMEOUT_RES) {
cmd->error = -ETIMEDOUT;
} else if (status & JZ_MMC_STATUS_CRC_RES_ERR) {
@@ -810,7 +871,7 @@ static irqreturn_t jz_mmc_irq(int irq, void *devid)
}
jz4740_mmc_set_irq_enabled(host, irq_reg, false);
- writew(irq_reg, host->base + JZ_REG_MMC_IREG);
+ host->write_irq_reg(host, irq_reg);
return IRQ_WAKE_THREAD;
}
@@ -844,9 +905,7 @@ static void jz4740_mmc_request(struct mmc_host *mmc, struct mmc_request *req)
host->req = req;
- writew(0xffff, host->base + JZ_REG_MMC_IREG);
-
- writew(JZ_MMC_IRQ_END_CMD_RES, host->base + JZ_REG_MMC_IREG);
+ host->write_irq_reg(host, ~0);
jz4740_mmc_set_irq_enabled(host, JZ_MMC_IRQ_END_CMD_RES, true);
host->state = JZ4740_MMC_STATE_READ_RESPONSE;
@@ -973,6 +1032,7 @@ static void jz4740_mmc_free_gpios(struct platform_device *pdev)
static const struct of_device_id jz4740_mmc_of_match[] = {
{ .compatible = "ingenic,jz4740-mmc", .data = (void *) JZ_MMC_JZ4740 },
+ { .compatible = "ingenic,jz4780-mmc", .data = (void *) JZ_MMC_JZ4780 },
{},
};
MODULE_DEVICE_TABLE(of, jz4740_mmc_of_match);
@@ -1017,6 +1077,19 @@ static int jz4740_mmc_probe(struct platform_device* pdev)
goto err_free_host;
}
+ if (host->version >= JZ_MMC_JZ4780) {
+ host->write_irq_reg = jz4780_mmc_write_irq_reg;
+ host->read_irq_reg = jz4780_mmc_read_irq_reg;
+ } else {
+ host->write_irq_reg = jz4740_mmc_write_irq_reg;
+ host->read_irq_reg = jz4740_mmc_read_irq_reg;
+ }
+
+ if (host->version >= JZ_MMC_JZ4750)
+ host->write_irq_mask = jz4750_mmc_write_irq_mask;
+ else
+ host->write_irq_mask = jz4740_mmc_write_irq_mask;
+
host->irq = platform_get_irq(pdev, 0);
if (host->irq < 0) {
ret = host->irq;
@@ -1055,7 +1128,7 @@ static int jz4740_mmc_probe(struct platform_device* pdev)
host->mmc = mmc;
host->pdev = pdev;
spin_lock_init(&host->lock);
- host->irq_mask = 0xffff;
+ host->irq_mask = ~0;
jz4740_mmc_reset(host);
--
2.16.2
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: [PATCH 08/14] mmc: jz4740: Add support for the JZ4780,
2018-03-09 15:12 ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780 Ezequiel Garcia
@ 2018-03-09 17:51 ` Paul Cercueil
2018-03-09 22:31 ` James Hogan
0 siblings, 1 reply; 669+ messages in thread
From: Paul Cercueil @ 2018-03-09 17:51 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Ulf Hansson, linux-mmc, linux-mips, James Hogan, Alex Smith
Hi,
Le 2018-03-09 16:12, Ezequiel Garcia a écrit :
> From: Alex Smith <alex.smith@imgtec.com>
>
> Add support for the JZ4780 MMC controller to the jz47xx_mmc driver.
> There
> are a few minor differences from the 4740 to the 4780 that need to be
> handled, but otherwise the controllers behave the same. The IREG and
> IMASK
> registers are expanded to 32 bits. Additionally, some error conditions
> are
> now reported in both STATUS and IREG. Writing IREG before reading
> STATUS
> causes the bits in STATUS to be cleared, so STATUS must be read first
> to
> ensure we see and report error conditions correctly.
>
> Signed-off-by: Alex Smith <alex.smith@imgtec.com>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> [Ezequiel: rebase and introduce register accessors]
> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
> ---
> drivers/mmc/host/Kconfig | 2 +-
> drivers/mmc/host/jz4740_mmc.c | 111
> ++++++++++++++++++++++++++++++++++--------
> 2 files changed, 93 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 620c2d90a646..7dd5169a2dfb 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -767,7 +767,7 @@ config MMC_SH_MMCIF
>
> config MMC_JZ4740
> tristate "JZ4740 SD/Multimedia Card Interface support"
> - depends on MACH_JZ4740
> + depends on MACH_JZ4740 || MACH_JZ4780
> help
> This selects support for the SD/MMC controller on Ingenic JZ4740
> SoCs.
> diff --git a/drivers/mmc/host/jz4740_mmc.c
> b/drivers/mmc/host/jz4740_mmc.c
> index 7d4dcce76cd8..bb1b9114ef53 100644
> --- a/drivers/mmc/host/jz4740_mmc.c
> +++ b/drivers/mmc/host/jz4740_mmc.c
> @@ -1,5 +1,7 @@
> /*
> * Copyright (C) 2009-2010, Lars-Peter Clausen <lars@metafoo.de>
> + * Copyright (C) 2013, Imagination Technologies
> + *
> * JZ4740 SD/MMC controller driver
> *
> * This program is free software; you can redistribute it and/or
> modify it
> @@ -52,6 +54,7 @@
> #define JZ_REG_MMC_RESP_FIFO 0x34
> #define JZ_REG_MMC_RXFIFO 0x38
> #define JZ_REG_MMC_TXFIFO 0x3C
> +#define JZ_REG_MMC_DMAC 0x44
>
> #define JZ_MMC_STRPCL_EXIT_MULTIPLE BIT(7)
> #define JZ_MMC_STRPCL_EXIT_TRANSFER BIT(6)
> @@ -105,11 +108,15 @@
> #define JZ_MMC_IRQ_PRG_DONE BIT(1)
> #define JZ_MMC_IRQ_DATA_TRAN_DONE BIT(0)
>
> +#define JZ_MMC_DMAC_DMA_SEL BIT(1)
> +#define JZ_MMC_DMAC_DMA_EN BIT(0)
>
> #define JZ_MMC_CLK_RATE 24000000
>
> enum jz4740_mmc_version {
> JZ_MMC_JZ4740,
> + JZ_MMC_JZ4750,
> + JZ_MMC_JZ4780,
> };
>
> enum jz4740_mmc_state {
> @@ -144,7 +151,7 @@ struct jz4740_mmc_host {
>
> uint32_t cmdat;
>
> - uint16_t irq_mask;
> + uint32_t irq_mask;
>
> spinlock_t lock;
>
> @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> * trigger is when data words in MSC_TXFIFO is < 8.
> */
> #define JZ4740_MMC_FIFO_HALF_SIZE 8
> +
> + void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> + void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> + uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> };
I'm not 100% fan about the callback idea, the original commit
(https://github.com/gcwnow/linux/commit/62472091) doesn't use them and
is
30 lines shorter.
I'm not terribly against either, so if nobody else bug on that, feel
free
to ignore my comment.
> +static void jz4750_mmc_write_irq_mask(struct jz4740_mmc_host *host,
> + uint32_t val)
> +{
> + return writel(val, host->base + JZ_REG_MMC_IMASK);
> +}
> +
> +static void jz4740_mmc_write_irq_mask(struct jz4740_mmc_host *host,
> + uint32_t val)
> +{
> + return writew(val, host->base + JZ_REG_MMC_IMASK);
> +}
> +
> +static void jz4740_mmc_write_irq_reg(struct jz4740_mmc_host *host,
> + uint32_t val)
> +{
> + return writew(val, host->base + JZ_REG_MMC_IREG);
> +}
> +
> +static uint32_t jz4740_mmc_read_irq_reg(struct jz4740_mmc_host *host)
> +{
> + return readw(host->base + JZ_REG_MMC_IREG);
> +}
> +
> +static void jz4780_mmc_write_irq_reg(struct jz4740_mmc_host *host,
> uint32_t val)
> +{
> + return writel(val, host->base + JZ_REG_MMC_IREG);
> +}
> +
> +/* In the 4780 onwards, IREG is expanded to 32 bits. */
> +static uint32_t jz4780_mmc_read_irq_reg(struct jz4740_mmc_host *host)
> +{
> + return readl(host->base + JZ_REG_MMC_IREG);
> +}
> +
>
> /*----------------------------------------------------------------------------*/
> /* DMA infrastructure */
>
> @@ -371,7 +416,7 @@ static void jz4740_mmc_set_irq_enabled(struct
> jz4740_mmc_host *host,
> host->irq_mask |= irq;
> spin_unlock_irqrestore(&host->lock, flags);
>
> - writew(host->irq_mask, host->base + JZ_REG_MMC_IMASK);
> + host->write_irq_mask(host, host->irq_mask);
> }
>
> static void jz4740_mmc_clock_enable(struct jz4740_mmc_host *host,
> @@ -422,10 +467,10 @@ static unsigned int jz4740_mmc_poll_irq(struct
> jz4740_mmc_host *host,
> unsigned int irq)
> {
> unsigned int timeout = 0x800;
> - uint16_t status;
> + uint32_t status;
>
> do {
> - status = readw(host->base + JZ_REG_MMC_IREG);
> + status = host->read_irq_reg(host);
> } while (!(status & irq) && --timeout);
>
> if (timeout == 0) {
> @@ -525,7 +570,7 @@ static bool jz4740_mmc_read_data(struct
> jz4740_mmc_host *host,
> void __iomem *fifo_addr = host->base + JZ_REG_MMC_RXFIFO;
> uint32_t *buf;
> uint32_t d;
> - uint16_t status;
> + uint32_t status;
> size_t i, j;
> unsigned int timeout;
>
> @@ -661,8 +706,25 @@ static void jz4740_mmc_send_command(struct
> jz4740_mmc_host *host,
> cmdat |= JZ_MMC_CMDAT_DATA_EN;
> if (cmd->data->flags & MMC_DATA_WRITE)
> cmdat |= JZ_MMC_CMDAT_WRITE;
> - if (host->use_dma)
> - cmdat |= JZ_MMC_CMDAT_DMA_EN;
> + if (host->use_dma) {
> + /*
> + * The 4780's MMC controller has integrated DMA ability
> + * in addition to being able to use the external DMA
> + * controller. It moves DMA control bits to a separate
> + * register. The DMA_SEL bit chooses the external
> + * controller over the integrated one. Earlier SoCs
> + * can only use the external controller, and have a
> + * single DMA enable bit in CMDAT.
> + */
> + if (host->version >= JZ_MMC_JZ4780) {
> + writel(JZ_MMC_DMAC_DMA_EN | JZ_MMC_DMAC_DMA_SEL,
> + host->base + JZ_REG_MMC_DMAC);
> + } else {
> + cmdat |= JZ_MMC_CMDAT_DMA_EN;
> + }
> + } else if (host->version >= JZ_MMC_JZ4780) {
> + writel(0, host->base + JZ_REG_MMC_DMAC);
> + }
>
> writew(cmd->data->blksz, host->base + JZ_REG_MMC_BLKLEN);
> writew(cmd->data->blocks, host->base + JZ_REG_MMC_NOB);
> @@ -743,7 +805,7 @@ static irqreturn_t jz_mmc_irq_worker(int irq, void
> *devid)
> host->state = JZ4740_MMC_STATE_SEND_STOP;
> break;
> }
> - writew(JZ_MMC_IRQ_DATA_TRAN_DONE, host->base + JZ_REG_MMC_IREG);
> + host->write_irq_reg(host, JZ_MMC_IRQ_DATA_TRAN_DONE);
>
> case JZ4740_MMC_STATE_SEND_STOP:
> if (!req->stop)
> @@ -773,9 +835,10 @@ static irqreturn_t jz_mmc_irq(int irq, void
> *devid)
> {
> struct jz4740_mmc_host *host = devid;
> struct mmc_command *cmd = host->cmd;
> - uint16_t irq_reg, status, tmp;
> + uint32_t irq_reg, status, tmp;
>
> - irq_reg = readw(host->base + JZ_REG_MMC_IREG);
> + status = readl(host->base + JZ_REG_MMC_STATUS);
> + irq_reg = host->read_irq_reg(host);
>
> tmp = irq_reg;
> irq_reg &= ~host->irq_mask;
> @@ -784,10 +847,10 @@ static irqreturn_t jz_mmc_irq(int irq, void
> *devid)
> JZ_MMC_IRQ_PRG_DONE | JZ_MMC_IRQ_DATA_TRAN_DONE);
>
> if (tmp != irq_reg)
> - writew(tmp & ~irq_reg, host->base + JZ_REG_MMC_IREG);
> + host->write_irq_reg(host, tmp & ~irq_reg);
>
> if (irq_reg & JZ_MMC_IRQ_SDIO) {
> - writew(JZ_MMC_IRQ_SDIO, host->base + JZ_REG_MMC_IREG);
> + host->write_irq_reg(host, JZ_MMC_IRQ_SDIO);
> mmc_signal_sdio_irq(host->mmc);
> irq_reg &= ~JZ_MMC_IRQ_SDIO;
> }
> @@ -796,8 +859,6 @@ static irqreturn_t jz_mmc_irq(int irq, void *devid)
> if (test_and_clear_bit(0, &host->waiting)) {
> del_timer(&host->timeout_timer);
>
> - status = readl(host->base + JZ_REG_MMC_STATUS);
> -
> if (status & JZ_MMC_STATUS_TIMEOUT_RES) {
> cmd->error = -ETIMEDOUT;
> } else if (status & JZ_MMC_STATUS_CRC_RES_ERR) {
> @@ -810,7 +871,7 @@ static irqreturn_t jz_mmc_irq(int irq, void *devid)
> }
>
> jz4740_mmc_set_irq_enabled(host, irq_reg, false);
> - writew(irq_reg, host->base + JZ_REG_MMC_IREG);
> + host->write_irq_reg(host, irq_reg);
>
> return IRQ_WAKE_THREAD;
> }
> @@ -844,9 +905,7 @@ static void jz4740_mmc_request(struct mmc_host
> *mmc, struct mmc_request *req)
>
> host->req = req;
>
> - writew(0xffff, host->base + JZ_REG_MMC_IREG);
> -
> - writew(JZ_MMC_IRQ_END_CMD_RES, host->base + JZ_REG_MMC_IREG);
> + host->write_irq_reg(host, ~0);
> jz4740_mmc_set_irq_enabled(host, JZ_MMC_IRQ_END_CMD_RES, true);
>
> host->state = JZ4740_MMC_STATE_READ_RESPONSE;
> @@ -973,6 +1032,7 @@ static void jz4740_mmc_free_gpios(struct
> platform_device *pdev)
>
> static const struct of_device_id jz4740_mmc_of_match[] = {
> { .compatible = "ingenic,jz4740-mmc", .data = (void *) JZ_MMC_JZ4740
> },
> + { .compatible = "ingenic,jz4780-mmc", .data = (void *) JZ_MMC_JZ4780
> },
> {},
> };
> MODULE_DEVICE_TABLE(of, jz4740_mmc_of_match);
> @@ -1017,6 +1077,19 @@ static int jz4740_mmc_probe(struct
> platform_device* pdev)
> goto err_free_host;
> }
>
> + if (host->version >= JZ_MMC_JZ4780) {
> + host->write_irq_reg = jz4780_mmc_write_irq_reg;
> + host->read_irq_reg = jz4780_mmc_read_irq_reg;
> + } else {
> + host->write_irq_reg = jz4740_mmc_write_irq_reg;
> + host->read_irq_reg = jz4740_mmc_read_irq_reg;
> + }
> +
> + if (host->version >= JZ_MMC_JZ4750)
> + host->write_irq_mask = jz4750_mmc_write_irq_mask;
> + else
> + host->write_irq_mask = jz4740_mmc_write_irq_mask;
> +
> host->irq = platform_get_irq(pdev, 0);
> if (host->irq < 0) {
> ret = host->irq;
> @@ -1055,7 +1128,7 @@ static int jz4740_mmc_probe(struct
> platform_device* pdev)
> host->mmc = mmc;
> host->pdev = pdev;
> spin_lock_init(&host->lock);
> - host->irq_mask = 0xffff;
> + host->irq_mask = ~0;
>
> jz4740_mmc_reset(host);
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2018-03-09 22:31 ` James Hogan
0 siblings, 0 replies; 669+ messages in thread
From: James Hogan @ 2018-03-09 22:31 UTC (permalink / raw)
To: Paul Cercueil
Cc: Ezequiel Garcia, Ulf Hansson, linux-mmc, linux-mips, Alex Smith
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
On Fri, Mar 09, 2018 at 06:51:36PM +0100, Paul Cercueil wrote:
> Le 2018-03-09 16:12, Ezequiel Garcia a écrit :
> > @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> > * trigger is when data words in MSC_TXFIFO is < 8.
> > */
> > #define JZ4740_MMC_FIFO_HALF_SIZE 8
> > +
> > + void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> > + void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> > + uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> > };
>
> I'm not 100% fan about the callback idea, the original commit
> (https://github.com/gcwnow/linux/commit/62472091) doesn't use them and
> is
> 30 lines shorter.
>
> I'm not terribly against either, so if nobody else bug on that, feel
> free
> to ignore my comment.
I was thinking the same as Paul too to be honest. Unless there is a
measurable benefit to having callbacks, I think its cleaner and more
readable to stick to conditionals and normal abstractions where
appropriate.
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2018-03-09 22:31 ` James Hogan
0 siblings, 0 replies; 669+ messages in thread
From: James Hogan @ 2018-03-09 22:31 UTC (permalink / raw)
To: Paul Cercueil
Cc: Ezequiel Garcia, Ulf Hansson, linux-mmc, linux-mips, Alex Smith
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
On Fri, Mar 09, 2018 at 06:51:36PM +0100, Paul Cercueil wrote:
> Le 2018-03-09 16:12, Ezequiel Garcia a écrit :
> > @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> > * trigger is when data words in MSC_TXFIFO is < 8.
> > */
> > #define JZ4740_MMC_FIFO_HALF_SIZE 8
> > +
> > + void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> > + void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> > + uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> > };
>
> I'm not 100% fan about the callback idea, the original commit
> (https://github.com/gcwnow/linux/commit/62472091) doesn't use them and
> is
> 30 lines shorter.
>
> I'm not terribly against either, so if nobody else bug on that, feel
> free
> to ignore my comment.
I was thinking the same as Paul too to be honest. Unless there is a
measurable benefit to having callbacks, I think its cleaner and more
readable to stick to conditionals and normal abstractions where
appropriate.
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2018-02-18 8:14 Tomasz Kłoczko
2018-02-18 9:28 ` your mail Tomasz Pala
0 siblings, 1 reply; 669+ messages in thread
From: Tomasz Kłoczko @ 2018-02-18 8:14 UTC (permalink / raw)
To: Linux fs Btrfs
Hi,
For some reasons btrfs pool each volume is not displayed in mount and
df output, and I cannot find how to display volumes/snapshots usage
using btrfs command.
I'm looking for equivalent of the "zfs list -r -t [all|snapshot,filesystem]"
https://docs.oracle.com/cd/E23824_01/html/821-1448/gazsu.html#scrolltoc
Can someone help with exact command syntax?
As it is a quite basic function I think that some man page must be not
up-to-date or I'm looking at the wrong doc .. or I'm just blind :-/
Another question related to btrfs functionalities.
Is anyone working on the analog of zfs delegations?
https://docs.oracle.com/cd/E23824_01/html/821-1448/gbchv.html#scrolltoc
I'm using now btrfs quite intensively and I'm trying to use btrfs as
same way as I've been using for veeery long time zfs :-P
So now I have many volumes and snapshots in my home directory, but to
maintain all this I must use root permission. As non-root working in
my own home which is separated btrfs volume it would be nice to have
the possibility to delegate permission to create, destroy,
send/receive, mount/umount etc. snapshots, volumes like it os possible
on zfs.
BTW: someone maybe started working on something like .zfs hidden
directory functions which is in each zfs volume mountpoint?
Have few or few tenths snapshots is not so big deal but the same on
scale few hundreds, thousands or more snapshots I think that would be
really hard without something like hidden .btrfs/snapshots directory.
On zfs .zfs/snapshots directory is especially useful when the volume
is exported over for example NFS. With zfs volume exported over NFS on
NFS client is possible to do "mkdir .zfs/snapshot/my_snapshot" to
create the snapshot (even from NFS client working on Windows) or
"rmdir .zfs/snapshot/my_snapshot" to destroy snapshot from remote NFS
client system. All without login over for example ssh on NFS server.
And last question.
As Linux has now containers which provide most of the core Solaris
non-global zones functions it would be good to have as well equivalent
of the zfs zoned property.
https://docs.oracle.com/cd/E19253-01/819-5461/gbbre/index.html
Someone maybe started working on something like this for btrfs?
After few years not using btrfs (because previously was quite
unstable) It is really good to see that now I'm not able to crash it.
I must say "big thank you" to all those people involved in reaching
current state :)
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2018-02-18 8:14 Tomasz Kłoczko
@ 2018-02-18 9:28 ` Tomasz Pala
2018-02-18 9:34 ` Tomasz Pala
0 siblings, 1 reply; 669+ messages in thread
From: Tomasz Pala @ 2018-02-18 9:28 UTC (permalink / raw)
To: Tomasz Kłoczko; +Cc: Linux fs Btrfs
On Sun, Feb 18, 2018 at 08:14:25 +0000, Tomasz Kłoczko wrote:
> For some reasons btrfs pool each volume is not displayed in mount and
> df output, and I cannot find how to display volumes/snapshots usage
> using btrfs command.
In general: not possible without enabling quotas, which in turn impact
snapshot performance significally.
btrfs quota enable /
btrfs quota rescan /
btrfs qgroup sh --sort=excl /
> So now I have many volumes and snapshots in my home directory, but to
> maintain all this I must use root permission. As non-root working in
> my own home which is separated btrfs volume it would be nice to have
> the possibility to delegate permission to create, destroy,
> send/receive, mount/umount etc. snapshots, volumes like it os possible
> on zfs.
I've already noticed this problem on February 10th:
[btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks
In short: not possible. Regular user can only create subvolumes.
> BTW: someone maybe started working on something like .zfs hidden
> directory functions which is in each zfs volume mountpoint?
In btrfs world this is done differently - don't put main (working) volume in the
root, but mount some branch by default, keeping all the subvolumes next
to it. I.e. don't:
@working_subvolume
@working_subvolume/snapshots
but:
@root_of_the_fs
@root_of_the_fs/working_subvolume
@root_of_the_fs/snapshots
In fact this is manual workaroud for the problem you've mentioned.
> Have few or few tenths snapshots is not so big deal but the same on
> scale few hundreds, thousands or more snapshots I think that would be
> really hard without something like hidden .btrfs/snapshots directory.
With few hundreds of subvolumes btrfs would fail miserably.
> After few years not using btrfs (because previously was quite
> unstable) It is really good to see that now I'm not able to crash it.
It's not crashing with LTS 4.4 and 4.9 kernels, many reports of various
crashes in 4.12, 4.14 and 4.15 were posted here. It is really hard to say,
which of the post-4.9 kernels have reliable btrfs.
--
Tomasz Pala <gotar@pld-linux.org>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2018-02-18 9:28 ` your mail Tomasz Pala
@ 2018-02-18 9:34 ` Tomasz Pala
0 siblings, 0 replies; 669+ messages in thread
From: Tomasz Pala @ 2018-02-18 9:34 UTC (permalink / raw)
To: Tomasz Kłoczko; +Cc: Linux fs Btrfs
On Sun, Feb 18, 2018 at 10:28:02 +0100, Tomasz Pala wrote:
> I've already noticed this problem on February 10th:
> [btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks
>
> In short: not possible. Regular user can only create subvolumes.
Not possible "oficially". Axel Burri has replied with more helpful approach:
https://github.com/digint/btrfs-progs-btrbk
Unfortunately this issue was not picked up by any developer, so for now
we can only wait for splitting libbtrfsutil so this task could be easier.
--
Tomasz Pala <gotar@pld-linux.org>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2017-12-07 21:32 Paul Marques Mota
2017-12-07 23:34 ` your mail Guenter Roeck
0 siblings, 1 reply; 669+ messages in thread
From: Paul Marques Mota @ 2017-12-07 21:32 UTC (permalink / raw)
To: linux-hwmon
From: Paul Marques Mota <paul@marquesmota.pt>
To: HARDWARE MONITORING <linux-hwmon@vger.kernel.org>
Date: Thu, 7 Dec 2017 20:04:22 +0000
Subject: [PATCH] add stack trace to deprecated hwmon_device_register()
Hi,
hwmon_device_register() in drivers/hwmon/hwmon.c prints the unhelpful
message below on my machine:
(NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
Therefore, this patch dumps the stack at that point. In my case it is
then obvious in the resulting dmesg, available at
http://www.marquesmota.pt/dmesg.txt
that thermal_add_hwmon_sysfs() in drivers/thermal/thermal_hwmon.c needs
to be converted to the new API.
This patch is against 4.15.0-rc2
I believe it is also needed in Bugzilla bug #195843
https://bugzilla.kernel.org/show_bug.cgi?id=195843
Signed-off-by: Paul Marques Mota<paul@marquesmota.pt>
---
drivers/hwmon/hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index c9790e2c3440..31719ce4a681 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -702,6 +702,7 @@ struct device *hwmon_device_register(struct device *dev)
{
dev_warn(dev,
"hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().\n");
+ dump_stack();
return __hwmon_device_register(dev, NULL, NULL, NULL, NULL);
}
--
2.15.1
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2017-12-07 21:32 Paul Marques Mota
@ 2017-12-07 23:34 ` Guenter Roeck
2017-12-07 23:38 ` Paul Marques Mota
0 siblings, 1 reply; 669+ messages in thread
From: Guenter Roeck @ 2017-12-07 23:34 UTC (permalink / raw)
To: Paul Marques Mota; +Cc: linux-hwmon
On Thu, Dec 07, 2017 at 09:32:01PM +0000, Paul Marques Mota wrote:
> From: Paul Marques Mota <paul@marquesmota.pt>
> To: HARDWARE MONITORING <linux-hwmon@vger.kernel.org>
> Date: Thu, 7 Dec 2017 20:04:22 +0000
> Subject: [PATCH] add stack trace to deprecated hwmon_device_register()
>
> Hi,
>
> hwmon_device_register() in drivers/hwmon/hwmon.c prints the unhelpful
> message below on my machine:
>
> (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
>
> Therefore, this patch dumps the stack at that point. In my case it is
> then obvious in the resulting dmesg, available at
>
> http://www.marquesmota.pt/dmesg.txt
>
> that thermal_add_hwmon_sysfs() in drivers/thermal/thermal_hwmon.c needs
> to be converted to the new API.
>
> This patch is against 4.15.0-rc2
> I believe it is also needed in Bugzilla bug #195843
> https://bugzilla.kernel.org/show_bug.cgi?id=195843
>
> Signed-off-by: Paul Marques Mota<paul@marquesmota.pt>
Nack, this is not needed. The thermal subsystem is the only subsystem
which doesn't pass a device pointer, and I don't want to have logs
clogged up with unnecessary tracebacks because of it.
If it wasn't for thermal, I would actually let hwmon registrations with
NULL device pointer fail completely. Unfortunately there is no easy way
to convert the thermal subsystem to use hwmon_device_register_with_info(),
since even though thermal_zone_device_register() registers a thermal zone
device, it does not have a notion of 'struct device *'.
Maybe someone can step in and convert the thermal code to use
hwmon_device_register_with_groups(). That doesn't really solve the problem,
but at least the symptom would be gone, and the thermal code would be
a little cleaner.
Guenter
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2017-12-07 9:26 Alexander Kappner
2017-12-07 10:38 ` your mail Greg Kroah-Hartman
0 siblings, 1 reply; 669+ messages in thread
From: Alexander Kappner @ 2017-12-07 9:26 UTC (permalink / raw)
To: mathias.nyman, Greg Kroah-Hartman, linux-usb, linux-kernel
Cc: Alexander Kappner
Date: Wed, 6 Dec 2017 15:28:37 -0800
Subject: [PATCH] usb-core: Fix potential null pointer dereference in xhci-debugfs.c
My kernel crashed just after resuming from hibernate and starting usbmuxd
(a user-space daemon for iOS device pairing) with several USB devices
connected (dmesg attached).
Backtrace leads to:
0xffffffff8170465d is in xhci_debugfs_create_endpoint
(drivers/usb/host/xhci-debugfs.c:381).
376 int ep_index)
377 {
378 struct xhci_ep_priv *epriv;
379 struct xhci_slot_priv *spriv = dev->debugfs_private;
380
381 if (spriv->eps[ep_index])
382 return;
383
384 epriv = kzalloc(sizeof(*epriv), GFP_KERNEL);
385 if (!epriv)
The read violation happens at address 0x40 and sizeof(struct
xhci_ep_priv)=0x40, so it seems ep_index is 1 and spriv is NULL here.
spriv gets allocated in xhci_debugfs_create_slot:
...
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return;
...
There's no separate error path if this allocation fails, so we might be
left with NULL in priv. Subsequent users of priv thus need to check for
this NULL - so this is what the patch does.
There might be other ways of triggering this null pointer dereference,
including when xhci_resume frees the device structures (e.g. after
returning from a hibernate), but I wasn't able to find or reproduce it.
[63953.758083] BUG: unable to handle kernel NULL pointer dereference at
0000000000000040
[63953.758090] IP: xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758091] PGD bb911d067 P4D bb911d067 PUD 10500ff067 PMD 0
[63953.758093] Oops: 0000 [#1] PREEMPT SMP
[63953.758094] Modules linked in: ipheth tun nvidia_modeset(PO) iwlmvm
mac80211 iwlwifi nvidia(PO) btusb btrtl btbcm btintel bluetooth cfg80211
qmi_wwan ecdh_generic thinkpad_acpi rfkill
[63953.758103] CPU: 4 PID: 27091 Comm: usbmuxd Tainted: P O
4.14.0.1-12769-g1deab8c #1
[63953.758104] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W
(1.35 ) 11/10/2016
[63953.758105] task: ffff8810527ba0c0 task.stack: ffffc9000a8ec000
[63953.758107] RIP: 0010:xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758108] RSP: 0018:ffffc9000a8efc80 EFLAGS: 00010206
[63953.758109] RAX: 0000000000000000 RBX: ffff88105a71c000 RCX:
0000000000030000
[63953.758110] RDX: 0000000000000003 RSI: ffff880c0b57e000 RDI:
ffff88105a71c238
[63953.758110] RBP: 0000000000000003 R08: ffff881063800600 R09:
0000000000000003
[63953.758111] R10: ffff88105a71c238 R11: 0000000000000001 R12:
0000000000000011
[63953.758112] R13: 0000000000000018 R14: 0000000000000000 R15:
0000000000000000
[63953.758113] FS: 00007f0a77715700(0000) GS:ffff8810a3d00000(0000)
knlGS:0000000000000000
[63953.758114] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[63953.758115] CR2: 0000000000000040 CR3: 00000003f91a8006 CR4:
00000000003606e0
[63953.758115] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[63953.758116] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[63953.758117] Call Trace:
[63953.758120] xhci_add_endpoint+0x127/0x2b0
[63953.758123] usb_hcd_alloc_bandwidth+0x1ad/0x300
[63953.758125] usb_set_configuration+0x1c8/0x880
[63953.758128] usbdev_do_ioctl+0xc41/0x1120
[63953.758130] usbdev_ioctl+0xa/0x10
[63953.758151] do_vfs_ioctl+0x8b/0x5c0
[63953.758153] ? __fget+0x6c/0xb0
[63953.758155] SyS_ioctl+0x76/0x90
[63953.758157] do_syscall_64+0x6b/0x290
[63953.758173] entry_SYSCALL64_slow_path+0x25/0x25
[63953.758175] RIP: 0033:0x7f0a76a151c7
[63953.758175] RSP: 002b:00007ffd1431b0c8 EFLAGS: 00000202 ORIG_RAX:
0000000000000010
[63953.758177] RAX: ffffffffffffffda RBX: 00000000023239a0 RCX:
00007f0a76a151c7
[63953.758178] RDX: 00007ffd1431b0dc RSI: 0000000080045505 RDI:
000000000000000e
[63953.758178] RBP: 00000000023240c0 R08: 00007ffd1431b008 R09:
0000000000000004
[63953.758179] R10: 00007ffd1431aec0 R11: 0000000000000202 R12:
00000000023240c0
[63953.758180] R13: 0000000000000001 R14: 0000000000000056 R15:
0000000000000038
[63953.758182] Code: e9 39 ff ff ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 41 57 41 56 41 55 41 54 55 48 63 ea 53 4c 8b b6 88 15 00 00 4d 8d 2c ee
<49> 83 7d 28 00 74 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 3d
[63953.758202] RIP: xhci_debugfs_create_endpoint+0x1d/0xa0 RSP:
ffffc9000a8efc80
[63953.758203] CR2: 0000000000000040
[63953.758204] ---[ end trace 1f7ea9a959f02054 ]---
Signed-off-by: Alexander Kappner <agk@godking.net>
---
drivers/usb/host/xhci-debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index 4f7895d..1cea59c 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -378,6 +378,9 @@ void xhci_debugfs_create_endpoint(struct xhci_hcd *xhci,
struct xhci_ep_priv *epriv;
struct xhci_slot_priv *spriv = dev->debugfs_private;
+ if (!spriv)
+ return;
+
if (spriv->eps[ep_index])
return;
--
2.1.4
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2017-12-07 9:26 Alexander Kappner
@ 2017-12-07 10:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 669+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-07 10:38 UTC (permalink / raw)
To: Alexander Kappner; +Cc: mathias.nyman, linux-usb, linux-kernel
On Thu, Dec 07, 2017 at 01:26:14AM -0800, Alexander Kappner wrote:
> Date: Wed, 6 Dec 2017 15:28:37 -0800
> Subject: [PATCH] usb-core: Fix potential null pointer dereference in xhci-debugfs.c
Something went wrong here, resulting in an email with no subject.
Can you fix this up and resend?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2017-08-18 17:42 Rajneesh Bhardwaj
2017-08-18 17:53 ` your mail Rajneesh Bhardwaj
0 siblings, 1 reply; 669+ messages in thread
From: Rajneesh Bhardwaj @ 2017-08-18 17:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peter Zijlstra (Intel),
Platform Driver, dvhart, Andy Shevchenko, linux-kernel,
Vishwanath Somayaji, dbasehore, rjw, rajatja
Bcc:
Subject: Re: [PATCH] platform/x86: intel_pmc_core: Add Package C-states
residency info
Reply-To:
In-Reply-To: <CAHp75Vd5Wnio-RCEBENtonYWOJF2+88FDvqkUv1HzV3CdcaaPA@mail.gmail.com>
On Fri, Aug 18, 2017 at 08:17:32PM +0300, Andy Shevchenko wrote:
> +PeterZ (since I mentioned his name)
>
> On Fri, Aug 18, 2017 at 5:58 PM, Rajneesh Bhardwaj
> <rajneesh.bhardwaj@intel.com> wrote:
> > On Fri, Aug 18, 2017 at 03:57:34PM +0300, Andy Shevchenko wrote:
> >> On Fri, Aug 18, 2017 at 3:37 PM, Rajneesh Bhardwaj
> >> <rajneesh.bhardwaj@intel.com> wrote:
> >> > This patch introduces a new debugfs entry to read current Package C-state
> >> > residency values and, one new kernel API to read the Package C-10 residency
> >> > counter.
> >> >
> >> > Package C-state residency MSRs provide useful debug information about system
> >> > idle states. In idle states system must enter deeper Package C-states.
>
> >> Why this patch is needed?
> >
> > Andy, I'll try to give some background for this.
> >
> > This is needed to enhance the S0ix failure debug capabilities from within
> > the kernel. On ChromeOS we have S0ix failsafe kernel framework that is used
> > to validate S0ix and report the blockers in case of a failure.
> > https://patchwork.kernel.org/patch/9148999/
>
> (It's not part of upstream)
Sorry i sent an older link. There are fresh attempts to get this into
mainline kernel and looks like there is a traction for it.
https://patchwork.kernel.org/patch/9831229/
Package C-state (PC10) validation is discussed there.
>
> > So far only intel_pmc_slp_s0_counter_read is called by this framework to
> > check whether the previous attempt to enter S0ix was success or not.
>
> I harder see even a single user of that API in current kernel. It
> should be unexported and removed I think.
>
> > Having
> > another PC10 counter related exported function enhances the S0ix debug since
> > PC10 state is a prerequisite to enter S0ix.
> >
> >> See, we have turbostat and cpupower user space tools which do this
> >> without any additional code to be written in kernel. What prevents
> >> your user space application do the same?
> >>
> >> Moreover, we have events for cstate, I assume perf or something alike
> >> can monitor those counters as well.
> >
> > You're right, perhaps the debugfs is redundant when we have those user space
> > tools but such tools are not available readily for all platforms/distros.
> > Interfaces like /dev/cpu/*/msr that turbostat uses are not available on all
> > the platforms.
> > PMC driver is a debug driver so i thought its better to show Package C-state
> > related info for low power debug here.
> >
> >>
> >> Sorry, NAK.
> >
> > This patch has two parts i.e. exported PC10 API and the debugfs. Based on
> > the above explanation, if the patch is not good as is, please let me know if
> > i should drop the debugfs part and respin a v2 with just the exported API or
> > drop this totally.
> >
> > Thanks for the feedback and thanks for taking time to review!
>
> Reading above makes me think that entire design of this is misguided.
> Since the most of values are counters they better to be accessed in a
> way how perf does.
>
> In case you need *in-kernel* facility, do some APIs (if it's not done
> yet) for events drivers first.
> cstate event driver is already in upstream.
>
> Sorry, NAK for entire patch until it would be blessed by people like Peter Z.
>
> --
> With Best Regards,
> Andy Shevchenko
--
Best Regards,
Rajneesh
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-08-18 17:42 Rajneesh Bhardwaj
@ 2017-08-18 17:53 ` Rajneesh Bhardwaj
0 siblings, 0 replies; 669+ messages in thread
From: Rajneesh Bhardwaj @ 2017-08-18 17:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peter Zijlstra (Intel),
Platform Driver, dvhart, Andy Shevchenko, linux-kernel,
Vishwanath Somayaji, dbasehore, rjw, rajatja
On Fri, Aug 18, 2017 at 11:12:14PM +0530, Rajneesh Bhardwaj wrote:
> Bcc:
> Subject: Re: [PATCH] platform/x86: intel_pmc_core: Add Package C-states
> residency info
> Reply-To:
> In-Reply-To: <CAHp75Vd5Wnio-RCEBENtonYWOJF2+88FDvqkUv1HzV3CdcaaPA@mail.gmail.com>
>
Please ignore my previous email without subject. It was sent by mistake.
> On Fri, Aug 18, 2017 at 08:17:32PM +0300, Andy Shevchenko wrote:
> > +PeterZ (since I mentioned his name)
> >
> > On Fri, Aug 18, 2017 at 5:58 PM, Rajneesh Bhardwaj
> > <rajneesh.bhardwaj@intel.com> wrote:
> > > On Fri, Aug 18, 2017 at 03:57:34PM +0300, Andy Shevchenko wrote:
> > >> On Fri, Aug 18, 2017 at 3:37 PM, Rajneesh Bhardwaj
> > >> <rajneesh.bhardwaj@intel.com> wrote:
> > >> > This patch introduces a new debugfs entry to read current Package C-state
> > >> > residency values and, one new kernel API to read the Package C-10 residency
> > >> > counter.
> > >> >
> > >> > Package C-state residency MSRs provide useful debug information about system
> > >> > idle states. In idle states system must enter deeper Package C-states.
> >
> > >> Why this patch is needed?
> > >
> > > Andy, I'll try to give some background for this.
> > >
> > > This is needed to enhance the S0ix failure debug capabilities from within
> > > the kernel. On ChromeOS we have S0ix failsafe kernel framework that is used
> > > to validate S0ix and report the blockers in case of a failure.
> > > https://patchwork.kernel.org/patch/9148999/
> >
> > (It's not part of upstream)
>
> Sorry i sent an older link. There are fresh attempts to get this into
> mainline kernel and looks like there is a traction for it.
> https://patchwork.kernel.org/patch/9831229/
>
> Package C-state (PC10) validation is discussed there.
>
> >
> > > So far only intel_pmc_slp_s0_counter_read is called by this framework to
> > > check whether the previous attempt to enter S0ix was success or not.
> >
> > I harder see even a single user of that API in current kernel. It
> > should be unexported and removed I think.
> >
> > > Having
> > > another PC10 counter related exported function enhances the S0ix debug since
> > > PC10 state is a prerequisite to enter S0ix.
> > >
> > >> See, we have turbostat and cpupower user space tools which do this
> > >> without any additional code to be written in kernel. What prevents
> > >> your user space application do the same?
> > >>
> > >> Moreover, we have events for cstate, I assume perf or something alike
> > >> can monitor those counters as well.
> > >
> > > You're right, perhaps the debugfs is redundant when we have those user space
> > > tools but such tools are not available readily for all platforms/distros.
> > > Interfaces like /dev/cpu/*/msr that turbostat uses are not available on all
> > > the platforms.
> > > PMC driver is a debug driver so i thought its better to show Package C-state
> > > related info for low power debug here.
> > >
> > >>
> > >> Sorry, NAK.
> > >
> > > This patch has two parts i.e. exported PC10 API and the debugfs. Based on
> > > the above explanation, if the patch is not good as is, please let me know if
> > > i should drop the debugfs part and respin a v2 with just the exported API or
> > > drop this totally.
> > >
> > > Thanks for the feedback and thanks for taking time to review!
> >
> > Reading above makes me think that entire design of this is misguided.
> > Since the most of values are counters they better to be accessed in a
> > way how perf does.
> >
> > In case you need *in-kernel* facility, do some APIs (if it's not done
> > yet) for events drivers first.
> > cstate event driver is already in upstream.
> >
> > Sorry, NAK for entire patch until it would be blessed by people like Peter Z.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> --
> Best Regards,
> Rajneesh
--
Best Regards,
Rajneesh
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2017-06-26 5:21 Leon Romanovsky
[not found] ` <20170626052117.GX1248-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: Leon Romanovsky @ 2017-06-26 5:21 UTC (permalink / raw)
To: Marcel Apfelbaum; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Yuval Shaia
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Bcc:
Subject: Re: Proposal for the 2nd RDMA microconference (LPC 2017)
Reply-To:
In-Reply-To: <786f10f7-6253-c95b-49e2-a89010a43781-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, Jun 25, 2017 at 11:43:35AM +0300, Marcel Apfelbaum wrote:
> Hi Leon,
>
> Here is our proposal for the coming conference.
Thanks Marcel for sending proposal, I'm looking forward to see you and
Yuval there.
In the meantime, I'm adding David who is our LPC POC and would like to
ask some questions.
>
> Abstract
> --------
> QEMU's limited RDMA support leaves it behind other modern hypervisors.
> Marcel and/or Yuval will present the implementation of an emulated RDMA
> device, analyze its performance and usability, and finally talk about future
> plans for a possible virtio-rdma device.
How are you implementing different fabrics? Does it completely SW
implementation and/or it requires HW beneath like prvdma? Namespaces,
migration?
What are the expectations from the community?
>
> Audience
> --------
> The audience is developers interested in device emulation / RDMA.
> They can expect an interesting discussion on what are the difficulties to
> work with RDMA in Virtual Machines and they will be welcomed to share their
> ideas.
>
> Benefits to the Ecosystem
> -------------------------
> Knowing how to tackle RDMA on virtualization may give developers an easier
> start on adding RDMA support to QEMU, which in turn will leverage the modern
> RDMA cards on virtualized environments.
>
>
> Thanks,
> Marcel & Yuval
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* (no subject)
@ 2017-06-22 9:50 Jessie Hernandez
2017-06-22 12:48 ` your mail Simon Ruderich
0 siblings, 1 reply; 669+ messages in thread
From: Jessie Hernandez @ 2017-06-22 9:50 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 9:50 Jessie Hernandez
@ 2017-06-22 12:48 ` Simon Ruderich
2017-06-22 13:35 ` AW: " Patrick Lehmann
0 siblings, 1 reply; 669+ messages in thread
From: Simon Ruderich @ 2017-06-22 12:48 UTC (permalink / raw)
To: Jessie Hernandez; +Cc: git
On Thu, Jun 22, 2017 at 11:50:01AM +0200, Jessie Hernandez wrote:
> subscribe git
You need to write to majordomo@vger.kernel.org (with subscribe
git in the body) to subscribe.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
^ permalink raw reply [flat|nested] 669+ messages in thread
* AW: your mail
2017-06-22 12:48 ` your mail Simon Ruderich
@ 2017-06-22 13:35 ` Patrick Lehmann
2017-06-22 13:47 ` Simon Ruderich
0 siblings, 1 reply; 669+ messages in thread
From: Patrick Lehmann @ 2017-06-22 13:35 UTC (permalink / raw)
To: Simon Ruderich, Jessie Hernandez; +Cc: git
But how can he write to the mailing list without a subscription?
Is this a security bug or is he already subscribed?
________________________________________
Von: git-owner@vger.kernel.org [git-owner@vger.kernel.org]" im Auftrag von "Simon Ruderich [simon@ruderich.org]
Gesendet: Donnerstag, 22. Juni 2017 14:48
Bis: Jessie Hernandez
Cc: git@vger.kernel.org
Betreff: Re: your mail
On Thu, Jun 22, 2017 at 11:50:01AM +0200, Jessie Hernandez wrote:
> subscribe git
You need to write to majordomo@vger.kernel.org (with subscribe
git in the body) to subscribe.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 13:35 ` AW: " Patrick Lehmann
@ 2017-06-22 13:47 ` Simon Ruderich
2017-06-22 13:55 ` AW: " Patrick Lehmann
0 siblings, 1 reply; 669+ messages in thread
From: Simon Ruderich @ 2017-06-22 13:47 UTC (permalink / raw)
To: Patrick Lehmann; +Cc: Jessie Hernandez, git
On Thu, Jun 22, 2017 at 01:35:33PM +0000, Patrick Lehmann wrote:
> But how can he write to the mailing list without a subscription?
> Is this a security bug or is he already subscribed?
Everybody can send to this mailing list. This is by design so
contributors/bug reporters can send mails without having to
subscribe.
Regards
Simon
--
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9
^ permalink raw reply [flat|nested] 669+ messages in thread
* AW: your mail
2017-06-22 13:47 ` Simon Ruderich
@ 2017-06-22 13:55 ` Patrick Lehmann
2017-06-22 20:46 ` Simon Ruderich
0 siblings, 1 reply; 669+ messages in thread
From: Patrick Lehmann @ 2017-06-22 13:55 UTC (permalink / raw)
To: Simon Ruderich; +Cc: Jessie Hernandez, git
The description on https://github.com/git/git doesn't reflect that policy.
a)
It explains that discussions take place in the mentioned mailing list.
b)
It describes how to subscribe.
With knowledge of other mailing lists (mostly managed by mailman),
subscription is required for participation.
________________________________________
Von: Simon Ruderich [simon@ruderich.org]
Gesendet: Donnerstag, 22. Juni 2017 15:47
Bis: Patrick Lehmann
Cc: Jessie Hernandez; git@vger.kernel.org
Betreff: Re: your mail
On Thu, Jun 22, 2017 at 01:35:33PM +0000, Patrick Lehmann wrote:
> But how can he write to the mailing list without a subscription?
> Is this a security bug or is he already subscribed?
Everybody can send to this mailing list. This is by design so
contributors/bug reporters can send mails without having to
subscribe.
Regards
Simon
--
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 13:55 ` AW: " Patrick Lehmann
@ 2017-06-22 20:46 ` Simon Ruderich
2017-06-22 21:35 ` Junio C Hamano
0 siblings, 1 reply; 669+ messages in thread
From: Simon Ruderich @ 2017-06-22 20:46 UTC (permalink / raw)
To: Patrick Lehmann; +Cc: Jessie Hernandez, git
On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
> The description on https://github.com/git/git doesn't reflect that policy.
>
> a)
> It explains that discussions take place in the mentioned mailing list.
> b)
> It describes how to subscribe.
However it doesn't say that you have to subscribe to send, only
how to subscribe.
> With knowledge of other mailing lists (mostly managed by mailman),
> subscription is required for participation.
That depends on the mailing list, some require subscription to
prevent spams but not all do.
Somebody might want to update the documentation, but personally
I see no reason to change anything. If you want to send a patch
to improve it, that would be great of course.
Regards
Simon
PS: Please don't top-post on this mailing list.
--
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 20:46 ` Simon Ruderich
@ 2017-06-22 21:35 ` Junio C Hamano
2017-06-22 21:58 ` Ævar Arnfjörð Bjarmason
0 siblings, 1 reply; 669+ messages in thread
From: Junio C Hamano @ 2017-06-22 21:35 UTC (permalink / raw)
To: Simon Ruderich; +Cc: Patrick Lehmann, Jessie Hernandez, git
Simon Ruderich <simon@ruderich.org> writes:
> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>> The description on https://github.com/git/git doesn't reflect that policy.
>>
>> a)
>> It explains that discussions take place in the mentioned mailing list.
>> b)
>> It describes how to subscribe.
>
> However it doesn't say that you have to subscribe to send, only
> how to subscribe.
For that matter, we also say "everyone is welcome to post", which
makes it clear that no subscription is required.
But I view these merely being technically correct. And making it
absolutely obvious does not cost too much.
>> With knowledge of other mailing lists (mostly managed by mailman),
>> subscription is required for participation.
>
> That depends on the mailing list, some require subscription to
> prevent spams but not all do.
Yes. But not many people realize that the world they know is the
only world. We are used to an open list and are shocked when we
encouter a closed one; let's not forget that shock.
How about doing it like this?
README.md | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/README.md b/README.md
index f17af66a97..bbaf54bffb 100644
--- a/README.md
+++ b/README.md
@@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
mailing list -- everyone is welcome to post bug reports, feature
requests, comments and patches to git@vger.kernel.org (read
[Documentation/SubmittingPatches][] for instructions on patch submission).
+
+You can send messages without subscribing to the list, but it is
+recommended to read what other people are saying on the list before
+you speak.
To subscribe to the list, send an email with just "subscribe git" in
the body to majordomo@vger.kernel.org. The mailing list archives are
available at <https://public-inbox.org/git/>,
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 21:35 ` Junio C Hamano
@ 2017-06-22 21:58 ` Ævar Arnfjörð Bjarmason
2017-06-22 22:14 ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2017-06-22 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Ruderich, Patrick Lehmann, Jessie Hernandez, git
On Thu, Jun 22 2017, Junio C. Hamano jotted:
> Simon Ruderich <simon@ruderich.org> writes:
>
>> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>>> The description on https://github.com/git/git doesn't reflect that policy.
>>>
>>> a)
>>> It explains that discussions take place in the mentioned mailing list.
>>> b)
>>> It describes how to subscribe.
>>
>> However it doesn't say that you have to subscribe to send, only
>> how to subscribe.
>
> For that matter, we also say "everyone is welcome to post", which
> makes it clear that no subscription is required.
>
> But I view these merely being technically correct. And making it
> absolutely obvious does not cost too much.
>
>>> With knowledge of other mailing lists (mostly managed by mailman),
>>> subscription is required for participation.
>>
>> That depends on the mailing list, some require subscription to
>> prevent spams but not all do.
>
> Yes. But not many people realize that the world they know is the
> only world. We are used to an open list and are shocked when we
> encouter a closed one; let's not forget that shock.
>
> How about doing it like this?
>
> README.md | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/README.md b/README.md
> index f17af66a97..bbaf54bffb 100644
> --- a/README.md
> +++ b/README.md
> @@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
> mailing list -- everyone is welcome to post bug reports, feature
> requests, comments and patches to git@vger.kernel.org (read
> [Documentation/SubmittingPatches][] for instructions on patch submission).
> +
> +You can send messages without subscribing to the list, but it is
> +recommended to read what other people are saying on the list before
> +you speak.
> To subscribe to the list, send an email with just "subscribe git" in
> the body to majordomo@vger.kernel.org. The mailing list archives are
> available at <https://public-inbox.org/git/>,
It's unclear what that means. I *think* it means "consider taking a look
around the list before you post", but then it's probably better advice
to tell people to skim the archives first to get an idea of the traffic.
E.g. if I page through the first 2 pages of public-inbox.org I get
messages going back to the 19th, but if I were to subscribe to the list
I'd need to wait 4 days to get the same mail.
Which, in the context of what this follows (how to submit a bug,
questions etc.) isn't a good use of time for the person reading the
instructions.
Maybe something more like:
diff --git a/README.md b/README.md
index f17af66a97..dc175757fa 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
available at <https://public-inbox.org/git/>,
<http://marc.info/?l=git> and other archival sites.
+You don't need to be subscribed to the list to send mail to it, and
+others on-list will generally CC you when replying (although some
+forget this). It's adviced to subscribe to the list if you want to be
+sure you're not missing follow-up discussion, or if your interest in
+the project is wider than a one-off bug report, question or patch.
+
The maintainer frequently sends the "What's cooking" reports that
list the current status of various development topics to the mailing
list. The discussion following them give a good reference for
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2017-06-22 21:58 ` Ævar Arnfjörð Bjarmason
@ 2017-06-22 22:14 ` Junio C Hamano
2017-06-22 23:21 ` Jeff King
2017-06-23 6:58 ` demerphq
2 siblings, 0 replies; 669+ messages in thread
From: Junio C Hamano @ 2017-06-22 22:14 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Simon Ruderich, Patrick Lehmann, Jessie Hernandez, git
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Maybe something more like:
Much better.
> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
> available at <https://public-inbox.org/git/>,
> <http://marc.info/?l=git> and other archival sites.
>
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
> The maintainer frequently sends the "What's cooking" reports that
> list the current status of various development topics to the mailing
> list. The discussion following them give a good reference for
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 21:58 ` Ævar Arnfjörð Bjarmason
2017-06-22 22:14 ` Junio C Hamano
@ 2017-06-22 23:21 ` Jeff King
2017-06-23 5:23 ` Junio C Hamano
2017-06-23 6:58 ` demerphq
2 siblings, 1 reply; 669+ messages in thread
From: Jeff King @ 2017-06-22 23:21 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, Simon Ruderich, Patrick Lehmann, Jessie Hernandez, git
On Thu, Jun 22, 2017 at 11:58:08PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Which, in the context of what this follows (how to submit a bug,
> questions etc.) isn't a good use of time for the person reading the
> instructions.
>
> Maybe something more like:
>
> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
> available at <https://public-inbox.org/git/>,
> <http://marc.info/?l=git> and other archival sites.
>
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
> The maintainer frequently sends the "What's cooking" reports that
> list the current status of various development topics to the mailing
> list. The discussion following them give a good reference for
You perhaps already read it, but you may want to steal wording or
suggestions from the mailing list section at:
https://git-scm.com/community
which is covering the same ideas (and vice versa, patches to that page
are welcome if the README says something better).
-Peff
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 23:21 ` Jeff King
@ 2017-06-23 5:23 ` Junio C Hamano
2017-06-23 16:53 ` Jeff King
0 siblings, 1 reply; 669+ messages in thread
From: Junio C Hamano @ 2017-06-23 5:23 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð Bjarmason, Simon Ruderich,
Patrick Lehmann, Jessie Hernandez, git
Jeff King <peff@peff.net> writes:
>> +You don't need to be subscribed to the list to send mail to it, and
>> +others on-list will generally CC you when replying (although some
>> +forget this). It's adviced to subscribe to the list if you want to be
>> +sure you're not missing follow-up discussion, or if your interest in
>> +the project is wider than a one-off bug report, question or patch.
>> +
>> The maintainer frequently sends the "What's cooking" reports that
>> list the current status of various development topics to the mailing
>> list. The discussion following them give a good reference for
>
> You perhaps already read it, but you may want to steal wording or
> suggestions from the mailing list section at:
>
> https://git-scm.com/community
>
> which is covering the same ideas (and vice versa, patches to that page
> are welcome if the README says something better).
OK, so... Ævar's version does not mention:
- text/plain, which is a very good addition.
- note about CC in a way as useful as the "community" page does,
which may want to steal from the latter.
- the archive, but it may not be needed in the context of this
document. "Read the archive to make sure you are not repeating
somebody else said before speaking" is something we silently wish
everybody to follow, but it is something we do not want to say
out loud, especially to new people.
- Windows, but I am not sure if it is necessary or even healthy.
One thing I would rather not to see is the Windows mailing list
becomes the first line triage place for any and all issues that
were experienced by a user who happened to be using Windows, and
majority of the issues turn out to be unspecific to Windows. I'd
suspect that all of us rather would want to see the referral go
the other way around.
Otoh, "community" page does not encourage subscription as a way to
ensure you'll see follow-up discussion, which may be a good thing to
add.
A tangent I just found funny is this paragraph on the "community"
page:
The archive can be found on public-inbox. Click here to
subscribe.
Of course clicking does not take you to a subscription page for
public-inbox, even though the two sentences appear to be related.
Perhaps swap the order of the two, like so, with a bit richer
explanation taken from Ævar's version:
... disable HTML in your outgoing messages.
By subscribing (click here), you can make sure you're not
missing follow-up discussion and also learn from other
development in the community. The list archive can be found
on public-inbox.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2017-06-23 5:23 ` Junio C Hamano
@ 2017-06-23 16:53 ` Jeff King
2017-06-23 18:44 ` Junio C Hamano
0 siblings, 1 reply; 669+ messages in thread
From: Jeff King @ 2017-06-23 16:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Simon Ruderich,
Patrick Lehmann, Jessie Hernandez, git
On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:
> Otoh, "community" page does not encourage subscription as a way to
> ensure you'll see follow-up discussion, which may be a good thing to
> add.
>
> A tangent I just found funny is this paragraph on the "community"
> page:
>
> The archive can be found on public-inbox. Click here to
> subscribe.
>
> Of course clicking does not take you to a subscription page for
> public-inbox, even though the two sentences appear to be related.
>
> Perhaps swap the order of the two, like so, with a bit richer
> explanation taken from Ævar's version:
>
> ... disable HTML in your outgoing messages.
>
> By subscribing (click here), you can make sure you're not
> missing follow-up discussion and also learn from other
> development in the community. The list archive can be found
> on public-inbox.
Yeah, I think that's a good suggestion. Do you want to phrase it in the
form of a patch? :)
-Peff
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-23 16:53 ` Jeff King
@ 2017-06-23 18:44 ` Junio C Hamano
0 siblings, 0 replies; 669+ messages in thread
From: Junio C Hamano @ 2017-06-23 18:44 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð Bjarmason, Simon Ruderich,
Patrick Lehmann, Jessie Hernandez, git
Jeff King <peff@peff.net> writes:
> On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:
>
>> Otoh, "community" page does not encourage subscription as a way to
>> ensure you'll see follow-up discussion, which may be a good thing to
>> add.
>>
>> A tangent I just found funny is this paragraph on the "community"
>> page:
>>
>> The archive can be found on public-inbox. Click here to
>> subscribe.
>>
>> Of course clicking does not take you to a subscription page for
>> public-inbox, even though the two sentences appear to be related.
>>
>> Perhaps swap the order of the two, like so, with a bit richer
>> explanation taken from Ævar's version:
>>
>> ... disable HTML in your outgoing messages.
>>
>> By subscribing (click here), you can make sure you're not
>> missing follow-up discussion and also learn from other
>> development in the community. The list archive can be found
>> on public-inbox.
>
> Yeah, I think that's a good suggestion. Do you want to phrase it in the
> form of a patch? :)
OK. Letme try.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-06-22 21:58 ` Ævar Arnfjörð Bjarmason
2017-06-22 22:14 ` Junio C Hamano
2017-06-22 23:21 ` Jeff King
@ 2017-06-23 6:58 ` demerphq
2 siblings, 0 replies; 669+ messages in thread
From: demerphq @ 2017-06-23 6:58 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Junio C Hamano, Simon Ruderich, Patrick Lehmann, Jessie Hernandez, git
On 22 June 2017 at 23:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
FWIW: "adviced" is misspelled, it should be "advised", and IMO, it
feels like poor style to begin a sentence with a contraction. Not
strictly wrong, but sufficiently informal that I think it is out of
place in docs like this. Better to just say "It is", or even just "You
are", especially as you use "you" later in the sentence.
I actually think simplifying that sentence considerably is preferable:
"To be sure you receive all follow-up mails you should subscribe to the list."
flows better and is more succinct than
"It's advised to subscribe to the list if you want to be sure you're
not missing follow-up discussion".
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2017-06-04 11:59 Yury Norov
2017-06-14 20:16 ` Yury Norov
0 siblings, 1 reply; 669+ messages in thread
From: Yury Norov @ 2017-06-04 11:59 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel, linux-kernel, linux-doc,
Arnd Bergmann
Cc: Yury Norov, Andrew Pinski, Andrew Pinski, Adam Borowski,
Chris Metcalf, Steve Ellcey, Maxim Kuvyrkov,
Ramana Radhakrishnan, Florian Weimer, Bamvor Zhangjian,
Andreas Schwab, Chris Metcalf, Heiko Carstens, schwidefsky,
broonie, Joseph Myers, christoph.muellner, szabolcs.nagy,
klimov.linux, Nathan_Lynch, agraf, Prasun.Kapoor, geert,
philipp.tomsich, manuel.montezelo, linyongting, davem,
zhouchengming1
Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
Hi Catalin,
Here is a rebase of latest kernel patchset against next-20170602. There's almost
no changes, but there are some conflicts that are not trivial, and I'd like to
refresh the submission therefore.
How are your experiments with testing and benchmarking of ILP32 are going? In
my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
LMBench shows no difference for LP64 and expected performance boost for ILP32
(compared to LP64 results).
Steve Ellcey is handling upstream submission of Glibc patches. The patches are
ready and have been reviewed and reworked per community’s comments. There are
no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
on ILP32 kernel submission.
Catalin, regarding rootfs, is OpenSuSe’s build sufficient for your experiments?
I’ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
them to Debian.
One last thing I wanted to check with you about is ILP32 PCS - does, in your
view, ARM Ltd. needs to publish any additional docs for ABI to become official?
Below is the regular description.
Thanks.
Yury
--------
This series enables aarch64 with ilp32 mode.
As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t is is used by new userspace). Also it
deprecates getrlimit and setrlimit syscalls prior to prlimit64.
This version is based on linux-next from 2017-03-01. It works with
glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.
Patches 1, 2, 3 and 8 are general, and may be applied separately.
This is the rebase of v7 - still no major changes has been made.
Kernel and GLIBC trees:
https://github.com/norov/linux/tree/ilp32-20170602
https://github.com/norov/glibc/tree/dev9
(GLIBC patches are managed by Steve Ellcey, so my tree is only for
reference.)
Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
v7: https://lkml.org/lkml/2017/1/9/213
v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
v7: Resend 2:
- vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
- rebased on next-20170602.
Andrew Pinski (6):
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: ensure the kernel is compiled for LP64
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64: ilp32: introduce ilp32-specific handlers for sigframe and
ucontext
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (13):
compat ABI: use non-compat openat and open_by_handle_at variants
32-bit ABI: introduce ARCH_32BIT_OFF_T config option
asm-generic: Drop getrlimit and setrlimit syscalls from default list
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
thread: move thread bits accessors to separated file
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ilp32: share aarch32 syscall handlers
arm64: signal: share lp64 signal routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
Documentation/arm64/ilp32.txt | 45 +++++++
arch/Kconfig | 4 +
arch/arc/Kconfig | 1 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 19 ++-
arch/arm64/Makefile | 8 ++
arch/arm64/include/asm/compat.h | 19 +--
arch/arm64/include/asm/elf.h | 37 ++----
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/include/asm/hwcap.h | 6 +-
arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/include/asm/processor.h | 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/seccomp.h | 2 +-
arch/arm64/include/asm/signal32.h | 9 +-
arch/arm64/include/asm/signal32_common.h | 27 ++++
arch/arm64/include/asm/signal_common.h | 33 +++++
arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 6 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/unistd.h | 13 ++
arch/arm64/kernel/Makefile | 8 +-
arch/arm64/kernel/asm-offsets.c | 9 +-
arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
arch/arm64/kernel/cpufeature.c | 8 +-
arch/arm64/kernel/cpuinfo.c | 20 +--
arch/arm64/kernel/entry.S | 34 +++++-
arch/arm64/kernel/entry32.S | 80 ------------
arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
arch/arm64/kernel/entry_ilp32.S | 22 ++++
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 8 +-
arch/arm64/kernel/perf_regs.c | 2 +-
arch/arm64/kernel/process.c | 7 +-
arch/arm64/kernel/ptrace.c | 80 ++++++++++--
arch/arm64/kernel/signal.c | 102 ++++++++++------
arch/arm64/kernel/signal32.c | 107 ----------------
arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
arch/arm64/kernel/traps.c | 5 +-
arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
arch/arm64/kernel/vdso.c | 69 +++++++++--
arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
arch/arm64/kernel/vdso/vdso.S | 6 +-
arch/blackfin/Kconfig | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/cris/Kconfig | 1 +
arch/frv/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/Kconfig | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/m32r/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/metag/Kconfig | 1 +
arch/metag/include/uapi/asm/unistd.h | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/Kconfig | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/score/Kconfig | 1 +
arch/score/include/uapi/asm/unistd.h | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/tile/Kconfig | 1 +
arch/tile/include/uapi/asm/unistd.h | 1 +
arch/tile/kernel/compat.c | 3 +
arch/unicore32/Kconfig | 1 +
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/um/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 2 +-
include/linux/fcntl.h | 2 +-
include/linux/thread_bits.h | 63 ++++++++++
include/linux/thread_info.h | 66 ++--------
include/uapi/asm-generic/unistd.h | 10 +-
93 files changed, 1601 insertions(+), 413 deletions(-)
create mode 100644 Documentation/arm64/ilp32.txt
create mode 100644 arch/arm64/include/asm/is_compat.h
create mode 100644 arch/arm64/include/asm/signal32_common.h
create mode 100644 arch/arm64/include/asm/signal_common.h
create mode 100644 arch/arm64/include/asm/signal_ilp32.h
create mode 100644 arch/arm64/kernel/binfmt_elf32.c
create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
create mode 100644 arch/arm64/kernel/entry32_common.S
create mode 100644 arch/arm64/kernel/entry_ilp32.S
create mode 100644 arch/arm64/kernel/signal32_common.c
create mode 100644 arch/arm64/kernel/signal_ilp32.c
create mode 100644 arch/arm64/kernel/sys_ilp32.c
create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
create mode 100644 include/linux/thread_bits.h
--
2.11.0
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2017-06-04 11:59 Yury Norov
@ 2017-06-14 20:16 ` Yury Norov
0 siblings, 0 replies; 669+ messages in thread
From: Yury Norov @ 2017-06-14 20:16 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel, linux-kernel, linux-doc,
Arnd Bergmann
Cc: Andrew Pinski, Andrew Pinski, Adam Borowski, Chris Metcalf,
Steve Ellcey, Maxim Kuvyrkov, Ramana Radhakrishnan,
Florian Weimer, Bamvor Zhangjian, Andreas Schwab, Chris Metcalf,
Heiko Carstens, schwidefsky, broonie, Joseph Myers,
christoph.muellner, szabolcs.nagy, klimov.linux, Nathan_Lynch,
agraf, Prasun.Kapoor, geert, philipp.tomsich, manuel.montezelo,
linyongting, davem, zhouchengming1
Hi Catalin, all.
Thank you for your time on reviewing the series. I really appreciate it.
This is the updated version where I tried to address all comments:
https://github.com/norov/linux/commits/ilp32-20170613.4
(3 last patches here is the Andrew Pinski's rework of vdso rebased on
ilp32 series)
If nothing will come here on review, I'll send v8 at the beginning of
the next week. Is this plan OK?
And this is the backport on the v4.11 kernel:
https://github.com/norov/linux/commits/ilp32-4.11.4
Yury
On Sun, Jun 04, 2017 at 02:59:49PM +0300, Yury Norov wrote:
> Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
>
> Hi Catalin,
>
> Here is a rebase of latest kernel patchset against next-20170602. There's almost
> no changes, but there are some conflicts that are not trivial, and I'd like to
> refresh the submission therefore.
>
> How are your experiments with testing and benchmarking of ILP32 are going? In
> my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
> LMBench shows no difference for LP64 and expected performance boost for ILP32
> (compared to LP64 results).
>
> Steve Ellcey is handling upstream submission of Glibc patches. The patches are
> ready and have been reviewed and reworked per community’s comments. There are
> no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
> on ILP32 kernel submission.
>
> Catalin, regarding rootfs, is OpenSuSe’s build sufficient for your experiments?
> I’ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
> them to Debian.
>
> One last thing I wanted to check with you about is ILP32 PCS - does, in your
> view, ARM Ltd. needs to publish any additional docs for ABI to become official?
>
> Below is the regular description.
>
> Thanks.
> Yury
>
> --------
>
> This series enables aarch64 with ilp32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t is is used by new userspace). Also it
> deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> This version is based on linux-next from 2017-03-01. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
>
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>
> This is the rebase of v7 - still no major changes has been made.
>
> Kernel and GLIBC trees:
> https://github.com/norov/linux/tree/ilp32-20170602
> https://github.com/norov/glibc/tree/dev9
>
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
>
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
> v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
> v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
> v7: https://lkml.org/lkml/2017/1/9/213
> v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
> v7: Resend 2:
> - vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
> - rebased on next-20170602.
>
> Andrew Pinski (6):
> arm64: rename COMPAT to AARCH32_EL0 in Kconfig
> arm64: ensure the kernel is compiled for LP64
> arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
> arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
> arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
> arm64:ilp32: add ARM64_ILP32 to Kconfig
>
> Philipp Tomsich (1):
> arm64:ilp32: add vdso-ilp32 and use for signal return
>
> Yury Norov (13):
> compat ABI: use non-compat openat and open_by_handle_at variants
> 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
> asm-generic: Drop getrlimit and setrlimit syscalls from default list
> arm64: ilp32: add documentation on the ILP32 ABI for ARM64
> thread: move thread bits accessors to separated file
> arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
> arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
> arm64: introduce binfmt_elf32.c
> arm64: ilp32: introduce binfmt_ilp32.c
> arm64: ilp32: share aarch32 syscall handlers
> arm64: signal: share lp64 signal routines to ilp32
> arm64: signal32: move ilp32 and aarch32 common code to separated file
> arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>
> Documentation/arm64/ilp32.txt | 45 +++++++
> arch/Kconfig | 4 +
> arch/arc/Kconfig | 1 +
> arch/arc/include/uapi/asm/unistd.h | 1 +
> arch/arm/Kconfig | 1 +
> arch/arm64/Kconfig | 19 ++-
> arch/arm64/Makefile | 8 ++
> arch/arm64/include/asm/compat.h | 19 +--
> arch/arm64/include/asm/elf.h | 37 ++----
> arch/arm64/include/asm/fpsimd.h | 2 +-
> arch/arm64/include/asm/ftrace.h | 2 +-
> arch/arm64/include/asm/hwcap.h | 6 +-
> arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
> arch/arm64/include/asm/memory.h | 5 +-
> arch/arm64/include/asm/processor.h | 11 +-
> arch/arm64/include/asm/ptrace.h | 2 +-
> arch/arm64/include/asm/seccomp.h | 2 +-
> arch/arm64/include/asm/signal32.h | 9 +-
> arch/arm64/include/asm/signal32_common.h | 27 ++++
> arch/arm64/include/asm/signal_common.h | 33 +++++
> arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
> arch/arm64/include/asm/syscall.h | 2 +-
> arch/arm64/include/asm/thread_info.h | 4 +-
> arch/arm64/include/asm/unistd.h | 6 +-
> arch/arm64/include/asm/vdso.h | 6 +
> arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
> arch/arm64/include/uapi/asm/unistd.h | 13 ++
> arch/arm64/kernel/Makefile | 8 +-
> arch/arm64/kernel/asm-offsets.c | 9 +-
> arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
> arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
> arch/arm64/kernel/cpufeature.c | 8 +-
> arch/arm64/kernel/cpuinfo.c | 20 +--
> arch/arm64/kernel/entry.S | 34 +++++-
> arch/arm64/kernel/entry32.S | 80 ------------
> arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
> arch/arm64/kernel/entry_ilp32.S | 22 ++++
> arch/arm64/kernel/head.S | 2 +-
> arch/arm64/kernel/hw_breakpoint.c | 8 +-
> arch/arm64/kernel/perf_regs.c | 2 +-
> arch/arm64/kernel/process.c | 7 +-
> arch/arm64/kernel/ptrace.c | 80 ++++++++++--
> arch/arm64/kernel/signal.c | 102 ++++++++++------
> arch/arm64/kernel/signal32.c | 107 ----------------
> arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
> arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
> arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
> arch/arm64/kernel/traps.c | 5 +-
> arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
> arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
> arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
> arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
> arch/arm64/kernel/vdso.c | 69 +++++++++--
> arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
> arch/arm64/kernel/vdso/vdso.S | 6 +-
> arch/blackfin/Kconfig | 1 +
> arch/c6x/include/uapi/asm/unistd.h | 1 +
> arch/cris/Kconfig | 1 +
> arch/frv/Kconfig | 1 +
> arch/h8300/Kconfig | 1 +
> arch/h8300/include/uapi/asm/unistd.h | 1 +
> arch/hexagon/Kconfig | 1 +
> arch/hexagon/include/uapi/asm/unistd.h | 1 +
> arch/m32r/Kconfig | 1 +
> arch/m68k/Kconfig | 1 +
> arch/metag/Kconfig | 1 +
> arch/metag/include/uapi/asm/unistd.h | 1 +
> arch/microblaze/Kconfig | 1 +
> arch/mips/Kconfig | 1 +
> arch/mn10300/Kconfig | 1 +
> arch/nios2/Kconfig | 1 +
> arch/nios2/include/uapi/asm/unistd.h | 1 +
> arch/openrisc/Kconfig | 1 +
> arch/openrisc/include/uapi/asm/unistd.h | 1 +
> arch/parisc/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/score/Kconfig | 1 +
> arch/score/include/uapi/asm/unistd.h | 1 +
> arch/sh/Kconfig | 1 +
> arch/sparc/Kconfig | 1 +
> arch/tile/Kconfig | 1 +
> arch/tile/include/uapi/asm/unistd.h | 1 +
> arch/tile/kernel/compat.c | 3 +
> arch/unicore32/Kconfig | 1 +
> arch/unicore32/include/uapi/asm/unistd.h | 1 +
> arch/x86/Kconfig | 1 +
> arch/x86/um/Kconfig | 1 +
> arch/xtensa/Kconfig | 1 +
> drivers/clocksource/arm_arch_timer.c | 2 +-
> include/linux/fcntl.h | 2 +-
> include/linux/thread_bits.h | 63 ++++++++++
> include/linux/thread_info.h | 66 ++--------
> include/uapi/asm-generic/unistd.h | 10 +-
> 93 files changed, 1601 insertions(+), 413 deletions(-)
> create mode 100644 Documentation/arm64/ilp32.txt
> create mode 100644 arch/arm64/include/asm/is_compat.h
> create mode 100644 arch/arm64/include/asm/signal32_common.h
> create mode 100644 arch/arm64/include/asm/signal_common.h
> create mode 100644 arch/arm64/include/asm/signal_ilp32.h
> create mode 100644 arch/arm64/kernel/binfmt_elf32.c
> create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
> create mode 100644 arch/arm64/kernel/entry32_common.S
> create mode 100644 arch/arm64/kernel/entry_ilp32.S
> create mode 100644 arch/arm64/kernel/signal32_common.c
> create mode 100644 arch/arm64/kernel/signal_ilp32.c
> create mode 100644 arch/arm64/kernel/sys_ilp32.c
> create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
> create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
> create mode 100644 include/linux/thread_bits.h
>
> --
> 2.11.0
^ permalink raw reply [flat|nested] 669+ messages in thread* your mail
@ 2017-06-14 20:16 ` Yury Norov
0 siblings, 0 replies; 669+ messages in thread
From: Yury Norov @ 2017-06-14 20:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin, all.
Thank you for your time on reviewing the series. I really appreciate it.
This is the updated version where I tried to address all comments:
https://github.com/norov/linux/commits/ilp32-20170613.4
(3 last patches here is the Andrew Pinski's rework of vdso rebased on
ilp32 series)
If nothing will come here on review, I'll send v8 at the beginning of
the next week. Is this plan OK?
And this is the backport on the v4.11 kernel:
https://github.com/norov/linux/commits/ilp32-4.11.4
Yury
On Sun, Jun 04, 2017 at 02:59:49PM +0300, Yury Norov wrote:
> Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
>
> Hi Catalin,
>
> Here is a rebase of latest kernel patchset against next-20170602. There's almost
> no changes, but there are some conflicts that are not trivial, and I'd like to
> refresh the submission therefore.
>
> How are your experiments with testing and benchmarking of ILP32 are going? In
> my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
> LMBench shows no difference for LP64 and expected performance boost for ILP32
> (compared to LP64 results).
>
> Steve Ellcey is handling upstream submission of Glibc patches. The patches are
> ready and have been reviewed and reworked per community?s comments. There are
> no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
> on ILP32 kernel submission.
>
> Catalin, regarding rootfs, is OpenSuSe?s build sufficient for your experiments?
> I?ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
> them to Debian.
>
> One last thing I wanted to check with you about is ILP32 PCS - does, in your
> view, ARM Ltd. needs to publish any additional docs for ABI to become official?
>
> Below is the regular description.
>
> Thanks.
> Yury
>
> --------
>
> This series enables aarch64 with ilp32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t is is used by new userspace). Also it
> deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> This version is based on linux-next from 2017-03-01. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
>
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>
> This is the rebase of v7 - still no major changes has been made.
>
> Kernel and GLIBC trees:
> https://github.com/norov/linux/tree/ilp32-20170602
> https://github.com/norov/glibc/tree/dev9
>
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
>
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
> v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
> v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
> v7: https://lkml.org/lkml/2017/1/9/213
> v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
> v7: Resend 2:
> - vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
> - rebased on next-20170602.
>
> Andrew Pinski (6):
> arm64: rename COMPAT to AARCH32_EL0 in Kconfig
> arm64: ensure the kernel is compiled for LP64
> arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
> arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
> arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
> arm64:ilp32: add ARM64_ILP32 to Kconfig
>
> Philipp Tomsich (1):
> arm64:ilp32: add vdso-ilp32 and use for signal return
>
> Yury Norov (13):
> compat ABI: use non-compat openat and open_by_handle_at variants
> 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
> asm-generic: Drop getrlimit and setrlimit syscalls from default list
> arm64: ilp32: add documentation on the ILP32 ABI for ARM64
> thread: move thread bits accessors to separated file
> arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
> arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
> arm64: introduce binfmt_elf32.c
> arm64: ilp32: introduce binfmt_ilp32.c
> arm64: ilp32: share aarch32 syscall handlers
> arm64: signal: share lp64 signal routines to ilp32
> arm64: signal32: move ilp32 and aarch32 common code to separated file
> arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>
> Documentation/arm64/ilp32.txt | 45 +++++++
> arch/Kconfig | 4 +
> arch/arc/Kconfig | 1 +
> arch/arc/include/uapi/asm/unistd.h | 1 +
> arch/arm/Kconfig | 1 +
> arch/arm64/Kconfig | 19 ++-
> arch/arm64/Makefile | 8 ++
> arch/arm64/include/asm/compat.h | 19 +--
> arch/arm64/include/asm/elf.h | 37 ++----
> arch/arm64/include/asm/fpsimd.h | 2 +-
> arch/arm64/include/asm/ftrace.h | 2 +-
> arch/arm64/include/asm/hwcap.h | 6 +-
> arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
> arch/arm64/include/asm/memory.h | 5 +-
> arch/arm64/include/asm/processor.h | 11 +-
> arch/arm64/include/asm/ptrace.h | 2 +-
> arch/arm64/include/asm/seccomp.h | 2 +-
> arch/arm64/include/asm/signal32.h | 9 +-
> arch/arm64/include/asm/signal32_common.h | 27 ++++
> arch/arm64/include/asm/signal_common.h | 33 +++++
> arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
> arch/arm64/include/asm/syscall.h | 2 +-
> arch/arm64/include/asm/thread_info.h | 4 +-
> arch/arm64/include/asm/unistd.h | 6 +-
> arch/arm64/include/asm/vdso.h | 6 +
> arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
> arch/arm64/include/uapi/asm/unistd.h | 13 ++
> arch/arm64/kernel/Makefile | 8 +-
> arch/arm64/kernel/asm-offsets.c | 9 +-
> arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
> arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
> arch/arm64/kernel/cpufeature.c | 8 +-
> arch/arm64/kernel/cpuinfo.c | 20 +--
> arch/arm64/kernel/entry.S | 34 +++++-
> arch/arm64/kernel/entry32.S | 80 ------------
> arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
> arch/arm64/kernel/entry_ilp32.S | 22 ++++
> arch/arm64/kernel/head.S | 2 +-
> arch/arm64/kernel/hw_breakpoint.c | 8 +-
> arch/arm64/kernel/perf_regs.c | 2 +-
> arch/arm64/kernel/process.c | 7 +-
> arch/arm64/kernel/ptrace.c | 80 ++++++++++--
> arch/arm64/kernel/signal.c | 102 ++++++++++------
> arch/arm64/kernel/signal32.c | 107 ----------------
> arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
> arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
> arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
> arch/arm64/kernel/traps.c | 5 +-
> arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
> arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
> arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
> arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
> arch/arm64/kernel/vdso.c | 69 +++++++++--
> arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
> arch/arm64/kernel/vdso/vdso.S | 6 +-
> arch/blackfin/Kconfig | 1 +
> arch/c6x/include/uapi/asm/unistd.h | 1 +
> arch/cris/Kconfig | 1 +
> arch/frv/Kconfig | 1 +
> arch/h8300/Kconfig | 1 +
> arch/h8300/include/uapi/asm/unistd.h | 1 +
> arch/hexagon/Kconfig | 1 +
> arch/hexagon/include/uapi/asm/unistd.h | 1 +
> arch/m32r/Kconfig | 1 +
> arch/m68k/Kconfig | 1 +
> arch/metag/Kconfig | 1 +
> arch/metag/include/uapi/asm/unistd.h | 1 +
> arch/microblaze/Kconfig | 1 +
> arch/mips/Kconfig | 1 +
> arch/mn10300/Kconfig | 1 +
> arch/nios2/Kconfig | 1 +
> arch/nios2/include/uapi/asm/unistd.h | 1 +
> arch/openrisc/Kconfig | 1 +
> arch/openrisc/include/uapi/asm/unistd.h | 1 +
> arch/parisc/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/score/Kconfig | 1 +
> arch/score/include/uapi/asm/unistd.h | 1 +
> arch/sh/Kconfig | 1 +
> arch/sparc/Kconfig | 1 +
> arch/tile/Kconfig | 1 +
> arch/tile/include/uapi/asm/unistd.h | 1 +
> arch/tile/kernel/compat.c | 3 +
> arch/unicore32/Kconfig | 1 +
> arch/unicore32/include/uapi/asm/unistd.h | 1 +
> arch/x86/Kconfig | 1 +
> arch/x86/um/Kconfig | 1 +
> arch/xtensa/Kconfig | 1 +
> drivers/clocksource/arm_arch_timer.c | 2 +-
> include/linux/fcntl.h | 2 +-
> include/linux/thread_bits.h | 63 ++++++++++
> include/linux/thread_info.h | 66 ++--------
> include/uapi/asm-generic/unistd.h | 10 +-
> 93 files changed, 1601 insertions(+), 413 deletions(-)
> create mode 100644 Documentation/arm64/ilp32.txt
> create mode 100644 arch/arm64/include/asm/is_compat.h
> create mode 100644 arch/arm64/include/asm/signal32_common.h
> create mode 100644 arch/arm64/include/asm/signal_common.h
> create mode 100644 arch/arm64/include/asm/signal_ilp32.h
> create mode 100644 arch/arm64/kernel/binfmt_elf32.c
> create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
> create mode 100644 arch/arm64/kernel/entry32_common.S
> create mode 100644 arch/arm64/kernel/entry_ilp32.S
> create mode 100644 arch/arm64/kernel/signal32_common.c
> create mode 100644 arch/arm64/kernel/signal_ilp32.c
> create mode 100644 arch/arm64/kernel/sys_ilp32.c
> create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
> create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
> create mode 100644 include/linux/thread_bits.h
>
> --
> 2.11.0
^ permalink raw reply [flat|nested] 669+ messages in thread
* [PATCH -v2 0/9] mm: make movable onlining suck less
@ 2017-04-10 11:03 Michal Hocko
2017-04-15 12:17 ` Michal Hocko
0 siblings, 1 reply; 669+ messages in thread
From: Michal Hocko @ 2017-04-10 11:03 UTC (permalink / raw)
To: linux-mm
Cc: Andrew Morton, Mel Gorman, Vlastimil Babka, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Joonsoo Kim, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML,
Dan Williams, Heiko Carstens, Lai Jiangshan, Martin Schwidefsky,
Michal Hocko, Tobias Regnery
Hi,
The last version of this series has been posted here [1]. It has seen
some more serious testing (thanks to Reza Arbab) and fixes for the found
issues. I have also decided to drop patch 1 [2] because it turned out to
be more complicated than I initially thought [3]. Few more patches were
added to deal with expectation on zone/node initialization.
I have rebased on top of the current mmotm-2017-04-07-15-53. It
conflicts with HMM because it touches memory hotplug as
well. We have discussed [4] with Jérôme and he agreed to
rebase on top of this rework [5] so I have reverted his series
before applyig mine. I will help him to resolve the resulting
conflicts. You can find the whole series including the HMM revers in
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git branch
attempts/rewrite-mem_hotplug
Motivation:
Movable onlining is a real hack with many downsides - mainly
reintroduction of lowmem/highmem issues we used to have on 32b systems -
but it is the only way to make the memory hotremove more reliable which
is something that people are asking for.
The current semantic of memory movable onlinening is really cumbersome,
however. The main reason for this is that the udev driven approach is
basically unusable because udev races with the memory probing while only
the last memory block or the one adjacent to the existing zone_movable
are allowed to be onlined movable. In short the criterion for the
successful online_movable changes under udev's feet. A reliable udev
approach would require a 2 phase approach where the first successful
movable online would have to check all the previous blocks and online
them in descending order. This is hard to be considered sane.
This patchset aims at making the onlining semantic more usable. First of
all it allows to online memory movable as long as it doesn't clash with
the existing ZONE_NORMAL. That means that ZONE_NORMAL and ZONE_MOVABLE
cannot overlap. Currently I preserve the original ordering semantic so
the zone always precedes the movable zone but I have plans to remove this
restriction in future because it is not really necessary.
First 3 patches are cleanups which should be ready to be merged right
away (unless I have missed something subtle of course).
Patch 4 deals with ZONE_DEVICE dependencies down the __add_pages path.
Patch 5 deals with implicit assumptions of register_one_node on pgdat
initialization.
Patch 6 is the core of the change. In order to make it easier to review
I have tried it to be as minimalistic as possible and the large code
removal is moved to patch 9.
Patch 7 is a trivial follow up cleanup. Patch 8 fixes sparse warnings
and finally patch 9 removes the unused code.
I have tested the patches in kvm:
# qemu-system-x86_64 -enable-kvm -monitor pty -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G ...
and then probed the additional memory by
(qemu) object_add memory-backend-ram,id=mem1,size=1G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Then I have used this simple script to probe the memory block by hand
# cat probe_memblock.sh
#!/bin/sh
BLOCK_NR=$1
# echo $((0x100000000+$BLOCK_NR*(128<<20))) > /sys/devices/system/memory/probe
# for i in $(seq 10); do sh probe_memblock.sh $i; done
# grep . /sys/devices/system/memory/memory3?/valid_zones 2>/dev/null
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Normal Movable
/sys/devices/system/memory/memory35/valid_zones:Normal Movable
/sys/devices/system/memory/memory36/valid_zones:Normal Movable
/sys/devices/system/memory/memory37/valid_zones:Normal Movable
/sys/devices/system/memory/memory38/valid_zones:Normal Movable
/sys/devices/system/memory/memory39/valid_zones:Normal Movable
The main difference to the original implementation is that all new
memblocks can be both online_kernel and online_movable initially
because there is no clash obviously. For the comparison the original
implementation would have
/sys/devices/system/memory/memory33/valid_zones:Normal
/sys/devices/system/memory/memory34/valid_zones:Normal
/sys/devices/system/memory/memory35/valid_zones:Normal
/sys/devices/system/memory/memory36/valid_zones:Normal
/sys/devices/system/memory/memory37/valid_zones:Normal
/sys/devices/system/memory/memory38/valid_zones:Normal
/sys/devices/system/memory/memory39/valid_zones:Normal Movable
Now
# echo online_movable > /sys/devices/system/memory/memory34/state
# grep . /sys/devices/system/memory/memory3?/valid_zones 2>/dev/null
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable
/sys/devices/system/memory/memory35/valid_zones:Movable
/sys/devices/system/memory/memory36/valid_zones:Movable
/sys/devices/system/memory/memory37/valid_zones:Movable
/sys/devices/system/memory/memory38/valid_zones:Movable
/sys/devices/system/memory/memory39/valid_zones:Movable
Block 33 can still be online both kernel and movable while all
the remaining can be only movable.
/proc/zonelist says
Node 0, zone Normal
pages free 0
min 0
low 0
high 0
spanned 0
present 0
--
Node 0, zone Movable
pages free 32753
min 85
low 117
high 149
spanned 32768
present 32768
A new memblock at a lower address will result in a new memblock (32)
which will still allow both Normal and Movable.
# sh probe_memblock.sh 0
# grep . /sys/devices/system/memory/memory3[2-5]/valid_zones 2>/dev/null
/sys/devices/system/memory/memory32/valid_zones:Normal Movable
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable
/sys/devices/system/memory/memory35/valid_zones:Movable
and online_kernel will convert it to the zone normal properly
while 33 can be still onlined both ways.
# echo online_kernel > /sys/devices/system/memory/memory32/state
# grep . /sys/devices/system/memory/memory3[2-5]/valid_zones 2>/dev/null
/sys/devices/system/memory/memory32/valid_zones:Normal
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable
/sys/devices/system/memory/memory35/valid_zones:Movable
/proc/zoneinfo will now tell
Node 0, zone Normal
pages free 65441
min 165
low 230
high 295
spanned 65536
present 65536
--
Node 0, zone Movable
pages free 32740
min 82
low 114
high 146
spanned 32768
present 32768
so both zones have one memblock spanned and present.
Onlining 39 should associate this block to the movable zone
# echo online > /sys/devices/system/memory/memory39/state
/proc/zoneinfo will now tell
Node 0, zone Normal
pages free 32765
min 80
low 112
high 144
spanned 32768
present 32768
--
Node 0, zone Movable
pages free 65501
min 160
low 225
high 290
spanned 196608
present 65536
so we will have a movable zone which spans 6 memblocks, 2 present and 4
representing a hole.
Offlining both movable blocks will lead to the zone with no present
pages which is the expected behavior I believe.
# echo offline > /sys/devices/system/memory/memory39/state
# echo offline > /sys/devices/system/memory/memory34/state
# grep -A6 "Movable\|Normal" /proc/zoneinfo
Node 0, zone Normal
pages free 32735
min 90
low 122
high 154
spanned 32768
present 32768
--
Node 0, zone Movable
pages free 0
min 0
low 0
high 0
spanned 196608
present 0
Any thoughts, complains, suggestions?
As a bonus we will get a nice cleanup in the memory hotplug codebase
arch/ia64/mm/init.c | 11 +-
arch/powerpc/mm/mem.c | 12 +-
arch/s390/mm/init.c | 32 +--
arch/sh/mm/init.c | 10 +-
arch/x86/mm/init_32.c | 7 +-
arch/x86/mm/init_64.c | 11 +-
drivers/base/memory.c | 74 ++++---
drivers/base/node.c | 58 ++----
include/linux/memory_hotplug.h | 19 +-
include/linux/mmzone.h | 16 +-
include/linux/node.h | 35 +++-
kernel/memremap.c | 6 +-
mm/memory_hotplug.c | 451 ++++++++++++++---------------------------
mm/page_alloc.c | 8 +-
mm/sparse.c | 3 +-
15 files changed, 284 insertions(+), 469 deletions(-)
Shortlog says:
Michal Hocko (9):
mm: remove return value from init_currently_empty_zone
mm, memory_hotplug: use node instead of zone in can_online_high_movable
mm: drop page_initialized check from get_nid_for_pfn
mm, memory_hotplug: get rid of is_zone_device_section
mm, memory_hotplug: split up register_one_node
mm, memory_hotplug: do not associate hotadded memory to zones until online
mm, memory_hotplug: replace for_device by want_memblock in arch_add_memory
mm, memory_hotplug: fix the section mismatch warning
mm, memory_hotplug: remove unused cruft after memory hotplug rework
[1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
[2] http://lkml.kernel.org/r/20170331073954.GF27098@dhcp22.suse.cz
[3] http://lkml.kernel.org/r/20170405081400.GE6035@dhcp22.suse.cz
[4] http://lkml.kernel.org/r/20170407121349.GB16392@dhcp22.suse.cz
[5] http://lkml.kernel.org/r/20170407182752.GA17852@redhat.com
^ permalink raw reply [flat|nested] 669+ messages in thread* (no subject)
2017-04-10 11:03 [PATCH -v2 0/9] mm: make movable onlining suck less Michal Hocko
@ 2017-04-15 12:17 ` Michal Hocko
2017-04-17 5:47 ` Joonsoo Kim
0 siblings, 1 reply; 669+ messages in thread
From: Michal Hocko @ 2017-04-15 12:17 UTC (permalink / raw)
To: linux-mm
Cc: Andrew Morton, Mel Gorman, Vlastimil Babka, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Joonsoo Kim, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
Hi,
here I 3 more preparatory patches which I meant to send on Thursday but
forgot... After more thinking about pfn walkers I have realized that
the current code doesn't check offline holes in zones. From a quick
review that doesn't seem to be a problem currently. Pfn walkers can race
with memory offlining and with the original hotplug impementation those
offline pages can change the zone but I wasn't able to find any serious
problem other than small confusion. The new hotplug code, will not have
any valid zone, though so those code paths should check PageReserved
to rule offline holes. I hope I have addressed all of them in these 3
patches. I would appreciate if Vlastimil and Jonsoo double check after
me.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-15 12:17 ` Michal Hocko
@ 2017-04-17 5:47 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-17 5:47 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> Hi,
> here I 3 more preparatory patches which I meant to send on Thursday but
> forgot... After more thinking about pfn walkers I have realized that
> the current code doesn't check offline holes in zones. From a quick
> review that doesn't seem to be a problem currently. Pfn walkers can race
> with memory offlining and with the original hotplug impementation those
> offline pages can change the zone but I wasn't able to find any serious
> problem other than small confusion. The new hotplug code, will not have
> any valid zone, though so those code paths should check PageReserved
> to rule offline holes. I hope I have addressed all of them in these 3
> patches. I would appreciate if Vlastimil and Jonsoo double check after
> me.
Hello, Michal.
s/Jonsoo/Joonsoo. :)
I'm not sure that it's a good idea to add PageResereved() check in pfn
walkers. First, this makes struct page validity check as two steps,
pfn_valid() and then PageResereved(). If we should not use struct page
in this case, it's better to pfn_valid() returns false rather than
adding a separate check. Anyway, we need to fix more places (all pfn
walker?) if we want to check validity by two steps.
The other problem I found is that your change will makes some
contiguous zones to be considered as non-contiguous. Memory allocated
by memblock API is also marked as PageResereved. If we consider this as
a hole, we will set such a zone as non-contiguous.
And, I guess that it's not enough to check PageResereved() in
pageblock_pfn_to_page() in order to skip these pages in compaction. If
holes are in the middle of the pageblock, pageblock_pfn_to_page()
cannot catch it and compaction will use struct page for this hole.
Therefore, I think that making pfn_valid() return false for not
onlined memory is a better solution for this problem. I don't know the
implementation detail for hotplug and I don't see your recent change
but we may defer memmap initialization until the zone is determined.
It will make pfn_valid() return false for un-initialized range.
Thanks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-17 5:47 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-17 5:47 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> Hi,
> here I 3 more preparatory patches which I meant to send on Thursday but
> forgot... After more thinking about pfn walkers I have realized that
> the current code doesn't check offline holes in zones. From a quick
> review that doesn't seem to be a problem currently. Pfn walkers can race
> with memory offlining and with the original hotplug impementation those
> offline pages can change the zone but I wasn't able to find any serious
> problem other than small confusion. The new hotplug code, will not have
> any valid zone, though so those code paths should check PageReserved
> to rule offline holes. I hope I have addressed all of them in these 3
> patches. I would appreciate if Vlastimil and Jonsoo double check after
> me.
Hello, Michal.
s/Jonsoo/Joonsoo. :)
I'm not sure that it's a good idea to add PageResereved() check in pfn
walkers. First, this makes struct page validity check as two steps,
pfn_valid() and then PageResereved(). If we should not use struct page
in this case, it's better to pfn_valid() returns false rather than
adding a separate check. Anyway, we need to fix more places (all pfn
walker?) if we want to check validity by two steps.
The other problem I found is that your change will makes some
contiguous zones to be considered as non-contiguous. Memory allocated
by memblock API is also marked as PageResereved. If we consider this as
a hole, we will set such a zone as non-contiguous.
And, I guess that it's not enough to check PageResereved() in
pageblock_pfn_to_page() in order to skip these pages in compaction. If
holes are in the middle of the pageblock, pageblock_pfn_to_page()
cannot catch it and compaction will use struct page for this hole.
Therefore, I think that making pfn_valid() return false for not
onlined memory is a better solution for this problem. I don't know the
implementation detail for hotplug and I don't see your recent change
but we may defer memmap initialization until the zone is determined.
It will make pfn_valid() return false for un-initialized range.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-17 5:47 ` Joonsoo Kim
@ 2017-04-17 8:15 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-17 8:15 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon 17-04-17 14:47:20, Joonsoo Kim wrote:
> On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> > Hi,
> > here I 3 more preparatory patches which I meant to send on Thursday but
> > forgot... After more thinking about pfn walkers I have realized that
> > the current code doesn't check offline holes in zones. From a quick
> > review that doesn't seem to be a problem currently. Pfn walkers can race
> > with memory offlining and with the original hotplug impementation those
> > offline pages can change the zone but I wasn't able to find any serious
> > problem other than small confusion. The new hotplug code, will not have
> > any valid zone, though so those code paths should check PageReserved
> > to rule offline holes. I hope I have addressed all of them in these 3
> > patches. I would appreciate if Vlastimil and Jonsoo double check after
> > me.
>
> Hello, Michal.
>
> s/Jonsoo/Joonsoo. :)
ups, sorry about that.
> I'm not sure that it's a good idea to add PageResereved() check in pfn
> walkers. First, this makes struct page validity check as two steps,
> pfn_valid() and then PageResereved().
Yes, those are two separate checkes because semantically they are
different. Not all pfn walkers do care about the online status.
> If we should not use struct page
> in this case, it's better to pfn_valid() returns false rather than
> adding a separate check. Anyway, we need to fix more places (all pfn
> walker?) if we want to check validity by two steps.
Which pfn walkers you have in mind?
> The other problem I found is that your change will makes some
> contiguous zones to be considered as non-contiguous. Memory allocated
> by memblock API is also marked as PageResereved. If we consider this as
> a hole, we will set such a zone as non-contiguous.
Why would that be a problem? We shouldn't touch those pages anyway?
> And, I guess that it's not enough to check PageResereved() in
> pageblock_pfn_to_page() in order to skip these pages in compaction. If
> holes are in the middle of the pageblock, pageblock_pfn_to_page()
> cannot catch it and compaction will use struct page for this hole.
Yes pageblock_pfn_to_page cannot catch it and it wouldn't with the
current implementation anyway. So the implementation won't be any worse
than with the current code. On the other hand offline holes will always
fill the whole pageblock (assuming those are not spanning multiple
memblocks).
> Therefore, I think that making pfn_valid() return false for not
> onlined memory is a better solution for this problem. I don't know the
> implementation detail for hotplug and I don't see your recent change
> but we may defer memmap initialization until the zone is determined.
> It will make pfn_valid() return false for un-initialized range.
I am not really sure. pfn_valid is used in many context and its only
purpose is to tell whether pfn_to_page will return a valid struct page
AFAIU.
I agree that having more checks is more error prone and we can add a
helper pfn_to_valid_page or something similar but I believe we can do
that on top of the current hotplug rework. This would require a non
trivial amount of changes and I believe that a lacking check for the
offline holes is not critical - we would (ab)use the lowest zone which
is similar to (ab)using ZONE_NORMAL/MOVABLE with the original code.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-17 8:15 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-17 8:15 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon 17-04-17 14:47:20, Joonsoo Kim wrote:
> On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> > Hi,
> > here I 3 more preparatory patches which I meant to send on Thursday but
> > forgot... After more thinking about pfn walkers I have realized that
> > the current code doesn't check offline holes in zones. From a quick
> > review that doesn't seem to be a problem currently. Pfn walkers can race
> > with memory offlining and with the original hotplug impementation those
> > offline pages can change the zone but I wasn't able to find any serious
> > problem other than small confusion. The new hotplug code, will not have
> > any valid zone, though so those code paths should check PageReserved
> > to rule offline holes. I hope I have addressed all of them in these 3
> > patches. I would appreciate if Vlastimil and Jonsoo double check after
> > me.
>
> Hello, Michal.
>
> s/Jonsoo/Joonsoo. :)
ups, sorry about that.
> I'm not sure that it's a good idea to add PageResereved() check in pfn
> walkers. First, this makes struct page validity check as two steps,
> pfn_valid() and then PageResereved().
Yes, those are two separate checkes because semantically they are
different. Not all pfn walkers do care about the online status.
> If we should not use struct page
> in this case, it's better to pfn_valid() returns false rather than
> adding a separate check. Anyway, we need to fix more places (all pfn
> walker?) if we want to check validity by two steps.
Which pfn walkers you have in mind?
> The other problem I found is that your change will makes some
> contiguous zones to be considered as non-contiguous. Memory allocated
> by memblock API is also marked as PageResereved. If we consider this as
> a hole, we will set such a zone as non-contiguous.
Why would that be a problem? We shouldn't touch those pages anyway?
> And, I guess that it's not enough to check PageResereved() in
> pageblock_pfn_to_page() in order to skip these pages in compaction. If
> holes are in the middle of the pageblock, pageblock_pfn_to_page()
> cannot catch it and compaction will use struct page for this hole.
Yes pageblock_pfn_to_page cannot catch it and it wouldn't with the
current implementation anyway. So the implementation won't be any worse
than with the current code. On the other hand offline holes will always
fill the whole pageblock (assuming those are not spanning multiple
memblocks).
> Therefore, I think that making pfn_valid() return false for not
> onlined memory is a better solution for this problem. I don't know the
> implementation detail for hotplug and I don't see your recent change
> but we may defer memmap initialization until the zone is determined.
> It will make pfn_valid() return false for un-initialized range.
I am not really sure. pfn_valid is used in many context and its only
purpose is to tell whether pfn_to_page will return a valid struct page
AFAIU.
I agree that having more checks is more error prone and we can add a
helper pfn_to_valid_page or something similar but I believe we can do
that on top of the current hotplug rework. This would require a non
trivial amount of changes and I believe that a lacking check for the
offline holes is not critical - we would (ab)use the lowest zone which
is similar to (ab)using ZONE_NORMAL/MOVABLE with the original code.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-17 8:15 ` Michal Hocko
@ 2017-04-20 1:27 ` Joonsoo Kim
-1 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-20 1:27 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> On Mon 17-04-17 14:47:20, Joonsoo Kim wrote:
> > On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> > > Hi,
> > > here I 3 more preparatory patches which I meant to send on Thursday but
> > > forgot... After more thinking about pfn walkers I have realized that
> > > the current code doesn't check offline holes in zones. From a quick
> > > review that doesn't seem to be a problem currently. Pfn walkers can race
> > > with memory offlining and with the original hotplug impementation those
> > > offline pages can change the zone but I wasn't able to find any serious
> > > problem other than small confusion. The new hotplug code, will not have
> > > any valid zone, though so those code paths should check PageReserved
> > > to rule offline holes. I hope I have addressed all of them in these 3
> > > patches. I would appreciate if Vlastimil and Jonsoo double check after
> > > me.
> >
> > Hello, Michal.
> >
> > s/Jonsoo/Joonsoo. :)
>
> ups, sorry about that.
>
> > I'm not sure that it's a good idea to add PageResereved() check in pfn
> > walkers. First, this makes struct page validity check as two steps,
> > pfn_valid() and then PageResereved().
>
> Yes, those are two separate checkes because semantically they are
> different. Not all pfn walkers do care about the online status.
If offlined page has no valid information, reading information
about offlined pages are just wrong. So, all pfn walkers that reads
information about the page should do care about it.
I guess that many callers for pfn_valid() is in this category.
>
> > If we should not use struct page
> > in this case, it's better to pfn_valid() returns false rather than
> > adding a separate check. Anyway, we need to fix more places (all pfn
> > walker?) if we want to check validity by two steps.
>
> Which pfn walkers you have in mind?
For example, kpagecount_read() in fs/proc/page.c. I searched it by
using pfn_valid().
> > The other problem I found is that your change will makes some
> > contiguous zones to be considered as non-contiguous. Memory allocated
> > by memblock API is also marked as PageResereved. If we consider this as
> > a hole, we will set such a zone as non-contiguous.
>
> Why would that be a problem? We shouldn't touch those pages anyway?
Skipping those pages in compaction are valid so no problem in this
case.
The problem I mentioned above is that adding PageReserved() check in
__pageblock_pfn_to_page() invalidates optimization by
set_zone_contiguous(). In compaction, we need to get a valid struct
page and it requires a lot of work. There is performance problem
report due to this so set_zone_contiguous() optimization is added. It
checks if the zone is contiguous or not in boot time. If zone is
determined as contiguous, we can easily get a valid struct page in
runtime without expensive checks.
Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
woule make that zone->contiguous usually returns false since memory
used by memblock API is marked as PageReserved() and your patch regard
it as a hole. It invalidates set_zone_contiguous() optimization and I
worry about it.
>
> > And, I guess that it's not enough to check PageResereved() in
> > pageblock_pfn_to_page() in order to skip these pages in compaction. If
> > holes are in the middle of the pageblock, pageblock_pfn_to_page()
> > cannot catch it and compaction will use struct page for this hole.
>
> Yes pageblock_pfn_to_page cannot catch it and it wouldn't with the
> current implementation anyway. So the implementation won't be any worse
> than with the current code. On the other hand offline holes will always
> fill the whole pageblock (assuming those are not spanning multiple
> memblocks).
>
> > Therefore, I think that making pfn_valid() return false for not
> > onlined memory is a better solution for this problem. I don't know the
> > implementation detail for hotplug and I don't see your recent change
> > but we may defer memmap initialization until the zone is determined.
> > It will make pfn_valid() return false for un-initialized range.
>
> I am not really sure. pfn_valid is used in many context and its only
> purpose is to tell whether pfn_to_page will return a valid struct page
> AFAIU.
>
> I agree that having more checks is more error prone and we can add a
> helper pfn_to_valid_page or something similar but I believe we can do
> that on top of the current hotplug rework. This would require a non
> trivial amount of changes and I believe that a lacking check for the
> offline holes is not critical - we would (ab)use the lowest zone which
> is similar to (ab)using ZONE_NORMAL/MOVABLE with the original code.
I'm not objecting your hotplug rework. In fact, I don't know the
relationship between this work and hotplug rework. I'm agreeing
with checking offline holes but I don't like the design and
implementation about it.
Let me clarify my desire(?) for this issue.
1. If pfn_valid() returns true, struct page has valid information, at
least, in flags (zone id, node id, flags, etc...). So, we can use them
without checking PageResereved().
2. pfn_valid() for offlined holes returns false. This can be easily
(?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
guess that there is no reason that pfn_valid() returns true for
offlined holes. If there is, please let me know.
3. We don't need to check PageReserved() in most of pfn walkers in
order to check offline holes.
Thanks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-20 1:27 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-20 1:27 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> On Mon 17-04-17 14:47:20, Joonsoo Kim wrote:
> > On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> > > Hi,
> > > here I 3 more preparatory patches which I meant to send on Thursday but
> > > forgot... After more thinking about pfn walkers I have realized that
> > > the current code doesn't check offline holes in zones. From a quick
> > > review that doesn't seem to be a problem currently. Pfn walkers can race
> > > with memory offlining and with the original hotplug impementation those
> > > offline pages can change the zone but I wasn't able to find any serious
> > > problem other than small confusion. The new hotplug code, will not have
> > > any valid zone, though so those code paths should check PageReserved
> > > to rule offline holes. I hope I have addressed all of them in these 3
> > > patches. I would appreciate if Vlastimil and Jonsoo double check after
> > > me.
> >
> > Hello, Michal.
> >
> > s/Jonsoo/Joonsoo. :)
>
> ups, sorry about that.
>
> > I'm not sure that it's a good idea to add PageResereved() check in pfn
> > walkers. First, this makes struct page validity check as two steps,
> > pfn_valid() and then PageResereved().
>
> Yes, those are two separate checkes because semantically they are
> different. Not all pfn walkers do care about the online status.
If offlined page has no valid information, reading information
about offlined pages are just wrong. So, all pfn walkers that reads
information about the page should do care about it.
I guess that many callers for pfn_valid() is in this category.
>
> > If we should not use struct page
> > in this case, it's better to pfn_valid() returns false rather than
> > adding a separate check. Anyway, we need to fix more places (all pfn
> > walker?) if we want to check validity by two steps.
>
> Which pfn walkers you have in mind?
For example, kpagecount_read() in fs/proc/page.c. I searched it by
using pfn_valid().
> > The other problem I found is that your change will makes some
> > contiguous zones to be considered as non-contiguous. Memory allocated
> > by memblock API is also marked as PageResereved. If we consider this as
> > a hole, we will set such a zone as non-contiguous.
>
> Why would that be a problem? We shouldn't touch those pages anyway?
Skipping those pages in compaction are valid so no problem in this
case.
The problem I mentioned above is that adding PageReserved() check in
__pageblock_pfn_to_page() invalidates optimization by
set_zone_contiguous(). In compaction, we need to get a valid struct
page and it requires a lot of work. There is performance problem
report due to this so set_zone_contiguous() optimization is added. It
checks if the zone is contiguous or not in boot time. If zone is
determined as contiguous, we can easily get a valid struct page in
runtime without expensive checks.
Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
woule make that zone->contiguous usually returns false since memory
used by memblock API is marked as PageReserved() and your patch regard
it as a hole. It invalidates set_zone_contiguous() optimization and I
worry about it.
>
> > And, I guess that it's not enough to check PageResereved() in
> > pageblock_pfn_to_page() in order to skip these pages in compaction. If
> > holes are in the middle of the pageblock, pageblock_pfn_to_page()
> > cannot catch it and compaction will use struct page for this hole.
>
> Yes pageblock_pfn_to_page cannot catch it and it wouldn't with the
> current implementation anyway. So the implementation won't be any worse
> than with the current code. On the other hand offline holes will always
> fill the whole pageblock (assuming those are not spanning multiple
> memblocks).
>
> > Therefore, I think that making pfn_valid() return false for not
> > onlined memory is a better solution for this problem. I don't know the
> > implementation detail for hotplug and I don't see your recent change
> > but we may defer memmap initialization until the zone is determined.
> > It will make pfn_valid() return false for un-initialized range.
>
> I am not really sure. pfn_valid is used in many context and its only
> purpose is to tell whether pfn_to_page will return a valid struct page
> AFAIU.
>
> I agree that having more checks is more error prone and we can add a
> helper pfn_to_valid_page or something similar but I believe we can do
> that on top of the current hotplug rework. This would require a non
> trivial amount of changes and I believe that a lacking check for the
> offline holes is not critical - we would (ab)use the lowest zone which
> is similar to (ab)using ZONE_NORMAL/MOVABLE with the original code.
I'm not objecting your hotplug rework. In fact, I don't know the
relationship between this work and hotplug rework. I'm agreeing
with checking offline holes but I don't like the design and
implementation about it.
Let me clarify my desire(?) for this issue.
1. If pfn_valid() returns true, struct page has valid information, at
least, in flags (zone id, node id, flags, etc...). So, we can use them
without checking PageResereved().
2. pfn_valid() for offlined holes returns false. This can be easily
(?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
guess that there is no reason that pfn_valid() returns true for
offlined holes. If there is, please let me know.
3. We don't need to check PageReserved() in most of pfn walkers in
order to check offline holes.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-20 1:27 ` Joonsoo Kim
@ 2017-04-20 7:28 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-20 7:28 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
[...]
> > Which pfn walkers you have in mind?
>
> For example, kpagecount_read() in fs/proc/page.c. I searched it by
> using pfn_valid().
Yeah, I've checked that one and in fact this is a good example of the
case where you do not really care about holes. It just checks the page
count which is a valid information under any circumstances.
> > > The other problem I found is that your change will makes some
> > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > by memblock API is also marked as PageResereved. If we consider this as
> > > a hole, we will set such a zone as non-contiguous.
> >
> > Why would that be a problem? We shouldn't touch those pages anyway?
>
> Skipping those pages in compaction are valid so no problem in this
> case.
>
> The problem I mentioned above is that adding PageReserved() check in
> __pageblock_pfn_to_page() invalidates optimization by
> set_zone_contiguous(). In compaction, we need to get a valid struct
> page and it requires a lot of work. There is performance problem
> report due to this so set_zone_contiguous() optimization is added. It
> checks if the zone is contiguous or not in boot time. If zone is
> determined as contiguous, we can easily get a valid struct page in
> runtime without expensive checks.
OK, I see. I've had some vague understading and the clarification helps.
> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> woule make that zone->contiguous usually returns false since memory
> used by memblock API is marked as PageReserved() and your patch regard
> it as a hole. It invalidates set_zone_contiguous() optimization and I
> worry about it.
OK, fair enough. I did't consider memblock allocations. I will rethink
this patch but there are essentially 3 options
- use a different criterion for the offline holes dection. I
have just realized we might do it by storing the online
information into the mem sections
- drop this patch
- move the PageReferenced check down the chain into
isolate_freepages_block resp. isolate_migratepages_block
I would prefer 3 over 2 over 1. I definitely want to make this more
robust so 1 is preferable long term but I do not want this to be a
roadblock to the rest of the rework. Does that sound acceptable to you?
[..]
> Let me clarify my desire(?) for this issue.
>
> 1. If pfn_valid() returns true, struct page has valid information, at
> least, in flags (zone id, node id, flags, etc...). So, we can use them
> without checking PageResereved().
This is no longer true after my rework. Pages are associated with the
zone during _onlining_ rather than when they are physically hotpluged.
Basically only the nid is set properly. Strictly speaking this is the
case also without my rework because the zone might change during online
phase so you cannot assume it is correct even now. It just happens that
it more or less works just fine.
> 2. pfn_valid() for offlined holes returns false. This can be easily
> (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> guess that there is no reason that pfn_valid() returns true for
> offlined holes. If there is, please let me know.
There is some code which really expects that pfn_valid returns true iff
there is a struct page and it doesn't care about the online status.
E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
do though is to add pfn_to_online_page which would do the proper check.
I have already sent [1]. As noted above we can (ab)use the remaining bit
in SECTION_MAP_MASK to detect offline pages more robustly.
> 3. We don't need to check PageReserved() in most of pfn walkers in
> order to check offline holes.
We still have to distinguish those who care about offline pages from
those who do not care about it.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-20 7:28 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-20 7:28 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
[...]
> > Which pfn walkers you have in mind?
>
> For example, kpagecount_read() in fs/proc/page.c. I searched it by
> using pfn_valid().
Yeah, I've checked that one and in fact this is a good example of the
case where you do not really care about holes. It just checks the page
count which is a valid information under any circumstances.
> > > The other problem I found is that your change will makes some
> > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > by memblock API is also marked as PageResereved. If we consider this as
> > > a hole, we will set such a zone as non-contiguous.
> >
> > Why would that be a problem? We shouldn't touch those pages anyway?
>
> Skipping those pages in compaction are valid so no problem in this
> case.
>
> The problem I mentioned above is that adding PageReserved() check in
> __pageblock_pfn_to_page() invalidates optimization by
> set_zone_contiguous(). In compaction, we need to get a valid struct
> page and it requires a lot of work. There is performance problem
> report due to this so set_zone_contiguous() optimization is added. It
> checks if the zone is contiguous or not in boot time. If zone is
> determined as contiguous, we can easily get a valid struct page in
> runtime without expensive checks.
OK, I see. I've had some vague understading and the clarification helps.
> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> woule make that zone->contiguous usually returns false since memory
> used by memblock API is marked as PageReserved() and your patch regard
> it as a hole. It invalidates set_zone_contiguous() optimization and I
> worry about it.
OK, fair enough. I did't consider memblock allocations. I will rethink
this patch but there are essentially 3 options
- use a different criterion for the offline holes dection. I
have just realized we might do it by storing the online
information into the mem sections
- drop this patch
- move the PageReferenced check down the chain into
isolate_freepages_block resp. isolate_migratepages_block
I would prefer 3 over 2 over 1. I definitely want to make this more
robust so 1 is preferable long term but I do not want this to be a
roadblock to the rest of the rework. Does that sound acceptable to you?
[..]
> Let me clarify my desire(?) for this issue.
>
> 1. If pfn_valid() returns true, struct page has valid information, at
> least, in flags (zone id, node id, flags, etc...). So, we can use them
> without checking PageResereved().
This is no longer true after my rework. Pages are associated with the
zone during _onlining_ rather than when they are physically hotpluged.
Basically only the nid is set properly. Strictly speaking this is the
case also without my rework because the zone might change during online
phase so you cannot assume it is correct even now. It just happens that
it more or less works just fine.
> 2. pfn_valid() for offlined holes returns false. This can be easily
> (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> guess that there is no reason that pfn_valid() returns true for
> offlined holes. If there is, please let me know.
There is some code which really expects that pfn_valid returns true iff
there is a struct page and it doesn't care about the online status.
E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
do though is to add pfn_to_online_page which would do the proper check.
I have already sent [1]. As noted above we can (ab)use the remaining bit
in SECTION_MAP_MASK to detect offline pages more robustly.
> 3. We don't need to check PageReserved() in most of pfn walkers in
> order to check offline holes.
We still have to distinguish those who care about offline pages from
those who do not care about it.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-20 7:28 ` Michal Hocko
@ 2017-04-20 8:49 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-20 8:49 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 09:28:20, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
[...]
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
>
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
> - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
> - drop this patch
> - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
>
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?
So I've played with all three options just to see how the outcome would
look like and it turned out that going with 1 will be easiest in the
end. What do you think about the following? It should be free of any
false positives. I have only compile tested it yet.
---
>From 747794c13c0e82b55b793a31cdbe1a84ee1c6920 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Thu, 13 Apr 2017 10:28:45 +0200
Subject: [PATCH] mm: consider zone which is not fully populated to have holes
__pageblock_pfn_to_page has two users currently, set_zone_contiguous
which checks whether the given zone contains holes and
pageblock_pfn_to_page which then carefully returns a first valid
page from the given pfn range for the given zone. This doesn't handle
zones which are not fully populated though. Memory pageblocks can be
offlined or might not have been onlined yet. In such a case the zone
should be considered to have holes otherwise pfn walkers can touch
and play with offline pages.
Current callers of pageblock_pfn_to_page in compaction seem to work
properly right now because they only isolate PageBuddy
(isolate_freepages_block) or PageLRU resp. __PageMovable
(isolate_migratepages_block) which will be always false for these pages.
It would be safer to skip these pages altogether, though.
In order to do this patch adds a new memory section state
(SECTION_IS_ONLINE) which is set in memory_present (during boot
time) or in online_pages_range during the memory hotplug. Similarly
offline_mem_sections clears the bit and it is called when the memory
range is offlined.
pfn_to_online_page helper is then added which check the mem section and
only returns a page if it is onlined already.
Use the new helper in __pageblock_pfn_to_page and skip the whole page
block in such a case.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
include/linux/memory_hotplug.h | 21 ++++++++++++++++++++
include/linux/mmzone.h | 20 ++++++++++++++++++-
mm/memory_hotplug.c | 3 +++
mm/page_alloc.c | 5 ++++-
mm/sparse.c | 45 +++++++++++++++++++++++++++++++++++++++++-
5 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 3c8cf86201c3..fc1c873504eb 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -14,6 +14,19 @@ struct memory_block;
struct resource;
#ifdef CONFIG_MEMORY_HOTPLUG
+/*
+ * Return page for the valid pfn only if the page is online. All pfn
+ * walkers which rely on the fully initialized page->flags and others
+ * should use this rather than pfn_valid && pfn_to_page
+ */
+#define pfn_to_online_page(pfn) \
+({ \
+ struct page *___page = NULL; \
+ \
+ if (online_section_nr(pfn_to_section_nr(pfn))) \
+ ___page = pfn_to_page(pfn); \
+ ___page; \
+})
/*
* Types for free bootmem stored in page->lru.next. These have to be in
@@ -203,6 +216,14 @@ extern void set_zone_contiguous(struct zone *zone);
extern void clear_zone_contiguous(struct zone *zone);
#else /* ! CONFIG_MEMORY_HOTPLUG */
+#define pfn_to_online_page(pfn) \
+({ \
+ struct page *___page = NULL; \
+ if (pfn_valid(pfn)) \
+ ___page = pfn_to_page(pfn); \
+ ___page; \
+ })
+
/*
* Stub functions for when hotplug is off
*/
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0fc121bbf4ff..cad16ac080f5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1143,7 +1143,8 @@ extern unsigned long usemap_size(void);
*/
#define SECTION_MARKED_PRESENT (1UL<<0)
#define SECTION_HAS_MEM_MAP (1UL<<1)
-#define SECTION_MAP_LAST_BIT (1UL<<2)
+#define SECTION_IS_ONLINE (1UL<<2)
+#define SECTION_MAP_LAST_BIT (1UL<<3)
#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
#define SECTION_NID_SHIFT 2
@@ -1174,6 +1175,23 @@ static inline int valid_section_nr(unsigned long nr)
return valid_section(__nr_to_section(nr));
}
+static inline int online_section(struct mem_section *section)
+{
+ return (section && (section->section_mem_map & SECTION_IS_ONLINE));
+}
+
+static inline int online_section_nr(unsigned long nr)
+{
+ return online_section(__nr_to_section(nr));
+}
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
+#ifdef CONFIG_MEMORY_HOTREMOVE
+void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
+#endif
+#endif
+
static inline struct mem_section *__pfn_to_section(unsigned long pfn)
{
return __nr_to_section(pfn_to_section_nr(pfn));
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index caa58338d121..98f565c279bf 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -929,6 +929,9 @@ static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
unsigned long i;
unsigned long onlined_pages = *(unsigned long *)arg;
struct page *page;
+
+ online_mem_sections(start_pfn, start_pfn + nr_pages);
+
if (PageReserved(pfn_to_page(start_pfn)))
for (i = 0; i < nr_pages; i++) {
page = pfn_to_page(start_pfn + i);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5d72d29a6ece..fa752de84eef 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1353,7 +1353,9 @@ struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn))
return NULL;
- start_page = pfn_to_page(start_pfn);
+ start_page = pfn_to_online_page(start_pfn);
+ if (!start_page)
+ return NULL;
if (page_zone(start_page) != zone)
return NULL;
@@ -7686,6 +7688,7 @@ __offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
break;
if (pfn == end_pfn)
return;
+ offline_mem_sections(pfn, end_pfn);
zone = page_zone(pfn_to_page(pfn));
spin_lock_irqsave(&zone->lock, flags);
pfn = start_pfn;
diff --git a/mm/sparse.c b/mm/sparse.c
index 6903c8fc3085..79017f90d8fc 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -185,7 +185,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
ms = __nr_to_section(section);
if (!ms->section_mem_map)
ms->section_mem_map = sparse_encode_early_nid(nid) |
- SECTION_MARKED_PRESENT;
+ SECTION_MARKED_PRESENT |
+ SECTION_IS_ONLINE;
}
}
@@ -590,6 +591,48 @@ void __init sparse_init(void)
}
#ifdef CONFIG_MEMORY_HOTPLUG
+
+/* Mark all memory sections within the pfn range as online */
+void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
+{
+ unsigned long pfn;
+
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ struct mem_section *ms;
+
+ /* onlining code should never touch invalid ranges */
+ if (WARN_ON(!valid_section_nr(section_nr)))
+ continue;
+
+ ms = __nr_to_section(section_nr);
+ ms->section_mem_map |= SECTION_IS_ONLINE;
+ }
+}
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+/* Mark all memory sections within the pfn range as online */
+void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
+{
+ unsigned long pfn;
+
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ struct mem_section *ms;
+
+ /*
+ * TODO this needs some double checking. Offlining code makes
+ * sure to check pfn_valid but those checks might be just bogus
+ */
+ if (WARN_ON(!valid_section_nr(section_nr)))
+ continue;
+
+ ms = __nr_to_section(section_nr);
+ ms->section_mem_map &= ~SECTION_IS_ONLINE;
+ }
+}
+#endif
+
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static inline struct page *kmalloc_section_memmap(unsigned long pnum, int nid)
{
--
2.11.0
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
@ 2017-04-20 8:49 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-20 8:49 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 09:28:20, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
[...]
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
>
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
> - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
> - drop this patch
> - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
>
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?
So I've played with all three options just to see how the outcome would
look like and it turned out that going with 1 will be easiest in the
end. What do you think about the following? It should be free of any
false positives. I have only compile tested it yet.
---
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-20 8:49 ` Michal Hocko
@ 2017-04-20 11:56 ` Vlastimil Babka
-1 siblings, 0 replies; 669+ messages in thread
From: Vlastimil Babka @ 2017-04-20 11:56 UTC (permalink / raw)
To: Michal Hocko, Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On 04/20/2017 10:49 AM, Michal Hocko wrote:
> On Thu 20-04-17 09:28:20, Michal Hocko wrote:
>> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> [...]
>>> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
>>> woule make that zone->contiguous usually returns false since memory
>>> used by memblock API is marked as PageReserved() and your patch regard
>>> it as a hole. It invalidates set_zone_contiguous() optimization and I
>>> worry about it.
>>
>> OK, fair enough. I did't consider memblock allocations. I will rethink
>> this patch but there are essentially 3 options
>> - use a different criterion for the offline holes dection. I
>> have just realized we might do it by storing the online
>> information into the mem sections
>> - drop this patch
>> - move the PageReferenced check down the chain into
>> isolate_freepages_block resp. isolate_migratepages_block
>>
>> I would prefer 3 over 2 over 1. I definitely want to make this more
>> robust so 1 is preferable long term but I do not want this to be a
>> roadblock to the rest of the rework. Does that sound acceptable to you?
>
> So I've played with all three options just to see how the outcome would
> look like and it turned out that going with 1 will be easiest in the
> end. What do you think about the following? It should be free of any
> false positives. I have only compile tested it yet.
That looks fine, can't say immediately if fully correct. I think you'll
need to bump SECTION_NID_SHIFT as well and make sure things still fit?
Otherwise looks like nobody needed a new section bit since 2005, so we
should be fine.
> ---
> From 747794c13c0e82b55b793a31cdbe1a84ee1c6920 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Thu, 13 Apr 2017 10:28:45 +0200
> Subject: [PATCH] mm: consider zone which is not fully populated to have holes
>
> __pageblock_pfn_to_page has two users currently, set_zone_contiguous
> which checks whether the given zone contains holes and
> pageblock_pfn_to_page which then carefully returns a first valid
> page from the given pfn range for the given zone. This doesn't handle
> zones which are not fully populated though. Memory pageblocks can be
> offlined or might not have been onlined yet. In such a case the zone
> should be considered to have holes otherwise pfn walkers can touch
> and play with offline pages.
>
> Current callers of pageblock_pfn_to_page in compaction seem to work
> properly right now because they only isolate PageBuddy
> (isolate_freepages_block) or PageLRU resp. __PageMovable
> (isolate_migratepages_block) which will be always false for these pages.
> It would be safer to skip these pages altogether, though.
>
> In order to do this patch adds a new memory section state
> (SECTION_IS_ONLINE) which is set in memory_present (during boot
> time) or in online_pages_range during the memory hotplug. Similarly
> offline_mem_sections clears the bit and it is called when the memory
> range is offlined.
>
> pfn_to_online_page helper is then added which check the mem section and
> only returns a page if it is onlined already.
>
> Use the new helper in __pageblock_pfn_to_page and skip the whole page
> block in such a case.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> include/linux/memory_hotplug.h | 21 ++++++++++++++++++++
> include/linux/mmzone.h | 20 ++++++++++++++++++-
> mm/memory_hotplug.c | 3 +++
> mm/page_alloc.c | 5 ++++-
> mm/sparse.c | 45 +++++++++++++++++++++++++++++++++++++++++-
> 5 files changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 3c8cf86201c3..fc1c873504eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -14,6 +14,19 @@ struct memory_block;
> struct resource;
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +/*
> + * Return page for the valid pfn only if the page is online. All pfn
> + * walkers which rely on the fully initialized page->flags and others
> + * should use this rather than pfn_valid && pfn_to_page
> + */
> +#define pfn_to_online_page(pfn) \
> +({ \
> + struct page *___page = NULL; \
> + \
> + if (online_section_nr(pfn_to_section_nr(pfn))) \
> + ___page = pfn_to_page(pfn); \
> + ___page; \
> +})
>
> /*
> * Types for free bootmem stored in page->lru.next. These have to be in
> @@ -203,6 +216,14 @@ extern void set_zone_contiguous(struct zone *zone);
> extern void clear_zone_contiguous(struct zone *zone);
>
> #else /* ! CONFIG_MEMORY_HOTPLUG */
> +#define pfn_to_online_page(pfn) \
> +({ \
> + struct page *___page = NULL; \
> + if (pfn_valid(pfn)) \
> + ___page = pfn_to_page(pfn); \
> + ___page; \
> + })
> +
> /*
> * Stub functions for when hotplug is off
> */
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0fc121bbf4ff..cad16ac080f5 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1143,7 +1143,8 @@ extern unsigned long usemap_size(void);
> */
> #define SECTION_MARKED_PRESENT (1UL<<0)
> #define SECTION_HAS_MEM_MAP (1UL<<1)
> -#define SECTION_MAP_LAST_BIT (1UL<<2)
> +#define SECTION_IS_ONLINE (1UL<<2)
> +#define SECTION_MAP_LAST_BIT (1UL<<3)
> #define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
> #define SECTION_NID_SHIFT 2
>
> @@ -1174,6 +1175,23 @@ static inline int valid_section_nr(unsigned long nr)
> return valid_section(__nr_to_section(nr));
> }
>
> +static inline int online_section(struct mem_section *section)
> +{
> + return (section && (section->section_mem_map & SECTION_IS_ONLINE));
> +}
> +
> +static inline int online_section_nr(unsigned long nr)
> +{
> + return online_section(__nr_to_section(nr));
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +#endif
> +#endif
> +
> static inline struct mem_section *__pfn_to_section(unsigned long pfn)
> {
> return __nr_to_section(pfn_to_section_nr(pfn));
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index caa58338d121..98f565c279bf 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -929,6 +929,9 @@ static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
> unsigned long i;
> unsigned long onlined_pages = *(unsigned long *)arg;
> struct page *page;
> +
> + online_mem_sections(start_pfn, start_pfn + nr_pages);
> +
> if (PageReserved(pfn_to_page(start_pfn)))
> for (i = 0; i < nr_pages; i++) {
> page = pfn_to_page(start_pfn + i);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5d72d29a6ece..fa752de84eef 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1353,7 +1353,9 @@ struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
> if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn))
> return NULL;
>
> - start_page = pfn_to_page(start_pfn);
> + start_page = pfn_to_online_page(start_pfn);
> + if (!start_page)
> + return NULL;
>
> if (page_zone(start_page) != zone)
> return NULL;
> @@ -7686,6 +7688,7 @@ __offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
> break;
> if (pfn == end_pfn)
> return;
> + offline_mem_sections(pfn, end_pfn);
> zone = page_zone(pfn_to_page(pfn));
> spin_lock_irqsave(&zone->lock, flags);
> pfn = start_pfn;
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 6903c8fc3085..79017f90d8fc 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -185,7 +185,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
> ms = __nr_to_section(section);
> if (!ms->section_mem_map)
> ms->section_mem_map = sparse_encode_early_nid(nid) |
> - SECTION_MARKED_PRESENT;
> + SECTION_MARKED_PRESENT |
> + SECTION_IS_ONLINE;
> }
> }
>
> @@ -590,6 +591,48 @@ void __init sparse_init(void)
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +
> +/* Mark all memory sections within the pfn range as online */
> +void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + struct mem_section *ms;
> +
> + /* onlining code should never touch invalid ranges */
> + if (WARN_ON(!valid_section_nr(section_nr)))
> + continue;
> +
> + ms = __nr_to_section(section_nr);
> + ms->section_mem_map |= SECTION_IS_ONLINE;
> + }
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +/* Mark all memory sections within the pfn range as online */
> +void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + struct mem_section *ms;
> +
> + /*
> + * TODO this needs some double checking. Offlining code makes
> + * sure to check pfn_valid but those checks might be just bogus
> + */
> + if (WARN_ON(!valid_section_nr(section_nr)))
> + continue;
> +
> + ms = __nr_to_section(section_nr);
> + ms->section_mem_map &= ~SECTION_IS_ONLINE;
> + }
> +}
> +#endif
> +
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> static inline struct page *kmalloc_section_memmap(unsigned long pnum, int nid)
> {
>
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2017-04-20 11:56 ` Vlastimil Babka
0 siblings, 0 replies; 669+ messages in thread
From: Vlastimil Babka @ 2017-04-20 11:56 UTC (permalink / raw)
To: Michal Hocko, Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On 04/20/2017 10:49 AM, Michal Hocko wrote:
> On Thu 20-04-17 09:28:20, Michal Hocko wrote:
>> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> [...]
>>> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
>>> woule make that zone->contiguous usually returns false since memory
>>> used by memblock API is marked as PageReserved() and your patch regard
>>> it as a hole. It invalidates set_zone_contiguous() optimization and I
>>> worry about it.
>>
>> OK, fair enough. I did't consider memblock allocations. I will rethink
>> this patch but there are essentially 3 options
>> - use a different criterion for the offline holes dection. I
>> have just realized we might do it by storing the online
>> information into the mem sections
>> - drop this patch
>> - move the PageReferenced check down the chain into
>> isolate_freepages_block resp. isolate_migratepages_block
>>
>> I would prefer 3 over 2 over 1. I definitely want to make this more
>> robust so 1 is preferable long term but I do not want this to be a
>> roadblock to the rest of the rework. Does that sound acceptable to you?
>
> So I've played with all three options just to see how the outcome would
> look like and it turned out that going with 1 will be easiest in the
> end. What do you think about the following? It should be free of any
> false positives. I have only compile tested it yet.
That looks fine, can't say immediately if fully correct. I think you'll
need to bump SECTION_NID_SHIFT as well and make sure things still fit?
Otherwise looks like nobody needed a new section bit since 2005, so we
should be fine.
> ---
> From 747794c13c0e82b55b793a31cdbe1a84ee1c6920 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Thu, 13 Apr 2017 10:28:45 +0200
> Subject: [PATCH] mm: consider zone which is not fully populated to have holes
>
> __pageblock_pfn_to_page has two users currently, set_zone_contiguous
> which checks whether the given zone contains holes and
> pageblock_pfn_to_page which then carefully returns a first valid
> page from the given pfn range for the given zone. This doesn't handle
> zones which are not fully populated though. Memory pageblocks can be
> offlined or might not have been onlined yet. In such a case the zone
> should be considered to have holes otherwise pfn walkers can touch
> and play with offline pages.
>
> Current callers of pageblock_pfn_to_page in compaction seem to work
> properly right now because they only isolate PageBuddy
> (isolate_freepages_block) or PageLRU resp. __PageMovable
> (isolate_migratepages_block) which will be always false for these pages.
> It would be safer to skip these pages altogether, though.
>
> In order to do this patch adds a new memory section state
> (SECTION_IS_ONLINE) which is set in memory_present (during boot
> time) or in online_pages_range during the memory hotplug. Similarly
> offline_mem_sections clears the bit and it is called when the memory
> range is offlined.
>
> pfn_to_online_page helper is then added which check the mem section and
> only returns a page if it is onlined already.
>
> Use the new helper in __pageblock_pfn_to_page and skip the whole page
> block in such a case.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> include/linux/memory_hotplug.h | 21 ++++++++++++++++++++
> include/linux/mmzone.h | 20 ++++++++++++++++++-
> mm/memory_hotplug.c | 3 +++
> mm/page_alloc.c | 5 ++++-
> mm/sparse.c | 45 +++++++++++++++++++++++++++++++++++++++++-
> 5 files changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 3c8cf86201c3..fc1c873504eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -14,6 +14,19 @@ struct memory_block;
> struct resource;
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +/*
> + * Return page for the valid pfn only if the page is online. All pfn
> + * walkers which rely on the fully initialized page->flags and others
> + * should use this rather than pfn_valid && pfn_to_page
> + */
> +#define pfn_to_online_page(pfn) \
> +({ \
> + struct page *___page = NULL; \
> + \
> + if (online_section_nr(pfn_to_section_nr(pfn))) \
> + ___page = pfn_to_page(pfn); \
> + ___page; \
> +})
>
> /*
> * Types for free bootmem stored in page->lru.next. These have to be in
> @@ -203,6 +216,14 @@ extern void set_zone_contiguous(struct zone *zone);
> extern void clear_zone_contiguous(struct zone *zone);
>
> #else /* ! CONFIG_MEMORY_HOTPLUG */
> +#define pfn_to_online_page(pfn) \
> +({ \
> + struct page *___page = NULL; \
> + if (pfn_valid(pfn)) \
> + ___page = pfn_to_page(pfn); \
> + ___page; \
> + })
> +
> /*
> * Stub functions for when hotplug is off
> */
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0fc121bbf4ff..cad16ac080f5 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1143,7 +1143,8 @@ extern unsigned long usemap_size(void);
> */
> #define SECTION_MARKED_PRESENT (1UL<<0)
> #define SECTION_HAS_MEM_MAP (1UL<<1)
> -#define SECTION_MAP_LAST_BIT (1UL<<2)
> +#define SECTION_IS_ONLINE (1UL<<2)
> +#define SECTION_MAP_LAST_BIT (1UL<<3)
> #define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
> #define SECTION_NID_SHIFT 2
>
> @@ -1174,6 +1175,23 @@ static inline int valid_section_nr(unsigned long nr)
> return valid_section(__nr_to_section(nr));
> }
>
> +static inline int online_section(struct mem_section *section)
> +{
> + return (section && (section->section_mem_map & SECTION_IS_ONLINE));
> +}
> +
> +static inline int online_section_nr(unsigned long nr)
> +{
> + return online_section(__nr_to_section(nr));
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +#endif
> +#endif
> +
> static inline struct mem_section *__pfn_to_section(unsigned long pfn)
> {
> return __nr_to_section(pfn_to_section_nr(pfn));
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index caa58338d121..98f565c279bf 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -929,6 +929,9 @@ static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
> unsigned long i;
> unsigned long onlined_pages = *(unsigned long *)arg;
> struct page *page;
> +
> + online_mem_sections(start_pfn, start_pfn + nr_pages);
> +
> if (PageReserved(pfn_to_page(start_pfn)))
> for (i = 0; i < nr_pages; i++) {
> page = pfn_to_page(start_pfn + i);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5d72d29a6ece..fa752de84eef 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1353,7 +1353,9 @@ struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
> if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn))
> return NULL;
>
> - start_page = pfn_to_page(start_pfn);
> + start_page = pfn_to_online_page(start_pfn);
> + if (!start_page)
> + return NULL;
>
> if (page_zone(start_page) != zone)
> return NULL;
> @@ -7686,6 +7688,7 @@ __offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
> break;
> if (pfn == end_pfn)
> return;
> + offline_mem_sections(pfn, end_pfn);
> zone = page_zone(pfn_to_page(pfn));
> spin_lock_irqsave(&zone->lock, flags);
> pfn = start_pfn;
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 6903c8fc3085..79017f90d8fc 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -185,7 +185,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
> ms = __nr_to_section(section);
> if (!ms->section_mem_map)
> ms->section_mem_map = sparse_encode_early_nid(nid) |
> - SECTION_MARKED_PRESENT;
> + SECTION_MARKED_PRESENT |
> + SECTION_IS_ONLINE;
> }
> }
>
> @@ -590,6 +591,48 @@ void __init sparse_init(void)
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +
> +/* Mark all memory sections within the pfn range as online */
> +void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + struct mem_section *ms;
> +
> + /* onlining code should never touch invalid ranges */
> + if (WARN_ON(!valid_section_nr(section_nr)))
> + continue;
> +
> + ms = __nr_to_section(section_nr);
> + ms->section_mem_map |= SECTION_IS_ONLINE;
> + }
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +/* Mark all memory sections within the pfn range as online */
> +void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + struct mem_section *ms;
> +
> + /*
> + * TODO this needs some double checking. Offlining code makes
> + * sure to check pfn_valid but those checks might be just bogus
> + */
> + if (WARN_ON(!valid_section_nr(section_nr)))
> + continue;
> +
> + ms = __nr_to_section(section_nr);
> + ms->section_mem_map &= ~SECTION_IS_ONLINE;
> + }
> +}
> +#endif
> +
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> static inline struct page *kmalloc_section_memmap(unsigned long pnum, int nid)
> {
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2017-04-20 11:56 ` Vlastimil Babka
@ 2017-04-20 12:13 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-20 12:13 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Joonsoo Kim, linux-mm, Andrew Morton, Mel Gorman,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 13:56:34, Vlastimil Babka wrote:
> On 04/20/2017 10:49 AM, Michal Hocko wrote:
> > On Thu 20-04-17 09:28:20, Michal Hocko wrote:
> >> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > [...]
> >>> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> >>> woule make that zone->contiguous usually returns false since memory
> >>> used by memblock API is marked as PageReserved() and your patch regard
> >>> it as a hole. It invalidates set_zone_contiguous() optimization and I
> >>> worry about it.
> >>
> >> OK, fair enough. I did't consider memblock allocations. I will rethink
> >> this patch but there are essentially 3 options
> >> - use a different criterion for the offline holes dection. I
> >> have just realized we might do it by storing the online
> >> information into the mem sections
> >> - drop this patch
> >> - move the PageReferenced check down the chain into
> >> isolate_freepages_block resp. isolate_migratepages_block
> >>
> >> I would prefer 3 over 2 over 1. I definitely want to make this more
> >> robust so 1 is preferable long term but I do not want this to be a
> >> roadblock to the rest of the rework. Does that sound acceptable to you?
> >
> > So I've played with all three options just to see how the outcome would
> > look like and it turned out that going with 1 will be easiest in the
> > end. What do you think about the following? It should be free of any
> > false positives. I have only compile tested it yet.
>
> That looks fine, can't say immediately if fully correct. I think you'll
> need to bump SECTION_NID_SHIFT as well and make sure things still fit?
> Otherwise looks like nobody needed a new section bit since 2005, so we
> should be fine.
You are absolutely right. Thanks for spotting this! I have folded this
in
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 611ff869fa4d..c412e6a3a1e9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1166,7 +1166,7 @@ extern unsigned long usemap_size(void);
#define SECTION_IS_ONLINE (1UL<<2)
#define SECTION_MAP_LAST_BIT (1UL<<3)
#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
-#define SECTION_NID_SHIFT 2
+#define SECTION_NID_SHIFT 3
static inline struct page *__section_mem_map_addr(struct mem_section *section)
{
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
@ 2017-04-20 12:13 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-20 12:13 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Joonsoo Kim, linux-mm, Andrew Morton, Mel Gorman,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 13:56:34, Vlastimil Babka wrote:
> On 04/20/2017 10:49 AM, Michal Hocko wrote:
> > On Thu 20-04-17 09:28:20, Michal Hocko wrote:
> >> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > [...]
> >>> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> >>> woule make that zone->contiguous usually returns false since memory
> >>> used by memblock API is marked as PageReserved() and your patch regard
> >>> it as a hole. It invalidates set_zone_contiguous() optimization and I
> >>> worry about it.
> >>
> >> OK, fair enough. I did't consider memblock allocations. I will rethink
> >> this patch but there are essentially 3 options
> >> - use a different criterion for the offline holes dection. I
> >> have just realized we might do it by storing the online
> >> information into the mem sections
> >> - drop this patch
> >> - move the PageReferenced check down the chain into
> >> isolate_freepages_block resp. isolate_migratepages_block
> >>
> >> I would prefer 3 over 2 over 1. I definitely want to make this more
> >> robust so 1 is preferable long term but I do not want this to be a
> >> roadblock to the rest of the rework. Does that sound acceptable to you?
> >
> > So I've played with all three options just to see how the outcome would
> > look like and it turned out that going with 1 will be easiest in the
> > end. What do you think about the following? It should be free of any
> > false positives. I have only compile tested it yet.
>
> That looks fine, can't say immediately if fully correct. I think you'll
> need to bump SECTION_NID_SHIFT as well and make sure things still fit?
> Otherwise looks like nobody needed a new section bit since 2005, so we
> should be fine.
You are absolutely right. Thanks for spotting this! I have folded this
in
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 611ff869fa4d..c412e6a3a1e9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1166,7 +1166,7 @@ extern unsigned long usemap_size(void);
#define SECTION_IS_ONLINE (1UL<<2)
#define SECTION_MAP_LAST_BIT (1UL<<3)
#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
-#define SECTION_NID_SHIFT 2
+#define SECTION_NID_SHIFT 3
static inline struct page *__section_mem_map_addr(struct mem_section *section)
{
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-20 7:28 ` Michal Hocko
@ 2017-04-21 4:38 ` Joonsoo Kim
-1 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-21 4:38 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> [...]
> > > Which pfn walkers you have in mind?
> >
> > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > using pfn_valid().
>
> Yeah, I've checked that one and in fact this is a good example of the
> case where you do not really care about holes. It just checks the page
> count which is a valid information under any circumstances.
I don't think so. First, it checks the page *map* count. Is it still valid
even if PageReserved() is set? What I'd like to ask in this example is
that what information is valid if PageReserved() is set. Is there any
design document on this? I think that we need to define/document it first.
And, I hope that all the information in flags field is valid in all
cases if pfn_valid() return true. By the design.
This makes all the exsiting pfn walkers happy since we don't need an
additional check for PageReserved().
>
> > > > The other problem I found is that your change will makes some
> > > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > > by memblock API is also marked as PageResereved. If we consider this as
> > > > a hole, we will set such a zone as non-contiguous.
> > >
> > > Why would that be a problem? We shouldn't touch those pages anyway?
> >
> > Skipping those pages in compaction are valid so no problem in this
> > case.
> >
> > The problem I mentioned above is that adding PageReserved() check in
> > __pageblock_pfn_to_page() invalidates optimization by
> > set_zone_contiguous(). In compaction, we need to get a valid struct
> > page and it requires a lot of work. There is performance problem
> > report due to this so set_zone_contiguous() optimization is added. It
> > checks if the zone is contiguous or not in boot time. If zone is
> > determined as contiguous, we can easily get a valid struct page in
> > runtime without expensive checks.
>
> OK, I see. I've had some vague understading and the clarification helps.
>
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
>
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
> - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
> - drop this patch
> - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
>
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?
I like #1 among of above options and I already see your patch for #1.
It's much better than your first attempt but I'm still not happy due
to the semantic of pfn_valid().
> [..]
> > Let me clarify my desire(?) for this issue.
> >
> > 1. If pfn_valid() returns true, struct page has valid information, at
> > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > without checking PageResereved().
>
> This is no longer true after my rework. Pages are associated with the
> zone during _onlining_ rather than when they are physically hotpluged.
If your rework make information valid during _onlining_, my
suggestion is making pfn_valid() return false until onlining.
Caller of pfn_valid() expects that they can get valid information from
the struct page. There is no reason to access the struct page if they
can't get valid information from it. So, passing pfn_valid() should
guarantee that, at least, some kind of information is valid.
If pfn_valid() doesn't guarantee it, most of the pfn walker should
check PageResereved() to make sure that validity of information from
the struct page.
> Basically only the nid is set properly. Strictly speaking this is the
> case also without my rework because the zone might change during online
> phase so you cannot assume it is correct even now. It just happens that
> it more or less works just fine.
>
> > 2. pfn_valid() for offlined holes returns false. This can be easily
> > (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> > guess that there is no reason that pfn_valid() returns true for
> > offlined holes. If there is, please let me know.
>
> There is some code which really expects that pfn_valid returns true iff
> there is a struct page and it doesn't care about the online status.
> E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
> do though is to add pfn_to_online_page which would do the proper check.
> I have already sent [1]. As noted above we can (ab)use the remaining bit
> in SECTION_MAP_MASK to detect offline pages more robustly.
Some pfn_valid() caller in hotplug code look wrong. They want to check
section's validity rather than pfn's validity. Others want to access
the struct page so they fit for my assumption (?) for pfn_valid().
Therefore, we can change that pfn_valid() return false until online.
> > 3. We don't need to check PageReserved() in most of pfn walkers in
> > order to check offline holes.
>
> We still have to distinguish those who care about offline pages from
> those who do not care about it.
Hotplug code can distinguish those by another way by using new section
mask as you did in a new patch. If someone excluding hotplug code do
care about offline pages, it would be just for optimization rather
than correteness. I think that it's okay.
Thanks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-21 4:38 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-21 4:38 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> [...]
> > > Which pfn walkers you have in mind?
> >
> > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > using pfn_valid().
>
> Yeah, I've checked that one and in fact this is a good example of the
> case where you do not really care about holes. It just checks the page
> count which is a valid information under any circumstances.
I don't think so. First, it checks the page *map* count. Is it still valid
even if PageReserved() is set? What I'd like to ask in this example is
that what information is valid if PageReserved() is set. Is there any
design document on this? I think that we need to define/document it first.
And, I hope that all the information in flags field is valid in all
cases if pfn_valid() return true. By the design.
This makes all the exsiting pfn walkers happy since we don't need an
additional check for PageReserved().
>
> > > > The other problem I found is that your change will makes some
> > > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > > by memblock API is also marked as PageResereved. If we consider this as
> > > > a hole, we will set such a zone as non-contiguous.
> > >
> > > Why would that be a problem? We shouldn't touch those pages anyway?
> >
> > Skipping those pages in compaction are valid so no problem in this
> > case.
> >
> > The problem I mentioned above is that adding PageReserved() check in
> > __pageblock_pfn_to_page() invalidates optimization by
> > set_zone_contiguous(). In compaction, we need to get a valid struct
> > page and it requires a lot of work. There is performance problem
> > report due to this so set_zone_contiguous() optimization is added. It
> > checks if the zone is contiguous or not in boot time. If zone is
> > determined as contiguous, we can easily get a valid struct page in
> > runtime without expensive checks.
>
> OK, I see. I've had some vague understading and the clarification helps.
>
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
>
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
> - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
> - drop this patch
> - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
>
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?
I like #1 among of above options and I already see your patch for #1.
It's much better than your first attempt but I'm still not happy due
to the semantic of pfn_valid().
> [..]
> > Let me clarify my desire(?) for this issue.
> >
> > 1. If pfn_valid() returns true, struct page has valid information, at
> > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > without checking PageResereved().
>
> This is no longer true after my rework. Pages are associated with the
> zone during _onlining_ rather than when they are physically hotpluged.
If your rework make information valid during _onlining_, my
suggestion is making pfn_valid() return false until onlining.
Caller of pfn_valid() expects that they can get valid information from
the struct page. There is no reason to access the struct page if they
can't get valid information from it. So, passing pfn_valid() should
guarantee that, at least, some kind of information is valid.
If pfn_valid() doesn't guarantee it, most of the pfn walker should
check PageResereved() to make sure that validity of information from
the struct page.
> Basically only the nid is set properly. Strictly speaking this is the
> case also without my rework because the zone might change during online
> phase so you cannot assume it is correct even now. It just happens that
> it more or less works just fine.
>
> > 2. pfn_valid() for offlined holes returns false. This can be easily
> > (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> > guess that there is no reason that pfn_valid() returns true for
> > offlined holes. If there is, please let me know.
>
> There is some code which really expects that pfn_valid returns true iff
> there is a struct page and it doesn't care about the online status.
> E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
> do though is to add pfn_to_online_page which would do the proper check.
> I have already sent [1]. As noted above we can (ab)use the remaining bit
> in SECTION_MAP_MASK to detect offline pages more robustly.
Some pfn_valid() caller in hotplug code look wrong. They want to check
section's validity rather than pfn's validity. Others want to access
the struct page so they fit for my assumption (?) for pfn_valid().
Therefore, we can change that pfn_valid() return false until online.
> > 3. We don't need to check PageReserved() in most of pfn walkers in
> > order to check offline holes.
>
> We still have to distinguish those who care about offline pages from
> those who do not care about it.
Hotplug code can distinguish those by another way by using new section
mask as you did in a new patch. If someone excluding hotplug code do
care about offline pages, it would be just for optimization rather
than correteness. I think that it's okay.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-21 4:38 ` Joonsoo Kim
@ 2017-04-21 7:16 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-21 7:16 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > [...]
> > > > Which pfn walkers you have in mind?
> > >
> > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > using pfn_valid().
> >
> > Yeah, I've checked that one and in fact this is a good example of the
> > case where you do not really care about holes. It just checks the page
> > count which is a valid information under any circumstances.
>
> I don't think so. First, it checks the page *map* count. Is it still valid
> even if PageReserved() is set?
I do not know about any user which would manipulate page map count for
referenced pages. The core MM code doesn't.
> What I'd like to ask in this example is
> that what information is valid if PageReserved() is set. Is there any
> design document on this? I think that we need to define/document it first.
NO, it is not AFAIK.
[...]
> > OK, fair enough. I did't consider memblock allocations. I will rethink
> > this patch but there are essentially 3 options
> > - use a different criterion for the offline holes dection. I
> > have just realized we might do it by storing the online
> > information into the mem sections
> > - drop this patch
> > - move the PageReferenced check down the chain into
> > isolate_freepages_block resp. isolate_migratepages_block
> >
> > I would prefer 3 over 2 over 1. I definitely want to make this more
> > robust so 1 is preferable long term but I do not want this to be a
> > roadblock to the rest of the rework. Does that sound acceptable to you?
>
> I like #1 among of above options and I already see your patch for #1.
> It's much better than your first attempt but I'm still not happy due
> to the semantic of pfn_valid().
You are trying to change a semantic of something that has a well defined
meaning. I disagree that we should change it. It might sound like a
simpler thing to do because pfn walkers will have to be checked but what
you are proposing is conflating two different things together.
> > [..]
> > > Let me clarify my desire(?) for this issue.
> > >
> > > 1. If pfn_valid() returns true, struct page has valid information, at
> > > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > > without checking PageResereved().
> >
> > This is no longer true after my rework. Pages are associated with the
> > zone during _onlining_ rather than when they are physically hotpluged.
>
> If your rework make information valid during _onlining_, my
> suggestion is making pfn_valid() return false until onlining.
>
> Caller of pfn_valid() expects that they can get valid information from
> the struct page. There is no reason to access the struct page if they
> can't get valid information from it. So, passing pfn_valid() should
> guarantee that, at least, some kind of information is valid.
>
> If pfn_valid() doesn't guarantee it, most of the pfn walker should
> check PageResereved() to make sure that validity of information from
> the struct page.
This is true only for those walkers which really depend on the full
initialization. This is not the case for all of them. I do not see any
reason to introduce another _pfn_valid to just check whether there is a
struct page...
So please do not conflate those two different concepts together. I
believe that the most prominent pfn walkers should be covered now and
others can be evaluated later.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-21 7:16 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-21 7:16 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > [...]
> > > > Which pfn walkers you have in mind?
> > >
> > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > using pfn_valid().
> >
> > Yeah, I've checked that one and in fact this is a good example of the
> > case where you do not really care about holes. It just checks the page
> > count which is a valid information under any circumstances.
>
> I don't think so. First, it checks the page *map* count. Is it still valid
> even if PageReserved() is set?
I do not know about any user which would manipulate page map count for
referenced pages. The core MM code doesn't.
> What I'd like to ask in this example is
> that what information is valid if PageReserved() is set. Is there any
> design document on this? I think that we need to define/document it first.
NO, it is not AFAIK.
[...]
> > OK, fair enough. I did't consider memblock allocations. I will rethink
> > this patch but there are essentially 3 options
> > - use a different criterion for the offline holes dection. I
> > have just realized we might do it by storing the online
> > information into the mem sections
> > - drop this patch
> > - move the PageReferenced check down the chain into
> > isolate_freepages_block resp. isolate_migratepages_block
> >
> > I would prefer 3 over 2 over 1. I definitely want to make this more
> > robust so 1 is preferable long term but I do not want this to be a
> > roadblock to the rest of the rework. Does that sound acceptable to you?
>
> I like #1 among of above options and I already see your patch for #1.
> It's much better than your first attempt but I'm still not happy due
> to the semantic of pfn_valid().
You are trying to change a semantic of something that has a well defined
meaning. I disagree that we should change it. It might sound like a
simpler thing to do because pfn walkers will have to be checked but what
you are proposing is conflating two different things together.
> > [..]
> > > Let me clarify my desire(?) for this issue.
> > >
> > > 1. If pfn_valid() returns true, struct page has valid information, at
> > > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > > without checking PageResereved().
> >
> > This is no longer true after my rework. Pages are associated with the
> > zone during _onlining_ rather than when they are physically hotpluged.
>
> If your rework make information valid during _onlining_, my
> suggestion is making pfn_valid() return false until onlining.
>
> Caller of pfn_valid() expects that they can get valid information from
> the struct page. There is no reason to access the struct page if they
> can't get valid information from it. So, passing pfn_valid() should
> guarantee that, at least, some kind of information is valid.
>
> If pfn_valid() doesn't guarantee it, most of the pfn walker should
> check PageResereved() to make sure that validity of information from
> the struct page.
This is true only for those walkers which really depend on the full
initialization. This is not the case for all of them. I do not see any
reason to introduce another _pfn_valid to just check whether there is a
struct page...
So please do not conflate those two different concepts together. I
believe that the most prominent pfn walkers should be covered now and
others can be evaluated later.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-21 7:16 ` Michal Hocko
@ 2017-04-24 1:44 ` Joonsoo Kim
-1 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-24 1:44 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > [...]
> > > > > Which pfn walkers you have in mind?
> > > >
> > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > using pfn_valid().
> > >
> > > Yeah, I've checked that one and in fact this is a good example of the
> > > case where you do not really care about holes. It just checks the page
> > > count which is a valid information under any circumstances.
> >
> > I don't think so. First, it checks the page *map* count. Is it still valid
> > even if PageReserved() is set?
>
> I do not know about any user which would manipulate page map count for
> referenced pages. The core MM code doesn't.
That's weird that we can get *map* count without PageReserved() check,
but we cannot get zone information.
Zone information is more static information than map count.
It should be defined/documented in this time that what information in
the struct page is valid even if PageReserved() is set. And then, we
need to fix all the things based on this design decision.
>
> > What I'd like to ask in this example is
> > that what information is valid if PageReserved() is set. Is there any
> > design document on this? I think that we need to define/document it first.
>
> NO, it is not AFAIK.
>
> [...]
> > > OK, fair enough. I did't consider memblock allocations. I will rethink
> > > this patch but there are essentially 3 options
> > > - use a different criterion for the offline holes dection. I
> > > have just realized we might do it by storing the online
> > > information into the mem sections
> > > - drop this patch
> > > - move the PageReferenced check down the chain into
> > > isolate_freepages_block resp. isolate_migratepages_block
> > >
> > > I would prefer 3 over 2 over 1. I definitely want to make this more
> > > robust so 1 is preferable long term but I do not want this to be a
> > > roadblock to the rest of the rework. Does that sound acceptable to you?
> >
> > I like #1 among of above options and I already see your patch for #1.
> > It's much better than your first attempt but I'm still not happy due
> > to the semantic of pfn_valid().
>
> You are trying to change a semantic of something that has a well defined
> meaning. I disagree that we should change it. It might sound like a
> simpler thing to do because pfn walkers will have to be checked but what
> you are proposing is conflating two different things together.
I don't think that *I* try to change the semantic of pfn_valid().
It would be original semantic of pfn_valid().
"If pfn_valid() returns true, we can get proper struct page and the
zone information,"
That situation is now being changed by your patch *hotplug rework*.
"Even if pfn_valid() returns true, we cannot get the zone information
without PageReserved() check, since *zone is determined during
onlining* and pfn_valid() return true after adding the memory."
>
> > > [..]
> > > > Let me clarify my desire(?) for this issue.
> > > >
> > > > 1. If pfn_valid() returns true, struct page has valid information, at
> > > > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > > > without checking PageResereved().
> > >
> > > This is no longer true after my rework. Pages are associated with the
> > > zone during _onlining_ rather than when they are physically hotpluged.
> >
> > If your rework make information valid during _onlining_, my
> > suggestion is making pfn_valid() return false until onlining.
> >
> > Caller of pfn_valid() expects that they can get valid information from
> > the struct page. There is no reason to access the struct page if they
> > can't get valid information from it. So, passing pfn_valid() should
> > guarantee that, at least, some kind of information is valid.
> >
> > If pfn_valid() doesn't guarantee it, most of the pfn walker should
> > check PageResereved() to make sure that validity of information from
> > the struct page.
>
> This is true only for those walkers which really depend on the full
> initialization. This is not the case for all of them. I do not see any
> reason to introduce another _pfn_valid to just check whether there is a
> struct page...
It's really confusing concept that only some information is valid for
*not* fully initialized struct page. Even, there is no document that
what information is valid for this half-initialized struct page.
Better design would be that we regard that every information is
invalid for half-initialized struct page. In this case, it's natural
to make pfn_valid() returns false for this half-initialized struct page.
>
> So please do not conflate those two different concepts together. I
> believe that the most prominent pfn walkers should be covered now and
> others can be evaluated later.
Even if original pfn_valid()'s semantic is not the one that I mentioned,
I think that suggested semantic from me is better.
Only hotplug code need to be changed and others doesn't need to be changed.
There is no overhead for others. What's the problem about this approach?
And, I'm not sure that you covered the most prominent pfn walkers.
Please see pagetypeinfo_showblockcount_print() in mm/vmstat.c.
As you admitted, additional check approach is really error-prone and
this example shows that.
Thanks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-24 1:44 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-24 1:44 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > [...]
> > > > > Which pfn walkers you have in mind?
> > > >
> > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > using pfn_valid().
> > >
> > > Yeah, I've checked that one and in fact this is a good example of the
> > > case where you do not really care about holes. It just checks the page
> > > count which is a valid information under any circumstances.
> >
> > I don't think so. First, it checks the page *map* count. Is it still valid
> > even if PageReserved() is set?
>
> I do not know about any user which would manipulate page map count for
> referenced pages. The core MM code doesn't.
That's weird that we can get *map* count without PageReserved() check,
but we cannot get zone information.
Zone information is more static information than map count.
It should be defined/documented in this time that what information in
the struct page is valid even if PageReserved() is set. And then, we
need to fix all the things based on this design decision.
>
> > What I'd like to ask in this example is
> > that what information is valid if PageReserved() is set. Is there any
> > design document on this? I think that we need to define/document it first.
>
> NO, it is not AFAIK.
>
> [...]
> > > OK, fair enough. I did't consider memblock allocations. I will rethink
> > > this patch but there are essentially 3 options
> > > - use a different criterion for the offline holes dection. I
> > > have just realized we might do it by storing the online
> > > information into the mem sections
> > > - drop this patch
> > > - move the PageReferenced check down the chain into
> > > isolate_freepages_block resp. isolate_migratepages_block
> > >
> > > I would prefer 3 over 2 over 1. I definitely want to make this more
> > > robust so 1 is preferable long term but I do not want this to be a
> > > roadblock to the rest of the rework. Does that sound acceptable to you?
> >
> > I like #1 among of above options and I already see your patch for #1.
> > It's much better than your first attempt but I'm still not happy due
> > to the semantic of pfn_valid().
>
> You are trying to change a semantic of something that has a well defined
> meaning. I disagree that we should change it. It might sound like a
> simpler thing to do because pfn walkers will have to be checked but what
> you are proposing is conflating two different things together.
I don't think that *I* try to change the semantic of pfn_valid().
It would be original semantic of pfn_valid().
"If pfn_valid() returns true, we can get proper struct page and the
zone information,"
That situation is now being changed by your patch *hotplug rework*.
"Even if pfn_valid() returns true, we cannot get the zone information
without PageReserved() check, since *zone is determined during
onlining* and pfn_valid() return true after adding the memory."
>
> > > [..]
> > > > Let me clarify my desire(?) for this issue.
> > > >
> > > > 1. If pfn_valid() returns true, struct page has valid information, at
> > > > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > > > without checking PageResereved().
> > >
> > > This is no longer true after my rework. Pages are associated with the
> > > zone during _onlining_ rather than when they are physically hotpluged.
> >
> > If your rework make information valid during _onlining_, my
> > suggestion is making pfn_valid() return false until onlining.
> >
> > Caller of pfn_valid() expects that they can get valid information from
> > the struct page. There is no reason to access the struct page if they
> > can't get valid information from it. So, passing pfn_valid() should
> > guarantee that, at least, some kind of information is valid.
> >
> > If pfn_valid() doesn't guarantee it, most of the pfn walker should
> > check PageResereved() to make sure that validity of information from
> > the struct page.
>
> This is true only for those walkers which really depend on the full
> initialization. This is not the case for all of them. I do not see any
> reason to introduce another _pfn_valid to just check whether there is a
> struct page...
It's really confusing concept that only some information is valid for
*not* fully initialized struct page. Even, there is no document that
what information is valid for this half-initialized struct page.
Better design would be that we regard that every information is
invalid for half-initialized struct page. In this case, it's natural
to make pfn_valid() returns false for this half-initialized struct page.
>
> So please do not conflate those two different concepts together. I
> believe that the most prominent pfn walkers should be covered now and
> others can be evaluated later.
Even if original pfn_valid()'s semantic is not the one that I mentioned,
I think that suggested semantic from me is better.
Only hotplug code need to be changed and others doesn't need to be changed.
There is no overhead for others. What's the problem about this approach?
And, I'm not sure that you covered the most prominent pfn walkers.
Please see pagetypeinfo_showblockcount_print() in mm/vmstat.c.
As you admitted, additional check approach is really error-prone and
this example shows that.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-24 1:44 ` Joonsoo Kim
@ 2017-04-24 7:53 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-24 7:53 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > [...]
> > > > > > Which pfn walkers you have in mind?
> > > > >
> > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > using pfn_valid().
> > > >
> > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > case where you do not really care about holes. It just checks the page
> > > > count which is a valid information under any circumstances.
> > >
> > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > even if PageReserved() is set?
> >
> > I do not know about any user which would manipulate page map count for
> > referenced pages. The core MM code doesn't.
>
> That's weird that we can get *map* count without PageReserved() check,
> but we cannot get zone information.
> Zone information is more static information than map count.
As I've already pointed out the rework of the hotplug code is mainly
about postponing the zone initialization from the physical hot add to
the logical onlining. The zone is really not clear until that moment.
> It should be defined/documented in this time that what information in
> the struct page is valid even if PageReserved() is set. And then, we
> need to fix all the things based on this design decision.
Where would you suggest documenting this? We do have
Documentation/memory-hotplug.txt but it is not really specific about
struct page.
[...]
> > You are trying to change a semantic of something that has a well defined
> > meaning. I disagree that we should change it. It might sound like a
> > simpler thing to do because pfn walkers will have to be checked but what
> > you are proposing is conflating two different things together.
>
> I don't think that *I* try to change the semantic of pfn_valid().
> It would be original semantic of pfn_valid().
>
> "If pfn_valid() returns true, we can get proper struct page and the
> zone information,"
I do not see any guarantee about the zone information anywhere. In fact
this is not true with the original implementation as I've tried to
explain already. We do have new pages associated with a zone but that
association might change during the online phase. So you cannot really
rely on that information until the page is online. There is no real
change in that regards after my rework.
[...]
> > So please do not conflate those two different concepts together. I
> > believe that the most prominent pfn walkers should be covered now and
> > others can be evaluated later.
>
> Even if original pfn_valid()'s semantic is not the one that I mentioned,
> I think that suggested semantic from me is better.
> Only hotplug code need to be changed and others doesn't need to be changed.
> There is no overhead for others. What's the problem about this approach?
That this would require to check _every_ single pfn_valid user in the
kernel. That is beyond my time capacity and not really necessary because
the current code already suffers from the same/similar class of
problems.
> And, I'm not sure that you covered the most prominent pfn walkers.
> Please see pagetypeinfo_showblockcount_print() in mm/vmstat.c.
I probably haven't (and will send a patch to fix this one - thanks for
pointing to it) but the point is they those are broken already and they
can be fixed in follow up patches. If you change pfn_valid you might
break an existing code in an unexpected ways.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-24 7:53 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-24 7:53 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > [...]
> > > > > > Which pfn walkers you have in mind?
> > > > >
> > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > using pfn_valid().
> > > >
> > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > case where you do not really care about holes. It just checks the page
> > > > count which is a valid information under any circumstances.
> > >
> > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > even if PageReserved() is set?
> >
> > I do not know about any user which would manipulate page map count for
> > referenced pages. The core MM code doesn't.
>
> That's weird that we can get *map* count without PageReserved() check,
> but we cannot get zone information.
> Zone information is more static information than map count.
As I've already pointed out the rework of the hotplug code is mainly
about postponing the zone initialization from the physical hot add to
the logical onlining. The zone is really not clear until that moment.
> It should be defined/documented in this time that what information in
> the struct page is valid even if PageReserved() is set. And then, we
> need to fix all the things based on this design decision.
Where would you suggest documenting this? We do have
Documentation/memory-hotplug.txt but it is not really specific about
struct page.
[...]
> > You are trying to change a semantic of something that has a well defined
> > meaning. I disagree that we should change it. It might sound like a
> > simpler thing to do because pfn walkers will have to be checked but what
> > you are proposing is conflating two different things together.
>
> I don't think that *I* try to change the semantic of pfn_valid().
> It would be original semantic of pfn_valid().
>
> "If pfn_valid() returns true, we can get proper struct page and the
> zone information,"
I do not see any guarantee about the zone information anywhere. In fact
this is not true with the original implementation as I've tried to
explain already. We do have new pages associated with a zone but that
association might change during the online phase. So you cannot really
rely on that information until the page is online. There is no real
change in that regards after my rework.
[...]
> > So please do not conflate those two different concepts together. I
> > believe that the most prominent pfn walkers should be covered now and
> > others can be evaluated later.
>
> Even if original pfn_valid()'s semantic is not the one that I mentioned,
> I think that suggested semantic from me is better.
> Only hotplug code need to be changed and others doesn't need to be changed.
> There is no overhead for others. What's the problem about this approach?
That this would require to check _every_ single pfn_valid user in the
kernel. That is beyond my time capacity and not really necessary because
the current code already suffers from the same/similar class of
problems.
> And, I'm not sure that you covered the most prominent pfn walkers.
> Please see pagetypeinfo_showblockcount_print() in mm/vmstat.c.
I probably haven't (and will send a patch to fix this one - thanks for
pointing to it) but the point is they those are broken already and they
can be fixed in follow up patches. If you change pfn_valid you might
break an existing code in an unexpected ways.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-24 7:53 ` Michal Hocko
@ 2017-04-25 2:50 ` Joonsoo Kim
-1 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-25 2:50 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon, Apr 24, 2017 at 09:53:12AM +0200, Michal Hocko wrote:
> On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> > On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > > [...]
> > > > > > > Which pfn walkers you have in mind?
> > > > > >
> > > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > > using pfn_valid().
> > > > >
> > > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > > case where you do not really care about holes. It just checks the page
> > > > > count which is a valid information under any circumstances.
> > > >
> > > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > > even if PageReserved() is set?
> > >
> > > I do not know about any user which would manipulate page map count for
> > > referenced pages. The core MM code doesn't.
> >
> > That's weird that we can get *map* count without PageReserved() check,
> > but we cannot get zone information.
> > Zone information is more static information than map count.
>
> As I've already pointed out the rework of the hotplug code is mainly
> about postponing the zone initialization from the physical hot add to
> the logical onlining. The zone is really not clear until that moment.
>
> > It should be defined/documented in this time that what information in
> > the struct page is valid even if PageReserved() is set. And then, we
> > need to fix all the things based on this design decision.
>
> Where would you suggest documenting this? We do have
> Documentation/memory-hotplug.txt but it is not really specific about
> struct page.
pfn_valid() in include/linux/mmzone.h looks proper place.
>
> [...]
>
> > > You are trying to change a semantic of something that has a well defined
> > > meaning. I disagree that we should change it. It might sound like a
> > > simpler thing to do because pfn walkers will have to be checked but what
> > > you are proposing is conflating two different things together.
> >
> > I don't think that *I* try to change the semantic of pfn_valid().
> > It would be original semantic of pfn_valid().
> >
> > "If pfn_valid() returns true, we can get proper struct page and the
> > zone information,"
>
> I do not see any guarantee about the zone information anywhere. In fact
> this is not true with the original implementation as I've tried to
> explain already. We do have new pages associated with a zone but that
> association might change during the online phase. So you cannot really
> rely on that information until the page is online. There is no real
> change in that regards after my rework.
I know that what you did doesn't change thing much. What I try to say
is that previous implementation related to pfn_valid() in hotplug is
wrong. Please do not assume that hotplug implementation is correct and
other pfn_valid() users are incorrect. There is no design document so
I'm not sure which one is correct but assumption that pfn_valid() user
can access whole the struct page information makes much sense to me.
So, I hope that please fix hotplug implementation rather than
modifying each pfn_valid() users.
>
> [...]
> > > So please do not conflate those two different concepts together. I
> > > believe that the most prominent pfn walkers should be covered now and
> > > others can be evaluated later.
> >
> > Even if original pfn_valid()'s semantic is not the one that I mentioned,
> > I think that suggested semantic from me is better.
> > Only hotplug code need to be changed and others doesn't need to be changed.
> > There is no overhead for others. What's the problem about this approach?
>
> That this would require to check _every_ single pfn_valid user in the
> kernel. That is beyond my time capacity and not really necessary because
> the current code already suffers from the same/similar class of
> problems.
I think that all the pfn_valid() user doesn't consider hole case.
Unlike your expectation, if your way is taken, it requires to check
_every_ pfn_valid() users.
Thanks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-25 2:50 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-25 2:50 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon, Apr 24, 2017 at 09:53:12AM +0200, Michal Hocko wrote:
> On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> > On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > > [...]
> > > > > > > Which pfn walkers you have in mind?
> > > > > >
> > > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > > using pfn_valid().
> > > > >
> > > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > > case where you do not really care about holes. It just checks the page
> > > > > count which is a valid information under any circumstances.
> > > >
> > > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > > even if PageReserved() is set?
> > >
> > > I do not know about any user which would manipulate page map count for
> > > referenced pages. The core MM code doesn't.
> >
> > That's weird that we can get *map* count without PageReserved() check,
> > but we cannot get zone information.
> > Zone information is more static information than map count.
>
> As I've already pointed out the rework of the hotplug code is mainly
> about postponing the zone initialization from the physical hot add to
> the logical onlining. The zone is really not clear until that moment.
>
> > It should be defined/documented in this time that what information in
> > the struct page is valid even if PageReserved() is set. And then, we
> > need to fix all the things based on this design decision.
>
> Where would you suggest documenting this? We do have
> Documentation/memory-hotplug.txt but it is not really specific about
> struct page.
pfn_valid() in include/linux/mmzone.h looks proper place.
>
> [...]
>
> > > You are trying to change a semantic of something that has a well defined
> > > meaning. I disagree that we should change it. It might sound like a
> > > simpler thing to do because pfn walkers will have to be checked but what
> > > you are proposing is conflating two different things together.
> >
> > I don't think that *I* try to change the semantic of pfn_valid().
> > It would be original semantic of pfn_valid().
> >
> > "If pfn_valid() returns true, we can get proper struct page and the
> > zone information,"
>
> I do not see any guarantee about the zone information anywhere. In fact
> this is not true with the original implementation as I've tried to
> explain already. We do have new pages associated with a zone but that
> association might change during the online phase. So you cannot really
> rely on that information until the page is online. There is no real
> change in that regards after my rework.
I know that what you did doesn't change thing much. What I try to say
is that previous implementation related to pfn_valid() in hotplug is
wrong. Please do not assume that hotplug implementation is correct and
other pfn_valid() users are incorrect. There is no design document so
I'm not sure which one is correct but assumption that pfn_valid() user
can access whole the struct page information makes much sense to me.
So, I hope that please fix hotplug implementation rather than
modifying each pfn_valid() users.
>
> [...]
> > > So please do not conflate those two different concepts together. I
> > > believe that the most prominent pfn walkers should be covered now and
> > > others can be evaluated later.
> >
> > Even if original pfn_valid()'s semantic is not the one that I mentioned,
> > I think that suggested semantic from me is better.
> > Only hotplug code need to be changed and others doesn't need to be changed.
> > There is no overhead for others. What's the problem about this approach?
>
> That this would require to check _every_ single pfn_valid user in the
> kernel. That is beyond my time capacity and not really necessary because
> the current code already suffers from the same/similar class of
> problems.
I think that all the pfn_valid() user doesn't consider hole case.
Unlike your expectation, if your way is taken, it requires to check
_every_ pfn_valid() users.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-25 2:50 ` Joonsoo Kim
@ 2017-04-26 9:19 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-26 9:19 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Tue 25-04-17 11:50:45, Joonsoo Kim wrote:
> On Mon, Apr 24, 2017 at 09:53:12AM +0200, Michal Hocko wrote:
> > On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> > > On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > > > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > > > [...]
> > > > > > > > Which pfn walkers you have in mind?
> > > > > > >
> > > > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > > > using pfn_valid().
> > > > > >
> > > > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > > > case where you do not really care about holes. It just checks the page
> > > > > > count which is a valid information under any circumstances.
> > > > >
> > > > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > > > even if PageReserved() is set?
> > > >
> > > > I do not know about any user which would manipulate page map count for
> > > > referenced pages. The core MM code doesn't.
> > >
> > > That's weird that we can get *map* count without PageReserved() check,
> > > but we cannot get zone information.
> > > Zone information is more static information than map count.
> >
> > As I've already pointed out the rework of the hotplug code is mainly
> > about postponing the zone initialization from the physical hot add to
> > the logical onlining. The zone is really not clear until that moment.
> >
> > > It should be defined/documented in this time that what information in
> > > the struct page is valid even if PageReserved() is set. And then, we
> > > need to fix all the things based on this design decision.
> >
> > Where would you suggest documenting this? We do have
> > Documentation/memory-hotplug.txt but it is not really specific about
> > struct page.
>
> pfn_valid() in include/linux/mmzone.h looks proper place.
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c412e6a3a1e9..443258fcac93 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1288,10 +1288,14 @@ unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long);
#ifdef CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
/*
* pfn_valid() is meant to be able to tell if a given PFN has valid memmap
- * associated with it or not. In FLATMEM, it is expected that holes always
- * have valid memmap as long as there is valid PFNs either side of the hole.
- * In SPARSEMEM, it is assumed that a valid section has a memmap for the
- * entire section.
+ * associated with it or not. This means that a struct page exists for this
+ * pfn. The caller cannot assume the page is fully initialized though.
+ * pfn_to_online_page() should be used to make sure the struct page is fully
+ * initialized.
+ *
+ * In FLATMEM, it is expected that holes always have valid memmap as long as
+ * there is valid PFNs either side of the hole. In SPARSEMEM, it is assumed
+ * that a valid section has a memmap for the entire section.
*
* However, an ARM, and maybe other embedded architectures in the future
* free memmap backing holes to save memory on the assumption the memmap is
> > [...]
> >
> > > > You are trying to change a semantic of something that has a well defined
> > > > meaning. I disagree that we should change it. It might sound like a
> > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > you are proposing is conflating two different things together.
> > >
> > > I don't think that *I* try to change the semantic of pfn_valid().
> > > It would be original semantic of pfn_valid().
> > >
> > > "If pfn_valid() returns true, we can get proper struct page and the
> > > zone information,"
> >
> > I do not see any guarantee about the zone information anywhere. In fact
> > this is not true with the original implementation as I've tried to
> > explain already. We do have new pages associated with a zone but that
> > association might change during the online phase. So you cannot really
> > rely on that information until the page is online. There is no real
> > change in that regards after my rework.
>
> I know that what you did doesn't change thing much. What I try to say
> is that previous implementation related to pfn_valid() in hotplug is
> wrong. Please do not assume that hotplug implementation is correct and
> other pfn_valid() users are incorrect. There is no design document so
> I'm not sure which one is correct but assumption that pfn_valid() user
> can access whole the struct page information makes much sense to me.
Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
still need pfn_valid to work for those pfns. Really, pfn_valid has a
different meaning than you would like it to have. Who knows how many
others like that are lurking there. I feel much more comfortable to go
and hunt already broken code and fix it rathert than break something
unexpectedly.
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-26 9:19 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-26 9:19 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Tue 25-04-17 11:50:45, Joonsoo Kim wrote:
> On Mon, Apr 24, 2017 at 09:53:12AM +0200, Michal Hocko wrote:
> > On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> > > On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > > > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > > > [...]
> > > > > > > > Which pfn walkers you have in mind?
> > > > > > >
> > > > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > > > using pfn_valid().
> > > > > >
> > > > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > > > case where you do not really care about holes. It just checks the page
> > > > > > count which is a valid information under any circumstances.
> > > > >
> > > > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > > > even if PageReserved() is set?
> > > >
> > > > I do not know about any user which would manipulate page map count for
> > > > referenced pages. The core MM code doesn't.
> > >
> > > That's weird that we can get *map* count without PageReserved() check,
> > > but we cannot get zone information.
> > > Zone information is more static information than map count.
> >
> > As I've already pointed out the rework of the hotplug code is mainly
> > about postponing the zone initialization from the physical hot add to
> > the logical onlining. The zone is really not clear until that moment.
> >
> > > It should be defined/documented in this time that what information in
> > > the struct page is valid even if PageReserved() is set. And then, we
> > > need to fix all the things based on this design decision.
> >
> > Where would you suggest documenting this? We do have
> > Documentation/memory-hotplug.txt but it is not really specific about
> > struct page.
>
> pfn_valid() in include/linux/mmzone.h looks proper place.
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c412e6a3a1e9..443258fcac93 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1288,10 +1288,14 @@ unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long);
#ifdef CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
/*
* pfn_valid() is meant to be able to tell if a given PFN has valid memmap
- * associated with it or not. In FLATMEM, it is expected that holes always
- * have valid memmap as long as there is valid PFNs either side of the hole.
- * In SPARSEMEM, it is assumed that a valid section has a memmap for the
- * entire section.
+ * associated with it or not. This means that a struct page exists for this
+ * pfn. The caller cannot assume the page is fully initialized though.
+ * pfn_to_online_page() should be used to make sure the struct page is fully
+ * initialized.
+ *
+ * In FLATMEM, it is expected that holes always have valid memmap as long as
+ * there is valid PFNs either side of the hole. In SPARSEMEM, it is assumed
+ * that a valid section has a memmap for the entire section.
*
* However, an ARM, and maybe other embedded architectures in the future
* free memmap backing holes to save memory on the assumption the memmap is
> > [...]
> >
> > > > You are trying to change a semantic of something that has a well defined
> > > > meaning. I disagree that we should change it. It might sound like a
> > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > you are proposing is conflating two different things together.
> > >
> > > I don't think that *I* try to change the semantic of pfn_valid().
> > > It would be original semantic of pfn_valid().
> > >
> > > "If pfn_valid() returns true, we can get proper struct page and the
> > > zone information,"
> >
> > I do not see any guarantee about the zone information anywhere. In fact
> > this is not true with the original implementation as I've tried to
> > explain already. We do have new pages associated with a zone but that
> > association might change during the online phase. So you cannot really
> > rely on that information until the page is online. There is no real
> > change in that regards after my rework.
>
> I know that what you did doesn't change thing much. What I try to say
> is that previous implementation related to pfn_valid() in hotplug is
> wrong. Please do not assume that hotplug implementation is correct and
> other pfn_valid() users are incorrect. There is no design document so
> I'm not sure which one is correct but assumption that pfn_valid() user
> can access whole the struct page information makes much sense to me.
Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
still need pfn_valid to work for those pfns. Really, pfn_valid has a
different meaning than you would like it to have. Who knows how many
others like that are lurking there. I feel much more comfortable to go
and hunt already broken code and fix it rathert than break something
unexpectedly.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-26 9:19 ` Michal Hocko
@ 2017-04-27 2:08 ` Joonsoo Kim
-1 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-27 2:08 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > [...]
> > >
> > > > > You are trying to change a semantic of something that has a well defined
> > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > you are proposing is conflating two different things together.
> > > >
> > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > It would be original semantic of pfn_valid().
> > > >
> > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > zone information,"
> > >
> > > I do not see any guarantee about the zone information anywhere. In fact
> > > this is not true with the original implementation as I've tried to
> > > explain already. We do have new pages associated with a zone but that
> > > association might change during the online phase. So you cannot really
> > > rely on that information until the page is online. There is no real
> > > change in that regards after my rework.
> >
> > I know that what you did doesn't change thing much. What I try to say
> > is that previous implementation related to pfn_valid() in hotplug is
> > wrong. Please do not assume that hotplug implementation is correct and
> > other pfn_valid() users are incorrect. There is no design document so
> > I'm not sure which one is correct but assumption that pfn_valid() user
> > can access whole the struct page information makes much sense to me.
>
> Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> still need pfn_valid to work for those pfns. Really, pfn_valid has a
It's really contrary example to your insist. They requires not only
struct page but also other information, especially, the zone index.
They checks zone idx to know whether this page is for ZONE_DEVICE or not.
So, pfn_valid() for ZONE_DEVICE pages assume that struct page has all
the valid information. It's perfectly matched with my suggestion.
Online isn't important issue here. What the important point is the condition
that pfn_valid() return true. pfn_valid() for ZONE_DEVICE returns true after
arch_add_memory() since all the struct page information is fixed there.
If zone of hotplugged memory cannot be fixed at this moment, you can
defef it until all the information is fixed (onlining). That
seems to be better semantic of pfn_valid() to me.
> different meaning than you would like it to have. Who knows how many
> others like that are lurking there. I feel much more comfortable to go
> and hunt already broken code and fix it rathert than break something
> unexpectedly.
I think that I did my best to explain my reasoning. It seems that we
cannot agree with each other so it's better for some others to express
their opinion to this problem. I will stop this discussion from now
on.
Thanks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-27 2:08 ` Joonsoo Kim
0 siblings, 0 replies; 669+ messages in thread
From: Joonsoo Kim @ 2017-04-27 2:08 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > [...]
> > >
> > > > > You are trying to change a semantic of something that has a well defined
> > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > you are proposing is conflating two different things together.
> > > >
> > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > It would be original semantic of pfn_valid().
> > > >
> > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > zone information,"
> > >
> > > I do not see any guarantee about the zone information anywhere. In fact
> > > this is not true with the original implementation as I've tried to
> > > explain already. We do have new pages associated with a zone but that
> > > association might change during the online phase. So you cannot really
> > > rely on that information until the page is online. There is no real
> > > change in that regards after my rework.
> >
> > I know that what you did doesn't change thing much. What I try to say
> > is that previous implementation related to pfn_valid() in hotplug is
> > wrong. Please do not assume that hotplug implementation is correct and
> > other pfn_valid() users are incorrect. There is no design document so
> > I'm not sure which one is correct but assumption that pfn_valid() user
> > can access whole the struct page information makes much sense to me.
>
> Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> still need pfn_valid to work for those pfns. Really, pfn_valid has a
It's really contrary example to your insist. They requires not only
struct page but also other information, especially, the zone index.
They checks zone idx to know whether this page is for ZONE_DEVICE or not.
So, pfn_valid() for ZONE_DEVICE pages assume that struct page has all
the valid information. It's perfectly matched with my suggestion.
Online isn't important issue here. What the important point is the condition
that pfn_valid() return true. pfn_valid() for ZONE_DEVICE returns true after
arch_add_memory() since all the struct page information is fixed there.
If zone of hotplugged memory cannot be fixed at this moment, you can
defef it until all the information is fixed (onlining). That
seems to be better semantic of pfn_valid() to me.
> different meaning than you would like it to have. Who knows how many
> others like that are lurking there. I feel much more comfortable to go
> and hunt already broken code and fix it rathert than break something
> unexpectedly.
I think that I did my best to explain my reasoning. It seems that we
cannot agree with each other so it's better for some others to express
their opinion to this problem. I will stop this discussion from now
on.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2017-04-27 2:08 ` Joonsoo Kim
@ 2017-04-27 15:10 ` Michal Hocko
-1 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-27 15:10 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 27-04-17 11:08:38, Joonsoo Kim wrote:
> On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > > [...]
> > > >
> > > > > > You are trying to change a semantic of something that has a well defined
> > > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > > you are proposing is conflating two different things together.
> > > > >
> > > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > > It would be original semantic of pfn_valid().
> > > > >
> > > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > > zone information,"
> > > >
> > > > I do not see any guarantee about the zone information anywhere. In fact
> > > > this is not true with the original implementation as I've tried to
> > > > explain already. We do have new pages associated with a zone but that
> > > > association might change during the online phase. So you cannot really
> > > > rely on that information until the page is online. There is no real
> > > > change in that regards after my rework.
> > >
> > > I know that what you did doesn't change thing much. What I try to say
> > > is that previous implementation related to pfn_valid() in hotplug is
> > > wrong. Please do not assume that hotplug implementation is correct and
> > > other pfn_valid() users are incorrect. There is no design document so
> > > I'm not sure which one is correct but assumption that pfn_valid() user
> > > can access whole the struct page information makes much sense to me.
> >
> > Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> > still need pfn_valid to work for those pfns. Really, pfn_valid has a
>
> It's really contrary example to your insist. They requires not only
> struct page but also other information, especially, the zone index.
> They checks zone idx to know whether this page is for ZONE_DEVICE or not.
Yes and they guarantee this association is true. Without memory onlining
though. This memory is never online for anybody who is asking.
[...]
> I think that I did my best to explain my reasoning. It seems that we
> cannot agree with each other so it's better for some others to express
> their opinion to this problem. I will stop this discussion from now
> on.
I _do_ appreciate your feedback and if the general consensus is to
modify pfn_valid I can go that direction but my gut feeling tells me
that conflating "existing struct page" test and "fully online and
initialized" one is a wrong thing to do.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2017-04-27 15:10 ` Michal Hocko
0 siblings, 0 replies; 669+ messages in thread
From: Michal Hocko @ 2017-04-27 15:10 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 27-04-17 11:08:38, Joonsoo Kim wrote:
> On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > > [...]
> > > >
> > > > > > You are trying to change a semantic of something that has a well defined
> > > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > > you are proposing is conflating two different things together.
> > > > >
> > > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > > It would be original semantic of pfn_valid().
> > > > >
> > > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > > zone information,"
> > > >
> > > > I do not see any guarantee about the zone information anywhere. In fact
> > > > this is not true with the original implementation as I've tried to
> > > > explain already. We do have new pages associated with a zone but that
> > > > association might change during the online phase. So you cannot really
> > > > rely on that information until the page is online. There is no real
> > > > change in that regards after my rework.
> > >
> > > I know that what you did doesn't change thing much. What I try to say
> > > is that previous implementation related to pfn_valid() in hotplug is
> > > wrong. Please do not assume that hotplug implementation is correct and
> > > other pfn_valid() users are incorrect. There is no design document so
> > > I'm not sure which one is correct but assumption that pfn_valid() user
> > > can access whole the struct page information makes much sense to me.
> >
> > Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> > still need pfn_valid to work for those pfns. Really, pfn_valid has a
>
> It's really contrary example to your insist. They requires not only
> struct page but also other information, especially, the zone index.
> They checks zone idx to know whether this page is for ZONE_DEVICE or not.
Yes and they guarantee this association is true. Without memory onlining
though. This memory is never online for anybody who is asking.
[...]
> I think that I did my best to explain my reasoning. It seems that we
> cannot agree with each other so it's better for some others to express
> their opinion to this problem. I will stop this discussion from now
> on.
I _do_ appreciate your feedback and if the general consensus is to
modify pfn_valid I can go that direction but my gut feeling tells me
that conflating "existing struct page" test and "fully online and
initialized" one is a wrong thing to do.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2016-11-15 20:29 Christoph Lameter
2016-11-16 10:40 ` your mail Peter Zijlstra
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Lameter @ 2016-11-15 20:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Daniel Vacek, Daniel Bristot de Oliveira, Tommaso Cucinotta,
LKML, linux-rt-users, Steven Rostedt, Ingo Molnar
> > There is a deadlock, Peter!!!
>
> Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
>
The description was given earlier in the the thread and the drawbacks of
using RT_RUNTIME_SHARE as well.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2016-11-15 20:29 Christoph Lameter
@ 2016-11-16 10:40 ` Peter Zijlstra
2016-11-16 14:25 ` Steven Rostedt
0 siblings, 1 reply; 669+ messages in thread
From: Peter Zijlstra @ 2016-11-16 10:40 UTC (permalink / raw)
To: Christoph Lameter
Cc: Daniel Vacek, Daniel Bristot de Oliveira, Tommaso Cucinotta,
LKML, linux-rt-users, Steven Rostedt, Ingo Molnar
On Tue, Nov 15, 2016 at 02:29:16PM -0600, Christoph Lameter wrote:
>
> > > There is a deadlock, Peter!!!
> >
> > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
> >
>
>
> The description was given earlier in the the thread and the drawbacks of
> using RT_RUNTIME_SHARE as well.
I've not seen a deadlock described. It either was an unbounded priority
inversion or a starvation issue, both of which are 'design' features of
the !rt kernel.
Neither things are new, so its not a regression either.
And, as stated, I'm not really happy to muck with this known troublesome
code and add features for which we must then maintain feature parity
when replacing it either.
On top of which, the implementation had issues; now I know you're the
blinder kind of person that disregards everything not in his immediate
interest, but if you'd looked at the patch you'd have seen he'd added
code the idle entry path, which will slow down every single to-idle
transition.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2016-11-16 10:40 ` your mail Peter Zijlstra
@ 2016-11-16 14:25 ` Steven Rostedt
2016-11-16 14:28 ` Peter Zijlstra
0 siblings, 1 reply; 669+ messages in thread
From: Steven Rostedt @ 2016-11-16 14:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Christoph Lameter, Daniel Vacek, Daniel Bristot de Oliveira,
Tommaso Cucinotta, LKML, linux-rt-users, Ingo Molnar
On Wed, 16 Nov 2016 11:40:14 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On top of which, the implementation had issues; now I know you're the
> blinder kind of person that disregards everything not in his immediate
> interest, but if you'd looked at the patch you'd have seen he'd added
> code the idle entry path, which will slow down every single to-idle
> transition.
Isn't to-idle a bit bloated anyway? Or has that been fixed. I know
there was some issues with idle_balance() which can add latency to
wakeups. idle_balance() is also in the to-idle path.
Note, that this is a sched feature which would be a nop (jump_label)
when disabled. And I'm sure it could also be optimized to be a static
inline as well when it is enabled.
I'm not saying we need to go this approach, but I'm just saying that
the to-idle issue is a bit of a red herring.
-- Steve
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2016-11-16 14:25 ` Steven Rostedt
@ 2016-11-16 14:28 ` Peter Zijlstra
0 siblings, 0 replies; 669+ messages in thread
From: Peter Zijlstra @ 2016-11-16 14:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christoph Lameter, Daniel Vacek, Daniel Bristot de Oliveira,
Tommaso Cucinotta, LKML, linux-rt-users, Ingo Molnar
On Wed, Nov 16, 2016 at 09:25:43AM -0500, Steven Rostedt wrote:
> On Wed, 16 Nov 2016 11:40:14 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> > On top of which, the implementation had issues; now I know you're the
> > blinder kind of person that disregards everything not in his immediate
> > interest, but if you'd looked at the patch you'd have seen he'd added
> > code the idle entry path, which will slow down every single to-idle
> > transition.
>
> Isn't to-idle a bit bloated anyway? Or has that been fixed. I know
> there was some issues with idle_balance() which can add latency to
> wakeups. idle_balance() is also in the to-idle path.
>
Yes it is too heavy as is, but just stacking more crap in just because
its already expensive seems to wrong way around.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2016-09-20 22:21 Andrew Banman
2016-09-20 22:23 ` your mail andrew banman
0 siblings, 1 reply; 669+ messages in thread
From: Andrew Banman @ 2016-09-20 22:21 UTC (permalink / raw)
To: mingo, akpm; +Cc: tglx, hpa, travis, rja, sivanich, x86, linux-kernel, abanman
>From Andrew Banman <abanman@sgi.com> # This line is ignored.
From: Andrew Banman <abanman@sgi.com>
Subject: [PATCH 0/9] arch/x86/platform/uv: add UV4 support to BAU
In-Reply-To:
The following patch set adds support for UV4 architecture to the Broadcast
Assist Unit (BAU). Major hardware changes to the BAU require these fixes to
ensure correct operation and to avoid illegal MMR writes.
arch/x86/include/asm/uv/uv_bau.h | 45 ++----------------------------
arch/x86/platform/uv/tlb_uv.c | 114 ++++++++++++++++++++++++---------------------------------------
-------------
The patch set can be thought of in three logical groups:
1) General cleanup.
[PATCH 1/9] arch/x86/platform/uv: BAU cleanup: update printks
[PATCH 2/9] arch/x86/platform/uv: BAU cleanup: pq_init
[PATCH 3/9] arch/x86/platform/uv: BAU replace uv_physnodeaddr
These housekeeping patches make the subsequent UV4 patches clearer,
and they should be done in any case.
2) Implement a new scheme to abstract UV version-specific functions.
[PATCH 4/9] arch/x86/platform/uv: BAU add generic function pointers
[PATCH 5/9] arch/x86/platform/uv: BAU use generic function pointers
We add a struct of function pointers to define version-specific BAU
operations. The philosophy is to abstract functions that perform the same
operation on all UV versions but have different implementations. This will
simplify their use in the body of the driver code and greatly simplify the
UV4 patches to follow.
3) Add UV4 functionality.
[PATCH 6/9] arch/x86/platform/uv: BAU UV4 populate uvhub_version
[PATCH 7/9] arch/x86/platform/uv: BAU UV4 disable software timeout
[PATCH 8/9] arch/x86/platform/uv: BAU UV4 fix payload queue setup
[PATCH 9/9] arch/x86/platform/uv: BAU UV4 add version-specific
These patches feature a minimal set of changes to make the BAU on UV4
operational.
This patch set has been tested for regressions on pre-UV4 architectures and
for correct functionality on UV4. The patches apply cleanly to 4.8-rc7.
Fine-tuned performance tweaking for UV4 will come in a future patch set.
Thank you,
Andrew Banman
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2016-09-20 22:21 Andrew Banman
@ 2016-09-20 22:23 ` andrew banman
0 siblings, 0 replies; 669+ messages in thread
From: andrew banman @ 2016-09-20 22:23 UTC (permalink / raw)
To: Andrew Banman
Cc: mingo, akpm, tglx, hpa, travis, rja, sivanich, x86, linux-kernel
Subject line got dropped the first time around. Will send again.
Apologies for the chatter,
Andrew
On Tue, Sep 20, 2016 at 05:21:06PM -0500, Andrew Banman wrote:
> From Andrew Banman <abanman@sgi.com> # This line is ignored.
> From: Andrew Banman <abanman@sgi.com>
> Subject: [PATCH 0/9] arch/x86/platform/uv: add UV4 support to BAU
> In-Reply-To:
>
> The following patch set adds support for UV4 architecture to the Broadcast
> Assist Unit (BAU). Major hardware changes to the BAU require these fixes to
> ensure correct operation and to avoid illegal MMR writes.
>
> arch/x86/include/asm/uv/uv_bau.h | 45 ++----------------------------
> arch/x86/platform/uv/tlb_uv.c | 114 ++++++++++++++++++++++++---------------------------------------
> -------------
>
> The patch set can be thought of in three logical groups:
>
> 1) General cleanup.
>
> [PATCH 1/9] arch/x86/platform/uv: BAU cleanup: update printks
> [PATCH 2/9] arch/x86/platform/uv: BAU cleanup: pq_init
> [PATCH 3/9] arch/x86/platform/uv: BAU replace uv_physnodeaddr
>
> These housekeeping patches make the subsequent UV4 patches clearer,
> and they should be done in any case.
>
>
> 2) Implement a new scheme to abstract UV version-specific functions.
>
> [PATCH 4/9] arch/x86/platform/uv: BAU add generic function pointers
> [PATCH 5/9] arch/x86/platform/uv: BAU use generic function pointers
>
> We add a struct of function pointers to define version-specific BAU
> operations. The philosophy is to abstract functions that perform the same
> operation on all UV versions but have different implementations. This will
> simplify their use in the body of the driver code and greatly simplify the
> UV4 patches to follow.
>
>
> 3) Add UV4 functionality.
>
> [PATCH 6/9] arch/x86/platform/uv: BAU UV4 populate uvhub_version
> [PATCH 7/9] arch/x86/platform/uv: BAU UV4 disable software timeout
> [PATCH 8/9] arch/x86/platform/uv: BAU UV4 fix payload queue setup
> [PATCH 9/9] arch/x86/platform/uv: BAU UV4 add version-specific
>
> These patches feature a minimal set of changes to make the BAU on UV4
> operational.
>
>
> This patch set has been tested for regressions on pre-UV4 architectures and
> for correct functionality on UV4. The patches apply cleanly to 4.8-rc7.
> Fine-tuned performance tweaking for UV4 will come in a future patch set.
>
>
> Thank you,
>
> Andrew Banman
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2016-09-01 2:02 Fennec Fox
2016-09-01 7:44 ` your mail M G Berberich
0 siblings, 1 reply; 669+ messages in thread
From: Fennec Fox @ 2016-09-01 2:02 UTC (permalink / raw)
To: linux-btrfs
Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
2016 x86_64 GNU/Linux
btrfs-progs v4.7
Data, single: total=30.01GiB, used=18.95GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=422.17MiB
GlobalReserve, single: total=144.00MiB, used=0.00B
{02:50} Wed Aug 31
[fennectech@Titanium ~]$ sudo fstrim -v /
[sudo] password for fennectech:
Sorry, try again.
[sudo] password for fennectech:
/: 99.8 GiB (107167244288 bytes) trimmed
{03:08} Wed Aug 31
[fennectech@Titanium ~]$ sudo fstrim -v /
[sudo] password for fennectech:
/: 99.9 GiB (107262181376 bytes) trimmed
I ran these commands minutes after echother ane each time it is
trimming the entire free space
Anyone else seen this? the filesystem is the root FS and is compressed
--
Fennec
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2016-09-01 2:02 Fennec Fox
@ 2016-09-01 7:44 ` M G Berberich
2016-09-01 11:17 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 669+ messages in thread
From: M G Berberich @ 2016-09-01 7:44 UTC (permalink / raw)
To: linux-btrfs
Am Mittwoch, den 31. August schrieb Fennec Fox:
> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> 2016 x86_64 GNU/Linux
> btrfs-progs v4.7
>
> Data, single: total=30.01GiB, used=18.95GiB
> System, single: total=4.00MiB, used=16.00KiB
> Metadata, single: total=1.01GiB, used=422.17MiB
> GlobalReserve, single: total=144.00MiB, used=0.00B
>
> {02:50} Wed Aug 31
> [fennectech@Titanium ~]$ sudo fstrim -v /
> [sudo] password for fennectech:
> Sorry, try again.
> [sudo] password for fennectech:
> /: 99.8 GiB (107167244288 bytes) trimmed
>
> {03:08} Wed Aug 31
> [fennectech@Titanium ~]$ sudo fstrim -v /
> [sudo] password for fennectech:
> /: 99.9 GiB (107262181376 bytes) trimmed
>
> I ran these commands minutes after echother ane each time it is
> trimming the entire free space
>
> Anyone else seen this? the filesystem is the root FS and is compressed
You should be very happy that it is trimming at all. Typical situation
on a used btrfs is
# fstrim -v /
/: 0 B (0 bytes) trimmed
even if there is 33G unused space ob the fs:
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 96G 61G 33G 66% /
MfG
bmg
--
„Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!“ | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg) |
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2016-09-01 7:44 ` your mail M G Berberich
@ 2016-09-01 11:17 ` Austin S. Hemmelgarn
2016-09-01 16:44 ` Kyle Gates
2016-09-01 21:15 ` M G Berberich
0 siblings, 2 replies; 669+ messages in thread
From: Austin S. Hemmelgarn @ 2016-09-01 11:17 UTC (permalink / raw)
To: linux-btrfs
On 2016-09-01 03:44, M G Berberich wrote:
> Am Mittwoch, den 31. August schrieb Fennec Fox:
>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
>> 2016 x86_64 GNU/Linux
>> btrfs-progs v4.7
>>
>> Data, single: total=30.01GiB, used=18.95GiB
>> System, single: total=4.00MiB, used=16.00KiB
>> Metadata, single: total=1.01GiB, used=422.17MiB
>> GlobalReserve, single: total=144.00MiB, used=0.00B
>>
>> {02:50} Wed Aug 31
>> [fennectech@Titanium ~]$ sudo fstrim -v /
>> [sudo] password for fennectech:
>> Sorry, try again.
>> [sudo] password for fennectech:
>> /: 99.8 GiB (107167244288 bytes) trimmed
>>
>> {03:08} Wed Aug 31
>> [fennectech@Titanium ~]$ sudo fstrim -v /
>> [sudo] password for fennectech:
>> /: 99.9 GiB (107262181376 bytes) trimmed
>>
>> I ran these commands minutes after echother ane each time it is
>> trimming the entire free space
>>
>> Anyone else seen this? the filesystem is the root FS and is compressed
>
> You should be very happy that it is trimming at all. Typical situation
> on a used btrfs is
>
> # fstrim -v /
> /: 0 B (0 bytes) trimmed
>
> even if there is 33G unused space ob the fs:
>
> # df -h /
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda2 96G 61G 33G 66% /
>
I think you're using an old kernel, this has been working since at least
4.5, but was broken in some older releases.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2016-09-01 11:17 ` Austin S. Hemmelgarn
@ 2016-09-01 16:44 ` Kyle Gates
2016-09-01 17:06 ` Austin S. Hemmelgarn
2016-09-02 1:51 ` Jeff Mahoney
2016-09-01 21:15 ` M G Berberich
1 sibling, 2 replies; 669+ messages in thread
From: Kyle Gates @ 2016-09-01 16:44 UTC (permalink / raw)
To: Austin S. Hemmelgarn, linux-btrfs
> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
> Sent: Thursday, September 01, 2016 6:18 AM
> To: linux-btrfs@vger.kernel.org
> Subject: Re: your mail
>
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> >> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
> UTC
> >> 2016 x86_64 GNU/Linux
> >> btrfs-progs v4.7
> >>
> >> Data, single: total=30.01GiB, used=18.95GiB System, single:
> >> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
> >> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
> >>
> >> {02:50} Wed Aug 31
> >> [fennectech@Titanium ~]$ sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> Sorry, try again.
> >> [sudo] password for fennectech:
> >> /: 99.8 GiB (107167244288 bytes) trimmed
> >>
> >> {03:08} Wed Aug 31
> >> [fennectech@Titanium ~]$ sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> /: 99.9 GiB (107262181376 bytes) trimmed
> >>
> >> I ran these commands minutes after echother ane each time it is
> >> trimming the entire free space
> >>
> >> Anyone else seen this? the filesystem is the root FS and is compressed
> >
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> >
> > # fstrim -v /
> > /: 0 B (0 bytes) trimmed
> >
> > even if there is 33G unused space ob the fs:
> >
> > # df -h /
> > Filesystem Size Used Avail Use% Mounted on
> > /dev/sda2 96G 61G 33G 66% /
> >
> I think you're using an old kernel, this has been working since at least 4.5, but
> was broken in some older releases.
M G is running 4.7.2
The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.
On my system all space has been allocated on my root filesystem so 0 B are trimmed:
kyle@home:~$ uname -a
Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
kyle@home:~$ sudo btrfs fi show /
Label: 'root' uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
Total devices 2 FS bytes used 13.44GiB
devid 14 size 20.00GiB used 20.00GiB path /dev/sde2
devid 15 size 20.00GiB used 20.00GiB path /dev/sdb2
kyle@home:~$ btrfs fi df /
Data, RAID1: total=18.97GiB, used=12.98GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=473.83MiB
GlobalReserve, single: total=160.00MiB, used=0.00B
kyle@home:~$ sudo fstrim -v /
[sudo] password for kyle:
/: 0 B (0 bytes) trimmed
But I do have space trimmed on my home filesystem:
kyle@home:~$ sudo btrfs fi show /home/
Label: 'home' uuid: b75fb450-4a28-434a-a483-e784940d463a
Total devices 2 FS bytes used 18.63GiB
devid 11 size 64.00GiB used 29.03GiB path /dev/sde3
devid 12 size 64.00GiB used 29.03GiB path /dev/sdb3
kyle@home:~$ btrfs fi df /home/
Data, RAID1: total=27.00GiB, used=18.46GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=2.00GiB, used=168.62MiB
GlobalReserve, single: total=64.00MiB, used=0.00B
kyle@home:~$ sudo fstrim -v /home
/home: 70 GiB (75092721664 bytes) trimmed
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2016-09-01 16:44 ` Kyle Gates
@ 2016-09-01 17:06 ` Austin S. Hemmelgarn
2016-09-02 1:51 ` Jeff Mahoney
1 sibling, 0 replies; 669+ messages in thread
From: Austin S. Hemmelgarn @ 2016-09-01 17:06 UTC (permalink / raw)
To: Kyle Gates, linux-btrfs
On 2016-09-01 12:44, Kyle Gates wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=30.01GiB, used=18.95GiB System, single:
>>>> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
>>>> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$ sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$ sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>> I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this? the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>> # fstrim -v /
>>> /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>> # df -h /
>>> Filesystem Size Used Avail Use% Mounted on
>>> /dev/sda2 96G 61G 33G 66% /
>>>
>> I think you're using an old kernel, this has been working since at least 4.5, but
>> was broken in some older releases.
>
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.
Yep, that would do so also, and this behavior really could be much
better documented.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2016-09-01 16:44 ` Kyle Gates
2016-09-01 17:06 ` Austin S. Hemmelgarn
@ 2016-09-02 1:51 ` Jeff Mahoney
1 sibling, 0 replies; 669+ messages in thread
From: Jeff Mahoney @ 2016-09-02 1:51 UTC (permalink / raw)
To: Kyle Gates, Austin S. Hemmelgarn, linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 3943 bytes --]
On 9/1/16 12:44 PM, Kyle Gates wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=30.01GiB, used=18.95GiB System, single:
>>>> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
>>>> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$ sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$ sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>> I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this? the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>> # fstrim -v /
>>> /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>> # df -h /
>>> Filesystem Size Used Avail Use% Mounted on
>>> /dev/sda2 96G 61G 33G 66% /
>>>
>> I think you're using an old kernel, this has been working since at least 4.5, but
>> was broken in some older releases.
>
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.
Historically it was the opposite problem. My fixes made it so it would
work on unallocated space. We probably need some debugging to see why
it's not discarding extents that are allocated as block groups but
unallocated within them.
-Jeff
> On my system all space has been allocated on my root filesystem so 0 B are trimmed:
> kyle@home:~$ uname -a
> Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> kyle@home:~$ sudo btrfs fi show /
> Label: 'root' uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
> Total devices 2 FS bytes used 13.44GiB
> devid 14 size 20.00GiB used 20.00GiB path /dev/sde2
> devid 15 size 20.00GiB used 20.00GiB path /dev/sdb2
> kyle@home:~$ btrfs fi df /
> Data, RAID1: total=18.97GiB, used=12.98GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=1.00GiB, used=473.83MiB
> GlobalReserve, single: total=160.00MiB, used=0.00B
> kyle@home:~$ sudo fstrim -v /
> [sudo] password for kyle:
> /: 0 B (0 bytes) trimmed
>
> But I do have space trimmed on my home filesystem:
> kyle@home:~$ sudo btrfs fi show /home/
> Label: 'home' uuid: b75fb450-4a28-434a-a483-e784940d463a
> Total devices 2 FS bytes used 18.63GiB
> devid 11 size 64.00GiB used 29.03GiB path /dev/sde3
> devid 12 size 64.00GiB used 29.03GiB path /dev/sdb3
> kyle@home:~$ btrfs fi df /home/
> Data, RAID1: total=27.00GiB, used=18.46GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=2.00GiB, used=168.62MiB
> GlobalReserve, single: total=64.00MiB, used=0.00B
> kyle@home:~$ sudo fstrim -v /home
> /home: 70 GiB (75092721664 bytes) trimmed
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2016-09-01 11:17 ` Austin S. Hemmelgarn
2016-09-01 16:44 ` Kyle Gates
@ 2016-09-01 21:15 ` M G Berberich
1 sibling, 0 replies; 669+ messages in thread
From: M G Berberich @ 2016-09-01 21:15 UTC (permalink / raw)
To: linux-btrfs
Am Donnerstag, den 01. September schrieb Austin S. Hemmelgarn:
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> > > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> > > 2016 x86_64 GNU/Linux
> > > btrfs-progs v4.7
> > >
> > > Data, single: total=30.01GiB, used=18.95GiB
> > > System, single: total=4.00MiB, used=16.00KiB
> > > Metadata, single: total=1.01GiB, used=422.17MiB
> > > GlobalReserve, single: total=144.00MiB, used=0.00B
> > >
> > > {02:50} Wed Aug 31
> > > [fennectech@Titanium ~]$ sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > Sorry, try again.
> > > [sudo] password for fennectech:
> > > /: 99.8 GiB (107167244288 bytes) trimmed
> > >
> > > {03:08} Wed Aug 31
> > > [fennectech@Titanium ~]$ sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > /: 99.9 GiB (107262181376 bytes) trimmed
> > >
> > > I ran these commands minutes after echother ane each time it is
> > > trimming the entire free space
> > >
> > > Anyone else seen this? the filesystem is the root FS and is compressed
> >
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> >
> > # fstrim -v /
> > /: 0 B (0 bytes) trimmed
> >
> > even if there is 33G unused space ob the fs:
> >
> > # df -h /
> > Filesystem Size Used Avail Use% Mounted on
> > /dev/sda2 96G 61G 33G 66% /
> >
> I think you're using an old kernel, this has been working since at least
> 4.5, but was broken in some older releases.
No, I’m always running a fairly up-to-date vanilla kernel on this
system. At the moment it’s:
Linux hermione 4.7.2 #4 SMP PREEMPT Wed Aug 24 17:12:03 CEST 2016 x86_64 GNU/Linux
I’m running kernels ≥ 4.5.0 since about April and I first reported this
problem at 7 Jul 2016 (Subject: fstrim problem/bug) probably with a
4.6.3 kernel.
MfG
bmg
--
„Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!“ | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg) |
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2016-04-11 19:04 miwilliams
2016-04-11 19:13 ` your mail Jeff King
0 siblings, 1 reply; 669+ messages in thread
From: miwilliams @ 2016-04-11 19:04 UTC (permalink / raw)
To: git
From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
From: Mike Williams <miwilliams@google.com>
Date: Mon, 11 Apr 2016 14:18:39 -0400
Subject: [PATCH 1/1] wt-status: Remove '!!' from
wt_status_collect_changed_cb
The wt_status_collect_changed_cb function uses an extraneous double
negation (!!)
when determining whether or not a submodule has new commits.
Signed-off-by: Mike Williams <miwilliams@google.com>
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index ef74864..b955179 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -431,7 +431,7 @@ static void wt_status_collect_changed_cb(struct
diff_queue_struct *q,
d->worktree_status = p->status;
d->dirty_submodule = p->two->dirty_submodule;
if (S_ISGITLINK(p->two->mode))
- d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
+ d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);
}
}
--
2.8.0
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2016-04-11 19:04 (unknown), miwilliams
@ 2016-04-11 19:13 ` Jeff King
0 siblings, 0 replies; 669+ messages in thread
From: Jeff King @ 2016-04-11 19:13 UTC (permalink / raw)
To: miwilliams; +Cc: git
On Mon, Apr 11, 2016 at 07:04:23PM +0000, miwilliams@google.com wrote:
> From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
> From: Mike Williams <miwilliams@google.com>
> Date: Mon, 11 Apr 2016 14:18:39 -0400
> Subject: [PATCH 1/1] wt-status: Remove '!!' from
> wt_status_collect_changed_cb
These bits (minus the initial "From ..." line) should go into your
actual email headers. As it is, your email has no subject line.
> The wt_status_collect_changed_cb function uses an extraneous double
> negation (!!) when determining whether or not a submodule has new
> commits.
> [...]
> - d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
> + d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);
It's not extraneous. hashcmp() returns 0 for equality, but an arbitrary
positive or negative value depending on how the two arguments differ.
The assigned "new_submodule_commits" is a bitfield of size 1. So the
"!!" is normalizing the value into "0" or "1".
-Peff
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2015-08-03 6:18 Shraddha Barke
2015-08-03 7:12 ` your mail Sudip Mukherjee
2015-08-03 7:24 ` Dan Carpenter
0 siblings, 2 replies; 669+ messages in thread
From: Shraddha Barke @ 2015-08-03 6:18 UTC (permalink / raw)
To: Oleg Drokin, Al Viro, Julia Lawall, aybuke ozdemir,
Andreas Dilger, John L. Hammond, Frank Zago, Greg Kroah-Hartman,
HPDD-discuss, devel, linux-kernel
Cc: Shraddha Barke
>From b67c6c20455b04b77447ab4561e44f1a75dd978d Mon Sep 17 00:00:00 2001
From: Shraddha Barke <shraddha.6596@gmail.com>
Date: Mon, 3 Aug 2015 11:34:19 +0530
Subject: [PATCH] Staging : lustre : Use -EINVAL instead of -ENOSYS
ENOSYS means that a nonexistent system call was called. This should
not be used for invalid operations on otherwise valid syscalls.
Use -EINVAL instead of -ENOSYS. This fixes checkpatch warning message:
WARNING: ENOSYS means 'invalid syscall nr' and nothing else
Signed-off-by: Shraddha Barke <shraddha.6596@gmail.com>
---
drivers/staging/lustre/lustre/llite/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c
index 2c467bf..93619a8 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -2786,7 +2786,7 @@ ll_file_flock(struct file *file, int cmd, struct file_lock *file_lock)
static int
ll_file_noflock(struct file *file, int cmd, struct file_lock *file_lock)
{
- return -ENOSYS;
+ return -EINVAL;
}
/**
--
2.1.0
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2015-08-03 6:18 Shraddha Barke
@ 2015-08-03 7:12 ` Sudip Mukherjee
2015-08-03 7:24 ` Dan Carpenter
1 sibling, 0 replies; 669+ messages in thread
From: Sudip Mukherjee @ 2015-08-03 7:12 UTC (permalink / raw)
To: Shraddha Barke
Cc: Oleg Drokin, Al Viro, Julia Lawall, aybuke ozdemir,
Andreas Dilger, John L. Hammond, Frank Zago, Greg Kroah-Hartman,
HPDD-discuss, devel, linux-kernel
On Mon, Aug 03, 2015 at 11:48:59AM +0530, Shraddha Barke wrote:
> From b67c6c20455b04b77447ab4561e44f1a75dd978d Mon Sep 17 00:00:00 2001
> From: Shraddha Barke <shraddha.6596@gmail.com>
> Date: Mon, 3 Aug 2015 11:34:19 +0530
> Subject: [PATCH] Staging : lustre : Use -EINVAL instead of -ENOSYS
You do not need these in the commit message.
regards
sudip
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2015-08-03 6:18 Shraddha Barke
2015-08-03 7:12 ` your mail Sudip Mukherjee
@ 2015-08-03 7:24 ` Dan Carpenter
1 sibling, 0 replies; 669+ messages in thread
From: Dan Carpenter @ 2015-08-03 7:24 UTC (permalink / raw)
To: Shraddha Barke
Cc: Oleg Drokin, Al Viro, Julia Lawall, aybuke ozdemir,
Andreas Dilger, John L. Hammond, Frank Zago, Greg Kroah-Hartman,
HPDD-discuss, devel, linux-kernel
Returning EINVAL here is the wrong thing. Just leave the code as is.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2015-06-13 1:02 Tom Christensen
2015-06-13 22:39 ` your mail Dave Chinner
0 siblings, 1 reply; 669+ messages in thread
From: Tom Christensen @ 2015-06-13 1:02 UTC (permalink / raw)
To: xfs; +Cc: swakefie
[-- Attachment #1.1: Type: text/plain, Size: 16098 bytes --]
We've run into a bit of an issue with xfs running Ceph. The following bug details what we are seeing:
https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
Here is additional info gathered:
xfs bmap output for a random directory
https://gist.github.com/dmmatson/e864252c7ff346df954a
attr -l of the file dchinner indicated from the xfs bmap output
(attr -l)
(6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
(6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
(6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
(6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
(6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
(6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
xfs_bmap -vp of same file
rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
(6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
(6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000
uname -a
Linux str-slc-02-01 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64
x86_64 GNU/Linux
xfsprogs version
xfs_repair version 3.1.9
number of cpus
2x6 core
/proc/meminfo
MemTotal: 264123244 kB
MemFree: 115763776 kB
MemAvailable: 118825516 kB
Buffers: 8624 kB
Cached: 5331460 kB
SwapCached: 0 kB
Active: 137378292 kB
Inactive: 4797536 kB
Active(anon): 136839564 kB
Inactive(anon): 5160 kB
Active(file): 538728 kB
Inactive(file): 4792376 kB
Unevictable: 8576 kB
Mlocked: 8896 kB
SwapTotal: 34058232 kB
SwapFree: 34058232 kB
Dirty: 116400 kB
Writeback: 3360 kB
AnonPages: 136847296 kB
Mapped: 3003196 kB
Shmem: 2776 kB
Slab: 1348116 kB
SReclaimable: 581188 kB
SUnreclaim: 766928 kB
KernelStack: 1788400 kB
PageTables: 505196 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 166119852 kB
Committed_AS: 259735308 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 908732 kB
VmallocChunk: 34221991936 kB
HardwareCorrupted: 0 kB
AnonHugePages: 34844672 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 137500 kB
DirectMap2M: 5070848 kB
DirectMap1G: 265289728 kB
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=132050356k,nr_inodes=33012589,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=26412328k,mode=755 0 0
/dev/mapper/system-root / ext4 rw,relatime,discard,errors=remount-ro,data=ordered 0 0
none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0
none /sys/fs/pstore pstore rw,relatime 0 0
/dev/sda1 /boot ext3 rw,relatime,data=ordered 0 0
systemd /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,name=systemd 0 0
/dev/mapper/e0364357-e2e0-4b5e-92c3-abbea655ca77 /var/lib/ceph/osd/ceph-293 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/a7745ae8-1b83-4cb5-892b-4cc8d27ed5b2 /var/lib/ceph/osd/ceph-302 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/60cecd8c-42fd-4cbf-9264-ead7319846d3 /var/lib/ceph/osd/ceph-295 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/c3ab6273-a646-40fe-bbf3-c4559bf4202a /var/lib/ceph/osd/ceph-298 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/3dfceed9-6563-46c9-b174-7173f73874ae /var/lib/ceph/osd/ceph-301 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/5765a366-3908-41ef-b2ab-dd10db6e8c29 /var/lib/ceph/osd/ceph-299 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/bb5b11a9-cc4d-49b8-a909-c8e84a88f0ee /var/lib/ceph/osd/ceph-316 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/4d3165f9-d879-426f-b7ef-6a959a09a1bf /var/lib/ceph/osd/ceph-313 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/2559e439-9540-40eb-99a6-cebbe2663cd9 /var/lib/ceph/tmp/mnt.BeT4xM xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/mapper/b492dfe2-103c-44b6-83ad-8dc35a9818c0 /var/lib/ceph/osd/ceph-303 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/e5b359e2-bb98-40a5-a285-612b8fb2b2a6 /var/lib/ceph/osd/ceph-314 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/6b45df8f-b6c0-4ed7-b791-a2694b3212ec /var/lib/ceph/osd/ceph-312 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/abcd86ff-57d0-4ef0-8ee7-1a13408b3b2c /var/lib/ceph/osd/ceph-322 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/a75ed2c0-cc39-4063-bb1e-202d47798499 /var/lib/ceph/osd/ceph-317 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/4d788f02-2720-4a50-8bac-e5a4cdf99441 /var/lib/ceph/osd/ceph-321 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/8d179b94-a071-4dab-927b-b9d2ed98451d /var/lib/ceph/osd/ceph-308 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/b781ebc5-7259-4cf2-8fd5-c608c61fe0e2 /var/lib/ceph/osd/ceph-318 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/deaa099e-9791-4c03-826e-6386eb2c4fff /var/lib/ceph/osd/ceph-323 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/bcbf31e3-7f17-49aa-9259-6dfe8e0f04bc /var/lib/ceph/osd/ceph-320 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/d2b9331f-bcfa-4c98-a0b7-5ab1ec93ee02 /var/lib/ceph/osd/ceph-311 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/0c4172f9-9acb-4c88-bc4e-1b6eb898ea28 /var/lib/ceph/osd/ceph-325 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/252ee856-0376-44ae-b6d7-03f930f8d082 /var/lib/ceph/osd/ceph-328 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/d4bcc76c-20c3-4253-bd05-472f3eb7df96 /var/lib/ceph/osd/ceph-319 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/2ca3f1d3-cf59-49df-a008-0bb6c549587b /var/lib/ceph/osd/ceph-315 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/16df1fdc-819b-4593-ac4f-80f3fcac6054 /var/lib/ceph/osd/ceph-306 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/ce83d72e-029b-40b6-9d59-3b0ebadea2c6 /var/lib/ceph/osd/ceph-324 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/86e078fe-6fa7-466c-83eb-14c53b531320 /var/lib/ceph/osd/ceph-307 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/368ef2f0-da43-48ee-bd91-2bfba95aea5a /var/lib/ceph/osd/ceph-310 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/ac67fd93-8145-40ce-96bb-812cec326306 /var/lib/ceph/osd/ceph-327 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/098e2832-e9d4-4b84-9fa9-acfa407a3afc /var/lib/ceph/osd/ceph-309 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/f1588472-430d-4db4-83dc-31e1ec1d2ba5 /var/lib/ceph/osd/ceph-326 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/fb64b259-7d70-4859-824e-b6ee7683495d /var/lib/ceph/osd/ceph-305 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/2559e439-9540-40eb-99a6-cebbe2663cd9 /var/lib/ceph/osd/ceph-300 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/mapper/ae8b44b1-25ac-4aa9-b987-9c57c3410ec6 /var/lib/ceph/osd/ceph-304 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/c198f472-4806-4c9c-aa79-b8e1b5554cdf /var/lib/ceph/osd/ceph-296 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/65d17dba-4c30-4e95-a0b5-577002712b6a /var/lib/ceph/osd/ceph-297 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
/dev/mapper/1f3dc9e8-0d84-4951-8c9b-48b6a6be83b8 /var/lib/ceph/osd/ceph-294 xfs rw,noatime,attr2,inode64,allocsize=4096k,noquota 0 0
major minor #blocks name
8 0 125034840 sda
8 1 291840 sda1
8 2 1 sda2
8 5 124740608 sda5
252 0 124235776 dm-0
252 1 503808 dm-1
8 32 2930266584 sdc
8 33 2920025543 sdc1
8 34 10238976 sdc2
8 128 2930266584 sdi
8 129 2920025543 sdi1
8 130 10238976 sdi2
8 96 2930266584 sdg
8 97 2920025543 sdg1
8 98 10238976 sdg2
8 112 2930266584 sdh
8 113 2920025543 sdh1
8 114 10238976 sdh2
8 176 2930266584 sdl
8 177 2920025543 sdl1
8 178 10238976 sdl2
8 144 2930266584 sdj
8 145 2920025543 sdj1
8 146 10238976 sdj2
8 240 2930266584 sdp
8 241 2920025543 sdp1
8 242 10238976 sdp2
8 224 2930266584 sdo
8 225 2920025543 sdo1
8 226 10238976 sdo2
8 80 2930266584 sdf
8 81 2920025543 sdf1
8 82 10238976 sdf2
8 48 2930266584 sdd
8 49 2920025543 sdd1
8 50 10238976 sdd2
65 48 2930266584 sdt
65 49 2920025543 sdt1
65 50 10238976 sdt2
8 64 2930266584 sde
8 65 2920025543 sde1
8 66 10238976 sde2
65 0 2930266584 sdq
65 1 2920025543 sdq1
65 2 10238976 sdq2
8 192 2930266584 sdm
8 193 2920025543 sdm1
8 194 10238976 sdm2
65 32 2930266584 sds
65 33 2920025543 sds1
65 34 10238976 sds2
65 64 2930266584 sdu
65 65 2920025543 sdu1
65 66 10238976 sdu2
65 16 2930266584 sdr
65 17 2920025543 sdr1
65 18 10238976 sdr2
65 160 2930266584 sdaa
65 161 2920025543 sdaa1
65 162 10238976 sdaa2
8 160 2930266584 sdk
8 161 2920025543 sdk1
8 162 10238976 sdk2
65 240 2930266584 sdaf
65 241 2920025543 sdaf1
65 242 10238976 sdaf2
8 16 2930266584 sdb
8 17 2920025543 sdb1
8 18 10238976 sdb2
65 176 2930266584 sdab
65 177 2920025543 sdab1
65 178 10238976 sdab2
65 96 2930266584 sdw
65 97 2920025543 sdw1
65 98 10238976 sdw2
65 128 2930266584 sdy
65 129 2920025543 sdy1
65 130 10238976 sdy2
66 16 2930266584 sdah
66 17 2920025543 sdah1
66 18 10238976 sdah2
8 208 2930266584 sdn
8 209 2920025543 sdn1
8 210 10238976 sdn2
65 144 2930266584 sdz
65 145 2920025543 sdz1
65 146 10238976 sdz2
65 80 2930266584 sdv
65 81 2920025543 sdv1
65 82 10238976 sdv2
65 192 2930266584 sdac
65 193 2920025543 sdac1
65 194 10238976 sdac2
65 224 2930266584 sdae
65 225 2920025543 sdae1
65 226 10238976 sdae2
65 112 2930266584 sdx
65 113 2920025543 sdx1
65 114 10238976 sdx2
66 0 2930266584 sdag
66 1 2920025543 sdag1
66 2 10238976 sdag2
65 208 2930266584 sdad
65 209 2920025543 sdad1
65 210 10238976 sdad2
66 64 2930266584 sdak
66 65 2920025543 sdak1
66 66 10238976 sdak2
66 48 2930266584 sdaj
66 49 2920025543 sdaj1
66 50 10238976 sdaj2
66 32 2930266584 sdai
66 33 2920025543 sdai1
66 34 10238976 sdai2
252 2 10238976 dm-2
252 3 2920025543 dm-3
252 4 10238976 dm-4
252 5 2920025543 dm-5
252 6 2920025543 dm-6
252 7 10238976 dm-7
252 8 2920025543 dm-8
252 9 10238976 dm-9
252 10 2920025543 dm-10
252 11 10238976 dm-11
252 12 10238976 dm-12
252 13 2920025543 dm-13
252 14 10238976 dm-14
252 15 2920025543 dm-15
252 16 10238976 dm-16
252 17 2920025543 dm-17
252 18 2920025543 dm-18
252 19 10238976 dm-19
252 20 2920025543 dm-20
252 21 10238976 dm-21
252 22 10238976 dm-22
252 23 2920025543 dm-23
252 24 10238976 dm-24
252 25 2920025543 dm-25
252 26 2920025543 dm-26
252 27 10238976 dm-27
252 28 10238976 dm-28
252 29 2920025543 dm-29
252 31 2920025543 dm-31
252 30 10238976 dm-30
252 32 10238976 dm-32
252 33 2920025543 dm-33
252 34 10238976 dm-34
252 35 2920025543 dm-35
252 36 2920025543 dm-36
252 37 10238976 dm-37
252 38 2920025543 dm-38
252 39 10238976 dm-39
252 40 2920025543 dm-40
252 41 2920025543 dm-41
252 42 2920025543 dm-42
252 43 10238976 dm-43
252 44 10238976 dm-44
252 45 10238976 dm-45
252 46 10238976 dm-46
252 47 2920025543 dm-47
252 48 2920025543 dm-48
252 49 10238976 dm-49
252 50 2920025543 dm-50
252 51 10238976 dm-51
252 52 2920025543 dm-52
252 53 10238976 dm-53
252 54 10238976 dm-54
252 55 2920025543 dm-55
252 56 2920025543 dm-56
252 57 10238976 dm-57
252 59 2920025543 dm-59
252 58 10238976 dm-58
252 60 10238976 dm-60
252 61 2920025543 dm-61
252 62 2920025543 dm-62
252 63 10238976 dm-63
252 64 2920025543 dm-64
252 65 10238976 dm-65
252 66 2920025543 dm-66
252 67 10238976 dm-67
252 68 2920025543 dm-68
252 69 10238976 dm-69
252 70 10238976 dm-70
252 71 2920025543 dm-71
252 72 10238976 dm-72
252 73 2920025543 dm-73
RAID layout: None
LVM configuration: None
HGST 3TB
meta-data=/dev/mapper/63e3300b-6b7b-41a0-bdf2-b64ec3c20c51 isize=2048 agcount=32, agsize=22812700 blks
= sectsz=4096 attr=2
data = bsize=4096 blocks=730006385, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=356448, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Some additional info can be found in the following ubuntu bug:
________________________________
Tom Christensen | Senior Software Engineer | StorageCraft Technology Corporation<http://www.storagecraft.com>
380 Data Drive Suite 300 | Draper | Utah | 84020
Office: 801.871.2774 | Mobile: 385.230.2422
________________________________
If you are not the intended recipient of this message, be advised that any dissemination or copying of this message is prohibited.
If you received this message erroneously, please notify the sender and delete it, together with any attachments.
[-- Attachment #1.2: Type: text/html, Size: 29593 bytes --]
[-- Attachment #2: dmesg.out --]
[-- Type: application/octet-stream, Size: 207835 bytes --]
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.16.0-38-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 (Ubuntu 3.16.0-38.52~14.04.1-generic 3.16.7-ckt10)
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.16.0-38-generic root=/dev/mapper/system-root ro
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] Centaur CentaurHauls
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009abff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009ac00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007de46fff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007de47000-0x000000007e00afff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007e00b000-0x000000007e200fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x000000007e201000-0x000000007f365fff] reserved
[ 0.000000] BIOS-e820: [mem 0x000000007f366000-0x000000007f7fffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000080000000-0x000000008fffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed3ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000000] AGP: No AGP bridge found
[ 0.000000] e820: last_pfn = 0x4080000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000000 mask 3FC000000000 write-back
[ 0.000000] 1 base 004000000000 mask 3FFF80000000 write-back
[ 0.000000] 2 base 000080000000 mask 3FFF80000000 uncachable
[ 0.000000] 3 disabled
[ 0.000000] 4 disabled
[ 0.000000] 5 disabled
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 256GB, type WB
[ 0.000000] reg 1, base: 256GB, range: 2GB, type WB
[ 0.000000] reg 2, base: 2GB, range: 2GB, type UC
[ 0.000000] total RAM covered: 262144M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 64K num_reg: 8 lose cover RAM: 0G
[ 0.000000] New variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 4GB, range: 4GB, type WB
[ 0.000000] reg 2, base: 8GB, range: 8GB, type WB
[ 0.000000] reg 3, base: 16GB, range: 16GB, type WB
[ 0.000000] reg 4, base: 32GB, range: 32GB, type WB
[ 0.000000] reg 5, base: 64GB, range: 64GB, type WB
[ 0.000000] reg 6, base: 128GB, range: 128GB, type WB
[ 0.000000] reg 7, base: 256GB, range: 2GB, type WB
[ 0.000000] e820: update [mem 0x80000000-0xffffffff] usable ==> reserved
[ 0.000000] e820: last_pfn = 0x7de47 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [mem 0x000fdb50-0x000fdb5f] mapped at [ffff8800000fdb50]
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.000000] Base memory trampoline at [ffff880000094000] 94000 size 24576
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] [mem 0x00000000-0x000fffff] page 4k
[ 0.000000] BRK [0x01fbd000, 0x01fbdfff] PGTABLE
[ 0.000000] BRK [0x01fbe000, 0x01fbefff] PGTABLE
[ 0.000000] BRK [0x01fbf000, 0x01fbffff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x407fe00000-0x407fffffff]
[ 0.000000] [mem 0x407fe00000-0x407fffffff] page 1G
[ 0.000000] init_memory_mapping: [mem 0x407c000000-0x407fdfffff]
[ 0.000000] [mem 0x407c000000-0x407fdfffff] page 1G
[ 0.000000] init_memory_mapping: [mem 0x4000000000-0x407bffffff]
[ 0.000000] [mem 0x4000000000-0x407bffffff] page 1G
[ 0.000000] init_memory_mapping: [mem 0x3000000000-0x3fffffffff]
[ 0.000000] [mem 0x3000000000-0x3fffffffff] page 1G
[ 0.000000] init_memory_mapping: [mem 0x00100000-0x7de46fff]
[ 0.000000] [mem 0x00100000-0x001fffff] page 4k
[ 0.000000] [mem 0x00200000-0x7ddfffff] page 2M
[ 0.000000] [mem 0x7de00000-0x7de46fff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x100000000-0x2fffffffff]
[ 0.000000] [mem 0x100000000-0x2fffffffff] page 1G
[ 0.000000] RAMDISK: [mem 0x358a0000-0x36c47fff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F04A0 000024 (v02 SUPERM)
[ 0.000000] ACPI: XSDT 0x000000007E124090 00009C (v01 SUPERM SMCI--MB 00000001 AMI 00010013)
[ 0.000000] ACPI: FACP 0x000000007E12EAD0 0000F4 (v04 SUPERM SMCI--MB 00000001 AMI 00010013)
[ 0.000000] ACPI: DSDT 0x000000007E1241C0 00A90E (v02 SUPERM SMCI--MB 00000000 INTL 20091112)
[ 0.000000] ACPI: FACS 0x000000007E1F8080 000040
[ 0.000000] ACPI: APIC 0x000000007E12EBC8 0001B4 (v03 00000001 AMI 00010013)
[ 0.000000] ACPI: FPDT 0x000000007E12ED80 000044 (v01 00000001 AMI 00010013)
[ 0.000000] ACPI: SRAT 0x000000007E12EDC8 000430 (v01 A M I AMI SRAT 00000001 AMI. 00000000)
[ 0.000000] ACPI: SLIT 0x000000007E12F1F8 000030 (v01 A M I AMI SLIT 00000000 AMI. 00000000)
[ 0.000000] ACPI: HPET 0x000000007E12F228 000038 (v01 SUPERM SMCI--MB 00000001 AMI. 00000005)
[ 0.000000] ACPI: PRAD 0x000000007E12F260 0000BE (v02 PRADID PRADTID 00000001 MSFT 04000000)
[ 0.000000] ACPI: SPMI 0x000000007E12F320 000040 (v05 A M I OEMSPMI 00000000 AMI. 00000000)
[ 0.000000] ACPI: SSDT 0x000000007E12F360 0C7AE8 (v02 INTEL CpuPm 00004000 INTL 20091112)
[ 0.000000] ACPI: EINJ 0x000000007E1F6E48 000130 (v01 AMI AMI EINJ 00000000 00000000)
[ 0.000000] ACPI: ERST 0x000000007E1F6F78 000230 (v01 AMIER AMI ERST 00000000 00000000)
[ 0.000000] ACPI: HEST 0x000000007E1F71A8 0000A8 (v01 AMI AMI HEST 00000000 00000000)
[ 0.000000] ACPI: BERT 0x000000007E1F7250 000030 (v01 AMI AMI BERT 00000000 00000000)
[ 0.000000] ACPI: DMAR 0x000000007E1F7280 000158 (v01 A M I OEMDMAR 00000001 INTL 00000001)
[ 0.000000] ACPI: MCFG 0x000000007E1F73D8 00003C (v01 SUPERM SMCI--MB 00000001 MSFT 00000097)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x04 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x05 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x06 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x07 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x08 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x09 -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0a -> Node 0
[ 0.000000] SRAT: PXM 0 -> APIC 0x0b -> Node 0
[ 0.000000] SRAT: PXM 1 -> APIC 0x20 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x21 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x22 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x23 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x24 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x25 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x26 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x27 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x28 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x29 -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2a -> Node 1
[ 0.000000] SRAT: PXM 1 -> APIC 0x2b -> Node 1
[ 0.000000] SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] SRAT: Node 0 PXM 0 [mem 0x100000000-0x207fffffff]
[ 0.000000] SRAT: Node 1 PXM 1 [mem 0x2080000000-0x407fffffff]
[ 0.000000] NUMA: Initialized distance table, cnt=2
[ 0.000000] NUMA: Node 0 [mem 0x00000000-0x7fffffff] + [mem 0x100000000-0x207fffffff] -> [mem 0x00000000-0x207fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x00000000-0x207fffffff]
[ 0.000000] NODE_DATA [mem 0x207fffb000-0x207fffffff]
[ 0.000000] Initmem setup node 1 [mem 0x2080000000-0x407fffffff]
[ 0.000000] NODE_DATA [mem 0x407fff8000-0x407fffcfff]
[ 0.000000] [ffffea0000000000-ffffea0081ffffff] PMD -> [ffff881fffe00000-ffff88207fdfffff] on node 0
[ 0.000000] [ffffea0082000000-ffffea0101ffffff] PMD -> [ffff883fff600000-ffff88407f5fffff] on node 1
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x00001000-0x00ffffff]
[ 0.000000] DMA32 [mem 0x01000000-0xffffffff]
[ 0.000000] Normal [mem 0x100000000-0x407fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00001000-0x00099fff]
[ 0.000000] node 0: [mem 0x00100000-0x7de46fff]
[ 0.000000] node 0: [mem 0x100000000-0x207fffffff]
[ 0.000000] node 1: [mem 0x2080000000-0x407fffffff]
[ 0.000000] On node 0 totalpages: 33545696
[ 0.000000] DMA zone: 64 pages used for memmap
[ 0.000000] DMA zone: 21 pages reserved
[ 0.000000] DMA zone: 3993 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 7994 pages used for memmap
[ 0.000000] DMA32 zone: 511559 pages, LIFO batch:31
[ 0.000000] Normal zone: 516096 pages used for memmap
[ 0.000000] Normal zone: 33030144 pages, LIFO batch:31
[ 0.000000] On node 1 totalpages: 33554432
[ 0.000000] Normal zone: 524288 pages used for memmap
[ 0.000000] Normal zone: 33554432 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x20] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x22] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x24] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x12] lapic_id[0x26] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x14] lapic_id[0x28] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x16] lapic_id[0x2a] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x21] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x23] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x11] lapic_id[0x25] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x13] lapic_id[0x27] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x15] lapic_id[0x29] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x17] lapic_id[0x2b] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0e] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x0f] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec01000] gsi_base[24])
[ 0.000000] IOAPIC[1]: apic_id 2, version 32, address 0xfec01000, GSI 24-47
[ 0.000000] ACPI: IOAPIC (id[0x03] address[0xfec40000] gsi_base[48])
[ 0.000000] IOAPIC[2]: apic_id 3, version 32, address 0xfec40000, GSI 48-71
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.000000] smpboot: Allowing 24 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 88
[ 0.000000] PM: Registered nosave memory: [mem 0x0009a000-0x0009afff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009b000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000dffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000e0000-0x000fffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x7de47000-0x7e00afff]
[ 0.000000] PM: Registered nosave memory: [mem 0x7e00b000-0x7e200fff]
[ 0.000000] PM: Registered nosave memory: [mem 0x7e201000-0x7f365fff]
[ 0.000000] PM: Registered nosave memory: [mem 0x7f366000-0x7f7fffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x7f800000-0x7fffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x80000000-0x8fffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x90000000-0xfed1bfff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed3ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfed40000-0xfeffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
[ 0.000000] e820: [mem 0x90000000-0xfed1bfff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on bare hardware
[ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:24 nr_node_ids:2
[ 0.000000] PERCPU: Embedded 27 pages/cpu @ffff881fffc00000 s81408 r8192 d20992 u131072
[ 0.000000] pcpu-alloc: s81408 r8192 d20992 u131072 alloc=1*2097152
[ 0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 12 13 14 15 16 17 -- -- -- --
[ 0.000000] pcpu-alloc: [1] 06 07 08 09 10 11 18 19 20 21 22 23 -- -- -- --
[ 0.000000] Built 2 zonelists in Zone order, mobility grouping on. Total pages: 66051665
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-38-generic root=/dev/mapper/system-root ro
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[ 0.000000] AGP: Checking aperture...
[ 0.000000] AGP: No AGP bridge found
[ 0.000000] Calgary: detecting Calgary via BIOS EBDA area
[ 0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[ 0.000000] Memory: 264100676K/268400512K available (7626K kernel code, 1131K rwdata, 3596K rodata, 1352K init, 1300K bss, 4299836K reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=24, Nodes=2
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU dyntick-idle grace-period acceleration is enabled.
[ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=24.
[ 0.000000] Offload RCU callbacks from all CPUs
[ 0.000000] Offload RCU callbacks from CPUs: 0-23.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=24
[ 0.000000] NR_IRQS:16640 nr_irqs:1688 16
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] allocated 1073741824 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2600.082 MHz processor
[ 0.000038] Calibrating delay loop (skipped), value calculated using timer frequency.. 5200.16 BogoMIPS (lpj=10400328)
[ 0.000043] pid_max: default: 32768 minimum: 301
[ 0.000059] ACPI: Core revision 20140424
[ 0.041733] ACPI: All ACPI Tables successfully acquired
[ 0.042085] Security Framework initialized
[ 0.042130] AppArmor: AppArmor initialized
[ 0.042132] Yama: becoming mindful.
[ 0.057775] Dentry cache hash table entries: 33554432 (order: 16, 268435456 bytes)
[ 0.118859] Inode-cache hash table entries: 16777216 (order: 15, 134217728 bytes)
[ 0.145859] Mount-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.146112] Mountpoint-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.147603] Initializing cgroup subsys memory
[ 0.147637] Initializing cgroup subsys devices
[ 0.147643] Initializing cgroup subsys freezer
[ 0.147647] Initializing cgroup subsys net_cls
[ 0.147651] Initializing cgroup subsys blkio
[ 0.147656] Initializing cgroup subsys perf_event
[ 0.147659] Initializing cgroup subsys net_prio
[ 0.147667] Initializing cgroup subsys hugetlb
[ 0.147704] CPU: Physical Processor ID: 0
[ 0.147706] CPU: Processor Core ID: 0
[ 0.148516] mce: CPU supports 23 MCE banks
[ 0.148551] CPU0: Thermal monitoring enabled (TM1)
[ 0.148581] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8
[ 0.148581] Last level dTLB entries: 4KB 512, 2MB 0, 4MB 0, 1GB 4
[ 0.148581] tlb_flushall_shift: 6
[ 0.148729] Freeing SMP alternatives memory: 32K (ffffffff81e6e000 - ffffffff81e76000)
[ 0.149877] ftrace: allocating 29244 entries in 115 pages
[ 0.163743] dmar: Host address width 46
[ 0.163746] dmar: DRHD base: 0x000000fbffe000 flags: 0x0
[ 0.163753] dmar: IOMMU 0: reg_base_addr fbffe000 ver 1:0 cap d2078c106f0466 ecap f020de
[ 0.163756] dmar: DRHD base: 0x000000dfffc000 flags: 0x1
[ 0.163761] dmar: IOMMU 1: reg_base_addr dfffc000 ver 1:0 cap d2078c106f0466 ecap f020de
[ 0.163763] dmar: RMRR base: 0x0000007deac000 end: 0x0000007deb8fff
[ 0.163765] dmar: ATSR flags: 0x0
[ 0.163766] dmar: RHSA base: 0x000000fbffe000 proximity domain: 0x1
[ 0.163768] dmar: RHSA base: 0x000000dfffc000 proximity domain: 0x0
[ 0.163898] IOAPIC id 3 under DRHD base 0xfbffe000 IOMMU 0
[ 0.163899] IOAPIC id 0 under DRHD base 0xdfffc000 IOMMU 1
[ 0.163901] IOAPIC id 2 under DRHD base 0xdfffc000 IOMMU 1
[ 0.163902] HPET id 0 under DRHD base 0xdfffc000
[ 0.163904] Queued invalidation will be enabled to support x2apic and Intr-remapping.
[ 0.164556] Enabled IRQ remapping in x2apic mode
[ 0.164558] Enabling x2apic
[ 0.164559] Enabled x2apic
[ 0.164564] Switched APIC routing to cluster x2apic.
[ 0.165210] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.204911] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (fam: 06, model: 3e, stepping: 04)
[ 0.204920] TSC deadline timer enabled
[ 0.204946] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, full-width counters, Intel PMU driver.
[ 0.204968] ... version: 3
[ 0.204969] ... bit width: 48
[ 0.204970] ... generic registers: 4
[ 0.204972] ... value mask: 0000ffffffffffff
[ 0.204973] ... max period: 0000ffffffffffff
[ 0.204974] ... fixed-purpose events: 3
[ 0.204976] ... event mask: 000000070000000f
[ 0.207316] x86: Booting SMP configuration:
[ 0.207319] .... node #0, CPUs: #1
[ 0.222805] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[ 0.222932] #2 #3 #4 #5
[ 0.278940] .... node #1, CPUs: #6 #7 #8 #9 #10 #11
[ 0.461316] .... node #0, CPUs: #12 #13 #14 #15 #16 #17
[ 0.545535] .... node #1, CPUs: #18 #19 #20 #21 #22 #23
[ 0.629693] x86: Booted up 2 nodes, 24 CPUs
[ 0.629696] smpboot: Total of 24 processors activated (124824.57 BogoMIPS)
[ 0.668845] devtmpfs: initialized
[ 0.668957] memory block size : 2048MB
[ 0.672427] evm: security.selinux
[ 0.672429] evm: security.SMACK64
[ 0.672430] evm: security.SMACK64EXEC
[ 0.672432] evm: security.SMACK64TRANSMUTE
[ 0.672433] evm: security.SMACK64MMAP
[ 0.672434] evm: security.ima
[ 0.672435] evm: security.capability
[ 0.672505] PM: Registering ACPI NVS region [mem 0x7e00b000-0x7e200fff] (2056192 bytes)
[ 0.672546] PM: Registering ACPI NVS region [mem 0x7f366000-0x7f7fffff] (4825088 bytes)
[ 0.673746] pinctrl core: initialized pinctrl subsystem
[ 0.673844] regulator-dummy: no parameters
[ 0.673882] RTC time: 16:12:04, date: 06/11/15
[ 0.673957] NET: Registered protocol family 16
[ 0.674122] cpuidle: using governor ladder
[ 0.674126] cpuidle: using governor menu
[ 0.674175] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.674178] ACPI: bus type PCI registered
[ 0.674180] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.674279] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
[ 0.674282] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820
[ 0.674687] PCI: Using configuration type 1 for base access
[ 0.681018] ACPI: Added _OSI(Module Device)
[ 0.681022] ACPI: Added _OSI(Processor Device)
[ 0.681023] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.681025] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.693389] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.947607] \_SB_:_OSC invalid UUID
[ 0.947609] _OSC request data:1 1f
[ 0.950043] ACPI: Interpreter enabled
[ 0.950053] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140424/hwxface-580)
[ 0.950058] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20140424/hwxface-580)
[ 0.950067] ACPI: (supports S0 S1 S4 S5)
[ 0.950069] ACPI: Using IOAPIC for interrupt routing
[ 0.950124] HEST: Table parsing has been initialized.
[ 0.950128] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.963447] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
[ 0.963453] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.963572] acpi PNP0A08:00: _OSC: platform does not support [PME AER]
[ 0.963671] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PCIeCapability]
[ 0.963674] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[ 0.963944] PCI host bridge to bus 0000:00
[ 0.963948] pci_bus 0000:00: root bus resource [bus 00-7e]
[ 0.963950] pci_bus 0000:00: root bus resource [io 0x0000-0x03af]
[ 0.963953] pci_bus 0000:00: root bus resource [io 0x03e0-0x0cf7]
[ 0.963954] pci_bus 0000:00: root bus resource [io 0x03b0-0x03df]
[ 0.963957] pci_bus 0000:00: root bus resource [io 0x0d00-0x9fff]
[ 0.963959] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[ 0.963961] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
[ 0.963963] pci_bus 0000:00: root bus resource [mem 0xfed08000-0xfed08fff]
[ 0.963965] pci_bus 0000:00: root bus resource [mem 0xfed0e000-0xfed0ffff]
[ 0.963967] pci_bus 0000:00: root bus resource [mem 0x80000000-0xdfffffff]
[ 0.963979] pci 0000:00:00.0: [8086:0e00] type 00 class 0x060000
[ 0.964044] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[ 0.964112] pci 0000:00:01.0: [8086:0e02] type 01 class 0x060400
[ 0.964186] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[ 0.964222] pci 0000:00:01.0: System wakeup disabled by ACPI
[ 0.964261] pci 0000:00:01.1: [8086:0e03] type 01 class 0x060400
[ 0.964332] pci 0000:00:01.1: PME# supported from D0 D3hot D3cold
[ 0.964366] pci 0000:00:01.1: System wakeup disabled by ACPI
[ 0.964411] pci 0000:00:02.0: [8086:0e04] type 01 class 0x060400
[ 0.964483] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[ 0.964517] pci 0000:00:02.0: System wakeup disabled by ACPI
[ 0.964561] pci 0000:00:03.0: [8086:0e08] type 01 class 0x060400
[ 0.964635] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
[ 0.964669] pci 0000:00:03.0: System wakeup disabled by ACPI
[ 0.964708] pci 0000:00:04.0: [8086:0e20] type 00 class 0x088000
[ 0.964724] pci 0000:00:04.0: reg 0x10: [mem 0xdfc1c000-0xdfc1ffff 64bit]
[ 0.964837] pci 0000:00:04.1: [8086:0e21] type 00 class 0x088000
[ 0.964851] pci 0000:00:04.1: reg 0x10: [mem 0xdfc18000-0xdfc1bfff 64bit]
[ 0.964965] pci 0000:00:04.2: [8086:0e22] type 00 class 0x088000
[ 0.964979] pci 0000:00:04.2: reg 0x10: [mem 0xdfc14000-0xdfc17fff 64bit]
[ 0.965091] pci 0000:00:04.3: [8086:0e23] type 00 class 0x088000
[ 0.965105] pci 0000:00:04.3: reg 0x10: [mem 0xdfc10000-0xdfc13fff 64bit]
[ 0.965218] pci 0000:00:04.4: [8086:0e24] type 00 class 0x088000
[ 0.965232] pci 0000:00:04.4: reg 0x10: [mem 0xdfc0c000-0xdfc0ffff 64bit]
[ 0.965343] pci 0000:00:04.5: [8086:0e25] type 00 class 0x088000
[ 0.965357] pci 0000:00:04.5: reg 0x10: [mem 0xdfc08000-0xdfc0bfff 64bit]
[ 0.965472] pci 0000:00:04.6: [8086:0e26] type 00 class 0x088000
[ 0.965486] pci 0000:00:04.6: reg 0x10: [mem 0xdfc04000-0xdfc07fff 64bit]
[ 0.965599] pci 0000:00:04.7: [8086:0e27] type 00 class 0x088000
[ 0.965613] pci 0000:00:04.7: reg 0x10: [mem 0xdfc00000-0xdfc03fff 64bit]
[ 0.965723] pci 0000:00:05.0: [8086:0e28] type 00 class 0x088000
[ 0.965821] pci 0000:00:05.2: [8086:0e2a] type 00 class 0x088000
[ 0.965922] pci 0000:00:05.4: [8086:0e2c] type 00 class 0x080020
[ 0.965932] pci 0000:00:05.4: reg 0x10: [mem 0xdfc25000-0xdfc25fff]
[ 0.966054] pci 0000:00:11.0: [8086:1d3e] type 01 class 0x060400
[ 0.966152] pci 0000:00:11.0: PME# supported from D0 D3hot D3cold
[ 0.966236] pci 0000:00:16.0: [8086:1d3a] type 00 class 0x078000
[ 0.966254] pci 0000:00:16.0: reg 0x10: [mem 0xfed0e000-0xfed0e00f 64bit]
[ 0.966316] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold
[ 0.966380] pci 0000:00:16.1: [8086:1d3b] type 00 class 0x078000
[ 0.966398] pci 0000:00:16.1: reg 0x10: [mem 0xfed0f000-0xfed0f00f 64bit]
[ 0.966460] pci 0000:00:16.1: PME# supported from D0 D3hot D3cold
[ 0.966540] pci 0000:00:1a.0: [8086:1d2d] type 00 class 0x0c0320
[ 0.966560] pci 0000:00:1a.0: reg 0x10: [mem 0xdfc23000-0xdfc233ff]
[ 0.966647] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
[ 0.966679] pci 0000:00:1a.0: System wakeup disabled by ACPI
[ 0.966722] pci 0000:00:1c.0: [8086:1d10] type 01 class 0x060400
[ 0.966801] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.966836] pci 0000:00:1c.0: System wakeup disabled by ACPI
[ 0.966882] pci 0000:00:1d.0: [8086:1d26] type 00 class 0x0c0320
[ 0.966902] pci 0000:00:1d.0: reg 0x10: [mem 0xdfc22000-0xdfc223ff]
[ 0.966988] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[ 0.967022] pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 0.967054] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[ 0.967123] pci 0000:00:1e.0: System wakeup disabled by ACPI
[ 0.967167] pci 0000:00:1f.0: [8086:1d41] type 00 class 0x060100
[ 0.967335] pci 0000:00:1f.2: [8086:1d02] type 00 class 0x010601
[ 0.967352] pci 0000:00:1f.2: reg 0x10: [io 0x9050-0x9057]
[ 0.967360] pci 0000:00:1f.2: reg 0x14: [io 0x9040-0x9043]
[ 0.967367] pci 0000:00:1f.2: reg 0x18: [io 0x9030-0x9037]
[ 0.967375] pci 0000:00:1f.2: reg 0x1c: [io 0x9020-0x9023]
[ 0.967383] pci 0000:00:1f.2: reg 0x20: [io 0x9000-0x901f]
[ 0.967390] pci 0000:00:1f.2: reg 0x24: [mem 0xdfc21000-0xdfc217ff]
[ 0.967433] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.967511] pci 0000:00:1f.3: [8086:1d22] type 00 class 0x0c0500
[ 0.967525] pci 0000:00:1f.3: reg 0x10: [mem 0xdfc20000-0xdfc200ff 64bit]
[ 0.967544] pci 0000:00:1f.3: reg 0x20: [io 0x1180-0x119f]
[ 0.967624] pci 0000:00:1f.6: [8086:1d24] type 00 class 0x118000
[ 0.967643] pci 0000:00:1f.6: reg 0x10: [mem 0xfed08000-0xfed08fff 64bit]
[ 0.967816] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 0.967867] pci 0000:00:01.1: PCI bridge to [bus 02]
[ 0.967927] pci 0000:03:00.0: [1000:0087] type 00 class 0x010700
[ 0.967935] pci 0000:03:00.0: reg 0x10: [io 0x8000-0x80ff]
[ 0.967942] pci 0000:03:00.0: reg 0x14: [mem 0xdfa40000-0xdfa4ffff 64bit]
[ 0.967949] pci 0000:03:00.0: reg 0x1c: [mem 0xdfa00000-0xdfa3ffff 64bit]
[ 0.967958] pci 0000:03:00.0: reg 0x30: [mem 0xdf900000-0xdf9fffff pref]
[ 0.967989] pci 0000:03:00.0: supports D1 D2
[ 0.975535] pci 0000:00:02.0: PCI bridge to [bus 03]
[ 0.975539] pci 0000:00:02.0: bridge window [io 0x8000-0x8fff]
[ 0.975542] pci 0000:00:02.0: bridge window [mem 0xdf900000-0xdfafffff]
[ 0.975590] pci 0000:00:03.0: PCI bridge to [bus 04]
[ 0.975677] pci 0000:05:00.0: [8086:1d6b] type 00 class 0x010700
[ 0.975697] pci 0000:05:00.0: reg 0x10: [mem 0xde47c000-0xde47ffff 64bit pref]
[ 0.975712] pci 0000:05:00.0: reg 0x18: [mem 0xde000000-0xde3fffff 64bit pref]
[ 0.975721] pci 0000:05:00.0: reg 0x20: [io 0x7000-0x70ff]
[ 0.975832] pci 0000:05:00.0: reg 0x164: [mem 0xde400000-0xde403fff 64bit pref]
[ 0.975917] pci 0000:00:11.0: PCI bridge to [bus 05]
[ 0.975921] pci 0000:00:11.0: bridge window [io 0x7000-0x7fff]
[ 0.975930] pci 0000:00:11.0: bridge window [mem 0xde000000-0xde4fffff 64bit pref]
[ 0.976011] pci 0000:06:00.0: [8086:1521] type 00 class 0x020000
[ 0.976032] pci 0000:06:00.0: reg 0x10: [mem 0xdfb60000-0xdfb7ffff]
[ 0.976057] pci 0000:06:00.0: reg 0x18: [io 0x6060-0x607f]
[ 0.976070] pci 0000:06:00.0: reg 0x1c: [mem 0xdfb8c000-0xdfb8ffff]
[ 0.976205] pci 0000:06:00.0: PME# supported from D0 D3hot D3cold
[ 0.976262] pci 0000:06:00.0: reg 0x184: [mem 0xde6e0000-0xde6e3fff 64bit pref]
[ 0.976290] pci 0000:06:00.0: reg 0x190: [mem 0xde6c0000-0xde6c3fff 64bit pref]
[ 0.976311] pci 0000:06:00.0: System wakeup disabled by ACPI
[ 0.976375] pci 0000:06:00.1: [8086:1521] type 00 class 0x020000
[ 0.976396] pci 0000:06:00.1: reg 0x10: [mem 0xdfb40000-0xdfb5ffff]
[ 0.976420] pci 0000:06:00.1: reg 0x18: [io 0x6040-0x605f]
[ 0.976433] pci 0000:06:00.1: reg 0x1c: [mem 0xdfb88000-0xdfb8bfff]
[ 0.976563] pci 0000:06:00.1: PME# supported from D0 D3hot D3cold
[ 0.976618] pci 0000:06:00.1: reg 0x184: [mem 0xde6a0000-0xde6a3fff 64bit pref]
[ 0.976647] pci 0000:06:00.1: reg 0x190: [mem 0xde680000-0xde683fff 64bit pref]
[ 0.976716] pci 0000:06:00.2: [8086:1521] type 00 class 0x020000
[ 0.976737] pci 0000:06:00.2: reg 0x10: [mem 0xdfb20000-0xdfb3ffff]
[ 0.976761] pci 0000:06:00.2: reg 0x18: [io 0x6020-0x603f]
[ 0.976774] pci 0000:06:00.2: reg 0x1c: [mem 0xdfb84000-0xdfb87fff]
[ 0.976904] pci 0000:06:00.2: PME# supported from D0 D3hot D3cold
[ 0.976959] pci 0000:06:00.2: reg 0x184: [mem 0xde660000-0xde663fff 64bit pref]
[ 0.976988] pci 0000:06:00.2: reg 0x190: [mem 0xde640000-0xde643fff 64bit pref]
[ 0.977063] pci 0000:06:00.3: [8086:1521] type 00 class 0x020000
[ 0.977084] pci 0000:06:00.3: reg 0x10: [mem 0xdfb00000-0xdfb1ffff]
[ 0.977109] pci 0000:06:00.3: reg 0x18: [io 0x6000-0x601f]
[ 0.977121] pci 0000:06:00.3: reg 0x1c: [mem 0xdfb80000-0xdfb83fff]
[ 0.977251] pci 0000:06:00.3: PME# supported from D0 D3hot D3cold
[ 0.977306] pci 0000:06:00.3: reg 0x184: [mem 0xde620000-0xde623fff 64bit pref]
[ 0.977338] pci 0000:06:00.3: reg 0x190: [mem 0xde600000-0xde603fff 64bit pref]
[ 0.983548] pci 0000:00:1c.0: PCI bridge to [bus 06-07]
[ 0.983553] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff]
[ 0.983556] pci 0000:00:1c.0: bridge window [mem 0xdfb00000-0xdfbfffff]
[ 0.983561] pci 0000:00:1c.0: bridge window [mem 0xde600000-0xde6fffff 64bit pref]
[ 0.983600] pci 0000:08:01.0: [102b:0532] type 00 class 0x030000
[ 0.983616] pci 0000:08:01.0: reg 0x10: [mem 0xdd000000-0xddffffff pref]
[ 0.983626] pci 0000:08:01.0: reg 0x14: [mem 0xdf800000-0xdf803fff]
[ 0.983635] pci 0000:08:01.0: reg 0x18: [mem 0xdf000000-0xdf7fffff]
[ 0.983761] pci 0000:00:1e.0: PCI bridge to [bus 08] (subtractive decode)
[ 0.983767] pci 0000:00:1e.0: bridge window [mem 0xdf000000-0xdf8fffff]
[ 0.983774] pci 0000:00:1e.0: bridge window [mem 0xdd000000-0xddffffff 64bit pref]
[ 0.983775] pci 0000:00:1e.0: bridge window [io 0x0000-0x03af] (subtractive decode)
[ 0.983777] pci 0000:00:1e.0: bridge window [io 0x03e0-0x0cf7] (subtractive decode)
[ 0.983778] pci 0000:00:1e.0: bridge window [io 0x03b0-0x03df] (subtractive decode)
[ 0.983780] pci 0000:00:1e.0: bridge window [io 0x0d00-0x9fff] (subtractive decode)
[ 0.983781] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[ 0.983782] pci 0000:00:1e.0: bridge window [mem 0x000c0000-0x000dffff] (subtractive decode)
[ 0.983784] pci 0000:00:1e.0: bridge window [mem 0xfed08000-0xfed08fff] (subtractive decode)
[ 0.983785] pci 0000:00:1e.0: bridge window [mem 0xfed0e000-0xfed0ffff] (subtractive decode)
[ 0.983787] pci 0000:00:1e.0: bridge window [mem 0x80000000-0xdfffffff] (subtractive decode)
[ 0.983829] pci_bus 0000:00: on NUMA node 0
[ 0.984191] ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus 7f])
[ 0.984195] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.984214] acpi PNP0A03:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 0.984217] acpi PNP0A03:00: FADT indicates ASPM is unsupported, using BIOS configuration
[ 0.984269] PCI host bridge to bus 0000:7f
[ 0.984272] pci_bus 0000:7f: root bus resource [bus 7f]
[ 0.984280] pci 0000:7f:08.0: [8086:0e80] type 00 class 0x088000
[ 0.984341] pci 0000:7f:09.0: [8086:0e90] type 00 class 0x088000
[ 0.984390] pci 0000:7f:0a.0: [8086:0ec0] type 00 class 0x088000
[ 0.984434] pci 0000:7f:0a.1: [8086:0ec1] type 00 class 0x088000
[ 0.984476] pci 0000:7f:0a.2: [8086:0ec2] type 00 class 0x088000
[ 0.984517] pci 0000:7f:0a.3: [8086:0ec3] type 00 class 0x088000
[ 0.984559] pci 0000:7f:0b.0: [8086:0e1e] type 00 class 0x088000
[ 0.984598] pci 0000:7f:0b.3: [8086:0e1f] type 00 class 0x088000
[ 0.984638] pci 0000:7f:0c.0: [8086:0ee0] type 00 class 0x088000
[ 0.984678] pci 0000:7f:0c.1: [8086:0ee2] type 00 class 0x088000
[ 0.984716] pci 0000:7f:0c.2: [8086:0ee4] type 00 class 0x088000
[ 0.984757] pci 0000:7f:0d.0: [8086:0ee1] type 00 class 0x088000
[ 0.984796] pci 0000:7f:0d.1: [8086:0ee3] type 00 class 0x088000
[ 0.984835] pci 0000:7f:0d.2: [8086:0ee5] type 00 class 0x088000
[ 0.984876] pci 0000:7f:0e.0: [8086:0ea0] type 00 class 0x088000
[ 0.984918] pci 0000:7f:0e.1: [8086:0e30] type 00 class 0x110100
[ 0.984965] pci 0000:7f:0f.0: [8086:0ea8] type 00 class 0x088000
[ 0.985023] pci 0000:7f:0f.1: [8086:0e71] type 00 class 0x088000
[ 0.985087] pci 0000:7f:0f.2: [8086:0eaa] type 00 class 0x088000
[ 0.985142] pci 0000:7f:0f.3: [8086:0eab] type 00 class 0x088000
[ 0.985195] pci 0000:7f:0f.4: [8086:0eac] type 00 class 0x088000
[ 0.985248] pci 0000:7f:0f.5: [8086:0ead] type 00 class 0x088000
[ 0.985301] pci 0000:7f:10.0: [8086:0eb0] type 00 class 0x088000
[ 0.985355] pci 0000:7f:10.1: [8086:0eb1] type 00 class 0x088000
[ 0.985407] pci 0000:7f:10.2: [8086:0eb2] type 00 class 0x088000
[ 0.985464] pci 0000:7f:10.3: [8086:0eb3] type 00 class 0x088000
[ 0.985517] pci 0000:7f:10.4: [8086:0eb4] type 00 class 0x088000
[ 0.985572] pci 0000:7f:10.5: [8086:0eb5] type 00 class 0x088000
[ 0.985627] pci 0000:7f:10.6: [8086:0eb6] type 00 class 0x088000
[ 0.985683] pci 0000:7f:10.7: [8086:0eb7] type 00 class 0x088000
[ 0.985738] pci 0000:7f:13.0: [8086:0e1d] type 00 class 0x088000
[ 0.985780] pci 0000:7f:13.1: [8086:0e34] type 00 class 0x110100
[ 0.985822] pci 0000:7f:13.4: [8086:0e81] type 00 class 0x088000
[ 0.985865] pci 0000:7f:13.5: [8086:0e36] type 00 class 0x110100
[ 0.985908] pci 0000:7f:16.0: [8086:0ec8] type 00 class 0x088000
[ 0.985950] pci 0000:7f:16.1: [8086:0ec9] type 00 class 0x088000
[ 0.985988] pci 0000:7f:16.2: [8086:0eca] type 00 class 0x088000
[ 0.986034] pci_bus 0000:7f: on NUMA node 0
[ 0.986127] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-fe])
[ 0.986131] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.986241] acpi PNP0A08:01: _OSC: platform does not support [PME AER]
[ 0.986339] acpi PNP0A08:01: _OSC: OS now controls [PCIeHotplug PCIeCapability]
[ 0.986345] acpi PNP0A08:01: FADT indicates ASPM is unsupported, using BIOS configuration
[ 0.986539] PCI host bridge to bus 0000:80
[ 0.986542] pci_bus 0000:80: root bus resource [bus 80-fe]
[ 0.986544] pci_bus 0000:80: root bus resource [io 0xa000-0xffff]
[ 0.986546] pci_bus 0000:80: root bus resource [mem 0xe0000000-0xfbffffff]
[ 0.986560] pci 0000:80:01.0: [8086:0e02] type 01 class 0x060400
[ 0.986646] pci 0000:80:01.0: PME# supported from D0 D3hot D3cold
[ 0.986676] pci 0000:80:01.0: System wakeup disabled by ACPI
[ 0.986718] pci 0000:80:02.0: [8086:0e04] type 01 class 0x060400
[ 0.986800] pci 0000:80:02.0: PME# supported from D0 D3hot D3cold
[ 0.986829] pci 0000:80:02.0: System wakeup disabled by ACPI
[ 0.986869] pci 0000:80:03.0: [8086:0e08] type 01 class 0x060400
[ 0.986952] pci 0000:80:03.0: PME# supported from D0 D3hot D3cold
[ 0.986987] pci 0000:80:03.0: System wakeup disabled by ACPI
[ 0.987025] pci 0000:80:04.0: [8086:0e20] type 00 class 0x088000
[ 0.987042] pci 0000:80:04.0: reg 0x10: [mem 0xfbf1c000-0xfbf1ffff 64bit]
[ 0.987161] pci 0000:80:04.1: [8086:0e21] type 00 class 0x088000
[ 0.987177] pci 0000:80:04.1: reg 0x10: [mem 0xfbf18000-0xfbf1bfff 64bit]
[ 0.987293] pci 0000:80:04.2: [8086:0e22] type 00 class 0x088000
[ 0.987308] pci 0000:80:04.2: reg 0x10: [mem 0xfbf14000-0xfbf17fff 64bit]
[ 0.987428] pci 0000:80:04.3: [8086:0e23] type 00 class 0x088000
[ 0.987443] pci 0000:80:04.3: reg 0x10: [mem 0xfbf10000-0xfbf13fff 64bit]
[ 0.987565] pci 0000:80:04.4: [8086:0e24] type 00 class 0x088000
[ 0.987581] pci 0000:80:04.4: reg 0x10: [mem 0xfbf0c000-0xfbf0ffff 64bit]
[ 0.987704] pci 0000:80:04.5: [8086:0e25] type 00 class 0x088000
[ 0.987719] pci 0000:80:04.5: reg 0x10: [mem 0xfbf08000-0xfbf0bfff 64bit]
[ 0.987842] pci 0000:80:04.6: [8086:0e26] type 00 class 0x088000
[ 0.987857] pci 0000:80:04.6: reg 0x10: [mem 0xfbf04000-0xfbf07fff 64bit]
[ 0.987973] pci 0000:80:04.7: [8086:0e27] type 00 class 0x088000
[ 0.987989] pci 0000:80:04.7: reg 0x10: [mem 0xfbf00000-0xfbf03fff 64bit]
[ 0.988108] pci 0000:80:05.0: [8086:0e28] type 00 class 0x088000
[ 0.988213] pci 0000:80:05.2: [8086:0e2a] type 00 class 0x088000
[ 0.988321] pci 0000:80:05.4: [8086:0e2c] type 00 class 0x080020
[ 0.988332] pci 0000:80:05.4: reg 0x10: [mem 0xfbf20000-0xfbf20fff]
[ 0.988504] pci 0000:80:01.0: PCI bridge to [bus 81]
[ 0.988577] pci 0000:82:00.0: [8086:1528] type 00 class 0x020000
[ 0.988592] pci 0000:82:00.0: reg 0x10: [mem 0xfb600000-0xfb7fffff 64bit pref]
[ 0.988614] pci 0000:82:00.0: reg 0x20: [mem 0xfb804000-0xfb807fff 64bit pref]
[ 0.988624] pci 0000:82:00.0: reg 0x30: [mem 0xfba80000-0xfbafffff pref]
[ 0.988670] pci 0000:82:00.0: PME# supported from D0 D3hot
[ 0.988700] pci 0000:82:00.0: reg 0x184: [mem 0xfbe00000-0xfbe03fff 64bit]
[ 0.988715] pci 0000:82:00.0: reg 0x190: [mem 0xfbd00000-0xfbd03fff 64bit]
[ 0.988767] pci 0000:82:00.1: [8086:1528] type 00 class 0x020000
[ 0.988781] pci 0000:82:00.1: reg 0x10: [mem 0xfb400000-0xfb5fffff 64bit pref]
[ 0.988802] pci 0000:82:00.1: reg 0x20: [mem 0xfb800000-0xfb803fff 64bit pref]
[ 0.988810] pci 0000:82:00.1: reg 0x30: [mem 0xfba00000-0xfba7ffff pref]
[ 0.988854] pci 0000:82:00.1: PME# supported from D0 D3hot
[ 0.988880] pci 0000:82:00.1: reg 0x184: [mem 0xfbc00000-0xfbc03fff 64bit]
[ 0.988893] pci 0000:82:00.1: reg 0x190: [mem 0xfbb00000-0xfbb03fff 64bit]
[ 0.995557] pci 0000:80:02.0: PCI bridge to [bus 82-83]
[ 0.995563] pci 0000:80:02.0: bridge window [mem 0xfba00000-0xfbefffff]
[ 0.995569] pci 0000:80:02.0: bridge window [mem 0xfb400000-0xfb8fffff 64bit pref]
[ 0.995617] pci 0000:80:03.0: PCI bridge to [bus 84]
[ 0.995642] pci_bus 0000:80: on NUMA node 1
[ 0.995694] ACPI: PCI Root Bridge [UNC1] (domain 0000 [bus ff])
[ 0.995698] acpi PNP0A03:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.995717] acpi PNP0A03:01: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 0.995720] acpi PNP0A03:01: FADT indicates ASPM is unsupported, using BIOS configuration
[ 0.995778] PCI host bridge to bus 0000:ff
[ 0.995780] pci_bus 0000:ff: root bus resource [bus ff]
[ 0.995789] pci 0000:ff:08.0: [8086:0e80] type 00 class 0x088000
[ 0.995853] pci 0000:ff:09.0: [8086:0e90] type 00 class 0x088000
[ 0.995913] pci 0000:ff:0a.0: [8086:0ec0] type 00 class 0x088000
[ 0.995964] pci 0000:ff:0a.1: [8086:0ec1] type 00 class 0x088000
[ 0.996015] pci 0000:ff:0a.2: [8086:0ec2] type 00 class 0x088000
[ 0.996063] pci 0000:ff:0a.3: [8086:0ec3] type 00 class 0x088000
[ 0.996120] pci 0000:ff:0b.0: [8086:0e1e] type 00 class 0x088000
[ 0.996169] pci 0000:ff:0b.3: [8086:0e1f] type 00 class 0x088000
[ 0.996217] pci 0000:ff:0c.0: [8086:0ee0] type 00 class 0x088000
[ 0.996264] pci 0000:ff:0c.1: [8086:0ee2] type 00 class 0x088000
[ 0.996311] pci 0000:ff:0c.2: [8086:0ee4] type 00 class 0x088000
[ 0.996361] pci 0000:ff:0d.0: [8086:0ee1] type 00 class 0x088000
[ 0.996409] pci 0000:ff:0d.1: [8086:0ee3] type 00 class 0x088000
[ 0.996456] pci 0000:ff:0d.2: [8086:0ee5] type 00 class 0x088000
[ 0.996505] pci 0000:ff:0e.0: [8086:0ea0] type 00 class 0x088000
[ 0.996557] pci 0000:ff:0e.1: [8086:0e30] type 00 class 0x110100
[ 0.996615] pci 0000:ff:0f.0: [8086:0ea8] type 00 class 0x088000
[ 0.996678] pci 0000:ff:0f.1: [8086:0e71] type 00 class 0x088000
[ 0.996743] pci 0000:ff:0f.2: [8086:0eaa] type 00 class 0x088000
[ 0.996805] pci 0000:ff:0f.3: [8086:0eab] type 00 class 0x088000
[ 0.996870] pci 0000:ff:0f.4: [8086:0eac] type 00 class 0x088000
[ 0.996934] pci 0000:ff:0f.5: [8086:0ead] type 00 class 0x088000
[ 0.997002] pci 0000:ff:10.0: [8086:0eb0] type 00 class 0x088000
[ 0.997070] pci 0000:ff:10.1: [8086:0eb1] type 00 class 0x088000
[ 0.997132] pci 0000:ff:10.2: [8086:0eb2] type 00 class 0x088000
[ 0.997196] pci 0000:ff:10.3: [8086:0eb3] type 00 class 0x088000
[ 0.997261] pci 0000:ff:10.4: [8086:0eb4] type 00 class 0x088000
[ 0.997328] pci 0000:ff:10.5: [8086:0eb5] type 00 class 0x088000
[ 0.997395] pci 0000:ff:10.6: [8086:0eb6] type 00 class 0x088000
[ 0.997467] pci 0000:ff:10.7: [8086:0eb7] type 00 class 0x088000
[ 0.997538] pci 0000:ff:13.0: [8086:0e1d] type 00 class 0x088000
[ 0.997585] pci 0000:ff:13.1: [8086:0e34] type 00 class 0x110100
[ 0.997634] pci 0000:ff:13.4: [8086:0e81] type 00 class 0x088000
[ 0.997682] pci 0000:ff:13.5: [8086:0e36] type 00 class 0x110100
[ 0.997734] pci 0000:ff:16.0: [8086:0ec8] type 00 class 0x088000
[ 0.997781] pci 0000:ff:16.1: [8086:0ec9] type 00 class 0x088000
[ 0.997830] pci 0000:ff:16.2: [8086:0eca] type 00 class 0x088000
[ 0.997887] pci_bus 0000:ff: on NUMA node 1
[ 0.997950] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 0.997991] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[ 0.998029] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 10 11 12 14 15)
[ 0.998067] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
[ 0.998104] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0
[ 0.998142] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0
[ 0.998180] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0
[ 0.998218] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *7 10 11 12 14 15)
[ 1.000070] ACPI: Enabled 1 GPEs in block 00 to 3F
[ 1.000233] ACPI Error: [\_SB_.PRAD] Namespace lookup failure, AE_NOT_FOUND (20140424/psargs-359)
[ 1.000241] ACPI Error: Method parse/execution failed [\_GPE._L24] (Node ffff881fff830438), AE_NOT_FOUND (20140424/psparse-536)
[ 1.000248] ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L24] (20140424/evgpe-580)
[ 1.000260] vgaarb: setting as boot device: PCI:0000:08:01.0
[ 1.000267] vgaarb: device added: PCI:0000:08:01.0,decodes=io+mem,owns=io+mem,locks=none
[ 1.000304] vgaarb: loaded
[ 1.000306] vgaarb: bridge control possible 0000:08:01.0
[ 1.000634] SCSI subsystem initialized
[ 1.000743] libata version 3.00 loaded.
[ 1.000778] ACPI: bus type USB registered
[ 1.000805] usbcore: registered new interface driver usbfs
[ 1.000815] usbcore: registered new interface driver hub
[ 1.000857] usbcore: registered new device driver usb
[ 1.001254] PCI: Using ACPI for IRQ routing
[ 1.005679] PCI: pci_cache_line_size set to 64 bytes
[ 1.005892] e820: reserve RAM buffer [mem 0x0009ac00-0x0009ffff]
[ 1.005894] e820: reserve RAM buffer [mem 0x7de47000-0x7fffffff]
[ 1.006055] NetLabel: Initializing
[ 1.006057] NetLabel: domain hash size = 128
[ 1.006059] NetLabel: protocols = UNLABELED CIPSOv4
[ 1.006079] NetLabel: unlabeled traffic allowed by default
[ 1.006152] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[ 1.006159] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[ 1.008255] Switched to clocksource hpet
[ 1.016265] AppArmor: AppArmor Filesystem Enabled
[ 1.016293] pnp: PnP ACPI init
[ 1.016304] ACPI: bus type PNP registered
[ 1.016420] system 00:00: [mem 0xfc000000-0xfcffffff] has been reserved
[ 1.016423] system 00:00: [mem 0xfd000000-0xfdffffff] has been reserved
[ 1.016425] system 00:00: [mem 0xfe000000-0xfeafffff] has been reserved
[ 1.016428] system 00:00: [mem 0xfeb00000-0xfebfffff] has been reserved
[ 1.016432] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 1.016527] system 00:01: [mem 0xdfffc000-0xdfffdfff] could not be reserved
[ 1.016531] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.016579] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 1.016657] system 00:03: [io 0x04d0-0x04d1] has been reserved
[ 1.016660] system 00:03: [mem 0x00000400-0x000004ff] could not be reserved
[ 1.016663] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.016737] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.016847] system 00:05: [io 0x0b00-0x0b7f] has been reserved
[ 1.016850] system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.016996] pnp 00:06: [dma 0 disabled]
[ 1.017043] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
[ 1.017171] pnp 00:07: [dma 0 disabled]
[ 1.017214] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active)
[ 1.017296] pnp 00:08: Plug and Play ACPI device, IDs IPI0001 (active)
[ 1.017440] system 00:09: [io 0x0400-0x0453] could not be reserved
[ 1.017443] system 00:09: [io 0x0458-0x047f] has been reserved
[ 1.017445] system 00:09: [io 0x1180-0x119f] has been reserved
[ 1.017447] system 00:09: [io 0x0500-0x057f] has been reserved
[ 1.017450] system 00:09: [mem 0xfed1c000-0xfed1ffff] has been reserved
[ 1.017452] system 00:09: [mem 0xfec00000-0xfecfffff] could not be reserved
[ 1.017455] system 00:09: [mem 0xff000000-0xffffffff] has been reserved
[ 1.017458] system 00:09: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 1.017537] system 00:0a: [io 0x0454-0x0457] has been reserved
[ 1.017540] system 00:0a: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active)
[ 1.017685] system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 1.017765] system 00:0c: [mem 0xfbffe000-0xfbffffff] could not be reserved
[ 1.017768] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 1.017908] system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved
[ 1.017911] system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 1.018103] pnp: PnP ACPI: found 14 devices
[ 1.018105] ACPI: bus type PNP unregistered
[ 1.024678] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 1.024690] pci 0000:00:01.1: PCI bridge to [bus 02]
[ 1.024701] pci 0000:00:02.0: PCI bridge to [bus 03]
[ 1.024704] pci 0000:00:02.0: bridge window [io 0x8000-0x8fff]
[ 1.024709] pci 0000:00:02.0: bridge window [mem 0xdf900000-0xdfafffff]
[ 1.024716] pci 0000:00:03.0: PCI bridge to [bus 04]
[ 1.024727] pci 0000:00:11.0: PCI bridge to [bus 05]
[ 1.024730] pci 0000:00:11.0: bridge window [io 0x7000-0x7fff]
[ 1.024739] pci 0000:00:11.0: bridge window [mem 0xde000000-0xde4fffff 64bit pref]
[ 1.024747] pci 0000:00:1c.0: PCI bridge to [bus 06-07]
[ 1.024750] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff]
[ 1.024756] pci 0000:00:1c.0: bridge window [mem 0xdfb00000-0xdfbfffff]
[ 1.024760] pci 0000:00:1c.0: bridge window [mem 0xde600000-0xde6fffff 64bit pref]
[ 1.024767] pci 0000:00:1e.0: PCI bridge to [bus 08]
[ 1.024772] pci 0000:00:1e.0: bridge window [mem 0xdf000000-0xdf8fffff]
[ 1.024776] pci 0000:00:1e.0: bridge window [mem 0xdd000000-0xddffffff 64bit pref]
[ 1.024784] pci_bus 0000:00: resource 4 [io 0x0000-0x03af]
[ 1.024785] pci_bus 0000:00: resource 5 [io 0x03e0-0x0cf7]
[ 1.024786] pci_bus 0000:00: resource 6 [io 0x03b0-0x03df]
[ 1.024788] pci_bus 0000:00: resource 7 [io 0x0d00-0x9fff]
[ 1.024789] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff]
[ 1.024790] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff]
[ 1.024792] pci_bus 0000:00: resource 10 [mem 0xfed08000-0xfed08fff]
[ 1.024793] pci_bus 0000:00: resource 11 [mem 0xfed0e000-0xfed0ffff]
[ 1.024795] pci_bus 0000:00: resource 12 [mem 0x80000000-0xdfffffff]
[ 1.024797] pci_bus 0000:03: resource 0 [io 0x8000-0x8fff]
[ 1.024798] pci_bus 0000:03: resource 1 [mem 0xdf900000-0xdfafffff]
[ 1.024800] pci_bus 0000:05: resource 0 [io 0x7000-0x7fff]
[ 1.024801] pci_bus 0000:05: resource 2 [mem 0xde000000-0xde4fffff 64bit pref]
[ 1.024803] pci_bus 0000:06: resource 0 [io 0x6000-0x6fff]
[ 1.024804] pci_bus 0000:06: resource 1 [mem 0xdfb00000-0xdfbfffff]
[ 1.024806] pci_bus 0000:06: resource 2 [mem 0xde600000-0xde6fffff 64bit pref]
[ 1.024808] pci_bus 0000:08: resource 1 [mem 0xdf000000-0xdf8fffff]
[ 1.024809] pci_bus 0000:08: resource 2 [mem 0xdd000000-0xddffffff 64bit pref]
[ 1.024810] pci_bus 0000:08: resource 4 [io 0x0000-0x03af]
[ 1.024812] pci_bus 0000:08: resource 5 [io 0x03e0-0x0cf7]
[ 1.024813] pci_bus 0000:08: resource 6 [io 0x03b0-0x03df]
[ 1.024814] pci_bus 0000:08: resource 7 [io 0x0d00-0x9fff]
[ 1.024816] pci_bus 0000:08: resource 8 [mem 0x000a0000-0x000bffff]
[ 1.024817] pci_bus 0000:08: resource 9 [mem 0x000c0000-0x000dffff]
[ 1.024819] pci_bus 0000:08: resource 10 [mem 0xfed08000-0xfed08fff]
[ 1.024820] pci_bus 0000:08: resource 11 [mem 0xfed0e000-0xfed0ffff]
[ 1.024821] pci_bus 0000:08: resource 12 [mem 0x80000000-0xdfffffff]
[ 1.024844] pci 0000:80:01.0: PCI bridge to [bus 81]
[ 1.024854] pci 0000:80:02.0: PCI bridge to [bus 82-83]
[ 1.024858] pci 0000:80:02.0: bridge window [mem 0xfba00000-0xfbefffff]
[ 1.024862] pci 0000:80:02.0: bridge window [mem 0xfb400000-0xfb8fffff 64bit pref]
[ 1.024868] pci 0000:80:03.0: PCI bridge to [bus 84]
[ 1.024877] pci_bus 0000:80: resource 4 [io 0xa000-0xffff]
[ 1.024879] pci_bus 0000:80: resource 5 [mem 0xe0000000-0xfbffffff]
[ 1.024880] pci_bus 0000:82: resource 1 [mem 0xfba00000-0xfbefffff]
[ 1.024882] pci_bus 0000:82: resource 2 [mem 0xfb400000-0xfb8fffff 64bit pref]
[ 1.024941] NET: Registered protocol family 2
[ 1.025534] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
[ 1.026286] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 1.026450] TCP: Hash tables configured (established 524288 bind 65536)
[ 1.026490] TCP: reno registered
[ 1.026618] UDP hash table entries: 65536 (order: 9, 2097152 bytes)
[ 1.027069] UDP-Lite hash table entries: 65536 (order: 9, 2097152 bytes)
[ 1.027530] NET: Registered protocol family 1
[ 1.068392] pci 0000:08:01.0: Video device with shadowed ROM
[ 1.068524] PCI: CLS 64 bytes, default 64
[ 1.068613] Trying to unpack rootfs image as initramfs...
[ 1.377651] Freeing initrd memory: 20128K (ffff8800358a0000 - ffff880036c48000)
[ 1.377817] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 1.377821] software IO TLB [mem 0x79e47000-0x7de47000] (64MB) mapped at [ffff880079e47000-ffff88007de46fff]
[ 1.379616] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer
[ 1.379724] microcode: CPU0 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379731] microcode: CPU1 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379738] microcode: CPU2 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379747] microcode: CPU3 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379757] microcode: CPU4 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379766] microcode: CPU5 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379788] microcode: CPU6 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379807] microcode: CPU7 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379832] microcode: CPU8 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379842] microcode: CPU9 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379852] microcode: CPU10 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379862] microcode: CPU11 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379871] microcode: CPU12 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379879] microcode: CPU13 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379895] microcode: CPU14 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379902] microcode: CPU15 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379909] microcode: CPU16 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379921] microcode: CPU17 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379932] microcode: CPU18 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379946] microcode: CPU19 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379971] microcode: CPU20 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379979] microcode: CPU21 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379988] microcode: CPU22 sig=0x306e4, pf=0x1, revision=0x427
[ 1.379996] microcode: CPU23 sig=0x306e4, pf=0x1, revision=0x427
[ 1.380130] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 1.380174] Scanning for low memory corruption every 60 seconds
[ 1.380839] futex hash table entries: 8192 (order: 7, 524288 bytes)
[ 1.380934] Initialise system trusted keyring
[ 1.380976] audit: initializing netlink subsys (disabled)
[ 1.380999] audit: type=2000 audit(1434039124.164:1): initialized
[ 1.381823] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 1.383176] zpool: loaded
[ 1.383179] zbud: loaded
[ 1.383364] VFS: Disk quotas dquot_6.5.2
[ 1.383412] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 1.384028] fuse init (API version 7.23)
[ 1.384122] msgmni has been set to 32768
[ 1.384196] Key type big_key registered
[ 1.384975] Key type asymmetric registered
[ 1.384994] Asymmetric key parser 'x509' registered
[ 1.385046] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 1.385161] io scheduler noop registered
[ 1.385164] io scheduler deadline registered (default)
[ 1.385218] io scheduler cfq registered
[ 1.386650] ioapic: probe of 0000:00:05.4 failed with error -22
[ 1.386683] ioapic: probe of 0000:80:05.4 failed with error -22
[ 1.386701] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 1.386717] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 1.386800] vesafb: mode is 640x480x32, linelength=2560, pages=0
[ 1.386802] vesafb: scrolling: redraw
[ 1.386804] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 1.416612] vesafb: framebuffer at 0xdd000000, mapped to 0xffffc90029400000, using 1216k, total 1216k
[ 1.430291] Console: switching to colour frame buffer device 80x30
[ 1.444553] fb0: VESA VGA frame buffer device
[ 1.444864] intel_idle: MWAIT substates: 0x1120
[ 1.444865] intel_idle: v0.4 model 0x3E
[ 1.444866] intel_idle: lapic_timer_reliable_states 0xffffffff
[ 1.445778] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[ 1.446319] ACPI: Power Button [PWRB]
[ 1.446594] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 1.464339] ACPI: Power Button [PWRF]
[ 1.496954] ERST: Error Record Serialization Table (ERST) support is initialized.
[ 1.518325] pstore: Registered erst as persistent store backend
[ 1.530273] GHES: APEI firmware first mode is enabled by WHEA _OSC.
[ 1.541708] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 1.573890] 00:06: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 1.615992] 00:07: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 1.638928] Linux agpgart interface v0.103
[ 1.651617] brd: module loaded
[ 1.663739] loop: module loaded
[ 1.674957] libphy: Fixed MDIO Bus: probed
[ 1.686965] tun: Universal TUN/TAP device driver, 1.6
[ 1.699612] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 1.712113] PPP generic driver version 2.4.2
[ 1.724444] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.736657] ehci-pci: EHCI PCI platform driver
[ 1.749744] ehci-pci 0000:00:1a.0: EHCI Host Controller
[ 1.760271] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
[ 1.780144] ehci-pci 0000:00:1a.0: debug port 2
[ 1.793922] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported
[ 1.793951] ehci-pci 0000:00:1a.0: irq 16, io mem 0xdfc23000
[ 1.812615] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[ 1.823305] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.834037] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.855377] usb usb1: Product: EHCI Host Controller
[ 1.866125] usb usb1: Manufacturer: Linux 3.16.0-38-generic ehci_hcd
[ 1.877826] usb usb1: SerialNumber: 0000:00:1a.0
[ 1.889559] hub 1-0:1.0: USB hub found
[ 1.900293] hub 1-0:1.0: 2 ports detected
[ 1.911742] ehci-pci 0000:00:1d.0: EHCI Host Controller
[ 1.922548] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
[ 1.944047] ehci-pci 0000:00:1d.0: debug port 2
[ 1.958110] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported
[ 1.958126] ehci-pci 0000:00:1d.0: irq 23, io mem 0xdfc22000
[ 1.976683] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[ 1.986038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.996336] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.017433] usb usb2: Product: EHCI Host Controller
[ 2.029234] usb usb2: Manufacturer: Linux 3.16.0-38-generic ehci_hcd
[ 2.040602] usb usb2: SerialNumber: 0000:00:1d.0
[ 2.050886] hub 2-0:1.0: USB hub found
[ 2.060790] hub 2-0:1.0: 2 ports detected
[ 2.070183] ehci-platform: EHCI generic platform driver
[ 2.080073] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.089531] ohci-pci: OHCI PCI platform driver
[ 2.099429] ohci-platform: OHCI generic platform driver
[ 2.108740] uhci_hcd: USB Universal Host Controller Interface driver
[ 2.118246] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 2.228782] usb 1-1: new high-speed USB device number 2 using ehci-pci
[ 2.433297] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
[ 2.444248] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2.455242] hub 1-1:1.0: USB hub found
[ 2.465086] hub 1-1:1.0: 6 ports detected
[ 2.584931] usb 2-1: new high-speed USB device number 2 using ehci-pci
[ 2.833434] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
[ 2.842012] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2.850897] hub 2-1:1.0: USB hub found
[ 2.860866] hub 2-1:1.0: 8 ports detected
[ 2.941208] usb 1-1.3: new full-speed USB device number 3 using ehci-pci
[ 3.184921] i8042: No controller found
[ 3.193682] tsc: Refined TSC clocksource calibration: 2599.999 MHz
[ 3.195281] mousedev: PS/2 mouse device common for all mice
[ 3.198538] rtc_cmos 00:02: RTC can wake from S4
[ 3.199804] rtc (null): invalid alarm value: 2015-6-11 16:12:65
[ 3.200145] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 3.200432] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[ 3.200535] device-mapper: uevent: version 1.0.3
[ 3.200923] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[ 3.200939] Intel P-state driver initializing.
[ 3.201003] Intel pstate controlling: cpu 0
[ 3.201072] Intel pstate controlling: cpu 1
[ 3.201291] Intel pstate controlling: cpu 2
[ 3.201334] Intel pstate controlling: cpu 3
[ 3.201477] Intel pstate controlling: cpu 4
[ 3.201598] Intel pstate controlling: cpu 5
[ 3.201703] Intel pstate controlling: cpu 6
[ 3.201817] Intel pstate controlling: cpu 7
[ 3.217260] usb 1-1.3: New USB device found, idVendor=0557, idProduct=2221
[ 3.217261] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.217262] usb 1-1.3: Product: Hermon USB hidmouse Device
[ 3.217263] usb 1-1.3: Manufacturer: Winbond Electronics Corp
[ 3.430623] Intel pstate controlling: cpu 8
[ 3.438953] Intel pstate controlling: cpu 9
[ 3.447414] Intel pstate controlling: cpu 10
[ 3.455211] Intel pstate controlling: cpu 11
[ 3.463234] Intel pstate controlling: cpu 12
[ 3.470385] Intel pstate controlling: cpu 13
[ 3.478440] Intel pstate controlling: cpu 14
[ 3.485743] Intel pstate controlling: cpu 15
[ 3.492988] Intel pstate controlling: cpu 16
[ 3.499734] Intel pstate controlling: cpu 17
[ 3.505937] Intel pstate controlling: cpu 18
[ 3.512278] Intel pstate controlling: cpu 19
[ 3.517734] Intel pstate controlling: cpu 20
[ 3.523041] Intel pstate controlling: cpu 21
[ 3.528088] Intel pstate controlling: cpu 22
[ 3.532792] Intel pstate controlling: cpu 23
[ 3.536723] Consider also installing thermald for improved thermal control.
[ 3.541595] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.547016] TCP: cubic registered
[ 3.551697] NET: Registered protocol family 10
[ 3.557465] NET: Registered protocol family 17
[ 3.562983] Key type dns_resolver registered
[ 3.569787] Loading compiled-in X.509 certificates
[ 3.577133] Loaded X.509 cert 'Magrathea: Glacier signing key: c284edaccf0b473652c34d23bec356944236e63b'
[ 3.590439] registered taskstats version 1
[ 3.599699] Key type trusted registered
[ 3.609217] Key type encrypted registered
[ 3.614823] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.620112] ima: No TPM chip found, activating TPM-bypass!
[ 3.625927] evm: HMAC attrs: 0x1
[ 3.632880] Magic number: 3:690:236
[ 3.638579] memory memory114: hash matches
[ 3.645050] rtc_cmos 00:02: setting system clock to 2015-06-11 16:12:07 UTC (1434039127)
[ 3.658482] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 3.666387] EDD information not available.
[ 3.674578] PM: Hibernation image not present or could not be loaded.
[ 3.675858] Freeing unused kernel memory: 1352K (ffffffff81d1c000 - ffffffff81e6e000)
[ 3.693755] Write protecting the kernel read-only data: 12288k
[ 3.704850] Freeing unused kernel memory: 556K (ffff880001775000 - ffff880001800000)
[ 3.726680] Freeing unused kernel memory: 500K (ffff880001b83000 - ffff880001c00000)
[ 3.769878] systemd-udevd[267]: starting version 204
[ 3.816623] pps_core: LinuxPPS API ver. 1 registered
[ 3.837702] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 3.871410] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.887920] PTP clock support registered
[ 3.901111] ahci 0000:00:1f.2: version 3.0
[ 3.901219] ahci 0000:00:1f.2: irq 90 for MSI/MSI-X
[ 3.901888] mpt2sas version 16.100.00.00 loaded
[ 3.903484] usbcore: registered new interface driver usbhid
[ 3.903484] usbhid: USB HID core driver
[ 3.917938] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[ 3.917940] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ems apst
[ 3.959046] scsi0 : ahci
[ 3.960479] scsi1 : ahci
[ 3.962100] scsi2 : ahci
[ 3.963848] scsi3 : ahci
[ 3.965287] scsi4 : ahci
[ 3.966748] scsi5 : ahci
[ 3.966810] ata1: SATA max UDMA/133 abar m2048@0xdfc21000 port 0xdfc21100 irq 90
[ 3.966838] ata2: SATA max UDMA/133 abar m2048@0xdfc21000 port 0xdfc21180 irq 90
[ 3.966872] ata3: SATA max UDMA/133 abar m2048@0xdfc21000 port 0xdfc21200 irq 90
[ 3.966907] ata4: SATA max UDMA/133 abar m2048@0xdfc21000 port 0xdfc21280 irq 90
[ 3.966941] ata5: SATA max UDMA/133 abar m2048@0xdfc21000 port 0xdfc21300 irq 90
[ 3.966964] ata6: SATA max UDMA/133 abar m2048@0xdfc21000 port 0xdfc21380 irq 90
[ 4.168810] dca service started, version 1.12.1
[ 4.170208] scsi6 : Fusion MPT SAS Host
[ 4.172028] mpt2sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (264123244 kB)
[ 4.172124] mpt2sas 0000:03:00.0: irq 91 for MSI/MSI-X
[ 4.172147] mpt2sas 0000:03:00.0: irq 92 for MSI/MSI-X
[ 4.172179] mpt2sas 0000:03:00.0: irq 93 for MSI/MSI-X
[ 4.172184] mpt2sas 0000:03:00.0: irq 94 for MSI/MSI-X
[ 4.172188] mpt2sas 0000:03:00.0: irq 95 for MSI/MSI-X
[ 4.172192] mpt2sas 0000:03:00.0: irq 96 for MSI/MSI-X
[ 4.172213] mpt2sas 0000:03:00.0: irq 97 for MSI/MSI-X
[ 4.172219] mpt2sas 0000:03:00.0: irq 98 for MSI/MSI-X
[ 4.172235] mpt2sas 0000:03:00.0: irq 99 for MSI/MSI-X
[ 4.172239] mpt2sas 0000:03:00.0: irq 100 for MSI/MSI-X
[ 4.172250] mpt2sas 0000:03:00.0: irq 101 for MSI/MSI-X
[ 4.172269] mpt2sas 0000:03:00.0: irq 102 for MSI/MSI-X
[ 4.172274] mpt2sas 0000:03:00.0: irq 103 for MSI/MSI-X
[ 4.172300] mpt2sas 0000:03:00.0: irq 104 for MSI/MSI-X
[ 4.172308] mpt2sas 0000:03:00.0: irq 105 for MSI/MSI-X
[ 4.172317] mpt2sas 0000:03:00.0: irq 106 for MSI/MSI-X
[ 4.172598] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 91
[ 4.172599] mpt2sas0-msix1: PCI-MSI-X enabled: IRQ 92
[ 4.172599] mpt2sas0-msix2: PCI-MSI-X enabled: IRQ 93
[ 4.172600] mpt2sas0-msix3: PCI-MSI-X enabled: IRQ 94
[ 4.172600] mpt2sas0-msix4: PCI-MSI-X enabled: IRQ 95
[ 4.172600] mpt2sas0-msix5: PCI-MSI-X enabled: IRQ 96
[ 4.172601] mpt2sas0-msix6: PCI-MSI-X enabled: IRQ 97
[ 4.172601] mpt2sas0-msix7: PCI-MSI-X enabled: IRQ 98
[ 4.172601] mpt2sas0-msix8: PCI-MSI-X enabled: IRQ 99
[ 4.172602] mpt2sas0-msix9: PCI-MSI-X enabled: IRQ 100
[ 4.172602] mpt2sas0-msix10: PCI-MSI-X enabled: IRQ 101
[ 4.172603] mpt2sas0-msix11: PCI-MSI-X enabled: IRQ 102
[ 4.172603] mpt2sas0-msix12: PCI-MSI-X enabled: IRQ 103
[ 4.172603] mpt2sas0-msix13: PCI-MSI-X enabled: IRQ 104
[ 4.172604] mpt2sas0-msix14: PCI-MSI-X enabled: IRQ 105
[ 4.172604] mpt2sas0-msix15: PCI-MSI-X enabled: IRQ 106
[ 4.172605] mpt2sas0: iomem(0x00000000dfa40000), mapped(0xffffc900293e0000), size(65536)
[ 4.172606] mpt2sas0: ioport(0x0000000000008000), size(256)
[ 4.379183] input: Winbond Electronics Corp Hermon USB hidmouse Device as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:0557:2221.0001/input/input2
[ 4.382192] ata4: SATA link down (SStatus 0 SControl 300)
[ 4.382642] ata1: SATA link down (SStatus 0 SControl 300)
[ 4.383035] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4.383352] ata6: SATA link down (SStatus 0 SControl 300)
[ 4.383811] ata3: SATA link down (SStatus 0 SControl 300)
[ 4.384121] ata5: SATA link down (SStatus 0 SControl 300)
[ 4.384886] ata2.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 4.384887] ata2.00: ATA-9: Samsung SSD 840 PRO Series, DXM06B0Q, max UDMA/133
[ 4.384888] ata2.00: 250069680 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 4.386052] ata2.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 4.386054] ata2.00: configured for UDMA/133
[ 4.394357] scsi 1:0:0:0: Direct-Access ATA Samsung SSD 840 6B0Q PQ: 0 ANSI: 5
[ 4.395829] sd 1:0:0:0: Attached scsi generic sg0 type 0
[ 4.396926] sd 1:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[ 4.398226] sd 1:0:0:0: [sda] Write Protect is off
[ 4.398228] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 4.398237] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.399923] sda: sda1 sda2 < sda5 >
[ 4.400643] sd 1:0:0:0: [sda] Attached SCSI disk
[ 4.548261] Switched to clocksource tsc
[ 4.548354] hid-generic 0003:0557:2221.0001: input,hidraw0: USB HID v1.00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-0000:00:1a.0-1.3/input0
[ 4.548502] input: Winbond Electronics Corp Hermon USB hidmouse Device as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:0557:2221.0002/input/input3
[ 4.548564] hid-generic 0003:0557:2221.0002: input,hidraw1: USB HID v1.00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-0000:00:1a.0-1.3/input1
[ 4.557495] random: lvm urandom read with 21 bits of entropy available
[ 4.674349] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[ 4.684760] isci 0000:05:00.0: driver configured for rev: 6 silicon
[ 4.695569] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.19.1-k
[ 4.719107] ixgbe: Copyright (c) 1999-2014 Intel Corporation.
[ 4.732903] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.13-k
[ 4.758164] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 4.760349] isci 0000:05:00.0: OEM parameter table found in OROM
[ 4.760351] isci 0000:05:00.0: [0]: invalid oem parameters detected, falling back to firmware
[ 4.760377] isci 0000:05:00.0: OEM SAS parameters (version: 1.3) loaded (firmware)
[ 4.760751] isci 0000:05:00.0: SCU controller 0: phy 3-0 cables: {short, short, short, short}
[ 4.764182] scsi7 : isci
[ 4.764665] isci 0000:05:00.0: irq 107 for MSI/MSI-X
[ 4.764683] isci 0000:05:00.0: irq 108 for MSI/MSI-X
[ 4.801788] mpt2sas0: sending message unit reset !!
[ 4.809757] mpt2sas0: message unit reset: SUCCESS
[ 4.899616] igb 0000:06:00.0: irq 109 for MSI/MSI-X
[ 4.899623] igb 0000:06:00.0: irq 110 for MSI/MSI-X
[ 4.899627] igb 0000:06:00.0: irq 111 for MSI/MSI-X
[ 4.899635] igb 0000:06:00.0: irq 112 for MSI/MSI-X
[ 4.899639] igb 0000:06:00.0: irq 113 for MSI/MSI-X
[ 4.899644] igb 0000:06:00.0: irq 114 for MSI/MSI-X
[ 4.899649] igb 0000:06:00.0: irq 115 for MSI/MSI-X
[ 4.899653] igb 0000:06:00.0: irq 116 for MSI/MSI-X
[ 4.899658] igb 0000:06:00.0: irq 117 for MSI/MSI-X
[ 4.931972] igb 0000:06:00.0: irq 109 for MSI/MSI-X
[ 4.931976] igb 0000:06:00.0: irq 110 for MSI/MSI-X
[ 4.931980] igb 0000:06:00.0: irq 111 for MSI/MSI-X
[ 4.931985] igb 0000:06:00.0: irq 112 for MSI/MSI-X
[ 4.931989] igb 0000:06:00.0: irq 113 for MSI/MSI-X
[ 4.931993] igb 0000:06:00.0: irq 114 for MSI/MSI-X
[ 4.931998] igb 0000:06:00.0: irq 115 for MSI/MSI-X
[ 4.932002] igb 0000:06:00.0: irq 116 for MSI/MSI-X
[ 4.932006] igb 0000:06:00.0: irq 117 for MSI/MSI-X
[ 4.965802] raid6: sse2x1 7923 MB/s
[ 4.998009] mpt2sas0: Allocated physical memory: size(18614 kB)
[ 5.012133] mpt2sas0: Current Controller Queue Depth(9979), Max Controller Queue Depth(10240)
[ 5.035432] mpt2sas0: Scatter Gather Elements per IO(128)
[ 5.045829] raid6: sse2x2 9685 MB/s
[ 5.059895] igb 0000:06:00.0: added PHC on eth0
[ 5.071082] igb 0000:06:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 5.083562] igb 0000:06:00.0: eth0: (PCIe:5.0Gb/s:Width x4) 00:25:90:f5:6e:02
[ 5.095481] igb 0000:06:00.0: eth0: PBA No: 105900-000
[ 5.106886] igb 0000:06:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[ 5.113857] raid6: sse2x4 11410 MB/s
[ 5.113858] raid6: using algorithm sse2x4 (11410 MB/s)
[ 5.113859] raid6: using ssse3x2 recovery algorithm
[ 5.158812] ixgbe 0000:82:00.0: irq 118 for MSI/MSI-X
[ 5.158817] ixgbe 0000:82:00.0: irq 119 for MSI/MSI-X
[ 5.158824] ixgbe 0000:82:00.0: irq 120 for MSI/MSI-X
[ 5.158829] ixgbe 0000:82:00.0: irq 121 for MSI/MSI-X
[ 5.158833] ixgbe 0000:82:00.0: irq 122 for MSI/MSI-X
[ 5.158837] ixgbe 0000:82:00.0: irq 123 for MSI/MSI-X
[ 5.158842] ixgbe 0000:82:00.0: irq 124 for MSI/MSI-X
[ 5.158846] ixgbe 0000:82:00.0: irq 125 for MSI/MSI-X
[ 5.158851] ixgbe 0000:82:00.0: irq 126 for MSI/MSI-X
[ 5.158855] ixgbe 0000:82:00.0: irq 127 for MSI/MSI-X
[ 5.158860] ixgbe 0000:82:00.0: irq 128 for MSI/MSI-X
[ 5.158864] ixgbe 0000:82:00.0: irq 129 for MSI/MSI-X
[ 5.158868] ixgbe 0000:82:00.0: irq 130 for MSI/MSI-X
[ 5.158872] ixgbe 0000:82:00.0: irq 131 for MSI/MSI-X
[ 5.158876] ixgbe 0000:82:00.0: irq 132 for MSI/MSI-X
[ 5.158880] ixgbe 0000:82:00.0: irq 133 for MSI/MSI-X
[ 5.158884] ixgbe 0000:82:00.0: irq 134 for MSI/MSI-X
[ 5.158888] ixgbe 0000:82:00.0: irq 135 for MSI/MSI-X
[ 5.158894] ixgbe 0000:82:00.0: irq 136 for MSI/MSI-X
[ 5.158898] ixgbe 0000:82:00.0: irq 137 for MSI/MSI-X
[ 5.158902] ixgbe 0000:82:00.0: irq 138 for MSI/MSI-X
[ 5.158906] ixgbe 0000:82:00.0: irq 139 for MSI/MSI-X
[ 5.158910] ixgbe 0000:82:00.0: irq 140 for MSI/MSI-X
[ 5.158914] ixgbe 0000:82:00.0: irq 141 for MSI/MSI-X
[ 5.158922] ixgbe 0000:82:00.0: irq 142 for MSI/MSI-X
[ 5.158980] ixgbe 0000:82:00.0: Multiqueue Enabled: Rx Queue count = 24, Tx Queue count = 24
[ 5.190802] igb 0000:06:00.1: irq 143 for MSI/MSI-X
[ 5.190808] igb 0000:06:00.1: irq 144 for MSI/MSI-X
[ 5.190812] igb 0000:06:00.1: irq 145 for MSI/MSI-X
[ 5.190817] igb 0000:06:00.1: irq 146 for MSI/MSI-X
[ 5.190822] igb 0000:06:00.1: irq 147 for MSI/MSI-X
[ 5.190826] igb 0000:06:00.1: irq 148 for MSI/MSI-X
[ 5.190831] igb 0000:06:00.1: irq 149 for MSI/MSI-X
[ 5.190835] igb 0000:06:00.1: irq 150 for MSI/MSI-X
[ 5.190840] igb 0000:06:00.1: irq 151 for MSI/MSI-X
[ 5.191497] xor: automatically using best checksumming function:
[ 5.219078] ixgbe 0000:82:00.0: PCI Express bandwidth of 32GT/s available
[ 5.225832] igb 0000:06:00.1: irq 143 for MSI/MSI-X
[ 5.225850] igb 0000:06:00.1: irq 144 for MSI/MSI-X
[ 5.225863] igb 0000:06:00.1: irq 145 for MSI/MSI-X
[ 5.225887] igb 0000:06:00.1: irq 146 for MSI/MSI-X
[ 5.225918] igb 0000:06:00.1: irq 147 for MSI/MSI-X
[ 5.225927] igb 0000:06:00.1: irq 148 for MSI/MSI-X
[ 5.225937] igb 0000:06:00.1: irq 149 for MSI/MSI-X
[ 5.225946] igb 0000:06:00.1: irq 150 for MSI/MSI-X
[ 5.225966] igb 0000:06:00.1: irq 151 for MSI/MSI-X
[ 5.229167] ixgbe 0000:82:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
[ 5.241906] avx : 21754.000 MB/sec
[ 5.261498] Btrfs loaded
[ 5.290364] igb 0000:06:00.1: added PHC on eth1
[ 5.300840] igb 0000:06:00.1: Intel(R) Gigabit Ethernet Network Connection
[ 5.311012] igb 0000:06:00.1: eth1: (PCIe:5.0Gb/s:Width x4) 00:25:90:f5:6e:03
[ 5.321692] igb 0000:06:00.1: eth1: PBA No: 105900-000
[ 5.333224] igb 0000:06:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[ 5.355508] igb 0000:06:00.2: irq 152 for MSI/MSI-X
[ 5.355514] igb 0000:06:00.2: irq 153 for MSI/MSI-X
[ 5.355519] igb 0000:06:00.2: irq 154 for MSI/MSI-X
[ 5.355530] igb 0000:06:00.2: irq 155 for MSI/MSI-X
[ 5.355535] igb 0000:06:00.2: irq 156 for MSI/MSI-X
[ 5.355540] igb 0000:06:00.2: irq 157 for MSI/MSI-X
[ 5.355547] igb 0000:06:00.2: irq 158 for MSI/MSI-X
[ 5.355551] igb 0000:06:00.2: irq 159 for MSI/MSI-X
[ 5.355556] igb 0000:06:00.2: irq 160 for MSI/MSI-X
[ 5.385043] EXT4-fs (dm-0): INFO: recovery required on readonly filesystem
[ 5.393378] igb 0000:06:00.2: irq 152 for MSI/MSI-X
[ 5.393399] igb 0000:06:00.2: irq 153 for MSI/MSI-X
[ 5.393428] igb 0000:06:00.2: irq 154 for MSI/MSI-X
[ 5.393462] igb 0000:06:00.2: irq 155 for MSI/MSI-X
[ 5.393504] igb 0000:06:00.2: irq 156 for MSI/MSI-X
[ 5.393539] igb 0000:06:00.2: irq 157 for MSI/MSI-X
[ 5.393565] igb 0000:06:00.2: irq 158 for MSI/MSI-X
[ 5.393585] igb 0000:06:00.2: irq 159 for MSI/MSI-X
[ 5.393597] igb 0000:06:00.2: irq 160 for MSI/MSI-X
[ 5.396255] EXT4-fs (dm-0): write access will be enabled during recovery
[ 5.399191] ixgbe 0000:82:00.0: MAC: 3, PHY: 3, PBA No: G45270-003
[ 5.399192] ixgbe 0000:82:00.0: a0:36:9f:3e:63:fc
[ 5.443870] EXT4-fs (dm-0): orphan cleanup on readonly fs
[ 5.454122] EXT4-fs (dm-0): 3 orphan inodes deleted
[ 5.462883] igb 0000:06:00.2: added PHC on eth2
[ 5.462884] igb 0000:06:00.2: Intel(R) Gigabit Ethernet Network Connection
[ 5.462885] igb 0000:06:00.2: eth2: (PCIe:5.0Gb/s:Width x4) 00:25:90:f5:6e:04
[ 5.463078] igb 0000:06:00.2: eth2: PBA No: 105900-000
[ 5.463079] igb 0000:06:00.2: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[ 5.465062] igb 0000:06:00.3: irq 161 for MSI/MSI-X
[ 5.465086] igb 0000:06:00.3: irq 162 for MSI/MSI-X
[ 5.465097] igb 0000:06:00.3: irq 163 for MSI/MSI-X
[ 5.465108] igb 0000:06:00.3: irq 164 for MSI/MSI-X
[ 5.465123] igb 0000:06:00.3: irq 165 for MSI/MSI-X
[ 5.465148] igb 0000:06:00.3: irq 166 for MSI/MSI-X
[ 5.465183] igb 0000:06:00.3: irq 167 for MSI/MSI-X
[ 5.465217] igb 0000:06:00.3: irq 168 for MSI/MSI-X
[ 5.465242] igb 0000:06:00.3: irq 169 for MSI/MSI-X
[ 5.514421] igb 0000:06:00.3: irq 161 for MSI/MSI-X
[ 5.514433] igb 0000:06:00.3: irq 162 for MSI/MSI-X
[ 5.514455] igb 0000:06:00.3: irq 163 for MSI/MSI-X
[ 5.514478] igb 0000:06:00.3: irq 164 for MSI/MSI-X
[ 5.514520] igb 0000:06:00.3: irq 165 for MSI/MSI-X
[ 5.514557] igb 0000:06:00.3: irq 166 for MSI/MSI-X
[ 5.514570] igb 0000:06:00.3: irq 167 for MSI/MSI-X
[ 5.514582] igb 0000:06:00.3: irq 168 for MSI/MSI-X
[ 5.514593] igb 0000:06:00.3: irq 169 for MSI/MSI-X
[ 5.525951] EXT4-fs (dm-0): recovery complete
[ 5.542609] ixgbe 0000:82:00.0: Intel(R) 10 Gigabit Network Connection
[ 5.550213] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[ 5.566846] mpt2sas0: LSISAS2308: FWVersion(17.00.01.00), ChipRevision(0x05), BiosVersion(07.33.00.00)
[ 5.566849] mpt2sas0: Protocol=(Initiator,Target), Capabilities=(TLR,EEDP,Snapshot Buffer,Diag Trace Buffer,Task Set Full,NCQ)
[ 5.566977] mpt2sas0: sending port enable !!
[ 5.591970] igb 0000:06:00.3: added PHC on eth4
[ 5.591971] igb 0000:06:00.3: Intel(R) Gigabit Ethernet Network Connection
[ 5.591972] igb 0000:06:00.3: eth4: (PCIe:5.0Gb/s:Width x4) 00:25:90:f5:6e:05
[ 5.592115] igb 0000:06:00.3: eth4: PBA No: 105900-000
[ 5.592116] igb 0000:06:00.3: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[ 6.119185] ixgbe 0000:82:00.1: irq 170 for MSI/MSI-X
[ 6.119191] ixgbe 0000:82:00.1: irq 171 for MSI/MSI-X
[ 6.119196] ixgbe 0000:82:00.1: irq 172 for MSI/MSI-X
[ 6.119203] ixgbe 0000:82:00.1: irq 173 for MSI/MSI-X
[ 6.119207] ixgbe 0000:82:00.1: irq 174 for MSI/MSI-X
[ 6.119211] ixgbe 0000:82:00.1: irq 175 for MSI/MSI-X
[ 6.119216] ixgbe 0000:82:00.1: irq 176 for MSI/MSI-X
[ 6.119220] ixgbe 0000:82:00.1: irq 177 for MSI/MSI-X
[ 6.119225] ixgbe 0000:82:00.1: irq 178 for MSI/MSI-X
[ 6.119229] ixgbe 0000:82:00.1: irq 179 for MSI/MSI-X
[ 6.119236] ixgbe 0000:82:00.1: irq 180 for MSI/MSI-X
[ 6.119240] ixgbe 0000:82:00.1: irq 181 for MSI/MSI-X
[ 6.119245] ixgbe 0000:82:00.1: irq 182 for MSI/MSI-X
[ 6.119249] ixgbe 0000:82:00.1: irq 183 for MSI/MSI-X
[ 6.119253] ixgbe 0000:82:00.1: irq 184 for MSI/MSI-X
[ 6.119257] ixgbe 0000:82:00.1: irq 185 for MSI/MSI-X
[ 6.119261] ixgbe 0000:82:00.1: irq 186 for MSI/MSI-X
[ 6.119266] ixgbe 0000:82:00.1: irq 187 for MSI/MSI-X
[ 6.119270] ixgbe 0000:82:00.1: irq 188 for MSI/MSI-X
[ 6.119274] ixgbe 0000:82:00.1: irq 189 for MSI/MSI-X
[ 6.119278] ixgbe 0000:82:00.1: irq 190 for MSI/MSI-X
[ 6.119282] ixgbe 0000:82:00.1: irq 191 for MSI/MSI-X
[ 6.119287] ixgbe 0000:82:00.1: irq 192 for MSI/MSI-X
[ 6.119291] ixgbe 0000:82:00.1: irq 193 for MSI/MSI-X
[ 6.119295] ixgbe 0000:82:00.1: irq 194 for MSI/MSI-X
[ 6.119353] ixgbe 0000:82:00.1: Multiqueue Enabled: Rx Queue count = 24, Tx Queue count = 24
[ 6.199722] ixgbe 0000:82:00.1: PCI Express bandwidth of 32GT/s available
[ 6.210022] ixgbe 0000:82:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
[ 6.381482] ixgbe 0000:82:00.1: MAC: 3, PHY: 3, PBA No: G45270-003
[ 6.392627] ixgbe 0000:82:00.1: a0:36:9f:3e:63:fe
[ 6.547077] ixgbe 0000:82:00.1: Intel(R) 10 Gigabit Network Connection
[ 6.651742] init: plymouth-upstart-bridge main process (424) terminated with status 1
[ 6.672598] init: plymouth-upstart-bridge main process ended, respawning
[ 6.690088] init: plymouth-upstart-bridge main process (434) terminated with status 1
[ 6.713691] init: plymouth-upstart-bridge main process ended, respawning
[ 6.793078] Adding 503804k swap on /dev/mapper/system-swap_1. Priority:-1 extents:1 across:503804k SSFS
[ 6.848219] random: nonblocking pool is initialized
[ 6.867091] systemd-udevd[549]: starting version 204
[ 6.879040] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,discard
[ 6.898170] lp: driver loaded but no devices found
[ 6.914831] 8021q: 802.1Q VLAN Support v1.8
[ 6.920257] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 6.935235] wmi: Mapper loaded
[ 6.938665] ioatdma: Intel(R) QuickData Technology Driver 4.00
[ 6.938891] ioatdma 0000:00:04.0: irq 195 for MSI/MSI-X
[ 6.939259] igb 0000:06:00.0: DCA enabled
[ 6.939327] igb 0000:06:00.1: DCA enabled
[ 6.939450] ioatdma 0000:00:04.1: irq 196 for MSI/MSI-X
[ 6.939590] igb 0000:06:00.2: DCA enabled
[ 6.939606] igb 0000:06:00.3: DCA enabled
[ 6.939706] ioatdma 0000:00:04.2: irq 197 for MSI/MSI-X
[ 6.939953] ioatdma 0000:00:04.3: irq 198 for MSI/MSI-X
[ 6.940404] ioatdma 0000:00:04.4: irq 199 for MSI/MSI-X
[ 6.940746] ioatdma 0000:00:04.5: irq 200 for MSI/MSI-X
[ 6.940988] ioatdma 0000:00:04.6: irq 201 for MSI/MSI-X
[ 6.941358] ioatdma 0000:00:04.7: irq 202 for MSI/MSI-X
[ 6.941987] ioatdma 0000:80:04.0: irq 203 for MSI/MSI-X
[ 6.942819] ioatdma 0000:80:04.1: irq 204 for MSI/MSI-X
[ 6.943247] ioatdma 0000:80:04.2: irq 205 for MSI/MSI-X
[ 6.943469] ioatdma 0000:80:04.3: irq 206 for MSI/MSI-X
[ 6.943937] ioatdma 0000:80:04.4: irq 207 for MSI/MSI-X
[ 6.946086] ioatdma 0000:80:04.5: irq 208 for MSI/MSI-X
[ 6.946305] ioatdma 0000:80:04.6: irq 209 for MSI/MSI-X
[ 6.946762] ioatdma 0000:80:04.7: irq 210 for MSI/MSI-X
[ 6.953712] ipmi message handler version 39.2
[ 6.957611] IPMI System Interface driver.
[ 6.957761] ipmi_si: probing via ACPI
[ 6.957784] ipmi_si 00:08: [io 0x0ca2] regsize 1 spacing 1 irq 0
[ 6.957786] ipmi_si: Adding ACPI-specified kcs state machine
[ 6.957851] ipmi_si: probing via SMBIOS
[ 6.957853] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
[ 6.957853] ipmi_si: Adding SMBIOS-specified kcs state machine duplicate interface
[ 6.957855] ipmi_si: probing via SPMI
[ 6.957856] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0
[ 6.957857] ipmi_si: Adding SPMI-specified kcs state machine duplicate interface
[ 6.957859] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
[ 6.961221] mei_me 0000:00:16.0: Device doesn't have valid ME Interface
[ 6.972850] EDAC MC: Ver: 3.0.0
[ 6.975003] EDAC sbridge: Seeking for: dev 0e.0 PCI ID 8086:0ea0
[ 6.975011] EDAC sbridge: Seeking for: dev 0e.0 PCI ID 8086:0ea0
[ 6.975017] EDAC sbridge: Seeking for: dev 0e.0 PCI ID 8086:0ea0
[ 6.975019] EDAC sbridge: Seeking for: dev 0f.0 PCI ID 8086:0ea8
[ 6.975022] EDAC sbridge: Seeking for: dev 0f.0 PCI ID 8086:0ea8
[ 6.975026] EDAC sbridge: Seeking for: dev 0f.0 PCI ID 8086:0ea8
[ 6.975027] EDAC sbridge: Seeking for: dev 0f.1 PCI ID 8086:0e71
[ 6.975031] EDAC sbridge: Seeking for: dev 0f.1 PCI ID 8086:0e71
[ 6.975034] EDAC sbridge: Seeking for: dev 0f.1 PCI ID 8086:0e71
[ 6.975036] EDAC sbridge: Seeking for: dev 0f.2 PCI ID 8086:0eaa
[ 6.975039] EDAC sbridge: Seeking for: dev 0f.2 PCI ID 8086:0eaa
[ 6.975043] EDAC sbridge: Seeking for: dev 0f.2 PCI ID 8086:0eaa
[ 6.975044] EDAC sbridge: Seeking for: dev 0f.3 PCI ID 8086:0eab
[ 6.975048] EDAC sbridge: Seeking for: dev 0f.3 PCI ID 8086:0eab
[ 6.975051] EDAC sbridge: Seeking for: dev 0f.3 PCI ID 8086:0eab
[ 6.975053] EDAC sbridge: Seeking for: dev 0f.4 PCI ID 8086:0eac
[ 6.975056] EDAC sbridge: Seeking for: dev 0f.4 PCI ID 8086:0eac
[ 6.975060] EDAC sbridge: Seeking for: dev 0f.4 PCI ID 8086:0eac
[ 6.975061] EDAC sbridge: Seeking for: dev 0f.5 PCI ID 8086:0ead
[ 6.975065] EDAC sbridge: Seeking for: dev 0f.5 PCI ID 8086:0ead
[ 6.975069] EDAC sbridge: Seeking for: dev 0f.5 PCI ID 8086:0ead
[ 6.975070] EDAC sbridge: Seeking for: dev 16.0 PCI ID 8086:0ec8
[ 6.975074] EDAC sbridge: Seeking for: dev 16.0 PCI ID 8086:0ec8
[ 6.975077] EDAC sbridge: Seeking for: dev 16.0 PCI ID 8086:0ec8
[ 6.975078] EDAC sbridge: Seeking for: dev 16.1 PCI ID 8086:0ec9
[ 6.975082] EDAC sbridge: Seeking for: dev 16.1 PCI ID 8086:0ec9
[ 6.975086] EDAC sbridge: Seeking for: dev 16.1 PCI ID 8086:0ec9
[ 6.975087] EDAC sbridge: Seeking for: dev 16.2 PCI ID 8086:0eca
[ 6.975091] EDAC sbridge: Seeking for: dev 16.2 PCI ID 8086:0eca
[ 6.975094] EDAC sbridge: Seeking for: dev 16.2 PCI ID 8086:0eca
[ 6.975095] EDAC sbridge: Seeking for: dev 1c.0 PCI ID 8086:0e60
[ 6.975100] EDAC sbridge: Seeking for: dev 1d.2 PCI ID 8086:0e6a
[ 6.975105] EDAC sbridge: Seeking for: dev 1d.3 PCI ID 8086:0e6b
[ 6.975109] EDAC sbridge: Seeking for: dev 11.0 PCI ID 8086:0eb8
[ 6.975114] EDAC sbridge: Seeking for: dev 11.4 PCI ID 8086:0ebc
[ 6.975476] EDAC MC0: Giving out device to module sbridge_edac.c controller Ivy Bridge Socket#0: DEV 0000:7f:0e.0 (POLLED)
[ 6.975721] EDAC MC1: Giving out device to module sbridge_edac.c controller Ivy Bridge Socket#1: DEV 0000:ff:0e.0 (POLLED)
[ 6.975723] EDAC sbridge: Driver loaded.
[ 6.997685] audit: type=1400 audit(1434039130.848:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/sbin/dhclient" pid=792 comm="apparmor_parser"
[ 6.997694] audit: type=1400 audit(1434039130.848:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=792 comm="apparmor_parser"
[ 6.997700] audit: type=1400 audit(1434039130.848:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=792 comm="apparmor_parser"
[ 6.997711] audit: type=1400 audit(1434039130.848:5): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/sbin/dhclient" pid=794 comm="apparmor_parser"
[ 6.997719] audit: type=1400 audit(1434039130.848:6): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=794 comm="apparmor_parser"
[ 6.997724] audit: type=1400 audit(1434039130.848:7): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=794 comm="apparmor_parser"
[ 6.997732] audit: type=1400 audit(1434039130.848:8): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/sbin/dhclient" pid=797 comm="apparmor_parser"
[ 6.997738] audit: type=1400 audit(1434039130.848:9): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=797 comm="apparmor_parser"
[ 6.997743] audit: type=1400 audit(1434039130.848:10): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=797 comm="apparmor_parser"
[ 6.998268] audit: type=1400 audit(1434039130.848:11): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=797 comm="apparmor_parser"
[ 6.998791] AVX version of gcm_enc/dec engaged.
[ 7.014768] systemd-udevd[612]: renamed network interface eth4 to rename6
[ 7.083698] ipmi_si 00:08: Found new BMC (man_id: 0x002a7c, prod_id: 0x0626, dev_id: 0x20)
[ 7.083707] ipmi_si 00:08: IPMI kcs interface initialized
[ 7.150813] mpt2sas0: host_add: handle(0x0001), sas_addr(0x500605b0091ca950), phys(8)
[ 7.156288] mpt2sas0: expander_add: handle(0x0009), parent(0x0001), sas_addr(0x500304800143423f), phys(38)
[ 7.186902] systemd-udevd[611]: renamed network interface eth3 to eth4
[ 7.386921] systemd-udevd[612]: renamed network interface rename6 to eth3
[ 7.388643] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 7.388645] 8021q: adding VLAN 0 to HW filter on device bond0
[ 7.389214] 8021q: VLANs not supported on bond0
[ 7.402247] mpt2sas0: expander_add: handle(0x0023), parent(0x0002), sas_addr(0x50030480014ac8bf), phys(30)
[ 7.411583] init: rpcbind main process (1127) terminated with status 127
[ 7.411592] init: rpcbind main process ended, respawning
[ 7.415468] bonding: bond0: Setting MII monitoring interval to 100
[ 7.421149] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 7.421150] 8021q: adding VLAN 0 to HW filter on device bond0
[ 7.429882] init: Failed to obtain startpar-bridge instance: Unknown parameter: INSTANCE
[ 7.464609] bonding: bond0: Adding slave eth5
[ 7.520243] Adding 33554428k swap on /opt/swap/swapfile. Priority:-2 extents:19 across:35799036k SSFS
[ 7.533552] EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem
[ 7.534549] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 7.567208] pps pps0: new PPS source ptp4
[ 7.567212] ixgbe 0000:82:00.1: registered PHC device on eth5
[ 7.969101] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready
[ 7.969105] 8021q: adding VLAN 0 to HW filter on device eth5
[ 7.989258] bonding: bond0: Enslaving eth5 as a backup interface with a down link
[ 7.990123] bonding: bond0: Adding slave eth4
[ 8.095897] pps pps1: new PPS source ptp5
[ 8.095900] ixgbe 0000:82:00.0: registered PHC device on eth4
[ 8.497556] IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
[ 8.497559] 8021q: adding VLAN 0 to HW filter on device eth4
[ 8.517684] bonding: bond0: Enslaving eth4 as a backup interface with a down link
[ 8.522187] IPv6: ADDRCONF(NETDEV_UP): bond0.21: link is not ready
[ 8.567868] init: failsafe main process (1239) killed by TERM signal
[ 8.888894] ipmi device interface
[ 8.943352] ioatdma 0000:00:04.1: ioat3_timer_event: Channel halted (0)
[ 11.940456] init: plymouth-upstart-bridge main process ended, respawning
[ 12.908949] mpt2sas0: port enable: SUCCESS
[ 13.148174] scsi 6:0:0:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 13.148179] scsi 6:0:0:0: SATA: handle(0x000a), sas_addr(0x500304800143420c), phy(12), device_name(0x0000000000000000)
[ 13.148180] scsi 6:0:0:0: SATA: enclosure_logical_id(0x500304800143423f), slot(0)
[ 13.148258] scsi 6:0:0:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 13.148260] scsi 6:0:0:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 13.397903] scsi 6:0:1:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 13.397907] scsi 6:0:1:0: SATA: handle(0x000b), sas_addr(0x500304800143420d), phy(13), device_name(0x0000000000000000)
[ 13.397909] scsi 6:0:1:0: SATA: enclosure_logical_id(0x500304800143423f), slot(1)
[ 13.397986] scsi 6:0:1:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 13.397988] scsi 6:0:1:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 13.648471] scsi 6:0:2:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 13.648475] scsi 6:0:2:0: SATA: handle(0x000c), sas_addr(0x500304800143420e), phy(14), device_name(0x0000000000000000)
[ 13.648477] scsi 6:0:2:0: SATA: enclosure_logical_id(0x500304800143423f), slot(2)
[ 13.648554] scsi 6:0:2:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 13.648556] scsi 6:0:2:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 13.875568] ixgbe 0000:82:00.1 eth5: NIC Link is Up 10 Gbps, Flow Control: None
[ 13.898511] scsi 6:0:3:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 13.898516] scsi 6:0:3:0: SATA: handle(0x000d), sas_addr(0x500304800143420f), phy(15), device_name(0x0000000000000000)
[ 13.898517] scsi 6:0:3:0: SATA: enclosure_logical_id(0x500304800143423f), slot(3)
[ 13.898595] scsi 6:0:3:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 13.898596] scsi 6:0:3:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 13.925388] bonding: bond0: link status definitely up for interface eth5, 10000 Mbps full duplex
[ 13.925390] bonding: bond0: making interface eth5 the new active one
[ 13.926119] bonding: bond0: first active interface up!
[ 13.926124] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 13.927427] IPv6: ADDRCONF(NETDEV_CHANGE): bond0.21: link becomes ready
[ 14.148682] scsi 6:0:4:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 14.148686] scsi 6:0:4:0: SATA: handle(0x000e), sas_addr(0x5003048001434210), phy(16), device_name(0x0000000000000000)
[ 14.148688] scsi 6:0:4:0: SATA: enclosure_logical_id(0x500304800143423f), slot(4)
[ 14.148765] scsi 6:0:4:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 14.148767] scsi 6:0:4:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 14.398653] scsi 6:0:5:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 14.398658] scsi 6:0:5:0: SATA: handle(0x000f), sas_addr(0x5003048001434211), phy(17), device_name(0x0000000000000000)
[ 14.398659] scsi 6:0:5:0: SATA: enclosure_logical_id(0x500304800143423f), slot(5)
[ 14.398737] scsi 6:0:5:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 14.398739] scsi 6:0:5:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 14.648651] scsi 6:0:6:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 14.648656] scsi 6:0:6:0: SATA: handle(0x0010), sas_addr(0x5003048001434212), phy(18), device_name(0x0000000000000000)
[ 14.648658] scsi 6:0:6:0: SATA: enclosure_logical_id(0x500304800143423f), slot(6)
[ 14.648736] scsi 6:0:6:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 14.648742] scsi 6:0:6:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 14.898793] scsi 6:0:7:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 14.898798] scsi 6:0:7:0: SATA: handle(0x0011), sas_addr(0x5003048001434213), phy(19), device_name(0x0000000000000000)
[ 14.898799] scsi 6:0:7:0: SATA: enclosure_logical_id(0x500304800143423f), slot(7)
[ 14.898877] scsi 6:0:7:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 14.898879] scsi 6:0:7:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 15.148978] scsi 6:0:8:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 15.148982] scsi 6:0:8:0: SATA: handle(0x0012), sas_addr(0x5003048001434214), phy(20), device_name(0x0000000000000000)
[ 15.148984] scsi 6:0:8:0: SATA: enclosure_logical_id(0x500304800143423f), slot(8)
[ 15.149070] scsi 6:0:8:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 15.149077] scsi 6:0:8:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 15.399075] scsi 6:0:9:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 15.399081] scsi 6:0:9:0: SATA: handle(0x0013), sas_addr(0x5003048001434215), phy(21), device_name(0x0000000000000000)
[ 15.399083] scsi 6:0:9:0: SATA: enclosure_logical_id(0x500304800143423f), slot(9)
[ 15.399160] scsi 6:0:9:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 15.399162] scsi 6:0:9:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 15.649115] scsi 6:0:10:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 15.649120] scsi 6:0:10:0: SATA: handle(0x0014), sas_addr(0x5003048001434216), phy(22), device_name(0x0000000000000000)
[ 15.649121] scsi 6:0:10:0: SATA: enclosure_logical_id(0x500304800143423f), slot(10)
[ 15.649199] scsi 6:0:10:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 15.649201] scsi 6:0:10:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 15.899613] scsi 6:0:11:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 15.899617] scsi 6:0:11:0: SATA: handle(0x0015), sas_addr(0x5003048001434217), phy(23), device_name(0x0000000000000000)
[ 15.899619] scsi 6:0:11:0: SATA: enclosure_logical_id(0x500304800143423f), slot(11)
[ 15.899696] scsi 6:0:11:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 15.899698] scsi 6:0:11:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 16.149314] scsi 6:0:12:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 16.149319] scsi 6:0:12:0: SATA: handle(0x0016), sas_addr(0x5003048001434218), phy(24), device_name(0x0000000000000000)
[ 16.149320] scsi 6:0:12:0: SATA: enclosure_logical_id(0x500304800143423f), slot(12)
[ 16.149398] scsi 6:0:12:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 16.149400] scsi 6:0:12:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 16.399470] scsi 6:0:13:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 16.399475] scsi 6:0:13:0: SATA: handle(0x0017), sas_addr(0x5003048001434219), phy(25), device_name(0x0000000000000000)
[ 16.399477] scsi 6:0:13:0: SATA: enclosure_logical_id(0x500304800143423f), slot(13)
[ 16.399555] scsi 6:0:13:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 16.399556] scsi 6:0:13:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 16.649771] scsi 6:0:14:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 16.649776] scsi 6:0:14:0: SATA: handle(0x0018), sas_addr(0x500304800143421a), phy(26), device_name(0x0000000000000000)
[ 16.649777] scsi 6:0:14:0: SATA: enclosure_logical_id(0x500304800143423f), slot(14)
[ 16.649874] scsi 6:0:14:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 16.649879] scsi 6:0:14:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 16.899604] scsi 6:0:15:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 16.899609] scsi 6:0:15:0: SATA: handle(0x0019), sas_addr(0x500304800143421b), phy(27), device_name(0x0000000000000000)
[ 16.899610] scsi 6:0:15:0: SATA: enclosure_logical_id(0x500304800143423f), slot(15)
[ 16.899699] scsi 6:0:15:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 16.899701] scsi 6:0:15:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 17.150120] scsi 6:0:16:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 17.150124] scsi 6:0:16:0: SATA: handle(0x001a), sas_addr(0x500304800143421c), phy(28), device_name(0x0000000000000000)
[ 17.150126] scsi 6:0:16:0: SATA: enclosure_logical_id(0x500304800143423f), slot(16)
[ 17.150204] scsi 6:0:16:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 17.150206] scsi 6:0:16:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 17.399868] scsi 6:0:17:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 17.399873] scsi 6:0:17:0: SATA: handle(0x001b), sas_addr(0x500304800143421d), phy(29), device_name(0x0000000000000000)
[ 17.399874] scsi 6:0:17:0: SATA: enclosure_logical_id(0x500304800143423f), slot(17)
[ 17.399952] scsi 6:0:17:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 17.399954] scsi 6:0:17:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 17.650294] scsi 6:0:18:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 17.650299] scsi 6:0:18:0: SATA: handle(0x001c), sas_addr(0x500304800143421e), phy(30), device_name(0x0000000000000000)
[ 17.650301] scsi 6:0:18:0: SATA: enclosure_logical_id(0x500304800143423f), slot(18)
[ 17.650378] scsi 6:0:18:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 17.650380] scsi 6:0:18:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 17.899830] scsi 6:0:19:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 17.899835] scsi 6:0:19:0: SATA: handle(0x001d), sas_addr(0x500304800143421f), phy(31), device_name(0x0000000000000000)
[ 17.899836] scsi 6:0:19:0: SATA: enclosure_logical_id(0x500304800143423f), slot(19)
[ 17.899914] scsi 6:0:19:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 17.899916] scsi 6:0:19:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 18.150115] scsi 6:0:20:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 18.150123] scsi 6:0:20:0: SATA: handle(0x001e), sas_addr(0x5003048001434220), phy(32), device_name(0x0000000000000000)
[ 18.150125] scsi 6:0:20:0: SATA: enclosure_logical_id(0x500304800143423f), slot(20)
[ 18.150204] scsi 6:0:20:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 18.150206] scsi 6:0:20:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 18.400229] scsi 6:0:21:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 18.400234] scsi 6:0:21:0: SATA: handle(0x001f), sas_addr(0x5003048001434221), phy(33), device_name(0x0000000000000000)
[ 18.400235] scsi 6:0:21:0: SATA: enclosure_logical_id(0x500304800143423f), slot(21)
[ 18.400313] scsi 6:0:21:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 18.400315] scsi 6:0:21:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 18.649925] scsi 6:0:22:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 18.649930] scsi 6:0:22:0: SATA: handle(0x0020), sas_addr(0x5003048001434222), phy(34), device_name(0x0000000000000000)
[ 18.649931] scsi 6:0:22:0: SATA: enclosure_logical_id(0x500304800143423f), slot(22)
[ 18.650009] scsi 6:0:22:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 18.650011] scsi 6:0:22:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 18.900356] scsi 6:0:23:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 18.900361] scsi 6:0:23:0: SATA: handle(0x0021), sas_addr(0x5003048001434223), phy(35), device_name(0x0000000000000000)
[ 18.900362] scsi 6:0:23:0: SATA: enclosure_logical_id(0x500304800143423f), slot(23)
[ 18.900440] scsi 6:0:23:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 18.900442] scsi 6:0:23:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 18.905031] scsi 6:0:24:0: Enclosure LSI SAS2X36 0e12 PQ: 0 ANSI: 5
[ 18.905037] scsi 6:0:24:0: SSP: handle(0x0022), sas_addr(0x500304800143423d), phy(36), device_name(0x0000000000000000)
[ 18.905039] scsi 6:0:24:0: SSP: enclosure_logical_id(0x500304800143423f), slot(24)
[ 18.905042] scsi 6:0:24:0: qdepth(254), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1)
[ 19.150142] scsi 6:0:25:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 19.150150] scsi 6:0:25:0: SATA: handle(0x0024), sas_addr(0x50030480014ac8ac), phy(12), device_name(0x0000000000000000)
[ 19.150151] scsi 6:0:25:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(0)
[ 19.150230] scsi 6:0:25:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 19.150232] scsi 6:0:25:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 19.288834] ixgbe 0000:82:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: None
[ 19.329571] bonding: bond0: link status definitely up for interface eth4, 10000 Mbps full duplex
[ 19.400278] scsi 6:0:26:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 19.400283] scsi 6:0:26:0: SATA: handle(0x0025), sas_addr(0x50030480014ac8ad), phy(13), device_name(0x0000000000000000)
[ 19.400284] scsi 6:0:26:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(1)
[ 19.400362] scsi 6:0:26:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 19.400364] scsi 6:0:26:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 19.650294] scsi 6:0:27:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 19.650300] scsi 6:0:27:0: SATA: handle(0x0026), sas_addr(0x50030480014ac8ae), phy(14), device_name(0x0000000000000000)
[ 19.650303] scsi 6:0:27:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(2)
[ 19.650382] scsi 6:0:27:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 19.650385] scsi 6:0:27:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 19.900417] scsi 6:0:28:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 19.900422] scsi 6:0:28:0: SATA: handle(0x0027), sas_addr(0x50030480014ac8af), phy(15), device_name(0x0000000000000000)
[ 19.900423] scsi 6:0:28:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(3)
[ 19.900501] scsi 6:0:28:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 19.900503] scsi 6:0:28:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 20.150532] scsi 6:0:29:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 20.150537] scsi 6:0:29:0: SATA: handle(0x0028), sas_addr(0x50030480014ac8b0), phy(16), device_name(0x0000000000000000)
[ 20.150539] scsi 6:0:29:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(4)
[ 20.150616] scsi 6:0:29:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 20.150618] scsi 6:0:29:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 20.401083] scsi 6:0:30:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 20.401088] scsi 6:0:30:0: SATA: handle(0x0029), sas_addr(0x50030480014ac8b1), phy(17), device_name(0x0000000000000000)
[ 20.401089] scsi 6:0:30:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(5)
[ 20.401167] scsi 6:0:30:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 20.401169] scsi 6:0:30:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 20.650764] scsi 6:0:31:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 20.650769] scsi 6:0:31:0: SATA: handle(0x002a), sas_addr(0x50030480014ac8b2), phy(18), device_name(0x0000000000000000)
[ 20.650770] scsi 6:0:31:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(6)
[ 20.650848] scsi 6:0:31:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 20.650850] scsi 6:0:31:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 20.901215] scsi 6:0:32:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 20.901220] scsi 6:0:32:0: SATA: handle(0x002b), sas_addr(0x50030480014ac8b3), phy(19), device_name(0x0000000000000000)
[ 20.901221] scsi 6:0:32:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(7)
[ 20.901299] scsi 6:0:32:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 20.901301] scsi 6:0:32:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 21.151347] scsi 6:0:33:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 21.151359] scsi 6:0:33:0: SATA: handle(0x002c), sas_addr(0x50030480014ac8b4), phy(20), device_name(0x0000000000000000)
[ 21.151360] scsi 6:0:33:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(8)
[ 21.151439] scsi 6:0:33:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 21.151442] scsi 6:0:33:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 21.401429] scsi 6:0:34:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 21.401435] scsi 6:0:34:0: SATA: handle(0x002d), sas_addr(0x50030480014ac8b5), phy(21), device_name(0x0000000000000000)
[ 21.401437] scsi 6:0:34:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(9)
[ 21.401516] scsi 6:0:34:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 21.401519] scsi 6:0:34:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 21.651161] scsi 6:0:35:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 21.651166] scsi 6:0:35:0: SATA: handle(0x002e), sas_addr(0x50030480014ac8b6), phy(22), device_name(0x0000000000000000)
[ 21.651168] scsi 6:0:35:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(10)
[ 21.651246] scsi 6:0:35:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 21.651248] scsi 6:0:35:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 21.901185] scsi 6:0:36:0: Direct-Access ATA HGST HDN724030AL A5E0 PQ: 0 ANSI: 6
[ 21.901191] scsi 6:0:36:0: SATA: handle(0x002f), sas_addr(0x50030480014ac8b7), phy(23), device_name(0x0000000000000000)
[ 21.901193] scsi 6:0:36:0: SATA: enclosure_logical_id(0x50030480014ac8bf), slot(11)
[ 21.901272] scsi 6:0:36:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
[ 21.901275] scsi 6:0:36:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
[ 21.905588] scsi 6:0:37:0: Enclosure LSI SAS2X28 0e12 PQ: 0 ANSI: 5
[ 21.905593] scsi 6:0:37:0: SSP: handle(0x0030), sas_addr(0x50030480014ac8bd), phy(28), device_name(0x0000000000000000)
[ 21.905594] scsi 6:0:37:0: SSP: enclosure_logical_id(0x50030480014ac8bf), slot(0)
[ 21.905596] scsi 6:0:37:0: qdepth(254), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1)
[ 21.908558] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 21.908742] sd 6:0:1:0: Attached scsi generic sg2 type 0
[ 21.909031] sd 6:0:2:0: Attached scsi generic sg3 type 0
[ 21.909299] sd 6:0:3:0: Attached scsi generic sg4 type 0
[ 21.909513] sd 6:0:4:0: Attached scsi generic sg5 type 0
[ 21.909793] sd 6:0:5:0: Attached scsi generic sg6 type 0
[ 21.909951] sd 6:0:6:0: Attached scsi generic sg7 type 0
[ 21.909982] sd 6:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.909984] sd 6:0:0:0: [sdb] 4096-byte physical blocks
[ 21.910133] sd 6:0:7:0: Attached scsi generic sg8 type 0
[ 21.910416] sd 6:0:8:0: Attached scsi generic sg9 type 0
[ 21.910684] sd 6:0:3:0: [sde] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.910685] sd 6:0:3:0: [sde] 4096-byte physical blocks
[ 21.911014] sd 6:0:4:0: [sdf] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.911016] sd 6:0:4:0: [sdf] 4096-byte physical blocks
[ 21.911143] sd 6:0:9:0: Attached scsi generic sg10 type 0
[ 21.911145] sd 6:0:5:0: [sdg] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.911147] sd 6:0:5:0: [sdg] 4096-byte physical blocks
[ 21.911403] sd 6:0:6:0: [sdh] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.911405] sd 6:0:6:0: [sdh] 4096-byte physical blocks
[ 21.912295] sd 6:0:10:0: Attached scsi generic sg11 type 0
[ 21.913667] sd 6:0:11:0: Attached scsi generic sg12 type 0
[ 21.913803] sd 6:0:1:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.913806] sd 6:0:1:0: [sdc] 4096-byte physical blocks
[ 21.914695] sd 6:0:12:0: Attached scsi generic sg13 type 0
[ 21.915449] sd 6:0:13:0: Attached scsi generic sg14 type 0
[ 21.915486] sd 6:0:11:0: [sdm] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.915489] sd 6:0:11:0: [sdm] 4096-byte physical blocks
[ 21.916044] sd 6:0:14:0: Attached scsi generic sg15 type 0
[ 21.916984] sd 6:0:15:0: Attached scsi generic sg16 type 0
[ 21.917321] sd 6:0:12:0: [sdn] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.917323] sd 6:0:12:0: [sdn] 4096-byte physical blocks
[ 21.917563] sd 6:0:16:0: Attached scsi generic sg17 type 0
[ 21.917861] sd 6:0:14:0: [sdp] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.917865] sd 6:0:14:0: [sdp] 4096-byte physical blocks
[ 21.918315] sd 6:0:15:0: [sdq] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.918317] sd 6:0:15:0: [sdq] 4096-byte physical blocks
[ 21.918324] sd 6:0:17:0: Attached scsi generic sg18 type 0
[ 21.918616] sd 6:0:13:0: [sdo] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.918618] sd 6:0:13:0: [sdo] 4096-byte physical blocks
[ 21.919279] sd 6:0:2:0: [sdd] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.919280] sd 6:0:2:0: [sdd] 4096-byte physical blocks
[ 21.920957] sd 6:0:10:0: [sdl] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.920960] sd 6:0:10:0: [sdl] 4096-byte physical blocks
[ 21.922003] sd 6:0:18:0: Attached scsi generic sg19 type 0
[ 21.923289] sd 6:0:18:0: [sdt] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.923292] sd 6:0:18:0: [sdt] 4096-byte physical blocks
[ 21.928803] sd 6:0:19:0: Attached scsi generic sg20 type 0
[ 21.930003] sd 6:0:20:0: Attached scsi generic sg21 type 0
[ 21.931248] sd 6:0:21:0: Attached scsi generic sg22 type 0
[ 21.932151] sd 6:0:22:0: Attached scsi generic sg23 type 0
[ 21.933333] sd 6:0:22:0: [sdx] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.933337] sd 6:0:22:0: [sdx] 4096-byte physical blocks
[ 21.933512] sd 6:0:23:0: Attached scsi generic sg24 type 0
[ 21.934586] sd 6:0:23:0: [sdy] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.934588] sd 6:0:23:0: [sdy] 4096-byte physical blocks
[ 21.935394] scsi 6:0:24:0: Attached scsi generic sg25 type 13
[ 21.935799] sd 6:0:25:0: Attached scsi generic sg26 type 0
[ 21.936452] sd 6:0:26:0: Attached scsi generic sg27 type 0
[ 21.937016] sd 6:0:25:0: [sdz] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.937019] sd 6:0:25:0: [sdz] 4096-byte physical blocks
[ 21.937623] sd 6:0:27:0: Attached scsi generic sg28 type 0
[ 21.938254] sd 6:0:16:0: [sdr] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.938257] sd 6:0:16:0: [sdr] 4096-byte physical blocks
[ 21.938862] sd 6:0:28:0: Attached scsi generic sg29 type 0
[ 21.939810] sd 6:0:28:0: [sdac] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.939813] sd 6:0:28:0: [sdac] 4096-byte physical blocks
[ 21.939951] sd 6:0:8:0: [sdj] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.939954] sd 6:0:8:0: [sdj] 4096-byte physical blocks
[ 21.940890] sd 6:0:29:0: Attached scsi generic sg30 type 0
[ 21.941554] sd 6:0:21:0: [sdw] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.941557] sd 6:0:21:0: [sdw] 4096-byte physical blocks
[ 21.943129] sd 6:0:26:0: [sdaa] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.943132] sd 6:0:26:0: [sdaa] 4096-byte physical blocks
[ 21.943875] sd 6:0:30:0: Attached scsi generic sg31 type 0
[ 21.944131] sd 6:0:29:0: [sdad] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.944133] sd 6:0:29:0: [sdad] 4096-byte physical blocks
[ 21.945045] sd 6:0:19:0: [sdu] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.945048] sd 6:0:19:0: [sdu] 4096-byte physical blocks
[ 21.947012] sd 6:0:31:0: Attached scsi generic sg32 type 0
[ 21.948147] sd 6:0:31:0: [sdaf] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.948150] sd 6:0:31:0: [sdaf] 4096-byte physical blocks
[ 21.949136] sd 6:0:17:0: [sds] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.949139] sd 6:0:17:0: [sds] 4096-byte physical blocks
[ 21.949731] sd 6:0:32:0: [sdag] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.949734] sd 6:0:32:0: [sdag] 4096-byte physical blocks
[ 21.949916] sd 6:0:32:0: Attached scsi generic sg33 type 0
[ 21.951584] sd 6:0:33:0: Attached scsi generic sg34 type 0
[ 21.955474] sd 6:0:34:0: [sdai] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.955477] sd 6:0:34:0: [sdai] 4096-byte physical blocks
[ 21.955708] sd 6:0:34:0: Attached scsi generic sg35 type 0
[ 21.957241] sd 6:0:33:0: [sdah] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.957243] sd 6:0:33:0: [sdah] 4096-byte physical blocks
[ 21.958465] sd 6:0:30:0: [sdae] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.958468] sd 6:0:30:0: [sdae] 4096-byte physical blocks
[ 21.960350] sd 6:0:9:0: [sdk] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.960353] sd 6:0:9:0: [sdk] 4096-byte physical blocks
[ 21.960415] sd 6:0:35:0: [sdaj] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.960418] sd 6:0:35:0: [sdaj] 4096-byte physical blocks
[ 21.970853] sd 6:0:7:0: [sdi] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.970856] sd 6:0:7:0: [sdi] 4096-byte physical blocks
[ 21.974554] sd 6:0:20:0: [sdv] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.974557] sd 6:0:20:0: [sdv] 4096-byte physical blocks
[ 21.998273] sd 6:0:27:0: [sdab] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 21.998275] sd 6:0:27:0: [sdab] 4096-byte physical blocks
[ 22.091735] ses 6:0:24:0: Attached Enclosure device
[ 22.091797] sd 6:0:35:0: Attached scsi generic sg36 type 0
[ 22.094710] sd 6:0:36:0: Attached scsi generic sg37 type 0
[ 22.095898] sd 6:0:36:0: [sdak] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 22.095899] sd 6:0:36:0: [sdak] 4096-byte physical blocks
[ 22.097475] ses 6:0:37:0: Attached Enclosure device
[ 22.097539] ses 6:0:37:0: Attached scsi generic sg38 type 13
[ 22.124835] sd 6:0:5:0: [sdg] Write Protect is off
[ 22.124838] sd 6:0:5:0: [sdg] Mode Sense: 7f 00 10 08
[ 22.127105] sd 6:0:5:0: [sdg] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.131269] sd 6:0:11:0: [sdm] Write Protect is off
[ 22.131272] sd 6:0:11:0: [sdm] Mode Sense: 7f 00 10 08
[ 22.133534] sd 6:0:11:0: [sdm] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.135970] sd 6:0:10:0: [sdl] Write Protect is off
[ 22.135973] sd 6:0:10:0: [sdl] Mode Sense: 7f 00 10 08
[ 22.137501] sd 6:0:13:0: [sdo] Write Protect is off
[ 22.137504] sd 6:0:13:0: [sdo] Mode Sense: 7f 00 10 08
[ 22.137599] sd 6:0:4:0: [sdf] Write Protect is off
[ 22.137601] sd 6:0:4:0: [sdf] Mode Sense: 7f 00 10 08
[ 22.138255] sd 6:0:10:0: [sdl] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.138625] sd 6:0:15:0: [sdq] Write Protect is off
[ 22.138628] sd 6:0:15:0: [sdq] Mode Sense: 7f 00 10 08
[ 22.139778] sd 6:0:12:0: [sdn] Write Protect is off
[ 22.139781] sd 6:0:12:0: [sdn] Mode Sense: 7f 00 10 08
[ 22.139802] sd 6:0:13:0: [sdo] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.139888] sd 6:0:4:0: [sdf] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.140065] sd 6:0:2:0: [sdd] Write Protect is off
[ 22.140067] sd 6:0:2:0: [sdd] Mode Sense: 7f 00 10 08
[ 22.140914] sd 6:0:15:0: [sdq] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.141723] sd 6:0:3:0: [sde] Write Protect is off
[ 22.141726] sd 6:0:3:0: [sde] Mode Sense: 7f 00 10 08
[ 22.142106] sd 6:0:12:0: [sdn] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.142283] sd 6:0:25:0: [sdz] Write Protect is off
[ 22.142286] sd 6:0:25:0: [sdz] Mode Sense: 7f 00 10 08
[ 22.142316] sd 6:0:6:0: [sdh] Write Protect is off
[ 22.142318] sd 6:0:6:0: [sdh] Mode Sense: 7f 00 10 08
[ 22.142362] sd 6:0:2:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.142985] sd 6:0:0:0: [sdb] Write Protect is off
[ 22.142988] sd 6:0:0:0: [sdb] Mode Sense: 7f 00 10 08
[ 22.144022] sd 6:0:3:0: [sde] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.144089] sd 6:0:1:0: [sdc] Write Protect is off
[ 22.144091] sd 6:0:1:0: [sdc] Mode Sense: 7f 00 10 08
[ 22.144572] sd 6:0:25:0: [sdz] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.144635] sd 6:0:6:0: [sdh] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.145284] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.145536] sd 6:0:28:0: [sdac] Write Protect is off
[ 22.145538] sd 6:0:28:0: [sdac] Mode Sense: 7f 00 10 08
[ 22.146405] sd 6:0:1:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.147344] sd 6:0:18:0: [sdt] Write Protect is off
[ 22.147347] sd 6:0:18:0: [sdt] Mode Sense: 7f 00 10 08
[ 22.147829] sd 6:0:28:0: [sdac] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.149625] sd 6:0:18:0: [sdt] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.151340] sd 6:0:22:0: [sdx] Write Protect is off
[ 22.151342] sd 6:0:22:0: [sdx] Mode Sense: 7f 00 10 08
[ 22.151503] sd 6:0:23:0: [sdy] Write Protect is off
[ 22.151504] sd 6:0:23:0: [sdy] Mode Sense: 7f 00 10 08
[ 22.153633] sd 6:0:22:0: [sdx] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.153780] sd 6:0:23:0: [sdy] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.155711] sd 6:0:14:0: [sdp] Write Protect is off
[ 22.155714] sd 6:0:14:0: [sdp] Mode Sense: 7f 00 10 08
[ 22.157858] sd 6:0:26:0: [sdaa] Write Protect is off
[ 22.157859] sd 6:0:26:0: [sdaa] Mode Sense: 7f 00 10 08
[ 22.157997] sd 6:0:14:0: [sdp] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.160223] sd 6:0:26:0: [sdaa] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.162436] sd 6:0:29:0: [sdad] Write Protect is off
[ 22.162437] sd 6:0:29:0: [sdad] Mode Sense: 7f 00 10 08
[ 22.164646] sd 6:0:16:0: [sdr] Write Protect is off
[ 22.164648] sd 6:0:16:0: [sdr] Mode Sense: 7f 00 10 08
[ 22.164716] sd 6:0:29:0: [sdad] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.166923] sd 6:0:16:0: [sdr] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.167330] sd 6:0:32:0: [sdag] Write Protect is off
[ 22.167333] sd 6:0:32:0: [sdag] Mode Sense: 7f 00 10 08
[ 22.168117] sd 6:0:21:0: [sdw] Write Protect is off
[ 22.168119] sd 6:0:21:0: [sdw] Mode Sense: 7f 00 10 08
[ 22.168535] sd 6:0:34:0: [sdai] Write Protect is off
[ 22.168538] sd 6:0:34:0: [sdai] Mode Sense: 7f 00 10 08
[ 22.169607] sd 6:0:32:0: [sdag] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.170000] sd 6:0:31:0: [sdaf] Write Protect is off
[ 22.170001] sd 6:0:31:0: [sdaf] Mode Sense: 7f 00 10 08
[ 22.170402] sd 6:0:21:0: [sdw] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.170818] sd 6:0:34:0: [sdai] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.172293] sd 6:0:31:0: [sdaf] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.172593] sd 6:0:19:0: [sdu] Write Protect is off
[ 22.172595] sd 6:0:19:0: [sdu] Mode Sense: 7f 00 10 08
[ 22.173627] sd 6:0:8:0: [sdj] Write Protect is off
[ 22.173629] sd 6:0:8:0: [sdj] Mode Sense: 7f 00 10 08
[ 22.174873] sd 6:0:19:0: [sdu] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.175919] sd 6:0:8:0: [sdj] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.177121] sd 6:0:30:0: [sdae] Write Protect is off
[ 22.177123] sd 6:0:30:0: [sdae] Mode Sense: 7f 00 10 08
[ 22.179398] sd 6:0:30:0: [sdae] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.181291] sd 6:0:9:0: [sdk] Write Protect is off
[ 22.181294] sd 6:0:9:0: [sdk] Mode Sense: 7f 00 10 08
[ 22.182473] sd 6:0:17:0: [sds] Write Protect is off
[ 22.182475] sd 6:0:17:0: [sds] Mode Sense: 7f 00 10 08
[ 22.183315] sd 6:0:35:0: [sdaj] Write Protect is off
[ 22.183318] sd 6:0:35:0: [sdaj] Mode Sense: 7f 00 10 08
[ 22.183575] sd 6:0:9:0: [sdk] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.184766] sd 6:0:17:0: [sds] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.185577] sd 6:0:35:0: [sdaj] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.188639] sd 6:0:20:0: [sdv] Write Protect is off
[ 22.188641] sd 6:0:20:0: [sdv] Mode Sense: 7f 00 10 08
[ 22.190915] sd 6:0:20:0: [sdv] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.191591] sd 6:0:33:0: [sdah] Write Protect is off
[ 22.191594] sd 6:0:33:0: [sdah] Mode Sense: 7f 00 10 08
[ 22.193866] sd 6:0:33:0: [sdah] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.195900] sd 6:0:7:0: [sdi] Write Protect is off
[ 22.195902] sd 6:0:7:0: [sdi] Mode Sense: 7f 00 10 08
[ 22.198196] sd 6:0:7:0: [sdi] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.223646] sd 6:0:27:0: [sdab] Write Protect is off
[ 22.223648] sd 6:0:27:0: [sdab] Mode Sense: 7f 00 10 08
[ 22.225937] sd 6:0:27:0: [sdab] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.319307] sd 6:0:36:0: [sdak] Write Protect is off
[ 22.319309] sd 6:0:36:0: [sdak] Mode Sense: 7f 00 10 08
[ 22.321562] sd 6:0:36:0: [sdak] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 22.388185] sdg: sdg1 sdg2
[ 22.395867] sdo: sdo1 sdo2
[ 22.397964] sdm: sdm1 sdm2
[ 22.398431] sdl: sdl1 sdl2
[ 22.401415] sdf: sdf1 sdf2
[ 22.403659] sdq: sdq1 sdq2
[ 22.405290] sdd: sdd1 sdd2
[ 22.405517] sdn: sdn1 sdn2
[ 22.405677] sde: sde1 sde2
[ 22.407507] sdac: sdac1 sdac2
[ 22.408275] sdc: sdc1 sdc2
[ 22.408314] sdz: sdz1 sdz2
[ 22.409576] sdb: sdb1 sdb2
[ 22.410581] sdt: sdt1 sdt2
[ 22.412396] sdh: sdh1 sdh2
[ 22.412845] sdx: sdx1 sdx2
[ 22.422152] sdp: sdp1 sdp2
[ 22.425473] sdaa: sdaa1 sdaa2
[ 22.427415] sdad: sdad1 sdad2
[ 22.430891] sdag: sdag1 sdag2
[ 22.431278] sdy: sdy1 sdy2
[ 22.431284] sdr: sdr1 sdr2
[ 22.433380] sdu: sdu1 sdu2
[ 22.434796] sdw: sdw1 sdw2
[ 22.435956] sdai: sdai1 sdai2
[ 22.437765] sdaf: sdaf1 sdaf2
[ 22.438140] sdj: sdj1 sdj2
[ 22.444281] sdae: sdae1 sdae2
[ 22.446351] sdaj: sdaj1 sdaj2
[ 22.447260] sds: sds1 sds2
[ 22.450650] sdk: sdk1 sdk2
[ 22.450684] sdv: sdv1 sdv2
[ 22.455980] sdah: sdah1 sdah2
[ 22.460319] sdi: sdi1 sdi2
[ 22.495461] sdab: sdab1 sdab2
[ 22.587028] sdak: sdak1 sdak2
[ 22.730857] sd 6:0:5:0: [sdg] Attached SCSI disk
[ 22.738535] sd 6:0:13:0: [sdo] Attached SCSI disk
[ 22.740624] sd 6:0:11:0: [sdm] Attached SCSI disk
[ 22.741096] sd 6:0:10:0: [sdl] Attached SCSI disk
[ 22.748145] sd 6:0:12:0: [sdn] Attached SCSI disk
[ 22.748338] sd 6:0:3:0: [sde] Attached SCSI disk
[ 22.750166] sd 6:0:28:0: [sdac] Attached SCSI disk
[ 22.750959] sd 6:0:25:0: [sdz] Attached SCSI disk
[ 22.752187] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 22.752412] sd 6:0:4:0: [sdf] Attached SCSI disk
[ 22.753226] sd 6:0:18:0: [sdt] Attached SCSI disk
[ 22.754664] sd 6:0:15:0: [sdq] Attached SCSI disk
[ 22.755315] sd 6:0:6:0: [sdh] Attached SCSI disk
[ 22.755503] sd 6:0:22:0: [sdx] Attached SCSI disk
[ 22.759298] sd 6:0:1:0: [sdc] Attached SCSI disk
[ 22.764633] sd 6:0:2:0: [sdd] Attached SCSI disk
[ 22.764813] sd 6:0:14:0: [sdp] Attached SCSI disk
[ 22.765825] sd 6:0:23:0: [sdy] Attached SCSI disk
[ 22.768129] sd 6:0:26:0: [sdaa] Attached SCSI disk
[ 22.773556] sd 6:0:32:0: [sdag] Attached SCSI disk
[ 22.773957] sd 6:0:16:0: [sdr] Attached SCSI disk
[ 22.777463] sd 6:0:21:0: [sdw] Attached SCSI disk
[ 22.778431] sd 6:0:29:0: [sdad] Attached SCSI disk
[ 22.778632] sd 6:0:34:0: [sdai] Attached SCSI disk
[ 22.780430] sd 6:0:31:0: [sdaf] Attached SCSI disk
[ 22.784393] sd 6:0:19:0: [sdu] Attached SCSI disk
[ 22.786945] sd 6:0:30:0: [sdae] Attached SCSI disk
[ 22.789034] sd 6:0:35:0: [sdaj] Attached SCSI disk
[ 22.789152] sd 6:0:8:0: [sdj] Attached SCSI disk
[ 22.793322] sd 6:0:9:0: [sdk] Attached SCSI disk
[ 22.793352] sd 6:0:20:0: [sdv] Attached SCSI disk
[ 22.798269] sd 6:0:17:0: [sds] Attached SCSI disk
[ 22.803219] sd 6:0:7:0: [sdi] Attached SCSI disk
[ 22.806971] sd 6:0:33:0: [sdah] Attached SCSI disk
[ 22.838344] sd 6:0:27:0: [sdab] Attached SCSI disk
[ 22.904691] sd 6:0:36:0: [sdak] Attached SCSI disk
[ 56.621216] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[ 56.622522] XFS (dm-61): Mounting V4 Filesystem
[ 56.733802] XFS (dm-61): Starting recovery (logdev: internal)
[ 61.490049] XFS (dm-61): Ending recovery (logdev: internal)
[ 61.698660] XFS (dm-59): Mounting V4 Filesystem
[ 61.821690] XFS (dm-59): Starting recovery (logdev: internal)
[ 62.290871] XFS (dm-59): Ending recovery (logdev: internal)
[ 62.447724] XFS (dm-66): Mounting V4 Filesystem
[ 62.575912] XFS (dm-66): Starting recovery (logdev: internal)
[ 65.577923] XFS (dm-66): Ending recovery (logdev: internal)
[ 65.850605] XFS (dm-72): Mounting V4 Filesystem
[ 65.981820] XFS (dm-72): Starting recovery (logdev: internal)
[ 66.466063] XFS (dm-72): Ending recovery (logdev: internal)
[ 66.636345] XFS (dm-71): Mounting V4 Filesystem
[ 66.732009] XFS (dm-71): Starting recovery (logdev: internal)
[ 67.193518] XFS (dm-71): Ending recovery (logdev: internal)
[ 67.344904] XFS (dm-63): Mounting V4 Filesystem
[ 67.465016] XFS (dm-63): Starting recovery (logdev: internal)
[ 69.050875] XFS (dm-63): Ending recovery (logdev: internal)
[ 69.368403] XFS (dm-68): Mounting V4 Filesystem
[ 69.521547] XFS (dm-68): Starting recovery (logdev: internal)
[ 721.140246] INFO: task tee:70771 blocked for more than 120 seconds.
[ 721.140605] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 721.140957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 721.141406] tee D ffff881fffc530c0 0 70771 70769 0x00000000
[ 721.141411] ffff881ee955bd68 0000000000000086 ffff881ea9d0dbb0 ffff881ee955bfd8
[ 721.141413] 00000000000130c0 00000000000130c0 ffff883fd2da0000 ffff881ea9d0dbb0
[ 721.141415] ffff883fcf2c5868 ffff883fcf2c5880 0000000000000000 ffffffff8122e7b0
[ 721.141417] Call Trace:
[ 721.141429] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 721.141434] [<ffffffff817699f9>] schedule+0x29/0x70
[ 721.141437] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 721.141442] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 721.141444] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 721.141448] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 721.141451] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 721.141456] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 721.141461] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 721.141463] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 721.141467] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 721.141469] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 721.141471] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 721.141474] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 841.188901] INFO: task tee:70771 blocked for more than 120 seconds.
[ 841.189257] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 841.189612] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 841.190062] tee D ffff881fffc530c0 0 70771 70769 0x00000000
[ 841.190067] ffff881ee955bd68 0000000000000086 ffff881ea9d0dbb0 ffff881ee955bfd8
[ 841.190069] 00000000000130c0 00000000000130c0 ffff883fd2da0000 ffff881ea9d0dbb0
[ 841.190071] ffff883fcf2c5868 ffff883fcf2c5880 0000000000000000 ffffffff8122e7b0
[ 841.190073] Call Trace:
[ 841.190096] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 841.190100] [<ffffffff817699f9>] schedule+0x29/0x70
[ 841.190103] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 841.190107] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 841.190110] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 841.190114] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 841.190116] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 841.190121] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 841.190125] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 841.190127] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 841.190131] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 841.190133] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 841.190136] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 841.190138] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 961.241559] INFO: task tee:70771 blocked for more than 120 seconds.
[ 961.241935] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 961.242288] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 961.242748] tee D ffff881fffc530c0 0 70771 70769 0x00000000
[ 961.242752] ffff881ee955bd68 0000000000000086 ffff881ea9d0dbb0 ffff881ee955bfd8
[ 961.242755] 00000000000130c0 00000000000130c0 ffff883fd2da0000 ffff881ea9d0dbb0
[ 961.242757] ffff883fcf2c5868 ffff883fcf2c5880 0000000000000000 ffffffff8122e7b0
[ 961.242759] Call Trace:
[ 961.242770] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 961.242776] [<ffffffff817699f9>] schedule+0x29/0x70
[ 961.242779] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 961.242784] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 961.242787] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 961.242791] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 961.242794] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 961.242799] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 961.242804] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 961.242806] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 961.242811] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 961.242813] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 961.242815] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 961.242818] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 1081.290049] INFO: task tee:70771 blocked for more than 120 seconds.
[ 1081.290487] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 1081.290846] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1081.291306] tee D ffff881fffc530c0 0 70771 70769 0x00000000
[ 1081.291310] ffff881ee955bd68 0000000000000086 ffff881ea9d0dbb0 ffff881ee955bfd8
[ 1081.291312] 00000000000130c0 00000000000130c0 ffff883fd2da0000 ffff881ea9d0dbb0
[ 1081.291315] ffff883fcf2c5868 ffff883fcf2c5880 0000000000000000 ffffffff8122e7b0
[ 1081.291317] Call Trace:
[ 1081.291327] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 1081.291332] [<ffffffff817699f9>] schedule+0x29/0x70
[ 1081.291335] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 1081.291339] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 1081.291341] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 1081.291345] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 1081.291347] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 1081.291352] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 1081.291357] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 1081.291359] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 1081.291363] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 1081.291365] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 1081.291367] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 1081.291370] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 1201.338928] INFO: task tee:70771 blocked for more than 120 seconds.
[ 1201.339342] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 1201.339696] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1201.340153] tee D ffff881fffc530c0 0 70771 70769 0x00000000
[ 1201.340158] ffff881ee955bd68 0000000000000086 ffff881ea9d0dbb0 ffff881ee955bfd8
[ 1201.340160] 00000000000130c0 00000000000130c0 ffff883fd2da0000 ffff881ea9d0dbb0
[ 1201.340162] ffff883fcf2c5868 ffff883fcf2c5880 0000000000000000 ffffffff8122e7b0
[ 1201.340165] Call Trace:
[ 1201.340176] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 1201.340181] [<ffffffff817699f9>] schedule+0x29/0x70
[ 1201.340184] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 1201.340189] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 1201.340191] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 1201.340196] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 1201.340198] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 1201.340203] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 1201.340208] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 1201.340210] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 1201.340215] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 1201.340217] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 1201.340219] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 1201.340222] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 1295.677333] XFS (dm-68): Ending recovery (logdev: internal)
[ 1296.095228] tee (70771): drop_caches: 3
[ 1296.095246] tee (216145): drop_caches: 3
[ 1296.095963] XFS (dm-64): Mounting V4 Filesystem
[ 1296.218229] XFS (dm-64): Starting recovery (logdev: internal)
[ 1296.608759] XFS (dm-64): Ending recovery (logdev: internal)
[ 1345.167186] XFS (dm-57): Mounting V4 Filesystem
[ 1345.449771] XFS (dm-57): Starting recovery (logdev: internal)
[ 1345.924941] XFS (dm-57): Ending recovery (logdev: internal)
[ 1346.099306] XFS (dm-54): Mounting V4 Filesystem
[ 1346.354555] XFS (dm-54): Starting recovery (logdev: internal)
[ 1349.216095] XFS (dm-54): Ending recovery (logdev: internal)
[ 1349.452830] XFS (dm-53): Mounting V4 Filesystem
[ 1349.614009] XFS (dm-53): Starting recovery (logdev: internal)
[ 1350.026321] XFS (dm-53): Ending recovery (logdev: internal)
[ 1350.194852] XFS (dm-51): Mounting V4 Filesystem
[ 1350.454414] XFS (dm-51): Starting recovery (logdev: internal)
[ 1353.072703] XFS (dm-51): Ending recovery (logdev: internal)
[ 1353.376491] XFS (dm-49): Mounting V4 Filesystem
[ 1353.517889] XFS (dm-49): Starting recovery (logdev: internal)
[ 1921.636750] INFO: task tee:388250 blocked for more than 120 seconds.
[ 1921.637110] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 1921.637473] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1921.637922] tee D ffff881fffcf30c0 0 388250 388246 0x00000000
[ 1921.637926] ffff881c5113bd68 0000000000000082 ffff883fc00fbd20 ffff881c5113bfd8
[ 1921.637928] 00000000000130c0 00000000000130c0 ffff883fd2da7010 ffff883fc00fbd20
[ 1921.637930] ffff883e02c6a068 ffff883e02c6a080 0000000000000000 ffffffff8122e7b0
[ 1921.637932] Call Trace:
[ 1921.637944] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 1921.637949] [<ffffffff817699f9>] schedule+0x29/0x70
[ 1921.637952] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 1921.637957] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 1921.637959] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 1921.637963] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 1921.637965] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 1921.637971] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 1921.637976] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 1921.637978] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 1921.637981] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 1921.637983] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 1921.637986] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 1921.638000] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 2041.693409] INFO: task tee:388250 blocked for more than 120 seconds.
[ 2041.693767] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 2041.704023] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2041.724782] tee D ffff881fffcf30c0 0 388250 388246 0x00000000
[ 2041.724788] ffff881c5113bd68 0000000000000082 ffff883fc00fbd20 ffff881c5113bfd8
[ 2041.724790] 00000000000130c0 00000000000130c0 ffff883fd2da7010 ffff883fc00fbd20
[ 2041.724792] ffff883e02c6a068 ffff883e02c6a080 0000000000000000 ffffffff8122e7b0
[ 2041.724794] Call Trace:
[ 2041.724815] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 2041.724820] [<ffffffff817699f9>] schedule+0x29/0x70
[ 2041.724828] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 2041.724833] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 2041.724835] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 2041.724839] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 2041.724841] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 2041.724846] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 2041.724854] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 2041.724868] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 2041.724872] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 2041.724874] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 2041.724877] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 2041.724880] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 2111.997767] XFS (dm-49): Ending recovery (logdev: internal)
[ 2113.180445] tee (388250): drop_caches: 3
[ 2128.718409] XFS (dm-47): Mounting V4 Filesystem
[ 2128.856539] XFS (dm-47): Starting recovery (logdev: internal)
[ 2129.326787] XFS (dm-47): Ending recovery (logdev: internal)
[ 2129.499172] XFS (dm-44): Mounting V4 Filesystem
[ 2129.758764] XFS (dm-44): Starting recovery (logdev: internal)
[ 2132.099984] XFS (dm-44): Ending recovery (logdev: internal)
[ 2132.286678] XFS (dm-43): Mounting V4 Filesystem
[ 2132.515828] XFS (dm-43): Starting recovery (logdev: internal)
[ 2136.015377] XFS (dm-43): Ending recovery (logdev: internal)
[ 2136.189762] XFS (dm-40): Mounting V4 Filesystem
[ 2136.462118] XFS (dm-40): Starting recovery (logdev: internal)
[ 2136.939301] XFS (dm-40): Ending recovery (logdev: internal)
[ 2137.106975] XFS (dm-38): Mounting V4 Filesystem
[ 2137.365241] XFS (dm-38): Starting recovery (logdev: internal)
[ 2137.835315] XFS (dm-38): Ending recovery (logdev: internal)
[ 2138.008335] XFS (dm-37): Mounting V4 Filesystem
[ 2138.252340] XFS (dm-37): Starting recovery (logdev: internal)
[ 2138.753540] XFS (dm-37): Ending recovery (logdev: internal)
[ 2138.970629] XFS (dm-34): Mounting V4 Filesystem
[ 2139.226506] XFS (dm-34): Starting recovery (logdev: internal)
[ 2142.103640] XFS (dm-34): Ending recovery (logdev: internal)
[ 2142.534629] XFS (dm-32): Mounting V4 Filesystem
[ 2142.674816] XFS (dm-32): Starting recovery (logdev: internal)
[ 2143.143217] XFS (dm-32): Ending recovery (logdev: internal)
[ 2189.949661] XFS (dm-30): Mounting V4 Filesystem
[ 2190.181668] XFS (dm-30): Starting recovery (logdev: internal)
[ 2190.661827] XFS (dm-30): Ending recovery (logdev: internal)
[ 2190.812172] XFS (dm-28): Mounting V4 Filesystem
[ 2191.070115] XFS (dm-28): Starting recovery (logdev: internal)
[ 2191.533728] XFS (dm-28): Ending recovery (logdev: internal)
[ 2191.687714] XFS (dm-26): Mounting V4 Filesystem
[ 2191.952642] XFS (dm-26): Starting recovery (logdev: internal)
[ 2194.707046] XFS (dm-26): Ending recovery (logdev: internal)
[ 2194.941289] XFS (dm-24): Mounting V4 Filesystem
[ 2195.124028] XFS (dm-24): Starting recovery (logdev: internal)
[ 2197.782500] XFS (dm-24): Ending recovery (logdev: internal)
[ 2197.972019] XFS (dm-22): Mounting V4 Filesystem
[ 2198.233392] XFS (dm-22): Starting recovery (logdev: internal)
[ 2200.631218] XFS (dm-22): Ending recovery (logdev: internal)
[ 2200.838276] XFS (dm-20): Mounting V4 Filesystem
[ 2201.072481] XFS (dm-20): Starting recovery (logdev: internal)
[ 2204.817633] XFS (dm-20): Ending recovery (logdev: internal)
[ 2205.059311] XFS (dm-18): Mounting V4 Filesystem
[ 2205.306003] XFS (dm-18): Starting recovery (logdev: internal)
[ 2205.798469] XFS (dm-18): Ending recovery (logdev: internal)
[ 2205.972939] XFS (dm-17): Mounting V4 Filesystem
[ 2206.226333] XFS (dm-17): Starting recovery (logdev: internal)
[ 2207.927508] XFS (dm-17): Ending recovery (logdev: internal)
[ 2208.264016] XFS (dm-15): Mounting V4 Filesystem
[ 2208.406496] XFS (dm-15): Starting recovery (logdev: internal)
[ 2521.922690] INFO: task tee:598448 blocked for more than 120 seconds.
[ 2521.933436] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 2521.946143] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2521.971978] tee D ffff88407fd330c0 0 598448 598445 0x00000000
[ 2521.971990] ffff881dc495fd68 0000000000000086 ffff883e8d61bd20 ffff881dc495ffd8
[ 2521.971993] 00000000000130c0 00000000000130c0 ffff883fd2f14750 ffff883e8d61bd20
[ 2521.971995] ffff883efec4c068 ffff883efec4c080 0000000000000000 ffffffff8122e7b0
[ 2521.971998] Call Trace:
[ 2521.972011] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 2521.972044] [<ffffffff817699f9>] schedule+0x29/0x70
[ 2521.972052] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 2521.972057] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 2521.972060] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 2521.972065] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 2521.972071] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 2521.972077] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 2521.972081] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 2521.972084] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 2521.972089] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 2521.972092] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 2521.972095] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 2521.972098] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 2642.024997] INFO: task tee:598448 blocked for more than 120 seconds.
[ 2642.035811] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 2642.046465] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2642.067494] tee D ffff88407fd330c0 0 598448 598445 0x00000000
[ 2642.067501] ffff881dc495fd68 0000000000000086 ffff883e8d61bd20 ffff881dc495ffd8
[ 2642.067507] 00000000000130c0 00000000000130c0 ffff883fd2f14750 ffff883e8d61bd20
[ 2642.067509] ffff883efec4c068 ffff883efec4c080 0000000000000000 ffffffff8122e7b0
[ 2642.067513] Call Trace:
[ 2642.067524] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 2642.067529] [<ffffffff817699f9>] schedule+0x29/0x70
[ 2642.067532] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 2642.067537] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 2642.067538] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 2642.067543] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 2642.067545] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 2642.067550] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 2642.067554] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 2642.067557] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 2642.067561] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 2642.067563] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 2642.067567] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 2642.067570] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 2762.121492] INFO: task tee:598448 blocked for more than 120 seconds.
[ 2762.132150] Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[ 2762.142801] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2762.164331] tee D ffff88407fd330c0 0 598448 598445 0x00000000
[ 2762.164336] ffff881dc495fd68 0000000000000086 ffff883e8d61bd20 ffff881dc495ffd8
[ 2762.164338] 00000000000130c0 00000000000130c0 ffff883fd2f14750 ffff883e8d61bd20
[ 2762.164340] ffff883efec4c068 ffff883efec4c080 0000000000000000 ffffffff8122e7b0
[ 2762.164342] Call Trace:
[ 2762.164355] [<ffffffff8122e7b0>] ? do_coredump+0xe60/0xe60
[ 2762.164364] [<ffffffff817699f9>] schedule+0x29/0x70
[ 2762.164369] [<ffffffff8176ca35>] rwsem_down_read_failed+0xf5/0x150
[ 2762.164374] [<ffffffff813944e4>] call_rwsem_down_read_failed+0x14/0x30
[ 2762.164379] [<ffffffff8176c090>] ? down_read+0x20/0x30
[ 2762.164385] [<ffffffff811d7c9c>] iterate_supers+0x9c/0x110
[ 2762.164388] [<ffffffff8122e906>] drop_caches_sysctl_handler+0x66/0x110
[ 2762.164393] [<ffffffff8132b0aa>] ? common_file_perm+0x4a/0x100
[ 2762.164397] [<ffffffff81242a23>] proc_sys_call_handler+0xb3/0xc0
[ 2762.164399] [<ffffffff81242a44>] proc_sys_write+0x14/0x20
[ 2762.164403] [<ffffffff811d4537>] vfs_write+0xb7/0x1f0
[ 2762.164405] [<ffffffff811d4401>] ? vfs_read+0xf1/0x170
[ 2762.164408] [<ffffffff811d50d6>] SyS_write+0x46/0xb0
[ 2762.164410] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[ 3078.845382] perf interrupt took too long (2514 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 3258.588758] XFS (dm-15): Ending recovery (logdev: internal)
[ 3261.209349] tee (598448): drop_caches: 3
[ 3261.209352] tee (808166): drop_caches: 3
[ 3298.764833] XFS (dm-13): Mounting V4 Filesystem
[ 3298.890777] XFS (dm-13): Starting recovery (logdev: internal)
[ 3299.372620] XFS (dm-13): Ending recovery (logdev: internal)
[ 3299.548459] XFS (dm-11): Mounting V4 Filesystem
[ 3299.791252] XFS (dm-11): Starting recovery (logdev: internal)
[ 3300.264293] XFS (dm-11): Ending recovery (logdev: internal)
[ 3300.581608] XFS (dm-8): Mounting V4 Filesystem
[ 3300.691550] XFS (dm-8): Starting recovery (logdev: internal)
[ 3301.170408] XFS (dm-8): Ending recovery (logdev: internal)
[ 3301.334980] XFS (dm-6): Mounting V4 Filesystem
[ 3301.566898] XFS (dm-6): Starting recovery (logdev: internal)
[ 3302.042037] XFS (dm-6): Ending recovery (logdev: internal)
[ 3302.341451] XFS (dm-4): Mounting V4 Filesystem
[ 3302.473908] XFS (dm-4): Starting recovery (logdev: internal)
[ 3302.923993] XFS (dm-4): Ending recovery (logdev: internal)
[ 3303.113509] XFS (dm-2): Mounting V4 Filesystem
[ 3303.354289] XFS (dm-2): Starting recovery (logdev: internal)
[ 3303.848719] XFS (dm-2): Ending recovery (logdev: internal)
[ 3569.863994] tee (918866): drop_caches: 3
[ 4197.520528] tee (977656): drop_caches: 3
[ 4764.058344] tee (986318): drop_caches: 3
[ 5398.549891] tee (998245): drop_caches: 3
[ 6124.259135] perf interrupt took too long (5019 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 6454.374420] tee (1008894): drop_caches: 3
[ 6600.794372] tee (1011430): drop_caches: 3
[ 7720.074069] tee (1020534): drop_caches: 3
[ 8166.864898] tee (1031038): drop_caches: 3
[ 8401.014879] tee (1036442): drop_caches: 3
[ 9235.670987] tee (1054602): drop_caches: 3
[ 9728.092318] tee (1062082): drop_caches: 3
[10310.482713] tee (1070434): drop_caches: 3
[11019.812693] tee (1073496): drop_caches: 3
[11569.260159] tee (1075052): drop_caches: 3
[12131.772631] tee (1076669): drop_caches: 3
[12665.019843] tee (1077949): drop_caches: 3
[13283.719785] tee (1079510): drop_caches: 3
[13923.447977] tee (1082164): drop_caches: 3
[14526.849858] tee (1084374): drop_caches: 3
[15210.154568] tee (1087578): drop_caches: 3
[15792.637972] tee (1089754): drop_caches: 3
[16363.897246] tee (1092185): drop_caches: 3
[16899.765822] tee (1094500): drop_caches: 3
[17718.637630] tee (1097176): drop_caches: 3
[18226.886416] tee (1098681): drop_caches: 3
[18600.982322] tee (1100092): drop_caches: 3
[19227.717330] tee (1103500): drop_caches: 3
[19733.474887] tee (1105126): drop_caches: 3
[20051.125104] systemd-timedated[1106893]: /etc/localtime should be a symbolic link to a timezone data file in /usr/share/zoneinfo/.
[20051.965705] nr_pdflush_threads exported in /proc is scheduled for removal
[20051.965819] sysctl: The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case. If you have one, please send an email to linux-mm@kvack.org.
[20337.294520] tee (1109446): drop_caches: 3
[20734.970982] init: irqbalance main process (1828) killed by TERM signal
[20736.177506] systemd-timedated[1112556]: /etc/localtime should be a symbolic link to a timezone data file in /usr/share/zoneinfo/.
[20931.451505] tee (1113838): drop_caches: 3
[21530.483224] tee (1123799): drop_caches: 3
[22130.168506] tee (1129379): drop_caches: 3
[23354.694195] tee (1135493): drop_caches: 3
[24143.600510] tee (1137931): drop_caches: 3
[27446.862440] tee (1145980): drop_caches: 3
[27446.881105] tee (1145950): drop_caches: 3
[27446.881110] tee (1145974): drop_caches: 3
[27446.881111] tee (1145971): drop_caches: 3
[28875.069745] tee (1148738): drop_caches: 3
[28875.069932] tee (1148744): drop_caches: 3
[29105.936533] tee (1149529): drop_caches: 3
[29428.925390] tee (1150183): drop_caches: 3
[29428.925396] tee (1150177): drop_caches: 3
[30164.280074] tee (1151809): drop_caches: 3
[30164.280163] tee (1151803): drop_caches: 3
[30674.817297] tee (1153036): drop_caches: 3
[31220.758241] tee (1153881): drop_caches: 3
[31813.527045] tee (1155415): drop_caches: 3
[32421.516347] tee (1157261): drop_caches: 3
[32969.935935] tee (1158411): drop_caches: 3
[33592.833641] tee (1160752): drop_caches: 3
[34196.314416] tee (1162675): drop_caches: 3
[34803.597999] tee (1165403): drop_caches: 3
[35369.270049] tee (1167516): drop_caches: 3
[35977.918512] tee (1169871): drop_caches: 3
[36572.977812] tee (1171955): drop_caches: 3
[37173.347066] tee (1175032): drop_caches: 3
[37778.468303] tee (1177411): drop_caches: 3
[38368.247153] tee (1180055): drop_caches: 3
[38967.690231] tee (1182480): drop_caches: 3
[39576.718316] tee (1185841): drop_caches: 3
[40161.823417] tee (1187814): drop_caches: 3
[40754.352070] tee (1190522): drop_caches: 3
[41375.997025] tee (1193969): drop_caches: 3
[42029.971545] tee (1196611): drop_caches: 3
[42657.755386] tee (1200361): drop_caches: 3
[43226.805439] tee (1203342): drop_caches: 3
[43879.183547] tee (1204641): drop_caches: 3
[44410.960591] tee (1206188): drop_caches: 3
[45002.159191] tee (1207979): drop_caches: 3
[45581.857589] tee (1209565): drop_caches: 3
[46229.789539] tee (1211461): drop_caches: 3
[46854.736325] tee (1214458): drop_caches: 3
[47453.451773] tee (1217266): drop_caches: 3
[48021.528533] tee (1219073): drop_caches: 3
[48674.314752] tee (1220761): drop_caches: 3
[49241.083673] tee (1222519): drop_caches: 3
[49828.102661] tee (1223972): drop_caches: 3
[50454.485129] tee (1226206): drop_caches: 3
[51015.351316] tee (1227619): drop_caches: 3
[51605.815200] tee (1229197): drop_caches: 3
[52250.428243] tee (1231104): drop_caches: 3
[52767.917931] tee (1232250): drop_caches: 3
[53380.236348] tee (1233732): drop_caches: 3
[53994.341503] tee (1236623): drop_caches: 3
[54576.236440] tee (1238899): drop_caches: 3
[55163.174383] tee (1240912): drop_caches: 3
[55775.711804] tee (1243908): drop_caches: 3
[56372.421290] tee (1247786): drop_caches: 3
[56967.499797] tee (1250937): drop_caches: 3
[57576.641171] tee (1253490): drop_caches: 3
[58178.261951] tee (1256717): drop_caches: 3
[58772.800885] tee (1259138): drop_caches: 3
[59381.020810] tee (1262219): drop_caches: 3
[59983.063180] tee (1264761): drop_caches: 3
[60582.942003] tee (1268674): drop_caches: 3
[61165.476536] tee (1271469): drop_caches: 3
[61768.312884] tee (1273793): drop_caches: 3
[62367.405710] tee (1277230): drop_caches: 3
[62949.808282] tee (1278777): drop_caches: 3
[63551.851679] tee (1282173): drop_caches: 3
[64202.976852] tee (1288577): drop_caches: 3
[64794.632517] tee (1293108): drop_caches: 3
[65376.626445] tee (1294602): drop_caches: 3
[66000.891998] tee (1295711): drop_caches: 3
[66584.735868] tee (1297079): drop_caches: 3
[67187.296954] tee (1298312): drop_caches: 3
[67792.331228] tee (1299714): drop_caches: 3
[68395.482799] tee (1301103): drop_caches: 3
[68989.769885] tee (1302401): drop_caches: 3
[69601.511261] tee (1303927): drop_caches: 3
[70219.442302] tee (1305482): drop_caches: 3
[70795.342500] tee (1306562): drop_caches: 3
[71395.584676] tee (1307817): drop_caches: 3
[72005.783042] tee (1309491): drop_caches: 3
[72677.845695] tee (1310819): drop_caches: 3
[73288.315871] tee (1312544): drop_caches: 3
[74065.278675] tee (1314262): drop_caches: 3
[74496.288391] tee (1315085): drop_caches: 3
[75080.147296] tee (1316151): drop_caches: 3
[75708.893873] tee (1317308): drop_caches: 3
[76315.093180] tee (1318531): drop_caches: 3
[77197.403553] tee (1320531): drop_caches: 3
[77773.719512] tee (1321639): drop_caches: 3
[78384.525427] tee (1322635): drop_caches: 3
[79406.513926] tee (1324297): drop_caches: 3
[79742.225287] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[79742.246394] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[79742.257410] PGD 3f4e799067 PUD 3f4e798067 PMD 0
[79742.268099] Oops: 0000 [#1] SMP
[79742.278624] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[79742.355559] CPU: 13 PID: 555376 Comm: ceph-osd Not tainted 3.16.0-38-generic #52~14.04.1-Ubuntu
[79742.377306] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[79742.399563] task: ffff883f69779e90 ti: ffff881d4af1c000 task.ti: ffff881d4af1c000
[79742.421855] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[79742.444715] RSP: 0000:ffff881d4af1fcf0 EFLAGS: 00010282
[79742.456066] RAX: 0000000000000000 RBX: ffff881ea0c049f8 RCX: 0000000000000001
[79742.467964] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881d4af1fca8
[79742.479624] RBP: ffff881d4af1fd10 R08: 0000000000000001 R09: ffff881d4af1fb90
[79742.490856] R10: ffff881d4af1fc20 R11: 0000000000000001 R12: ffff881d4af1fd40
[79742.501534] R13: 0000000000000003 R14: 0000000000000003 R15: 0000000034243792
[79742.512182] FS: 00007ff807456700(0000) GS:ffff881fffce0000(0000) knlGS:0000000000000000
[79742.533375] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[79742.543875] CR2: 0000000000000098 CR3: 0000003f5fa5a000 CR4: 00000000001407e0
[79742.554501] Stack:
[79742.564663] ffffffffc05132b0 ffff881d4af1fdc0 ffff881d4af1fdc0 ffff881cafc19000
[79742.585528] ffff881d4af1fd80 ffffffffc0495e7b 0000000200000008 ffff881e9e284010
[79742.606763] 00000000c3cf97a8 ffff881fcf6cc300 0000000000000000 0000000000000000
[79742.627996] Call Trace:
[79742.638398] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[79742.648914] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[79742.659228] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[79742.669189] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[79742.678895] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[79742.688717] [<ffffffff811ef204>] evict+0xb4/0x180
[79742.699094] [<ffffffff811ef9e5>] iput+0xf5/0x180
[79742.708338] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[79742.717201] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[79742.726070] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[79742.734489] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[79742.742817] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[79742.768671] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[79742.777452] RSP <ffff881d4af1fcf0>
[79742.786483] CR2: 0000000000000098
[79742.807830] ---[ end trace 5a50666514df0dc6 ]---
[79745.531641] [sched_delayed] sched: RT throttling activated
[79925.614734] init: ceph-osd (ceph/656) main process (553577) killed by ABRT signal
[79925.638877] init: ceph-osd (ceph/656) main process ended, respawning
[80544.264601] tee (1325821): drop_caches: 3
[80544.309160] tee (1331375): drop_caches: 3
[81117.472860] tee (1331707): drop_caches: 3
[81538.365246] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[81538.381876] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[81538.389767] PGD 1e9e6f9067 PUD 1ea0d20067 PMD 0
[81538.398001] Oops: 0000 [#2] SMP
[81538.405955] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[81538.469310] CPU: 15 PID: 262524 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[81538.489019] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[81538.508994] task: ffff883d8ab07010 ti: ffff883c6228c000 task.ti: ffff883c6228c000
[81538.529357] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[81538.549793] RSP: 0018:ffff883c6228fcf0 EFLAGS: 00010282
[81538.560414] RAX: 0000000000000000 RBX: ffff8819d1986cb0 RCX: 0000000000000001
[81538.571366] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff883c6228fca8
[81538.582172] RBP: ffff883c6228fd10 R08: 0000000000000001 R09: ffff883c6228fb90
[81538.593355] R10: ffff883c6228fc20 R11: 0000000000000001 R12: ffff883c6228fd40
[81538.605460] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000087e5f03c
[81538.615595] FS: 00007f324e613700(0000) GS:ffff881fffd20000(0000) knlGS:0000000000000000
[81538.635499] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[81538.645892] CR2: 0000000000000098 CR3: 0000001ea2325000 CR4: 00000000001407e0
[81538.656462] Stack:
[81538.666718] ffffffffc05132b0 ffff883c6228fdc0 ffff883c6228fdc0 ffff881306a4ac00
[81538.687218] ffff883c6228fd80 ffffffffc0495e7b 0000000200000008 ffff881fd1779010
[81538.708121] 00000000e474f3a8 ffff881d24d14300 0000000000000000 0000000000000000
[81538.729415] Call Trace:
[81538.739600] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[81538.750043] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[81538.760312] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[81538.770399] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[81538.780228] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[81538.789823] [<ffffffff811ef204>] evict+0xb4/0x180
[81538.799234] [<ffffffff811ef9e5>] iput+0xf5/0x180
[81538.808293] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[81538.817428] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[81538.827088] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[81538.835703] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[81538.845298] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[81538.876589] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[81538.887399] RSP <ffff883c6228fcf0>
[81538.897823] CR2: 0000000000000098
[81538.921701] ---[ end trace 5a50666514df0dc7 ]---
[81681.593367] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[81681.610839] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[81681.619753] PGD 1f072d5067 PUD 1f072d7067 PMD 0
[81681.628388] Oops: 0000 [#3] SMP
[81681.637009] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[81681.699520] CPU: 8 PID: 869878 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[81681.717780] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[81681.736931] task: ffff883da23f8000 ti: ffff88368fc24000 task.ti: ffff88368fc24000
[81681.756772] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[81681.778471] RSP: 0000:ffff88368fc27cf0 EFLAGS: 00010286
[81681.789290] RAX: 0000000000000000 RBX: ffff881dabb33960 RCX: 0000000000000001
[81681.800082] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88368fc27ca8
[81681.810961] RBP: ffff88368fc27d10 R08: 0000000000000001 R09: ffff88368fc27b90
[81681.821396] R10: ffff88368fc27c20 R11: 0000000000000001 R12: ffff88368fc27d40
[81681.831736] R13: 0000000000000001 R14: 0000000000000001 R15: 000000007372227d
[81681.841905] FS: 00007f8ed02e6700(0000) GS:ffff88407fc40000(0000) knlGS:0000000000000000
[81681.862044] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[81681.872534] CR2: 0000000000000098 CR3: 0000001fd11af000 CR4: 00000000001407e0
[81681.882890] Stack:
[81681.892988] ffffffffc05132b0 ffff88368fc27dc0 ffff88368fc27dc0 ffff883da34a9c00
[81681.913540] ffff88368fc27d80 ffffffffc0495e7b 0000000200000008 ffff883fc02e9010
[81681.934514] 0000000105212a98 ffff883e84536a00 0000000000000000 0000000000000000
[81681.955645] Call Trace:
[81681.965768] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[81681.976728] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[81681.986941] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[81681.996842] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[81682.007457] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[81682.017562] [<ffffffff811ef204>] evict+0xb4/0x180
[81682.028530] [<ffffffff811ef9e5>] iput+0xf5/0x180
[81682.039431] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[81682.050008] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[81682.060588] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[81682.068867] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[81682.077241] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[81682.103326] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[81682.112285] RSP <ffff88368fc27cf0>
[81682.120996] CR2: 0000000000000098
[81682.129873] ---[ end trace 5a50666514df0dc8 ]---
[81720.277749] init: ceph-osd (ceph/496) main process (260966) killed by ABRT signal
[81720.295890] init: ceph-osd (ceph/496) main process ended, respawning
[81864.285324] init: ceph-osd (ceph/560) main process (868857) killed by ABRT signal
[81864.302595] init: ceph-osd (ceph/560) main process ended, respawning
[82026.346821] tee (1333267): drop_caches: 3
[82506.438263] tee (1340825): drop_caches: 3
[82560.755590] tee (1340827): drop_caches: 3
[83248.992469] tee (1344240): drop_caches: 3
[85240.825815] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[85240.842332] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85240.851665] PGD 1ec4aee067 PUD 1ebfb93067 PMD 0
[85240.859971] Oops: 0000 [#4] SMP
[85240.868463] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[85240.932763] CPU: 14 PID: 276354 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[85240.951757] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[85240.971278] task: ffff883fbcd5b2f0 ti: ffff883cc5554000 task.ti: ffff883cc5554000
[85240.991134] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85241.011618] RSP: 0000:ffff883cc5557cf0 EFLAGS: 00010282
[85241.022011] RAX: 0000000000000000 RBX: ffff88186f284570 RCX: 0000000000000001
[85241.032223] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff883cc5557ca8
[85241.042492] RBP: ffff883cc5557d10 R08: 0000000000000001 R09: ffff883cc5557b90
[85241.052795] R10: ffff883cc5557c20 R11: 0000000000000001 R12: ffff883cc5557d40
[85241.062626] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000044ce83ee
[85241.072263] FS: 00007ff91dbfb700(0000) GS:ffff881fffd00000(0000) knlGS:0000000000000000
[85241.092335] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[85241.103491] CR2: 0000000000000098 CR3: 0000001ebf8fd000 CR4: 00000000001407e0
[85241.114190] Stack:
[85241.125561] ffffffffc05132b0 ffff883cc5557dc0 ffff883cc5557dc0 ffff882775ca2800
[85241.146914] ffff883cc5557d80 ffffffffc0495e7b 0000000200000008 ffff881f74194010
[85241.168092] 0000000125beb638 ffff881f517e1380 0000000000000000 0000000000000000
[85241.189210] Call Trace:
[85241.199585] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[85241.209847] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[85241.220215] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[85241.230112] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[85241.239883] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[85241.249807] [<ffffffff811ef204>] evict+0xb4/0x180
[85241.259304] [<ffffffff811ef9e5>] iput+0xf5/0x180
[85241.268426] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[85241.277375] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[85241.286097] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[85241.294519] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[85241.302748] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[85241.329723] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85241.338717] RSP <ffff883cc5557cf0>
[85241.348726] CR2: 0000000000000098
[85241.375128] ---[ end trace 5a50666514df0dc9 ]---
[85425.665686] init: ceph-osd (ceph/638) main process (275050) killed by ABRT signal
[85425.684910] init: ceph-osd (ceph/638) main process ended, respawning
[85527.649569] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[85527.670856] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85527.681461] PGD 19d07ee067 PUD 1ce15a4067 PMD 0
[85527.691880] Oops: 0000 [#5] SMP
[85527.702262] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[85527.779803] CPU: 7 PID: 871186 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[85527.801176] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[85527.821365] task: ffff883f6cd8c750 ti: ffff883509100000 task.ti: ffff883509100000
[85527.842326] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85527.863923] RSP: 0018:ffff883509103cf0 EFLAGS: 00010282
[85527.874884] RAX: 0000000000000000 RBX: ffff883f3a6449f8 RCX: 0000000000000001
[85527.886416] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff883509103ca8
[85527.897140] RBP: ffff883509103d10 R08: 0000000000000001 R09: ffff883509103b90
[85527.907720] R10: ffff883509103c20 R11: 0000000000000001 R12: ffff883509103d40
[85527.918403] R13: 0000000000000002 R14: 0000000000000002 R15: 00000000002bc354
[85527.929679] FS: 00007f36a1558700(0000) GS:ffff88407fc20000(0000) knlGS:0000000000000000
[85527.950614] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[85527.961070] CR2: 0000000000000098 CR3: 000000174be01000 CR4: 00000000001407e0
[85527.971694] Stack:
[85527.981785] ffffffffc05132b0 ffff883509103dc0 ffff883509103dc0 ffff883a49c16800
[85528.002410] ffff883509103d80 ffffffffc0495e7b 0000000200000008 ffff8836f1fb3010
[85528.023519] 000000006cc9eb18 ffff88378cb7c780 0000000000000000 0000000000000000
[85528.044624] Call Trace:
[85528.054956] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[85528.065323] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[85528.075571] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[85528.085552] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[85528.095234] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[85528.105102] [<ffffffff811ef204>] evict+0xb4/0x180
[85528.115567] [<ffffffff811ef9e5>] iput+0xf5/0x180
[85528.124702] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[85528.133800] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[85528.142441] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[85528.150940] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[85528.159074] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[85528.185579] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85528.194318] RSP <ffff883509103cf0>
[85528.203427] CR2: 0000000000000098
[85528.212765] ---[ end trace 5a50666514df0dca ]---
[85656.105997] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[85656.124969] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85656.133895] PGD 3ed9bc4067 PUD 3f03141067 PMD 0
[85656.142690] Oops: 0000 [#6] SMP
[85656.151175] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[85656.213819] CPU: 19 PID: 531402 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[85656.232298] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[85656.251344] task: ffff883e8d619e90 ti: ffff881cfe304000 task.ti: ffff881cfe304000
[85656.271404] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85656.292452] RSP: 0018:ffff881cfe307cf0 EFLAGS: 00010282
[85656.303091] RAX: 0000000000000000 RBX: ffff881f6aeb36a8 RCX: 0000000000000001
[85656.313920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881cfe307ca8
[85656.325307] RBP: ffff881cfe307d10 R08: 0000000000000001 R09: ffff881cfe307b90
[85656.335862] R10: ffff881cfe307c20 R11: 0000000000000001 R12: ffff881cfe307d40
[85656.346130] R13: 000000000000000c R14: 000000000000000c R15: 00000000864c1473
[85656.356320] FS: 00007f63cbfae700(0000) GS:ffff88407fce0000(0000) knlGS:0000000000000000
[85656.377099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[85656.390221] CR2: 0000000000000098 CR3: 0000003e49e88000 CR4: 00000000001407e0
[85656.403052] Stack:
[85656.415451] ffffffffc05132b0 ffff881cfe307dc0 ffff881cfe307dc0 ffff88376d043400
[85656.440431] ffff881cfe307d80 ffffffffc0495e7b 0000000200000008 ffff88378db95010
[85656.465732] 0000000000050500 ffff881cfbd12400 0000000000000000 0000000000000000
[85656.489431] Call Trace:
[85656.499622] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[85656.510024] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[85656.520326] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[85656.530404] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[85656.540223] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[85656.549812] [<ffffffff811ef204>] evict+0xb4/0x180
[85656.559216] [<ffffffff811ef9e5>] iput+0xf5/0x180
[85656.568396] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[85656.577284] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[85656.586183] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[85656.595093] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[85656.604004] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[85656.630204] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[85656.639070] RSP <ffff881cfe307cf0>
[85656.647821] CR2: 0000000000000098
[85656.656590] ---[ end trace 5a50666514df0dcb ]---
[85711.172421] init: ceph-osd (ceph/477) main process (870324) killed by ABRT signal
[85711.190563] init: ceph-osd (ceph/477) main process ended, respawning
[85841.490138] init: ceph-osd (ceph/665) main process (530118) killed by ABRT signal
[85841.507894] init: ceph-osd (ceph/665) main process ended, respawning
[86461.580200] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[86461.596970] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86461.605659] PGD 1d3cb6e067 PUD 1c88dba067 PMD 0
[86461.614299] Oops: 0000 [#7] SMP
[86461.622701] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[86461.687882] CPU: 16 PID: 554809 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[86461.708425] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[86461.729413] task: ffff883f02d11e90 ti: ffff881f0018c000 task.ti: ffff881f0018c000
[86461.750551] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86461.773053] RSP: 0018:ffff881f0018fcf0 EFLAGS: 00010286
[86461.783891] RAX: 0000000000000000 RBX: ffff88199f9c5050 RCX: 0000000000000001
[86461.797269] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881f0018fca8
[86461.810685] RBP: ffff881f0018fd10 R08: 0000000000000001 R09: ffff881f0018fb90
[86461.823123] R10: ffff881f0018fc20 R11: 0000000000000001 R12: ffff881f0018fd40
[86461.833755] R13: 0000000000000001 R14: 0000000000000001 R15: 000000006f18892e
[86461.844069] FS: 00007fb39c358700(0000) GS:ffff881fffd40000(0000) knlGS:0000000000000000
[86461.864970] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[86461.875319] CR2: 0000000000000098 CR3: 0000001d2bfc1000 CR4: 00000000001407e0
[86461.885738] Stack:
[86461.895767] ffffffffc05132b0 ffff881f0018fdc0 ffff881f0018fdc0 ffff880273d9a400
[86461.916235] ffff881f0018fd80 ffffffffc0495e7b 0000000200000008 ffff881871959010
[86461.937115] 000000013b769bc0 ffff88194727ea00 0000000000000000 0000000000000000
[86461.958350] Call Trace:
[86461.968596] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[86461.978906] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[86461.988962] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[86461.998857] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[86462.008567] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[86462.018182] [<ffffffff811ef204>] evict+0xb4/0x180
[86462.027320] [<ffffffff811ef9e5>] iput+0xf5/0x180
[86462.036687] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[86462.047730] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[86462.056811] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[86462.065463] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[86462.073711] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[86462.099430] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86462.108060] RSP <ffff881f0018fcf0>
[86462.116888] CR2: 0000000000000098
[86462.138153] ---[ end trace 5a50666514df0dcc ]---
[86509.644955] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[86509.662224] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86509.671327] PGD 1d21de6067 PUD 1f6040a067 PMD 0
[86509.680179] Oops: 0000 [#8] SMP
[86509.688752] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[86509.755167] CPU: 4 PID: 532127 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[86509.775942] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[86509.795344] task: ffff883f6cd98a30 ti: ffff883cf15f0000 task.ti: ffff883cf15f0000
[86509.814934] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86509.835747] RSP: 0018:ffff883cf15f3cf0 EFLAGS: 00010282
[86509.846325] RAX: 0000000000000000 RBX: ffff88197bab1308 RCX: 0000000000000001
[86509.857160] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff883cf15f3ca8
[86509.868092] RBP: ffff883cf15f3d10 R08: 0000000000000001 R09: ffff883cf15f3b90
[86509.878686] R10: ffff883cf15f3c20 R11: 0000000000000001 R12: ffff883cf15f3d40
[86509.888932] R13: 0000000000000002 R14: 0000000000000002 R15: 0000000085add140
[86509.899004] FS: 00007f7a47c0d700(0000) GS:ffff881fffc80000(0000) knlGS:0000000000000000
[86509.919029] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[86509.929478] CR2: 0000000000000098 CR3: 0000001f700d5000 CR4: 00000000001407e0
[86509.939778] Stack:
[86509.949822] ffffffffc05132b0 ffff883cf15f3dc0 ffff883cf15f3dc0 ffff881f17927800
[86509.970334] ffff883cf15f3d80 ffffffffc0495e7b 0000000200000008 ffff8819472fe010
[86509.991184] 000000006ccc2860 ffff881ea0cd8900 0000000000000000 0000000000000000
[86510.013391] Call Trace:
[86510.024026] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[86510.035017] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[86510.047298] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[86510.059118] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[86510.071056] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[86510.082502] [<ffffffff811ef204>] evict+0xb4/0x180
[86510.093531] [<ffffffff811ef9e5>] iput+0xf5/0x180
[86510.104723] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[86510.115297] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[86510.125622] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[86510.136189] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[86510.146039] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[86510.177146] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86510.185986] RSP <ffff883cf15f3cf0>
[86510.194684] CR2: 0000000000000098
[86510.203682] ---[ end trace 5a50666514df0dcd ]---
[86646.071723] init: ceph-osd (ceph/591) main process (553541) killed by ABRT signal
[86646.089281] init: ceph-osd (ceph/591) main process ended, respawning
[86691.461158] init: ceph-osd (ceph/435) main process (530829) killed by ABRT signal
[86691.478207] init: ceph-osd (ceph/435) main process ended, respawning
[86822.251261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[86822.268539] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86822.277240] PGD 38bda99067 PUD 35c0c50067 PMD 0
[86822.285836] Oops: 0000 [#9] SMP
[86822.294323] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[86822.360393] CPU: 12 PID: 870680 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[86822.380430] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[86822.401375] task: ffff881c731a9460 ti: ffff881f070e0000 task.ti: ffff881f070e0000
[86822.423281] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86822.445384] RSP: 0018:ffff881f070e3cf0 EFLAGS: 00010286
[86822.456577] RAX: 0000000000000000 RBX: ffff881f00943d00 RCX: 0000000000000001
[86822.467734] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881f070e3ca8
[86822.478796] RBP: ffff881f070e3d10 R08: 0000000000000001 R09: ffff881f070e3b90
[86822.489672] R10: ffff881f070e3c20 R11: 0000000000000001 R12: ffff881f070e3d40
[86822.500299] R13: 0000000000000002 R14: 0000000000000002 R15: 000000006930c23e
[86822.510832] FS: 00007fe22c9fd700(0000) GS:ffff881fffcc0000(0000) knlGS:0000000000000000
[86822.531506] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[86822.541845] CR2: 0000000000000098 CR3: 0000003eca464000 CR4: 00000000001407e0
[86822.552318] Stack:
[86822.562652] ffffffffc05132b0 ffff881f070e3dc0 ffff881f070e3dc0 ffff882ea078c000
[86822.583333] ffff881f070e3d80 ffffffffc0495e7b 0000000200000008 ffff881f53a62010
[86822.604680] 000000010ffc32a0 ffff881fcf8c7000 0000000000000000 0000000000000000
[86822.625905] Call Trace:
[86822.636048] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[86822.646613] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[86822.656875] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[86822.666789] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[86822.676565] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[86822.686119] [<ffffffff811ef204>] evict+0xb4/0x180
[86822.696207] [<ffffffff811ef9e5>] iput+0xf5/0x180
[86822.705401] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[86822.716450] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[86822.727288] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[86822.736886] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[86822.745310] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[86822.771506] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86822.780348] RSP <ffff881f070e3cf0>
[86822.789092] CR2: 0000000000000098
[86822.798152] ---[ end trace 5a50666514df0dce ]---
[86919.124544] tee (1360527): drop_caches: 3
[86919.124734] tee (1346944): drop_caches: 3
[86961.928164] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[86961.944818] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86961.953484] PGD 1fcfa06067 PUD 1fc7d4e067 PMD 0
[86961.961743] Oops: 0000 [#10] SMP
[86961.969608] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[86962.030212] CPU: 3 PID: 4451 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[86962.048202] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[86962.067137] task: ffff881fc71d28c0 ti: ffff881fd16c4000 task.ti: ffff881fd16c4000
[86962.086701] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86962.107166] RSP: 0000:ffff881fd16c7cf0 EFLAGS: 00010282
[86962.117709] RAX: 0000000000000000 RBX: ffff881c48236570 RCX: 0000000000000001
[86962.128125] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881fd16c7ca8
[86962.138445] RBP: ffff881fd16c7d10 R08: 0000000000000001 R09: ffff881fd16c7b90
[86962.148464] R10: ffff881fd16c7c20 R11: 0000000000000001 R12: ffff881fd16c7d40
[86962.158441] R13: 0000000000000003 R14: 0000000000000003 R15: 000000007ef003a2
[86962.168411] FS: 00007f0c22bf6700(0000) GS:ffff881fffc60000(0000) knlGS:0000000000000000
[86962.188203] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[86962.198538] CR2: 0000000000000098 CR3: 0000001fc210c000 CR4: 00000000001407e0
[86962.208901] Stack:
[86962.219201] ffffffffc05132b0 ffff881fd16c7dc0 ffff881fd16c7dc0 ffff8801cbfbf000
[86962.241080] ffff881fd16c7d80 ffffffffc0495e7b 0000000200000008 ffff881947d50010
[86962.262398] 000000006cca2cd8 ffff881948e9f000 0000000000000000 0000000000000000
[86962.283412] Call Trace:
[86962.293514] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[86962.303899] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[86962.314144] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[86962.324134] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[86962.333880] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[86962.343558] [<ffffffff811ef204>] evict+0xb4/0x180
[86962.353087] [<ffffffff811ef9e5>] iput+0xf5/0x180
[86962.362117] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[86962.370900] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[86962.379395] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[86962.388030] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[86962.396366] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[86962.422803] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86962.431545] RSP <ffff881fd16c7cf0>
[86962.440069] CR2: 0000000000000098
[86962.449122] ---[ end trace 5a50666514df0dcf ]---
[86980.953575] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[86980.971005] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86980.980441] PGD 1ea25f4067 PUD 1ef660c067 PMD 0
[86980.989251] Oops: 0000 [#11] SMP
[86980.999506] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[86981.075385] CPU: 9 PID: 534051 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[86981.097184] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[86981.120102] task: ffff881c7324a8c0 ti: ffff881c2857c000 task.ti: ffff881c2857c000
[86981.143970] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86981.168907] RSP: 0018:ffff881c2857fcf0 EFLAGS: 00010286
[86981.180765] RAX: 0000000000000000 RBX: ffff88360c370828 RCX: 0000000000000001
[86981.191626] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881c2857fca8
[86981.202569] RBP: ffff881c2857fd10 R08: 0000000000000001 R09: ffff881c2857fb90
[86981.213917] R10: ffff881c2857fc20 R11: 0000000000000001 R12: ffff881c2857fd40
[86981.224365] R13: 0000000000000005 R14: 0000000000000005 R15: 000000002445d569
[86981.234535] FS: 00007f647958e700(0000) GS:ffff88407fc60000(0000) knlGS:0000000000000000
[86981.254625] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[86981.265100] CR2: 0000000000000098 CR3: 0000001eb78da000 CR4: 00000000001407e0
[86981.275662] Stack:
[86981.285742] ffffffffc05132b0 ffff881c2857fdc0 ffff881c2857fdc0 ffff883885eff800
[86981.306771] ffff881c2857fd80 ffffffffc0495e7b 0000000200000008 ffff8835d41dd010
[86981.327924] 000000003664e868 ffff883e8c01b780 0000000000000000 0000000000000000
[86981.349204] Call Trace:
[86981.359644] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[86981.369974] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[86981.380065] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[86981.389902] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[86981.399587] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[86981.409249] [<ffffffff811ef204>] evict+0xb4/0x180
[86981.418430] [<ffffffff811ef9e5>] iput+0xf5/0x180
[86981.427656] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[86981.436660] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[86981.445397] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[86981.453802] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[86981.462287] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[86981.489249] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[86981.497830] RSP <ffff881c2857fcf0>
[86981.506669] CR2: 0000000000000098
[86981.515458] ---[ end trace 5a50666514df0dd0 ]---
[87006.189590] init: ceph-osd (ceph/416) main process (869762) killed by ABRT signal
[87006.206884] init: ceph-osd (ceph/416) main process ended, respawning
[87145.757174] init: ceph-osd (ceph/680) main process (4107) killed by ABRT signal
[87145.774741] init: ceph-osd (ceph/680) main process ended, respawning
[87165.426676] init: ceph-osd (ceph/583) main process (532654) killed by ABRT signal
[87165.444956] init: ceph-osd (ceph/583) main process ended, respawning
[87400.697996] tee (1360840): drop_caches: 3
[88519.480634] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[88519.497732] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[88519.506741] PGD 1f0a46d067 PUD 1c5c2df067 PMD 0
[88519.515776] Oops: 0000 [#12] SMP
[88519.525036] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[88519.593998] CPU: 12 PID: 557802 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[88519.614475] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[88519.636422] task: ffff883c3e0f5bb0 ti: ffff883e7b608000 task.ti: ffff883e7b608000
[88519.660737] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[88519.686310] RSP: 0018:ffff883e7b60bcf0 EFLAGS: 00010286
[88519.697097] RAX: 0000000000000000 RBX: ffff881fd1610828 RCX: 0000000000000001
[88519.707966] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff883e7b60bca8
[88519.719028] RBP: ffff883e7b60bd10 R08: 0000000000000001 R09: ffff883e7b60bb90
[88519.729734] R10: ffff883e7b60bc20 R11: 0000000000000001 R12: ffff883e7b60bd40
[88519.740171] R13: 0000000000000002 R14: 0000000000000002 R15: 00000000e1ddc3d2
[88519.750867] FS: 00007f71c9977700(0000) GS:ffff881fffcc0000(0000) knlGS:0000000000000000
[88519.771443] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[88519.781907] CR2: 0000000000000098 CR3: 0000001cfbf21000 CR4: 00000000001407e0
[88519.792485] Stack:
[88519.802677] ffffffffc05132b0 ffff883e7b60bdc0 ffff883e7b60bdc0 ffff8839679bbc00
[88519.823288] ffff883e7b60bd80 ffffffffc0495e7b 0000000200000008 ffff88197dc76010
[88519.844444] 000000010ff2e558 ffff88180621ea00 0000000000000000 0000000000000000
[88519.865502] Call Trace:
[88519.875655] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[88519.886233] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[88519.897478] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[88519.909317] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[88519.919221] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[88519.928855] [<ffffffff811ef204>] evict+0xb4/0x180
[88519.938338] [<ffffffff811ef9e5>] iput+0xf5/0x180
[88519.947641] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[88519.956521] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[88519.965271] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[88519.973830] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[88519.982008] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[88520.008089] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[88520.017002] RSP <ffff883e7b60bcf0>
[88520.025773] CR2: 0000000000000098
[88520.047028] ---[ end trace 5a50666514df0dd1 ]---
[88673.852863] init: ceph-osd (ceph/620) main process (556454) killed by ABRT signal
[88673.870441] init: ceph-osd (ceph/620) main process ended, respawning
[91042.566841] BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
[91042.584209] IP: [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[91042.593112] PGD 1fcf629067 PUD 1fd0046067 PMD 0
[91042.601765] Oops: 0000 [#13] SMP
[91042.610386] Modules linked in: xfs libcrc32c dm_crypt ses enclosure ipmi_devintf x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev sb_edac edac_core mei_me mei lpc_ich ipmi_si ipmi_msghandler ioatdma wmi mac_hid bonding 8021q garp stp mrp llc lp parport btrfs xor raid6_pq igb ixgbe isci i2c_algo_bit hid_generic dca ahci usbhid mpt2sas ptp hid libsas libahci mdio raid_class pps_core scsi_transport_sas
[91042.673765] CPU: 16 PID: 277118 Comm: ceph-osd Tainted: G D 3.16.0-38-generic #52~14.04.1-Ubuntu
[91042.693086] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0b 05/27/2014
[91042.713345] task: ffff883da3f5bd20 ti: ffff883c62318000 task.ti: ffff883c62318000
[91042.734218] RIP: 0010:[<ffffffffc04d28b0>] [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[91042.755908] RSP: 0018:ffff883c6231bcf0 EFLAGS: 00010286
[91042.766821] RAX: 0000000000000000 RBX: ffff881fca5922b8 RCX: 0000000000000001
[91042.777842] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff883c6231bca8
[91042.789217] RBP: ffff883c6231bd10 R08: 0000000000000001 R09: ffff883c6231bb90
[91042.799782] R10: ffff883c6231bc20 R11: 0000000000000001 R12: ffff883c6231bd40
[91042.810530] R13: 0000000000000001 R14: 0000000000000001 R15: 00000000fdee988c
[91042.821067] FS: 00007f3aa0320700(0000) GS:ffff881fffd40000(0000) knlGS:0000000000000000
[91042.841757] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[91042.852215] CR2: 0000000000000098 CR3: 0000001fc99af000 CR4: 00000000001407e0
[91042.862600] Stack:
[91042.872890] ffffffffc05132b0 ffff883c6231bdc0 ffff883c6231bdc0 ffff881fc5aad800
[91042.893385] ffff883c6231bd80 ffffffffc0495e7b 0000000200000008 ffff881d376a3010
[91042.914398] 000000011ad63590 ffff881eaa191980 0000000000000000 0000000000000000
[91042.935354] Call Trace:
[91042.945469] [<ffffffffc0495e7b>] xfs_attr3_node_inactive+0x19b/0x220 [xfs]
[91042.955905] [<ffffffffc0495f96>] xfs_attr3_root_inactive+0x96/0x100 [xfs]
[91042.965967] [<ffffffffc04960b2>] xfs_attr_inactive+0xb2/0x150 [xfs]
[91042.975998] [<ffffffffc04e728a>] xfs_inactive+0x8a/0x160 [xfs]
[91042.985642] [<ffffffffc04af3de>] xfs_fs_evict_inode+0x7e/0xc0 [xfs]
[91042.995209] [<ffffffff811ef204>] evict+0xb4/0x180
[91043.004717] [<ffffffff811ef9e5>] iput+0xf5/0x180
[91043.014679] [<ffffffff811e4413>] do_unlinkat+0x193/0x2c0
[91043.023913] [<ffffffff811d961f>] ? SYSC_newstat+0x2f/0x40
[91043.032535] [<ffffffff811e5496>] SyS_unlink+0x16/0x20
[91043.040995] [<ffffffff8176da4d>] system_call_fastpath+0x1a/0x1f
[91043.049339] Code: 55 48 89 e5 41 54 4d 89 c4 53 48 89 fb 48 83 ec 10 48 c7 04 24 b0 32 51 c0 e8 ed fe ff ff 85 c0 75 49 48 85 db 74 44 49 8b 34 24 <48> 8b 96 98 00 00 00 0f b7 52 08 66 c1 c2 08 66 81 fa be 3e 74
[91043.075208] RIP [<ffffffffc04d28b0>] xfs_da3_node_read+0x30/0xd0 [xfs]
[91043.083934] RSP <ffff883c6231bcf0>
[91043.092737] CR2: 0000000000000098
[91043.114204] ---[ end trace 5a50666514df0dd2 ]---
[91102.696725] tee (1399014): drop_caches: 3
[91102.696825] tee (1398613): drop_caches: 3
[91105.035948] tee (1401752): drop_caches: 3
[91105.037052] tee (1360837): drop_caches: 3
[91157.471951] tee (1406017): drop_caches: 3
[91157.488887] tee (1406009): drop_caches: 3
[91157.488889] tee (1406113): drop_caches: 3
[91157.488891] tee (1406124): drop_caches: 3
[91157.488892] tee (1406023): drop_caches: 3
[91189.199378] tee (1406741): drop_caches: 3
[91227.781592] init: ceph-osd (ceph/571) main process (276126) killed by ABRT signal
[91227.793767] init: ceph-osd (ceph/571) main process ended, respawning
[91323.205616] tee (1409872): drop_caches: 3
[92020.358372] tee (1420465): drop_caches: 3
[92750.603036] tee (1427379): drop_caches: 3
[93293.228937] tee (1432421): drop_caches: 3
[93782.880202] tee (1436635): drop_caches: 3
[94389.760277] tee (1443489): drop_caches: 3
[95683.273681] tee (1451405): drop_caches: 3
[95683.274761] tee (1451411): drop_caches: 3
[96115.516458] tee (1453623): drop_caches: 3
[96656.846121] tee (1456482): drop_caches: 3
[97294.164097] tee (1460357): drop_caches: 3
[97912.361522] tee (1463513): drop_caches: 3
[99039.990839] tee (1502043): drop_caches: 3
[99155.768401] tee (1505031): drop_caches: 3
[99606.831933] tee (1519625): drop_caches: 3
[102689.660012] tee (1527422): drop_caches: 3
[102689.666220] tee (1527428): drop_caches: 3
[103513.924336] tee (1529579): drop_caches: 3
[104678.959399] tee (1532520): drop_caches: 3
[105101.730283] tee (1534232): drop_caches: 3
[105101.734362] tee (1534274): drop_caches: 3
[105586.095603] tee (1535485): drop_caches: 3
[106367.857055] tee (1552316): drop_caches: 3
[106367.861252] tee (1552326): drop_caches: 3
[106607.659245] tee (1553970): drop_caches: 3
[106607.659587] tee (1553973): drop_caches: 3
[108230.133768] tee (1576183): drop_caches: 3
[108230.133769] tee (1576186): drop_caches: 3
[109821.208540] tee (1588276): drop_caches: 3
[109821.211636] tee (1588271): drop_caches: 3
[109821.211759] tee (1588263): drop_caches: 3
[112318.756154] tee (1606103): drop_caches: 3
[112318.756156] tee (1606116): drop_caches: 3
[112318.756162] tee (1606104): drop_caches: 3
[112318.756164] tee (1606112): drop_caches: 3
[112318.907232] tee (1606093): drop_caches: 3
[113545.012648] tee (1618093): drop_caches: 3
[113545.012650] tee (1618088): drop_caches: 3
[114809.706514] tee (1625774): drop_caches: 3
[114809.706539] tee (1625767): drop_caches: 3
[116084.795941] tee (1634121): drop_caches: 3
[116084.795985] tee (1634124): drop_caches: 3
[116559.034261] tee (1641091): drop_caches: 3
[116965.269062] tee (1645921): drop_caches: 3
[-- Attachment #3: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2015-06-13 1:02 Tom Christensen
@ 2015-06-13 22:39 ` Dave Chinner
2015-06-14 23:27 ` Dave Chinner
0 siblings, 1 reply; 669+ messages in thread
From: Dave Chinner @ 2015-06-13 22:39 UTC (permalink / raw)
To: Tom Christensen; +Cc: swakefie, xfs
On Sat, Jun 13, 2015 at 01:02:51AM +0000, Tom Christensen wrote:
> We've run into a bit of an issue with xfs running Ceph. The following bug details what we are seeing:
> https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
>
> Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
>
> Here is additional info gathered:
>
> xfs bmap output for a random directory
> https://gist.github.com/dmmatson/e864252c7ff346df954a
>
> attr -l of the file dchinner indicated from the xfs bmap output
> (attr -l)
> (6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
>
> xfs_bmap -vp of same file
>
> rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> (6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> (6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000
And the attribute fork was:
rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..7]: 1461176488..1461176495 8 (1163688..1163695) 8 00000
1: [8..31]: 1461176504..1461176527 8 (1163704..1163727) 24 00000
I just created a filesystem and attribute list identical to the
above, and came up with a attribute fork that looks like:
/mnt/scratch/udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..7]: 120..127 0 (120..127) 8 00000
1: [8..15]: 112..119 0 (112..119) 8 00000
2: [16..23]: 104..111 0 (104..111) 8 00000
IOWs, there's an extra block in the attribute fork that is causing
problems than there needs to be. That tends to imply attribute
overwrites might be contributing here (the 3-phase overwrite
algorithm increases the space usage) so I'm going to need to try a
few different things to see if I can get an attribute fork into the
same shape....
> LVM configuration: None
>
> HGST 3TB
>
> meta-data=/dev/mapper/63e3300b-6b7b-41a0-bdf2-b64ec3c20c51 isize=2048 agcount=32, agsize=22812700 blks
agcount=32 will actually be slowing your disks down. The default of
4AGs is usually best for a single spindle as it has sufficient
allocation cncurrency but results in much fewer seeks than a higher
AG count....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2015-06-13 22:39 ` your mail Dave Chinner
@ 2015-06-14 23:27 ` Dave Chinner
0 siblings, 0 replies; 669+ messages in thread
From: Dave Chinner @ 2015-06-14 23:27 UTC (permalink / raw)
To: Tom Christensen; +Cc: swakefie, xfs
On Sun, Jun 14, 2015 at 08:39:21AM +1000, Dave Chinner wrote:
> On Sat, Jun 13, 2015 at 01:02:51AM +0000, Tom Christensen wrote:
> > We've run into a bit of an issue with xfs running Ceph. The following bug details what we are seeing:
> > https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
> >
> > Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
> >
> > Here is additional info gathered:
> >
> > xfs bmap output for a random directory
> > https://gist.github.com/dmmatson/e864252c7ff346df954a
> >
> > attr -l of the file dchinner indicated from the xfs bmap output
> > (attr -l)
> > (6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> >
> > xfs_bmap -vp of same file
> >
> > rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> > (6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> > (6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000
>
> And the attribute fork was:
>
> rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> 0: [0..7]: 1461176488..1461176495 8 (1163688..1163695) 8 00000
> 1: [8..31]: 1461176504..1461176527 8 (1163704..1163727) 24 00000
>
> I just created a filesystem and attribute list identical to the
> above, and came up with a attribute fork that looks like:
>
> /mnt/scratch/udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> 0: [0..7]: 120..127 0 (120..127) 8 00000
> 1: [8..15]: 112..119 0 (112..119) 8 00000
> 2: [16..23]: 104..111 0 (104..111) 8 00000
>
> IOWs, there's an extra block in the attribute fork that is causing
> problems than there needs to be. That tends to imply attribute
> overwrites might be contributing here (the 3-phase overwrite
> algorithm increases the space usage) so I'm going to need to try a
> few different things to see if I can get an attribute fork into the
> same shape....
I've had a test running overnight that generates attribute forks of
this shape, but I haven't seen any problems. sequential grow of
attributes, semi random growth, semi random truncation, etc don't
seem to trip over this problem on a 4.1-rc6 kernel. Hence I'm going
to need a metadump image of a filesystem with a broken file in it.
An obfuscated dump is fine; I only need to look at the structure of
the bad attribute fork. If you want to send the link privately to me
that is fine, too.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 669+ messages in thread
* No subject
@ 2015-04-21 10:18 Ard Biesheuvel
2015-04-21 10:46 ` your mail Dave P Martin
0 siblings, 1 reply; 669+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 12:13, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> This updates the PROCINFO offset-to-setup-function fields of the
>> Thumb2 capable CPU definitions to include the Thumb bit when building
>> a Thumb2 kernel. This ensures that these function are always called
>> in the correct mode.
>
> I don't think this is necessary, in fact, I think this is positively
> regression causing.
>
> The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> As we have seen already from the kernel dumps from the V7M kernel, when
> it calculates initfunc - name in a T2 kernel, the resulting value is an
> _odd_ number.
>
OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
But looking at proc-v7.S again, the problem may just be the missing
ENDPROC() declarations for a couple of the setup() functions, which
explains why they are lacking the Thumb annotations.
> Using BSYM() here will increment it to be the next _even_ number, which
> is wrong as this will potentially point at either half way through a
> 32-bit T2 instruction, or the second 16-bit T2 instruction.
>
Agreed.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 10:18 No subject Ard Biesheuvel
@ 2015-04-21 10:46 ` Dave P Martin
2015-04-21 10:50 ` Ard Biesheuvel
0 siblings, 1 reply; 669+ messages in thread
From: Dave P Martin @ 2015-04-21 10:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 12:13, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
> >> This updates the PROCINFO offset-to-setup-function fields of the
> >> Thumb2 capable CPU definitions to include the Thumb bit when building
> >> a Thumb2 kernel. This ensures that these function are always called
> >> in the correct mode.
> >
> > I don't think this is necessary, in fact, I think this is positively
> > regression causing.
> >
> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> > As we have seen already from the kernel dumps from the V7M kernel, when
> > it calculates initfunc - name in a T2 kernel, the resulting value is an
> > _odd_ number.
> >
>
> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
'| 1' is more logical, but can't be resolved at link time because
there's no relocation for this operation. Hence '+ 1'. This matters
for local cross-section references that can't be resolved at assembly
time.
> But looking at proc-v7.S again, the problem may just be the missing
> ENDPROC() declarations for a couple of the setup() functions, which
> explains why they are lacking the Thumb annotations.
Yes, if any are missing ENDPROC() then it should be added there.
Cheers
---Dave
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 10:46 ` your mail Dave P Martin
@ 2015-04-21 10:50 ` Ard Biesheuvel
2015-04-21 11:10 ` Dave P Martin
0 siblings, 1 reply; 669+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 10:50 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 12:13, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> >> This updates the PROCINFO offset-to-setup-function fields of the
>> >> Thumb2 capable CPU definitions to include the Thumb bit when building
>> >> a Thumb2 kernel. This ensures that these function are always called
>> >> in the correct mode.
>> >
>> > I don't think this is necessary, in fact, I think this is positively
>> > regression causing.
>> >
>> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
>> > As we have seen already from the kernel dumps from the V7M kernel, when
>> > it calculates initfunc - name in a T2 kernel, the resulting value is an
>> > _odd_ number.
>> >
>>
>> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
>
> '| 1' is more logical, but can't be resolved at link time because
> there's no relocation for this operation. Hence '+ 1'. This matters
> for local cross-section references that can't be resolved at assembly
> time.
>
OK, that makes sense. But it does appear that the local cross-section
references are working just fine, i.e., references from other sections
in the same .o have the thumb bit set correctly even without BSYM()
>> But looking at proc-v7.S again, the problem may just be the missing
>> ENDPROC() declarations for a couple of the setup() functions, which
>> explains why they are lacking the Thumb annotations.
>
> Yes, if any are missing ENDPROC() then it should be added there.
>
I am putting together a v2 with this instead of the BSYM() on the initfn
Cheers,
Ard.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 10:50 ` Ard Biesheuvel
@ 2015-04-21 11:10 ` Dave P Martin
2015-04-21 11:15 ` Ard Biesheuvel
2015-04-21 11:24 ` Russell King - ARM Linux
0 siblings, 2 replies; 669+ messages in thread
From: Dave P Martin @ 2015-04-21 11:10 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
> >> On 21 April 2015 at 12:13, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
> >> >> This updates the PROCINFO offset-to-setup-function fields of the
> >> >> Thumb2 capable CPU definitions to include the Thumb bit when building
> >> >> a Thumb2 kernel. This ensures that these function are always called
> >> >> in the correct mode.
> >> >
> >> > I don't think this is necessary, in fact, I think this is positively
> >> > regression causing.
> >> >
> >> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> >> > As we have seen already from the kernel dumps from the V7M kernel, when
> >> > it calculates initfunc - name in a T2 kernel, the resulting value is an
> >> > _odd_ number.
> >> >
> >>
> >> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
> >
> > '| 1' is more logical, but can't be resolved at link time because
> > there's no relocation for this operation. Hence '+ 1'. This matters
> > for local cross-section references that can't be resolved at assembly
> > time.
> >
>
> OK, that makes sense. But it does appear that the local cross-section
> references are working just fine, i.e., references from other sections
> in the same .o have the thumb bit set correctly even without BSYM()
For branch targets, the set of situations where BSYM must be used and
the set of situations where it must not be used are mutually exclusive:
* If the assembler resolves the address and the address will be used as a
branch target, BSYM() must be used. This applies to non-cross-section
references within in single object only.
* If the linker resolves the address, BSYM() must not be used and the
target label must be annotated with ENDPROC(). This applies to
all cross-section or cross-object references.
For any address that won't be used as a branch target, BSYM() must not
be used.
Cross-section non-cross-object references where the target is missing
ENDPROC() and BSYM _is_ used will also work, but this should be avoided
-- it's an abuse really.
The reason for these rules is that the assembler doesn't do any Thumb
bit handling when taking the address of a local symbol, irrespective
of the symbol's type. This can result in a screwup unless the assembler
can't resolve the address and must leave it as a relocation for the
linker to process, or if the correct annotation for the linker to do
the right fixup is missing.
I don't know the history of why this inconsistency exists between the
assembler and linker behaviour, but changing it would likely break
more stuff than it fixes now.
Maybe it would be a good idea to add a comment in asm/unified.h
explaining this, assuming (hopefully) that my explanation was right...
[...]
Cheers
---Dave
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 11:10 ` Dave P Martin
@ 2015-04-21 11:15 ` Ard Biesheuvel
2015-04-21 11:24 ` Russell King - ARM Linux
1 sibling, 0 replies; 669+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 11:15 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 13:10, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
>> > On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
>> >> On 21 April 2015 at 12:13, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> >> >> This updates the PROCINFO offset-to-setup-function fields of the
>> >> >> Thumb2 capable CPU definitions to include the Thumb bit when building
>> >> >> a Thumb2 kernel. This ensures that these function are always called
>> >> >> in the correct mode.
>> >> >
>> >> > I don't think this is necessary, in fact, I think this is positively
>> >> > regression causing.
>> >> >
>> >> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
>> >> > As we have seen already from the kernel dumps from the V7M kernel, when
>> >> > it calculates initfunc - name in a T2 kernel, the resulting value is an
>> >> > _odd_ number.
>> >> >
>> >>
>> >> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
>> >
>> > '| 1' is more logical, but can't be resolved at link time because
>> > there's no relocation for this operation. Hence '+ 1'. This matters
>> > for local cross-section references that can't be resolved at assembly
>> > time.
>> >
>>
>> OK, that makes sense. But it does appear that the local cross-section
>> references are working just fine, i.e., references from other sections
>> in the same .o have the thumb bit set correctly even without BSYM()
>
> For branch targets, the set of situations where BSYM must be used and
> the set of situations where it must not be used are mutually exclusive:
>
> * If the assembler resolves the address and the address will be used as a
> branch target, BSYM() must be used. This applies to non-cross-section
> references within in single object only.
>
Here, 'sym | 1' should work ...
> * If the linker resolves the address, BSYM() must not be used and the
> target label must be annotated with ENDPROC(). This applies to
> all cross-section or cross-object references.
>
> For any address that won't be used as a branch target, BSYM() must not
> be used.
>
> Cross-section non-cross-object references where the target is missing
> ENDPROC() and BSYM _is_ used will also work, but this should be avoided
> -- it's an abuse really.
>
... and for the other cases, we rely on the assembler to emit
relocations for the linker to process.
So in summary, defining BSYM() as 'sym + 1' rather than 'sym | 1' only
enables cases where BSYM() shouldn't be used in the first place. Or am
I missing something?
>
> The reason for these rules is that the assembler doesn't do any Thumb
> bit handling when taking the address of a local symbol, irrespective
> of the symbol's type. This can result in a screwup unless the assembler
> can't resolve the address and must leave it as a relocation for the
> linker to process, or if the correct annotation for the linker to do
> the right fixup is missing.
>
>
> I don't know the history of why this inconsistency exists between the
> assembler and linker behaviour, but changing it would likely break
> more stuff than it fixes now.
>
> Maybe it would be a good idea to add a comment in asm/unified.h
> explaining this, assuming (hopefully) that my explanation was right...
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 11:10 ` Dave P Martin
2015-04-21 11:15 ` Ard Biesheuvel
@ 2015-04-21 11:24 ` Russell King - ARM Linux
2015-04-21 12:50 ` Russell King - ARM Linux
1 sibling, 1 reply; 669+ messages in thread
From: Russell King - ARM Linux @ 2015-04-21 11:24 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 12:10:43PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
> > OK, that makes sense. But it does appear that the local cross-section
> > references are working just fine, i.e., references from other sections
> > in the same .o have the thumb bit set correctly even without BSYM()
>
> For branch targets, the set of situations where BSYM must be used and
> the set of situations where it must not be used are mutually exclusive:
>
> * If the assembler resolves the address and the address will be used as a
> branch target, BSYM() must be used. This applies to non-cross-section
> references within in single object only.
>
> * If the linker resolves the address, BSYM() must not be used and the
> target label must be annotated with ENDPROC(). This applies to
> all cross-section or cross-object references.
Yes, that agrees with the situation we have for the initfunc stuff.
> For any address that won't be used as a branch target, BSYM() must not
> be used.
>
> Cross-section non-cross-object references where the target is missing
> ENDPROC() and BSYM _is_ used will also work, but this should be avoided
> -- it's an abuse really.
We should probably create a badr macro to complement the adr pseudo-op
which incorporates the BSYM thing so make this clearer - and a comment
before it. This is really the case where BSYM should be used.
We have one case in the kernel source which is probably buggy:
arch/arm/kvm/interrupts.S: ldr r2, =BSYM(panic)
and killing BSYM in favour of a badr macro would prevent this.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 11:24 ` Russell King - ARM Linux
@ 2015-04-21 12:50 ` Russell King - ARM Linux
2015-04-21 13:10 ` Ard Biesheuvel
2015-04-21 13:18 ` Dave P Martin
0 siblings, 2 replies; 669+ messages in thread
From: Russell King - ARM Linux @ 2015-04-21 12:50 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> We should probably create a badr macro to complement the adr pseudo-op
> which incorporates the BSYM thing so make this clearer - and a comment
> before it. This is really the case where BSYM should be used.
Something like this. Note that I've also removed the BSYM() usage in
the KVM code.
arch/arm/boot/compressed/head.S | 4 ++--
arch/arm/common/mcpm_head.S | 2 +-
arch/arm/include/asm/assembler.h | 17 ++++++++++++++++-
arch/arm/include/asm/entry-macro-multi.S | 4 ++--
arch/arm/include/asm/unified.h | 2 --
arch/arm/kernel/entry-armv.S | 12 ++++++------
arch/arm/kernel/entry-common.S | 6 +++---
arch/arm/kernel/entry-ftrace.S | 2 +-
arch/arm/kernel/head-nommu.S | 6 +++---
arch/arm/kernel/head.S | 8 ++++----
arch/arm/kernel/sleep.S | 2 +-
arch/arm/kvm/interrupts.S | 2 +-
arch/arm/lib/call_with_stack.S | 2 +-
arch/arm/mm/proc-v7m.S | 2 +-
14 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 2c45b5709fa4..06e983f59980 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -130,7 +130,7 @@ start:
.endr
ARM( mov r0, r0 )
ARM( b 1f )
- THUMB( adr r12, BSYM(1f) )
+ THUMB( badr r12, 1f )
THUMB( bx r12 )
.word _magic_sig @ Magic numbers to help the loader
@@ -447,7 +447,7 @@ dtb_check_done:
bl cache_clean_flush
- adr r0, BSYM(restart)
+ badr r0, restart
add r0, r0, r6
mov pc, r0
diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
index e02db4b81a66..08b3bb9bc6a2 100644
--- a/arch/arm/common/mcpm_head.S
+++ b/arch/arm/common/mcpm_head.S
@@ -49,7 +49,7 @@
ENTRY(mcpm_entry_point)
ARM_BE8(setend be)
- THUMB( adr r12, BSYM(1f) )
+ THUMB( badr r12, 1f )
THUMB( bx r12 )
THUMB( .thumb )
1:
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 186270b3e194..4abe57279c66 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -178,6 +178,21 @@
.endm
/*
+ * Assembly version of "adr rd, BSYM(sym)". This should only be used to
+ * reference local symbols in the same assembly file which are to be
+ * resolved by the assembler. Other usage is undefined.
+ */
+ .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
+ .macro badr\c, rd, sym
+#ifdef CONFIG_THUMB2_KERNEL
+ adr\c \rd, \sym + 1
+#else
+ adr\c \rd, \sym
+#endif
+ .endm
+ .endr
+
+/*
* Get current thread_info.
*/
.macro get_thread_info, rd
@@ -326,7 +341,7 @@
THUMB( orr \reg , \reg , #PSR_T_BIT )
bne 1f
orr \reg, \reg, #PSR_A_BIT
- adr lr, BSYM(2f)
+ badr lr, 2f
msr spsr_cxsf, \reg
__MSR_ELR_HYP(14)
__ERET
diff --git a/arch/arm/include/asm/entry-macro-multi.S b/arch/arm/include/asm/entry-macro-multi.S
index 469a2b30fa27..609184f522ee 100644
--- a/arch/arm/include/asm/entry-macro-multi.S
+++ b/arch/arm/include/asm/entry-macro-multi.S
@@ -10,7 +10,7 @@
@
@ routine called with r0 = irq number, r1 = struct pt_regs *
@
- adrne lr, BSYM(1b)
+ badrne lr, 1b
bne asm_do_IRQ
#ifdef CONFIG_SMP
@@ -23,7 +23,7 @@
ALT_SMP(test_for_ipi r0, r2, r6, lr)
ALT_UP_B(9997f)
movne r1, sp
- adrne lr, BSYM(1b)
+ badrne lr, 1b
bne do_IPI
#endif
9997:
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index 200f9a7cd623..a91ae499614c 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -45,7 +45,6 @@
#define THUMB(x...) x
#ifdef __ASSEMBLY__
#define W(instr) instr.w
-#define BSYM(sym) sym + 1
#else
#define WASM(instr) #instr ".w"
#endif
@@ -59,7 +58,6 @@
#define THUMB(x...)
#ifdef __ASSEMBLY__
#define W(instr) instr
-#define BSYM(sym) sym
#else
#define WASM(instr) #instr
#endif
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 570306c49406..f8f7398c74c2 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -40,7 +40,7 @@
#ifdef CONFIG_MULTI_IRQ_HANDLER
ldr r1, =handle_arch_irq
mov r0, sp
- adr lr, BSYM(9997f)
+ badr lr, 9997f
ldr pc, [r1]
#else
arch_irq_handler_default
@@ -273,7 +273,7 @@ __und_svc:
str r4, [sp, #S_PC]
orr r0, r9, r0, lsl #16
#endif
- adr r9, BSYM(__und_svc_finish)
+ badr r9, __und_svc_finish
mov r2, r4
bl call_fpe
@@ -469,7 +469,7 @@ __und_usr:
@ instruction, or the more conventional lr if we are to treat
@ this as a real undefined instruction
@
- adr r9, BSYM(ret_from_exception)
+ badr r9, ret_from_exception
@ IRQs must be enabled before attempting to read the instruction from
@ user space since that could cause a page/translation fault if the
@@ -486,7 +486,7 @@ __und_usr:
@ r2 = PC value for the following instruction (:= regs->ARM_pc)
@ r4 = PC value for the faulting instruction
@ lr = 32-bit undefined instruction function
- adr lr, BSYM(__und_usr_fault_32)
+ badr lr, __und_usr_fault_32
b call_fpe
__und_usr_thumb:
@@ -522,7 +522,7 @@ ARM_BE8(rev16 r0, r0) @ little endian instruction
add r2, r2, #2 @ r2 is PC + 2, make it PC + 4
str r2, [sp, #S_PC] @ it's a 2x16bit instr, update
orr r0, r0, r5, lsl #16
- adr lr, BSYM(__und_usr_fault_32)
+ badr lr, __und_usr_fault_32
@ r0 = the two 16-bit Thumb instructions which caused the exception
@ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
@ r4 = PC value for the first 16-bit Thumb instruction
@@ -716,7 +716,7 @@ __und_usr_fault_32:
__und_usr_fault_16:
mov r1, #2
1: mov r0, sp
- adr lr, BSYM(ret_from_exception)
+ badr lr, ret_from_exception
b __und_fault
ENDPROC(__und_usr_fault_32)
ENDPROC(__und_usr_fault_16)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index f8ccc21fa032..6ab159384667 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -88,7 +88,7 @@ ENTRY(ret_from_fork)
bl schedule_tail
cmp r5, #0
movne r0, r4
- adrne lr, BSYM(1f)
+ badrne lr, 1f
retne r5
1: get_thread_info tsk
b ret_slow_syscall
@@ -196,7 +196,7 @@ local_restart:
bne __sys_trace
cmp scno, #NR_syscalls @ check upper syscall limit
- adr lr, BSYM(ret_fast_syscall) @ return address
+ badr lr, ret_fast_syscall @ return address
ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine
add r1, sp, #S_OFF
@@ -231,7 +231,7 @@ __sys_trace:
add r0, sp, #S_OFF
bl syscall_trace_enter
- adr lr, BSYM(__sys_trace_return) @ return address
+ badr lr, __sys_trace_return @ return address
mov scno, r0 @ syscall number (possibly new)
add r1, sp, #S_R0 + S_OFF @ pointer to regs
cmp scno, #NR_syscalls @ check upper syscall limit
diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S
index fe57c73e70a4..c73c4030ca5d 100644
--- a/arch/arm/kernel/entry-ftrace.S
+++ b/arch/arm/kernel/entry-ftrace.S
@@ -87,7 +87,7 @@
1: mcount_get_lr r1 @ lr of instrumented func
mcount_adjust_addr r0, lr @ instrumented function
- adr lr, BSYM(2f)
+ badr lr, 2f
mov pc, r2
2: mcount_exit
.endm
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 84da14b7cd04..c9660167ef1a 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -46,7 +46,7 @@ ENTRY(stext)
.arm
ENTRY(stext)
- THUMB( adr r9, BSYM(1f) ) @ Kernel is always entered in ARM.
+ THUMB( badr r9, 1f ) @ Kernel is always entered in ARM.
THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
THUMB( .thumb ) @ switch to Thumb now.
THUMB(1: )
@@ -79,7 +79,7 @@ ENTRY(stext)
#endif
ldr r13, =__mmap_switched @ address to jump to after
@ initialising sctlr
- adr lr, BSYM(1f) @ return (PIC) address
+ badr lr, 1f @ return (PIC) address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10
ret r12
@@ -115,7 +115,7 @@ ENTRY(secondary_startup)
bl __setup_mpu @ Initialize the MPU
#endif
- adr lr, BSYM(__after_proc_init) @ return address
+ badr lr, __after_proc_init @ return address
mov r13, r12 @ __secondary_switched address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 7304b4c44b52..1eecd57453be 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -80,7 +80,7 @@
ENTRY(stext)
ARM_BE8(setend be ) @ ensure we are in BE8 mode
- THUMB( adr r9, BSYM(1f) ) @ Kernel is always entered in ARM.
+ THUMB( badr r9, 1f ) @ Kernel is always entered in ARM.
THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
THUMB( .thumb ) @ switch to Thumb now.
THUMB(1: )
@@ -148,7 +148,7 @@ ENTRY(stext)
*/
ldr r13, =__mmap_switched @ address to jump to after
@ mmu has been enabled
- adr lr, BSYM(1f) @ return (PIC) address
+ badr lr, 1f @ return (PIC) address
#ifdef CONFIG_ARM_LPAE
mov r5, #0 @ high TTBR0
mov r8, r4, lsr #12 @ TTBR1 is swapper_pg_dir pfn
@@ -364,7 +364,7 @@ __turn_mmu_on_loc:
.text
ENTRY(secondary_startup_arm)
.arm
- THUMB( adr r9, BSYM(1f) ) @ Kernel is entered in ARM.
+ THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
THUMB( .thumb ) @ switch to Thumb now.
THUMB(1: )
@@ -400,7 +400,7 @@ ENTRY(secondary_startup)
add r3, r7, lr
ldrd r4, [r3, #0] @ get secondary_data.pgdir
ldr r8, [r3, #8] @ get secondary_data.swapper_pg_dir
- adr lr, BSYM(__enable_mmu) @ return address
+ badr lr, __enable_mmu @ return address
mov r13, r12 @ __secondary_switched address
ldr r12, [r10, #PROCINFO_INITFUNC]
add r12, r12, r10 @ initialise processor
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 7d37bfc50830..76bb3128e135 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -81,7 +81,7 @@ ENTRY(__cpu_suspend)
mov r1, r4 @ size of save block
add r0, sp, #8 @ pointer to save block
bl __cpu_suspend_save
- adr lr, BSYM(cpu_suspend_abort)
+ badr lr, cpu_suspend_abort
ldmfd sp!, {r0, pc} @ call suspend fn
ENDPROC(__cpu_suspend)
.ltorg
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 79caf79b304a..87847d2c5f99 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -309,7 +309,7 @@ ENTRY(kvm_call_hyp)
THUMB( orr r2, r2, #PSR_T_BIT )
msr spsr_cxsf, r2
mrs r1, ELR_hyp
- ldr r2, =BSYM(panic)
+ ldr r2, =panic
msr ELR_hyp, r2
ldr r0, =\panic_str
clrex @ Clear exclusive monitor
diff --git a/arch/arm/lib/call_with_stack.S b/arch/arm/lib/call_with_stack.S
index ed1a421813cb..bf3a40889205 100644
--- a/arch/arm/lib/call_with_stack.S
+++ b/arch/arm/lib/call_with_stack.S
@@ -35,7 +35,7 @@ ENTRY(call_with_stack)
mov r2, r0
mov r0, r1
- adr lr, BSYM(1f)
+ badr lr, 1f
ret r2
1: ldr lr, [sp]
diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
index e08e1f2bab76..67d9209077c6 100644
--- a/arch/arm/mm/proc-v7m.S
+++ b/arch/arm/mm/proc-v7m.S
@@ -98,7 +98,7 @@ __v7m_setup:
str r5, [r0, V7M_SCB_SHPR3] @ set PendSV priority
@ SVC to run the kernel in this mode
- adr r1, BSYM(1f)
+ badr r1, 1f
ldr r5, [r12, #11 * 4] @ read the SVC vector entry
str r1, [r12, #11 * 4] @ write the temporary SVC vector entry
mov r6, lr @ save LR
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related [flat|nested] 669+ messages in thread* your mail
2015-04-21 12:50 ` Russell King - ARM Linux
@ 2015-04-21 13:10 ` Ard Biesheuvel
2015-04-21 13:21 ` Dave P Martin
2015-04-21 13:18 ` Dave P Martin
1 sibling, 1 reply; 669+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 13:10 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 14:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> We should probably create a badr macro to complement the adr pseudo-op
>> which incorporates the BSYM thing so make this clearer - and a comment
>> before it. This is really the case where BSYM should be used.
>
> Something like this. Note that I've also removed the BSYM() usage in
> the KVM code.
>
Yes, that is much better. It is a pity that we still can't use '| 1'
but the fact that you are forced to use 'adr' now probably mostly
eliminates the risk regarding that.
I did notice that are are 4 or 5 instances (commented inline) of an
ARM to thumb mode switch which can just as easily be implemented as
'blx 1f' instead of using this badr macro (whose use we want to
discourage, I assume, since the address arithmetic is still slightly
dodgy). Do you think we should do something about that as well?
> arch/arm/boot/compressed/head.S | 4 ++--
> arch/arm/common/mcpm_head.S | 2 +-
> arch/arm/include/asm/assembler.h | 17 ++++++++++++++++-
> arch/arm/include/asm/entry-macro-multi.S | 4 ++--
> arch/arm/include/asm/unified.h | 2 --
> arch/arm/kernel/entry-armv.S | 12 ++++++------
> arch/arm/kernel/entry-common.S | 6 +++---
> arch/arm/kernel/entry-ftrace.S | 2 +-
> arch/arm/kernel/head-nommu.S | 6 +++---
> arch/arm/kernel/head.S | 8 ++++----
> arch/arm/kernel/sleep.S | 2 +-
> arch/arm/kvm/interrupts.S | 2 +-
> arch/arm/lib/call_with_stack.S | 2 +-
> arch/arm/mm/proc-v7m.S | 2 +-
> 14 files changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 2c45b5709fa4..06e983f59980 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -130,7 +130,7 @@ start:
> .endr
> ARM( mov r0, r0 )
> ARM( b 1f )
> - THUMB( adr r12, BSYM(1f) )
> + THUMB( badr r12, 1f )
> THUMB( bx r12 )
>
blx 1f
> .word _magic_sig @ Magic numbers to help the loader
> @@ -447,7 +447,7 @@ dtb_check_done:
>
> bl cache_clean_flush
>
> - adr r0, BSYM(restart)
> + badr r0, restart
> add r0, r0, r6
> mov pc, r0
>
> diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
> index e02db4b81a66..08b3bb9bc6a2 100644
> --- a/arch/arm/common/mcpm_head.S
> +++ b/arch/arm/common/mcpm_head.S
> @@ -49,7 +49,7 @@
> ENTRY(mcpm_entry_point)
>
> ARM_BE8(setend be)
> - THUMB( adr r12, BSYM(1f) )
> + THUMB( badr r12, 1f )
> THUMB( bx r12 )
> THUMB( .thumb )
> 1:
likewise
> [...]
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 84da14b7cd04..c9660167ef1a 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -46,7 +46,7 @@ ENTRY(stext)
> .arm
> ENTRY(stext)
>
> - THUMB( adr r9, BSYM(1f) ) @ Kernel is always entered in ARM.
> + THUMB( badr r9, 1f ) @ Kernel is always entered in ARM.
> THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
> THUMB( .thumb ) @ switch to Thumb now.
> THUMB(1: )
likewise
> @@ -79,7 +79,7 @@ ENTRY(stext)
> #endif
> ldr r13, =__mmap_switched @ address to jump to after
> @ initialising sctlr
> - adr lr, BSYM(1f) @ return (PIC) address
> + badr lr, 1f @ return (PIC) address
> ldr r12, [r10, #PROCINFO_INITFUNC]
> add r12, r12, r10
> ret r12
> @@ -115,7 +115,7 @@ ENTRY(secondary_startup)
> bl __setup_mpu @ Initialize the MPU
> #endif
>
> - adr lr, BSYM(__after_proc_init) @ return address
> + badr lr, __after_proc_init @ return address
> mov r13, r12 @ __secondary_switched address
> ldr r12, [r10, #PROCINFO_INITFUNC]
> add r12, r12, r10
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 7304b4c44b52..1eecd57453be 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -80,7 +80,7 @@
> ENTRY(stext)
> ARM_BE8(setend be ) @ ensure we are in BE8 mode
>
> - THUMB( adr r9, BSYM(1f) ) @ Kernel is always entered in ARM.
> + THUMB( badr r9, 1f ) @ Kernel is always entered in ARM.
> THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
> THUMB( .thumb ) @ switch to Thumb now.
> THUMB(1: )
likewise
> @@ -148,7 +148,7 @@ ENTRY(stext)
> */
> ldr r13, =__mmap_switched @ address to jump to after
> @ mmu has been enabled
> - adr lr, BSYM(1f) @ return (PIC) address
> + badr lr, 1f @ return (PIC) address
> #ifdef CONFIG_ARM_LPAE
> mov r5, #0 @ high TTBR0
> mov r8, r4, lsr #12 @ TTBR1 is swapper_pg_dir pfn
> @@ -364,7 +364,7 @@ __turn_mmu_on_loc:
> .text
> ENTRY(secondary_startup_arm)
> .arm
> - THUMB( adr r9, BSYM(1f) ) @ Kernel is entered in ARM.
> + THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
> THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
> THUMB( .thumb ) @ switch to Thumb now.
> THUMB(1: )
likewise
--
Ard.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 13:10 ` Ard Biesheuvel
@ 2015-04-21 13:21 ` Dave P Martin
2015-04-21 13:28 ` Ard Biesheuvel
2015-04-21 14:05 ` Russell King - ARM Linux
0 siblings, 2 replies; 669+ messages in thread
From: Dave P Martin @ 2015-04-21 13:21 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 14:50, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> We should probably create a badr macro to complement the adr pseudo-op
> >> which incorporates the BSYM thing so make this clearer - and a comment
> >> before it. This is really the case where BSYM should be used.
> >
> > Something like this. Note that I've also removed the BSYM() usage in
> > the KVM code.
> >
>
> Yes, that is much better. It is a pity that we still can't use '| 1'
> but the fact that you are forced to use 'adr' now probably mostly
> eliminates the risk regarding that.
>
> I did notice that are are 4 or 5 instances (commented inline) of an
> ARM to thumb mode switch which can just as easily be implemented as
> 'blx 1f' instead of using this badr macro (whose use we want to
> discourage, I assume, since the address arithmetic is still slightly
> dodgy). Do you think we should do something about that as well?
Err, probably. That just looks like an oversight -- I think I'm
responsible for at least some of those.
There's no good reason not to replace adr+BSYM+bx.
For switches from ARM, this could be replaced with bx <label> which
should work just fine. There shouldn't be any instances of this from
Thumb, because switching instruction set is the whole point here.
(Thumb doesn't have bx <label>, but blx <label> is available at the cost
of clobbering lr).
Cheers
---Dave
[...]
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 13:21 ` Dave P Martin
@ 2015-04-21 13:28 ` Ard Biesheuvel
2015-04-21 15:51 ` Dave Martin
2015-04-21 14:05 ` Russell King - ARM Linux
1 sibling, 1 reply; 669+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 13:28 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 15:21, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 14:50, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> >> We should probably create a badr macro to complement the adr pseudo-op
>> >> which incorporates the BSYM thing so make this clearer - and a comment
>> >> before it. This is really the case where BSYM should be used.
>> >
>> > Something like this. Note that I've also removed the BSYM() usage in
>> > the KVM code.
>> >
>>
>> Yes, that is much better. It is a pity that we still can't use '| 1'
>> but the fact that you are forced to use 'adr' now probably mostly
>> eliminates the risk regarding that.
>>
>> I did notice that are are 4 or 5 instances (commented inline) of an
>> ARM to thumb mode switch which can just as easily be implemented as
>> 'blx 1f' instead of using this badr macro (whose use we want to
>> discourage, I assume, since the address arithmetic is still slightly
>> dodgy). Do you think we should do something about that as well?
>
> Err, probably. That just looks like an oversight -- I think I'm
> responsible for at least some of those.
>
> There's no good reason not to replace adr+BSYM+bx.
>
> For switches from ARM, this could be replaced with bx <label> which
> should work just fine. There shouldn't be any instances of this from
> Thumb, because switching instruction set is the whole point here.
>
> (Thumb doesn't have bx <label>, but blx <label> is available at the cost
> of clobbering lr).
>
It appears neither have 'bx <label>', but 'add pc, pc, #1; nop' does
the job nicely as well.
And as you say, there are no instances of Thumb->ARM mode switches.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 13:28 ` Ard Biesheuvel
@ 2015-04-21 15:51 ` Dave Martin
0 siblings, 0 replies; 669+ messages in thread
From: Dave Martin @ 2015-04-21 15:51 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 03:28:14PM +0200, Ard Biesheuvel wrote:
> On 21 April 2015 at 15:21, Dave P Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> >> On 21 April 2015 at 14:50, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> >> We should probably create a badr macro to complement the adr pseudo-op
> >> >> which incorporates the BSYM thing so make this clearer - and a comment
> >> >> before it. This is really the case where BSYM should be used.
> >> >
> >> > Something like this. Note that I've also removed the BSYM() usage in
> >> > the KVM code.
> >> >
> >>
> >> Yes, that is much better. It is a pity that we still can't use '| 1'
> >> but the fact that you are forced to use 'adr' now probably mostly
> >> eliminates the risk regarding that.
> >>
> >> I did notice that are are 4 or 5 instances (commented inline) of an
> >> ARM to thumb mode switch which can just as easily be implemented as
> >> 'blx 1f' instead of using this badr macro (whose use we want to
> >> discourage, I assume, since the address arithmetic is still slightly
> >> dodgy). Do you think we should do something about that as well?
> >
> > Err, probably. That just looks like an oversight -- I think I'm
> > responsible for at least some of those.
> >
> > There's no good reason not to replace adr+BSYM+bx.
> >
> > For switches from ARM, this could be replaced with bx <label> which
> > should work just fine. There shouldn't be any instances of this from
> > Thumb, because switching instruction set is the whole point here.
> >
> > (Thumb doesn't have bx <label>, but blx <label> is available at the cost
> > of clobbering lr).
> >
>
> It appears neither have 'bx <label>', but 'add pc, pc, #1; nop' does
Duh, I'm getting myself confused. Yes, both have blx <label> but not
bx <label>.
Note that blx may result in suboptimal branch prediction because it
looks like a function call. But these aren't hot paths, so I doubt
it matters.
> the job nicely as well.
Bit icky though...
Cheers
---Dave
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 13:21 ` Dave P Martin
2015-04-21 13:28 ` Ard Biesheuvel
@ 2015-04-21 14:05 ` Russell King - ARM Linux
1 sibling, 0 replies; 669+ messages in thread
From: Russell King - ARM Linux @ 2015-04-21 14:05 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 02:21:46PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> > Yes, that is much better. It is a pity that we still can't use '| 1'
> > but the fact that you are forced to use 'adr' now probably mostly
> > eliminates the risk regarding that.
> >
> > I did notice that are are 4 or 5 instances (commented inline) of an
> > ARM to thumb mode switch which can just as easily be implemented as
> > 'blx 1f' instead of using this badr macro (whose use we want to
> > discourage, I assume, since the address arithmetic is still slightly
> > dodgy). Do you think we should do something about that as well?
>
> Err, probably. That just looks like an oversight -- I think I'm
> responsible for at least some of those.
>
> There's no good reason not to replace adr+BSYM+bx.
>
> For switches from ARM, this could be replaced with bx <label> which
> should work just fine. There shouldn't be any instances of this from
> Thumb, because switching instruction set is the whole point here.
Where do you get this bx <label> from? It doesn't seem to be in
DDI0406C.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 12:50 ` Russell King - ARM Linux
2015-04-21 13:10 ` Ard Biesheuvel
@ 2015-04-21 13:18 ` Dave P Martin
2015-04-21 13:55 ` Russell King - ARM Linux
1 sibling, 1 reply; 669+ messages in thread
From: Dave P Martin @ 2015-04-21 13:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> > We should probably create a badr macro to complement the adr pseudo-op
> > which incorporates the BSYM thing so make this clearer - and a comment
> > before it. This is really the case where BSYM should be used.
>
> Something like this. Note that I've also removed the BSYM() usage in
> the KVM code.
Nice. Wrapping this around adr will make the assembler check that it's
not a cross-section reference too.
> arch/arm/boot/compressed/head.S | 4 ++--
> arch/arm/common/mcpm_head.S | 2 +-
> arch/arm/include/asm/assembler.h | 17 ++++++++++++++++-
> arch/arm/include/asm/entry-macro-multi.S | 4 ++--
> arch/arm/include/asm/unified.h | 2 --
> arch/arm/kernel/entry-armv.S | 12 ++++++------
> arch/arm/kernel/entry-common.S | 6 +++---
> arch/arm/kernel/entry-ftrace.S | 2 +-
> arch/arm/kernel/head-nommu.S | 6 +++---
> arch/arm/kernel/head.S | 8 ++++----
> arch/arm/kernel/sleep.S | 2 +-
> arch/arm/kvm/interrupts.S | 2 +-
> arch/arm/lib/call_with_stack.S | 2 +-
> arch/arm/mm/proc-v7m.S | 2 +-
> 14 files changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 2c45b5709fa4..06e983f59980 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -130,7 +130,7 @@ start:
> .endr
> ARM( mov r0, r0 )
> ARM( b 1f )
> - THUMB( adr r12, BSYM(1f) )
> + THUMB( badr r12, 1f )
> THUMB( bx r12 )
>
> .word _magic_sig @ Magic numbers to help the loader
> @@ -447,7 +447,7 @@ dtb_check_done:
>
> bl cache_clean_flush
>
> - adr r0, BSYM(restart)
> + badr r0, restart
> add r0, r0, r6
> mov pc, r0
>
> diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
> index e02db4b81a66..08b3bb9bc6a2 100644
> --- a/arch/arm/common/mcpm_head.S
> +++ b/arch/arm/common/mcpm_head.S
> @@ -49,7 +49,7 @@
> ENTRY(mcpm_entry_point)
>
> ARM_BE8(setend be)
> - THUMB( adr r12, BSYM(1f) )
> + THUMB( badr r12, 1f )
> THUMB( bx r12 )
> THUMB( .thumb )
> 1:
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 186270b3e194..4abe57279c66 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -178,6 +178,21 @@
> .endm
>
> /*
> + * Assembly version of "adr rd, BSYM(sym)". This should only be used to
> + * reference local symbols in the same assembly file which are to be
> + * resolved by the assembler. Other usage is undefined.
BSYM() is gone, so this comment shouldn't refer to it...
> + */
> + .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
This wrap-macro-with-cc idiom could be factored, but it may not be worth
it just yet.
[...]
Cheers
---Dave
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 13:18 ` Dave P Martin
@ 2015-04-21 13:55 ` Russell King - ARM Linux
2015-04-21 14:06 ` Ard Biesheuvel
0 siblings, 1 reply; 669+ messages in thread
From: Russell King - ARM Linux @ 2015-04-21 13:55 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> > > We should probably create a badr macro to complement the adr pseudo-op
> > > which incorporates the BSYM thing so make this clearer - and a comment
> > > before it. This is really the case where BSYM should be used.
> >
> > Something like this. Note that I've also removed the BSYM() usage in
> > the KVM code.
>
> Nice. Wrapping this around adr will make the assembler check that it's
> not a cross-section reference too.
While looking at this, I've become very upset with our toolchain's
abilities. This is with stock binutils 2.22-2.25, and Ard's suggestion
for using blx:
00000000 <secondary_startup_arm>:
0: fafffffe blx 4 <secondary_startup>
00000004 <secondary_startup>:
4: f7ff fffe bl 0 <__hyp_stub_install_secondary>
8: f3ef 8900 mrs r9, CPSR
c: f089 091a eor.w r9, r9, #26
10: f019 0f1f tst.w r9, #31
That's fine, but now if we look at the .head.text section (I also added
an ENTRY(start) to try and solve this):
00000000 <stext>:
0: ffff faff ; <UNDEFINED> instruction: 0xfffffaff
00000004 <start>:
4: fffef7ff .word 0xfffef7ff
8: f3ef 8900 mrs r9, CPSR
c: 091af089 .word 0x091af089
10: f019 0f1f tst.w r9, #31
14: 091ff029 .word 0x091ff029
18: 09d3f049 .word 0x09d3f049
1c: f049 0920 orr.w r9, r9, #32
20: f449d109 .word 0xf449d109
24: f20f7980 .word 0xf20f7980
28: 0e13 lsrs r3, r2, #24
2a: f399 .short 0xf399
2c: 8f00 ldrh r0, [r0, #56] ; 0x38
2e: f38e .short 0xf38e
30: f3de8e30 .word 0xf3de8e30
34: 8f00 .short 0x8f00
36: f389 8100 msr CPSR_c, r9
readelf for this shows for section 5:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 5] .head.text PROGBITS 00000000 000290 000254 00 AX 0 0 4
...
Num: Value Size Type Bind Vis Ndx Name
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 NOTYPE LOCAL DEFAULT 5 $a
6: 00000004 0 NOTYPE LOCAL DEFAULT 5 $t
7: 0000002e 0 NOTYPE LOCAL DEFAULT 5 $d
8: 00000036 0 NOTYPE LOCAL DEFAULT 5 $t
...
65: 00000000 4 FUNC GLOBAL DEFAULT 5 stext
66: 00000005 122 FUNC GLOBAL DEFAULT 5 start
One has to wonder about the toolchain when the stupid $[adt] hack seems
to be going soooo wrong.
I think I'm going to stop working on this until we have a toolchain
which behaves sensibly... when you can't get the damned thing to
disassemble for confirmation purposes, its best to leave the damned
code alone.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 669+ messages in thread* your mail
2015-04-21 13:55 ` Russell King - ARM Linux
@ 2015-04-21 14:06 ` Ard Biesheuvel
2015-04-21 17:03 ` Dave Martin
0 siblings, 1 reply; 669+ messages in thread
From: Ard Biesheuvel @ 2015-04-21 14:06 UTC (permalink / raw)
To: linux-arm-kernel
On 21 April 2015 at 15:55, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
>> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
>> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> > > We should probably create a badr macro to complement the adr pseudo-op
>> > > which incorporates the BSYM thing so make this clearer - and a comment
>> > > before it. This is really the case where BSYM should be used.
>> >
>> > Something like this. Note that I've also removed the BSYM() usage in
>> > the KVM code.
>>
>> Nice. Wrapping this around adr will make the assembler check that it's
>> not a cross-section reference too.
>
> While looking at this, I've become very upset with our toolchain's
> abilities. This is with stock binutils 2.22-2.25, and Ard's suggestion
> for using blx:
>
> 00000000 <secondary_startup_arm>:
> 0: fafffffe blx 4 <secondary_startup>
>
> 00000004 <secondary_startup>:
> 4: f7ff fffe bl 0 <__hyp_stub_install_secondary>
> 8: f3ef 8900 mrs r9, CPSR
> c: f089 091a eor.w r9, r9, #26
> 10: f019 0f1f tst.w r9, #31
>
> That's fine, but now if we look at the .head.text section (I also added
> an ENTRY(start) to try and solve this):
>
> 00000000 <stext>:
> 0: ffff faff ; <UNDEFINED> instruction: 0xfffffaff
>
> 00000004 <start>:
> 4: fffef7ff .word 0xfffef7ff
> 8: f3ef 8900 mrs r9, CPSR
> c: 091af089 .word 0x091af089
> 10: f019 0f1f tst.w r9, #31
> 14: 091ff029 .word 0x091ff029
> 18: 09d3f049 .word 0x09d3f049
> 1c: f049 0920 orr.w r9, r9, #32
> 20: f449d109 .word 0xf449d109
> 24: f20f7980 .word 0xf20f7980
> 28: 0e13 lsrs r3, r2, #24
> 2a: f399 .short 0xf399
> 2c: 8f00 ldrh r0, [r0, #56] ; 0x38
> 2e: f38e .short 0xf38e
> 30: f3de8e30 .word 0xf3de8e30
> 34: 8f00 .short 0x8f00
> 36: f389 8100 msr CPSR_c, r9
>
> readelf for this shows for section 5:
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> [ 5] .head.text PROGBITS 00000000 000290 000254 00 AX 0 0 4
> ...
> Num: Value Size Type Bind Vis Ndx Name
> 4: 00000000 0 SECTION LOCAL DEFAULT 5
> 5: 00000000 0 NOTYPE LOCAL DEFAULT 5 $a
> 6: 00000004 0 NOTYPE LOCAL DEFAULT 5 $t
> 7: 0000002e 0 NOTYPE LOCAL DEFAULT 5 $d
> 8: 00000036 0 NOTYPE LOCAL DEFAULT 5 $t
> ...
> 65: 00000000 4 FUNC GLOBAL DEFAULT 5 stext
> 66: 00000005 122 FUNC GLOBAL DEFAULT 5 start
>
> One has to wonder about the toolchain when the stupid $[adt] hack seems
> to be going soooo wrong.
>
> I think I'm going to stop working on this until we have a toolchain
> which behaves sensibly... when you can't get the damned thing to
> disassemble for confirmation purposes, its best to leave the damned
> code alone.
>
It indeed seems to be objdump that is failing, but the code itself
looks fine to me. For the record, binutils v2.23.52 works fine
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2015-04-21 14:06 ` Ard Biesheuvel
@ 2015-04-21 17:03 ` Dave Martin
0 siblings, 0 replies; 669+ messages in thread
From: Dave Martin @ 2015-04-21 17:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Apr 21, 2015 at 04:06:02PM +0200, Ard Biesheuvel wrote:
> On 21 April 2015 at 15:55, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
> >> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> >> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> > > We should probably create a badr macro to complement the adr pseudo-op
> >> > > which incorporates the BSYM thing so make this clearer - and a comment
> >> > > before it. This is really the case where BSYM should be used.
> >> >
> >> > Something like this. Note that I've also removed the BSYM() usage in
> >> > the KVM code.
> >>
> >> Nice. Wrapping this around adr will make the assembler check that it's
> >> not a cross-section reference too.
> >
> > While looking at this, I've become very upset with our toolchain's
> > abilities. This is with stock binutils 2.22-2.25, and Ard's suggestion
> > for using blx:
> >
> > 00000000 <secondary_startup_arm>:
> > 0: fafffffe blx 4 <secondary_startup>
> >
> > 00000004 <secondary_startup>:
> > 4: f7ff fffe bl 0 <__hyp_stub_install_secondary>
> > 8: f3ef 8900 mrs r9, CPSR
> > c: f089 091a eor.w r9, r9, #26
> > 10: f019 0f1f tst.w r9, #31
> >
> > That's fine, but now if we look at the .head.text section (I also added
> > an ENTRY(start) to try and solve this):
> >
> > 00000000 <stext>:
> > 0: ffff faff ; <UNDEFINED> instruction: 0xfffffaff
> >
> > 00000004 <start>:
> > 4: fffef7ff .word 0xfffef7ff
> > 8: f3ef 8900 mrs r9, CPSR
> > c: 091af089 .word 0x091af089
> > 10: f019 0f1f tst.w r9, #31
> > 14: 091ff029 .word 0x091ff029
> > 18: 09d3f049 .word 0x09d3f049
> > 1c: f049 0920 orr.w r9, r9, #32
> > 20: f449d109 .word 0xf449d109
> > 24: f20f7980 .word 0xf20f7980
> > 28: 0e13 lsrs r3, r2, #24
> > 2a: f399 .short 0xf399
> > 2c: 8f00 ldrh r0, [r0, #56] ; 0x38
> > 2e: f38e .short 0xf38e
> > 30: f3de8e30 .word 0xf3de8e30
> > 34: 8f00 .short 0x8f00
> > 36: f389 8100 msr CPSR_c, r9
> >
> > readelf for this shows for section 5:
> >
> > Section Headers:
> > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> > [ 5] .head.text PROGBITS 00000000 000290 000254 00 AX 0 0 4
> > ...
> > Num: Value Size Type Bind Vis Ndx Name
> > 4: 00000000 0 SECTION LOCAL DEFAULT 5
> > 5: 00000000 0 NOTYPE LOCAL DEFAULT 5 $a
> > 6: 00000004 0 NOTYPE LOCAL DEFAULT 5 $t
> > 7: 0000002e 0 NOTYPE LOCAL DEFAULT 5 $d
> > 8: 00000036 0 NOTYPE LOCAL DEFAULT 5 $t
> > ...
> > 65: 00000000 4 FUNC GLOBAL DEFAULT 5 stext
> > 66: 00000005 122 FUNC GLOBAL DEFAULT 5 start
> >
> > One has to wonder about the toolchain when the stupid $[adt] hack seems
> > to be going soooo wrong.
> >
> > I think I'm going to stop working on this until we have a toolchain
> > which behaves sensibly... when you can't get the damned thing to
> > disassemble for confirmation purposes, its best to leave the damned
> > code alone.
> >
>
> It indeed seems to be objdump that is failing, but the code itself
> looks fine to me. For the record, binutils v2.23.52 works fine
I've come across weird disassembly issues like this in the past.
The objdump code is something of a fragmented mess (shock, horror),
but I think there were fixes in the pipeline for some issues of this
sort.
If it is possible to manually check most or all of the cases of
badr, that might be sufficient -- this only gets used in a few,
specific places.
Objdump doesn't inspire much confidence though :(
Cheers
---Dave
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20150121201024.GA4548@obsidianresearch.com>]
* No subject
@ 2014-10-28 14:13 Mark Rutland
2014-10-28 14:19 ` your mail Mark Rutland
0 siblings, 1 reply; 669+ messages in thread
From: Mark Rutland @ 2014-10-28 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Bcc:
Subject: Re: [PATCHv4 7/7] arm64: add better page protections to arm64
Reply-To:
In-Reply-To: <1414440752-9411-8-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
> Add page protections for arm64 similar to those in arm.
> This is for security reasons to prevent certain classes
> of exploits. The current method:
>
> - Map all memory as either RWX or RW. We round to the nearest
> section to avoid creating page tables before everything is mapped
> - Once everything is mapped, if either end of the RWX section should
> not be X, we split the PMD and remap as necessary
> - When initmem is to be freed, we change the permissions back to
> RW (using stop machine if necessary to flush the TLB)
> - If CONFIG_DEBUG_RODATA is set, the read only sections are set
> read only.
>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> v4: Combined the Kconfig options
> ---
> arch/arm64/Kconfig.debug | 23 +++
> arch/arm64/include/asm/cacheflush.h | 4 +
> arch/arm64/kernel/vmlinux.lds.S | 17 ++
> arch/arm64/mm/init.c | 1 +
> arch/arm64/mm/mm.h | 2 +
> arch/arm64/mm/mmu.c | 303 +++++++++++++++++++++++++++++++-----
> 6 files changed, 314 insertions(+), 36 deletions(-)
With this patch applied to v3.18-rc2, my board to blows up at boot when
using UEFI (without DEBUG_RODATA selected):
---->8----
EFI stub: Booting Linux Kernel...
Initializing cgroup subsys cpu
Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
CPU: AArch64 Processor [410fd030] revision 0
Detected VIPT I-cache on CPU0
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.40 by ARM Juno EFI Oct 7 2014 15:05:42
efi: ACPI=0xfebdc000 ACPI 2.0=0xfebdc014
cma: Reserved 16 MiB at fd800000
BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
Kernel panic - not syncing: BUG!
CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
Call trace:
[<ffffffc000087ec8>] dump_backtrace+0x0/0x124
[<ffffffc000087ffc>] show_stack+0x10/0x1c
[<ffffffc0004ebd58>] dump_stack+0x74/0xb8
[<ffffffc0004eb018>] panic+0xe0/0x220
[<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
[<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
[<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
[<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
[<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
[<ffffffc0006978a8>] setup_arch+0x408/0x5c0
[<ffffffc00069566c>] start_kernel+0x94/0x3a0
---[ end Kernel panic - not syncing: BUG!
---->8----
I've not yet figured out precisely why. I haven't tried a !EFI boot
because of the way my board is set up at the moment.
Mark.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2014-10-28 14:13 No subject Mark Rutland
@ 2014-10-28 14:19 ` Mark Rutland
0 siblings, 0 replies; 669+ messages in thread
From: Mark Rutland @ 2014-10-28 14:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 28, 2014 at 02:13:25PM +0000, Mark Rutland wrote:
> Bcc:
> Subject: Re: [PATCHv4 7/7] arm64: add better page protections to arm64
> Reply-To:
> In-Reply-To: <1414440752-9411-8-git-send-email-lauraa@codeaurora.org>
Apologies for this, I appear to have accidentally inserted a newline and
confused my mail client. I'll resend this with that fixed.
Mark.
>
> Hi Laura,
>
> On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
> > Add page protections for arm64 similar to those in arm.
> > This is for security reasons to prevent certain classes
> > of exploits. The current method:
> >
> > - Map all memory as either RWX or RW. We round to the nearest
> > section to avoid creating page tables before everything is mapped
> > - Once everything is mapped, if either end of the RWX section should
> > not be X, we split the PMD and remap as necessary
> > - When initmem is to be freed, we change the permissions back to
> > RW (using stop machine if necessary to flush the TLB)
> > - If CONFIG_DEBUG_RODATA is set, the read only sections are set
> > read only.
> >
> > Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> > ---
> > v4: Combined the Kconfig options
> > ---
> > arch/arm64/Kconfig.debug | 23 +++
> > arch/arm64/include/asm/cacheflush.h | 4 +
> > arch/arm64/kernel/vmlinux.lds.S | 17 ++
> > arch/arm64/mm/init.c | 1 +
> > arch/arm64/mm/mm.h | 2 +
> > arch/arm64/mm/mmu.c | 303 +++++++++++++++++++++++++++++++-----
> > 6 files changed, 314 insertions(+), 36 deletions(-)
>
> With this patch applied to v3.18-rc2, my board to blows up at boot when
> using UEFI (without DEBUG_RODATA selected):
>
> ---->8----
> EFI stub: Booting Linux Kernel...
> Initializing cgroup subsys cpu
> Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
> CPU: AArch64 Processor [410fd030] revision 0
> Detected VIPT I-cache on CPU0
> bootconsole [uart0] enabled
> efi: Getting EFI parameters from FDT:
> EFI v2.40 by ARM Juno EFI Oct 7 2014 15:05:42
> efi: ACPI=0xfebdc000 ACPI 2.0=0xfebdc014
> cma: Reserved 16 MiB at fd800000
> BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
> Kernel panic - not syncing: BUG!
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
> Call trace:
> [<ffffffc000087ec8>] dump_backtrace+0x0/0x124
> [<ffffffc000087ffc>] show_stack+0x10/0x1c
> [<ffffffc0004ebd58>] dump_stack+0x74/0xb8
> [<ffffffc0004eb018>] panic+0xe0/0x220
> [<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
> [<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
> [<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
> [<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
> [<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
> [<ffffffc0006978a8>] setup_arch+0x408/0x5c0
> [<ffffffc00069566c>] start_kernel+0x94/0x3a0
> ---[ end Kernel panic - not syncing: BUG!
> ---->8----
>
> I've not yet figured out precisely why. I haven't tried a !EFI boot
> because of the way my board is set up at the moment.
>
> Mark.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2014-10-15 8:10 Christoph Lameter
2014-10-27 15:07 ` your mail Tejun Heo
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Lameter @ 2014-10-15 8:10 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel
Subject: Convert remaining __get_cpu_var uses
During the 3.18 merge period additional __get_cpu_var uses were
added. The patch converts these to this_cpu_ptr().
[This does not address the powerpc issue where the conversion
patches were routed directly to the powerpc maintainers but were
not applied in the merge period. Will have to be handled separately]
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/arch/arm/xen/mm32.c
===================================================================
--- linux.orig/arch/arm/xen/mm32.c
+++ linux/arch/arm/xen/mm32.c
@@ -56,7 +56,7 @@ static struct notifier_block xen_mm32_cp
static void* xen_mm32_remap_page(dma_addr_t handle)
{
unsigned long virt = get_cpu_var(xen_mm32_scratch_virt);
- pte_t *ptep = __get_cpu_var(xen_mm32_scratch_ptep);
+ pte_t *ptep = __this_cpu_read(xen_mm32_scratch_ptep);
*ptep = pfn_pte(handle >> PAGE_SHIFT, PAGE_KERNEL);
local_flush_tlb_kernel_page(virt);
Index: linux/arch/arm64/kernel/psci.c
===================================================================
--- linux.orig/arch/arm64/kernel/psci.c
+++ linux/arch/arm64/kernel/psci.c
@@ -511,7 +511,7 @@ static int cpu_psci_cpu_kill(unsigned in
static int psci_suspend_finisher(unsigned long index)
{
- struct psci_power_state *state = __get_cpu_var(psci_power_state);
+ struct psci_power_state *state = __this_cpu_read(psci_power_state);
return psci_ops.cpu_suspend(state[index - 1],
virt_to_phys(cpu_resume));
@@ -520,7 +520,7 @@ static int psci_suspend_finisher(unsigne
static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
{
int ret;
- struct psci_power_state *state = __get_cpu_var(psci_power_state);
+ struct psci_power_state *state = __this_cpu_read(psci_power_state);
/*
* idle state index 0 corresponds to wfi, should never be called
* from the cpu_suspend operations
Index: linux/kernel/irq_work.c
===================================================================
--- linux.orig/kernel/irq_work.c
+++ linux/kernel/irq_work.c
@@ -175,11 +175,11 @@ EXPORT_SYMBOL_GPL(irq_work_run);
void irq_work_tick(void)
{
- struct llist_head *raised = &__get_cpu_var(raised_list);
+ struct llist_head *raised = this_cpu_ptr(&raised_list);
if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
irq_work_run_list(raised);
- irq_work_run_list(&__get_cpu_var(lazy_list));
+ irq_work_run_list(this_cpu_ptr(&lazy_list));
}
/*
Index: linux/kernel/time/tick-sched.c
===================================================================
--- linux.orig/kernel/time/tick-sched.c
+++ linux/kernel/time/tick-sched.c
@@ -235,7 +235,7 @@ void tick_nohz_full_kick(void)
if (!tick_nohz_full_cpu(smp_processor_id()))
return;
- irq_work_queue(&__get_cpu_var(nohz_full_kick_work));
+ irq_work_queue(this_cpu_ptr(&nohz_full_kick_work));
}
/*
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2014-10-15 8:10 Christoph Lameter
@ 2014-10-27 15:07 ` Tejun Heo
0 siblings, 0 replies; 669+ messages in thread
From: Tejun Heo @ 2014-10-27 15:07 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-kernel
Hello, Christoph.
On Wed, Oct 15, 2014 at 03:10:37AM -0500, Christoph Lameter wrote:
> Subject: Convert remaining __get_cpu_var uses
>
> During the 3.18 merge period additional __get_cpu_var uses were
> added. The patch converts these to this_cpu_ptr().
>
> [This does not address the powerpc issue where the conversion
> patches were routed directly to the powerpc maintainers but were
> not applied in the merge period. Will have to be handled separately]
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
Can you please repost with proper subject line and the subsys
maintainers cc'd?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2014-09-01 15:47 sunwxg
2014-09-01 17:01 ` your mail Dan Carpenter
0 siblings, 1 reply; 669+ messages in thread
From: sunwxg @ 2014-09-01 15:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Dulshani Gunawardhana, Josh Triplett,
John L. Hammond, Andreas Dilger, Chi Pham, Oleg Drokin
Cc: Sun Wang, devel, linux-kernel
From: Sun Wang <sun.wxg@gmail.com>
Subject: [PATCH] staging: lustre: lov_pack: fix coding style issue
Fix the style error checking by checkpatch.pl
ERROR: space required after that ','
Signed-off-by: Sun Wang <sun.wxg@gmail.com>
---
drivers/staging/lustre/lustre/lov/lov_pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/lov/lov_pack.c b/drivers/staging/lustre/lustre/lov/lov_pack.c
index 20e5870..62ea223 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pack.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pack.c
@@ -95,7 +95,7 @@ void lov_dump_lmm_v1(int level, struct lov_mds_md_v1 *lmm)
void lov_dump_lmm_v3(int level, struct lov_mds_md_v3 *lmm)
{
lov_dump_lmm_common(level, lmm);
- CDEBUG(level,"pool_name "LOV_POOLNAMEF"\n", lmm->lmm_pool_name);
+ CDEBUG(level, "pool_name "LOV_POOLNAMEF"\n", lmm->lmm_pool_name);
lov_dump_lmm_objects(level, lmm->lmm_objects,
le16_to_cpu(lmm->lmm_stripe_count));
}
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2014-09-01 15:47 sunwxg
@ 2014-09-01 17:01 ` Dan Carpenter
0 siblings, 0 replies; 669+ messages in thread
From: Dan Carpenter @ 2014-09-01 17:01 UTC (permalink / raw)
To: sunwxg
Cc: Greg Kroah-Hartman, Dulshani Gunawardhana, Josh Triplett,
John L. Hammond, Andreas Dilger, Chi Pham, Oleg Drokin, devel,
linux-kernel
No subject.
It should be a subject about adding spaces.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <1409556896-21523-2-git-send-email-xiaoguang_wang5188@qq.com>]
* Re: your mail
[not found] <1409556896-21523-2-git-send-email-xiaoguang_wang5188@qq.com>
@ 2014-09-01 8:04 ` Dan Carpenter
0 siblings, 0 replies; 669+ messages in thread
From: Dan Carpenter @ 2014-09-01 8:04 UTC (permalink / raw)
To: sunwxg
Cc: Benjamin Romer, David Kershner, Greg Kroah-Hartman, Ken Cox,
Iulia Manda, Luis R. Rodriguez, Masaru Nomura, devel,
sparmaintainer, linux-kernel
On Mon, Sep 01, 2014 at 03:34:56PM +0800, sunwxg wrote:
> From: Sun Wang <xiaoguang_wang5188@qq.com>
>
> Subject: [PATCH] staging: unisys: visorutil: procobjecttree: fix coding style issue
>
Your email headers are mangled. The subject is vague.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2014-07-09 1:03 James Ban
2014-07-09 7:56 ` your mail Mark Brown
0 siblings, 1 reply; 669+ messages in thread
From: James Ban @ 2014-07-09 1:03 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, Support Opensource, LKML, David Dajun Chen
> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Tuesday, July 08, 2014 4:36 PM
> To: Opensource [James Seong-Won Ban]
> Cc: Liam Girdwood; Support Opensource; LKML; David Dajun Chen
> Subject: Re: [PATCH V4] regulator: DA9211 : new regulator driver
>
> On Thu, Jul 03, 2014 at 04:29:03PM +0900, James Ban wrote:
>
> This is greatly improved, thanks, however there are still a few issues which
> should be addressed:
>
> > +static irqreturn_t da9211_irq_handler(int irq, void *data) {
> > + struct da9211 *chip = data;
> > + int reg_val, ret;
> > +
> > + ret = regmap_read(chip->regmap, DA9211_REG_EVENT_B, ®_val);
> > + if (ret < 0)
> > + goto error_i2c;
> > +
> > + if (reg_val & DA9211_E_OV_CURR_A) {
>
> > + if (reg_val & DA9211_E_OV_CURR_B) {
>
> > +
> > + return IRQ_HANDLED;
>
> This is buggy - the driver should only return IRQ_HANDLED if it handled the
> interrupt somehow, otherwise it should return IRQ_NONE and let the interrupt
> core handle things. This is especially important since the device appears to
> require that interrupts are explicitly acknoweldged so if something is flagged
> but not handled the interrupt will just sit constantly asserted.
Basically all interrupts are masked when the chip wakes up.
Only two interrupts are unmasked at the start of driver like below.
-------------
if (chip->chip_irq != 0) {
ret = regmap_update_bits(chip->regmap,
DA9211_REG_MASK_B, DA9211_M_OV_CURR_A << i, 1);
-----------------
So constant assertion which you are worry about could not happen.
Please let me know if you think other case.
>
> > +static int da9211_regulator_init(struct da9211 *chip) {
> > + struct regulator_config config = { };
> > + int i, ret;
> > + unsigned int data;
> > +
> > + ret = regmap_update_bits(chip->regmap, DA9211_REG_PAGE_CON,
> > + DA9211_REG_PAGE_MASK, DA9211_REG_PAGE2);
> > + if (ret < 0) {
> > + dev_err(chip->dev, "Failed to update PAGE reg: %d\n", ret);
> > + goto err;
> > + }
>
> It would be better to model the paging in the register map in the regmap
> - the API has support for this, it's going to be more robust to use it.
I will change the code for the usage of the API.
>
> > + dev_info(chip->dev, "# IRQ configured [%d]\n", chip->chip_irq);
>
> > + for (i = 0; i < chip->num_regulator; i++)
> > + regulator_unregister(chip->rdev[i]);
>
> Use devm_regulator_register().
I will do it.
>
> > + if (chip->chip_irq != 0)
> > + free_irq(chip->chip_irq, chip);
>
> devm_request_threaded_irq().
I will use devm_request_threaded_irq and remove free_irq.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2014-07-09 1:03 James Ban
@ 2014-07-09 7:56 ` Mark Brown
0 siblings, 0 replies; 669+ messages in thread
From: Mark Brown @ 2014-07-09 7:56 UTC (permalink / raw)
To: James Ban; +Cc: Liam Girdwood, Support Opensource, LKML, David Dajun Chen
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On Wed, Jul 09, 2014 at 10:03:32AM +0900, James Ban wrote:
> > > + ret = regmap_read(chip->regmap, DA9211_REG_EVENT_B, ®_val);
> > > + if (ret < 0)
> > > + goto error_i2c;
> > > + if (reg_val & DA9211_E_OV_CURR_A) {
> > > + if (reg_val & DA9211_E_OV_CURR_B) {
> > > + return IRQ_HANDLED;
> > This is buggy - the driver should only return IRQ_HANDLED if it handled the
> > interrupt somehow, otherwise it should return IRQ_NONE and let the interrupt
> > core handle things. This is especially important since the device appears to
> > require that interrupts are explicitly acknoweldged so if something is flagged
> > but not handled the interrupt will just sit constantly asserted.
> Basically all interrupts are masked when the chip wakes up.
> Only two interrupts are unmasked at the start of driver like below.
I know that's the intention but the code should still be written
robustly - something might go wrong somewhere which causes another
interrupt to be enabled, or we might even gain support for shared
threaded interrupts in the interrupt core and someone could then
try to use that in a system.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2014-02-25 11:20 srikanth TS
2014-02-25 15:01 ` Will Deacon
0 siblings, 1 reply; 669+ messages in thread
From: srikanth TS @ 2014-02-25 11:20 UTC (permalink / raw)
To: Will Deacon
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ
[-- Attachment #1.1: Type: text/plain, Size: 1733 bytes --]
On Feb 25, 2014 2:28 AM, "Will Deacon" <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>
> On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > Hi Will Deacon,
>
> Hello,
>
> > Currently SMMU driver expecting all stream ID used by respective master
> > should be defined in the DT.
> >
> > We want to know how to handle in the case of virtual functions
dynamically
> > created and destroyed.
> >
> > Is PCI driver responsible for creating stream ID respective BDand
> > requesting SMMU to add to the mapping table[stream Id to context mapping
> > table]?
> >
> > Or is there any right way of doing it?
>
> Correct, the driver currently doesn't support dynamic mappings (mainly
> because I didn't want to try and invent something that I couldn't test).
>
> There are a couple of ways to solve this:
>
> (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> within a fixed range. That would probably need some code in the bus
> layer, so that a bus notifier can kick and call back to the relevant
> SMMU.
I think first way of solving seems to be better, because we don't know how
many
VF are used and i feel its not good idea to keep whole list of
streamID [which is
equal to max num vf] in DT. Again in this method we need to generate the
stream ID
dynamically whenever VF is added in pci iov driver side. And then pass that
stream ID to SMMU.
Is it ok this way? Or you prefer 2nd way which is simpler.
>
> (2) Describe the RID -> SID mapping in the device-tree. We probably want
> to avoid an enormous table, so this would only work for simple `SID
=
> RID + offset' or 'SID = RID & mask' cases.
>
> How do your IDs map to each other?
>
> Will
-srikanth ts
[-- Attachment #1.2: Type: text/html, Size: 2684 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2014-02-25 15:01 ` Will Deacon
0 siblings, 0 replies; 669+ messages in thread
From: Will Deacon @ 2014-02-25 15:01 UTC (permalink / raw)
To: srikanth TS; +Cc: ts.srikanth, linux-kernel, iommu, sungjinn.chung
On Tue, Feb 25, 2014 at 11:20:11AM +0000, srikanth TS wrote:
>
> On Feb 25, 2014 2:28 AM, "Will Deacon" <will.deacon@arm.com<mailto:will.deacon@arm.com>> wrote:
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective master
> > > should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions dynamically
> > > created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context mapping
> > > table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test).
> >
> > There are a couple of ways to solve this:
> >
> > (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> > within a fixed range. That would probably need some code in the bus
> > layer, so that a bus notifier can kick and call back to the relevant
> > SMMU.
>
> I think first way of solving seems to be better, because we don't know how many
>
> VF are used and i feel its not good idea to keep whole list of streamID [which is
>
> equal to max num vf] in DT. Again in this method we need to generate the stream ID
>
> dynamically whenever VF is added in pci iov driver side. And then pass that
>
> stream ID to SMMU.
>
> Is it ok this way? Or you prefer 2nd way which is simpler.
I'm happy either way, but I'd need to see some patches before I can merge
anything ;)
Will
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2014-02-25 15:01 ` Will Deacon
0 siblings, 0 replies; 669+ messages in thread
From: Will Deacon @ 2014-02-25 15:01 UTC (permalink / raw)
To: srikanth TS
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ
On Tue, Feb 25, 2014 at 11:20:11AM +0000, srikanth TS wrote:
>
> On Feb 25, 2014 2:28 AM, "Will Deacon" <will.deacon-5wv7dgnIgG8@public.gmane.org<mailto:will.deacon-5wv7dgnIgG8@public.gmane.org>> wrote:
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective master
> > > should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions dynamically
> > > created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context mapping
> > > table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test).
> >
> > There are a couple of ways to solve this:
> >
> > (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> > within a fixed range. That would probably need some code in the bus
> > layer, so that a bus notifier can kick and call back to the relevant
> > SMMU.
>
> I think first way of solving seems to be better, because we don't know how many
>
> VF are used and i feel its not good idea to keep whole list of streamID [which is
>
> equal to max num vf] in DT. Again in this method we need to generate the stream ID
>
> dynamically whenever VF is added in pci iov driver side. And then pass that
>
> stream ID to SMMU.
>
> Is it ok this way? Or you prefer 2nd way which is simpler.
I'm happy either way, but I'd need to see some patches before I can merge
anything ;)
Will
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2014-02-24 15:12 srikanth TS
2014-02-24 17:28 ` Will Deacon
0 siblings, 1 reply; 669+ messages in thread
From: srikanth TS @ 2014-02-24 15:12 UTC (permalink / raw)
To: will.deacon-5wv7dgnIgG8
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ
[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]
Hi Will Deacon,
Currently SMMU driver expecting all stream ID used by respective master
should be defined in the DT.
We want to know how to handle in the case of virtual functions dynamically
created and destroyed.
Is PCI driver responsible for creating stream ID respective BDand
requesting SMMU to add to the mapping table[stream Id to context mapping
table]?
Or is there any right way of doing it?
WBRs,
Srikanth.
[-- Attachment #1.2: Type: text/html, Size: 1538 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2014-02-24 17:28 ` Will Deacon
0 siblings, 0 replies; 669+ messages in thread
From: Will Deacon @ 2014-02-24 17:28 UTC (permalink / raw)
To: srikanth TS; +Cc: iommu, linux-kernel, ts.srikanth, sungjinn.chung
On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> Hi Will Deacon,
Hello,
> Currently SMMU driver expecting all stream ID used by respective master
> should be defined in the DT.
>
> We want to know how to handle in the case of virtual functions dynamically
> created and destroyed.
>
> Is PCI driver responsible for creating stream ID respective BDand
> requesting SMMU to add to the mapping table[stream Id to context mapping
> table]?
>
> Or is there any right way of doing it?
Correct, the driver currently doesn't support dynamic mappings (mainly
because I didn't want to try and invent something that I couldn't test).
There are a couple of ways to solve this:
(1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
within a fixed range. That would probably need some code in the bus
layer, so that a bus notifier can kick and call back to the relevant
SMMU.
(2) Describe the RID -> SID mapping in the device-tree. We probably want
to avoid an enormous table, so this would only work for simple `SID =
RID + offset' or 'SID = RID & mask' cases.
How do your IDs map to each other?
Will
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2014-02-24 17:28 ` Will Deacon
0 siblings, 0 replies; 669+ messages in thread
From: Will Deacon @ 2014-02-24 17:28 UTC (permalink / raw)
To: srikanth TS
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ
On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> Hi Will Deacon,
Hello,
> Currently SMMU driver expecting all stream ID used by respective master
> should be defined in the DT.
>
> We want to know how to handle in the case of virtual functions dynamically
> created and destroyed.
>
> Is PCI driver responsible for creating stream ID respective BDand
> requesting SMMU to add to the mapping table[stream Id to context mapping
> table]?
>
> Or is there any right way of doing it?
Correct, the driver currently doesn't support dynamic mappings (mainly
because I didn't want to try and invent something that I couldn't test).
There are a couple of ways to solve this:
(1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
within a fixed range. That would probably need some code in the bus
layer, so that a bus notifier can kick and call back to the relevant
SMMU.
(2) Describe the RID -> SID mapping in the device-tree. We probably want
to avoid an enormous table, so this would only work for simple `SID =
RID + offset' or 'SID = RID & mask' cases.
How do your IDs map to each other?
Will
^ permalink raw reply [flat|nested] 669+ messages in thread* RE: your mail
@ 2014-02-25 11:28 ` Varun Sethi
0 siblings, 0 replies; 669+ messages in thread
From: Varun Sethi @ 2014-02-25 11:28 UTC (permalink / raw)
To: Will Deacon, srikanth TS; +Cc: iommu, sungjinn.chung, linux-kernel, ts.srikanth
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Will Deacon
> Sent: Monday, February 24, 2014 10:59 PM
> To: srikanth TS
> Cc: iommu@lists.linux-foundation.org; sungjinn.chung@samsung.com; linux-
> kernel@vger.kernel.org; ts.srikanth@samsung.com
> Subject: Re: your mail
>
> On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > Hi Will Deacon,
>
> Hello,
>
> > Currently SMMU driver expecting all stream ID used by respective
> > master should be defined in the DT.
> >
> > We want to know how to handle in the case of virtual functions
> > dynamically created and destroyed.
> >
> > Is PCI driver responsible for creating stream ID respective BDand
> > requesting SMMU to add to the mapping table[stream Id to context
> > mapping table]?
> >
> > Or is there any right way of doing it?
>
> Correct, the driver currently doesn't support dynamic mappings (mainly
> because I didn't want to try and invent something that I couldn't test).
>
> There are a couple of ways to solve this:
>
> (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> within a fixed range. That would probably need some code in the bus
> layer, so that a bus notifier can kick and call back to the
> relevant
> SMMU.
This could be done in add device notifier. I am working on similar(not PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC patch by next week.
-Varun
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2014-02-25 11:28 ` Varun Sethi
0 siblings, 0 replies; 669+ messages in thread
From: Varun Sethi @ 2014-02-25 11:28 UTC (permalink / raw)
To: Will Deacon, srikanth TS
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ
> -----Original Message-----
> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> Sent: Monday, February 24, 2014 10:59 PM
> To: srikanth TS
> Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> Subject: Re: your mail
>
> On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > Hi Will Deacon,
>
> Hello,
>
> > Currently SMMU driver expecting all stream ID used by respective
> > master should be defined in the DT.
> >
> > We want to know how to handle in the case of virtual functions
> > dynamically created and destroyed.
> >
> > Is PCI driver responsible for creating stream ID respective BDand
> > requesting SMMU to add to the mapping table[stream Id to context
> > mapping table]?
> >
> > Or is there any right way of doing it?
>
> Correct, the driver currently doesn't support dynamic mappings (mainly
> because I didn't want to try and invent something that I couldn't test).
>
> There are a couple of ways to solve this:
>
> (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> within a fixed range. That would probably need some code in the bus
> layer, so that a bus notifier can kick and call back to the
> relevant
> SMMU.
This could be done in add device notifier. I am working on similar(not PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC patch by next week.
-Varun
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <42a1041ac2df4a73a94dc4516969e35d-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>]
* RE: your mail
[not found] ` <42a1041ac2df4a73a94dc4516969e35d-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
@ 2014-02-26 8:23 ` srikanth TS
[not found] ` <CAM0G4zv7nBLRdiXcFjiarXAhsbA+5MkdWHPysjpn=ydky72Piw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: srikanth TS @ 2014-02-26 8:23 UTC (permalink / raw)
To: Varun Sethi
Cc: Will Deacon, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ
[-- Attachment #1.1: Type: text/plain, Size: 2003 bytes --]
On Feb 25, 2014 8:28 PM, "Varun Sethi" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> > Sent: Monday, February 24, 2014 10:59 PM
> > To: srikanth TS
> > Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> > Subject: Re: your mail
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective
> > > master should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions
> > > dynamically created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context
> > > mapping table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test).
> >
> > There are a couple of ways to solve this:
> >
> > (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an
SMMU
> > within a fixed range. That would probably need some code in the
bus
> > layer, so that a bus notifier can kick and call back to the
> > relevant
> > SMMU.
> This could be done in add device notifier. I am working on similar(not
PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC
patch by next week.
Can you please explain with little more detail. We just want to make sure
your idea fits in for pci iov also.
-Srikanth ts
>
> -Varun
>
[-- Attachment #1.2: Type: text/html, Size: 3095 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2014-01-23 9:06 Prabhakar Lad
2014-01-23 19:55 ` your mail Mark Brown
0 siblings, 1 reply; 669+ messages in thread
From: Prabhakar Lad @ 2014-01-23 9:06 UTC (permalink / raw)
To: Mark Brown, broonie; +Cc: LKML
Hi Mark,
I see a issue with one of the davinci boards, where regulator_get() fails
from this patch "regulator: core: Provide a dummy regulator with full
constraints".
as I see regulator_get() supports dummy regulators by default.
So currently I am booting it traditional way (NON DT way) and
regulator_dev_lookup()
fails (return NULL) and for this check it fails.
+ if (ret && ret != -ENODEV) {
regulator = ERR_PTR(ret);
goto out;
}
In the NON-DT case the 'ret' is never updated in regulator_dev_lookup().
I tried adding regulator_has_full_constraints(); call in .init_machine
but results
the same. Any pointer would be helpfull.
Thanks,
--Prabhakar Lad
^ permalink raw reply [flat|nested] 669+ messages in thread[parent not found: <1388425244-10017-1-git-send-email-jdb@sitrep3.com>]
* Re: your mail
[not found] <1388425244-10017-1-git-send-email-jdb@sitrep3.com>
@ 2014-01-09 18:39 ` Greg KH
2014-01-09 18:49 ` Joe Borġ
0 siblings, 1 reply; 669+ messages in thread
From: Greg KH @ 2014-01-09 18:39 UTC (permalink / raw)
To: Joe Borg; +Cc: abbotti, hsweeten, devel, linux-kernel
On Mon, Dec 30, 2013 at 05:40:44PM +0000, Joe Borg wrote:
> >From 6d9f6446434c4021cc9452e31c374ac50e08f0f9 Mon Sep 17 00:00:00 2001
> From: Joe Borg <root@josephb.org>
This isn't matching your "from:" line on your email, why should I trust
it?
And doing kernel work as 'root'? That's not a good idea for lots of
reasons...
> Date: Mon, 30 Dec 2013 15:35:08 +0000
> Subject: [PATCH 62/62] DAS1800: Fixing error from checkpatch.
>
> Fixed pointer typeo; foo * bar should be foo *bar.
>
> Signed-off by Joe Borg <root@josephb.org>
What happened to your Subject:?
And why is the whole git header in the email, please use git send-email
so that I don't have to hand-edit the body of the email to apply it.
Can you please fix this up and resend?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2014-01-09 18:39 ` Greg KH
@ 2014-01-09 18:49 ` Joe Borġ
2014-01-14 16:40 ` Steven Rostedt
0 siblings, 1 reply; 669+ messages in thread
From: Joe Borġ @ 2014-01-09 18:49 UTC (permalink / raw)
To: Greg KH; +Cc: abbotti, hsweeten, devel, linux-kernel
Hi Greg,
I'll re do them tonight.
I didn't do the changes as root, I sent them from my server as it has SMTP out.
Thanks
Regards,
Joseph David Borġ
http://www.jdborg.com
On 9 January 2014 18:39, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Dec 30, 2013 at 05:40:44PM +0000, Joe Borg wrote:
>> >From 6d9f6446434c4021cc9452e31c374ac50e08f0f9 Mon Sep 17 00:00:00 2001
>> From: Joe Borg <root@josephb.org>
>
> This isn't matching your "from:" line on your email, why should I trust
> it?
>
> And doing kernel work as 'root'? That's not a good idea for lots of
> reasons...
>
>> Date: Mon, 30 Dec 2013 15:35:08 +0000
>> Subject: [PATCH 62/62] DAS1800: Fixing error from checkpatch.
>>
>> Fixed pointer typeo; foo * bar should be foo *bar.
>>
>> Signed-off by Joe Borg <root@josephb.org>
>
> What happened to your Subject:?
>
> And why is the whole git header in the email, please use git send-email
> so that I don't have to hand-edit the body of the email to apply it.
>
> Can you please fix this up and resend?
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2014-01-09 18:49 ` Joe Borġ
@ 2014-01-14 16:40 ` Steven Rostedt
0 siblings, 0 replies; 669+ messages in thread
From: Steven Rostedt @ 2014-01-14 16:40 UTC (permalink / raw)
To: Joe Bor??; +Cc: Greg KH, abbotti, hsweeten, devel, linux-kernel
On Thu, Jan 09, 2014 at 06:49:39PM +0000, Joe Bor?? wrote:
>
> I didn't do the changes as root, I sent them from my server as it has SMTP out.
>
Hmm, this gives me an idea. There's nothing, I believe, that makes the root user
have to have the name "root" except for the passwd file. Maybe I'll just
rename "root" to "walley" and then use "root" as my normal account. If anyone tries
to break into "root" they will just gain access to a normal account and nothing
more ;-)
/me goes back to hacking
-- Steve
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2013-10-19 22:21 Antonio Quartulli
2013-10-20 0:15 ` (unknown) David Miller
0 siblings, 1 reply; 669+ messages in thread
From: Antonio Quartulli @ 2013-10-19 22:21 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
this is another batch intended for net-next/linux-3.13.
This pull request is a bit bigger than usual, but 6 patches are very small
(three of them are about email updates)..
Patch 1 is fixing a previous merge conflict resolution that went wrong
(I realised that only now while checking other patches..).
Patches from 2 to 4 that are updating our emails in all the proper files
(Documentation/, headers and MAINTAINERS).
Patches 5, 6 and 7 are bringing a big improvement to the TranslationTable
component: it is now able to group non-mesh clients based on the VLAN they
belong to. In this way a lot a new enhancements are now possible thanks to the
fact that each batman-adv behaviour can be applied on a per VLAN basis.
And, of course, in patches from 8 to 12 you have some of the enhancements I was
talking about:
- make the batman-Gateway selection VLAN dependent
- make DAT (Distributed ARP Table) group ARP entries on a VLAN basis (this
allows DAT to work even when the admin decided to use the same IP subnet on
different VLANs)
- make the AP-Isolation behaviour switchable on each VLAN independently
- export VLAN specific attributes via sysfs. Switches like the AP-Isolation are
now exported once per VLAN (backward compatibility of the sysfs interface has
been preserved)
Patches 13 and 14 are small code cleanups.
Patch 15 is a minor improvement in the TT locking mechanism.
Patches 16 and 17 are other enhancements to the TT component. Those allow a
node to parse a "non-mesh client announcement message" and accept only those
TT entries belonging to certain VLANs.
Patch 18 exploits this parse&accept mechanism to make the Bridge Loop Avoidance
component reject only TT entries connected to the VLAN where it is operating.
Previous to this change, BLA was rejecting all the entries coming from any other
Backbone node, regardless of the VLAN (for more details about how the Bridge
Loop Avoidance works please check [1]).
Please pull or let me know of any problem.
Thanks a lot,
Antonio
[1] http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-II
The following changes since commit b1eda2ac3fa6bf23b27c7c70eda6885124c79ed3:
em_ipset: use dev_net() accessor (2013-10-18 16:23:06 -0400)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
for you to fetch changes up to cfd4f75701b6b13b1ec74e6f65ad0d1969c19247:
batman-adv: make the backbone gw check VLAN specific (2013-10-19 23:25:38 +0200)
----------------------------------------------------------------
Included changed:
- email addresses update in documentation, source files and MAINTAINERS
- make the TT component distinguish non-mesh clients based on the VLAN they
belong to
- improve all the internal components to properly work on a per-VLAN basis
(enabled by the new TT-VLAN feature)
- enhance the sysfs interface in order to provide behaviour switches on a
per-VLAN basis (enabled by the new TT-VLAN feature)
- improve TT lock mechanism
- improve unicast transmission APIs
----------------------------------------------------------------
Antonio Quartulli (15):
batman-adv: check skb preparation return value
batman-adv: update email address for Antonio Quartulli
batman-adv: add the VLAN ID attribute to the TT entry
batman-adv: use vid when computing local and global TT CRC
batman-adv: print the VID together with the TT entries
batman-adv: make the GW module correctly talk to the new VLAN-TT
batman-adv: make the Distributed ARP Table vlan aware
batman-adv: add per VLAN interface attribute framework
batman-adv: add sysfs framework for VLAN
batman-adv: make the AP isolation attribute VLAN specific
batman-adv: remove bogus comment
batman-adv: lock around TT operations to avoid sending inconsistent data
batman-adv: make the TT CRC logic VLAN specific
batman-adv: make the TT global purge routine VLAN specific
batman-adv: make the backbone gw check VLAN specific
Linus Lüssing (1):
batman-adv: refine API calls for unicast transmissions of SKBs
Marek Lindner (1):
batman-adv: update email address for Marek Lindner
Simon Wunderlich (1):
batman-adv: update email address for Simon Wunderlich
.../ABI/testing/sysfs-class-net-batman-adv | 4 +-
Documentation/ABI/testing/sysfs-class-net-mesh | 23 +-
Documentation/networking/batman-adv.txt | 4 +-
MAINTAINERS | 2 +-
net/batman-adv/bridge_loop_avoidance.c | 58 +-
net/batman-adv/bridge_loop_avoidance.h | 10 +-
net/batman-adv/distributed-arp-table.c | 160 ++-
net/batman-adv/gateway_client.c | 25 +-
net/batman-adv/hard-interface.c | 2 +
net/batman-adv/main.c | 33 +-
net/batman-adv/main.h | 15 +-
net/batman-adv/originator.c | 104 +-
net/batman-adv/originator.h | 7 +
net/batman-adv/packet.h | 32 +-
net/batman-adv/routing.c | 28 +-
net/batman-adv/send.c | 98 +-
net/batman-adv/send.h | 51 +-
net/batman-adv/soft-interface.c | 227 +++-
net/batman-adv/soft-interface.h | 4 +
net/batman-adv/sysfs.c | 178 ++-
net/batman-adv/sysfs.h | 10 +
net/batman-adv/translation-table.c | 1157 +++++++++++++++-----
net/batman-adv/translation-table.h | 23 +-
net/batman-adv/types.h | 83 +-
24 files changed, 1851 insertions(+), 487 deletions(-)
^ permalink raw reply [flat|nested] 669+ messages in thread* (unknown)
2013-10-19 22:21 (unknown), Antonio Quartulli
@ 2013-10-20 0:15 ` David Miller
2013-10-20 7:57 ` your mail Antonio Quartulli
0 siblings, 1 reply; 669+ messages in thread
From: David Miller @ 2013-10-20 0:15 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Sun, 20 Oct 2013 00:21:52 +0200
> this is another batch intended for net-next/linux-3.13.
Looks good, pulled, thanks a lot Antonio.
Please don't use empty subject lines in the future, lots of
sites block such emails and I see all of those bounces as
vger postmaster :-/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2013-10-20 0:15 ` (unknown) David Miller
@ 2013-10-20 7:57 ` Antonio Quartulli
0 siblings, 0 replies; 669+ messages in thread
From: Antonio Quartulli @ 2013-10-20 7:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, b.a.t.m.a.n
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
On Sat, Oct 19, 2013 at 08:15:11PM -0400, David Miller wrote:
> From: Antonio Quartulli <antonio@meshcoding.com>
> Date: Sun, 20 Oct 2013 00:21:52 +0200
>
> > this is another batch intended for net-next/linux-3.13.
>
> Looks good, pulled, thanks a lot Antonio.
>
> Please don't use empty subject lines in the future, lots of
> sites block such emails and I see all of those bounces as
> vger postmaster :-/
>
Ops, my bad. I won't do it again in the future!
Thanks a lot David.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2013-09-03 14:02 Igor Filakhtov
0 siblings, 0 replies; 669+ messages in thread
From: Igor Filakhtov @ 2013-09-03 14:02 UTC (permalink / raw)
To: lartc
I have a total control over IP adresses, static DHCP and so on, so
this is not a problem.
Best regards, Igor V. Filakhtov
GMail: filakhtov@gmail.com | Cell: (050) 65-66-280 | Skype: ihor.filakhtov
On Tue, Sep 3, 2013 at 12:11 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 30/08/13, Igor Filakhtov wrote:
>> Greetings all,
>
>> There are 5 users in my LAN, every of those have at least two devices
>> (pc, smartphone). These devices using static DHCP addresses. All
>> packets from single device owner are marked.
>> These packets later are shaped using TC.
>
> It might be easier to filter the traffic with tc (match ip
> src/dst/sport/dport) instead of relying on iptables.
>
> --
> Nicolas Sebrecht
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2013-05-17 18:02 ASHISH VERMA
2013-05-21 13:13 ` your mail Magnus Bäck
0 siblings, 1 reply; 669+ messages in thread
From: ASHISH VERMA @ 2013-05-17 18:02 UTC (permalink / raw)
To: git
Hi, i am using git to push my code from eclipse to heroku , but
recently iam getting error like::
master:master rejected:non fast forward
and i am not able to resolve it .I tried a git pull but that says -
conflicts shud be resolved before git pull can be implemented.I can;t
find the solution Please help ASAP...
ASHISH
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2013-05-17 18:02 (unknown), ASHISH VERMA
@ 2013-05-21 13:13 ` Magnus Bäck
0 siblings, 0 replies; 669+ messages in thread
From: Magnus Bäck @ 2013-05-21 13:13 UTC (permalink / raw)
To: ASHISH VERMA; +Cc: git
On Friday, May 17, 2013 at 14:02 EDT,
ASHISH VERMA <ashunew1989@gmail.com> wrote:
> Hi, i am using git to push my code from eclipse to heroku , but
> recently iam getting error like::
>
> master:master rejected:non fast forward
>
> and i am not able to resolve it .I tried a git pull but that says -
> conflicts shud be resolved before git pull can be implemented.I can;t
> find the solution Please help ASAP...
Resolve the conflicts by either hand-editing the files (you'll see the
markers where the conflicts are) add running 'git add' to tell git that
you're done resolving them, or set up Git to use a graphical tool like
kdiff3. When you're done, run 'git commit' to create the merge commit.
After that you'll be able to push to your upstream (unless things have
moved again while you were resolving the initial conflict).
This guide to merge conflicts looks pretty good:
http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/
--
Magnus Bäck
baeck@google.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2013-01-23 12:37 Nitin Kshirsagar
[not found] ` <C4B5704C6FEB5244B2A1BCC8CF83B86B0A6257C7D0-AQg6BlXVjylhNUoibfp7lHKnxlUjViKd@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: Nitin Kshirsagar @ 2013-01-23 12:37 UTC (permalink / raw)
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA,
kent.overstreet-Re5JQEeQqe8AvxtiuMwx3w
Cc: Amit Kale, Sanoj Unnikrishnan
Hello Kent,
I have setup bcache and run fio data verification test on write back and write through caches.
The fio tests are passed, however I have found following issues while using bcache.
Issue1: Cache is not created as per user specified options
--------------------------------------------------------------------------------------------------------
Steps:
1.Create cache by specifying mode writeback and cache replacement policy as fifo
[root@annu bcache]# make-bcache --cache /dev/sdc --bdev /dev/sdd --writeback --cache_replacement_policy=fifo
UUID: e25f2840-f02b-46af-81e7-28948b2737cc
Set UUID: 68da5b89-1e87-457a-80c7-2c822737f969
nbuckets: 2048
block_size: 1
bucket_size: 1024
nr_in_set: 1
nr_this_dev: 0
first_bucket: 1
UUID: a3ce52e6-631b-4c74-afa2-9f8b0088c7f4
Set UUID: 68da5b89-1e87-457a-80c7-2c822737f969
nbuckets: 20480
block_size: 1
bucket_size: 1024
nr_in_set: 1
nr_this_dev: 0
first_bucket: 1
[root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
[root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
2. Cache mode should be "writeback" instead of "writethrough"
[root@annu bcache]# cat /sys/block/bcache2/bcache/cache_mode
[writethrough] writeback writearound none
[root@annu bcache]# cat /sys/block/bcache2/bcache/writeback_running
1
3. Cache policy should be "fifo" instead of "lru"
[root@annu ~]# cat /sys/block/bcache2/bcache/cache/cache0/cache_replacement_policy
[lru] fifo random
Issue2: Cache dirty data value should not be negative.
-------------------------------------------------------------------------------------------------------
Steps:
1.Create cache by specifying mode writeback and cache replacement policy as fifo
2.To make bcache devices known to the kernel
[root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
[root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
3.Create FS on cache /dev/bcacheN and mount in directory
4.Create Data set by using fio or dd on mount point.
5. Change cache node from "writethrough" to "writeback"
[root@annu ~]# echo writeback > /sys/block/bcache2/bcache/cache_mode
[root@annu ~]# cat /sys/block/bcache2/bcache/cache_mode
writethrough [writeback] writearound none
6.Check cache dirty data should not be negative value
[root@annu ~]# cat /sys/block/bcache2/bcache/dirty_data
-9.4M
--
Thanks & Regards
Nitin Kshirsagar
Software Engr, QA
Cell 997.566.3985
STEC india private Limited, Pune | The SSD Company TM
NASDAQ STEC • Web www.stec-inc.com
PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED
This electronic transmission, and any documents attached hereto, may contain confidential, proprietary and/or legally privileged information. The information is intended only for use by the recipient named above. If you received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited, and violators will be pursued legally.
^ permalink raw reply [flat|nested] 669+ messages in thread[parent not found: <CACaajQtCTW_PKA25q3-4o4XAV6sgZnyD+Skkw6mhUHpRBEgbjQ@mail.gmail.com>]
* Re: your mail
[not found] <CACaajQtCTW_PKA25q3-4o4XAV6sgZnyD+Skkw6mhUHpRBEgbjQ@mail.gmail.com>
@ 2012-11-26 18:29 ` Greg KH
0 siblings, 0 replies; 669+ messages in thread
From: Greg KH @ 2012-11-26 18:29 UTC (permalink / raw)
To: Vasiliy Tolstov; +Cc: linux-kernel, stable
On Mon, Nov 26, 2012 at 10:14:44PM +0400, Vasiliy Tolstov wrote:
> Hello, Greg. Hello kernel team! I'm system enginer at clodo.ru (russian cloud
> hosting provider) we are use xen and sles11-sp2 for our compute xen nodes.
> Each virtual machine (domU) have disks that attached by Infiniband SRP. On top
> of disk that attached by srp we use multipath (to do failover)
> Now we have issues like all commands that uses multipath hang while one storage
> is rebooted.
> After some discussion with maintainer of linux-rdma (Bart Van Assche) and using
> it backported ib_srp with HA patches we can't solve deadlock issues. Bart
> thinks that SLES team does not backport some core scsi patches to their kernel
> (3.0.42) to prevent multipath deadlock (currently is about 2.5 minutes) on
> failed target.
> Is that possible to determine or getting help to solve this issue?
As you are using SLES, please contact the SUSE for support for that
kernel, as you are paying for it, and the community can't do anything to
support their kernel, sorry.
Best of luck,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 2012-11-26 18:29 ` Greg KH
0 siblings, 0 replies; 669+ messages in thread
From: Greg KH @ 2012-11-26 18:29 UTC (permalink / raw)
To: Vasiliy Tolstov; +Cc: linux-kernel, stable
On Mon, Nov 26, 2012 at 10:14:44PM +0400, Vasiliy Tolstov wrote:
> Hello, Greg. Hello kernel team! I'm system enginer at�clodo.ru�(russian cloud
> hosting provider) we are use xen and sles11-sp2 for our compute xen nodes.
> Each virtual machine (domU) have disks that attached by Infiniband SRP. On top
> of disk that attached by srp we use multipath (to do failover)
> Now we have issues like all commands that uses multipath hang while one storage
> is rebooted.
> After some discussion with maintainer of linux-rdma (Bart Van Assche) and using
> it backported ib_srp with HA patches we can't solve deadlock issues. Bart
> thinks that SLES team does not backport some core scsi patches to their kernel
> (3.0.42) to prevent multipath deadlock (currently is about 2.5 minutes) on
> failed target.
> Is that possible to determine or getting help to solve this issue?
As you are using SLES, please contact the SUSE for support for that
kernel, as you are paying for it, and the community can't do anything to
support their kernel, sorry.
Best of luck,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2012-10-18 15:47 walter harms
0 siblings, 0 replies; 669+ messages in thread
From: walter harms @ 2012-10-18 15:47 UTC (permalink / raw)
To: kernel-janitors
Am 18.10.2012 15:17, schrieb Nicolas Palix:
> Hi,
>
>
>> But I do think we should maybe find another list for Fengguang's
>> emails? It's sort of a lot higher traffic than before and sort of a
>> different flavour.
>>
>> I still will want to subscribe to the emails, but it would be better
>> to use a different list. Apparently Dave Miller didn't like the
>> idea of creating a special list for it because he didn't like the
>> emails in the first place. But now I think everyone likes them a
>> lot. It might be worth asking again.
>
> I agreed in the first place but kernel-janitors is also a great place
> for newcomers.
> Having those reports accessible could be great for them. Also, it is not
> that different than the janitorial work done before. The main difference I see
> is that there is no fixing patches associated to the reports. But the problems
> addressed are almost the same, and they are found with the same tools.
>
> Does it worth a new list ?
>
> Maybe the set of branches tested need to be further refined to lower
> the false positives.
> Finally, we may hope developers will test their patches before releasing them.
>
> Is there any mean for them to apply the tests before pushing ?
>
> If a new list is created, please let us know how to subscribe to it on this one.
>
> Regards.
>
I support the idea of a new list. The reports are mostly nothing that what the janitors can
review. Fengguang is important but cleary targeted to developers in ongoing projects.
Janitors care more about the state of the current kernel.
just my two cents,
wh
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2012-10-10 15:06 Kent Yoder
2012-10-10 15:12 ` your mail Kent Yoder
0 siblings, 1 reply; 669+ messages in thread
From: Kent Yoder @ 2012-10-10 15:06 UTC (permalink / raw)
Cc: linux-kernel, linux-security-module, tpmdd-devel, Kent Yoder
The following changes since commit ecefbd94b834fa32559d854646d777c56749ef1c:
Merge tag 'kvm-3.7-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2012-10-04 09:30:33 -0700)
are available in the git repository at:
git://github.com/shpedoikal/linux.git tpmdd-fixes-v3.6
for you to fetch changes up to 1631cfb7cee28388b04aef6c0a73050f6fd76e4d:
driver/char/tpm: fix regression causesd by ppi (2012-10-10 09:50:56 -0500)
----------------------------------------------------------------
Gang Wei (1):
driver/char/tpm: fix regression causesd by ppi
drivers/char/tpm/tpm.c | 3 ++-
drivers/char/tpm/tpm.h | 9 +++++++--
drivers/char/tpm/tpm_ppi.c | 18 ++++++++++--------
3 files changed, 19 insertions(+), 11 deletions(-)
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-10-10 15:06 Kent Yoder
@ 2012-10-10 15:12 ` Kent Yoder
0 siblings, 0 replies; 669+ messages in thread
From: Kent Yoder @ 2012-10-10 15:12 UTC (permalink / raw)
To: Kent Yoder; +Cc: linux-kernel, linux-security-module, tpmdd-devel
Please ignore.
On Wed, Oct 10, 2012 at 10:06:53AM -0500, Kent Yoder wrote:
> The following changes since commit ecefbd94b834fa32559d854646d777c56749ef1c:
>
> Merge tag 'kvm-3.7-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2012-10-04 09:30:33 -0700)
>
> are available in the git repository at:
>
>
> git://github.com/shpedoikal/linux.git tpmdd-fixes-v3.6
>
> for you to fetch changes up to 1631cfb7cee28388b04aef6c0a73050f6fd76e4d:
>
> driver/char/tpm: fix regression causesd by ppi (2012-10-10 09:50:56 -0500)
>
> ----------------------------------------------------------------
> Gang Wei (1):
> driver/char/tpm: fix regression causesd by ppi
>
> drivers/char/tpm/tpm.c | 3 ++-
> drivers/char/tpm/tpm.h | 9 +++++++--
> drivers/char/tpm/tpm_ppi.c | 18 ++++++++++--------
> 3 files changed, 19 insertions(+), 11 deletions(-)
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2012-10-04 16:50 Andrea Arcangeli
2012-10-04 18:17 ` Christoph Lameter
0 siblings, 1 reply; 669+ messages in thread
From: Andrea Arcangeli @ 2012-10-04 16:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-kernel, linux-mm, Linus Torvalds, Andrew Morton,
Peter Zijlstra, Ingo Molnar, Mel Gorman, Hugh Dickins,
Rik van Riel, Johannes Weiner, Hillf Danton, Andrew Jones,
Dan Smith, Thomas Gleixner, Paul Turner, Suresh Siddha,
Mike Galbraith, Paul E. McKenney
Subject: Re: [PATCH 29/33] autonuma: page_autonuma
Reply-To:
In-Reply-To: <0000013a2c223da2-632aa43e-21f8-4abd-a0ba-2e1b49881e3a-000000@email.amazonses.com>
Hi Christoph,
On Thu, Oct 04, 2012 at 02:16:14PM +0000, Christoph Lameter wrote:
> On Thu, 4 Oct 2012, Andrea Arcangeli wrote:
>
> > Move the autonuma_last_nid from the "struct page" to a separate
> > page_autonuma data structure allocated in the memsection (with
> > sparsemem) or in the pgdat (with flatmem).
>
> Note that there is a available word in struct page before the autonuma
> patches on x86_64 with CONFIG_HAVE_ALIGNED_STRUCT_PAGE.
>
> In fact the page_autonuma fills up the structure to nicely fit in one 64
> byte cacheline.
Good point indeed.
So we could drop page_autonuma by creating a CONFIG_SLUB=y dependency
(AUTONUMA wouldn't be available in the kernel config if SLAB=y, and it
also wouldn't be available on 32bit archs but the latter isn't a
problem).
I think it's a reasonable alternative to page_autonuma. Certainly it
looks more appealing than taking over 16 precious bits from
page->flags. There are still pros and cons. I'm neutral on it so more
comments would be welcome ;).
Andrea
PS. randomly moved some in Cc over to Bcc as I overflowed the max
header allowed on linux-kernel oops!
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-10-04 16:50 Andrea Arcangeli
@ 2012-10-04 18:17 ` Christoph Lameter
0 siblings, 0 replies; 669+ messages in thread
From: Christoph Lameter @ 2012-10-04 18:17 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: linux-kernel, linux-mm, Linus Torvalds, Andrew Morton,
Peter Zijlstra, Ingo Molnar, Mel Gorman, Hugh Dickins,
Rik van Riel, Johannes Weiner, Hillf Danton, Andrew Jones,
Dan Smith, Thomas Gleixner, Paul Turner, Suresh Siddha,
Mike Galbraith, Paul E. McKenney
On Thu, 4 Oct 2012, Andrea Arcangeli wrote:
> So we could drop page_autonuma by creating a CONFIG_SLUB=y dependency
> (AUTONUMA wouldn't be available in the kernel config if SLAB=y, and it
> also wouldn't be available on 32bit archs but the latter isn't a
> problem).
Nope it should depend on page struct alignment. Other kernel subsystems
may be depeding on page struct alignment in the future (and some other
arches may already have that requirement)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2012-10-04 18:17 ` Christoph Lameter
0 siblings, 0 replies; 669+ messages in thread
From: Christoph Lameter @ 2012-10-04 18:17 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: linux-kernel, linux-mm, Linus Torvalds, Andrew Morton,
Peter Zijlstra, Ingo Molnar, Mel Gorman, Hugh Dickins,
Rik van Riel, Johannes Weiner, Hillf Danton, Andrew Jones,
Dan Smith, Thomas Gleixner, Paul Turner, Suresh Siddha,
Mike Galbraith, Paul E. McKenney
On Thu, 4 Oct 2012, Andrea Arcangeli wrote:
> So we could drop page_autonuma by creating a CONFIG_SLUB=y dependency
> (AUTONUMA wouldn't be available in the kernel config if SLAB=y, and it
> also wouldn't be available on 32bit archs but the latter isn't a
> problem).
Nope it should depend on page struct alignment. Other kernel subsystems
may be depeding on page struct alignment in the future (and some other
arches may already have that requirement)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2012-08-03 17:43 Tejun Heo
2012-08-08 16:39 ` your mail Tejun Heo
0 siblings, 1 reply; 669+ messages in thread
From: Tejun Heo @ 2012-08-03 17:43 UTC (permalink / raw)
To: linux-kernel
Cc: torvalds, akpm, padovan, marcel, peterz, mingo, davem,
dougthompson, ibm-acpi, cbou, rui.zhang, tomi.valkeinen
delayed_work has been annoyingly missing the mechanism to modify timer
of a pending delayed_work - ie. mod_timer() counterpart. delayed_work
users have been working around this using several methods - using an
explicit timer + work item, messing directly with delayed_work->timer,
and canceling before re-queueing, all of which are error-prone and/or
ugly.
Gustavo Padovan posted a RFC implementation[1] of mod_delayed_work() a
while back but it wasn't complete. To properly implement
mod_delayed_work[_on](), it should be able to steal pending work items
which may be on timer or worklist or anywhere inbetween. This is
similar to what __cancel_work_timer() does but it turns out that there
are a lot of holes around this area and try_to_grab_pending() needs
considerable amount of work to be used for other purposes too.
This patchset improves canceling and try_to_grab_pending(), use it to
implement mod_delayed_work[_on](), convert easy ones, and drop
__cancel_delayed_work_sync() which doesn't have relevant users
afterwards.
Changes from the first take[L] are,
* All updated patches rolled into the series and Acked-by's added.a
* Tomi Valkeinen pointed out that mod_delayed_work() can't be called
from IRQ handlers and thus can't replace __cancel_delayed_work()
users. __cancel_delayed_work() users dropped from conversion. This
will be handled by a future patchset.
* Ensuring preemtion is disabled across PENDING manipulation doesn't
make try_to_grab_pending() safe to use from bh context and making it
impossible to replace even cancel_delayed_work() users. Whole patch
series updated so that IRQ is disabled across PENDING manipulation
instead. As most operations had to grab gcwq->lock anyway, this
doesn't add extra IRQ toggling.
* try_to_grab_pending() and __cancel_work_timer() updated to take bool
@is_dwork instead of @timer and disable IRQ on successful return.
This patchset contains the following fourteen patches.
0001-workqueue-reorder-queueing-functions-so-that-_on-var.patch
0002-workqueue-make-queueing-functions-return-bool.patch
0003-workqueue-add-missing-smp_wmb-in-process_one_work.patch
0004-workqueue-disable-irq-while-manipulating-PENDING.patch
0005-workqueue-set-delayed_work-timer-function-on-initial.patch
0006-workqueue-unify-local-CPU-queueing-handling.patch
0007-workqueue-fix-zero-delay-handling-of-queue_delayed_w.patch
0008-workqueue-move-try_to_grab_pending-upwards.patch
0009-workqueue-introduce-WORK_OFFQ_FLAG_.patch
0010-workqueue-factor-out-__queue_delayed_work-from-queue.patch
0011-workqueue-reorganize-try_to_grab_pending-and-__cance.patch
0012-workqueue-mark-a-work-item-being-canceled-as-such.patch
0013-workqueue-implement-mod_delayed_work-_on.patch
0014-workqueue-use-mod_delayed_work-instead-of-cancel-que.patch
0001-0003 are preparatory.
0004 removes the possibility of cancel_sync spinning for extended
period of time while another task holding PENDING is preempted or
interrupted.
0005-0007 clean up local queueing handling.
0008-0011 prepare for try_to_grab_pending() improvements.
0012 makes try_to_grab_pending() distinguish transient failure which
can be safely busy-retried and failure because the work item is being
canceled, which may take arbitrary amount of time.
0013 uses the improved try_to_grab_pending() to implement
mod_delayed_work[_on]().
0014 converts cancel + queue sequences to mod_delayed_work().
This patchset is also available at the following git branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-wq-mod_delayed
If nobody objects, I'd like to route this series through wq/for-3.7.
Changes to other subsystems are fairly localized and conflicts, if
they occur, shouldn't be too painful to handle.
Although this ends up adding ~130 LOC, it contains a lot more
documentation, converted only the apparent ones, and IMHO is
worthwhile to have regardless as it removes an annoyance which is
pretty easy to encounter while using delayed_work.
Thanks.
block/genhd.c | 6
drivers/edac/edac_mc.c | 17
drivers/infiniband/core/addr.c | 4
drivers/infiniband/hw/nes/nes_hw.c | 6
drivers/infiniband/hw/nes/nes_nic.c | 5
drivers/net/wireless/ipw2x00/ipw2100.c | 8
drivers/net/wireless/zd1211rw/zd_usb.c | 3
drivers/platform/x86/thinkpad_acpi.c | 20
drivers/power/charger-manager.c | 9
drivers/power/ds2760_battery.c | 9
drivers/power/jz4740-battery.c | 6
drivers/thermal/thermal_sys.c | 15
fs/afs/callback.c | 4
fs/afs/server.c | 10
fs/afs/vlocation.c | 14
fs/nfs/nfs4renewd.c | 3
include/linux/workqueue.h | 47 +-
kernel/workqueue.c | 732 ++++++++++++++++++++-------------
net/core/dst.c | 4
net/rfkill/input.c | 3
20 files changed, 526 insertions(+), 399 deletions(-)
--
tejun
[1] http://thread.gmane.org/gmane.linux.kernel/1159922
[L] http://thread.gmane.org/gmane.linux.kernel/1334546
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-08-03 17:43 Tejun Heo
@ 2012-08-08 16:39 ` Tejun Heo
0 siblings, 0 replies; 669+ messages in thread
From: Tejun Heo @ 2012-08-08 16:39 UTC (permalink / raw)
To: linux-kernel
Cc: torvalds, akpm, padovan, marcel, peterz, mingo, davem,
dougthompson, ibm-acpi, cbou, rui.zhang, tomi.valkeinen
On Fri, Aug 03, 2012 at 10:43:45AM -0700, Tejun Heo wrote:
> delayed_work has been annoyingly missing the mechanism to modify timer
> of a pending delayed_work - ie. mod_timer() counterpart. delayed_work
> users have been working around this using several methods - using an
> explicit timer + work item, messing directly with delayed_work->timer,
> and canceling before re-queueing, all of which are error-prone and/or
> ugly.
>
> Gustavo Padovan posted a RFC implementation[1] of mod_delayed_work() a
> while back but it wasn't complete. To properly implement
> mod_delayed_work[_on](), it should be able to steal pending work items
> which may be on timer or worklist or anywhere inbetween. This is
> similar to what __cancel_work_timer() does but it turns out that there
> are a lot of holes around this area and try_to_grab_pending() needs
> considerable amount of work to be used for other purposes too.
>
> This patchset improves canceling and try_to_grab_pending(), use it to
> implement mod_delayed_work[_on](), convert easy ones, and drop
> __cancel_delayed_work_sync() which doesn't have relevant users
> afterwards.
Applied to wq/for-3.7.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2012-07-03 20:18 Elie De Brauwer
[not found] ` <4FF3539B.50103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: Elie De Brauwer @ 2012-07-03 20:18 UTC (permalink / raw)
To: linux-man-u79uwXL29TY76Z2rM5mHXA
subscribe linux-man
--
Elie De Brauwer
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread* (unknown)
@ 2012-06-21 18:26 Paul Walmsley
2012-06-22 8:56 ` Tony Lindgren
0 siblings, 1 reply; 669+ messages in thread
From: Paul Walmsley @ 2012-06-21 18:26 UTC (permalink / raw)
To: tony
Cc: linux-omap, linux-arm-kernel, khilman, Omar Ramirez Luna, peter.ujfalusi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
- ----------------------------------------------------------------
Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
- ----------------------------------------------------------------
Testing logs are available at
http://www.pwsan.com/omap/bootlogs/20120620/omap_cleanup_a_3.6__07b3a13957aa250ff5b5409b8ed756b113544112/
The summary is that 5912OSK NFS root and N800 MMC don't boot to
userspace; this broke between v3.4-rc2 and v3.5-rc3. 3517 boards are
still broken with NFS root and also several stack tracebacks during
boot. In terms of PM, core isn't entering idle on OMAP3 or OMAP4.
These problems all exist in v3.5-rc3 - they aren't caused by this
series.
object size (delta in bytes from v3.5-rc3 (485802a6c524e62b5924849dd727ddbb1497cc71)):
text data bss total kernel
0 0 0 0 5912osk_testconfig/vmlinux
+4636 -400 0 +4236 am33xx_testconfig/vmlinux
+440 -408 +32 +64 n800_multi_omap2xxx/vmlinux
+416 -192 +32 +256 n800_testconfig/vmlinux
0 0 0 0 omap1510_defconfig/vmlinux
0 0 0 0 omap1_defconfig/vmlinux
+732 -456 0 +276 omap2_4_testconfig/vmlinux
+4776 -624 0 +4152 omap2plus_defconfig/vmlinux
+684 -664 0 +20 omap2plus_no_pm/vmlinux
+616 -336 +64 +344 omap3_4_testconfig/vmlinux
+360 -384 0 -24 omap3_testconfig/vmlinux
+580 -120 +64 +524 omap4_testconfig/vmlinux
Kevin Hilman (7):
ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module()
ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module
ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable()
ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready
ARM: OMAP2+: hwmod: use init-time function pointer for hardreset
ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm
ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
Omar Ramirez Luna (2):
ARM: OMAP2+: control: new APIs to configure boot address and mode
ARM: OMAP: dsp: interface to control module functions
Paul Walmsley (2):
ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain
Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6
Peter Ujfalusi (3):
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2420
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2430
ARM: OMAP3: Move McBSP fck clock alias to hwmod data
arch/arm/mach-omap2/Makefile | 1 -
arch/arm/mach-omap2/clock2420_data.c | 4 -
arch/arm/mach-omap2/clock2430_data.c | 10 -
arch/arm/mach-omap2/clock3xxx_data.c | 10 -
arch/arm/mach-omap2/clockdomain.h | 2 -
arch/arm/mach-omap2/clockdomains2420_data.c | 2 -
arch/arm/mach-omap2/clockdomains2430_data.c | 2 -
arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 -
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
arch/arm/mach-omap2/control.c | 43 ++
arch/arm/mach-omap2/control.h | 2 +
arch/arm/mach-omap2/dsp.c | 4 +
.../include/mach/ctrl_module_core_44xx.h | 1 +
arch/arm/mach-omap2/omap_hwmod.c | 427 ++++++++++++++------
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 10 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 16 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 23 ++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 +-
arch/arm/plat-omap/include/plat/clock.h | 2 -
arch/arm/plat-omap/include/plat/dsp.h | 3 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
22 files changed, 409 insertions(+), 187 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJP42cFAAoJEMePsQ0LvSpLmMAP/06LRRSFBPklr2hDmFPKBfBD
guF3rAN5zimEyknXp1RhoHJjcH0YCkUdQgD24w51yVwVB9zVW0M6G9hVi91cJj9X
1StRIwTbtb08yPdOlpywEXzHpjXz3AauCMRRxYJHi0FjajwHNKWWv+A/iolM0p8P
5o5ZY+D3AzJqfX/+A0FK2YKn2Z7X9kxg8uTTukhXhe38ldZJ2pHqA4ND2n2F+GnD
DUGqpnYu+QLTmw0x0NbpTNDarnmUEa/tH1NRny5Fh+ujYxH5NPTVvxHTW8tbm5bl
qkleWJaDc+D2pCnD3ch3cUlLgIfTZbo4KUg+Y4uv4QLrLx/QTu6TpyJaP+ZJw3sY
amakgmv3vzYzHMOf/0gxIe6xDZl6YFVXiOdJex4kQ5qodXRgmh82gYUrEKLLHuWn
+EKwIBM8xV5zYzA60vZ05ul7QqeNfwD5D6dd5As96QweVJFMGiIDWINGfxOtI/mH
ygXD6sSZvYhqGk2EVb+hje971urmI4aIrolt/xB4anOATiehaJuwhLjtp+5ZO7tL
5w3bybiUqKh+CN0DlpL/Srw0jaVp/pjZE8+4tzw/Mvm5T8wSVZL2ysJfmX4WffKl
k7RI46jiiQfFLJbSF5pgXUEm00/Ut3g7otp2F+iZLuAplJwoojl7cgezTSAgRc9E
Rhv07SsL5AAZ5OyCOdeQ
=rQK5
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-06-21 18:26 (unknown) Paul Walmsley
@ 2012-06-22 8:56 ` Tony Lindgren
0 siblings, 0 replies; 669+ messages in thread
From: Tony Lindgren @ 2012-06-22 8:56 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-omap, linux-arm-kernel, khilman, Omar Ramirez Luna, peter.ujfalusi
* Paul Walmsley <paul@pwsan.com> [120621 11:31]:
> Hi Tony
>
> The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
>
> Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
>
> for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
>
> Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
>
> ----------------------------------------------------------------
>
> Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
>
> ----------------------------------------------------------------
Merging into cleanup-hwmod and merging into l-o master for testing.
Tony
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2012-06-22 8:56 ` Tony Lindgren
0 siblings, 0 replies; 669+ messages in thread
From: Tony Lindgren @ 2012-06-22 8:56 UTC (permalink / raw)
To: linux-arm-kernel
* Paul Walmsley <paul@pwsan.com> [120621 11:31]:
> Hi Tony
>
> The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
>
> Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
>
> for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
>
> Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
>
> ----------------------------------------------------------------
>
> Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
>
> ----------------------------------------------------------------
Merging into cleanup-hwmod and merging into l-o master for testing.
Tony
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2012-05-06 14:17 Bruce Zu
2012-05-06 17:04 ` your mail Marcus Karlsson
0 siblings, 1 reply; 669+ messages in thread
From: Bruce Zu @ 2012-05-06 14:17 UTC (permalink / raw)
To: git
I want subscribe this git mail list
thanks!
Bruce Zu
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <1330599216.71336.YahooMailNeo@web30703.mail.mud.yahoo.com>]
* (unknown)
[not found] <1330599216.71336.YahooMailNeo@web30703.mail.mud.yahoo.com>
@ 2012-03-01 12:41 ` bella tk
2012-03-01 12:58 ` your mail David Sterba
0 siblings, 1 reply; 669+ messages in thread
From: bella tk @ 2012-03-01 12:41 UTC (permalink / raw)
To: linux-btrfs, chris.mason
Hi=A0
I want to use btrfs defrag tool but before that i want to know how much=
the disk is fragmented. I have tried to use filefrag but it gives me F=
IBMAP:invalid argument for many times. I am using e2fsprogs version 1.4=
2 on debian squeeze. Is there another way to find out the level of frag=
mentation on btrfs filesystem?
Thanks in advance
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-03-01 12:41 ` (unknown) bella tk
@ 2012-03-01 12:58 ` David Sterba
2012-03-01 14:26 ` Chris Mason
0 siblings, 1 reply; 669+ messages in thread
From: David Sterba @ 2012-03-01 12:58 UTC (permalink / raw)
To: bella tk; +Cc: linux-btrfs, chris.mason
On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
> I want to use btrfs defrag tool but before that i want to know how
> much the disk is fragmented. I have tried to use filefrag but it gives
> me FIBMAP:invalid argument for many times.
The only way to trigger FIBMAP on btrfs is to run filefrag with -B
option, but it should use FIEMAP by default and it works. With -v option
it'll list all extents.
> I am using e2fsprogs version 1.42 on debian squeeze. Is there another
> way to find out the level of fragmentation on btrfs filesystem?
For while filesystem fragmentation, you can use the btrfs-filefrags
too that Arne sent to the list some time ago.
If you're interested in file level fragmentation, then filefrag is the
tool to use, but beware that just counting extents is not enough, and
compression makes things more complicated to interpret results
correctly.
Also, defragmentation does unCOW the files (until the snapshot aware
defrag is finished).
david
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-03-01 12:58 ` your mail David Sterba
@ 2012-03-01 14:26 ` Chris Mason
0 siblings, 0 replies; 669+ messages in thread
From: Chris Mason @ 2012-03-01 14:26 UTC (permalink / raw)
To: bella tk, linux-btrfs
On Thu, Mar 01, 2012 at 01:58:14PM +0100, David Sterba wrote:
> On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
> > I want to use btrfs defrag tool but before that i want to know how
> > much the disk is fragmented. I have tried to use filefrag but it gives
> > me FIBMAP:invalid argument for many times.
>
> The only way to trigger FIBMAP on btrfs is to run filefrag with -B
> option, but it should use FIEMAP by default and it works. With -v option
> it'll list all extents.
We actually disabled bmap to keep the swap code from remembering fixed
offsets for btrfs files. The only way to get the mapping is with
fiemap.
The defrag ioctl won't bother defragging files that are not fragmented.
-chris
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2012-02-21 15:39 Yang Honggang
2012-02-21 11:34 ` your mail Hans J. Koch
0 siblings, 1 reply; 669+ messages in thread
From: Yang Honggang @ 2012-02-21 15:39 UTC (permalink / raw)
To: linux-kernel; +Cc: hjk
hi, everyone
Is there a mail list dedicated for UIO (userspace I/O)?
I want to contribute to UIO but did not find the right
mail list.
thx,
Joseph
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-02-21 15:39 Yang Honggang
@ 2012-02-21 11:34 ` Hans J. Koch
0 siblings, 0 replies; 669+ messages in thread
From: Hans J. Koch @ 2012-02-21 11:34 UTC (permalink / raw)
To: Yang Honggang; +Cc: linux-kernel, hjk
On Tue, Feb 21, 2012 at 10:39:18AM -0500, Yang Honggang wrote:
> hi, everyone
Please give your mail a proper subject line before posting.
If you talk about UIO, it should start with uio:
Otherwise, people won't read it and just send it to /dev/null.
>
> Is there a mail list dedicated for UIO (userspace I/O)?
No, there's not enough mail traffic to justify that.
> I want to contribute to UIO but did not find the right
> mail list.
Please send your contribution to LKML and Cc: me and Greg
Kroah-Hartman. If you change an existing driver, also Cc:
the author of that driver.
Thanks,
Hans
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Richard Weinberger @ 2012-02-12 0:21 UTC (permalink / raw)
To: linux-kernel
Cc: user-mode-linux-devel, viro, akpm, alan, gregkh, Richard Weinberger
Can you please review this patch?
Thanks,
//richard
---
>From d8f5e7953def150bcc1e6a39dbbe589f1c68bcbd Mon Sep 17 00:00:00 2001
From: Richard Weinberger <richard@nod.at>
Date: Sun, 12 Feb 2012 01:12:49 +0100
Subject: [PATCH] um: Use tty_port
UML's line driver has to use tty_port.
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/um/drivers/line.c | 212 +++++++++++---------------------------
arch/um/drivers/line.h | 13 ++-
arch/um/drivers/ssl.c | 16 +++-
arch/um/drivers/stdio_console.c | 14 ++-
4 files changed, 94 insertions(+), 161 deletions(-)
diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index c1cf220..c789748 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
{
struct chan *chan = data;
struct line *line = chan->line;
+ struct tty_struct *tty;
+
+ if (line) {
+ tty = tty_port_tty_get(&line->port);
+ chan_interrupt(&line->chan_list, &line->task, tty, irq);
+ tty_kref_put(tty);
+ }
- if (line)
- chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
return IRQ_HANDLED;
}
static void line_timer_cb(struct work_struct *work)
{
struct line *line = container_of(work, struct line, task.work);
+ struct tty_struct *tty;
- if (!line->throttled)
- chan_interrupt(&line->chan_list, &line->task, line->tty,
+ if (!line->throttled) {
+ tty = tty_port_tty_get(&line->port);
+ chan_interrupt(&line->chan_list, &line->task, tty,
line->driver->read_irq);
+
+ tty_kref_put(tty);
+ }
}
/*
@@ -228,92 +238,6 @@ void line_set_termios(struct tty_struct *tty, struct ktermios * old)
/* nothing */
}
-static const struct {
- int cmd;
- char *level;
- char *name;
-} tty_ioctls[] = {
- /* don't print these, they flood the log ... */
- { TCGETS, NULL, "TCGETS" },
- { TCSETS, NULL, "TCSETS" },
- { TCSETSW, NULL, "TCSETSW" },
- { TCFLSH, NULL, "TCFLSH" },
- { TCSBRK, NULL, "TCSBRK" },
-
- /* general tty stuff */
- { TCSETSF, KERN_DEBUG, "TCSETSF" },
- { TCGETA, KERN_DEBUG, "TCGETA" },
- { TIOCMGET, KERN_DEBUG, "TIOCMGET" },
- { TCSBRKP, KERN_DEBUG, "TCSBRKP" },
- { TIOCMSET, KERN_DEBUG, "TIOCMSET" },
-
- /* linux-specific ones */
- { TIOCLINUX, KERN_INFO, "TIOCLINUX" },
- { KDGKBMODE, KERN_INFO, "KDGKBMODE" },
- { KDGKBTYPE, KERN_INFO, "KDGKBTYPE" },
- { KDSIGACCEPT, KERN_INFO, "KDSIGACCEPT" },
-};
-
-int line_ioctl(struct tty_struct *tty, unsigned int cmd,
- unsigned long arg)
-{
- int ret;
- int i;
-
- ret = 0;
- switch(cmd) {
-#ifdef TIOCGETP
- case TIOCGETP:
- case TIOCSETP:
- case TIOCSETN:
-#endif
-#ifdef TIOCGETC
- case TIOCGETC:
- case TIOCSETC:
-#endif
-#ifdef TIOCGLTC
- case TIOCGLTC:
- case TIOCSLTC:
-#endif
- /* Note: these are out of date as we now have TCGETS2 etc but this
- whole lot should probably go away */
- case TCGETS:
- case TCSETSF:
- case TCSETSW:
- case TCSETS:
- case TCGETA:
- case TCSETAF:
- case TCSETAW:
- case TCSETA:
- case TCXONC:
- case TCFLSH:
- case TIOCOUTQ:
- case TIOCINQ:
- case TIOCGLCKTRMIOS:
- case TIOCSLCKTRMIOS:
- case TIOCPKT:
- case TIOCGSOFTCAR:
- case TIOCSSOFTCAR:
- return -ENOIOCTLCMD;
-#if 0
- case TCwhatever:
- /* do something */
- break;
-#endif
- default:
- for (i = 0; i < ARRAY_SIZE(tty_ioctls); i++)
- if (cmd == tty_ioctls[i].cmd)
- break;
- if (i == ARRAY_SIZE(tty_ioctls)) {
- printk(KERN_ERR "%s: %s: unknown ioctl: 0x%x\n",
- __func__, tty->name, cmd);
- }
- ret = -ENOIOCTLCMD;
- break;
- }
- return ret;
-}
-
void line_throttle(struct tty_struct *tty)
{
struct line *line = tty->driver_data;
@@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
{
struct chan *chan = data;
struct line *line = chan->line;
- struct tty_struct *tty = line->tty;
+ struct tty_struct *tty = tty_port_tty_get(&line->port);
int err;
/*
@@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
spin_lock(&line->lock);
err = flush_buffer(line);
if (err == 0) {
+ tty_kref_put(tty);
+
+ spin_unlock(&line->lock);
return IRQ_NONE;
} else if (err < 0) {
line->head = line->buffer;
@@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
return IRQ_NONE;
tty_wakeup(tty);
+ tty_kref_put(tty);
return IRQ_HANDLED;
}
+static const struct tty_port_operations line_port_ops;
+
int line_setup_irq(int fd, int input, int output, struct line *line, void *data)
{
const struct line_driver *driver = line->driver;
@@ -404,27 +334,27 @@ int line_setup_irq(int fd, int input, int output, struct line *line, void *data)
* first open or last close. Otherwise, open and close just return.
*/
-int line_open(struct line *lines, struct tty_struct *tty)
+int line_open(struct tty_struct *tty, struct file *filp)
{
- struct line *line = &lines[tty->index];
- int err = -ENODEV;
+ struct line *line = tty->driver_data;
+ return tty_port_open(&line->port, tty, filp);
+}
- spin_lock(&line->count_lock);
- if (!line->valid)
- goto out_unlock;
+int line_install(struct tty_driver *driver, struct tty_struct *tty, struct line *line)
+{
+ int ret = tty_init_termios(tty);
- err = 0;
- if (line->count++)
- goto out_unlock;
+ if (ret)
+ return ret;
- BUG_ON(tty->driver_data);
+ tty_driver_kref_get(driver);
+ tty->count++;
tty->driver_data = line;
- line->tty = tty;
+ driver->ttys[tty->index] = tty;
- spin_unlock(&line->count_lock);
- err = enable_chan(line);
- if (err) /* line_close() will be called by our caller */
- return err;
+ ret = enable_chan(line);
+ if (ret)
+ return ret;
INIT_DELAYED_WORK(&line->task, line_timer_cb);
@@ -437,48 +367,36 @@ int line_open(struct line *lines, struct tty_struct *tty)
&tty->winsize.ws_col);
return 0;
-
-out_unlock:
- spin_unlock(&line->count_lock);
- return err;
}
static void unregister_winch(struct tty_struct *tty);
-void line_close(struct tty_struct *tty, struct file * filp)
+void line_cleanup(struct tty_struct *tty)
{
struct line *line = tty->driver_data;
- /*
- * If line_open fails (and tty->driver_data is never set),
- * tty_open will call line_close. So just return in this case.
- */
- if (line == NULL)
- return;
-
- /* We ignore the error anyway! */
- flush_buffer(line);
-
- spin_lock(&line->count_lock);
- BUG_ON(!line->valid);
-
- if (--line->count)
- goto out_unlock;
-
- line->tty = NULL;
- tty->driver_data = NULL;
-
- spin_unlock(&line->count_lock);
-
if (line->sigio) {
unregister_winch(tty);
line->sigio = 0;
}
- return;
+ tty->driver_data = NULL;
+}
+
+void line_close(struct tty_struct *tty, struct file * filp)
+{
+ struct line *line = tty->driver_data;
+
+ if (!line)
+ return;
+
+ tty_port_close(&line->port, tty, filp);
+}
-out_unlock:
- spin_unlock(&line->count_lock);
+void line_hangup(struct tty_struct *tty)
+{
+ struct line *line = tty->driver_data;
+ tty_port_hangup(&line->port);
}
void close_lines(struct line *lines, int nlines)
@@ -495,13 +413,6 @@ static int setup_one_line(struct line *lines, int n, char *init, int init_prio,
struct line *line = &lines[n];
int err = -EINVAL;
- spin_lock(&line->count_lock);
-
- if (line->count) {
- *error_out = "Device is already open";
- goto out;
- }
-
if (line->init_pri <= init_prio) {
line->init_pri = init_prio;
if (!strcmp(init, "none"))
@@ -512,8 +423,7 @@ static int setup_one_line(struct line *lines, int n, char *init, int init_prio,
}
}
err = 0;
-out:
- spin_unlock(&line->count_lock);
+
return err;
}
@@ -598,6 +508,7 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
struct line *line;
char *end;
int dev, n = 0;
+ struct tty_struct *tty;
dev = simple_strtoul(name, &end, 0);
if ((*end != '\0') || (end == name)) {
@@ -612,13 +523,15 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
line = &lines[dev];
- spin_lock(&line->count_lock);
+ tty = tty_port_tty_get(&line->port);
+
if (!line->valid)
CONFIG_CHUNK(str, size, n, "none", 1);
- else if (line->tty == NULL)
+ else if (tty == NULL)
CONFIG_CHUNK(str, size, n, line->init_str, 1);
else n = chan_config_string(&line->chan_list, str, size, error_out);
- spin_unlock(&line->count_lock);
+
+ tty_kref_put(tty);
return n;
}
@@ -678,8 +591,8 @@ struct tty_driver *register_lines(struct line_driver *line_driver,
}
for(i = 0; i < nlines; i++) {
- if (!lines[i].valid)
- tty_unregister_device(driver, i);
+ tty_port_init(&lines[i].port);
+ lines[i].port.ops = &line_port_ops;
}
mconsole_register_dev(&line_driver->mc);
@@ -805,7 +718,6 @@ void register_winch_irq(int fd, int tty_fd, int pid, struct tty_struct *tty,
.pid = pid,
.tty = tty,
.stack = stack });
-
if (um_request_irq(WINCH_IRQ, fd, IRQ_READ, winch_interrupt,
IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
"winch", winch) < 0) {
diff --git a/arch/um/drivers/line.h b/arch/um/drivers/line.h
index 63df3ca..54adfc6 100644
--- a/arch/um/drivers/line.h
+++ b/arch/um/drivers/line.h
@@ -31,9 +31,8 @@ struct line_driver {
};
struct line {
- struct tty_struct *tty;
- spinlock_t count_lock;
- unsigned long count;
+ struct tty_port port;
+
int valid;
char *init_str;
@@ -59,15 +58,17 @@ struct line {
};
#define LINE_INIT(str, d) \
- { .count_lock = __SPIN_LOCK_UNLOCKED((str).count_lock), \
- .init_str = str, \
+ { .init_str = str, \
.init_pri = INIT_STATIC, \
.valid = 1, \
.lock = __SPIN_LOCK_UNLOCKED((str).lock), \
.driver = d }
extern void line_close(struct tty_struct *tty, struct file * filp);
-extern int line_open(struct line *lines, struct tty_struct *tty);
+extern int line_open(struct tty_struct *tty, struct file *filp);
+extern int line_install(struct tty_driver *driver, struct tty_struct *tty, struct line *line);
+extern void line_cleanup(struct tty_struct *tty);
+extern void line_hangup(struct tty_struct *tty);
extern int line_setup(struct line *lines, unsigned int sizeof_lines,
char *init, char **error_out);
extern int line_write(struct tty_struct *tty, const unsigned char *buf,
diff --git a/arch/um/drivers/ssl.c b/arch/um/drivers/ssl.c
index 9d8c20a..89e4e75 100644
--- a/arch/um/drivers/ssl.c
+++ b/arch/um/drivers/ssl.c
@@ -92,6 +92,7 @@ static int ssl_remove(int n, char **error_out)
error_out);
}
+#if 0
static int ssl_open(struct tty_struct *tty, struct file *filp)
{
int err = line_open(serial_lines, tty);
@@ -103,7 +104,6 @@ static int ssl_open(struct tty_struct *tty, struct file *filp)
return err;
}
-#if 0
static void ssl_flush_buffer(struct tty_struct *tty)
{
return;
@@ -124,8 +124,16 @@ void ssl_hangup(struct tty_struct *tty)
}
#endif
+static int ssl_install(struct tty_driver *driver, struct tty_struct *tty)
+{
+ if (tty->index < NR_PORTS)
+ return line_install(driver, tty, &serial_lines[tty->index]);
+ else
+ return -ENODEV;
+}
+
static const struct tty_operations ssl_ops = {
- .open = ssl_open,
+ .open = line_open,
.close = line_close,
.write = line_write,
.put_char = line_put_char,
@@ -134,9 +142,11 @@ static const struct tty_operations ssl_ops = {
.flush_buffer = line_flush_buffer,
.flush_chars = line_flush_chars,
.set_termios = line_set_termios,
- .ioctl = line_ioctl,
.throttle = line_throttle,
.unthrottle = line_unthrottle,
+ .install = ssl_install,
+ .cleanup = line_cleanup,
+ .hangup = line_hangup,
#if 0
.stop = ssl_stop,
.start = ssl_start,
diff --git a/arch/um/drivers/stdio_console.c b/arch/um/drivers/stdio_console.c
index 088776f..014f3ee 100644
--- a/arch/um/drivers/stdio_console.c
+++ b/arch/um/drivers/stdio_console.c
@@ -97,7 +97,7 @@ static int con_remove(int n, char **error_out)
static int con_open(struct tty_struct *tty, struct file *filp)
{
- int err = line_open(vts, tty);
+ int err = line_open(tty, filp);
if (err)
printk(KERN_ERR "Failed to open console %d, err = %d\n",
tty->index, err);
@@ -105,6 +105,14 @@ static int con_open(struct tty_struct *tty, struct file *filp)
return err;
}
+static int con_install(struct tty_driver *driver, struct tty_struct *tty)
+{
+ if (tty->index < MAX_TTYS)
+ return line_install(driver, tty, &vts[tty->index]);
+ else
+ return -ENODEV;
+}
+
/* Set in an initcall, checked in an exitcall */
static int con_init_done = 0;
@@ -118,9 +126,11 @@ static const struct tty_operations console_ops = {
.flush_buffer = line_flush_buffer,
.flush_chars = line_flush_chars,
.set_termios = line_set_termios,
- .ioctl = line_ioctl,
.throttle = line_throttle,
.unthrottle = line_unthrottle,
+ .cleanup = line_cleanup,
+ .install = con_install,
+ .hangup = line_hangup,
};
static void uml_console_write(struct console *console, const char *string,
--
1.7.7.3
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2012-02-12 0:21 Richard Weinberger
@ 2012-02-12 0:25 ` Jesper Juhl
2012-02-12 1:02 ` Al Viro
2012-02-12 19:11 ` Al Viro
2 siblings, 0 replies; 669+ messages in thread
From: Jesper Juhl @ 2012-02-12 0:25 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, user-mode-linux-devel, viro, akpm, alan, gregkh
On Sun, 12 Feb 2012, Richard Weinberger wrote:
> Can you please review this patch?
>
A subject on the mail along with a description of the patch would make
that a great deal easier...
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
@ 2012-02-12 1:02 ` Al Viro
2012-02-12 12:40 ` Jiri Slaby
2012-02-12 19:11 ` Al Viro
2 siblings, 1 reply; 669+ messages in thread
From: Al Viro @ 2012-02-12 1:02 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, user-mode-linux-devel, akpm, alan, gregkh
On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
Not a full review by any means, but...
> +++ b/arch/um/drivers/line.c
> @@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
> {
> struct chan *chan = data;
> struct line *line = chan->line;
> + struct tty_struct *tty;
> +
> + if (line) {
> + tty = tty_port_tty_get(&line->port);
> + chan_interrupt(&line->chan_list, &line->task, tty, irq);
> + tty_kref_put(tty);
> + }
>
> - if (line)
> - chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
> return IRQ_HANDLED;
> }
Is tty_kref_put() safe in interrupt? Here it seems to be OK, but in other
callers... More or less at random: drivers/tty/serial/lantiq.c has it
called from lqasc_rx_int(). It seems to be possible to have it end up
calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
we have it called from. Alan?
> @@ -495,13 +413,6 @@ static int setup_one_line(struct line *lines, int n, char *init, int init_prio,
> struct line *line = &lines[n];
> int err = -EINVAL;
>
> - spin_lock(&line->count_lock);
> -
> - if (line->count) {
> - *error_out = "Device is already open";
> - goto out;
> - }
... and similar in line_open() - just what happens if you try to reconfigure
an opened one?
> @@ -612,13 +523,15 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
>
> line = &lines[dev];
>
> - spin_lock(&line->count_lock);
> + tty = tty_port_tty_get(&line->port);
> +
> if (!line->valid)
> CONFIG_CHUNK(str, size, n, "none", 1);
> - else if (line->tty == NULL)
> + else if (tty == NULL)
> CONFIG_CHUNK(str, size, n, line->init_str, 1);
> else n = chan_config_string(&line->chan_list, str, size, error_out);
> - spin_unlock(&line->count_lock);
> +
> + tty_kref_put(tty);
again, where's the exclusion with config changes?
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-02-12 1:02 ` Al Viro
@ 2012-02-12 12:40 ` Jiri Slaby
2012-02-12 19:06 ` Al Viro
0 siblings, 1 reply; 669+ messages in thread
From: Jiri Slaby @ 2012-02-12 12:40 UTC (permalink / raw)
To: Al Viro
Cc: Richard Weinberger, linux-kernel, user-mode-linux-devel, akpm,
alan, gregkh, Jiri Slaby
On 02/12/2012 02:02 AM, Al Viro wrote:
> On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
>> +++ b/arch/um/drivers/line.c
>> @@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
>> {
>> struct chan *chan = data;
>> struct line *line = chan->line;
>> + struct tty_struct *tty;
>> +
>> + if (line) {
>> + tty = tty_port_tty_get(&line->port);
>> + chan_interrupt(&line->chan_list, &line->task, tty, irq);
>> + tty_kref_put(tty);
>> + }
>>
>> - if (line)
>> - chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
>> return IRQ_HANDLED;
>> }
>
> Is tty_kref_put() safe in interrupt? Here it seems to be OK, but in other
> callers... More or less at random: drivers/tty/serial/lantiq.c has it
> called from lqasc_rx_int(). It seems to be possible to have it end up
> calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
> Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
> we have it called from. Alan?
I'm not Alan, but will reply anyway. Yes, it is safe (unless the driver
does something tricky). In the driver you mention, this is uart_ops,
called from tty_port_operations' ->shutdown. And that's a different from
tty_operations' ->shutdown.
Yes, there are:
* tty->ops
* tty_port->ops
* uart_port->ops
uart_port->ops->shutdown is supposed to tear down interrupts like in
lantiq.c. It is called from tty_port->ops->shutdown. And that one is
allowed to be called only from user context (tty->ops->close and
tty->ops->hangup).
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-02-12 12:40 ` Jiri Slaby
@ 2012-02-12 19:06 ` Al Viro
2012-02-13 9:40 ` Jiri Slaby
0 siblings, 1 reply; 669+ messages in thread
From: Al Viro @ 2012-02-12 19:06 UTC (permalink / raw)
To: Jiri Slaby
Cc: Richard Weinberger, linux-kernel, user-mode-linux-devel, akpm,
alan, gregkh, Jiri Slaby
On Sun, Feb 12, 2012 at 01:40:47PM +0100, Jiri Slaby wrote:
> > Is tty_kref_put() safe in interrupt? Here it seems to be OK, but in other
> > callers... More or less at random: drivers/tty/serial/lantiq.c has it
> > called from lqasc_rx_int(). It seems to be possible to have it end up
> > calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
> > Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
> > we have it called from. Alan?
>
> I'm not Alan, but will reply anyway. Yes, it is safe (unless the driver
> does something tricky). In the driver you mention, this is uart_ops,
> called from tty_port_operations' ->shutdown. And that's a different from
> tty_operations' ->shutdown.
>
> Yes, there are:
> * tty->ops
> * tty_port->ops
> * uart_port->ops
>
> uart_port->ops->shutdown is supposed to tear down interrupts like in
> lantiq.c. It is called from tty_port->ops->shutdown. And that one is
> allowed to be called only from user context (tty->ops->close and
> tty->ops->hangup).
Yecchhh... If I'm reading (and grepping) it right, there are only two
non-default instance of tty_operations ->shutdown() - pty and vt ones.
Lovely... And while we are at it, vt instance is definitely not safe
from interrupts - calls console_lock(). Not that it was relevant in
this case...
It's probably too late in this case, but I would've called that method
->sync_cleanup(). Assuming I'm not misreading its intent and history...
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-02-12 19:06 ` Al Viro
@ 2012-02-13 9:40 ` Jiri Slaby
0 siblings, 0 replies; 669+ messages in thread
From: Jiri Slaby @ 2012-02-13 9:40 UTC (permalink / raw)
To: Al Viro
Cc: Jiri Slaby, Richard Weinberger, linux-kernel,
user-mode-linux-devel, akpm, alan, gregkh
On 02/12/2012 08:06 PM, Al Viro wrote:
> Yecchhh... If I'm reading (and grepping) it right, there are only two
> non-default instance of tty_operations ->shutdown() - pty and vt ones.
> Lovely... And while we are at it, vt instance is definitely not safe
> from interrupts - calls console_lock(). Not that it was relevant in
> this case...
Thanks for looking into that. I was too lazy to do that on Sunday.
You're right that it may cause problems. Fortunately vt doesn't refcount
ttys. Hence con_shutdown can be called only from release_tty (close
path) in the user context.
Adding to my TODO list, unless somebody beats me to fix it.
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
2012-02-12 1:02 ` Al Viro
@ 2012-02-12 19:11 ` Al Viro
2012-02-13 9:15 ` Jiri Slaby
2 siblings, 1 reply; 669+ messages in thread
From: Al Viro @ 2012-02-12 19:11 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, user-mode-linux-devel, akpm, alan, gregkh
On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
> @@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
> {
> struct chan *chan = data;
> struct line *line = chan->line;
> - struct tty_struct *tty = line->tty;
> + struct tty_struct *tty = tty_port_tty_get(&line->port);
> int err;
>
> /*
> @@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
> spin_lock(&line->lock);
> err = flush_buffer(line);
> if (err == 0) {
> + tty_kref_put(tty);
> +
> + spin_unlock(&line->lock);
> return IRQ_NONE;
> } else if (err < 0) {
> line->head = line->buffer;
> @@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
> return IRQ_NONE;
>
> tty_wakeup(tty);
> + tty_kref_put(tty);
> return IRQ_HANDLED;
> }
That, BTW, smells ugly. Note that return before the last one has no
tty_kref_put() for a very good reason - it's under if (!tty). And
just as line->tty, port->tty can become NULL, so tty_port_tty_get()
can, indeed, return NULL here. Which makes the first tty_kref_put()
oopsable...
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-02-12 19:11 ` Al Viro
@ 2012-02-13 9:15 ` Jiri Slaby
0 siblings, 0 replies; 669+ messages in thread
From: Jiri Slaby @ 2012-02-13 9:15 UTC (permalink / raw)
To: Al Viro
Cc: Richard Weinberger, linux-kernel, user-mode-linux-devel, akpm,
alan, gregkh
On 02/12/2012 08:11 PM, Al Viro wrote:
> On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
>
>> @@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>> {
>> struct chan *chan = data;
>> struct line *line = chan->line;
>> - struct tty_struct *tty = line->tty;
>> + struct tty_struct *tty = tty_port_tty_get(&line->port);
>> int err;
>>
>> /*
>> @@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>> spin_lock(&line->lock);
>> err = flush_buffer(line);
>> if (err == 0) {
>> + tty_kref_put(tty);
>> +
>> + spin_unlock(&line->lock);
>> return IRQ_NONE;
>> } else if (err < 0) {
>> line->head = line->buffer;
>> @@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>> return IRQ_NONE;
>>
>> tty_wakeup(tty);
>> + tty_kref_put(tty);
>> return IRQ_HANDLED;
>> }
>
> That, BTW, smells ugly. Note that return before the last one has no
> tty_kref_put() for a very good reason - it's under if (!tty). And
> just as line->tty, port->tty can become NULL, so tty_port_tty_get()
> can, indeed, return NULL here. Which makes the first tty_kref_put()
> oopsable...
Nope, it is allowed to call tty_kref_put(NULL).
regards,
--
js
suse labs
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se>]
* Re: your mail
[not found] <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se>
@ 2012-01-25 13:26 ` Henrik Rydberg
2012-01-25 14:09 ` Maurus Cuelenaere
0 siblings, 1 reply; 669+ messages in thread
From: Henrik Rydberg @ 2012-01-25 13:26 UTC (permalink / raw)
To: mcuelenaere; +Cc: linux-input
Hi Maurus,
> Subject: [RFC] HID: add Microsoft Touch Mouse driver
>
> This patch adds support for the proprietary Microsoft Touch Mouse
> multitouch protocol.
Exciting stuff, nice job on the patch too. Please find some initial
comments inline.
> @@ -0,0 +1,371 @@
> +/*
> + * HID driver for the Microsoft Touch Mouse
> + *
> + * Copyright (c) 2011 Maurus Cuelenaere <mcuelenaere@gmail.com>
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +#include <linux/usb.h>
> +
> +#include "hid-ids.h"
> +
> +#define MSTM_RAW_DATA_HID_ID 0x27
> +#define MSTM_RAW_DATA_FOOTER 0x51
> +
> +#define MSTM_DATA_WIDTH 15
> +#define MSTM_DATA_HEIGHT 13
> +
> +struct mstm_raw_data_packet {
> + __u8 hid_id;
> + __u8 data_length;
> + __u16 unk1;
> + __u8 unk2;
> + __u8 footer;
> + __u8 timestamp;
> + __u8 data[25]; /* milliseconds */
> +};
I take it this means you get at most 50 nibbles per transfer?
> +
> +struct mstm_state {
> + bool advance_flag;
> + int x;
> + int y;
> + unsigned char last_timestamp;
> + unsigned char data[MSTM_DATA_WIDTH][MSTM_DATA_HEIGHT];
> +};
The ability to simply send an "input screen" would be perfect
here. This device may be on the border of what can/should be handled
via input events. A memory mapped driver, uio-based or something
similar, could be an option.
> +
> +struct mstm_device {
> + struct input_dev *input;
> +
> + struct mstm_state state;
> +};
> +
> +#define MSTM_INTERFACE_KEYBOARD 0
> +#define MSTM_INTERFACE_MOUSE 1
> +#define MSTM_INTERFACE_CONTROL 2
> +
> +static inline int hid_get_interface_number(struct hid_device *hdev) {
> + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> + return intf->cur_altsetting->desc.bInterfaceNumber;
> +}
> +
> +/*
> + * The mouse sensor only yields data for a specific part of its surface.
> + * Because of this, we can't just increase x and y uniformly; so there's
> + * a need for this simple algorithm.
> + *
> + * Visual representation of available data:
> + * 0 1 2 3 4 5 6 7 8 9 A B C D E F
> + * 0 * * * * * * * * * *
> + * 1 * * * * * * * * * * * *
> + * 2 * * * * * * * * * * * * * *
> + * 3 * * * * * * * * * * * * * *
> + * 4 * * * * * * * * * * * * * * * *
> + * 5 * * * * * * * * * * * * * * * *
> + * 6 * * * * * * * * * * * * * * * *
> + * 7 * * * * * * * * * * * * * * * *
> + * 8 * * * * * * * * * * * * * * * *
> + * 9 * * * * * * * * * * * * * * * *
> + * A * * * * * * * * * * * * * * * *
> + * B * * * * * * * * * * * * * * * *
> + * C * * * * * * * * * * * * * * * *
> + * D * * * * * * * * * * * * * * * *
> + */
> +static void mstm_advance_pointer(struct mstm_state *state)
> +{
> + int max, nextMin;
> +
> + state->x++;
> +
> + switch (state->y) {
> + case 0:
> + max = 11;
> + nextMin = 2;
> + break;
> + case 1:
> + max = 12;
> + nextMin = 1;
> + break;
> + case 2:
> + max = 13;
> + nextMin = 1;
> + break;
> + case 3:
> + max = 13;
> + nextMin = 0;
> + break;
> + default:
> + max = 14;
> + nextMin = 0;
> + break;
> + }
> +
> + if (state->x > max) {
> + state->y++;
> + state->x = nextMin;
> + }
> +}
> +
> +static void mstm_parse_nibble(struct mstm_state *state, __u8 nibble)
> +{
> + int i;
> +
> + if (state->advance_flag) {
> + state->advance_flag = false;
> + for (i = -3; i < nibble; i++)
> + mstm_advance_pointer(state);
> + } else {
> + if (nibble == 0xF) {
> + /* The next nibble will indicate how many
> + * positions to advance, so set a flag */
> + state->advance_flag = true;
> + } else {
> + state->data[state->x][state->y] = nibble;
> + mstm_advance_pointer(state);
> + }
> + }
> +}
Looking good.
> +static void mstm_push_data(struct hid_device *hdev)
> +{
> + struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
> + struct input_dev *input = mstm_dev->input;
> + int x, y;
> +
> + for (x = 0; x < MSTM_DATA_WIDTH; x++) {
> + for (y = 0; y < MSTM_DATA_HEIGHT; y++) {
> + unsigned char pressure = mstm_dev->state.data[x][y];
> + if (pressure > 0) {
> + //input_report_abs(input, ABS_MT_BLOB_ID, 1);
> + //input_report_abs(input, ABS_MT_TOUCH_MAJOR, pressure/3);
> + input_report_abs(input, ABS_MT_POSITION_X, x);
> + input_report_abs(input, ABS_MT_POSITION_Y, y);
> + input_mt_sync(input);
> + }
> + }
> + }
True, the blob id has not yet been used, but its definition is
different from how it is used here. Also, since you do not attempt any
kind of clustering (single-linkage or similar), the blob as stated
might not even be connected. One possible option could be to use the
slots, but only send ABS_MT_TOUCH_MAJOR or ABS_MT_PRESSURE, nothing
else. The device would (rightfully) not be recognized as MT since the
position is missing, all data would be available for processing in
userspace, and bandwidth would be minimized since there could only be
so many changes coming in per millisecond.
> +static int mstm_input_mapping(struct hid_device *hdev,
> + struct hid_input *hi, struct hid_field *field,
> + struct hid_usage *usage, unsigned long **bit, int *max)
> +{
> + struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
> +
> + //printk("mstm_input_mapping(%p)\n", hdev);
> +
> + /* bail early if not the correct interface */
> + if (mstm_dev == NULL)
> + return 0;
> +
> + /* HACK: get rid of ABS_MT_* params */
> + if ((usage->hid & HID_USAGE_PAGE) == HID_UP_GENDESK)
> + return -1;
I am not sure about the hack here, nor its explanation. ;-)
> +
> + /* map input device to hid device */
> + mstm_dev->input = hi->input;
> +
> + return 0;
> +}
> +
> +static void mstm_setup_input(struct mstm_device *mstm)
> +{
> + __set_bit(EV_ABS, mstm->input->evbit);
> +
> + input_set_abs_params(mstm->input, ABS_MT_POSITION_X, 0, MSTM_DATA_WIDTH, 0, 0);
> + input_set_abs_params(mstm->input, ABS_MT_POSITION_Y, 0, MSTM_DATA_HEIGHT, 0, 0);
> + input_set_abs_params(mstm->input, ABS_MT_TOUCH_MAJOR, 0, 0xF, 0, 0);
> + input_set_abs_params(mstm->input, ABS_MT_BLOB_ID, 0, 10, 0, 0);
> +
> + input_abs_set_res(mstm->input, ABS_MT_POSITION_X, 6); /* 83mm */
> + input_abs_set_res(mstm->input, ABS_MT_POSITION_Y, 5); /* 70mm */
> +
> + input_set_events_per_packet(mstm->input, 60);
> +}
Regarding the resolution of touch major, it is generally assumed (in
userspace) that the units are the same as the position, so scaling in
the driver is reasonable. Otherwise, why not specify resolution for
touch major as well?
Thanks,
Henrik
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2012-01-25 13:26 ` Henrik Rydberg
@ 2012-01-25 14:09 ` Maurus Cuelenaere
0 siblings, 0 replies; 669+ messages in thread
From: Maurus Cuelenaere @ 2012-01-25 14:09 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: linux-input
Hi Henrik,
Op 25-01-12 14:26, Henrik Rydberg schreef:
> Hi Maurus,
>
>> Subject: [RFC] HID: add Microsoft Touch Mouse driver
>>
>> This patch adds support for the proprietary Microsoft Touch Mouse
>> multitouch protocol.
> Exciting stuff, nice job on the patch too. Please find some initial
> comments inline.
>
>> @@ -0,0 +1,371 @@
>> +/*
>> + * HID driver for the Microsoft Touch Mouse
>> + *
>> + * Copyright (c) 2011 Maurus Cuelenaere<mcuelenaere@gmail.com>
>> + *
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>> + *
>> + */
>> +
>> +#include<linux/device.h>
>> +#include<linux/input.h>
>> +#include<linux/hid.h>
>> +#include<linux/module.h>
>> +#include<linux/usb.h>
>> +
>> +#include "hid-ids.h"
>> +
>> +#define MSTM_RAW_DATA_HID_ID 0x27
>> +#define MSTM_RAW_DATA_FOOTER 0x51
>> +
>> +#define MSTM_DATA_WIDTH 15
>> +#define MSTM_DATA_HEIGHT 13
>> +
>> +struct mstm_raw_data_packet {
>> + __u8 hid_id;
>> + __u8 data_length;
>> + __u16 unk1;
>> + __u8 unk2;
>> + __u8 footer;
>> + __u8 timestamp;
>> + __u8 data[25]; /* milliseconds */
>> +};
> I take it this means you get at most 50 nibbles per transfer?
Correct.
Hmm, looks like that milliseconds comment needs to be on the line above it.
>> +
>> +struct mstm_state {
>> + bool advance_flag;
>> + int x;
>> + int y;
>> + unsigned char last_timestamp;
>> + unsigned char data[MSTM_DATA_WIDTH][MSTM_DATA_HEIGHT];
>> +};
> The ability to simply send an "input screen" would be perfect
> here. This device may be on the border of what can/should be handled
> via input events. A memory mapped driver, uio-based or something
> similar, could be an option.
In my first tests, I was doing readouts in userspace using hidraw, which
performed quite well.
Bandwidth could be an issue, but I'd like to use the current APIs as
much as possible so I don't need to go modifying mtdev, X, ...
>> +
>> +struct mstm_device {
>> + struct input_dev *input;
>> +
>> + struct mstm_state state;
>> +};
>> +
>> +#define MSTM_INTERFACE_KEYBOARD 0
>> +#define MSTM_INTERFACE_MOUSE 1
>> +#define MSTM_INTERFACE_CONTROL 2
>> +
>> +static inline int hid_get_interface_number(struct hid_device *hdev) {
>> + struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>> + return intf->cur_altsetting->desc.bInterfaceNumber;
>> +}
>> +
>> +/*
>> + * The mouse sensor only yields data for a specific part of its surface.
>> + * Because of this, we can't just increase x and y uniformly; so there's
>> + * a need for this simple algorithm.
>> + *
>> + * Visual representation of available data:
>> + * 0 1 2 3 4 5 6 7 8 9 A B C D E F
>> + * 0 * * * * * * * * * *
>> + * 1 * * * * * * * * * * * *
>> + * 2 * * * * * * * * * * * * * *
>> + * 3 * * * * * * * * * * * * * *
>> + * 4 * * * * * * * * * * * * * * * *
>> + * 5 * * * * * * * * * * * * * * * *
>> + * 6 * * * * * * * * * * * * * * * *
>> + * 7 * * * * * * * * * * * * * * * *
>> + * 8 * * * * * * * * * * * * * * * *
>> + * 9 * * * * * * * * * * * * * * * *
>> + * A * * * * * * * * * * * * * * * *
>> + * B * * * * * * * * * * * * * * * *
>> + * C * * * * * * * * * * * * * * * *
>> + * D * * * * * * * * * * * * * * * *
>> + */
>> +static void mstm_advance_pointer(struct mstm_state *state)
>> +{
>> + int max, nextMin;
>> +
>> + state->x++;
>> +
>> + switch (state->y) {
>> + case 0:
>> + max = 11;
>> + nextMin = 2;
>> + break;
>> + case 1:
>> + max = 12;
>> + nextMin = 1;
>> + break;
>> + case 2:
>> + max = 13;
>> + nextMin = 1;
>> + break;
>> + case 3:
>> + max = 13;
>> + nextMin = 0;
>> + break;
>> + default:
>> + max = 14;
>> + nextMin = 0;
>> + break;
>> + }
>> +
>> + if (state->x> max) {
>> + state->y++;
>> + state->x = nextMin;
>> + }
>> +}
>> +
>> +static void mstm_parse_nibble(struct mstm_state *state, __u8 nibble)
>> +{
>> + int i;
>> +
>> + if (state->advance_flag) {
>> + state->advance_flag = false;
>> + for (i = -3; i< nibble; i++)
>> + mstm_advance_pointer(state);
>> + } else {
>> + if (nibble == 0xF) {
>> + /* The next nibble will indicate how many
>> + * positions to advance, so set a flag */
>> + state->advance_flag = true;
>> + } else {
>> + state->data[state->x][state->y] = nibble;
>> + mstm_advance_pointer(state);
>> + }
>> + }
>> +}
> Looking good.
>
>> +static void mstm_push_data(struct hid_device *hdev)
>> +{
>> + struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
>> + struct input_dev *input = mstm_dev->input;
>> + int x, y;
>> +
>> + for (x = 0; x< MSTM_DATA_WIDTH; x++) {
>> + for (y = 0; y< MSTM_DATA_HEIGHT; y++) {
>> + unsigned char pressure = mstm_dev->state.data[x][y];
>> + if (pressure> 0) {
>> + //input_report_abs(input, ABS_MT_BLOB_ID, 1);
>> + //input_report_abs(input, ABS_MT_TOUCH_MAJOR, pressure/3);
>> + input_report_abs(input, ABS_MT_POSITION_X, x);
>> + input_report_abs(input, ABS_MT_POSITION_Y, y);
>> + input_mt_sync(input);
>> + }
>> + }
>> + }
> True, the blob id has not yet been used, but its definition is
> different from how it is used here. Also, since you do not attempt any
> kind of clustering (single-linkage or similar), the blob as stated
> might not even be connected.
Indeed, without clustering the BLOB_ID would be useless but that line
was only for testing with one finger.
> One possible option could be to use the
> slots, but only send ABS_MT_TOUCH_MAJOR or ABS_MT_PRESSURE, nothing
> else. The device would (rightfully) not be recognized as MT since the
> position is missing, all data would be available for processing in
> userspace, and bandwidth would be minimized since there could only be
> so many changes coming in per millisecond.
So how does userspace then finds out where these pressure points are
located?
Or do you mean to just dump all data to user space (15 * 13 *
sizeof(ABS_MT_PRESSURE value) + overhead)?
>> +static int mstm_input_mapping(struct hid_device *hdev,
>> + struct hid_input *hi, struct hid_field *field,
>> + struct hid_usage *usage, unsigned long **bit, int *max)
>> +{
>> + struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
>> +
>> + //printk("mstm_input_mapping(%p)\n", hdev);
>> +
>> + /* bail early if not the correct interface */
>> + if (mstm_dev == NULL)
>> + return 0;
>> +
>> + /* HACK: get rid of ABS_MT_* params */
>> + if ((usage->hid& HID_USAGE_PAGE) == HID_UP_GENDESK)
>> + return -1;
> I am not sure about the hack here, nor its explanation. ;-)
The HID tables specify some ABS_MT_* values and I didn't know whether
these were going to conflict with the ones I report above, so I just
discard all GenericDesktop fields.
root@hp4530s:~# grep MT /sys/kernel/debug/hid/0003\:045E\:0773.0006/rdesc
GenericDesktop.MultiAxis ---> Absolute.MTMajor
GenericDesktop.0009 ---> Absolute.MTMinor
GenericDesktop.000a ---> Absolute.MTMajorW
GenericDesktop.000b ---> Absolute.MTMinorW
GenericDesktop.000c ---> Absolute.MTOrientation
GenericDesktop.000d ---> Absolute.MTPositionX
GenericDesktop.000e ---> Absolute.MTPositionY
GenericDesktop.000f ---> Absolute.MTToolType
GenericDesktop.0010 ---> Absolute.MTBlobID
>> +
>> + /* map input device to hid device */
>> + mstm_dev->input = hi->input;
>> +
>> + return 0;
>> +}
>> +
>> +static void mstm_setup_input(struct mstm_device *mstm)
>> +{
>> + __set_bit(EV_ABS, mstm->input->evbit);
>> +
>> + input_set_abs_params(mstm->input, ABS_MT_POSITION_X, 0, MSTM_DATA_WIDTH, 0, 0);
>> + input_set_abs_params(mstm->input, ABS_MT_POSITION_Y, 0, MSTM_DATA_HEIGHT, 0, 0);
>> + input_set_abs_params(mstm->input, ABS_MT_TOUCH_MAJOR, 0, 0xF, 0, 0);
>> + input_set_abs_params(mstm->input, ABS_MT_BLOB_ID, 0, 10, 0, 0);
>> +
>> + input_abs_set_res(mstm->input, ABS_MT_POSITION_X, 6); /* 83mm */
>> + input_abs_set_res(mstm->input, ABS_MT_POSITION_Y, 5); /* 70mm */
>> +
>> + input_set_events_per_packet(mstm->input, 60);
>> +}
> Regarding the resolution of touch major, it is generally assumed (in
> userspace) that the units are the same as the position, so scaling in
> the driver is reasonable. Otherwise, why not specify resolution for
> touch major as well?
I didn't specify it because other HID drivers only specified resolutions
for POSITION_{X,Y}, I'll try it and see how mtview reacts.
Thanks for the review!
--
Maurus Cuelenaere
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20120110061735.9BD676BA98@mailhub.coreip.homeip.net>]
* Re: your mail
[not found] <20120110061735.9BD676BA98@mailhub.coreip.homeip.net>
@ 2012-01-10 7:45 ` Dmitry Torokhov
0 siblings, 0 replies; 669+ messages in thread
From: Dmitry Torokhov @ 2012-01-10 7:45 UTC (permalink / raw)
To: Milton Miller; +Cc: Che-Liang Chiou, linux-kernel
On Mon, Jan 09, 2012 at 10:17:35PM -0800, Milton Miller wrote:
> Subject Re: [PATCH 1/2] Input: serio_raw - cosmetic fixes
> In-Reply-To: <20120109082412.GC4049@core.coreip.homeip.net>
> References: <20120109082412.GC4049@core.coreip.homeip.net>
> <1325847795-30486-1-git-send-email-clchiou@chromium.org>
> Date: Tue, 10 Jan 2012 00:14:35 -0600
> Subject: (No subject header)
> X-Originating-IP: 71.22.127.106
> Message-ID: <1326176075_1502@mail4.comsite.net>
>
> On Mon, 9 Jan 2012 about 00:24:12 -0800, Dmitry Torokhov wrote:
> > > struct serio_raw_client *client = file->private_data;
> > > struct serio_raw *serio_raw = client->serio_raw;
> > > - unsigned int mask;
> > >
> > > poll_wait(file, &serio_raw->wait, wait);
> > >
> > > - mask = serio_raw->dead ? POLLHUP | POLLERR : POLLOUT | POLLWRNORM;
> > > if (serio_raw->head != serio_raw->tail)
> > > return POLLIN | POLLRDNORM;
> > >
> >
> > This however is not quite correct. I will be applying the patch below
> > instead.
> >
> >
> > diff --git a/drivers/input/serio/serio_raw.c b/drivers/input/serio/serio_raw.c
> > index ca78a89..c2c6ad8 100644
> > --- a/drivers/input/serio/serio_raw.c
> > +++ b/drivers/input/serio/serio_raw.c
> > @@ -237,7 +237,7 @@ static unsigned int serio_raw_poll(struct file *file, poll_table *wait)
> >
> > mask = serio_raw->dead ? POLLHUP | POLLERR : POLLOUT | POLLWRNORM;
> > if (serio_raw->head != serio_raw->tail)
> > - return POLLIN | POLLRDNORM;
> > + mask |= POLLIN | POLLRDNORM;
> >
> > return 0;
>
> doesn't this need to be changed to return mask?
Doh! Of course it does.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 669+ messages in thread
* No subject
@ 2011-12-02 16:01 Will Deacon
2011-12-02 16:11 ` your mail Will Deacon
0 siblings, 1 reply; 669+ messages in thread
From: Will Deacon @ 2011-12-02 16:01 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2011-11-22 23:42 Tony Breeds
2011-11-22 23:47 ` your mail Tony Breeds
0 siblings, 1 reply; 669+ messages in thread
From: Tony Breeds @ 2011-11-22 23:42 UTC (permalink / raw)
To: LinuxPPC-dev
>From 1a44c074e3ce572cbf60d31ac704e6ce42be4708 Mon Sep 17 00:00:00 2001
From: Tony Breeds <tony@bakeyournoodle.com>
Date: Wed, 23 Nov 2011 10:16:40 +1100
Subject: [PATCH] powerpc: 44x: Add mtd ndfc to the ppx44x defconfig
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/configs/ppc44x_defconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/ppc44x_defconfig b/arch/powerpc/configs/ppc44x_defconfig
index 6cdf1c0..3b98d73 100644
--- a/arch/powerpc/configs/ppc44x_defconfig
+++ b/arch/powerpc/configs/ppc44x_defconfig
@@ -52,6 +52,8 @@ CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_NAND=m
+CONFIG_MTD_NAND_NDFC=m
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_GLUEBI=m
CONFIG_PROC_DEVICETREE=y
--
1.7.6.4
^ permalink raw reply related [flat|nested] 669+ messages in thread
* (no subject)
@ 2011-10-20 0:17 Mikulas Patocka
2011-10-20 0:57 ` your mail Alasdair G Kergon
2011-10-20 9:52 ` Joe Thornber
0 siblings, 2 replies; 669+ messages in thread
From: Mikulas Patocka @ 2011-10-20 0:17 UTC (permalink / raw)
To: Alasdair G. Kergon; +Cc: dm-devel, Edward Thornber
[-- Attachment #1: Type: TEXT/PLAIN, Size: 288 bytes --]
Hi
Here I'm sending two dm-bufio patches. The first one fixed
dm_bufio_release_move function (the write callback could be called with a
wrong block number). The next one adds a conditional resched (Alasdair
agreed on it --- it should be later put into general Linux headers).
Mikulas
[-- Attachment #2: Type: TEXT/PLAIN, Size: 1221 bytes --]
---
drivers/md/dm-bufio.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Index: linux-3.1-rc3-fast/drivers/md/dm-bufio.c
===================================================================
--- linux-3.1-rc3-fast.orig/drivers/md/dm-bufio.c 2011-10-19 18:39:22.000000000 +0200
+++ linux-3.1-rc3-fast/drivers/md/dm-bufio.c 2011-10-19 18:47:43.000000000 +0200
@@ -1185,11 +1185,24 @@ retry:
__unlink_buffer(b);
__link_buffer(b, new_block, LIST_DIRTY);
} else {
+ sector_t old_block;
wait_on_bit_lock(&b->state, B_WRITING,
do_io_schedule, TASK_UNINTERRUPTIBLE);
+ /*
+ * Relink buffer to "new_block" so that write_callback
+ * sees "new_block" as a block number.
+ * After the write, link the buffer back to old_block.
+ * All this must be done in bufio lock, so that block number
+ * change isn't visible to other threads.
+ */
+ old_block = b->block;
+ __unlink_buffer(b);
+ __link_buffer(b, new_block, b->list_mode);
submit_io(b, WRITE, new_block, write_endio);
wait_on_bit(&b->state, B_WRITING,
do_io_schedule, TASK_UNINTERRUPTIBLE);
+ __unlink_buffer(b);
+ __link_buffer(b, old_block, b->list_mode);
}
dm_bufio_unlock(c);
[-- Attachment #3: Type: TEXT/PLAIN, Size: 2874 bytes --]
---
drivers/md/dm-bufio.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
Index: linux-3.1-rc3-fast/drivers/md/dm-bufio.c
===================================================================
--- linux-3.1-rc3-fast.orig/drivers/md/dm-bufio.c 2011-10-19 18:49:14.000000000 +0200
+++ linux-3.1-rc3-fast/drivers/md/dm-bufio.c 2011-10-19 18:57:01.000000000 +0200
@@ -183,6 +183,16 @@ static void dm_bufio_unlock(struct dm_bu
mutex_unlock(&c->lock);
}
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+#define dm_bufio_cond_resched() \
+do { \
+ if (unlikely(need_resched())) \
+ _cond_resched(); \
+} while (0)
+#else
+#define dm_bufio_cond_resched() do { } while (0)
+#endif
+
/*----------------------------------------------------------------*/
/*
@@ -644,6 +654,7 @@ static struct dm_buffer *__get_unclaimed
__unlink_buffer(b);
return b;
}
+ dm_bufio_cond_resched();
}
list_for_each_entry_reverse(b, &c->lru[LIST_DIRTY], lru_list) {
@@ -654,6 +665,7 @@ static struct dm_buffer *__get_unclaimed
__unlink_buffer(b);
return b;
}
+ dm_bufio_cond_resched();
}
return NULL;
@@ -772,6 +784,7 @@ static void __write_dirty_buffers_async(
return;
__write_dirty_buffer(b);
+ dm_bufio_cond_resched();
}
}
@@ -820,6 +833,7 @@ static void __check_watermark(struct dm_
return;
__free_buffer_wake(b);
+ dm_bufio_cond_resched();
}
if (c->n_buffers[LIST_DIRTY] > threshold_buffers)
@@ -835,9 +849,11 @@ static struct dm_buffer *__find(struct d
struct hlist_node *hn;
hlist_for_each_entry(b, hn, &c->cache_hash[DM_BUFIO_HASH(block)],
- hash_list)
+ hash_list) {
+ dm_bufio_cond_resched();
if (b->block == block)
return b;
+ }
return NULL;
}
@@ -1084,6 +1100,8 @@ again:
!test_bit(B_WRITING, &b->state))
__relink_lru(b, LIST_CLEAN);
+ dm_bufio_cond_resched();
+
/*
* If we dropped the lock, the list is no longer consistent,
* so we must restart the search.
@@ -1310,11 +1328,13 @@ static void __scan(struct dm_bufio_clien
int l;
struct dm_buffer *b, *tmp;
- for (l = 0; l < LIST_SIZE; l++)
+ for (l = 0; l < LIST_SIZE; l++) {
list_for_each_entry_safe_reverse(b, tmp, &c->lru[l], lru_list)
if (!__cleanup_old_buffer(b, sc->gfp_mask, 0) &&
!--nr_to_scan)
return;
+ dm_bufio_cond_resched();
+ }
}
static int shrink(struct shrinker *shrinker, struct shrink_control *sc)
@@ -1531,9 +1551,11 @@ static void cleanup_old_buffers(void)
struct dm_buffer, lru_list);
if (__cleanup_old_buffer(b, 0, max_age * HZ))
break;
+ dm_bufio_cond_resched();
}
dm_bufio_unlock(c);
+ dm_bufio_cond_resched();
}
mutex_unlock(&dm_bufio_clients_lock);
}
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-10-20 0:17 (no subject) Mikulas Patocka
@ 2011-10-20 0:57 ` Alasdair G Kergon
2011-10-20 9:52 ` Joe Thornber
1 sibling, 0 replies; 669+ messages in thread
From: Alasdair G Kergon @ 2011-10-20 0:57 UTC (permalink / raw)
To: Mikulas Patocka; +Cc: dm-devel, thornber
On Wed, Oct 19, 2011 at 08:17:37PM -0400, Mikulas Patocka wrote:
> The next one adds a conditional resched (Alasdair
> agreed on it --- it should be later put into general Linux headers).
Indeed, this part:
> +#ifdef CONFIG_PREEMPT_VOLUNTARY
> +#define dm_bufio_cond_resched() \
> +do { \
> + if (unlikely(need_resched())) \
> + _cond_resched(); \
> +} while (0)
> +#else
> +#define dm_bufio_cond_resched() do { } while (0)
> +#endif
doesn't really belong in a dm file.
Alasdair
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-10-20 0:17 (no subject) Mikulas Patocka
2011-10-20 0:57 ` your mail Alasdair G Kergon
@ 2011-10-20 9:52 ` Joe Thornber
1 sibling, 0 replies; 669+ messages in thread
From: Joe Thornber @ 2011-10-20 9:52 UTC (permalink / raw)
To: Mikulas Patocka; +Cc: dm-devel, Alasdair G. Kergon
On Wed, Oct 19, 2011 at 08:17:37PM -0400, Mikulas Patocka wrote:
> Hi
>
> Here I'm sending two dm-bufio patches. The first one fixed
> dm_bufio_release_move function (the write callback could be called with a
> wrong block number). The next one adds a conditional resched (Alasdair
> agreed on it --- it should be later put into general Linux headers).
Thanks Mikulas, merging now.
- Joe
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2011-09-21 21:54 jim.cromie
2011-09-26 23:23 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: jim.cromie @ 2011-09-21 21:54 UTC (permalink / raw)
To: jbaron; +Cc: joe, bart.vanassche, greg, linux-kernel
hi all,
this reworked* patchset enhances dynamic-debug with:
- multiple queries on bootline, via ddebug_query='"...", formerly just
1 query was accepted. This also allows cat foo-queries > $CONTROL
to add numerous rules together.
- tolerance to errors in ddebug_query. Formerly, a bad rule would
kill the facility, now it stays up, you can correct the rule without
rebooting.
- pending queries. bootline can enable pr_debugs in an uninstalled
module, by adding 'a' flag. When module is loaded later, pr_debug
callsites are enabled, before module-init is run, so pr_debug can be
used in module-init. Currently pending queries are readable in
$DBGMT/dynamic_debug/pending
- filter flags. flags before the operator [+-=] are used to narrow
selection of callsites. This augments module, filename, function
filters, allowing:
echo p+t > $CONTROL # add TID to ALL enabled sites
echo ml+p > $CONTROL # enable sites marked earlier.
- src-dir relative paths in $CONTROL. Formerly, filenames were
printed with full path, and new rules had to use full path if
basename wasnt enough. Now theyre printed with relative paths, and
relative paths are accepted when writing new rules.
Minor things
- added warn if >1 function, filename, module filter is used. also
fix a pr_err() conditional on verbose.
- '_' (empty) flag added. $CONTROL now says '=_' for disabled
callsites, so your grep command can be more selective than '='
- printing is enabled by p flag only, formerly any flag enabled
callsite. this fix is needed for filter-flags as described above.
- dynamic debug supercedes DEBUG - Formerly ddebug couldnt control
callsites when module had DEBUG 1, now it can. DEBUG 1 now enables
callsites by default, but you can turn them off.
- shrink _ddebug.lineno:24 to 18
lineno:24 allows 16G-lines files to be 'pr_debug'd, which is silly.
Largest in tree is 29k-lines, future additions that large are
*unlikely*. Even allowing for out-of-tree machine-generated code
(which shouldnt need ddebug, right? ;-), 256k-lines should be
enough.
- pr_fmt_dbg() - like pr_fmt(), but used in dynamic_pr_debug().
Allows independent control of the prefix-text added by pr_debug vs
pr_info and others. TBD - Joe Perches had issues with this, maybe
addressed here. Its also at end of set, so can be trivially
excluded from upstream.
- internal ddebug verbosity - this modparam enables several levels of
internal debugging. Previous patchsets used the ddebug facilities
within ddebug (eat your own dogfood) but that was deemed too
aggressive.
Future additions.
- user flags: If we can free up extra bits (32bit is currently tight),
adding user-flags (say: x,y,z) would let users mark groups of
callsites, then enable and disable them in a single operation:
echo module foo +x > $CONTROL
echo module bar +x > $CONTROL
...
echo x+p > $CONTROL
Breakdown:
1-15 prep, cleanups, minor things
16-23 major enhancements, doc
24-26 non-essentials, worth considering, discussing.
If you like, you can also get it from github,
git://github.com/jimc/linux-2.6.git dyndbg/on-driver-core
This is a clone of GregKH's driver-core tree, circa -rc3,
which includes 8/12 of Jason Barons dynamic-debug patches.
Ive added Jason's last 4/12, and my 26 patches.
thanks
Jim Cromie
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2011-09-20 15:24 Ken D'Ambrosio
2011-09-20 15:35 ` your mail Hugo Mills
0 siblings, 1 reply; 669+ messages in thread
From: Ken D'Ambrosio @ 2011-09-20 15:24 UTC (permalink / raw)
To: linux-btrfs
Just wondering if/how one goes about getting the btrfs checksum of a given
file. Is there a way?
Thanks!
-Ken
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-09-20 15:24 (unknown) Ken D'Ambrosio
@ 2011-09-20 15:35 ` Hugo Mills
2011-09-20 15:40 ` Hugo Mills
0 siblings, 1 reply; 669+ messages in thread
From: Hugo Mills @ 2011-09-20 15:35 UTC (permalink / raw)
To: File's, checksum?; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
> Just wondering if/how one goes about getting the btrfs checksum of a given
> file. Is there a way?
Checksums are computed on individual 4k blocks, not on the whole
file. There's no explicit interface for retrieving checksums, but if
you understand the data structures, you can get hold of the checksums
for a file using the BTRFS_IOC_TREE_SEARCH ioctl.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- "How deep will this sub go?" "Oh, she'll go all the way to ---
the bottom if we don't stop her."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-09-20 15:35 ` your mail Hugo Mills
@ 2011-09-20 15:40 ` Hugo Mills
0 siblings, 0 replies; 669+ messages in thread
From: Hugo Mills @ 2011-09-20 15:40 UTC (permalink / raw)
To: linux-btrfs, Ken D'Ambrosio
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
[Your Reply-to: header was screwed up, so I'm sending this again.
From: Ken D'Ambrosio <ken@jots.org>
Reply-to: File's@jots.org, checksum?@jots.org
]
On Tue, Sep 20, 2011 at 04:35:40PM +0100, Hugo Mills wrote:
> On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
> > Just wondering if/how one goes about getting the btrfs checksum of a given
> > file. Is there a way?
>
> Checksums are computed on individual 4k blocks, not on the whole
> file. There's no explicit interface for retrieving checksums, but if
> you understand the data structures, you can get hold of the checksums
> for a file using the BTRFS_IOC_TREE_SEARCH ioctl.
>
> Hugo.
>
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- "How deep will this sub go?" "Oh, she'll go all the way to ---
the bottom if we don't stop her."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2011-08-28 14:11 Jan Engelhardt
2011-08-31 11:56 ` your mail Jozsef Kadlecsik
0 siblings, 1 reply; 669+ messages in thread
From: Jan Engelhardt @ 2011-08-28 14:11 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter Developer Mailing List
libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
a #ifdef __KERNEL__ section lately and is thus absent from userspace.
(In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-08-28 14:11 (unknown) Jan Engelhardt
@ 2011-08-31 11:56 ` Jozsef Kadlecsik
2011-08-31 12:10 ` Jan Engelhardt
0 siblings, 1 reply; 669+ messages in thread
From: Jozsef Kadlecsik @ 2011-08-31 11:56 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
Hi Jan,
On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
After rewieving your patches, I don't get it: what userspace tool would
use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
definitely not use it and ipset either. So why your patches are
required?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-08-31 11:56 ` your mail Jozsef Kadlecsik
@ 2011-08-31 12:10 ` Jan Engelhardt
2011-08-31 12:16 ` Jozsef Kadlecsik
0 siblings, 1 reply; 669+ messages in thread
From: Jan Engelhardt @ 2011-08-31 12:10 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter Developer Mailing List
On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>Hi Jan,
>
>On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>
>> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
>> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
>> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>
>After rewieving your patches, I don't get it: what userspace tool would
>use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
>definitely not use it and ipset either. So why your patches are
>required?
iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which
#includes ip_set.h to get at the definition of ip_set.h.
Patch will be resent.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-08-31 12:10 ` Jan Engelhardt
@ 2011-08-31 12:16 ` Jozsef Kadlecsik
2011-08-31 12:44 ` Jan Engelhardt
0 siblings, 1 reply; 669+ messages in thread
From: Jozsef Kadlecsik @ 2011-08-31 12:16 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>
> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >
> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >
> >After rewieving your patches, I don't get it: what userspace tool would
> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
> >definitely not use it and ipset either. So why your patches are
> >required?
>
> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which
> #includes ip_set.h to get at the definition of ip_set.h.
> Patch will be resent.
iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and
xt_set.h includes nothing.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-08-31 12:16 ` Jozsef Kadlecsik
@ 2011-08-31 12:44 ` Jan Engelhardt
2011-08-31 12:49 ` Jozsef Kadlecsik
0 siblings, 1 reply; 669+ messages in thread
From: Jan Engelhardt @ 2011-08-31 12:44 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter Developer Mailing List
On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
>On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>
>> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>>
>> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>> >
>> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
>> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
>> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>> >
>> >After rewieving your patches, I don't get it: what userspace tool would
>> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
>> >definitely not use it and ipset either. So why your patches are
>> >required?
>>
>> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which
>> #includes ip_set.h to get at the definition of ip_set.h.
>> Patch will be resent.
>
>iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and
>xt_set.h includes nothing.
14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
#include <linux/types.h>
#include <linux/netfilter/ipset/ip_set.h>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-08-31 12:44 ` Jan Engelhardt
@ 2011-08-31 12:49 ` Jozsef Kadlecsik
2011-08-31 13:04 ` Jan Engelhardt
0 siblings, 1 reply; 669+ messages in thread
From: Jozsef Kadlecsik @ 2011-08-31 12:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
>
> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >
> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> >>
> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >> >
> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >> >
> >> >After rewieving your patches, I don't get it: what userspace tool would
> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
> >> >definitely not use it and ipset either. So why your patches are
> >> >required?
> >>
> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which
> >> #includes ip_set.h to get at the definition of ip_set.h.
> >> Patch will be resent.
> >
> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and
> >xt_set.h includes nothing.
>
> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
> #include <linux/types.h>
> #include <linux/netfilter/ipset/ip_set.h>
This is the kernel source tree. You wrote about libxt_SET.c and userspace:
kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
kadlec@mentat:/usr/src/git/iptables$
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-08-31 12:49 ` Jozsef Kadlecsik
@ 2011-08-31 13:04 ` Jan Engelhardt
2011-08-31 13:24 ` Jozsef Kadlecsik
0 siblings, 1 reply; 669+ messages in thread
From: Jan Engelhardt @ 2011-08-31 13:04 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter Developer Mailing List
On Wednesday 2011-08-31 14:49, Jozsef Kadlecsik wrote:
>On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>
>> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
>>
>> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>> >
>> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>> >>
>> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>> >> >
>> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
>> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
>> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>> >> >
>> >> >After rewieving your patches, I don't get it: what userspace tool would
>> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
>> >> >definitely not use it and ipset either. So why your patches are
>> >> >required?
>> >>
>> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which
>> >> #includes ip_set.h to get at the definition of ip_set.h.
>> >> Patch will be resent.
>> >
>> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and
>> >xt_set.h includes nothing.
>>
>> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
>> #include <linux/types.h>
>> #include <linux/netfilter/ipset/ip_set.h>
>
>This is the kernel source tree. You wrote about libxt_SET.c and userspace:
>
>kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
>kadlec@mentat:/usr/src/git/iptables$
Of course the header files in the iptables source tree come from the
(sanitized) kernel headers, and time and again, new copies from the
kernel are brought into the iptables tree.
(Cf. commits b4af04be14560b3fcc6cf23200148d408014a2f5,
350661a6eb089f3e54e67e022db9e16ea280499f,
978e27e8f8c2e49d0528c6c4ae3a56627fbe8492,
e0bba47e550420e371c97425cc6d39909a6e059b, and possibly more in the
past.)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-08-31 13:04 ` Jan Engelhardt
@ 2011-08-31 13:24 ` Jozsef Kadlecsik
0 siblings, 0 replies; 669+ messages in thread
From: Jozsef Kadlecsik @ 2011-08-31 13:24 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> On Wednesday 2011-08-31 14:49, Jozsef Kadlecsik wrote:
>
> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >
> >> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
> >>
> >> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >> >
> >> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> >> >>
> >> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >> >> >
> >> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into
> >> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace.
> >> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >> >> >
> >> >> >After rewieving your patches, I don't get it: what userspace tool would
> >> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does
> >> >> >definitely not use it and ipset either. So why your patches are
> >> >> >required?
> >> >>
> >> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which
> >> >> #includes ip_set.h to get at the definition of ip_set.h.
> >> >> Patch will be resent.
> >> >
> >> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and
> >> >xt_set.h includes nothing.
> >>
> >> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
> >> #include <linux/types.h>
> >> #include <linux/netfilter/ipset/ip_set.h>
> >
> >This is the kernel source tree. You wrote about libxt_SET.c and userspace:
> >
> >kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
> >kadlec@mentat:/usr/src/git/iptables$
>
> Of course the header files in the iptables source tree come from the
> (sanitized) kernel headers, and time and again, new copies from the
> kernel are brought into the iptables tree.
>
> (Cf. commits b4af04be14560b3fcc6cf23200148d408014a2f5,
> 350661a6eb089f3e54e67e022db9e16ea280499f,
> 978e27e8f8c2e49d0528c6c4ae3a56627fbe8492,
> e0bba47e550420e371c97425cc6d39909a6e059b, and possibly more in the
> past.)
Then I'm going to apply your patches. After that some more work is
required from me, because ipset userspace assumes those parts to be
excluded by #ifdef __KERNEL__.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH] module: Use binary search in lookup_symbol()
@ 2011-05-17 23:33 Tim Bird
2011-05-18 18:55 ` Alessio Igor Bogani
0 siblings, 1 reply; 669+ messages in thread
From: Tim Bird @ 2011-05-17 23:33 UTC (permalink / raw)
To: Greg KH
Cc: Alessio Igor Bogani, Rusty Russell, Anders Kaseorg, Tim Abbott,
LKML, Linux Embedded, Jason Wessel, Dirk Behme
On 05/17/2011 04:22 PM, Greg KH wrote:
> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
>> This work was supported by a hardware donation from the CE Linux Forum.
>>
>> Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
>> ---
>
> That's nice, but _why_ do this change? What does it buy us?
>
> Please explain why you make a change, not just who sponsored the change,
> that's not very interesting to developers.
Just a note here on the attribution...
Alessio - you can remove the "hardware donation from CELF" line
after the first submission or so. It doesn't need to be on
every submission of the patch set, and it doesn't need to go into
the commit message for the patch set. We only want it associated
with the patch set somewhere Google-able (like LKML).
That said, I can answer Greg's question. This is to speed up
the symbol resolution on module loading. The last numbers I
saw showed a reduction of about 15-20% for the module load
time, for large-ish modules. Of course this is highly dependent
on the size of the modules, what they do at load time, and how many
symbols are looked up to link them into the kernel.
Alessio - do you have any timings you can share for the speedup?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
2011-05-17 23:33 [PATCH] module: Use binary search in lookup_symbol() Tim Bird
@ 2011-05-18 18:55 ` Alessio Igor Bogani
2011-05-18 19:22 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: Alessio Igor Bogani @ 2011-05-18 18:55 UTC (permalink / raw)
To: Greg KH, Rusty Russell, Tim Bird, Christoph Hellwig
Cc: Anders Kaseorg, Tim Abbott, LKML, Linux Embedded, Jason Wessel,
Dirk Behme, Alessio Igor Bogani
Dear Mr. Bird, Dear Mr. Kroah-Hartman,
Sorry for my very bad English.
2011/5/18 Tim Bird <tim.bird@am.sony.com>:
[...]
> Alessio - do you have any timings you can share for the speedup?
You can find a little benchmark using ftrace at end of this email:
https://lkml.org/lkml/2011/4/5/341
> On 05/17/2011 04:22 PM, Greg KH wrote:
>> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
>>> This work was supported by a hardware donation from the CE Linux Forum.
[...]
>> Please explain why you make a change, not just who sponsored the change,
>> that's not very interesting to developers.
You are right. I apologize.
This patch is a missing piece (not essential it is only a further little
optimization) of this little patchset:
https://lkml.org/lkml/2011/4/16/48
Unfortunately I forgot to include this patch in the series (my first error)
then I avoided explaining the changes because I had thought that those were
already enough explained in the cover-letter of the patchset (my second error).
Sorry for my mistakes.
Is this better?
Subject: [PATCH] module: Use binary search in lookup_symbol()
The function is_exported() with its helper function lookup_symbol() are used to
verify if a provided symbol is effectively exported by the kernel or by the
modules. Now that both have their symbols sorted we can replace a linear search
with a binary search which provide a considerably speed-up.
This work was supported by a hardware donation from the CE Linux Forum.
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
---
kernel/module.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 1e2b657..795bdc7 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2055,11 +2055,8 @@ static const struct kernel_symbol *lookup_symbol(const char *name,
const struct kernel_symbol *start,
const struct kernel_symbol *stop)
{
- const struct kernel_symbol *ks = start;
- for (; ks < stop; ks++)
- if (strcmp(ks->name, name) == 0)
- return ks;
- return NULL;
+ return bsearch(name, start, stop - start,
+ sizeof(struct kernel_symbol), cmp_name);
}
static int is_exported(const char *name, unsigned long value,
--
Thank you very much!
Ciao,
Alessio
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2011-05-18 18:55 ` Alessio Igor Bogani
@ 2011-05-18 19:22 ` Greg KH
2011-05-18 20:35 ` Alessio Igor Bogani
0 siblings, 1 reply; 669+ messages in thread
From: Greg KH @ 2011-05-18 19:22 UTC (permalink / raw)
To: Alessio Igor Bogani
Cc: Rusty Russell, Tim Bird, Christoph Hellwig, Anders Kaseorg,
Tim Abbott, LKML, Linux Embedded, Jason Wessel, Dirk Behme
On Wed, May 18, 2011 at 08:55:25PM +0200, Alessio Igor Bogani wrote:
> Dear Mr. Bird, Dear Mr. Kroah-Hartman,
>
> Sorry for my very bad English.
>
> 2011/5/18 Tim Bird <tim.bird@am.sony.com>:
> [...]
> > Alessio - do you have any timings you can share for the speedup?
>
> You can find a little benchmark using ftrace at end of this email:
> https://lkml.org/lkml/2011/4/5/341
>
> > On 05/17/2011 04:22 PM, Greg KH wrote:
> >> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
> >>> This work was supported by a hardware donation from the CE Linux Forum.
> [...]
> >> Please explain why you make a change, not just who sponsored the change,
> >> that's not very interesting to developers.
>
> You are right. I apologize.
>
> This patch is a missing piece (not essential it is only a further little
> optimization) of this little patchset:
> https://lkml.org/lkml/2011/4/16/48
>
> Unfortunately I forgot to include this patch in the series (my first error)
> then I avoided explaining the changes because I had thought that those were
> already enough explained in the cover-letter of the patchset (my second error).
>
> Sorry for my mistakes.
>
> Is this better?
>
> Subject: [PATCH] module: Use binary search in lookup_symbol()
>
> The function is_exported() with its helper function lookup_symbol() are used to
> verify if a provided symbol is effectively exported by the kernel or by the
> modules. Now that both have their symbols sorted we can replace a linear search
> with a binary search which provide a considerably speed-up.
>
> This work was supported by a hardware donation from the CE Linux Forum.
>
> Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Much better, I have no objection to this at all.
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Care to resend it without all the stuff above so someone (Rusty I guess)
can apply it?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-18 19:22 ` your mail Greg KH
@ 2011-05-18 20:35 ` Alessio Igor Bogani
0 siblings, 0 replies; 669+ messages in thread
From: Alessio Igor Bogani @ 2011-05-18 20:35 UTC (permalink / raw)
To: Greg KH
Cc: Rusty Russell, Tim Bird, Christoph Hellwig, Anders Kaseorg,
Tim Abbott, LKML, Linux Embedded, Jason Wessel, Dirk Behme
Dear Mr. Kroah-Hartman,
2011/5/18 Greg KH <greg@kroah.com>:
[...]
> Care to resend it without all the stuff above so someone (Rusty I guess)
> can apply it?
Sure! It'll follow in few minutes.
Thank you very much!
Ciao,
Alessio
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2011-05-16 9:34 Keshava Munegowda
2011-05-16 9:44 ` your mail Felipe Balbi
0 siblings, 1 reply; 669+ messages in thread
From: Keshava Munegowda @ 2011-05-16 9:34 UTC (permalink / raw)
To: linux-usb, linux-omap, linux-kernel
Cc: Keshava Munegowda, balbi, gadiyar, sameo, parthab
Following 2 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and
EHCI , OHCI irq and base addresses.
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 153 +++++++++++++++++++++++
2 files changed, 337 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 909a84d..fe9a176 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3574,6 +3576,185 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = &omap34xx_usb_host_hs_hwmod,
+ .slave = &omap3xxx_l3_main_hwmod,
+ .clk = "core_l3_ick",
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = "usbhs_uhh",
+ .sysc = &omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ &omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = "ohci-irq", .irq = 76 },
+ { .name = "ehci-irq", .irq = 77 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = "uhh",
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = "ohci",
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647FF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {
+ .name = "ehci",
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064CFF,
+ .flags = ADDR_MAP_ON_INIT
+ }
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_usb_host_hs_hwmod,
+ .clk = "l4_ick",
+ .addr = omap34xx_usb_host_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = "usbhost_120m_fck",
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk = "usbhost_48m_fck",
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ &omap34xx_l4_cfg__usb_host_hs,
+ &omap34xx_f128m_cfg__usb_host_hs,
+ &omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = "usbhs_uhh",
+ .class = &omap34xx_usb_host_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_irqs),
+ .main_clk = "usbhost_ick",
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters = omap34xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap34xx_usb_tll_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_tll_hs_hwmod_class = {
+ .name = "usbhs_tll",
+ .sysc = &omap34xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_tll_hs_irqs[] = {
+ { .name = "tll-irq", .irq = 78 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_tll_hs_addrs[] = {
+ {
+ .name = "tll",
+ .pa_start = 0x48062000,
+ .pa_end = 0x48062fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f_cfg__usb_tll_hs = {
+ .clk = "usbtll_fck",
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_tll_hs = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_usb_tll_hs_hwmod,
+ .clk = "l4_ick",
+ .addr = omap34xx_usb_tll_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap34xx_usb_tll_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_tll_hs_slaves[] = {
+ &omap34xx_l4_cfg__usb_tll_hs,
+ &omap34xx_f_cfg__usb_tll_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod = {
+ .name = "usbhs_tll",
+ .class = &omap34xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_tll_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_usb_tll_hs_irqs),
+ .main_clk = "usbtll_ick",
+ .prcm = {
+ .omap2 = {
+ .module_offs = CORE_MOD,
+ .prcm_reg_id = 3,
+ .module_bit = 2,
+ .idlest_reg_id = 3,
+ .idlest_idle_bit = 2,
+ },
+ },
+ .slaves = omap34xx_usb_tll_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_tll_hs_slaves),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_main_hwmod,
&omap3xxx_l4_core_hwmod,
@@ -3656,6 +3837,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
/* usbotg for am35x */
&am35xx_usbhsotg_hwmod,
+ &omap34xx_usb_host_hs_hwmod,
+ &omap34xx_usb_tll_hs_hwmod,
+
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index abc548a..d7112b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -66,6 +66,8 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5027,6 +5029,155 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = &omap44xx_usb_host_hs_hwmod,
+ .slave = &omap44xx_l3_main_2_hwmod,
+ .clk = "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = "usbhs_uhh",
+ .sysc = &omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ &omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+ { .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .name = "ehci-irq", .irq = 77 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = "uhh",
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = "ohci",
+ .pa_start = 0x4A064800,
+ .pa_end = 0x4A064BFF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {
+ .name = "ehci",
+ .pa_start = 0x4A064C00,
+ .pa_end = 0x4A064FFF,
+ .flags = ADDR_MAP_ON_INIT
+ }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_usb_host_hs_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_usb_host_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ &omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = "usbhs_uhh",
+ .class = &omap44xx_usb_host_hs_hwmod_class,
+ .mpu_irqs = omap44xx_usb_host_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_irqs),
+ .main_clk = "usb_host_hs_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters = omap44xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_usb_tll_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_tll_hs_hwmod_class = {
+ .name = "usbhs_tll",
+ .sysc = &omap44xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_tll_hs_irqs[] = {
+ { .name = "tll-irq", .irq = 78 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_tll_hs_addrs[] = {
+ {
+ .name = "tll",
+ .pa_start = 0x4a062000,
+ .pa_end = 0x4a063fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_usb_tll_hs_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_usb_tll_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_tll_hs_slaves[] = {
+ &omap44xx_l4_cfg__usb_tll_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
+ .name = "usbhs_tll",
+ .class = &omap44xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap44xx_usb_tll_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_irqs),
+ .main_clk = "usb_tll_hs_ick",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_tll_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5173,6 +5324,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ &omap44xx_usb_host_hs_hwmod,
+ &omap44xx_usb_tll_hs_hwmod,
NULL,
};
--
1.6.0.4
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2011-05-16 9:34 Keshava Munegowda
@ 2011-05-16 9:44 ` Felipe Balbi
2011-05-16 10:07 ` Munegowda, Keshava
0 siblings, 1 reply; 669+ messages in thread
From: Felipe Balbi @ 2011-05-16 9:44 UTC (permalink / raw)
To: Keshava Munegowda
Cc: linux-usb, linux-omap, linux-kernel, balbi, gadiyar, sameo, parthab
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hi,
On Mon, May 16, 2011 at 03:04:20PM +0530, Keshava Munegowda wrote:
> Following 2 hwmod strcuture are added:
> UHH hwmod of usbhs with uhh base address and
> EHCI , OHCI irq and base addresses.
> TLL hwmod of usbhs with the TLL base address and irq.
>
> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
missing subject line.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-16 9:44 ` your mail Felipe Balbi
@ 2011-05-16 10:07 ` Munegowda, Keshava
0 siblings, 0 replies; 669+ messages in thread
From: Munegowda, Keshava @ 2011-05-16 10:07 UTC (permalink / raw)
To: balbi; +Cc: linux-usb, linux-omap, linux-kernel, gadiyar, sameo, parthab
On Mon, May 16, 2011 at 3:14 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, May 16, 2011 at 03:04:20PM +0530, Keshava Munegowda wrote:
>> Following 2 hwmod strcuture are added:
>> UHH hwmod of usbhs with uhh base address and
>> EHCI , OHCI irq and base addresses.
>> TLL hwmod of usbhs with the TLL base address and irq.
>>
>> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
>
> missing subject line.
Ya, I have already correct it and resend this patch [RESEND] [PATCH 1/5]...
Regards
keshava
^ permalink raw reply [flat|nested] 669+ messages in thread
* No subject
@ 2011-05-13 19:35 Vadim Bendebury
2011-05-14 3:32 ` your mail Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 669+ messages in thread
From: Vadim Bendebury @ 2011-05-13 19:35 UTC (permalink / raw)
To: linux-arm-kernel
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2011-05-13 19:35 No subject Vadim Bendebury
@ 2011-05-14 3:32 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 669+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
On 12:35 Fri 13 May , Vadim Bendebury wrote:
> >From 8ed0ea5fcf5552ca3307611b685b4518794eca41 Mon Sep 17 00:00:00 2001
> From: Vadim Bendebury <vbendeb@chromium.org>
> Date: Wed, 11 May 2011 17:31:40 -0700
> Subject: [PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.
>
> This is a cosmetic change, adding a '_thumb' prefix to the
> 'Hardware' line in /proc/cpuinfo. Tested as follows:
I do think is the right place or right way to do so
I think we need to create a sysfs entry to allow machine to more information
Best Regards,
J.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due to a deadlock
@ 2011-05-03 11:01 Surbhi Palande
2011-05-03 13:08 ` (unknown), Surbhi Palande
0 siblings, 1 reply; 669+ messages in thread
From: Surbhi Palande @ 2011-05-03 11:01 UTC (permalink / raw)
To: Toshiyuki Okajima
Cc: Jan Kara, Ted Ts'o, Masayoshi MIZUMA, Andreas Dilger,
linux-ext4, linux-fsdevel, sandeen
On 04/18/2011 12:05 PM, Toshiyuki Okajima wrote:
> Hi,
>
> (2011/04/16 2:13), Jan Kara wrote:
>> Hello,
>>
>> On Fri 15-04-11 22:39:07, Toshiyuki Okajima wrote:
>>>> For ext3 or ext4 without delayed allocation we block inside writepage()
>>>> function. But as I wrote to Dave Chinner, ->page_mkwrite() should
>>>> probably
>>>> get modified to block while minor-faulting the page on frozen fs
>>>> because
>>>> when blocks are already allocated we may skip starting a transaction
>>>> and so
>>>> we could possibly modify the filesystem.
>>> OK. I think ->page_mkwrite() should also block writing the
>>> minor-faulting pages.
>>>
>>> (minor-pagefault)
>>> -> do_wp_page()
>>> -> page_mkwrite(= ext4_mkwrite())
>>> => BLOCK!
>>>
>>> (major-pagefault)
>>> -> do_liner_fault()
>>> -> page_mkwrite(= ext4_mkwrite())
>>> => BLOCK!
>>>
>>>>
>>>>>>> Mizuma-san's reproducer also writes the data which maps to the
>>>>>>> file (mmap).
>>>>>>> The original problem happens after the fsfreeze operation is done.
>>>>>>> I understand the normal write operation (not mmap) can be blocked
>>>>>>> while
>>>>>>> fsfreezing. So, I guess we don't always block all the write
>>>>>>> operation
>>>>>>> while fsfreezing.
>>>>>> Technically speaking, we block all the transaction starts which
>>>>>> means we
>>>>>> end up blocking all the writes from going to disk. But that does
>>>>>> not mean
>>>>>> we block all the writes from going to in-memory cache - as you
>>>>>> properly
>>>>>> note the mmap case is one of such exceptions.
>>>>> Hm, I also think we can allow the writes to in-memory cache but we
>>>>> can't allow
>>>>> the writes to disk while fsfreezing. I am considering that mmap
>>>>> path can
>>>>> write to disk while fsfreezing because this deadlock problem
>>>>> happens after
>>>>> fsfreeze operation is done...
>>>> I'm sorry I don't understand now - are you speaking about the case
>>>> above
>>>> when writepage() does not wait for filesystem being frozen or something
>>>> else?
>>> Sorry, I didn't understand around the page fault path.
>>> So, I had read the kernel source code around it, then I maybe
>>> understand...
>>>
>>> I worry whether we can update the file data in mmap case while
>>> fsfreezing.
>>> Of course, I understand that we can write to in-memory cache, and it
>>> is not a
>>> problem. However, if we can write to disk while fsfreezing, it is a
>>> problem.
>>> So, I summarize the cases whether we can write to disk or not.
>>>
>>> --------------------------------------------------------------------------
>>>
>>> Cases (Whether we can write the data mmapped to the file on the disk
>>> while fsfreezing)
>>>
>>> [1] One of the page which has been mmapped is not bound. And
>>> the page is not allocated yet. (major fault?)
>>>
>>> (1) user dirtys a page
>>> (2) a page fault occurs (do_page_fault)
>>> (3) __do_falut is called.
>>> (4) ext4_page_mkwrite is called
>>> (5) ext4_write_begin is called
>>> (6) ext4_journal_start_sb => We can STOP!
>>>
>>> [2] One of the page which has been mmapped is not bound. But
>>> the page is already allocated, and the buffer_heads of the page
>>> are not mapped (BH_Mapped). (minor fault?)
>>>
>>> (1) user dirtys a page
>>> (2) a page fault occurs (do_page_fault)
>>> (3) do_wp_page is called.
>>> (4) ext4_page_mkwrite is called
>>> (5) ext4_write_begin is called
>>> (6) ext4_journal_start_sb => We can STOP!
What happens in the case as follows:
Task 1: Mmapped writes
t1)ext4_page_mkwrite()
t2) ext4_write_begin() (FS is thawed so we proceed)
t3) ext4_write_end() (journal is stopped now)
-----Pre-empted-----
Task 2: Freeze Task
t4) freezes the super block...
...(continues)....
tn) the page cache is clean and the F.S is frozen. Freeze has completed
execution.
Task 1: Mmapped writes
tn+1) ext4_page_mkwrite() returns 0.
tn+2) __do_fault() gets control, code gets executed.
tn+3) _do_fault() marks the page dirty if the intent is to write to a
file based page which faulted.
So you end up dirtying the page cache when the F.S is frozen? No?
Warm Regards,
Surbhi.
>>>
>>> [3] One of the page which has been mmapped is not bound. But
>>> the page is already allocated, and the buffer_heads of the page
>>> are mapped (BH_Mapped). (minor fault?)
>>>
>>> (1) user dirtys a page
>>> (2) a page fault occurs (do_page_fault)
>>> (3) do_wp_page is called.
>>> (4) ext4_page_mkwrite is called
>>> * Cannot block the dirty page to be written because all bh is mapped.
>>> (5) user munmaps the page (munmap)
>>> (6) zap_pte_range dirtys the page (struct page) which is pte_dirtyed.
>>> (7) writeback thread writes the page (struct page) to disk
>>> => We cannot STOP!
>>>
>>> [4] One of the page which has been mmapped is bound. And
>>> the page is already allocated.
>>>
>>> (1) user dirtys a page
>>> ( ) no page fault occurs
>>> (2) user munmaps the page (munmap)
>>> (3) zap_pte_range dirtys the page (struct page) which is pte_dirtyed.
>>> (4) writeback thread writes the page (struct page) to disk
>>> => We cannot STOP!
>>> --------------------------------------------------------------------------
>>>
>>>
>>> So, we can block the cases [1], [2].
>>> But I think we cannot block the cases [3], [4] now.
>>> If fixing the page_mkwrite, we can also block the case [3].
>>> But the case [4] is not blocked because no page fault occurs
>>> when we dirty the mmapped page.
>>>
>>> Therefore, to repair this problem, we need to fix the cases [3], [4].
>>> I think we must modify the writeback thread to fix the case [4].
>> The trick here is that when we write a page to disk, we write-protect
>> the page (you seem to call this that "the page is bound", I'm not sure
>> why).
> Hm, I want to understand how to write-protect the page under fsfreezing.
> But, anyway, I understand we don't need to consider the case [4].
>
>> So we are guaranteed to receive a minor fault (case [3]) if user tries to
>> modify a page after we finish writeback while freezing the filesystem.
>> So principially all we need to do is just wait in ext4_page_mkwrite().
> OK. I understand.
> Are there any concrete ideas to fix this?
> For ext4, we can rescue from the case [3] by modifying ext4_page_mkwrite().
> But for ext3 or other FSs, we must implement ->page_mkwrite() to prevent
> it?
>
> Thanks,
> Toshiyuki Okajima
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
2011-05-03 11:01 [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due to a deadlock Surbhi Palande
@ 2011-05-03 13:08 ` Surbhi Palande
2011-05-03 13:46 ` your mail Jan Kara
0 siblings, 1 reply; 669+ messages in thread
From: Surbhi Palande @ 2011-05-03 13:08 UTC (permalink / raw)
To: jack
Cc: toshi.okajima, tytso, m.mizuma, adilger.kernel, linux-ext4,
linux-fsdevel, sandeen
On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
Toshiyuki pointed out.
zap_pte_range()
mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
So, I think that it is here that we should do the checking for a ext4 F.S
frozen state and also prevent a parallel ext4 F.S freeze from happening.
Attaching a patch for initial review. Please do let me know your thoughts!
Thanks a lot!
Warm Regards,
Surbhi.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-03 13:08 ` (unknown), Surbhi Palande
@ 2011-05-03 13:46 ` Jan Kara
2011-05-03 13:56 ` Surbhi Palande
0 siblings, 1 reply; 669+ messages in thread
From: Jan Kara @ 2011-05-03 13:46 UTC (permalink / raw)
To: Surbhi Palande
Cc: jack, toshi.okajima, tytso, m.mizuma, adilger.kernel, linux-ext4,
linux-fsdevel, sandeen
On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> Toshiyuki pointed out.
>
> zap_pte_range()
> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>
> So, I think that it is here that we should do the checking for a ext4 F.S
> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>
> Attaching a patch for initial review. Please do let me know your thoughts!
This is definitely the wrong place. ->set_page_dirty() callbacks are
called with various locks held and the page need not be locked (thus
dereferencing page->mapping is oopsable). Moreover this particular callback
is called only in data=journal mode.
Believe me, the right place is page_mkwrite() - you have to catch the
read-only => read-write page transition. Once the page is mapped
read-write, you've already lost the race.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-03 13:46 ` your mail Jan Kara
@ 2011-05-03 13:56 ` Surbhi Palande
2011-05-03 15:26 ` Surbhi Palande
2011-05-03 15:36 ` Jan Kara
0 siblings, 2 replies; 669+ messages in thread
From: Surbhi Palande @ 2011-05-03 13:56 UTC (permalink / raw)
To: Jan Kara
Cc: toshi.okajima, tytso, m.mizuma, adilger.kernel, linux-ext4,
linux-fsdevel, sandeen
On 05/03/2011 04:46 PM, Jan Kara wrote:
> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
Sorry for missing the subject line :(
>> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
>> Toshiyuki pointed out.
>>
>> zap_pte_range()
>> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>
>> So, I think that it is here that we should do the checking for a ext4 F.S
>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>
>> Attaching a patch for initial review. Please do let me know your thoughts!
> This is definitely the wrong place. ->set_page_dirty() callbacks are
> called with various locks held and the page need not be locked (thus
> dereferencing page->mapping is oopsable). Moreover this particular callback
> is called only in data=journal mode.
Ok! Thanks for that!
>
> Believe me, the right place is page_mkwrite() - you have to catch the
> read-only => read-write page transition. Once the page is mapped
> read-write, you've already lost the race.
My only point is:
1) something should prevent the freeze from happening. We cant merely
check the vfs_check_frozen()?
And this should be done where the page is marked dirty.Also, I thought
that the page is marked read-write only in the page table in the
__do_page_fault()? i.e the zap_pte_range() marks them dirty in the page
cache? Is this understanding right?
IMHO, whatever code dirties the page in the page cache should call a F.S
specific function and let it _prevent_ a fsfreeze while the page is
getting dirtied, so that a freeze called after this point flushes this page!
Warm Regards,
Surbhi.
>
> Honza
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-03 13:56 ` Surbhi Palande
@ 2011-05-03 15:26 ` Surbhi Palande
2011-05-03 15:36 ` Jan Kara
1 sibling, 0 replies; 669+ messages in thread
From: Surbhi Palande @ 2011-05-03 15:26 UTC (permalink / raw)
To: surbhi.palande
Cc: Jan Kara, toshi.okajima, tytso, m.mizuma, adilger.kernel,
linux-ext4, linux-fsdevel, sandeen
On 05/03/2011 04:56 PM, Surbhi Palande wrote:
> On 05/03/2011 04:46 PM, Jan Kara wrote:
>> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>
> Sorry for missing the subject line :(
>>> On munmap() zap_pte_range() is called which dirties the PTE dirty
>>> pages as
>>> Toshiyuki pointed out.
>>>
>>> zap_pte_range()
>>> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>>
>>> So, I think that it is here that we should do the checking for a ext4
>>> F.S
>>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>>
>>> Attaching a patch for initial review. Please do let me know your
>>> thoughts!
>> This is definitely the wrong place. ->set_page_dirty() callbacks are
>> called with various locks held and the page need not be locked (thus
>> dereferencing page->mapping is oopsable). Moreover this particular
>> callback
>> is called only in data=journal mode.
> Ok! Thanks for that!
>
>>
>> Believe me, the right place is page_mkwrite() - you have to catch the
>> read-only => read-write page transition. Once the page is mapped
>> read-write, you've already lost the race.
Also, we then need to prevent a munmap()/zap_pte_range() call from
dirtying a mmapped file page when the F.S is frozen?
Warm Regards,
Surbhi.
>
> My only point is:
> 1) something should prevent the freeze from happening. We cant merely
> check the vfs_check_frozen()?
>
> And this should be done where the page is marked dirty.Also, I thought
> that the page is marked read-write only in the page table in the
> __do_page_fault()? i.e the zap_pte_range() marks them dirty in the page
> cache? Is this understanding right?
>
> IMHO, whatever code dirties the page in the page cache should call a F.S
> specific function and let it _prevent_ a fsfreeze while the page is
> getting dirtied, so that a freeze called after this point flushes this
> page!
>
> Warm Regards,
> Surbhi.
>
>
>
>
>
>
>
>
>
>
>>
>> Honza
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-03 13:56 ` Surbhi Palande
2011-05-03 15:26 ` Surbhi Palande
@ 2011-05-03 15:36 ` Jan Kara
2011-05-03 15:43 ` Surbhi Palande
1 sibling, 1 reply; 669+ messages in thread
From: Jan Kara @ 2011-05-03 15:36 UTC (permalink / raw)
To: Surbhi Palande
Cc: Jan Kara, toshi.okajima, tytso, m.mizuma, adilger.kernel,
linux-ext4, linux-fsdevel, sandeen
On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
> On 05/03/2011 04:46 PM, Jan Kara wrote:
> >On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>
> Sorry for missing the subject line :(
> >>On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> >>Toshiyuki pointed out.
> >>
> >>zap_pte_range()
> >> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
> >>
> >>So, I think that it is here that we should do the checking for a ext4 F.S
> >>frozen state and also prevent a parallel ext4 F.S freeze from happening.
> >>
> >>Attaching a patch for initial review. Please do let me know your thoughts!
> > This is definitely the wrong place. ->set_page_dirty() callbacks are
> >called with various locks held and the page need not be locked (thus
> >dereferencing page->mapping is oopsable). Moreover this particular callback
> >is called only in data=journal mode.
> Ok! Thanks for that!
>
> >
> >Believe me, the right place is page_mkwrite() - you have to catch the
> >read-only => read-write page transition. Once the page is mapped
> >read-write, you've already lost the race.
>
> My only point is:
> 1) something should prevent the freeze from happening. We cant
> merely check the vfs_check_frozen()?
Yes, I agree - see my other email with patches.
> And this should be done where the page is marked dirty.Also, I
> thought that the page is marked read-write only in the page table in
> the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
> the page cache? Is this understanding right?
The page can become dirty either because it was written via standard
write - write_begin is responsible for reliable check here - or it was
written via mmap - here we rely on page_mkwrite to do a reliable check -
it is analogous to write_begin callback. There should be no other way
to dirty a page.
With dirty bits it is a bit complicated. We have two of them in fact. One
in page table entry maintained by mmu and one in page structure maintained
by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
from page table into struct page. This is a lazy process so page can in
principle have new data without a dirty bit set in struct page because we
have not yet copied the dirty bit from page table. Only at moments where it
is important (like when we want to unmap the page, or throw away the page,
or so), we make sure struct page and page table bits are in sync.
Another subtle thing you need not be aware of it that when we clear page
dirty bit, we also writeprotect the page. So we are guaranteed to get a
page fault when the page is written to again.
> IMHO, whatever code dirties the page in the page cache should call a
> F.S specific function and let it _prevent_ a fsfreeze while the page
> is getting dirtied, so that a freeze called after this point flushes
> this page!
Agreed, that's what code in write_begin() and page_mkwrite() should
achieve.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-03 15:36 ` Jan Kara
@ 2011-05-03 15:43 ` Surbhi Palande
2011-05-04 19:24 ` Jan Kara
0 siblings, 1 reply; 669+ messages in thread
From: Surbhi Palande @ 2011-05-03 15:43 UTC (permalink / raw)
To: Jan Kara
Cc: toshi.okajima, tytso, m.mizuma, adilger.kernel, linux-ext4,
linux-fsdevel, sandeen
On 05/03/2011 06:36 PM, Jan Kara wrote:
> On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
>> On 05/03/2011 04:46 PM, Jan Kara wrote:
>>> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>>
>> Sorry for missing the subject line :(
>>>> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
>>>> Toshiyuki pointed out.
>>>>
>>>> zap_pte_range()
>>>> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>>>
>>>> So, I think that it is here that we should do the checking for a ext4 F.S
>>>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>>>
>>>> Attaching a patch for initial review. Please do let me know your thoughts!
>>> This is definitely the wrong place. ->set_page_dirty() callbacks are
>>> called with various locks held and the page need not be locked (thus
>>> dereferencing page->mapping is oopsable). Moreover this particular callback
>>> is called only in data=journal mode.
>> Ok! Thanks for that!
>>
>>>
>>> Believe me, the right place is page_mkwrite() - you have to catch the
>>> read-only => read-write page transition. Once the page is mapped
>>> read-write, you've already lost the race.
>>
>> My only point is:
>> 1) something should prevent the freeze from happening. We cant
>> merely check the vfs_check_frozen()?
> Yes, I agree - see my other email with patches.
>
>> And this should be done where the page is marked dirty.Also, I
>> thought that the page is marked read-write only in the page table in
>> the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
>> the page cache? Is this understanding right?
> The page can become dirty either because it was written via standard
> write - write_begin is responsible for reliable check here - or it was
> written via mmap - here we rely on page_mkwrite to do a reliable check -
> it is analogous to write_begin callback. There should be no other way
> to dirty a page.
>
> With dirty bits it is a bit complicated. We have two of them in fact. One
> in page table entry maintained by mmu and one in page structure maintained
> by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
> from page table into struct page. This is a lazy process so page can in
> principle have new data without a dirty bit set in struct page because we
> have not yet copied the dirty bit from page table. Only at moments where it
> is important (like when we want to unmap the page, or throw away the page,
> or so), we make sure struct page and page table bits are in sync.
>
> Another subtle thing you need not be aware of it that when we clear page
> dirty bit, we also writeprotect the page. So we are guaranteed to get a
> page fault when the page is written to again.
>
>> IMHO, whatever code dirties the page in the page cache should call a
>> F.S specific function and let it _prevent_ a fsfreeze while the page
>> is getting dirtied, so that a freeze called after this point flushes
>> this page!
> Agreed, that's what code in write_begin() and page_mkwrite() should
> achieve.
> Honza
Thanks a lot for the wonderful explanation :)
How about the revert : i.e calling jbd2_journal_unlock_updates() from
ext4_unfreeze() instead of the ext4_freeze()? Do you agree to that?
Warm Regards,
Surbhi.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-05-03 15:43 ` Surbhi Palande
@ 2011-05-04 19:24 ` Jan Kara
0 siblings, 0 replies; 669+ messages in thread
From: Jan Kara @ 2011-05-04 19:24 UTC (permalink / raw)
To: Surbhi Palande
Cc: Jan Kara, toshi.okajima, tytso, m.mizuma, adilger.kernel,
linux-ext4, linux-fsdevel, sandeen
On Tue 03-05-11 18:43:48, Surbhi Palande wrote:
> On 05/03/2011 06:36 PM, Jan Kara wrote:
> >On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
> >>On 05/03/2011 04:46 PM, Jan Kara wrote:
> >>>On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> >>
> >>Sorry for missing the subject line :(
> >>>>On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> >>>>Toshiyuki pointed out.
> >>>>
> >>>>zap_pte_range()
> >>>> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
> >>>>
> >>>>So, I think that it is here that we should do the checking for a ext4 F.S
> >>>>frozen state and also prevent a parallel ext4 F.S freeze from happening.
> >>>>
> >>>>Attaching a patch for initial review. Please do let me know your thoughts!
> >>> This is definitely the wrong place. ->set_page_dirty() callbacks are
> >>>called with various locks held and the page need not be locked (thus
> >>>dereferencing page->mapping is oopsable). Moreover this particular callback
> >>>is called only in data=journal mode.
> >>Ok! Thanks for that!
> >>
> >>>
> >>>Believe me, the right place is page_mkwrite() - you have to catch the
> >>>read-only => read-write page transition. Once the page is mapped
> >>>read-write, you've already lost the race.
> >>
> >>My only point is:
> >>1) something should prevent the freeze from happening. We cant
> >>merely check the vfs_check_frozen()?
> > Yes, I agree - see my other email with patches.
> >
> >>And this should be done where the page is marked dirty.Also, I
> >>thought that the page is marked read-write only in the page table in
> >>the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
> >>the page cache? Is this understanding right?
> > The page can become dirty either because it was written via standard
> >write - write_begin is responsible for reliable check here - or it was
> >written via mmap - here we rely on page_mkwrite to do a reliable check -
> >it is analogous to write_begin callback. There should be no other way
> >to dirty a page.
> >
> >With dirty bits it is a bit complicated. We have two of them in fact. One
> >in page table entry maintained by mmu and one in page structure maintained
> >by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
> >from page table into struct page. This is a lazy process so page can in
> >principle have new data without a dirty bit set in struct page because we
> >have not yet copied the dirty bit from page table. Only at moments where it
> >is important (like when we want to unmap the page, or throw away the page,
> >or so), we make sure struct page and page table bits are in sync.
> >
> >Another subtle thing you need not be aware of it that when we clear page
> >dirty bit, we also writeprotect the page. So we are guaranteed to get a
> >page fault when the page is written to again.
> >
> >>IMHO, whatever code dirties the page in the page cache should call a
> >>F.S specific function and let it _prevent_ a fsfreeze while the page
> >>is getting dirtied, so that a freeze called after this point flushes
> >>this page!
> > Agreed, that's what code in write_begin() and page_mkwrite() should
> >achieve.
> > Honza
> Thanks a lot for the wonderful explanation :)
>
> How about the revert : i.e calling jbd2_journal_unlock_updates()
> from ext4_unfreeze() instead of the ext4_freeze()? Do you agree to
> that?
Sorry, I don't agree with revert. We could talk about changing
jbd2_journal_unlock_updates() to not return with mutex held (and handle
synchronization of locked journal operations differently) as an alternative
to doing "freeze" reference counting. But returning with mutex held to user
space is no-go. It will cause problems in lockdep, violates kernel locking
rules, and generally is a bad programming ;).
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2011-02-16 11:54 Hema HK
2011-02-16 11:55 ` your mail Felipe Balbi
0 siblings, 1 reply; 669+ messages in thread
From: Hema HK @ 2011-02-16 11:54 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA, Hema HK, Felipe Balbi
Moved all the board specific internal PHY functions out of usb_musb.c file
as this file is shared between the OMAP2+ and AM35xx platforms.
There exists a file which has the functions specific to internal PHY
used for OMAP4 platform. Moved all phy specific functions to this file
and passing these functions through board data in the board file.
Signed-off-by: Hema HK <hemahk-l0cyMroinI0@public.gmane.org>
Cc: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
+ .set_phy_power = am35x_musb_phy_power,
+ .clear_irq = am35x_musb_clear_irq,
+ .set_mode = am35x_musb_set_mode,
+ .reset = am35x_musb_reset,
};
static __init void am3517_evm_musb_init(void)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -29,6 +29,7 @@
#include <linux/usb.h>
#include <plat/usb.h>
+#include "control.h"
/* OMAP control module register for UTMI PHY */
#define CONTROL_DEV_CONF 0x300
@@ -147,3 +148,95 @@ int omap4430_phy_exit(struct device *dev
return 0;
}
+
+void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval &= ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+ * Start the on-chip PHY and its PLL.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO "Waiting for PHY clock good...\n");
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+ & CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR "musb PHY clock good timed out\n");
+ break;
+ }
+ }
+ } else {
+ /*
+ * Power down the on-chip PHY.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,102 +30,9 @@
#include <mach/irqs.h>
#include <mach/am35xx.h>
#include <plat/usb.h>
-#include "control.h"
#if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
-static void am35x_musb_reset(void)
-{
- u32 regval;
-
- /* Reset the musb interface */
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-
- regval |= AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval &= ~AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-}
-
-static void am35x_musb_phy_power(u8 on)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(100);
- u32 devconf2;
-
- if (on) {
- /*
- * Start the on-chip PHY and its PLL.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
- devconf2 |= CONF2_PHY_PLLON;
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-
- pr_info(KERN_INFO "Waiting for PHY clock good...\n");
- while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
- & CONF2_PHYCLKGD)) {
- cpu_relax();
-
- if (time_after(jiffies, timeout)) {
- pr_err(KERN_ERR "musb PHY clock good timed out\n");
- break;
- }
- }
- } else {
- /*
- * Power down the on-chip PHY.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_PHY_PLLON;
- devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
- }
-}
-
-static void am35x_musb_clear_irq(void)
-{
- u32 regval;
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval |= AM35XX_USBOTGSS_INT_CLR;
- omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
-}
-
-static void am35x_musb_set_mode(u8 musb_mode)
-{
- u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_OTGMODE;
- switch (musb_mode) {
-#ifdef CONFIG_USB_MUSB_HDRC_HCD
- case MUSB_HOST: /* Force VBUS valid, ID = 0 */
- devconf2 |= CONF2_FORCE_HOST;
- break;
-#endif
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
- devconf2 |= CONF2_FORCE_DEVICE;
- break;
-#endif
-#ifdef CONFIG_USB_MUSB_OTG
- case MUSB_OTG: /* Don't override the VBUS/ID comparators */
- devconf2 |= CONF2_NO_OVERRIDE;
- break;
-#endif
- default:
- pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
- }
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-}
-
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
.flags = IORESOURCE_MEM,
@@ -189,10 +96,6 @@ void __init usb_musb_init(struct omap_mu
musb_device.name = "musb-am35x";
musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
musb_resources[1].start = INT_35XX_USBOTG_IRQ;
- board_data->set_phy_power = am35x_musb_phy_power;
- board_data->clear_irq = am35x_musb_clear_irq;
- board_data->set_mode = am35x_musb_set_mode;
- board_data->reset = am35x_musb_reset;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===================================================================
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -91,6 +91,10 @@ extern int omap4430_phy_exit(struct devi
#endif
+extern void am35x_musb_reset(void);
+extern void am35x_musb_phy_power(u8 on);
+extern void am35x_musb_clear_irq(void);
+extern void am35x_musb_set_mode(u8 musb_mode);
/*
* FIXME correct answer depends on hmc_mode,
Index: linux-2.6/arch/arm/mach-omap2/Makefile
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-2.6/arch/arm/mach-omap2/Makefile
@@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
hsmmc.o \
omap_phy_internal.o
-obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
+obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
+ omap_phy_internal.o \
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-02-16 11:54 (unknown), Hema HK
@ 2011-02-16 11:55 ` Felipe Balbi
2011-02-16 12:07 ` Hema Kalliguddi
0 siblings, 1 reply; 669+ messages in thread
From: Felipe Balbi @ 2011-02-16 11:55 UTC (permalink / raw)
To: Hema HK; +Cc: linux-usb, linux-omap, Felipe Balbi
no subject ??
--
balbi
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
2011-02-16 11:55 ` your mail Felipe Balbi
@ 2011-02-16 12:07 ` Hema Kalliguddi
0 siblings, 0 replies; 669+ messages in thread
From: Hema Kalliguddi @ 2011-02-16 12:07 UTC (permalink / raw)
To: balbi; +Cc: linux-usb, linux-omap
Hi,
Yes. This was broken patch. My bad... I resent the patch.
Regards,
Hema
>-----Original Message-----
>From: Felipe Balbi [mailto:balbi@ti.com]
>Sent: Wednesday, February 16, 2011 5:26 PM
>To: Hema HK
>Cc: linux-usb@vger.kernel.org; linux-omap@vger.kernel.org; Felipe Balbi
>Subject: Re: your mail
>
>no subject ??
>
>--
>balbi
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2011-02-16 11:53 Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: Hema HK @ 2011-02-16 11:53 UTC (permalink / raw)
To: linux-usb; +Cc: linux-omap, Hema HK
From: Hema HK <hemahk@ti.com
Moved all the board specific internal PHY functions out of usb_musb.c file
as this file is shared between the OMAP2+ and AM35xx platforms.
There exists a file which has the functions specific to internal PHY
used for OMAP4 platform. Moved all phy specific functions to this file
and passing these functions through board data in the board file.
Signed-off-by: Hema HK <hemahk@ti.com>
Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
+ .set_phy_power = am35x_musb_phy_power,
+ .clear_irq = am35x_musb_clear_irq,
+ .set_mode = am35x_musb_set_mode,
+ .reset = am35x_musb_reset,
};
static __init void am3517_evm_musb_init(void)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -29,6 +29,7 @@
#include <linux/usb.h>
#include <plat/usb.h>
+#include "control.h"
/* OMAP control module register for UTMI PHY */
#define CONTROL_DEV_CONF 0x300
@@ -147,3 +148,95 @@ int omap4430_phy_exit(struct device *dev
return 0;
}
+
+void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval &= ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+ * Start the on-chip PHY and its PLL.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO "Waiting for PHY clock good...\n");
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+ & CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR "musb PHY clock good timed out\n");
+ break;
+ }
+ }
+ } else {
+ /*
+ * Power down the on-chip PHY.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,102 +30,9 @@
#include <mach/irqs.h>
#include <mach/am35xx.h>
#include <plat/usb.h>
-#include "control.h"
#if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
-static void am35x_musb_reset(void)
-{
- u32 regval;
-
- /* Reset the musb interface */
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-
- regval |= AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval &= ~AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-}
-
-static void am35x_musb_phy_power(u8 on)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(100);
- u32 devconf2;
-
- if (on) {
- /*
- * Start the on-chip PHY and its PLL.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
- devconf2 |= CONF2_PHY_PLLON;
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-
- pr_info(KERN_INFO "Waiting for PHY clock good...\n");
- while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
- & CONF2_PHYCLKGD)) {
- cpu_relax();
-
- if (time_after(jiffies, timeout)) {
- pr_err(KERN_ERR "musb PHY clock good timed out\n");
- break;
- }
- }
- } else {
- /*
- * Power down the on-chip PHY.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_PHY_PLLON;
- devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
- }
-}
-
-static void am35x_musb_clear_irq(void)
-{
- u32 regval;
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval |= AM35XX_USBOTGSS_INT_CLR;
- omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
-}
-
-static void am35x_musb_set_mode(u8 musb_mode)
-{
- u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_OTGMODE;
- switch (musb_mode) {
-#ifdef CONFIG_USB_MUSB_HDRC_HCD
- case MUSB_HOST: /* Force VBUS valid, ID = 0 */
- devconf2 |= CONF2_FORCE_HOST;
- break;
-#endif
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
- devconf2 |= CONF2_FORCE_DEVICE;
- break;
-#endif
-#ifdef CONFIG_USB_MUSB_OTG
- case MUSB_OTG: /* Don't override the VBUS/ID comparators */
- devconf2 |= CONF2_NO_OVERRIDE;
- break;
-#endif
- default:
- pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
- }
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-}
-
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
.flags = IORESOURCE_MEM,
@@ -189,10 +96,6 @@ void __init usb_musb_init(struct omap_mu
musb_device.name = "musb-am35x";
musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
musb_resources[1].start = INT_35XX_USBOTG_IRQ;
- board_data->set_phy_power = am35x_musb_phy_power;
- board_data->clear_irq = am35x_musb_clear_irq;
- board_data->set_mode = am35x_musb_set_mode;
- board_data->reset = am35x_musb_reset;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===================================================================
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -91,6 +91,10 @@ extern int omap4430_phy_exit(struct devi
#endif
+extern void am35x_musb_reset(void);
+extern void am35x_musb_phy_power(u8 on);
+extern void am35x_musb_clear_irq(void);
+extern void am35x_musb_set_mode(u8 musb_mode);
/*
* FIXME correct answer depends on hmc_mode,
Index: linux-2.6/arch/arm/mach-omap2/Makefile
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-2.6/arch/arm/mach-omap2/Makefile
@@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
hsmmc.o \
omap_phy_internal.o
-obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
+obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
+ omap_phy_internal.o \
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
^ permalink raw reply [flat|nested] 669+ messages in thread* (no subject)
@ 2011-01-14 1:14 Omar Ramirez Luna
2011-01-14 4:36 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: Omar Ramirez Luna @ 2011-01-14 1:14 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Felipe Contreras, devel, linux-kernel
Please pull these changes for 2.6.38:
The following changes since commit 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5:
Linux 2.6.37 (2011-01-04 16:50:19 -0800)
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git for-gkh-2.6.38
Guzman Lugo, Fernando (1):
staging: tidspbridge: configure full L1 MMU range
Omar Ramirez Luna (1):
staging: tidspbridge: replace mbox callback with notifier_call
drivers/staging/tidspbridge/core/tiomap3430.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
Regards,
Omar
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-01-14 1:14 Omar Ramirez Luna
@ 2011-01-14 4:36 ` Greg KH
0 siblings, 0 replies; 669+ messages in thread
From: Greg KH @ 2011-01-14 4:36 UTC (permalink / raw)
To: Omar Ramirez Luna; +Cc: Felipe Contreras, devel, linux-kernel
On Thu, Jan 13, 2011 at 07:14:53PM -0600, Omar Ramirez Luna wrote:
> Please pull these changes for 2.6.38:
>
> The following changes since commit 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5:
>
> Linux 2.6.37 (2011-01-04 16:50:19 -0800)
>
> are available in the git repository at:
> git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git for-gkh-2.6.38
>
> Guzman Lugo, Fernando (1):
> staging: tidspbridge: configure full L1 MMU range
>
> Omar Ramirez Luna (1):
> staging: tidspbridge: replace mbox callback with notifier_call
>
> drivers/staging/tidspbridge/core/tiomap3430.c | 15 +++++++--------
> 1 files changed, 7 insertions(+), 8 deletions(-)
You forgot a Subject: line.
Also, as these are just 2 patches, care to just email them so we can
review them?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2011-01-03 16:38 castet.matthieu
2011-01-03 17:03 ` your mail Stanislaw Gruszka
0 siblings, 1 reply; 669+ messages in thread
From: castet.matthieu @ 2011-01-03 16:38 UTC (permalink / raw)
To: linux-kernel, linux-usb; +Cc: stf_xl, tj
Hi,
could you CC me on ueagle-atm.c patches.
>From what I remind we sleep in the workqueue, that's why we couldn't use the
system one (freeze keyboard...). But may be the code changed.
Matthieu
Tejun Heo a écrit :
> With cmwq, there's no reason to use separate workqueues. Drop
> uea_softc->work_q and use system_wq instead. The used work item is
> sync flushed on driver detach.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Stanislaw Gruszka <stf_xl@wp.pl>
> Cc: linux-usb@vger.kernel.org
> ---
> Only compile tested. Please feel free to take it into the subsystem
> tree or simply ack - I'll route it through the wq tree.
>
> Thanks.
>
> drivers/usb/atm/ueagle-atm.c | 19 +++++--------------
> 1 files changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
> index 44447f5..55c1d3b 100644
> --- a/drivers/usb/atm/ueagle-atm.c
> +++ b/drivers/usb/atm/ueagle-atm.c
> @@ -168,7 +168,6 @@ struct uea_softc {
> union cmv_dsc cmv_dsc;
>
> struct work_struct task;
> - struct workqueue_struct *work_q;
> u16 pageno;
> u16 ovl;
>
> @@ -1879,7 +1878,7 @@ static int uea_start_reset(struct uea_softc *sc)
> /* start loading DSP */
> sc->pageno = 0;
> sc->ovl = 0;
> - queue_work(sc->work_q, &sc->task);
> + schedule_work(&sc->task);
>
> /* wait for modem ready CMV */
> ret = wait_cmv_ack(sc);
> @@ -2091,14 +2090,14 @@ static void uea_schedule_load_page_e1(struct uea_softc
*sc,
> {
> sc->pageno = intr->e1_bSwapPageNo;
> sc->ovl = intr->e1_bOvl >> 4 | intr->e1_bOvl << 4;
> - queue_work(sc->work_q, &sc->task);
> + schedule_work(&sc->task);
> }
>
> static void uea_schedule_load_page_e4(struct uea_softc *sc,
> struct intr_pkt *intr)
> {
> sc->pageno = intr->e4_bSwapPageNo;
> - queue_work(sc->work_q, &sc->task);
> + schedule_work(&sc->task);
> }
>
> /*
> @@ -2170,13 +2169,6 @@ static int uea_boot(struct uea_softc *sc)
>
> init_waitqueue_head(&sc->sync_q);
>
> - sc->work_q = create_workqueue("ueagle-dsp");
> - if (!sc->work_q) {
> - uea_err(INS_TO_USBDEV(sc), "cannot allocate workqueue\n");
> - uea_leaves(INS_TO_USBDEV(sc));
> - return -ENOMEM;
> - }
> -
> if (UEA_CHIP_VERSION(sc) == ADI930)
> load_XILINX_firmware(sc);
>
> @@ -2222,7 +2214,6 @@ err1:
> sc->urb_int = NULL;
> kfree(intr);
> err0:
> - destroy_workqueue(sc->work_q);
> uea_leaves(INS_TO_USBDEV(sc));
> return -ENOMEM;
> }
> @@ -2243,8 +2234,8 @@ static void uea_stop(struct uea_softc *sc)
> kfree(sc->urb_int->transfer_buffer);
> usb_free_urb(sc->urb_int);
>
> - /* stop any pending boot process, when no one can schedule work */
> - destroy_workqueue(sc->work_q);
> + /* flush the work item, when no one can schedule it */
> + flush_work_sync(&sc->task);
>
> if (sc->dsp_firm)
> release_firmware(sc->dsp_firm);
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2011-01-03 16:38 castet.matthieu
@ 2011-01-03 17:03 ` Stanislaw Gruszka
2011-01-04 5:17 ` Tejun Heo
0 siblings, 1 reply; 669+ messages in thread
From: Stanislaw Gruszka @ 2011-01-03 17:03 UTC (permalink / raw)
To: castet.matthieu; +Cc: linux-kernel, linux-usb, stf_xl, tj
On Mon, Jan 03, 2011 at 05:38:00PM +0100, castet.matthieu@free.fr wrote:
> Hi,
>
> could you CC me on ueagle-atm.c patches.
>
> From what I remind we sleep in the workqueue, that's why we couldn't use the
> system one (freeze keyboard...). But may be the code changed.
In case when firmware is not available we can sleep for a few seconds in
work function. That's block keyboard driver who also use common workqueue.
If recent Tejun workqueue rewrite allow to long sleep in work func and
not hurt other workqueue users, patch is ok.
Unfortunately I'm not able to test the patch, my ueagle device was physically
damaged a few months ago.
Stanislaw
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2011-01-03 17:03 ` your mail Stanislaw Gruszka
@ 2011-01-04 5:17 ` Tejun Heo
0 siblings, 0 replies; 669+ messages in thread
From: Tejun Heo @ 2011-01-04 5:17 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: castet.matthieu, linux-kernel, linux-usb, stf_xl
On Mon, Jan 03, 2011 at 06:03:17PM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 03, 2011 at 05:38:00PM +0100, castet.matthieu@free.fr wrote:
> > could you CC me on ueagle-atm.c patches.
Will try to, but maybe it's a good idea to add a MAINTAINERS entry?
> > From what I remind we sleep in the workqueue, that's why we couldn't use the
> > system one (freeze keyboard...). But may be the code changed.
> In case when firmware is not available we can sleep for a few seconds in
> work function. That's block keyboard driver who also use common workqueue.
> If recent Tejun workqueue rewrite allow to long sleep in work func and
> not hurt other workqueue users, patch is ok.
Yeap, work items can sleep all they want on the system_wq. It won't
delay execution of other work items.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2010-09-18 11:49 Raj Kumar
2010-09-18 15:36 ` your mail Alan Stern
0 siblings, 1 reply; 669+ messages in thread
From: Raj Kumar @ 2010-09-18 11:49 UTC (permalink / raw)
To: stern, linux-pm
[-- Attachment #1.1: Type: text/plain, Size: 710 bytes --]
Hi Alan,
I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
then X device driver when detects waorkload, Can this X device driver call policy governor APIS for scaling clock or
this X device driver can directly calls DVFS driver APIs directly?
I just want to know from our device driver how do call DVFS driver if DVFS driver is registered with cpu frequency subsystem?
Regards
Raj
[-- Attachment #1.2: Type: text/html, Size: 1000 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-09-18 11:49 (no subject) Raj Kumar
@ 2010-09-18 15:36 ` Alan Stern
2010-09-18 15:56 ` Dominik Brodowski
0 siblings, 1 reply; 669+ messages in thread
From: Alan Stern @ 2010-09-18 15:36 UTC (permalink / raw)
To: Raj Kumar; +Cc: linux-pm
On Sat, 18 Sep 2010, Raj Kumar wrote:
> Hi Alan,
>
>
>
> I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
>
> e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
>
> upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
>
> then X device driver when detects waorkload, Can this X device driver call policy governor APIS for scaling clock or
>
> this X device driver can directly calls DVFS driver APIs directly?
I don't know. I have never used cpufreq and I don't know how it works.
> I just want to know from our device driver how do call DVFS driver if DVFS driver is registered with cpu frequency subsystem?
Then you should ask somebody else.
Alan Stern
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-09-18 15:36 ` your mail Alan Stern
@ 2010-09-18 15:56 ` Dominik Brodowski
0 siblings, 0 replies; 669+ messages in thread
From: Dominik Brodowski @ 2010-09-18 15:56 UTC (permalink / raw)
To: Raj Kumar, linux-pm
Hi Raj,
On Sat, Sep 18, 2010 at 11:36:16AM -0400, Alan Stern wrote:
> > I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
> >
> > e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
> >
> > upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
> >
> > then X device driver when detects waorkload, Can this X device driver call policy governor APIS for scaling clock or
> >
> > this X device driver can directly calls DVFS driver APIs directly?
Best would be to register a cpufreq policy notifier,
(cpufreq_register_notifier()), and then call cpufreq_update_policy()
whenever the "X device driver" needs to modify its frequency constraints.
In addition, it would be best to discuss this on the cpufreq mailing list at
cpufreq@vger.kernel.org
Best,
Dominik
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2010-06-16 16:33 Jan Kara
2010-06-16 22:15 ` your mail Dave Chinner
2010-06-22 2:59 ` Wu Fengguang
0 siblings, 2 replies; 669+ messages in thread
From: Jan Kara @ 2010-06-16 16:33 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-mm, Andrew Morton, npiggin
Hello,
here is the fourth version of the writeback livelock avoidance patches
for data integrity writes. To quickly summarize the idea: we tag dirty
pages at the beginning of write_cache_pages with a new TOWRITE tag and
then write only tagged pages to avoid parallel writers to livelock us.
See changelogs of the patches for more details.
I have tested the patches with fsx and a test program I wrote which
checks that if we crash after fsync, the data is indeed on disk.
If there are no more concerns, can these patches get merged?
Honza
Changes since last version:
- tagging function was changed to stop after given amount of pages to
avoid keeping tree_lock and irqs disabled for too long
- changed names and updated comments as Andrew suggested
- measured memory impact and reported it in the changelog
Things suggested but not changed (I want to avoid going in circles ;):
- use tagging also for WB_SYNC_NONE writeback - there's problem with an
interaction with wbc->nr_to_write. If we tag all dirty pages, we can
spend too much time tagging when we write only a few pages in the end
because of nr_to_write. If we tag only say nr_to_write pages, we may
not have enough pages tagged because some pages are written out by
someone else and so we would have to restart and tagging would become
essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
writeback if we can get rid of nr_to_write. But that's a story for
a different patch set.
- implement function for clearing several tags (TOWRITE, DIRTY) at once
- IMHO not worth it because we would save only conversion of page index
to radix tree offsets. The rest would have to be separate anyways. And
the interface would be incosistent as well...
- use __lookup_tag to implement radix_tree_range_tag_if_tagged - doesn't
quite work because __lookup_tag returns only leaf nodes so we'd have to
implement tree traversal anyways to tag also internal nodes.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-06-16 16:33 (unknown), Jan Kara
@ 2010-06-16 22:15 ` Dave Chinner
2010-06-22 2:59 ` Wu Fengguang
1 sibling, 0 replies; 669+ messages in thread
From: Dave Chinner @ 2010-06-16 22:15 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-fsdevel, linux-mm, Andrew Morton, npiggin
On Wed, Jun 16, 2010 at 06:33:49PM +0200, Jan Kara wrote:
> Hello,
>
> here is the fourth version of the writeback livelock avoidance patches
> for data integrity writes. To quickly summarize the idea: we tag dirty
> pages at the beginning of write_cache_pages with a new TOWRITE tag and
> then write only tagged pages to avoid parallel writers to livelock us.
> See changelogs of the patches for more details.
> I have tested the patches with fsx and a test program I wrote which
> checks that if we crash after fsync, the data is indeed on disk.
> If there are no more concerns, can these patches get merged?
Has it been run through xfstests? I'd suggest doing that at least
with XFS as there are several significant sync sanity tests for XFS
in the suite...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-06-16 16:33 (unknown), Jan Kara
@ 2010-06-22 2:59 ` Wu Fengguang
2010-06-22 2:59 ` Wu Fengguang
1 sibling, 0 replies; 669+ messages in thread
From: Wu Fengguang @ 2010-06-22 2:59 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-fsdevel, linux-mm, Andrew Morton, npiggin
> - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> spend too much time tagging when we write only a few pages in the end
> because of nr_to_write. If we tag only say nr_to_write pages, we may
> not have enough pages tagged because some pages are written out by
> someone else and so we would have to restart and tagging would become
This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
writeback triggered by sync(). write_cache_pages() already ignored
nr_to_write for WB_SYNC_ALL.
> essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> writeback if we can get rid of nr_to_write. But that's a story for
> a different patch set.
Besides introducing overheads, it will be a policy change in which the
system loses control to somehow "throttle" writeback of huge files.
So it may be safer to enlarge nr_to_write instead of canceling it totally.
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2010-06-22 2:59 ` Wu Fengguang
0 siblings, 0 replies; 669+ messages in thread
From: Wu Fengguang @ 2010-06-22 2:59 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-fsdevel, linux-mm, Andrew Morton, npiggin
> - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> spend too much time tagging when we write only a few pages in the end
> because of nr_to_write. If we tag only say nr_to_write pages, we may
> not have enough pages tagged because some pages are written out by
> someone else and so we would have to restart and tagging would become
This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
writeback triggered by sync(). write_cache_pages() already ignored
nr_to_write for WB_SYNC_ALL.
> essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> writeback if we can get rid of nr_to_write. But that's a story for
> a different patch set.
Besides introducing overheads, it will be a policy change in which the
system loses control to somehow "throttle" writeback of huge files.
So it may be safer to enlarge nr_to_write instead of canceling it totally.
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-06-22 2:59 ` Wu Fengguang
@ 2010-06-22 13:54 ` Jan Kara
-1 siblings, 0 replies; 669+ messages in thread
From: Jan Kara @ 2010-06-22 13:54 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Jan Kara, linux-fsdevel, linux-mm, Andrew Morton, npiggin
On Tue 22-06-10 10:59:41, Wu Fengguang wrote:
> > - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> > interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> > spend too much time tagging when we write only a few pages in the end
> > because of nr_to_write. If we tag only say nr_to_write pages, we may
> > not have enough pages tagged because some pages are written out by
> > someone else and so we would have to restart and tagging would become
>
> This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
> writeback triggered by sync(). write_cache_pages() already ignored
> nr_to_write for WB_SYNC_ALL.
We could do that but frankly, I'm not very fond of adding more special
cases to writeback code than strictly necessary...
> > essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> > writeback if we can get rid of nr_to_write. But that's a story for
> > a different patch set.
>
> Besides introducing overheads, it will be a policy change in which the
> system loses control to somehow "throttle" writeback of huge files.
Yes, but if we guarantee we cannot livelock on a single file, do we care?
Memory management does not care because it's getting rid of dirty pages
which is what it wants. User might care but actually writing out files in
the order they were dirtied (i.e., the order user written them) is quite
natural so it's not a "surprising" behavior. And I don't think we can
assume that data in those small files are more valuable than data in the
large file and thus should be written earlier...
With the overhead you are right that tagging is more expensive than
checking nr_to_write limit...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2010-06-22 13:54 ` Jan Kara
0 siblings, 0 replies; 669+ messages in thread
From: Jan Kara @ 2010-06-22 13:54 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Jan Kara, linux-fsdevel, linux-mm, Andrew Morton, npiggin
On Tue 22-06-10 10:59:41, Wu Fengguang wrote:
> > - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> > interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> > spend too much time tagging when we write only a few pages in the end
> > because of nr_to_write. If we tag only say nr_to_write pages, we may
> > not have enough pages tagged because some pages are written out by
> > someone else and so we would have to restart and tagging would become
>
> This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
> writeback triggered by sync(). write_cache_pages() already ignored
> nr_to_write for WB_SYNC_ALL.
We could do that but frankly, I'm not very fond of adding more special
cases to writeback code than strictly necessary...
> > essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> > writeback if we can get rid of nr_to_write. But that's a story for
> > a different patch set.
>
> Besides introducing overheads, it will be a policy change in which the
> system loses control to somehow "throttle" writeback of huge files.
Yes, but if we guarantee we cannot livelock on a single file, do we care?
Memory management does not care because it's getting rid of dirty pages
which is what it wants. User might care but actually writing out files in
the order they were dirtied (i.e., the order user written them) is quite
natural so it's not a "surprising" behavior. And I don't think we can
assume that data in those small files are more valuable than data in the
large file and thus should be written earlier...
With the overhead you are right that tagging is more expensive than
checking nr_to_write limit...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-06-22 13:54 ` Jan Kara
(?)
@ 2010-06-22 14:12 ` Wu Fengguang
-1 siblings, 0 replies; 669+ messages in thread
From: Wu Fengguang @ 2010-06-22 14:12 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-fsdevel, linux-mm, Andrew Morton, npiggin
On Tue, Jun 22, 2010 at 09:54:58PM +0800, Jan Kara wrote:
> On Tue 22-06-10 10:59:41, Wu Fengguang wrote:
> > > - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> > > interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> > > spend too much time tagging when we write only a few pages in the end
> > > because of nr_to_write. If we tag only say nr_to_write pages, we may
> > > not have enough pages tagged because some pages are written out by
> > > someone else and so we would have to restart and tagging would become
> >
> > This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
> > writeback triggered by sync(). write_cache_pages() already ignored
> > nr_to_write for WB_SYNC_ALL.
> We could do that but frankly, I'm not very fond of adding more special
> cases to writeback code than strictly necessary...
So do me. However for this case we only need to broaden the special case test:
if (nr_to_write > 0) {
nr_to_write--;
if (nr_to_write == 0 &&
- wbc->sync_mode == WB_SYNC_NONE) {
+ !wbc->for_sync) {
> > > essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> > > writeback if we can get rid of nr_to_write. But that's a story for
> > > a different patch set.
> >
> > Besides introducing overheads, it will be a policy change in which the
> > system loses control to somehow "throttle" writeback of huge files.
> Yes, but if we guarantee we cannot livelock on a single file, do we care?
> Memory management does not care because it's getting rid of dirty pages
> which is what it wants. User might care but actually writing out files in
> the order they were dirtied (i.e., the order user written them) is quite
> natural so it's not a "surprising" behavior. And I don't think we can
> assume that data in those small files are more valuable than data in the
> large file and thus should be written earlier...
It could be a surprising behavior when, there is a 4GB dirty file and
100 small dirty files. The user may expect the 100 small dirty files
be synced to disk after 30s. However without nr_to_write, they could
be delayed by the 4GB file for 40 more seconds. Now if something goes
wrong in between and the small dirty files happen to include some
.c/.tex/.txt/... files.
Small files are more likely your precious documents that are typed in
word-by-word and perhaps the most important data you want to protect.
Naturally you'll want them enjoy more priority than large files.
> With the overhead you are right that tagging is more expensive than
> checking nr_to_write limit...
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2010-06-13 6:16 Mike Gilks
2010-06-18 23:52 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: Mike Gilks @ 2010-06-13 6:16 UTC (permalink / raw)
To: gregkh, mchehab, julia, joe; +Cc: devel, linux-kernel
Subject:r8192U_core.c Last pass
In-Reply-To:
This is the last patch I can manage for this file.
Everything else to do with checkpatch.pl issues may require an actual developer to look at it.
Mike
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-06-13 6:16 Mike Gilks
@ 2010-06-18 23:52 ` Greg KH
0 siblings, 0 replies; 669+ messages in thread
From: Greg KH @ 2010-06-18 23:52 UTC (permalink / raw)
To: Mike Gilks; +Cc: gregkh, mchehab, julia, joe, devel, linux-kernel
On Sun, Jun 13, 2010 at 02:16:47PM +0800, Mike Gilks wrote:
> Subject:r8192U_core.c Last pass
> In-Reply-To:
>
>
> This is the last patch I can manage for this file.
> Everything else to do with checkpatch.pl issues may require an actual developer to look at it.
I have a whole bunch of series of patches from you (one duplicating
Linus's patch, I don't think you ment to send that...) So, which should
I apply?
How about I delete them all and you send me the latest ones that you
want me to apply, as I'm totally confused which is your latest version
and which isn't and I see lots of duplicates.
Sound good?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* No subject
@ 2010-06-07 17:58 Dave Hylands
2010-06-07 22:10 ` your mail Jamie Lokier
0 siblings, 1 reply; 669+ messages in thread
From: Dave Hylands @ 2010-06-07 17:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I'm trying to understand what I need to be concerned about with SMP
processors and sharing global data (in particular a dual Cortex-A9)
I'm familiar with spinlocks, but in this case I'm trying to work with
some lockless data structures.
What I'm not sure is whether the following would work. Suppose I have
a couple of 8-bit get/put indicies which are in adjacent memory
locations (within the same 32-bit word).
If I have an ISR and a thread running on an SMP core, and the ISR is
running on one core and the thread is running on a second core, if the
ISR were to only write to the put pointer and the thread were only to
write to the get pointer, does the cache maintain consistency? Or do
the get and put pointers need to be in separate cache lines?
Another way of asking this: If both cores are writing to the same
32-bit word (but different bytes) do the writes collide?
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2010-06-07 17:58 No subject Dave Hylands
@ 2010-06-07 22:10 ` Jamie Lokier
2010-06-07 22:44 ` Dave Hylands
0 siblings, 1 reply; 669+ messages in thread
From: Jamie Lokier @ 2010-06-07 22:10 UTC (permalink / raw)
To: linux-arm-kernel
Dave Hylands wrote:
> I'm trying to understand what I need to be concerned about with SMP
> processors and sharing global data (in particular a dual Cortex-A9)
>
> I'm familiar with spinlocks, but in this case I'm trying to work with
> some lockless data structures.
>
> What I'm not sure is whether the following would work. Suppose I have
> a couple of 8-bit get/put indicies which are in adjacent memory
> locations (within the same 32-bit word).
>
> If I have an ISR and a thread running on an SMP core, and the ISR is
> running on one core and the thread is running on a second core, if the
> ISR were to only write to the put pointer and the thread were only to
> write to the get pointer, does the cache maintain consistency? Or do
> the get and put pointers need to be in separate cache lines?
>
> Another way of asking this: If both cores are writing to the same
> 32-bit word (but different bytes) do the writes collide?
I'm pretty sure any system compatible with pthreads has to be fine
with the variables being independent, because the bytes could be
variables protected by separate mutexes.
However, other questions for your lockless structures are whether
writes by one processor are seen in a reasonable or even bounded time
by reads on another processor (write buffering), and which barrier
instructions to use between the index accesses and accessing some
array they might indexing (only a problem for userspace, because the
kernel already provides barriers).
-- Jamie
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
2010-06-07 22:10 ` your mail Jamie Lokier
@ 2010-06-07 22:44 ` Dave Hylands
0 siblings, 0 replies; 669+ messages in thread
From: Dave Hylands @ 2010-06-07 22:44 UTC (permalink / raw)
To: linux-arm-kernel
HI Jamie,
On Mon, Jun 7, 2010 at 3:10 PM, Jamie Lokier wrote:
> Dave Hylands wrote:
[...]
>> Another way of asking this: If both cores are writing to the same
>> 32-bit word (but different bytes) do the writes collide?
>
> I'm pretty sure any system compatible with pthreads has to be fine
> with the variables being independent, because the bytes could be
> variables protected by separate mutexes.
>
> However, other questions for your lockless structures are whether
> writes by one processor are seen in a reasonable or even bounded time
> by reads on another processor (write buffering), and which barrier
> instructions to use between the index accesses and accessing some
> array they might indexing (only a problem for userspace, because the
> kernel already provides barriers).
After lots of reading - I think that the Snoop Control Unit takes care
of moving the cache lines from one core to the other when both cores
are trying to access data from the same cache line.
So it's not very efficient to have both cores accessing data from the
same cache line - but it seems that the integrity of the data should
be maintained (or at least this is my current understanding).
--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2010-05-18 10:38 Marek Szyprowski
2010-05-19 2:24 ` Ben Dooks
0 siblings, 1 reply; 669+ messages in thread
From: Marek Szyprowski @ 2010-05-18 10:38 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: m.szyprowski, kyungmin.park, ben-linux, kgene.kim
Hello,
This patch series perform a general cleanup in Samsung S5PC100 SoC support.
This chip is moved from custom s5pc1xx platform framework to new plat-s5p
framework, so more common code can be easily reused in upcomming extensions
for S5PV210/S5PC110 SoCs.
This patch series is prepared against next-samsung tree, with assumption
that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
I've tried to split my changes as much as possible to clearly show how the
transition from plat-s5pc1xx to plat-s5p is being done.
Changes since v2:
- fixed some whitespace/tabs errors
- removed external interrupt code, a common code from plat-s5p will be used
- moved SMDKC100 fixes to separate patch series
Changes since v1:
- bases on completely new clock code provided by Kukjin Kim
- added some plat-s5p fixes required for transition
- removed custom functions from gpiolib implementation (now uses common
code from plat-samsung)
- restructured the changes to avoid breaking the functionality beteen the
patches
- some other minor cleanups (mainly c1xx to c100 renames)
This patch series includes:
[PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
[PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
[PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
[PATCH 04/11] ARM: S5PC100: gpio.h cleanup
[PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
[PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
[PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
[PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
[PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2010-05-18 10:38 (unknown), Marek Szyprowski
@ 2010-05-19 2:24 ` Ben Dooks
0 siblings, 0 replies; 669+ messages in thread
From: Ben Dooks @ 2010-05-19 2:24 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, linux-arm-kernel, kyungmin.park, ben-linux, kgene.kim
On Tue, May 18, 2010 at 12:38:38PM +0200, Marek Szyprowski wrote:
> Hello,
Hi, messages are supposed to have subjects... please supply one next
timne.
> This patch series perform a general cleanup in Samsung S5PC100 SoC support.
> This chip is moved from custom s5pc1xx platform framework to new plat-s5p
> framework, so more common code can be easily reused in upcomming extensions
> for S5PV210/S5PC110 SoCs.
>
> This patch series is prepared against next-samsung tree, with assumption
> that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
> plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
> ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
>
> I've tried to split my changes as much as possible to clearly show how the
> transition from plat-s5pc1xx to plat-s5p is being done.
Ok, this seems to be a pretty good progression from one to the other.
I will chase up the EINT support, it got dropped from the first pull due
to your bug reports.
Will start sorting out a second round of branches with a view to trying to
get this into the current merge window. I hope to have something to test
by the end of today.
> Changes since v2:
> - fixed some whitespace/tabs errors
> - removed external interrupt code, a common code from plat-s5p will be used
> - moved SMDKC100 fixes to separate patch series
>
> Changes since v1:
> - bases on completely new clock code provided by Kukjin Kim
> - added some plat-s5p fixes required for transition
> - removed custom functions from gpiolib implementation (now uses common
> code from plat-samsung)
> - restructured the changes to avoid breaking the functionality beteen the
> patches
> - some other minor cleanups (mainly c1xx to c100 renames)
>
> This patch series includes:
>
> [PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
> [PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
> [PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
> [PATCH 04/11] ARM: S5PC100: gpio.h cleanup
> [PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
> [PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
> [PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
> [PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply [flat|nested] 669+ messages in thread
* your mail
@ 2010-05-19 2:24 ` Ben Dooks
0 siblings, 0 replies; 669+ messages in thread
From: Ben Dooks @ 2010-05-19 2:24 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 18, 2010 at 12:38:38PM +0200, Marek Szyprowski wrote:
> Hello,
Hi, messages are supposed to have subjects... please supply one next
timne.
> This patch series perform a general cleanup in Samsung S5PC100 SoC support.
> This chip is moved from custom s5pc1xx platform framework to new plat-s5p
> framework, so more common code can be easily reused in upcomming extensions
> for S5PV210/S5PC110 SoCs.
>
> This patch series is prepared against next-samsung tree, with assumption
> that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
> plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
> ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
>
> I've tried to split my changes as much as possible to clearly show how the
> transition from plat-s5pc1xx to plat-s5p is being done.
Ok, this seems to be a pretty good progression from one to the other.
I will chase up the EINT support, it got dropped from the first pull due
to your bug reports.
Will start sorting out a second round of branches with a view to trying to
get this into the current merge window. I hope to have something to test
by the end of today.
> Changes since v2:
> - fixed some whitespace/tabs errors
> - removed external interrupt code, a common code from plat-s5p will be used
> - moved SMDKC100 fixes to separate patch series
>
> Changes since v1:
> - bases on completely new clock code provided by Kukjin Kim
> - added some plat-s5p fixes required for transition
> - removed custom functions from gpiolib implementation (now uses common
> code from plat-samsung)
> - restructured the changes to avoid breaking the functionality beteen the
> patches
> - some other minor cleanups (mainly c1xx to c100 renames)
>
> This patch series includes:
>
> [PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
> [PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
> [PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
> [PATCH 04/11] ARM: S5PC100: gpio.h cleanup
> [PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
> [PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
> [PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
> [PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2010-05-14 21:39 Jiaying Zhang
2010-05-14 22:07 ` your mail tytso
0 siblings, 1 reply; 669+ messages in thread
From: Jiaying Zhang @ 2010-05-14 21:39 UTC (permalink / raw)
To: curtw, fmayhar, mrubin, tytso
Cc: [PATCH], fix, the, extent, validity, checking, in, e2fsck, linux-ext4
This patch changes e2fsck to use the same checking on the validity of an extent
as the kernel ext4 is using.
Signed-off-by: Jiaying Zhang <jiayingz@google.com>
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 3c6f91c..c5dc01a 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1690,8 +1690,8 @@ static void scan_extent_node(e2fsck_t ctx, struct problem_context *pctx,
is_dir = LINUX_S_ISDIR(pctx->inode->i_mode);
problem = 0;
- if (extent.e_pblk < ctx->fs->super->s_first_data_block ||
- extent.e_pblk >= ext2fs_blocks_count(ctx->fs->super))
+ if (extent.e_pblk <= ctx->fs->super->s_first_data_block ||
+ extent.e_pblk > ext2fs_blocks_count(ctx->fs->super))
problem = PR_1_EXTENT_BAD_START_BLK;
else if (extent.e_lblk < start_block)
problem = PR_1_OUT_OF_ORDER_EXTENTS;
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2010-05-14 21:39 (unknown) Jiaying Zhang
@ 2010-05-14 22:07 ` tytso
0 siblings, 0 replies; 669+ messages in thread
From: tytso @ 2010-05-14 22:07 UTC (permalink / raw)
To: Jiaying Zhang; +Cc: curtw, fmayhar, mrubin, linux-ext4
On Fri, May 14, 2010 at 02:39:45PM -0700, Jiaying Zhang wrote:
> This patch changes e2fsck to use the same checking on the validity
> of an extent as the kernel ext4 is using.
Actually, the better fix is to explicitly test for extent.e_blk == 0.
The kernel test works because at the moment nothing creates file
systems where s_first_data_block is anything other than 0 or 1. But
technically speaking, having an extent which begins at
s_first_data_block isn't actually _wrong_. It might overlap with fs
metadata, but pass1b will handle that. The reason why it doesn't in
the case of 0 is because 0 is a special case and also means "there's
no block present" when returned by ext2fs_block_iterate.
Arguably the kernel should be changed to something similar, but in
practice it won't make a difference in practice. E2fsck can do a
slightly better job recovering in the case of 1k block filesystems, so
this patch is slightly better.
- Ted
commit e6238d3708d328851bfdff7580d1b8504c7cf2e4
Author: Theodore Ts'o <tytso@mit.edu>
Date: Fri May 14 18:03:14 2010 -0400
e2fsck: Explicitly reject extents that begin at physical block 0 as illegal
In the case where s_first_data_block is 1, we need to explictly reject
an extent whose starting physical block is zero.
Thanks to Jiaying Zhang <jiayingz@google.com> for finding this bug.
Addresses-Google-Bug: #2573806
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 5e2ecc7..c35937f 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1694,7 +1694,8 @@ static void scan_extent_node(e2fsck_t ctx, struct problem_context *pctx,
is_dir = LINUX_S_ISDIR(pctx->inode->i_mode);
problem = 0;
- if (extent.e_pblk < ctx->fs->super->s_first_data_block ||
+ if (extent.e_pblk == 0 ||
+ extent.e_pblk < ctx->fs->super->s_first_data_block ||
extent.e_pblk >= ctx->fs->super->s_blocks_count)
problem = PR_1_EXTENT_BAD_START_BLK;
else if (extent.e_lblk < start_block)
^ permalink raw reply related [flat|nested] 669+ messages in thread
* (no subject)
@ 2010-04-14 12:54 Alan Cox
2010-04-14 23:16 ` your mail Dmitry Torokhov
0 siblings, 1 reply; 669+ messages in thread
From: Alan Cox @ 2010-04-14 12:54 UTC (permalink / raw)
To: linux-i2c, khali, linux-input, linux-kernel
Subject: [FOR COMMENT] cy8ctmg110 for review
From: Samuli Konttila <samuli.konttila@aavamobile.com>
Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
devices.
(Some clean up by Alan Cox)
(No signed off, not yet ready to go in)
---
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 3
drivers/input/touchscreen/cy8ctmg110_ts.c | 521 +++++++++++++++++++++++++++++
3 files changed, 535 insertions(+), 1 deletions(-)
create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index b3ba374..89a3eb1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
To compile this driver as a module, choose M here: the
module will be called tps6507x_ts.
+config TOUCHSCREEN_CY8CTMG110
+ tristate "cy8ctmg110 touchscreen"
+ depends on I2C
+ help
+ Say Y here if you have a cy8ctmg110 touchscreen capacitive
+ touchscreen
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cy8ctmg110_ts.
+
endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index dfb7239..c7acb65 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -1,5 +1,5 @@
#
-# Makefile for the touchscreen drivers.
+# Makefile for the touchscreen drivers.mororor
#
# Each configuration option enables a list of files.
@@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC) += atmel_tsadcc.o
obj-$(CONFIG_TOUCHSCREEN_BITSY) += h3600_ts_input.o
+obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
obj-$(CONFIG_TOUCHSCREEN_DYNAPRO) += dynapro.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE) += gunze.o
obj-$(CONFIG_TOUCHSCREEN_EETI) += eeti_ts.o
diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
new file mode 100644
index 0000000..4adbe87
--- /dev/null
+++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
@@ -0,0 +1,521 @@
+/*
+ * cy8ctmg110_ts.c Driver for cypress touch screen controller
+ * Copyright (c) 2009 Aava Mobile
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <asm/io.h>
+#include <linux/i2c.h>
+#include <linux/timer.h>
+#include <linux/gpio.h>
+#include <linux/hrtimer.h>
+
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <asm/ioctl.h>
+#include <asm/uaccess.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <asm/ioctl.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+
+#define CY8CTMG110_DRIVER_NAME "cy8ctmg110"
+
+
+/*HW definations*/
+#define CY8CTMG110_RESET_PIN_GPIO 43
+#define CY8CTMG110_IRQ_PIN_GPIO 59
+#define CY8CTMG110_I2C_ADDR 0x38
+#define CY8CTMG110_I2C_ADDR_EXT 0x39
+#define CY8CTMG110_I2C_ADDR_ 0x2 /*i2c address first sample */
+#define CY8CTMG110_I2C_ADDR__ 53 /*i2c address to FW where irq support missing */
+#define CY8CTMG110_TOUCH_IRQ 21
+#define CY8CTMG110_TOUCH_LENGHT 9787
+#define CY8CTMG110_SCREEN_LENGHT 8424
+
+
+/*Touch coordinates*/
+#define CY8CTMG110_X_MIN 0
+#define CY8CTMG110_Y_MIN 0
+#define CY8CTMG110_X_MAX 864
+#define CY8CTMG110_Y_MAX 480
+
+
+/*cy8ctmg110 registers defination*/
+#define CY8CTMG110_TOUCH_WAKEUP_TIME 0
+#define CY8CTMG110_TOUCH_SLEEP_TIME 2
+#define CY8CTMG110_TOUCH_X1 3
+#define CY8CTMG110_TOUCH_Y1 5
+#define CY8CTMG110_TOUCH_X2 7
+#define CY8CTMG110_TOUCH_Y2 9
+#define CY8CTMG110_FINGERS 11
+#define CY8CTMG110_GESTURE 12
+#define CY8CTMG110_REG_MAX 13
+
+#define CY8CTMG110_POLL_TIMER_DELAY 1000*1000*100
+#define TOUCH_MAX_I2C_FAILS 50
+
+/* Scale factors for coordinates */
+#define X_SCALE_FACTOR 9387/8424
+#define Y_SCALE_FACTOR 97/100
+
+/* For tracing */
+static int g_y_trace_coord = 0;
+module_param(g_y_trace_coord, int, 0600);
+
+/* Polling mode */
+static int polling = 0;
+module_param(polling, int, 0);
+MODULE_PARM_DESC(polling, "Set to enabling polling of the touchscreen");
+
+
+/*
+ * The touch position structure.
+ */
+struct ts_event {
+ int x1;
+ int y1;
+ int x2;
+ int y2;
+ bool event_sended;
+};
+
+/*
+ * The touch driver structure.
+ */
+struct cy8ctmg110 {
+ struct input_dev *input;
+ char phys[32];
+ struct ts_event tc;
+ struct i2c_client *client;
+ bool pending;
+ spinlock_t lock;
+ bool initController;
+ bool sleepmode;
+ int i2c_fail_count;
+ struct hrtimer timer;
+};
+
+/*
+ * cy8ctmg110_poweroff is the routine that is called when touch hardware
+ * will powered off
+ */
+static void cy8ctmg110_power(bool poweron)
+{
+ if (poweron)
+ gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 0);
+ else
+ gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 1);
+}
+
+/*
+ * cy8ctmg110_write_req write regs to the i2c devices
+ *
+ */
+static int cy8ctmg110_write_req(struct cy8ctmg110 *tsc, unsigned char reg,
+ unsigned char len, unsigned char *value)
+{
+ struct i2c_client *client = tsc->client;
+ unsigned int ret;
+ unsigned char i2c_data[] = { 0, 0, 0, 0, 0, 0 };
+ struct i2c_msg msg[] = {
+ {client->addr, 0, len + 1, i2c_data},
+ };
+
+ i2c_data[0] = reg;
+ memcpy(i2c_data + 1, value, len);
+
+ ret = i2c_transfer(client->adapter, msg, 1);
+ if (ret != 1) {
+ printk("cy8ctmg110 touch : i2c write data cmd failed \n");
+ return ret;
+ }
+ return 0;
+}
+
+/*
+ * cy8ctmg110_read_req read regs from i2c devise
+ *
+ */
+
+static int cy8ctmg110_read_req(struct cy8ctmg110 *tsc,
+ unsigned char *i2c_data, unsigned char len, unsigned char cmd)
+{
+ struct i2c_client *client = tsc->client;
+ unsigned int ret;
+ unsigned char regs_cmd[2] = { 0, 0 };
+ struct i2c_msg msg1[] = {
+ {client->addr, 0, 1, regs_cmd},
+ };
+ struct i2c_msg msg2[] = {
+ {client->addr, I2C_M_RD, len, i2c_data},
+ };
+
+ regs_cmd[0] = cmd;
+
+ /* first write slave position to i2c devices */
+ ret = i2c_transfer(client->adapter, msg1, 1);
+ if (ret != 1) {
+ tsc->i2c_fail_count++;
+ return ret;
+ }
+
+ /* Second read data from position */
+ ret = i2c_transfer(client->adapter, msg2, 1);
+ if (ret != 1) {
+ tsc->i2c_fail_count++;
+ return ret;
+ }
+ return 0;
+}
+
+/*
+ * cy8ctmg110_send_event delevery touch event to the userpace
+ * function use normal input interface
+ */
+static void cy8ctmg110_send_event(void *tsc)
+{
+ struct cy8ctmg110 *ts = tsc;
+ struct input_dev *input = ts->input;
+ u16 x, y;
+ u16 x2, y2;
+
+ x = ts->tc.x1;
+ y = ts->tc.y1;
+
+ if (ts->tc.event_sended == false) {
+ input_report_key(input, BTN_TOUCH, 1);
+ ts->pending = true;
+ x2 = (u16) (y * X_SCALE_FACTOR);
+ y2 = (u16) (x * Y_SCALE_FACTOR);
+ input_report_abs(input, ABS_X, x2);
+ input_report_abs(input, ABS_Y, y2);
+ input_sync(input);
+ if (g_y_trace_coord)
+ printk("cy8ctmg110 touch position X:%d (was = %d) Y:%d (was = %d)\n", x2, y, y2, x);
+ }
+
+}
+
+/*
+ * cy8ctmg110_touch_pos check touch position from i2c devices
+ *
+ */
+static int cy8ctmg110_touch_pos(struct cy8ctmg110 *tsc)
+{
+ unsigned char reg_p[CY8CTMG110_REG_MAX];
+ int x, y;
+
+ memset(reg_p, 0, CY8CTMG110_REG_MAX);
+
+ /*Reading coordinates */
+ if (cy8ctmg110_read_req(tsc, reg_p, 9, CY8CTMG110_TOUCH_X1) != 0)
+ return -EIO;
+
+ y = reg_p[2] << 8 | reg_p[3];
+ x = reg_p[0] << 8 | reg_p[1];
+ /*number of touch */
+ if (reg_p[8] == 0) {
+ if (tsc->pending == true) {
+ struct input_dev *input = tsc->input;
+
+ input_report_key(input, BTN_TOUCH, 0);
+ tsc->tc.event_sended = true;
+ tsc->pending = false;
+ }
+ } else if (tsc->tc.x1 != x || tsc->tc.y1 != y) {
+ tsc->tc.y1 = y;
+ tsc->tc.x1 = x;
+ tsc->tc.event_sended = false;
+ cy8ctmg110_send_event(tsc);
+ }
+ return 0;
+}
+
+/*
+ * if interrupt isn't in use the touch positions can reads by polling
+ *
+ */
+static enum hrtimer_restart cy8ctmg110_timer(struct hrtimer *handle)
+{
+ struct cy8ctmg110 *ts = container_of(handle, struct cy8ctmg110, timer);
+ unsigned long flags;
+
+ spin_lock_irqsave(&ts->lock, flags);
+
+ cy8ctmg110_touch_pos(ts);
+ if (ts->i2c_fail_count < TOUCH_MAX_I2C_FAILS)
+ hrtimer_start(&ts->timer, ktime_set(0, CY8CTMG110_POLL_TIMER_DELAY), HRTIMER_MODE_REL);
+
+ spin_unlock_irqrestore(&ts->lock, flags);
+ return HRTIMER_NORESTART;
+}
+
+/*
+ * cy8ctmg110_init_controller set init value to touchcontroller
+ *
+ */
+static bool cy8ctmg110_set_sleepmode(struct cy8ctmg110 *ts)
+{
+ unsigned char reg_p[3];
+
+ if (ts->sleepmode == true) {
+ reg_p[0] = 0x00;
+ reg_p[1] = 0xff;
+ reg_p[2] = 5;
+ } else {
+ reg_p[0] = 0x10;
+ reg_p[1] = 0xff;
+ reg_p[2] = 0;
+ }
+
+ if (cy8ctmg110_write_req(ts, CY8CTMG110_TOUCH_WAKEUP_TIME, 3, reg_p))
+ return false;
+
+ ts->initController = true;
+ return true;
+}
+
+/*
+ * cy8ctmg110_irq_handler irq handling function
+ *
+ */
+
+static irqreturn_t cy8ctmg110_irq_handler(int irq, void *dev_id)
+{
+ struct cy8ctmg110 *tsc = (struct cy8ctmg110 *) dev_id;
+
+ if (tsc->initController == false) {
+ if (cy8ctmg110_set_sleepmode(tsc) == true)
+ tsc->initController = true;
+ } else
+ cy8ctmg110_touch_pos(tsc);
+
+ /* if interrupt supported in the touch controller
+ timer polling need to stop */
+ tsc->i2c_fail_count = TOUCH_MAX_I2C_FAILS;
+ return IRQ_HANDLED;
+}
+
+
+static int cy8ctmg110_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct cy8ctmg110 *ts;
+ struct input_dev *input_dev;
+ int err;
+ client->irq = CY8CTMG110_TOUCH_IRQ;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_READ_WORD_DATA))
+ return -EIO;
+
+ ts = kzalloc(sizeof(struct cy8ctmg110), GFP_KERNEL);
+ input_dev = input_allocate_device();
+
+ if (!ts || !input_dev) {
+ err = -ENOMEM;
+ goto err_free_mem;
+ }
+
+ ts->client = client;
+ i2c_set_clientdata(client, ts);
+
+ ts->input = input_dev;
+ ts->pending = false;
+ ts->sleepmode = false;
+
+ snprintf(ts->phys, sizeof(ts->phys), "%s/input0",
+ dev_name(&client->dev));
+
+ input_dev->name = CY8CTMG110_DRIVER_NAME " Touchscreen";
+ input_dev->phys = ts->phys;
+ input_dev->id.bustype = BUS_I2C;
+
+ spin_lock_init(&ts->lock);
+
+ input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) |
+ BIT_MASK(EV_REL) | BIT_MASK(EV_ABS);
+ input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+ input_set_capability(input_dev, EV_KEY, KEY_F);
+
+ input_set_abs_params(input_dev, ABS_X, CY8CTMG110_X_MIN, CY8CTMG110_X_MAX, 0, 0);
+ input_set_abs_params(input_dev, ABS_Y, CY8CTMG110_Y_MIN, CY8CTMG110_Y_MAX, 0, 0);
+
+ err = gpio_request(CY8CTMG110_RESET_PIN_GPIO, NULL);
+
+ if (err) {
+ dev_err(&client->dev, "cy8ctmg110_ts: Unable to request GPIO pin %d.\n",
+ CY8CTMG110_RESET_PIN_GPIO);
+ goto err_free_irq;
+ }
+ cy8ctmg110_power(true);
+
+ ts->initController = false;
+ ts->i2c_fail_count = 0;
+
+ hrtimer_init(&ts->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ ts->timer.function = cy8ctmg110_timer;
+
+ if (polling)
+ hrtimer_start(&ts->timer, ktime_set(10, 0), HRTIMER_MODE_REL);
+
+ /* Can we fall back to polling if these bits fail - something to look
+ at for robustness */
+
+ err = gpio_request(CY8CTMG110_IRQ_PIN_GPIO, "touch_irq_key");
+ if (err < 0) {
+ dev_err(&client->dev,
+ "cy8ctmg110_ts: failed to request GPIO %d, error %d\n",
+ CY8CTMG110_IRQ_PIN_GPIO, err);
+ goto err_free_timer;
+ }
+
+ err = gpio_direction_input(CY8CTMG110_IRQ_PIN_GPIO);
+
+ if (err < 0) {
+ dev_err(&client->dev,
+ "cy8ctmg110_ts: failed to configure input direction for GPIO %d, error %d\n",
+ CY8CTMG110_IRQ_PIN_GPIO, err);
+ goto err_free_gpio;
+ }
+ client->irq = gpio_to_irq(CY8CTMG110_IRQ_PIN_GPIO);
+
+ if (client->irq < 0) {
+ err = client->irq;
+ dev_err(&client->dev,
+ "cy8ctmg110_ts: Unable to get irq number" " for GPIO %d, error %d\n",
+ CY8CTMG110_IRQ_PIN_GPIO, err);
+ goto err_free_gpio;
+ }
+ err = request_irq(client->irq, cy8ctmg110_irq_handler, IRQF_TRIGGER_RISING | IRQF_SHARED, "touch_reset_key", ts);
+ if (err < 0) {
+ dev_err(&client->dev,
+ "cy8ctmg110 irq %d busy? error %d\n",
+ client->irq, err);
+ goto err_free_gpio;
+ }
+
+ err = input_register_device(input_dev);
+ if (!err)
+ return 0;
+err_free_gpio:
+ gpio_free(CY8CTMG110_IRQ_PIN_GPIO);
+err_free_timer:
+ if (polling)
+ hrtimer_cancel(&ts->timer);
+err_free_irq:
+ free_irq(client->irq, ts);
+err_free_mem:
+ input_free_device(input_dev);
+ kfree(ts);
+ return err;
+}
+
+/*
+ * cy8ctmg110_suspend
+ *
+ */
+
+static int cy8ctmg110_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+ if (device_may_wakeup(&client->dev))
+ enable_irq_wake(client->irq);
+
+ return 0;
+}
+
+/*
+ * cy8ctmg110_resume
+ *
+ */
+
+static int cy8ctmg110_resume(struct i2c_client *client)
+{
+ if (device_may_wakeup(&client->dev))
+ disable_irq_wake(client->irq);
+
+ return 0;
+}
+
+/*
+ * cy8ctmg110_remove
+ *
+ */
+
+static int cy8ctmg110_remove(struct i2c_client *client)
+{
+ struct cy8ctmg110 *ts = i2c_get_clientdata(client);
+
+ cy8ctmg110_power(false);
+
+ if (polling)
+ hrtimer_cancel(&ts->timer);
+ free_irq(client->irq, ts);
+ input_unregister_device(ts->input);
+ /* FIXME: Do we need to free the GPIO ? */
+ kfree(ts);
+ return 0;
+}
+
+static struct i2c_device_id cy8ctmg110_idtable[] = {
+ {CY8CTMG110_DRIVER_NAME, 1},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, cy8ctmg110_idtable);
+
+static struct i2c_driver cy8ctmg110_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = CY8CTMG110_DRIVER_NAME,
+ .bus = &i2c_bus_type,
+ },
+ .id_table = cy8ctmg110_idtable,
+ .probe = cy8ctmg110_probe,
+ .remove = cy8ctmg110_remove,
+ .suspend = cy8ctmg110_suspend,
+ .resume = cy8ctmg110_resume,
+};
+
+static int __init cy8ctmg110_init(void)
+{
+ return i2c_add_driver(&cy8ctmg110_driver);
+}
+
+static void __exit cy8ctmg110_exit(void)
+{
+ i2c_del_driver(&cy8ctmg110_driver);
+}
+
+module_init(cy8ctmg110_init);
+module_exit(cy8ctmg110_exit);
+
+MODULE_AUTHOR("Samuli Konttila <samuli.konttila@aavamobile.com>");
+MODULE_DESCRIPTION("cy8ctmg110 TouchScreen Driver");
+MODULE_LICENSE("GPL v2");
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2010-04-14 12:54 Alan Cox
@ 2010-04-14 23:16 ` Dmitry Torokhov
2010-04-15 23:41 ` Rafi Rubin
0 siblings, 1 reply; 669+ messages in thread
From: Dmitry Torokhov @ 2010-04-14 23:16 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-i2c, khali, linux-input, linux-kernel
On Wed, Apr 14, 2010 at 01:54:02PM +0100, Alan Cox wrote:
> Subject: [FOR COMMENT] cy8ctmg110 for review
>
> From: Samuli Konttila <samuli.konttila@aavamobile.com>
>
> Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
> devices.
>
> (Some clean up by Alan Cox)
>
> (No signed off, not yet ready to go in)
> ---
>
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 3
> drivers/input/touchscreen/cy8ctmg110_ts.c | 521 +++++++++++++++++++++++++++++
> 3 files changed, 535 insertions(+), 1 deletions(-)
> create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c
>
>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index b3ba374..89a3eb1 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
> To compile this driver as a module, choose M here: the
> module will be called tps6507x_ts.
>
> +config TOUCHSCREEN_CY8CTMG110
> + tristate "cy8ctmg110 touchscreen"
> + depends on I2C
> + help
> + Say Y here if you have a cy8ctmg110 touchscreen capacitive
> + touchscreen
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cy8ctmg110_ts.
> +
> endif
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index dfb7239..c7acb65 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -1,5 +1,5 @@
> #
> -# Makefile for the touchscreen drivers.
> +# Makefile for the touchscreen drivers.mororor
> #
>
> # Each configuration option enables a list of files.
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
> obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
> obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC) += atmel_tsadcc.o
> obj-$(CONFIG_TOUCHSCREEN_BITSY) += h3600_ts_input.o
> +obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
> obj-$(CONFIG_TOUCHSCREEN_DYNAPRO) += dynapro.o
> obj-$(CONFIG_TOUCHSCREEN_GUNZE) += gunze.o
> obj-$(CONFIG_TOUCHSCREEN_EETI) += eeti_ts.o
> diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
> new file mode 100644
> index 0000000..4adbe87
> --- /dev/null
> +++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
> @@ -0,0 +1,521 @@
> +/*
> + * cy8ctmg110_ts.c Driver for cypress touch screen controller
> + * Copyright (c) 2009 Aava Mobile
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/input.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <asm/io.h>
> +#include <linux/i2c.h>
> +#include <linux/timer.h>
> +#include <linux/gpio.h>
> +#include <linux/hrtimer.h>
> +
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <asm/uaccess.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <linux/fs.h>
> +#include <linux/init.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +
> +#define CY8CTMG110_DRIVER_NAME "cy8ctmg110"
> +
> +
> +/*HW definations*/
> +#define CY8CTMG110_RESET_PIN_GPIO 43
> +#define CY8CTMG110_IRQ_PIN_GPIO 59
> +#define CY8CTMG110_I2C_ADDR 0x38
> +#define CY8CTMG110_I2C_ADDR_EXT 0x39
> +#define CY8CTMG110_I2C_ADDR_ 0x2 /*i2c address first sample */
> +#define CY8CTMG110_I2C_ADDR__ 53 /*i2c address to FW where irq support missing */
> +#define CY8CTMG110_TOUCH_IRQ 21
> +#define CY8CTMG110_TOUCH_LENGHT 9787
> +#define CY8CTMG110_SCREEN_LENGHT 8424
> +
> +
> +/*Touch coordinates*/
> +#define CY8CTMG110_X_MIN 0
> +#define CY8CTMG110_Y_MIN 0
> +#define CY8CTMG110_X_MAX 864
> +#define CY8CTMG110_Y_MAX 480
> +
> +
> +/*cy8ctmg110 registers defination*/
> +#define CY8CTMG110_TOUCH_WAKEUP_TIME 0
> +#define CY8CTMG110_TOUCH_SLEEP_TIME 2
> +#define CY8CTMG110_TOUCH_X1 3
> +#define CY8CTMG110_TOUCH_Y1 5
> +#define CY8CTMG110_TOUCH_X2 7
> +#define CY8CTMG110_TOUCH_Y2 9
> +#define CY8CTMG110_FINGERS 11
> +#define CY8CTMG110_GESTURE 12
> +#define CY8CTMG110_REG_MAX 13
> +
> +#define CY8CTMG110_POLL_TIMER_DELAY 1000*1000*100
> +#define TOUCH_MAX_I2C_FAILS 50
> +
> +/* Scale factors for coordinates */
> +#define X_SCALE_FACTOR 9387/8424
> +#define Y_SCALE_FACTOR 97/100
> +
> +/* For tracing */
> +static int g_y_trace_coord = 0;
> +module_param(g_y_trace_coord, int, 0600);
> +
> +/* Polling mode */
> +static int polling = 0;
> +module_param(polling, int, 0);
> +MODULE_PARM_DESC(polling, "Set to enabling polling of the touchscreen");
> +
> +
> +/*
> + * The touch position structure.
> + */
> +struct ts_event {
> + int x1;
> + int y1;
> + int x2;
> + int y2;
> + bool event_sended;
> +};
> +
> +/*
> + * The touch driver structure.
> + */
> +struct cy8ctmg110 {
> + struct input_dev *input;
> + char phys[32];
> + struct ts_event tc;
> + struct i2c_client *client;
> + bool pending;
> + spinlock_t lock;
> + bool initController;
> + bool sleepmode;
> + int i2c_fail_count;
> + struct hrtimer timer;
> +};
> +
> +/*
> + * cy8ctmg110_poweroff is the routine that is called when touch hardware
> + * will powered off
> + */
> +static void cy8ctmg110_power(bool poweron)
> +{
> + if (poweron)
> + gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 0);
> + else
> + gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 1);
> +}
> +
> +/*
> + * cy8ctmg110_write_req write regs to the i2c devices
> + *
> + */
> +static int cy8ctmg110_write_req(struct cy8ctmg110 *tsc, unsigned char reg,
> + unsigned char len, unsigned char *value)
> +{
> + struct i2c_client *client = tsc->client;
> + unsigned int ret;
> + unsigned char i2c_data[] = { 0, 0, 0, 0, 0, 0 };
> + struct i2c_msg msg[] = {
> + {client->addr, 0, len + 1, i2c_data},
> + };
> +
> + i2c_data[0] = reg;
> + memcpy(i2c_data + 1, value, len);
> +
> + ret = i2c_transfer(client->adapter, msg, 1);
> + if (ret != 1) {
> + printk("cy8ctmg110 touch : i2c write data cmd failed \n");
> + return ret;
> + }
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_read_req read regs from i2c devise
> + *
> + */
> +
> +static int cy8ctmg110_read_req(struct cy8ctmg110 *tsc,
> + unsigned char *i2c_data, unsigned char len, unsigned char cmd)
> +{
> + struct i2c_client *client = tsc->client;
> + unsigned int ret;
> + unsigned char regs_cmd[2] = { 0, 0 };
> + struct i2c_msg msg1[] = {
> + {client->addr, 0, 1, regs_cmd},
> + };
> + struct i2c_msg msg2[] = {
> + {client->addr, I2C_M_RD, len, i2c_data},
> + };
> +
> + regs_cmd[0] = cmd;
> +
> + /* first write slave position to i2c devices */
> + ret = i2c_transfer(client->adapter, msg1, 1);
> + if (ret != 1) {
> + tsc->i2c_fail_count++;
> + return ret;
> + }
> +
> + /* Second read data from position */
> + ret = i2c_transfer(client->adapter, msg2, 1);
> + if (ret != 1) {
> + tsc->i2c_fail_count++;
> + return ret;
> + }
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_send_event delevery touch event to the userpace
> + * function use normal input interface
> + */
> +static void cy8ctmg110_send_event(void *tsc)
> +{
> + struct cy8ctmg110 *ts = tsc;
> + struct input_dev *input = ts->input;
> + u16 x, y;
> + u16 x2, y2;
> +
> + x = ts->tc.x1;
> + y = ts->tc.y1;
> +
> + if (ts->tc.event_sended == false) {
We set "event_sended" to false immediately before calling
cy8ctmg110_send_event() so I do not see the point of this flag.
> + input_report_key(input, BTN_TOUCH, 1);
> + ts->pending = true;
> + x2 = (u16) (y * X_SCALE_FACTOR);
> + y2 = (u16) (x * Y_SCALE_FACTOR);
> + input_report_abs(input, ABS_X, x2);
> + input_report_abs(input, ABS_Y, y2);
> + input_sync(input);
> + if (g_y_trace_coord)
> + printk("cy8ctmg110 touch position X:%d (was = %d) Y:%d (was = %d)\n", x2, y, y2, x);
Do we really need this? Seems to be early development diagnostic.
> + }
> +
> +}
> +
> +/*
> + * cy8ctmg110_touch_pos check touch position from i2c devices
> + *
> + */
> +static int cy8ctmg110_touch_pos(struct cy8ctmg110 *tsc)
> +{
> + unsigned char reg_p[CY8CTMG110_REG_MAX];
> + int x, y;
> +
> + memset(reg_p, 0, CY8CTMG110_REG_MAX);
> +
> + /*Reading coordinates */
> + if (cy8ctmg110_read_req(tsc, reg_p, 9, CY8CTMG110_TOUCH_X1) != 0)
> + return -EIO;
> +
> + y = reg_p[2] << 8 | reg_p[3];
> + x = reg_p[0] << 8 | reg_p[1];
> + /*number of touch */
> + if (reg_p[8] == 0) {
> + if (tsc->pending == true) {
> + struct input_dev *input = tsc->input;
> +
> + input_report_key(input, BTN_TOUCH, 0);
> + tsc->tc.event_sended = true;
> + tsc->pending = false;
> + }
Just do input_report_key(input, BTN_TOUCH, 0); and let input core take
care of filtering duplicates. This will allow you get rid of bunch of
flags. Also input_sync() is missing here.
> + } else if (tsc->tc.x1 != x || tsc->tc.y1 != y) {
> + tsc->tc.y1 = y;
> + tsc->tc.x1 = x;
> + tsc->tc.event_sended = false;
> + cy8ctmg110_send_event(tsc);
> + }
> + return 0;
> +}
> +
> +/*
> + * if interrupt isn't in use the touch positions can reads by polling
> + *
> + */
> +static enum hrtimer_restart cy8ctmg110_timer(struct hrtimer *handle)
> +{
> + struct cy8ctmg110 *ts = container_of(handle, struct cy8ctmg110, timer);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ts->lock, flags);
> +
> + cy8ctmg110_touch_pos(ts);
> + if (ts->i2c_fail_count < TOUCH_MAX_I2C_FAILS)
> + hrtimer_start(&ts->timer, ktime_set(0, CY8CTMG110_POLL_TIMER_DELAY), HRTIMER_MODE_REL);
> +
So device simply dies after so many errors?
> + spin_unlock_irqrestore(&ts->lock, flags);
The timer handler is the only user for the spinlock, what is the point?
> + return HRTIMER_NORESTART;
> +}
> +
> +/*
> + *
> + */
> +static bool cy8ctmg110_set_sleepmode(struct cy8ctmg110 *ts)
> +{
> + unsigned char reg_p[3];
> +
> + if (ts->sleepmode == true) {
> + reg_p[0] = 0x00;
> + reg_p[1] = 0xff;
> + reg_p[2] = 5;
> + } else {
> + reg_p[0] = 0x10;
> + reg_p[1] = 0xff;
> + reg_p[2] = 0;
> + }
> +
> + if (cy8ctmg110_write_req(ts, CY8CTMG110_TOUCH_WAKEUP_TIME, 3, reg_p))
> + return false;
> +
> + ts->initController = true;
> + return true;
> +}
> +
> +/*
> + * cy8ctmg110_irq_handler irq handling function
> + *
> + */
> +
> +static irqreturn_t cy8ctmg110_irq_handler(int irq, void *dev_id)
> +{
> + struct cy8ctmg110 *tsc = (struct cy8ctmg110 *) dev_id;
> +
> + if (tsc->initController == false) {
> + if (cy8ctmg110_set_sleepmode(tsc) == true)
> + tsc->initController = true;
> + } else
> + cy8ctmg110_touch_pos(tsc);
Initalizing device from interrupt handler is quite novel concept...
> +
> + /* if interrupt supported in the touch controller
> + timer polling need to stop */
> + tsc->i2c_fail_count = TOUCH_MAX_I2C_FAILS;
> + return IRQ_HANDLED;
> +}
> +
> +
> +static int cy8ctmg110_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> + struct cy8ctmg110 *ts;
> + struct input_dev *input_dev;
> + int err;
> + client->irq = CY8CTMG110_TOUCH_IRQ;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_READ_WORD_DATA))
> + return -EIO;
> +
> + ts = kzalloc(sizeof(struct cy8ctmg110), GFP_KERNEL);
> + input_dev = input_allocate_device();
> +
> + if (!ts || !input_dev) {
> + err = -ENOMEM;
> + goto err_free_mem;
> + }
> +
> + ts->client = client;
> + i2c_set_clientdata(client, ts);
> +
> + ts->input = input_dev;
> + ts->pending = false;
> + ts->sleepmode = false;
> +
> + snprintf(ts->phys, sizeof(ts->phys), "%s/input0",
> + dev_name(&client->dev));
> +
> + input_dev->name = CY8CTMG110_DRIVER_NAME " Touchscreen";
> + input_dev->phys = ts->phys;
> + input_dev->id.bustype = BUS_I2C;
> +
> + spin_lock_init(&ts->lock);
> +
> + input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) |
You usually do not set up autorepeat for pointingt devices.
> + BIT_MASK(EV_REL) | BIT_MASK(EV_ABS);
The device does not emit relative events.
> + input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> +
> + input_set_capability(input_dev, EV_KEY, KEY_F);
KEY_F?
> +
> + input_set_abs_params(input_dev, ABS_X, CY8CTMG110_X_MIN, CY8CTMG110_X_MAX, 0, 0);
> + input_set_abs_params(input_dev, ABS_Y, CY8CTMG110_Y_MIN, CY8CTMG110_Y_MAX, 0, 0);
> +
> + err = gpio_request(CY8CTMG110_RESET_PIN_GPIO, NULL);
> +
> + if (err) {
> + dev_err(&client->dev, "cy8ctmg110_ts: Unable to request GPIO pin %d.\n",
> + CY8CTMG110_RESET_PIN_GPIO);
> + goto err_free_irq;
> + }
> + cy8ctmg110_power(true);
> +
> + ts->initController = false;
> + ts->i2c_fail_count = 0;
> +
> + hrtimer_init(&ts->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + ts->timer.function = cy8ctmg110_timer;
> +
> + if (polling)
> + hrtimer_start(&ts->timer, ktime_set(10, 0), HRTIMER_MODE_REL);
> +
Polling mode shoudl be controlled by platform data, not kernel module I think.
> + /* Can we fall back to polling if these bits fail - something to look
> + at for robustness */
> +
> + err = gpio_request(CY8CTMG110_IRQ_PIN_GPIO, "touch_irq_key");
> + if (err < 0) {
> + dev_err(&client->dev,
> + "cy8ctmg110_ts: failed to request GPIO %d, error %d\n",
> + CY8CTMG110_IRQ_PIN_GPIO, err);
> + goto err_free_timer;
> + }
> +
> + err = gpio_direction_input(CY8CTMG110_IRQ_PIN_GPIO);
> +
> + if (err < 0) {
> + dev_err(&client->dev,
> + "cy8ctmg110_ts: failed to configure input direction for GPIO %d, error %d\n",
> + CY8CTMG110_IRQ_PIN_GPIO, err);
> + goto err_free_gpio;
> + }
> + client->irq = gpio_to_irq(CY8CTMG110_IRQ_PIN_GPIO);
> +
> + if (client->irq < 0) {
> + err = client->irq;
> + dev_err(&client->dev,
> + "cy8ctmg110_ts: Unable to get irq number" " for GPIO %d, error %d\n",
> + CY8CTMG110_IRQ_PIN_GPIO, err);
> + goto err_free_gpio;
> + }
> + err = request_irq(client->irq, cy8ctmg110_irq_handler, IRQF_TRIGGER_RISING | IRQF_SHARED, "touch_reset_key", ts);
> + if (err < 0) {
> + dev_err(&client->dev,
> + "cy8ctmg110 irq %d busy? error %d\n",
> + client->irq, err);
> + goto err_free_gpio;
> + }
> +
> + err = input_register_device(input_dev);
> + if (!err)
> + return 0;
> +err_free_gpio:
> + gpio_free(CY8CTMG110_IRQ_PIN_GPIO);
> +err_free_timer:
> + if (polling)
> + hrtimer_cancel(&ts->timer);
> +err_free_irq:
> + free_irq(client->irq, ts);
> +err_free_mem:
> + input_free_device(input_dev);
> + kfree(ts);
> + return err;
> +}
> +
> +/*
> + * cy8ctmg110_suspend
> + *
> + */
> +
> +static int cy8ctmg110_suspend(struct i2c_client *client, pm_message_t mesg)
> +{
Stop timer here? Also power down the device?
> + if (device_may_wakeup(&client->dev))
> + enable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_resume
> + *
> + */
> +
> +static int cy8ctmg110_resume(struct i2c_client *client)
> +{
> + if (device_may_wakeup(&client->dev))
> + disable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_remove
> + *
> + */
> +
> +static int cy8ctmg110_remove(struct i2c_client *client)
> +{
> + struct cy8ctmg110 *ts = i2c_get_clientdata(client);
> +
> + cy8ctmg110_power(false);
> +
> + if (polling)
> + hrtimer_cancel(&ts->timer);
Implement close() method and move the code above there? Also do open().
> + free_irq(client->irq, ts);
> + input_unregister_device(ts->input);
> + /* FIXME: Do we need to free the GPIO ? */
> + kfree(ts);
> + return 0;
> +}
> +
> +static struct i2c_device_id cy8ctmg110_idtable[] = {
> + {CY8CTMG110_DRIVER_NAME, 1},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, cy8ctmg110_idtable);
> +
> +static struct i2c_driver cy8ctmg110_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = CY8CTMG110_DRIVER_NAME,
> + .bus = &i2c_bus_type,
> + },
> + .id_table = cy8ctmg110_idtable,
> + .probe = cy8ctmg110_probe,
> + .remove = cy8ctmg110_remove,
> + .suspend = cy8ctmg110_suspend,
> + .resume = cy8ctmg110_resume,
> +};
> +
> +static int __init cy8ctmg110_init(void)
> +{
> + return i2c_add_driver(&cy8ctmg110_driver);
> +}
> +
> +static void __exit cy8ctmg110_exit(void)
> +{
> + i2c_del_driver(&cy8ctmg110_driver);
> +}
> +
> +module_init(cy8ctmg110_init);
> +module_exit(cy8ctmg110_exit);
> +
> +MODULE_AUTHOR("Samuli Konttila <samuli.konttila@aavamobile.com>");
> +MODULE_DESCRIPTION("cy8ctmg110 TouchScreen Driver");
> +MODULE_LICENSE("GPL v2");
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dmitry
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2010-04-14 23:16 ` your mail Dmitry Torokhov
@ 2010-04-15 23:41 ` Rafi Rubin
2010-04-16 4:21 ` Dmitry Torokhov
0 siblings, 1 reply; 669+ messages in thread
From: Rafi Rubin @ 2010-04-15 23:41 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Alan Cox, linux-i2c, khali, linux-input, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> + if (ts->tc.event_sended == false) {
>
> We set "event_sended" to false immediately before calling
> cy8ctmg110_send_event() so I do not see the point of this flag.
On that note:
$ git grep -n sended
drivers/net/eth16i.c:1295:
how many packets there is to be sended */
drivers/net/wan/sbni.c:638:
/* if frame was sended but not ACK'ed - resend it */
drivers/net/wan/sbni.c:659:
* frame sended then in prepare_to_send next frame
drivers/usb/serial/aircable.c:13:
* next two bytes must say how much data will be sended.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvHpB4ACgkQwuRiAT9o609wAgCfbGjTP2lIN6JJyX28VzjPHxTY
ylIAn15FZRPpBEkWaFR8oAFKCCRmNF4d
=u4nx
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2010-04-15 23:41 ` Rafi Rubin
@ 2010-04-16 4:21 ` Dmitry Torokhov
0 siblings, 0 replies; 669+ messages in thread
From: Dmitry Torokhov @ 2010-04-16 4:21 UTC (permalink / raw)
To: Rafi Rubin; +Cc: Alan Cox, linux-i2c, khali, linux-input, linux-kernel
On Thu, Apr 15, 2010 at 07:41:22PM -0400, Rafi Rubin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >> + if (ts->tc.event_sended == false) {
> >
> > We set "event_sended" to false immediately before calling
> > cy8ctmg110_send_event() so I do not see the point of this flag.
>
> On that note:
>
> $ git grep -n sended
> drivers/net/eth16i.c:1295:
> how many packets there is to be sended */
> drivers/net/wan/sbni.c:638:
> /* if frame was sended but not ACK'ed - resend it */
> drivers/net/wan/sbni.c:659:
> * frame sended then in prepare_to_send next frame
> drivers/usb/serial/aircable.c:13:
> * next two bytes must say how much data will be sended.
>
Well, if you want to go down that path...
[dtor@hammer work]$ grep -r -e "\(setted\|setuped\|split\+ed\)" . | wc -l
54
[dtor@hammer work]$
--
Dmitry
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2010-02-15 22:58 Serge Hallyn
[not found] ` <1266274696-23018-1-git-send-email-serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 669+ messages in thread
From: Serge Hallyn @ 2010-02-15 22:58 UTC (permalink / raw)
To: containers-qjLDD68F18O7TbgM5vRIOg
We've currently got ns_exec both in user-cr and cr_tests. Let's
give the user-cr version all features of the cr_tests one, and
get rid of the cr_tests one.
I'm also renaming it nsexec bc nsexecwp is stupid and ns_exec is
annoying, whereas nsexec lets you type 'nse<tab>'.
^ permalink raw reply [flat|nested] 669+ messages in thread[parent not found: <20100113004939.289333186@suse.com>]
* Re: your mail
[not found] <20100113004939.289333186@suse.com>
@ 2010-01-13 14:57 ` scameron
0 siblings, 0 replies; 669+ messages in thread
From: scameron @ 2010-01-13 14:57 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: Linux Kernel Mailing List, Andrew Morton, Linux SCSI
On Tue, Jan 12, 2010 at 07:49:00PM -0500, Jeff Mahoney wrote:
> Subject: [patch 5/6] hpsa: Fix section mismatch
> References: <20100113004855.550486769@suse.com>
> Content-Disposition: inline; filename=patches.rpmify/hpsa-fix-section-mismatch
>
> hpsa_pci_init calls hpsa_interrupt_mode which is a __devinit function.
> hpsa_pci_init is only called by hpsa_init_one which is also __devinit, so
> mark it __devinit as well.
>
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> ---
> drivers/scsi/hpsa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -3111,7 +3111,7 @@ default_int_mode:
> return;
> }
>
> -static int hpsa_pci_init(struct ctlr_info *h, struct pci_dev *pdev)
> +static int __devinit hpsa_pci_init(struct ctlr_info *h, struct pci_dev *pdev)
> {
> ushort subsystem_vendor_id, subsystem_device_id, command;
> __u32 board_id, scratchpad = 0;
>
Thanks.
-- steve
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <1250258343-14203-1-git-send-email-thierry.reding@avionic-design.de>]
* your mail
[not found] <1250258343-14203-1-git-send-email-thierry.reding@avionic-design.de>
@ 2009-10-02 14:53 ` Thierry Reding
2010-01-02 12:06 ` Russell King - ARM Linux
0 siblings, 1 reply; 669+ messages in thread
From: Thierry Reding @ 2009-10-02 14:53 UTC (permalink / raw)
To: linux-arm-kernel
* Thierry Reding wrote:
> So it's been quite a while since I last posted this series and there have been
> a number of changes.
>
> Support for T-Pid analog variants is dropped and will be handled in user-space
> instead. There hardware does not differ from the standard T-Pid. This gets rid
> of some ugly platform-specific #ifdefs.
>
> Front-panel controls are now handled in a separate driver, adx-keypad. That
> way backlight control can be moved to userspace.
>
> This series also adds a watchdog driver that can be used on all Avionic Design
> Xanthos-based boards.
Russell,
with the watchdog and backlight drivers out of the way, would you like me to
get any of the other drivers (fb, keypad) in via seperate trees or can they go
in through the ARM tree?
Do the remaining patches need additional work or can I go ahead and submit
them to the patch system? Or do you prefer some other way to get them into
your tree?
Thierry
^ permalink raw reply [flat|nested] 669+ messages in thread* your mail
2009-10-02 14:53 ` Thierry Reding
@ 2010-01-02 12:06 ` Russell King - ARM Linux
0 siblings, 0 replies; 669+ messages in thread
From: Russell King - ARM Linux @ 2010-01-02 12:06 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 02, 2009 at 04:53:15PM +0200, Thierry Reding wrote:
> * Thierry Reding wrote:
> > So it's been quite a while since I last posted this series and there have been
> > a number of changes.
> >
> > Support for T-Pid analog variants is dropped and will be handled in user-space
> > instead. There hardware does not differ from the standard T-Pid. This gets rid
> > of some ugly platform-specific #ifdefs.
> >
> > Front-panel controls are now handled in a separate driver, adx-keypad. That
> > way backlight control can be moved to userspace.
> >
> > This series also adds a watchdog driver that can be used on all Avionic Design
> > Xanthos-based boards.
>
> Russell,
>
> with the watchdog and backlight drivers out of the way, would you like me to
> get any of the other drivers (fb, keypad) in via seperate trees or can they go
> in through the ARM tree?
They should go in via the relevant driver trees.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Your Mail
@ 2009-08-10 16:47 Brown.K
0 siblings, 0 replies; 669+ messages in thread
From: Brown.K @ 2009-08-10 16:47 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Its a pleasure to be in contact with you today. I wish to let you know that I have a client who wants to invest in your country. We will eventually fly into your country to visit you.
I will give you more details and how much he wishes to invest, if you will assure us that you will be a reliable Investor, If you can handle this Investment Procurement in your country , please provide your response to discuss more and I will study your Feasibility appraisal because this is a genuine business we need to establish in your country.
You have to be diligent,honest and be focused to do business and posses managerial abilities. Note that a fully signed and stamped Memorandum of Understanding will be initiated in this business venture to aid in guiding both parties & commitments in this transaction.
Kindly send me the below information for my perusal:
1. Your Complete Full Names 2. Your Residential Address 3. Your age and Occupation 4. Your Phone and Fax Numbers for Easy and Faster Communication.
[For your information: FRAUDULENT OR DUBIOUS ELEMENTS ARE NOT ALLOWED!!]
Thanks for your anticipated cooperation. Have a nice day while i wait for your answer now.
Sir Kelly Brown
------------------------
Doing Good Business Brings Good Money: B & K Consultants.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2009-07-23 5:38 Haneef Syed
2009-07-23 5:50 ` your mail Gleb Natapov
0 siblings, 1 reply; 669+ messages in thread
From: Haneef Syed @ 2009-07-23 5:38 UTC (permalink / raw)
To: kvm
HI All,
I have taken kvm-22 with linux-2.6.24 kernel but when ever i install guest
through qemu bins, system hangs.
In dmesg it prints as "Unable to handle NULL derefrencing pointer".
Please suggest me why it is behaving like this
______________________________________________________________________
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2009-07-23 5:38 (unknown), Haneef Syed
@ 2009-07-23 5:50 ` Gleb Natapov
2009-07-23 6:09 ` Haneef Syed
0 siblings, 1 reply; 669+ messages in thread
From: Gleb Natapov @ 2009-07-23 5:50 UTC (permalink / raw)
To: Haneef Syed; +Cc: kvm
On Thu, Jul 23, 2009 at 11:08:41AM +0530, Haneef Syed wrote:
> HI All,
>
> I have taken kvm-22 with linux-2.6.24 kernel but when ever i install guest
> through qemu bins, system hangs.
>
> In dmesg it prints as "Unable to handle NULL derefrencing pointer".
>
> Please suggest me why it is behaving like this
>
I would suggest you to use more recent KVM. The latest one is kvm-88.
There were a couple of bug fixes and enhancements in those 66 version.
--
Gleb.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2009-06-17 16:08 Koffi Nogbe
2009-06-17 16:14 ` your mail Matthew Wilcox
0 siblings, 1 reply; 669+ messages in thread
From: Koffi Nogbe @ 2009-06-17 16:08 UTC (permalink / raw)
To: linux-scsi
How can I modify the kernel to be able to create unlimited partition
on a single drive. The reason for the question is I want to use one of
my box as a storage server for fast access to the be able to create my
RAID across all drives all the time so I want to slice the drives into
multiple 2GB partition and used that in the RAID then use LVM to put
it together. With SCSI drive I m stock with 15 partitions and with IDE
20. Any help is appreciated.
end
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2009-06-17 16:08 (unknown), Koffi Nogbe
@ 2009-06-17 16:14 ` Matthew Wilcox
0 siblings, 0 replies; 669+ messages in thread
From: Matthew Wilcox @ 2009-06-17 16:14 UTC (permalink / raw)
To: Koffi Nogbe; +Cc: linux-scsi
On Wed, Jun 17, 2009 at 12:08:03PM -0400, Koffi Nogbe wrote:
> How can I modify the kernel to be able to create unlimited partition
> on a single drive.
You can't in any sensible way.
> The reason for the question is I want to use one of
> my box as a storage server for fast access to the be able to create my
> RAID across all drives all the time so I want to slice the drives into
> multiple 2GB partition and used that in the RAID then use LVM to put
> it together. With SCSI drive I m stock with 15 partitions and with IDE
> 20. Any help is appreciated.
Sounds like you want to use LVM to create lots of PEs, then tie them
together into RAIDs. http://tldp.org/HOWTO/LVM-HOWTO/tyingittogether.html
may be helpful.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
@ 2009-05-06 23:53 Oleg Nesterov
2009-05-07 0:21 ` Roland McGrath
0 siblings, 1 reply; 669+ messages in thread
From: Oleg Nesterov @ 2009-05-06 23:53 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Chris Wright, Roland McGrath, linux-kernel
On 05/06, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > + task_lock(task);
> > retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
> > + task_unlock(task);
> > if (retval)
> > - goto bad;
> > + goto unlock_creds;
>
> Hm, that's a bit ugly - why dont you reuse ptrace_may_access(),
> which does much of this already?
Indeed, even the changelog mentions this.
I was going to cleanup this later. Because I think that
__ptrace_may_access() should die. It has only one caller, mm_for_maps().
I will re-check, but it looks a bit strange. More precisely, I just
can't understand it. Why we can't just do
struct mm_struct *mm_for_maps(struct task_struct *task)
{
struct mm_struct *mm = get_task_mm(task);
if (mm && mm != current->mm && !ptrace_may_access()) {
mmput(mm);
mm = NULL;
}
return mm;
}
? We do not care if this task exits and clears ->mm right before
or after ptrace_may_access(), and this is possible eith the current
code too once it drops tasklist.
Oleg.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-06 23:53 [RFC PATCH 3/3a] ptrace: add _ptrace_may_access() Oleg Nesterov
@ 2009-05-07 0:21 ` Roland McGrath
2009-05-07 6:36 ` Oleg Nesterov
0 siblings, 1 reply; 669+ messages in thread
From: Roland McGrath @ 2009-05-07 0:21 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Ingo Molnar, Andrew Morton, Chris Wright, linux-kernel, Al Viro
> I was going to cleanup this later. Because I think that
> __ptrace_may_access() should die. It has only one caller, mm_for_maps().
CC'ing Al Viro, who wrote mm_for_maps() (and no one has touched it since,
see commit 831830b).
> I will re-check, but it looks a bit strange. More precisely, I just
> can't understand it. Why we can't just do
>
> struct mm_struct *mm_for_maps(struct task_struct *task)
> {
> struct mm_struct *mm = get_task_mm(task);
>
> if (mm && mm != current->mm && !ptrace_may_access()) {
> mmput(mm);
> mm = NULL;
> }
>
> return mm;
> }
That seems fine to me. I suspect the old code just predated the PF_KTHREAD
check in get_task_mm() and excluding the borrowed-mm window races was the
only reason for using task_lock() that way.
> ? We do not care if this task exits and clears ->mm right before
> or after ptrace_may_access(), and this is possible eith the current
> code too once it drops tasklist.
I agree.
Thanks,
Roland
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 0:21 ` Roland McGrath
@ 2009-05-07 6:36 ` Oleg Nesterov
2009-05-07 8:20 ` Ingo Molnar
0 siblings, 1 reply; 669+ messages in thread
From: Oleg Nesterov @ 2009-05-07 6:36 UTC (permalink / raw)
To: Roland McGrath
Cc: Ingo Molnar, Andrew Morton, Chris Wright, linux-kernel, Al Viro
On 05/06, Roland McGrath wrote:
>
> > I was going to cleanup this later. Because I think that
> > __ptrace_may_access() should die. It has only one caller, mm_for_maps().
>
> CC'ing Al Viro, who wrote mm_for_maps() (and no one has touched it since,
> see commit 831830b).
>
> > I will re-check, but it looks a bit strange. More precisely, I just
> > can't understand it. Why we can't just do
> >
> > struct mm_struct *mm_for_maps(struct task_struct *task)
> > {
> > struct mm_struct *mm = get_task_mm(task);
> >
> > if (mm && mm != current->mm && !ptrace_may_access()) {
> > mmput(mm);
> > mm = NULL;
> > }
> >
> > return mm;
> > }
>
> That seems fine to me. I suspect the old code just predated the PF_KTHREAD
> check in get_task_mm() and excluding the borrowed-mm window races was the
> only reason for using task_lock() that way.
>
> > ? We do not care if this task exits and clears ->mm right before
> > or after ptrace_may_access(), and this is possible eith the current
> > code too once it drops tasklist.
>
> I agree.
Great. Will try to make the patches soon.
And I forgot to mention, there is another reason to kill __ptrace_may_access.
Because we can "narrow" the critical section protected by task_lock(). Not
for performance of course, just for clarity:
/* the callers of ptrace_may_access should be fixed */
int ptrace_may_access(struct task_struct *task, unsigned int mode)
{
const struct cred *cred = current_cred(), *tcred;
int ret = 0;
/* May we inspect the given task?
* This check is used both for attaching with ptrace
* and for allowing access to sensitive information in /proc.
*
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
*/
/* Don't let security modules deny introspection */
if (task == current)
return ret;
rcu_read_lock();
tcred = __task_cred(task);
if ((cred->uid != tcred->euid ||
cred->uid != tcred->suid ||
cred->uid != tcred->uid ||
cred->gid != tcred->egid ||
cred->gid != tcred->sgid ||
cred->gid != tcred->gid) &&
!capable(CAP_SYS_PTRACE))
ret = -EPERM;
rcu_read_unlock();
if (ret)
return ret;
/* kill rmb ? */
task_lock(task);
if (!task->mm || !get_dumpable(task->mm)) {
if (!capable(CAP_SYS_PTRACE))
ret = -EPERM;
task_unclock(task);
if (ret)
return ret;
return security_ptrace_may_access(task, mode);
}
Btw, "[PATCH 3/3]" notes that security_ptrace_may_access() is called without
task_lock(), this note "leaked" from this change in future ;)
But firsty I'll try to grep/recheck this all.
Oleg.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 6:36 ` Oleg Nesterov
@ 2009-05-07 8:20 ` Ingo Molnar
2009-05-07 8:31 ` Oleg Nesterov
0 siblings, 1 reply; 669+ messages in thread
From: Ingo Molnar @ 2009-05-07 8:20 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Roland McGrath, Andrew Morton, Chris Wright, linux-kernel, Al Viro
* Oleg Nesterov <oleg@redhat.com> wrote:
> /* the callers of ptrace_may_access should be fixed */
>
> int ptrace_may_access(struct task_struct *task, unsigned int mode)
Sigh, NAK, for the reasons explained in the previous mails.
Ingo
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:20 ` Ingo Molnar
@ 2009-05-07 8:31 ` Oleg Nesterov
2009-05-07 8:38 ` Ingo Molnar
0 siblings, 1 reply; 669+ messages in thread
From: Oleg Nesterov @ 2009-05-07 8:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Roland McGrath, Andrew Morton, Chris Wright, linux-kernel, Al Viro
On 05/07, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > /* the callers of ptrace_may_access should be fixed */
> >
> > int ptrace_may_access(struct task_struct *task, unsigned int mode)
>
> Sigh, NAK, for the reasons explained in the previous mails.
Agreed, but what about security_operations->ptrace_may_access ?
It has the same (bad) name, but returns the error code or 0 on
success.
Oleg.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:31 ` Oleg Nesterov
@ 2009-05-07 8:38 ` Ingo Molnar
2009-05-07 8:57 ` Chris Wright
0 siblings, 1 reply; 669+ messages in thread
From: Ingo Molnar @ 2009-05-07 8:38 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Roland McGrath, Andrew Morton, Chris Wright, linux-kernel, Al Viro
* Oleg Nesterov <oleg@redhat.com> wrote:
> On 05/07, Ingo Molnar wrote:
> >
> > * Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > > /* the callers of ptrace_may_access should be fixed */
> > >
> > > int ptrace_may_access(struct task_struct *task, unsigned int mode)
> >
> > Sigh, NAK, for the reasons explained in the previous mails.
>
> Agreed, but what about security_operations->ptrace_may_access ?
>
> It has the same (bad) name, but returns the error code or 0 on
> success.
Bad code should generally be fixed, or in exceptional circumstances
it can tolerated if it's pre-existing bad code, but it should never
be propagated. It has not spread _that_ widely yet, and is isolated
to the security subsystem:
include/linux/security.h
security/capability.c
security/commoncap.c
security/root_plug.c
security/security.c
security/selinux/hooks.c
security/smack/smack_lsm.c
Ingo
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:38 ` Ingo Molnar
@ 2009-05-07 8:57 ` Chris Wright
2009-05-07 9:04 ` Ingo Molnar
0 siblings, 1 reply; 669+ messages in thread
From: Chris Wright @ 2009-05-07 8:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Oleg Nesterov, Roland McGrath, Andrew Morton, Chris Wright,
linux-kernel, Al Viro
* Ingo Molnar (mingo@elte.hu) wrote:
> * Oleg Nesterov <oleg@redhat.com> wrote:
> > Agreed, but what about security_operations->ptrace_may_access ?
> > It has the same (bad) name, but returns the error code or 0 on
> > success.
>
> Bad code should generally be fixed, or in exceptional circumstances
> it can tolerated if it's pre-existing bad code, but it should never
> be propagated. It has not spread _that_ widely yet, and is isolated
> to the security subsystem:
And the security hooks tend to all follow the 0 success -ve ERR on error.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:57 ` Chris Wright
@ 2009-05-07 9:04 ` Ingo Molnar
2009-05-07 9:20 ` Chris Wright
0 siblings, 1 reply; 669+ messages in thread
From: Ingo Molnar @ 2009-05-07 9:04 UTC (permalink / raw)
To: Chris Wright
Cc: Oleg Nesterov, Roland McGrath, Andrew Morton, linux-kernel, Al Viro
* Chris Wright <chrisw@sous-sol.org> wrote:
> * Ingo Molnar (mingo@elte.hu) wrote:
> > * Oleg Nesterov <oleg@redhat.com> wrote:
> > > Agreed, but what about security_operations->ptrace_may_access ?
> > > It has the same (bad) name, but returns the error code or 0 on
> > > success.
> >
> > Bad code should generally be fixed, or in exceptional circumstances
> > it can tolerated if it's pre-existing bad code, but it should never
> > be propagated. It has not spread _that_ widely yet, and is isolated
> > to the security subsystem:
>
> And the security hooks tend to all follow the 0 success -ve ERR on error.
I just sent a patch (see below) that renames them to
ptrace_access_check().
They have no active connection to the core kernel
ptrace_may_access() check in any case: the methods seem to be
home-brewn, security-module specific checks for how wide ptrace is
allowed to go.
The design around that code does not seem to be very consistent.
One solution would be for the default "plain Linux" security module
to have a stock ->ptrace_access_check() that does the current
ptrace_may_access() check, and then procfs could be updated to use
that callback - instead of calling into the ptrace core code
directly.
This would mean that in the end the 'may' usage is eliminated
altogether, and we have a clean ptrace_access_check() facility with
a retval convention.
Ingo
-------------->
Subject: security: rename ptrace_may_access => ptrace_access_check
From: Ingo Molnar <mingo@elte.hu>
The ->ptrace_may_access methods are named confusingly - the real
ptrace_may_access() returns a bool, while these security checks have
a retval convention.
Rename it to ptrace_access_check, to reduce the confusion factor.
[ Impact: cleanup, no code changed ]
Signed-off-by-if-you-test-it: Ingo Molnar <mingo@elte.hu>
---
include/linux/security.h | 14 +++++++-------
security/capability.c | 2 +-
security/commoncap.c | 4 ++--
security/root_plug.c | 2 +-
security/security.c | 4 ++--
security/selinux/hooks.c | 6 +++---
security/smack/smack_lsm.c | 8 ++++----
7 files changed, 20 insertions(+), 20 deletions(-)
Index: tip/include/linux/security.h
===================================================================
--- tip.orig/include/linux/security.h
+++ tip/include/linux/security.h
@@ -52,7 +52,7 @@ struct audit_krule;
extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
int cap, int audit);
extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
extern int cap_ptrace_traceme(struct task_struct *parent);
extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
* @alter contains the flag indicating whether changes are to be made.
* Return 0 if permission is granted.
*
- * @ptrace_may_access:
+ * @ptrace_access_check:
* Check permission before allowing the current process to trace the
* @child process.
* Security modules may also want to perform a process tracing check
@@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_may_access
+ * The parent process will still have to undergo the ptrace_access_check
* checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
@@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
struct security_operations {
char name[SECURITY_NAME_MAX + 1];
- int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+ int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
@@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
extern int register_security(struct security_operations *ops);
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
int security_ptrace_traceme(struct task_struct *parent);
int security_capget(struct task_struct *target,
kernel_cap_t *effective,
@@ -1798,10 +1798,10 @@ static inline int security_init(void)
return 0;
}
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
- return cap_ptrace_may_access(child, mode);
+ return cap_ptrace_access_check(child, mode);
}
static inline int security_ptrace_traceme(struct task_struct *parent)
Index: tip/security/capability.c
===================================================================
--- tip.orig/security/capability.c
+++ tip/security/capability.c
@@ -867,7 +867,7 @@ struct security_operations default_secur
void security_fixup_ops(struct security_operations *ops)
{
- set_to_cap_if_null(ops, ptrace_may_access);
+ set_to_cap_if_null(ops, ptrace_access_check);
set_to_cap_if_null(ops, ptrace_traceme);
set_to_cap_if_null(ops, capget);
set_to_cap_if_null(ops, capset);
Index: tip/security/commoncap.c
===================================================================
--- tip.orig/security/commoncap.c
+++ tip/security/commoncap.c
@@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
}
/**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
* another
* @child: The process to be accessed
* @mode: The mode of attachment.
@@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
* Determine whether a process may access another, returning 0 if permission
* granted, -ve if denied.
*/
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
int ret = 0;
Index: tip/security/root_plug.c
===================================================================
--- tip.orig/security/root_plug.c
+++ tip/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security
static struct security_operations rootplug_security_ops = {
/* Use the capability functions for some of the hooks */
- .ptrace_may_access = cap_ptrace_may_access,
+ .ptrace_access_check = cap_ptrace_access_check,
.ptrace_traceme = cap_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
Index: tip/security/security.c
===================================================================
--- tip.orig/security/security.c
+++ tip/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_op
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
- return security_ops->ptrace_may_access(child, mode);
+ return security_ops->ptrace_access_check(child, mode);
}
int security_ptrace_traceme(struct task_struct *parent)
Index: tip/security/selinux/hooks.c
===================================================================
--- tip.orig/security/selinux/hooks.c
+++ tip/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
/* Hook functions begin here. */
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(child, mode);
+ rc = cap_ptrace_access_check(child, mode);
if (rc)
return rc;
@@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
static struct security_operations selinux_ops = {
.name = "selinux",
- .ptrace_may_access = selinux_ptrace_may_access,
+ .ptrace_access_check = selinux_ptrace_access_check,
.ptrace_traceme = selinux_ptrace_traceme,
.capget = selinux_capget,
.capset = selinux_capset,
Index: tip/security/smack/smack_lsm.c
===================================================================
--- tip.orig/security/smack/smack_lsm.c
+++ tip/security/smack/smack_lsm.c
@@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
*/
/**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
* @ctp: child task pointer
* @mode: ptrace attachment mode
*
@@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
*
* Do the capability checks, and require read and write.
*/
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(ctp, mode);
+ rc = cap_ptrace_access_check(ctp, mode);
if (rc != 0)
return rc;
@@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
struct security_operations smack_ops = {
.name = "smack",
- .ptrace_may_access = smack_ptrace_may_access,
+ .ptrace_access_check = smack_ptrace_access_check,
.ptrace_traceme = smack_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 9:04 ` Ingo Molnar
@ 2009-05-07 9:20 ` Chris Wright
2009-05-07 9:54 ` James Morris
0 siblings, 1 reply; 669+ messages in thread
From: Chris Wright @ 2009-05-07 9:20 UTC (permalink / raw)
To: Ingo Molnar
Cc: Chris Wright, Oleg Nesterov, Roland McGrath, Andrew Morton,
linux-kernel, Al Viro
* Ingo Molnar (mingo@elte.hu) wrote:
>
> * Chris Wright <chrisw@sous-sol.org> wrote:
>
> > * Ingo Molnar (mingo@elte.hu) wrote:
> > > * Oleg Nesterov <oleg@redhat.com> wrote:
> > > > Agreed, but what about security_operations->ptrace_may_access ?
> > > > It has the same (bad) name, but returns the error code or 0 on
> > > > success.
> > >
> > > Bad code should generally be fixed, or in exceptional circumstances
> > > it can tolerated if it's pre-existing bad code, but it should never
> > > be propagated. It has not spread _that_ widely yet, and is isolated
> > > to the security subsystem:
> >
> > And the security hooks tend to all follow the 0 success -ve ERR on error.
>
> I just sent a patch (see below) that renames them to
> ptrace_access_check().
>
> They have no active connection to the core kernel
> ptrace_may_access() check in any case:
Not sure what you mean:
ptrace_may_access
__ptrace_may_access
security_ptrace_may_access
Looks like your patch won't compile.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
2009-05-07 9:20 ` Chris Wright
@ 2009-05-07 9:54 ` James Morris
2009-05-07 10:20 ` your mail Ingo Molnar
0 siblings, 1 reply; 669+ messages in thread
From: James Morris @ 2009-05-07 9:54 UTC (permalink / raw)
To: Chris Wright
Cc: Ingo Molnar, Oleg Nesterov, Roland McGrath, Andrew Morton,
linux-kernel, Al Viro, linux-security-module
On Thu, 7 May 2009, Chris Wright wrote:
> * Ingo Molnar (mingo@elte.hu) wrote:
[Added LSM list to the CC; please do so whenever making changes in this
area...]
> > They have no active connection to the core kernel
> > ptrace_may_access() check in any case:
>
> Not sure what you mean:
>
> ptrace_may_access
> __ptrace_may_access
> security_ptrace_may_access
>
> Looks like your patch won't compile.
>
Below is an updated version which fixes the bug, against
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
Boot tested with SELinux.
commit c4c79671177dc3e8387c337f75f3c664cdf08838
Author: Ingo Molnar <mingo@elte.hu>
Date: Thu May 7 19:26:19 2009 +1000
security: rename ptrace_may_access => ptrace_access_check
The ->ptrace_may_access() methods are named confusingly - the real
ptrace_may_access() returns a bool, while these security checks have
a retval convention.
Rename it to ptrace_access_check, to reduce the confusion factor.
[ Impact: cleanup, no code changed ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: James Morris <jmorris@namei.org>
diff --git a/include/linux/security.h b/include/linux/security.h
index 54ed157..0147def 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -51,7 +51,7 @@ struct audit_krule;
extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
int cap, int audit);
extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
extern int cap_ptrace_traceme(struct task_struct *parent);
extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1208,7 +1208,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* @alter contains the flag indicating whether changes are to be made.
* Return 0 if permission is granted.
*
- * @ptrace_may_access:
+ * @ptrace_access_check:
* Check permission before allowing the current process to trace the
* @child process.
* Security modules may also want to perform a process tracing check
@@ -1223,7 +1223,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_may_access
+ * The parent process will still have to undergo the ptrace_access_check
* checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
@@ -1335,7 +1335,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
struct security_operations {
char name[SECURITY_NAME_MAX + 1];
- int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+ int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
@@ -1616,7 +1616,7 @@ extern int security_module_enable(struct security_operations *ops);
extern int register_security(struct security_operations *ops);
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
int security_ptrace_traceme(struct task_struct *parent);
int security_capget(struct task_struct *target,
kernel_cap_t *effective,
@@ -1797,10 +1797,10 @@ static inline int security_init(void)
return 0;
}
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
- return cap_ptrace_may_access(child, mode);
+ return cap_ptrace_access_check(child, mode);
}
static inline int security_ptrace_traceme(struct task_struct *parent)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c9cf48b..284d0ac 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -160,7 +160,7 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
if (!dumpable && !capable(CAP_SYS_PTRACE))
return -EPERM;
- return security_ptrace_may_access(task, mode);
+ return security_ptrace_access_check(task, mode);
}
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
diff --git a/security/capability.c b/security/capability.c
index 21b6cea..f218dd3 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -863,7 +863,7 @@ struct security_operations default_security_ops = {
void security_fixup_ops(struct security_operations *ops)
{
- set_to_cap_if_null(ops, ptrace_may_access);
+ set_to_cap_if_null(ops, ptrace_access_check);
set_to_cap_if_null(ops, ptrace_traceme);
set_to_cap_if_null(ops, capget);
set_to_cap_if_null(ops, capset);
diff --git a/security/commoncap.c b/security/commoncap.c
index 97ac1f1..e57611a 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -101,7 +101,7 @@ int cap_settime(struct timespec *ts, struct timezone *tz)
}
/**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
* another
* @child: The process to be accessed
* @mode: The mode of attachment.
@@ -109,7 +109,7 @@ int cap_settime(struct timespec *ts, struct timezone *tz)
* Determine whether a process may access another, returning 0 if permission
* granted, -ve if denied.
*/
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
int ret = 0;
diff --git a/security/root_plug.c b/security/root_plug.c
index 40fb4f1..e8d5861 100644
--- a/security/root_plug.c
+++ b/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security (struct linux_binprm *bprm)
static struct security_operations rootplug_security_ops = {
/* Use the capability functions for some of the hooks */
- .ptrace_may_access = cap_ptrace_may_access,
+ .ptrace_access_check = cap_ptrace_access_check,
.ptrace_traceme = cap_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
diff --git a/security/security.c b/security/security.c
index 206e538..a3e6918 100644
--- a/security/security.c
+++ b/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_operations *ops)
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
- return security_ops->ptrace_may_access(child, mode);
+ return security_ops->ptrace_access_check(child, mode);
}
int security_ptrace_traceme(struct task_struct *parent)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 39046dd..e30c4bb 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct file *file)
/* Hook functions begin here. */
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(child, mode);
+ rc = cap_ptrace_access_check(child, mode);
if (rc)
return rc;
@@ -5310,7 +5310,7 @@ static int selinux_key_getsecurity(struct key *key, char **_buffer)
static struct security_operations selinux_ops = {
.name = "selinux",
- .ptrace_may_access = selinux_ptrace_may_access,
+ .ptrace_access_check = selinux_ptrace_access_check,
.ptrace_traceme = selinux_ptrace_traceme,
.capget = selinux_capget,
.capset = selinux_capset,
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f557767..79949f9 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -91,7 +91,7 @@ struct inode_smack *new_inode_smack(char *smack)
*/
/**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
* @ctp: child task pointer
* @mode: ptrace attachment mode
*
@@ -99,13 +99,13 @@ struct inode_smack *new_inode_smack(char *smack)
*
* Do the capability checks, and require read and write.
*/
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
{
int rc;
struct smk_audit_info ad;
char *sp, *tsp;
- rc = cap_ptrace_may_access(ctp, mode);
+ rc = cap_ptrace_access_check(ctp, mode);
if (rc != 0)
return rc;
@@ -3031,7 +3031,7 @@ static void smack_release_secctx(char *secdata, u32 seclen)
struct security_operations smack_ops = {
.name = "smack",
- .ptrace_may_access = smack_ptrace_may_access,
+ .ptrace_access_check = smack_ptrace_access_check,
.ptrace_traceme = smack_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2009-05-07 9:54 ` James Morris
@ 2009-05-07 10:20 ` Ingo Molnar
2009-05-08 3:27 ` Casey Schaufler
0 siblings, 1 reply; 669+ messages in thread
From: Ingo Molnar @ 2009-05-07 10:20 UTC (permalink / raw)
To: James Morris
Cc: Chris Wright, Oleg Nesterov, Roland McGrath, Andrew Morton,
linux-kernel, Al Viro, linux-security-module
* James Morris <jmorris@namei.org> wrote:
> On Thu, 7 May 2009, Chris Wright wrote:
>
> > * Ingo Molnar (mingo@elte.hu) wrote:
>
> [Added LSM list to the CC; please do so whenever making changes in this
> area...]
>
> > > They have no active connection to the core kernel
> > > ptrace_may_access() check in any case:
> >
> > Not sure what you mean:
> >
> > ptrace_may_access
> > __ptrace_may_access
> > security_ptrace_may_access
> >
> > Looks like your patch won't compile.
> >
>
> Below is an updated version which fixes the bug, against
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>
> Boot tested with SELinux.
thanks! Below are the two patches i wrote and tested.
Ingo
----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
Date: Thu, 7 May 2009 11:49:47 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@sous-sol.org>
Subject: [patch 1/2] ptrace, security: rename ptrace_may_access =>
ptrace_access_check
Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
The ptrace_may_access() methods are named confusingly - some
variants return a bool, while the security subsystem methods have a
retval convention.
Rename it to ptrace_access_check, to reduce the confusion factor. A
followup patch eliminates the bool usage.
[ Impact: cleanup, no code changed ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
LKML-Reference: <20090507084943.GB19133@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
fs/proc/array.c | 2 +-
fs/proc/base.c | 10 +++++-----
fs/proc/task_mmu.c | 2 +-
include/linux/ptrace.h | 4 ++--
include/linux/security.h | 14 +++++++-------
kernel/ptrace.c | 10 +++++-----
security/capability.c | 2 +-
security/commoncap.c | 4 ++--
security/root_plug.c | 2 +-
security/security.c | 4 ++--
security/selinux/hooks.c | 6 +++---
security/smack/smack_lsm.c | 8 ++++----
12 files changed, 34 insertions(+), 34 deletions(-)
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c
+++ linux/fs/proc/array.c
@@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
state = *get_task_state(task);
vsize = eip = esp = 0;
- permitted = ptrace_may_access(task, PTRACE_MODE_READ);
+ permitted = ptrace_access_check(task, PTRACE_MODE_READ);
mm = get_task_mm(task);
if (mm) {
vsize = task_vsize(mm);
Index: linux/fs/proc/base.c
===================================================================
--- linux.orig/fs/proc/base.c
+++ linux/fs/proc/base.c
@@ -222,7 +222,7 @@ static int check_mem_permission(struct t
rcu_read_lock();
match = (tracehook_tracer_task(task) == current);
rcu_read_unlock();
- if (match && ptrace_may_access(task, PTRACE_MODE_ATTACH))
+ if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
return 0;
}
@@ -242,7 +242,7 @@ struct mm_struct *mm_for_maps(struct tas
if (task->mm != mm)
goto out;
if (task->mm != current->mm &&
- __ptrace_may_access(task, PTRACE_MODE_READ) < 0)
+ __ptrace_access_check(task, PTRACE_MODE_READ) < 0)
goto out;
task_unlock(task);
return mm;
@@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0)
- if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ if (!ptrace_access_check(task, PTRACE_MODE_READ))
return 0;
else
return sprintf(buffer, "%lu", wchan);
@@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
*/
task = get_proc_task(inode);
if (task) {
- allowed = ptrace_may_access(task, PTRACE_MODE_READ);
+ allowed = ptrace_access_check(task, PTRACE_MODE_READ);
put_task_struct(task);
}
return allowed;
@@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
if (!task)
goto out_no_task;
- if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ if (!ptrace_access_check(task, PTRACE_MODE_READ))
goto out;
ret = -ENOMEM;
Index: linux/fs/proc/task_mmu.c
===================================================================
--- linux.orig/fs/proc/task_mmu.c
+++ linux/fs/proc/task_mmu.c
@@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
goto out;
ret = -EACCES;
- if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ if (!ptrace_access_check(task, PTRACE_MODE_READ))
goto out_task;
ret = -EINVAL;
Index: linux/include/linux/ptrace.h
===================================================================
--- linux.orig/include/linux/ptrace.h
+++ linux/include/linux/ptrace.h
@@ -99,9 +99,9 @@ extern void ptrace_fork(struct task_stru
#define PTRACE_MODE_READ 1
#define PTRACE_MODE_ATTACH 2
/* Returns 0 on success, -errno on denial. */
-extern int __ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
/* Returns true on success, false on denial. */
-extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
static inline int ptrace_reparented(struct task_struct *child)
{
Index: linux/include/linux/security.h
===================================================================
--- linux.orig/include/linux/security.h
+++ linux/include/linux/security.h
@@ -52,7 +52,7 @@ struct audit_krule;
extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
int cap, int audit);
extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
extern int cap_ptrace_traceme(struct task_struct *parent);
extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
* @alter contains the flag indicating whether changes are to be made.
* Return 0 if permission is granted.
*
- * @ptrace_may_access:
+ * @ptrace_access_check:
* Check permission before allowing the current process to trace the
* @child process.
* Security modules may also want to perform a process tracing check
@@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_may_access
+ * The parent process will still have to undergo the ptrace_access_check
* checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
@@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
struct security_operations {
char name[SECURITY_NAME_MAX + 1];
- int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+ int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
@@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
extern int register_security(struct security_operations *ops);
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
int security_ptrace_traceme(struct task_struct *parent);
int security_capget(struct task_struct *target,
kernel_cap_t *effective,
@@ -1798,10 +1798,10 @@ static inline int security_init(void)
return 0;
}
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
- return cap_ptrace_may_access(child, mode);
+ return cap_ptrace_access_check(child, mode);
}
static inline int security_ptrace_traceme(struct task_struct *parent)
Index: linux/kernel/ptrace.c
===================================================================
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -127,7 +127,7 @@ int ptrace_check_attach(struct task_stru
return ret;
}
-int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int __ptrace_access_check(struct task_struct *task, unsigned int mode)
{
const struct cred *cred = current_cred(), *tcred;
@@ -162,14 +162,14 @@ int __ptrace_may_access(struct task_stru
if (!dumpable && !capable(CAP_SYS_PTRACE))
return -EPERM;
- return security_ptrace_may_access(task, mode);
+ return security_ptrace_access_check(task, mode);
}
-bool ptrace_may_access(struct task_struct *task, unsigned int mode)
+bool ptrace_access_check(struct task_struct *task, unsigned int mode)
{
int err;
task_lock(task);
- err = __ptrace_may_access(task, mode);
+ err = __ptrace_access_check(task, mode);
task_unlock(task);
return !err;
}
@@ -217,7 +217,7 @@ repeat:
/* the same process cannot be attached many times */
if (task->ptrace & PT_PTRACED)
goto bad;
- retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
+ retval = __ptrace_access_check(task, PTRACE_MODE_ATTACH);
if (retval)
goto bad;
Index: linux/security/capability.c
===================================================================
--- linux.orig/security/capability.c
+++ linux/security/capability.c
@@ -863,7 +863,7 @@ struct security_operations default_secur
void security_fixup_ops(struct security_operations *ops)
{
- set_to_cap_if_null(ops, ptrace_may_access);
+ set_to_cap_if_null(ops, ptrace_access_check);
set_to_cap_if_null(ops, ptrace_traceme);
set_to_cap_if_null(ops, capget);
set_to_cap_if_null(ops, capset);
Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c
+++ linux/security/commoncap.c
@@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
}
/**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
* another
* @child: The process to be accessed
* @mode: The mode of attachment.
@@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
* Determine whether a process may access another, returning 0 if permission
* granted, -ve if denied.
*/
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
int ret = 0;
Index: linux/security/root_plug.c
===================================================================
--- linux.orig/security/root_plug.c
+++ linux/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security
static struct security_operations rootplug_security_ops = {
/* Use the capability functions for some of the hooks */
- .ptrace_may_access = cap_ptrace_may_access,
+ .ptrace_access_check = cap_ptrace_access_check,
.ptrace_traceme = cap_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
Index: linux/security/security.c
===================================================================
--- linux.orig/security/security.c
+++ linux/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_op
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
- return security_ops->ptrace_may_access(child, mode);
+ return security_ops->ptrace_access_check(child, mode);
}
int security_ptrace_traceme(struct task_struct *parent)
Index: linux/security/selinux/hooks.c
===================================================================
--- linux.orig/security/selinux/hooks.c
+++ linux/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
/* Hook functions begin here. */
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(child, mode);
+ rc = cap_ptrace_access_check(child, mode);
if (rc)
return rc;
@@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
static struct security_operations selinux_ops = {
.name = "selinux",
- .ptrace_may_access = selinux_ptrace_may_access,
+ .ptrace_access_check = selinux_ptrace_access_check,
.ptrace_traceme = selinux_ptrace_traceme,
.capget = selinux_capget,
.capset = selinux_capset,
Index: linux/security/smack/smack_lsm.c
===================================================================
--- linux.orig/security/smack/smack_lsm.c
+++ linux/security/smack/smack_lsm.c
@@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
*/
/**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
* @ctp: child task pointer
* @mode: ptrace attachment mode
*
@@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
*
* Do the capability checks, and require read and write.
*/
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(ctp, mode);
+ rc = cap_ptrace_access_check(ctp, mode);
if (rc != 0)
return rc;
@@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
struct security_operations smack_ops = {
.name = "smack",
- .ptrace_may_access = smack_ptrace_may_access,
+ .ptrace_access_check = smack_ptrace_access_check,
.ptrace_traceme = smack_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
Date: Thu, 7 May 2009 11:50:54 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@sous-sol.org>
Subject: [patch 2/2] ptrace: turn ptrace_access_check() into a retval
function
Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
ptrace_access_check() returns a bool, while most of the ptrace
access check machinery works with Linux retvals (where 0 indicates
success, negative indicates an error).
So eliminate the bool and invert the usage at the call sites.
( Note: "< 0" checks are used instead of !0 checks, because that's
the convention for retval checks and it results in similarly fast
assembly code. )
[ Impact: cleanup ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
fs/proc/array.c | 2 +-
fs/proc/base.c | 8 ++++----
fs/proc/task_mmu.c | 2 +-
include/linux/ptrace.h | 2 +-
kernel/ptrace.c | 6 ++++--
5 files changed, 11 insertions(+), 9 deletions(-)
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c
+++ linux/fs/proc/array.c
@@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
state = *get_task_state(task);
vsize = eip = esp = 0;
- permitted = ptrace_access_check(task, PTRACE_MODE_READ);
+ permitted = !ptrace_access_check(task, PTRACE_MODE_READ);
mm = get_task_mm(task);
if (mm) {
vsize = task_vsize(mm);
Index: linux/fs/proc/base.c
===================================================================
--- linux.orig/fs/proc/base.c
+++ linux/fs/proc/base.c
@@ -222,7 +222,7 @@ static int check_mem_permission(struct t
rcu_read_lock();
match = (tracehook_tracer_task(task) == current);
rcu_read_unlock();
- if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
+ if (match && !ptrace_access_check(task, PTRACE_MODE_ATTACH))
return 0;
}
@@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0)
- if (!ptrace_access_check(task, PTRACE_MODE_READ))
+ if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
return 0;
else
return sprintf(buffer, "%lu", wchan);
@@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
*/
task = get_proc_task(inode);
if (task) {
- allowed = ptrace_access_check(task, PTRACE_MODE_READ);
+ allowed = !ptrace_access_check(task, PTRACE_MODE_READ);
put_task_struct(task);
}
return allowed;
@@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
if (!task)
goto out_no_task;
- if (!ptrace_access_check(task, PTRACE_MODE_READ))
+ if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
goto out;
ret = -ENOMEM;
Index: linux/fs/proc/task_mmu.c
===================================================================
--- linux.orig/fs/proc/task_mmu.c
+++ linux/fs/proc/task_mmu.c
@@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
goto out;
ret = -EACCES;
- if (!ptrace_access_check(task, PTRACE_MODE_READ))
+ if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
goto out_task;
ret = -EINVAL;
Index: linux/include/linux/ptrace.h
===================================================================
--- linux.orig/include/linux/ptrace.h
+++ linux/include/linux/ptrace.h
@@ -101,7 +101,7 @@ extern void ptrace_fork(struct task_stru
/* Returns 0 on success, -errno on denial. */
extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
/* Returns true on success, false on denial. */
-extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
+extern int ptrace_access_check(struct task_struct *task, unsigned int mode);
static inline int ptrace_reparented(struct task_struct *child)
{
Index: linux/kernel/ptrace.c
===================================================================
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -165,13 +165,15 @@ int __ptrace_access_check(struct task_st
return security_ptrace_access_check(task, mode);
}
-bool ptrace_access_check(struct task_struct *task, unsigned int mode)
+int ptrace_access_check(struct task_struct *task, unsigned int mode)
{
int err;
+
task_lock(task);
err = __ptrace_access_check(task, mode);
task_unlock(task);
- return !err;
+
+ return err;
}
int ptrace_attach(struct task_struct *task)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2009-05-07 10:20 ` your mail Ingo Molnar
@ 2009-05-08 3:27 ` Casey Schaufler
0 siblings, 0 replies; 669+ messages in thread
From: Casey Schaufler @ 2009-05-08 3:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: James Morris, Chris Wright, Oleg Nesterov, Roland McGrath,
Andrew Morton, linux-kernel, Al Viro, linux-security-module
Ingo Molnar wrote:
> * James Morris <jmorris@namei.org> wrote:
>
>
>> On Thu, 7 May 2009, Chris Wright wrote:
>>
>>
>>> * Ingo Molnar (mingo@elte.hu) wrote:
>>>
>> [Added LSM list to the CC; please do so whenever making changes in this
>> area...]
>>
>>
>>>> They have no active connection to the core kernel
>>>> ptrace_may_access() check in any case:
>>>>
>>> Not sure what you mean:
>>>
>>> ptrace_may_access
>>> __ptrace_may_access
>>> security_ptrace_may_access
>>>
>>> Looks like your patch won't compile.
>>>
>>>
>> Below is an updated version which fixes the bug, against
>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>>
>> Boot tested with SELinux.
>>
>
> thanks! Below are the two patches i wrote and tested.
>
I hate to make an assumption regarding whether or not your tests
included Smack, so I'll ask. Does tested mean with Smack?
Thank you.
> Ingo
>
> ----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
>
> Date: Thu, 7 May 2009 11:49:47 +0200
> From: Ingo Molnar <mingo@elte.hu>
> To: Chris Wright <chrisw@sous-sol.org>
> Subject: [patch 1/2] ptrace, security: rename ptrace_may_access =>
> ptrace_access_check
> Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
> Andrew Morton <akpm@linux-foundation.org>,
> linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
>
> The ptrace_may_access() methods are named confusingly - some
> variants return a bool, while the security subsystem methods have a
> retval convention.
>
> Rename it to ptrace_access_check, to reduce the confusion factor. A
> followup patch eliminates the bool usage.
>
> [ Impact: cleanup, no code changed ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Cc: Roland McGrath <roland@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Chris Wright <chrisw@sous-sol.org>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Cc: Oleg Nesterov <oleg@redhat.com>
> LKML-Reference: <20090507084943.GB19133@elte.hu>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> fs/proc/array.c | 2 +-
> fs/proc/base.c | 10 +++++-----
> fs/proc/task_mmu.c | 2 +-
> include/linux/ptrace.h | 4 ++--
> include/linux/security.h | 14 +++++++-------
> kernel/ptrace.c | 10 +++++-----
> security/capability.c | 2 +-
> security/commoncap.c | 4 ++--
> security/root_plug.c | 2 +-
> security/security.c | 4 ++--
> security/selinux/hooks.c | 6 +++---
> security/smack/smack_lsm.c | 8 ++++----
> 12 files changed, 34 insertions(+), 34 deletions(-)
>
> Index: linux/fs/proc/array.c
> ===================================================================
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
>
> state = *get_task_state(task);
> vsize = eip = esp = 0;
> - permitted = ptrace_may_access(task, PTRACE_MODE_READ);
> + permitted = ptrace_access_check(task, PTRACE_MODE_READ);
> mm = get_task_mm(task);
> if (mm) {
> vsize = task_vsize(mm);
> Index: linux/fs/proc/base.c
> ===================================================================
> --- linux.orig/fs/proc/base.c
> +++ linux/fs/proc/base.c
> @@ -222,7 +222,7 @@ static int check_mem_permission(struct t
> rcu_read_lock();
> match = (tracehook_tracer_task(task) == current);
> rcu_read_unlock();
> - if (match && ptrace_may_access(task, PTRACE_MODE_ATTACH))
> + if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
> return 0;
> }
>
> @@ -242,7 +242,7 @@ struct mm_struct *mm_for_maps(struct tas
> if (task->mm != mm)
> goto out;
> if (task->mm != current->mm &&
> - __ptrace_may_access(task, PTRACE_MODE_READ) < 0)
> + __ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> goto out;
> task_unlock(task);
> return mm;
> @@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
> wchan = get_wchan(task);
>
> if (lookup_symbol_name(wchan, symname) < 0)
> - if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + if (!ptrace_access_check(task, PTRACE_MODE_READ))
> return 0;
> else
> return sprintf(buffer, "%lu", wchan);
> @@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
> */
> task = get_proc_task(inode);
> if (task) {
> - allowed = ptrace_may_access(task, PTRACE_MODE_READ);
> + allowed = ptrace_access_check(task, PTRACE_MODE_READ);
> put_task_struct(task);
> }
> return allowed;
> @@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
> if (!task)
> goto out_no_task;
>
> - if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + if (!ptrace_access_check(task, PTRACE_MODE_READ))
> goto out;
>
> ret = -ENOMEM;
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
> goto out;
>
> ret = -EACCES;
> - if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + if (!ptrace_access_check(task, PTRACE_MODE_READ))
> goto out_task;
>
> ret = -EINVAL;
> Index: linux/include/linux/ptrace.h
> ===================================================================
> --- linux.orig/include/linux/ptrace.h
> +++ linux/include/linux/ptrace.h
> @@ -99,9 +99,9 @@ extern void ptrace_fork(struct task_stru
> #define PTRACE_MODE_READ 1
> #define PTRACE_MODE_ATTACH 2
> /* Returns 0 on success, -errno on denial. */
> -extern int __ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
> /* Returns true on success, false on denial. */
> -extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
>
> static inline int ptrace_reparented(struct task_struct *child)
> {
> Index: linux/include/linux/security.h
> ===================================================================
> --- linux.orig/include/linux/security.h
> +++ linux/include/linux/security.h
> @@ -52,7 +52,7 @@ struct audit_krule;
> extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
> int cap, int audit);
> extern int cap_settime(struct timespec *ts, struct timezone *tz);
> -extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
> +extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
> extern int cap_ptrace_traceme(struct task_struct *parent);
> extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
> extern int cap_capset(struct cred *new, const struct cred *old,
> @@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
> * @alter contains the flag indicating whether changes are to be made.
> * Return 0 if permission is granted.
> *
> - * @ptrace_may_access:
> + * @ptrace_access_check:
> * Check permission before allowing the current process to trace the
> * @child process.
> * Security modules may also want to perform a process tracing check
> @@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
> * Check that the @parent process has sufficient permission to trace the
> * current process before allowing the current process to present itself
> * to the @parent process for tracing.
> - * The parent process will still have to undergo the ptrace_may_access
> + * The parent process will still have to undergo the ptrace_access_check
> * checks before it is allowed to trace this one.
> * @parent contains the task_struct structure for debugger process.
> * Return 0 if permission is granted.
> @@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
> struct security_operations {
> char name[SECURITY_NAME_MAX + 1];
>
> - int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
> + int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
> int (*ptrace_traceme) (struct task_struct *parent);
> int (*capget) (struct task_struct *target,
> kernel_cap_t *effective,
> @@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
> extern int register_security(struct security_operations *ops);
>
> /* Security operations */
> -int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
> +int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
> int security_ptrace_traceme(struct task_struct *parent);
> int security_capget(struct task_struct *target,
> kernel_cap_t *effective,
> @@ -1798,10 +1798,10 @@ static inline int security_init(void)
> return 0;
> }
>
> -static inline int security_ptrace_may_access(struct task_struct *child,
> +static inline int security_ptrace_access_check(struct task_struct *child,
> unsigned int mode)
> {
> - return cap_ptrace_may_access(child, mode);
> + return cap_ptrace_access_check(child, mode);
> }
>
> static inline int security_ptrace_traceme(struct task_struct *parent)
> Index: linux/kernel/ptrace.c
> ===================================================================
> --- linux.orig/kernel/ptrace.c
> +++ linux/kernel/ptrace.c
> @@ -127,7 +127,7 @@ int ptrace_check_attach(struct task_stru
> return ret;
> }
>
> -int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> +int __ptrace_access_check(struct task_struct *task, unsigned int mode)
> {
> const struct cred *cred = current_cred(), *tcred;
>
> @@ -162,14 +162,14 @@ int __ptrace_may_access(struct task_stru
> if (!dumpable && !capable(CAP_SYS_PTRACE))
> return -EPERM;
>
> - return security_ptrace_may_access(task, mode);
> + return security_ptrace_access_check(task, mode);
> }
>
> -bool ptrace_may_access(struct task_struct *task, unsigned int mode)
> +bool ptrace_access_check(struct task_struct *task, unsigned int mode)
> {
> int err;
> task_lock(task);
> - err = __ptrace_may_access(task, mode);
> + err = __ptrace_access_check(task, mode);
> task_unlock(task);
> return !err;
> }
> @@ -217,7 +217,7 @@ repeat:
> /* the same process cannot be attached many times */
> if (task->ptrace & PT_PTRACED)
> goto bad;
> - retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
> + retval = __ptrace_access_check(task, PTRACE_MODE_ATTACH);
> if (retval)
> goto bad;
>
> Index: linux/security/capability.c
> ===================================================================
> --- linux.orig/security/capability.c
> +++ linux/security/capability.c
> @@ -863,7 +863,7 @@ struct security_operations default_secur
>
> void security_fixup_ops(struct security_operations *ops)
> {
> - set_to_cap_if_null(ops, ptrace_may_access);
> + set_to_cap_if_null(ops, ptrace_access_check);
> set_to_cap_if_null(ops, ptrace_traceme);
> set_to_cap_if_null(ops, capget);
> set_to_cap_if_null(ops, capset);
> Index: linux/security/commoncap.c
> ===================================================================
> --- linux.orig/security/commoncap.c
> +++ linux/security/commoncap.c
> @@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
> }
>
> /**
> - * cap_ptrace_may_access - Determine whether the current process may access
> + * cap_ptrace_access_check - Determine whether the current process may access
> * another
> * @child: The process to be accessed
> * @mode: The mode of attachment.
> @@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
> * Determine whether a process may access another, returning 0 if permission
> * granted, -ve if denied.
> */
> -int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
> +int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
> {
> int ret = 0;
>
> Index: linux/security/root_plug.c
> ===================================================================
> --- linux.orig/security/root_plug.c
> +++ linux/security/root_plug.c
> @@ -72,7 +72,7 @@ static int rootplug_bprm_check_security
>
> static struct security_operations rootplug_security_ops = {
> /* Use the capability functions for some of the hooks */
> - .ptrace_may_access = cap_ptrace_may_access,
> + .ptrace_access_check = cap_ptrace_access_check,
> .ptrace_traceme = cap_ptrace_traceme,
> .capget = cap_capget,
> .capset = cap_capset,
> Index: linux/security/security.c
> ===================================================================
> --- linux.orig/security/security.c
> +++ linux/security/security.c
> @@ -127,9 +127,9 @@ int register_security(struct security_op
>
> /* Security operations */
>
> -int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
> +int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
> {
> - return security_ops->ptrace_may_access(child, mode);
> + return security_ops->ptrace_access_check(child, mode);
> }
>
> int security_ptrace_traceme(struct task_struct *parent)
> Index: linux/security/selinux/hooks.c
> ===================================================================
> --- linux.orig/security/selinux/hooks.c
> +++ linux/security/selinux/hooks.c
> @@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
>
> /* Hook functions begin here. */
>
> -static int selinux_ptrace_may_access(struct task_struct *child,
> +static int selinux_ptrace_access_check(struct task_struct *child,
> unsigned int mode)
> {
> int rc;
>
> - rc = cap_ptrace_may_access(child, mode);
> + rc = cap_ptrace_access_check(child, mode);
> if (rc)
> return rc;
>
> @@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
> static struct security_operations selinux_ops = {
> .name = "selinux",
>
> - .ptrace_may_access = selinux_ptrace_may_access,
> + .ptrace_access_check = selinux_ptrace_access_check,
> .ptrace_traceme = selinux_ptrace_traceme,
> .capget = selinux_capget,
> .capset = selinux_capset,
> Index: linux/security/smack/smack_lsm.c
> ===================================================================
> --- linux.orig/security/smack/smack_lsm.c
> +++ linux/security/smack/smack_lsm.c
> @@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
> */
>
> /**
> - * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
> + * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
> * @ctp: child task pointer
> * @mode: ptrace attachment mode
> *
> @@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
> *
> * Do the capability checks, and require read and write.
> */
> -static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
> +static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
> {
> int rc;
>
> - rc = cap_ptrace_may_access(ctp, mode);
> + rc = cap_ptrace_access_check(ctp, mode);
> if (rc != 0)
> return rc;
>
> @@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
> struct security_operations smack_ops = {
> .name = "smack",
>
> - .ptrace_may_access = smack_ptrace_may_access,
> + .ptrace_access_check = smack_ptrace_access_check,
> .ptrace_traceme = smack_ptrace_traceme,
> .capget = cap_capget,
> .capset = cap_capset,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> ----- End forwarded message -----
> ----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
>
> Date: Thu, 7 May 2009 11:50:54 +0200
> From: Ingo Molnar <mingo@elte.hu>
> To: Chris Wright <chrisw@sous-sol.org>
> Subject: [patch 2/2] ptrace: turn ptrace_access_check() into a retval
> function
> Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
> Andrew Morton <akpm@linux-foundation.org>,
> linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
>
> ptrace_access_check() returns a bool, while most of the ptrace
> access check machinery works with Linux retvals (where 0 indicates
> success, negative indicates an error).
>
> So eliminate the bool and invert the usage at the call sites.
>
> ( Note: "< 0" checks are used instead of !0 checks, because that's
> the convention for retval checks and it results in similarly fast
> assembly code. )
>
> [ Impact: cleanup ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> fs/proc/array.c | 2 +-
> fs/proc/base.c | 8 ++++----
> fs/proc/task_mmu.c | 2 +-
> include/linux/ptrace.h | 2 +-
> kernel/ptrace.c | 6 ++++--
> 5 files changed, 11 insertions(+), 9 deletions(-)
>
> Index: linux/fs/proc/array.c
> ===================================================================
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
>
> state = *get_task_state(task);
> vsize = eip = esp = 0;
> - permitted = ptrace_access_check(task, PTRACE_MODE_READ);
> + permitted = !ptrace_access_check(task, PTRACE_MODE_READ);
> mm = get_task_mm(task);
> if (mm) {
> vsize = task_vsize(mm);
> Index: linux/fs/proc/base.c
> ===================================================================
> --- linux.orig/fs/proc/base.c
> +++ linux/fs/proc/base.c
> @@ -222,7 +222,7 @@ static int check_mem_permission(struct t
> rcu_read_lock();
> match = (tracehook_tracer_task(task) == current);
> rcu_read_unlock();
> - if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
> + if (match && !ptrace_access_check(task, PTRACE_MODE_ATTACH))
> return 0;
> }
>
> @@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
> wchan = get_wchan(task);
>
> if (lookup_symbol_name(wchan, symname) < 0)
> - if (!ptrace_access_check(task, PTRACE_MODE_READ))
> + if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> return 0;
> else
> return sprintf(buffer, "%lu", wchan);
> @@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
> */
> task = get_proc_task(inode);
> if (task) {
> - allowed = ptrace_access_check(task, PTRACE_MODE_READ);
> + allowed = !ptrace_access_check(task, PTRACE_MODE_READ);
> put_task_struct(task);
> }
> return allowed;
> @@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
> if (!task)
> goto out_no_task;
>
> - if (!ptrace_access_check(task, PTRACE_MODE_READ))
> + if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> goto out;
>
> ret = -ENOMEM;
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
> goto out;
>
> ret = -EACCES;
> - if (!ptrace_access_check(task, PTRACE_MODE_READ))
> + if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> goto out_task;
>
> ret = -EINVAL;
> Index: linux/include/linux/ptrace.h
> ===================================================================
> --- linux.orig/include/linux/ptrace.h
> +++ linux/include/linux/ptrace.h
> @@ -101,7 +101,7 @@ extern void ptrace_fork(struct task_stru
> /* Returns 0 on success, -errno on denial. */
> extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
> /* Returns true on success, false on denial. */
> -extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
> +extern int ptrace_access_check(struct task_struct *task, unsigned int mode);
>
> static inline int ptrace_reparented(struct task_struct *child)
> {
> Index: linux/kernel/ptrace.c
> ===================================================================
> --- linux.orig/kernel/ptrace.c
> +++ linux/kernel/ptrace.c
> @@ -165,13 +165,15 @@ int __ptrace_access_check(struct task_st
> return security_ptrace_access_check(task, mode);
> }
>
> -bool ptrace_access_check(struct task_struct *task, unsigned int mode)
> +int ptrace_access_check(struct task_struct *task, unsigned int mode)
> {
> int err;
> +
> task_lock(task);
> err = __ptrace_access_check(task, mode);
> task_unlock(task);
> - return !err;
> +
> + return err;
> }
>
> int ptrace_attach(struct task_struct *task)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> ----- End forwarded message -----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2009-04-02 4:16 Lelsie Rhorer
2009-04-02 6:56 ` your mail Luca Berra
0 siblings, 1 reply; 669+ messages in thread
From: Lelsie Rhorer @ 2009-04-02 4:16 UTC (permalink / raw)
To: linux-raid
I'm having a severe problem whose root cause I cannot determine. I have a
RAID 6 array managed by mdadm running on Debian "Lenny" with a 3.2GHz AMD
Athlon 64 x 2 processor and 8G of RAM. There are ten 1 Terabyte SATA
drives, unpartitioned, fully allocated to the /dev/md0 device. The drive
are served by 3 Silicon Image SATA port multipliers and a Silicon Image 4
port eSATA controller. The /dev/md0 device is also unpartitioned, and all
8T of active space is formatted as a single Reiserfs file system. The
entire volume is mounted to /RAID. Various directories on the volume are
shared using both NFS and SAMBA.
Performance of the RAID system is very good. The array can read and write
at over 450 Mbps, and I don't know if the limit is the array itself or the
network, but since the performance is more than adequate I really am not
concerned which is the case.
The issue is the entire array will occasionally pause completely for about
40 seconds when a file is created. This does not always happen, but the
situation is easily reproducible. The frequency at which the symptom
occurs seems to be related to the transfer load on the array. If no other
transfers are in process, then the failure seems somewhat more rare,
perhaps accompanying less than 1 file creation in 10.. During heavy file
transfer activity, sometimes the system halts with every other file
creation. Although I have observed many dozens of these events, I have
never once observed it to happen except when a file creation occurs.
Reading and writing existing files never triggers the event, although any
read or write occurring during the event is halted for the duration.
(There is one cron jog which runs every half-hour that creates a tiny file;
this is the most common failure vector.) There are other drives formatted
with other file systems on the machine, but the issue has never been seen
on any of the other drives. When the array runs its regularly scheduled
health check, the problem is much worse. Not only does it lock up with
almost every single file creation, but the lock-up time is much longer -
sometimes in excess of 2 minutes.
Transfers via Linux based utilities (ftp, NFS, cp, mv, rsync, etc) all
recover after the event, but SAMBA based transfers frequently fail, both
reads and writes.
How can I troubleshoot and more importantly resolve this issue?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2009-04-02 4:16 (unknown), Lelsie Rhorer
@ 2009-04-02 6:56 ` Luca Berra
0 siblings, 0 replies; 669+ messages in thread
From: Luca Berra @ 2009-04-02 6:56 UTC (permalink / raw)
To: linux-raid
On Wed, Apr 01, 2009 at 11:16:06PM -0500, Lelsie Rhorer wrote:
>8T of active space is formatted as a single Reiserfs file system. The
....
>The issue is the entire array will occasionally pause completely for about
>40 seconds when a file is created. This does not always happen, but the
>situation is easily reproducible. The frequency at which the symptom
i wonder how costly b-tree operaton are for a 8Tb filesystem...
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2009-03-27 23:26 Eric Anholt
2009-03-28 0:02 ` your mail Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: Eric Anholt @ 2009-03-27 23:26 UTC (permalink / raw)
To: Linus Torvalds, lkml, dri-devel
[-- Attachment #1: Type: text/plain, Size: 4382 bytes --]
The following changes since commit be0ea69674ed95e1e98cb3687a241badc756d228:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../penberg/slab-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
There's only one outside-of-i915 commit here (debugfs), and it's a
prereq for the i915 changes. airlied said he'd pulled my version into
his tree, so we should be OK with it going in through my tree since he
hasn't send a pull request out.
Short summary: Fixing lock order reversals finally. Piles of KMS fixes
as usual. Support for an unreleased chipset. And a bunch of
infrastructure for debugging info we're going to be adding in this
kernel so that just maybe we can get a better handle on these "I use my
machine for a few days and then the GPU falls over" bugs.
Ben Gamari (3):
drm: Convert proc files to seq_file and introduce debugfs
drm/i915: Convert i915 proc files to seq_file and move to debugfs.
drm/i915: Consolidate gem object list dumping
Chris Wilson (2):
drm/i915: Display fence register state in debugfs i915_gem_fence_regs node.
drm/i915: Check for dev->primary->master before dereference.
Eric Anholt (8):
drm/i915: Change DCC tiling detection case to cover only mobile parts.
drm/i915: Fix lock order reversal in GTT pwrite path.
drm/i915: Make GEM object's page lists refcounted instead of get/free.
drm/i915: Fix lock order reversal in shmem pwrite path.
drm/i915: Fix lock order reversal in shmem pread path.
drm/i915: Fix lock order reversal with cliprects and cmdbuf in non-DRI2 paths.
drm/i915: Fix lock order reversal in GEM relocation entry copying.
drm/i915: Add information on pinning and fencing to the i915 list debug.
Kristian Høgsberg (1):
drm/i915: Read the right SDVO register when detecting SVDO/HDMI.
Li Peng (1):
drm/i915: Fix LVDS dither setting
Ma Ling (2):
drm/i915: Use documented PLL timing limits for G4X platform
drm/i915: Use a different PLL timing search function on G4X.
Owain G. Ainsworth (1):
i915/drm: Remove two redundant agp_chipset_flushes
Shaohua Li (1):
agp/intel: Add support for new intel chipset.
Zhao Yakui (2):
drm/i915: Sync mode_valid/mode_set with intel video driver
drm/i915: Sync crt hotplug detection with intel video driver
Zhenyu Wang (4):
drm/i915: TV modes' parameters sync up with 2D driver
drm/i915: Fix TV get_modes to return modes count
drm/i915: TV mode_set sync up with 2D driver
drm/i915: TV detection fix
drivers/char/agp/intel-agp.c | 21 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_debugfs.c | 235 ++++++++
drivers/gpu/drm/drm_drv.c | 12 +-
drivers/gpu/drm/drm_info.c | 328 +++++++++++
drivers/gpu/drm/drm_proc.c | 721 ++++---------------------
drivers/gpu/drm/drm_stub.c | 15 +-
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 116 +++--
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 21 +-
drivers/gpu/drm/i915/i915_gem.c | 898 +++++++++++++++++++++++++------
drivers/gpu/drm/i915/i915_gem_debugfs.c | 257 +++++++++
drivers/gpu/drm/i915/i915_gem_proc.c | 334 ------------
drivers/gpu/drm/i915/i915_gem_tiling.c | 31 +-
drivers/gpu/drm/i915/i915_reg.h | 22 +-
drivers/gpu/drm/i915/intel_bios.h | 12 +-
drivers/gpu/drm/i915/intel_crt.c | 66 ++-
drivers/gpu/drm/i915/intel_display.c | 406 +++++++++++++-
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
drivers/gpu/drm/i915/intel_tv.c | 148 +++---
include/drm/drmP.h | 77 +++-
include/drm/drm_pciids.h | 2 +
23 files changed, 2431 insertions(+), 1304 deletions(-)
create mode 100644 drivers/gpu/drm/drm_debugfs.c
create mode 100644 drivers/gpu/drm/drm_info.c
create mode 100644 drivers/gpu/drm/i915/i915_gem_debugfs.c
delete mode 100644 drivers/gpu/drm/i915/i915_gem_proc.c
--
Eric Anholt
eric@anholt.net eric.anholt@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2009-03-27 23:26 Eric Anholt
@ 2009-03-28 0:02 ` Linus Torvalds
0 siblings, 0 replies; 669+ messages in thread
From: Linus Torvalds @ 2009-03-28 0:02 UTC (permalink / raw)
To: Eric Anholt; +Cc: lkml, dri-devel
On Fri, 27 Mar 2009, Eric Anholt wrote:
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
Grr.
Guys, what the *hell* is wrong with you, when you can't even react to
trivial warnings and fix buggy code pointed out by the compiler?
If you had _ever_ compiled this on x86-64, you would have seen:
drivers/gpu/drm/i915/i915_gem_debugfs.c: In function ‘i915_gem_fence_regs_info’:
drivers/gpu/drm/i915/i915_gem_debugfs.c:201: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 7 has type ‘size_t’
and this is not the first time this has happened.
See commits f06da264cfb0f9444d41ca247213e419f90aa72a and
aeb565dfc3ac4c8b47c5049085b4c7bfb2c7d5d7.
What's so hard with keeping the build warning-clean, and fixing these
things _long_ before they hit my tree?
Some basic quality control. PLEASE.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>]
* Re: your mail
[not found] <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>
@ 2009-03-13 16:54 ` Ralf Nyren
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Nyren @ 2009-03-13 16:54 UTC (permalink / raw)
To: Rory Filer; +Cc: linux-kernel, Kevin Lloyd
Hi Rory,
Sounds great, send the driver and I'll give it a try at once. I'll report back
to you with the results.
Many thanks, Ralf
On Fri, 13 Mar 2009, Rory Filer wrote:
> Hi Ralf
>
>
>
> Kevin passed your email on to my attention and I think we can help you with this problem. We've been doing a lot of work on our drivers lately and I've got a freshly-ready version of sierra.c just for 2.6.28. We've done a lot of testing here and it seems pretty robust; perhaps you'd be willing to give it a try?
>
>
>
> Since I'm not sure about the etiquette for posting to this list, so I will attach the driver in a separate email to you.
>
>
>
> Regards
>
>
>
> Rory Filer
>
>
>
>
>
> -----Original Message-----
>
> From: Ralf Nyren [mailto:ralf@nyren.net]
>
> Sent: Friday, March 13, 2009 8:01 AM
>
> To: linux-kernel@vger.kernel.org
>
> Cc: Kevin Lloyd
>
> Subject: Sierra Wireless (MC8780) HSDPA speed issue
>
>
>
> Hi,
>
>
>
> I have a Sierra Wireless MC8780 UMTS card in a Fujitsu S6410 laptop running kernel 2.6.28.7. In kernel sierra driver v1.3.2.
>
>
>
> The card works but speed seems limited to approx 1.0 Mbit/s download using the linux driver. Testing the card in Windows XP yields download speeds close to 5.0 Mbit/s.
>
>
>
> I recently updated the firmware of the card to support HSDPA/HSUPA. The update gave the desired result in Windows but not in Linux. The speed improved in Linux but didn't increase above 1 Mbit/s.
>
>
>
> Is there any known driver limitations or is this a configuration issue?
>
>
>
> Please let me know if you need any additional information.
>
>
>
> Best regards, Ralf
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2009-03-11 10:47 Vitaly Mayatskikh
2009-03-11 14:59 ` your mail Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: Vitaly Mayatskikh @ 2009-03-11 10:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
Forgot to sign-off...
(v)scnprintf says it should return 0 when size is 0, but doesn't do
so. Also size_t is unsigned, it can't be less then 0. Fix the code and
comments.
Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com>
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 0fbd012..8e75c7e 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -947,7 +947,7 @@ EXPORT_SYMBOL(vsnprintf);
* @args: Arguments for the format string
*
* The return value is the number of characters which have been written into
- * the @buf not including the trailing '\0'. If @size is <= 0 the function
+ * the @buf not including the trailing '\0'. If @size is == 0 the function
* returns 0.
*
* Call this function if you are already dealing with a va_list.
@@ -958,7 +958,8 @@ EXPORT_SYMBOL(vsnprintf);
int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
int i;
-
+ if (!size)
+ return 0;
i=vsnprintf(buf,size,fmt,args);
return (i >= size) ? (size - 1) : i;
}
@@ -998,7 +999,7 @@ EXPORT_SYMBOL(snprintf);
* @...: Arguments for the format string
*
* The return value is the number of characters written into @buf not including
- * the trailing '\0'. If @size is <= 0 the function returns 0.
+ * the trailing '\0'. If @size is == 0 the function returns 0.
*/
int scnprintf(char * buf, size_t size, const char *fmt, ...)
@@ -1006,6 +1007,8 @@ int scnprintf(char * buf, size_t size, const char *fmt, ...)
va_list args;
int i;
+ if (!size)
+ return 0;
va_start(args, fmt);
i = vsnprintf(buf, size, fmt, args);
va_end(args);
--
wbr, Vitaly
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2009-03-11 10:47 Vitaly Mayatskikh
@ 2009-03-11 14:59 ` Linus Torvalds
2009-03-11 17:23 ` Vitaly Mayatskikh
0 siblings, 1 reply; 669+ messages in thread
From: Linus Torvalds @ 2009-03-11 14:59 UTC (permalink / raw)
To: Vitaly Mayatskikh; +Cc: linux-kernel
On Wed, 11 Mar 2009, Vitaly Mayatskikh wrote:
>
> (v)scnprintf says it should return 0 when size is 0, but doesn't do
> so. Also size_t is unsigned, it can't be less then 0. Fix the code and
> comments.
That is bogus.
The code really does (od "did"? Maybe you removed it) check for _smaller_
than 0:
int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
...
/* Reject out-of-range values early. Large positive sizes are
used for unknown buffer sizes. */
if (unlikely((int) size < 0)) {
/* There can be only one.. */
static char warn = 1;
WARN_ON(warn);
warn = 0;
return 0;
}
...
because under/overflows have happened.
The kernel is _not_ a regular libc. We have different rules.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2009-03-11 14:59 ` your mail Linus Torvalds
@ 2009-03-11 17:23 ` Vitaly Mayatskikh
0 siblings, 0 replies; 669+ messages in thread
From: Vitaly Mayatskikh @ 2009-03-11 17:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Vitaly Mayatskikh, linux-kernel
> On Wed, 11 Mar 2009, Vitaly Mayatskikh wrote:
> >
> > (v)scnprintf says it should return 0 when size is 0, but doesn't do
> > so. Also size_t is unsigned, it can't be less then 0. Fix the code and
> > comments.
>
> That is bogus.
>
> The code really does (od "did"? Maybe you removed it) check for _smaller_
> than 0:
Well, (v)scnprintf says it returns 0 for size <= 0, but really returns
-1 for size == 0. I think, this code can't return 0 for size == 0:
i=vsnprintf(buf,size,fmt,args);
return (i >= size) ? (size - 1) : i;
Systemtap's script:
function test:long()
%{
char tmp[256];
long err;
err = scnprintf(tmp, 0, "%lu", (long)128);
THIS->__retvalue = err;
%}
probe begin
{
printf("scnprintf returns %d\n", test());
}
stap -g scnprintf.stp
scnprintf returns -1
--
wbr, Vitaly
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2009-02-13 0:45 Youngwhan Kim
2009-02-13 3:40 ` your mail Johannes Weiner
0 siblings, 1 reply; 669+ messages in thread
From: Youngwhan Kim @ 2009-02-13 0:45 UTC (permalink / raw)
To: linux-kernel
unsubscribe
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2009-01-20 3:21 Paul Mundt
0 siblings, 0 replies; 669+ messages in thread
From: Paul Mundt @ 2009-01-20 3:21 UTC (permalink / raw)
To: linux-sh
On Tue, Jan 13, 2009 at 03:45:47PM +0000, Steve Glendinning wrote:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Tue, 13 Jan 2009 15:22:36 +0000
> Subject: [PATCH 0/3] sh: convert platforms to use smsc911x
>
> This patchset, intended for 2.6.30, converts all in-tree sh platforms
> from smc911x to the actively maintained smsc911x driver.
>
> I've rebased and fixed up the patchset against the current linus tree,
> please let me know if I should rebase it against another instead.
>
> Steve Glendinning (3):
> sh: convert magicpanelr2 platform to use smsc911x
> sh: convert ap325rxa platform to use smsc911x
> sh: convert rsk7203 platform to use smsc911x
>
Thanks, these are already in the queue, they will be included in the next
merge.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2009-01-19 2:54 Gao, Yunpeng
2009-01-19 3:07 ` your mail Matthew Wilcox
0 siblings, 1 reply; 669+ messages in thread
From: Gao, Yunpeng @ 2009-01-19 2:54 UTC (permalink / raw)
To: linux-ia64; +Cc: linux-kernel
Hi all,
I have to use 64bit variable in my 2.6.27 kernel NAND driver as below:
---------------------------------------------------------------------------
u64 NAND_capacity;
unsigned int block_num, block_size;
...
block_num = NAND_capacity / block_size;
---------------------------------------------------------------------------
but it failed when compiling and reports 'undefined reference to `__udivdi3'.
Does any idea about this? I need to include some special head file or change something in Kconfig?
BTW, the environment is Fedora Core 9, gcc 4.3.0.
Thanks a lot.
Rgds,
Yunpeng Gao
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2009-01-19 2:54 Gao, Yunpeng
@ 2009-01-19 3:07 ` Matthew Wilcox
0 siblings, 0 replies; 669+ messages in thread
From: Matthew Wilcox @ 2009-01-19 3:07 UTC (permalink / raw)
To: Gao, Yunpeng; +Cc: linux-ia64, linux-kernel
On Mon, Jan 19, 2009 at 10:54:02AM +0800, Gao, Yunpeng wrote:
> I have to use 64bit variable in my 2.6.27 kernel NAND driver as below:
> ---------------------------------------------------------------------------
> u64 NAND_capacity;
> unsigned int block_num, block_size;
> ...
> block_num = NAND_capacity / block_size;
> ---------------------------------------------------------------------------
> but it failed when compiling and reports 'undefined reference to `__udivdi3'.
Presumably block_size is a power of two, so you can do:
block_num = NAND_capacity >> block_shift;
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2009-01-13 6:10 Steven Rostedt
2009-01-13 13:21 ` your mail Steven Rostedt
0 siblings, 1 reply; 669+ messages in thread
From: Steven Rostedt @ 2009-01-13 6:10 UTC (permalink / raw)
To: linux-kernel
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2009-01-11 3:41 Jose Luis Marchetti
2009-01-11 6:47 ` your mail Jesper Juhl
0 siblings, 1 reply; 669+ messages in thread
From: Jose Luis Marchetti @ 2009-01-11 3:41 UTC (permalink / raw)
To: linux-kernel
Hi,
I would like to open/read/write/close a regular file from my device
driver.
I think it would be possible, but I am confused, the "The Linux Kernel
Module Programming Guide" states that I can not use standard libraries
from within a module, I know the standard library ends up calling
system calls, but which calls should I use to deal with regular
files ?
I am developing a Ethernet driver and the Mac address configuration
Thanks in advance!
José Luís Marchetti
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
^ permalink raw reply [flat|nested] 669+ messages in thread* (unknown),
@ 2008-08-13 14:54 aneesh.kumar
2008-08-13 15:16 ` your mail Aneesh Kumar K.V
0 siblings, 1 reply; 669+ messages in thread
From: aneesh.kumar @ 2008-08-13 14:54 UTC (permalink / raw)
To: pasky; +Cc: git, Aneesh Kumar K.V
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
topgit: Implement tg-import
This can be used to import a set of commits
between range specified by range1..range2
This should help us to convert an already
existing quilt, stgit branches to topgit
managed one
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
Makefile | 2 +-
README | 7 ++++++
tg-create.sh | 22 ++++++++----------
tg-export.sh | 2 +-
tg-import.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 6eade1e..95624ac 100644
--- a/Makefile
+++ b/Makefile
@@ -6,7 +6,7 @@ sharedir = $(PREFIX)/share/topgit
hooksdir = $(cmddir)/hooks
-commands_in = tg-create.sh tg-delete.sh tg-export.sh tg-info.sh tg-patch.sh tg-summary.sh tg-update.sh
+commands_in = tg-create.sh tg-delete.sh tg-export.sh tg-info.sh tg-patch.sh tg-summary.sh tg-update.sh tg-import.sh
hooks_in = hooks/pre-commit.sh
commands_out = $(patsubst %.sh,%,$(commands_in))
diff --git a/README b/README
index b58a1b4..8b8f4d7 100644
--- a/README
+++ b/README
@@ -330,6 +330,13 @@ tg export
TODO: Make stripping of [PATCH] and other prefixes configurable
TODO: --mbox option for other mode of operation
+tg import
+~~~~~~~~
+ Import the commits between the given revision range into
+ a topgit managed branch
+
+ Usage: tg import rev1..rev2
+
tg update
~~~~~~~~~
Update the current topic branch wrt. changes in the branches
diff --git a/tg-create.sh b/tg-create.sh
index 939af33..6cce7ed 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -31,17 +31,18 @@ done
deps="${deps# }"
if [ -z "$deps" ]; then
- if [ -z "$name" -a -s "$git_dir/top-name" -a -s "$git_dir/top-deps" -a -s "$git_dir/top-merge" ]; then
- # We are setting up the base branch now; resume merge!
- name="$(cat "$git_dir/top-name")"
+ head="$(git symbolic-ref HEAD)"
+ bname="${head#refs/top-bases/}"
+ if [ "$bname" != "$head" -a -s "$git_dir/top-deps" -a -s "$git_dir/top-merge" ]; then
+ # We are on a base branch now; resume merge!
deps="$(cat "$git_dir/top-deps")"
merge="$(cat "$git_dir/top-merge")"
+ name="$bname"
restarted=1
info "Resuming $name setup..."
else
# The common case
[ -z "$name" ] && die "no branch name given"
- head="$(git symbolic-ref HEAD)"
deps="${head#refs/heads/}"
[ "$deps" != "$head" ] || die "refusing to auto-depend on non-head ref ($head)"
info "Automatically marking dependency on $deps"
@@ -58,7 +59,7 @@ done
die "branch '$name' already exists"
# Clean up any stale stuff
-rm -f "$git_dir/top-name" "$git_dir/top-deps" "$git_dir/top-merge"
+rm -f "$git_dir/top-deps" "$git_dir/top-merge"
## Create base
@@ -68,8 +69,7 @@ if [ -n "$merge" ]; then
branch="${merge%% *}"
merge="${merge#* }"
info "Creating $name base from $branch..."
- # We create a detached head so that we can abort this operation
- git checkout -q "$(git rev-parse "$branch")"
+ switch_to_base "$name" "$branch"
fi
@@ -83,10 +83,9 @@ while [ -n "$merge" ]; do
if ! git merge "$branch"; then
info "Please commit merge resolution and call: tg create"
- info "It is also safe to abort this operation using:"
- info "git reset --hard some_branch"
- info "(You are on a detached HEAD now.)"
- echo "$name" >"$git_dir/top-name"
+ info "It is also safe to abort this operation using \`git reset --hard\`"
+ info "but please remember you are on the base branch now;"
+ info "you will want to switch to a different branch."
echo "$deps" >"$git_dir/top-deps"
echo "$merge" >"$git_dir/top-merge"
exit 2
@@ -96,7 +95,6 @@ done
## Set up the topic branch
-git update-ref "refs/top-bases/$name" "HEAD" ""
git checkout -b "$name"
echo "$deps" | sed 's/ /\n/g' >"$root_dir/.topdeps"
diff --git a/tg-export.sh b/tg-export.sh
index 62361dd..73ad2ef 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -190,7 +190,7 @@ recurse_deps driver "$name"
if [ "$driver" = "collapse" ]; then
- git update-ref "refs/heads/$output" "$(cat "$playground/$name")" ""
+ git update-ref "refs/heads/$output" "$(cat "$playground/$name")"
depcount="$(cat "$playground/^ticker" | wc -l)"
echo "Exported topic branch $name (total $depcount topics) to branch $output"
diff --git a/tg-import.sh b/tg-import.sh
new file mode 100644
index 0000000..6c991c5
--- /dev/null
+++ b/tg-import.sh
@@ -0,0 +1,68 @@
+#!/bin/sh
+# TopGit - A different patch queue manager
+# GPLv2
+
+
+tg_get_commit_msg()
+{
+ commit="$1"
+ git log -1 --pretty=format:"From: %an <%ae>%n%n%s%n%n%b" "$commit"
+}
+
+tg_get_branch_name()
+{
+ # nice sed script from git-format-patch.sh
+ commit="$1"
+ titleScript='
+ s/[^-a-z.A-Z_0-9]/-/g
+ s/\.\.\.*/\./g
+ s/\.*$//
+ s/--*/-/g
+ s/^-//
+ s/-$//
+ q
+'
+ git log -1 --pretty=format:"%s" "$commit" | sed -e "$titleScript"
+}
+
+tg_process_commit()
+{
+ commit="$1"
+ branch_name=$(tg_get_branch_name "$commit")
+ echo "Importing $commit to $branch_name"
+ tg create tp/"$branch_name"
+ git read-tree "$commit"
+ tg_get_commit_msg "$commit" > .topmsg
+ git add -f .topmsg .topdeps
+ git commit -C "$commit"
+}
+
+# nice arg verification stolen from git-format-patch.sh
+for revpair
+do
+ case "$revpair" in
+ ?*..?*)
+ rev1=`expr "z$revpair" : 'z\(.*\)\.\.'`
+ rev2=`expr "z$revpair" : 'z.*\.\.\(.*\)'`
+ ;;
+ *)
+ die "Unknow range spec $revpair"
+ ;;
+ esac
+ git rev-parse --verify "$rev1^0" >/dev/null 2>&1 ||
+ die "Not a valid rev $rev1 ($revpair)"
+ git rev-parse --verify "$rev2^0" >/dev/null 2>&1 ||
+ die "Not a valid rev $rev2 ($revpair)"
+ git cherry -v "$rev1" "$rev2" |
+ while read sign rev comment
+ do
+ case "$sign" in
+ '-')
+ info "Merged already: $comment"
+ ;;
+ *)
+ tg_process_commit "$rev"
+ ;;
+ esac
+ done
+done
--
tg: (f27e693..) tp/topgit-Implement-tg-import (depends on: master)
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2008-08-13 14:54 (unknown), aneesh.kumar
@ 2008-08-13 15:16 ` Aneesh Kumar K.V
0 siblings, 0 replies; 669+ messages in thread
From: Aneesh Kumar K.V @ 2008-08-13 15:16 UTC (permalink / raw)
To: aneesh.kumar; +Cc: pasky, git
On Wed, Aug 13, 2008 at 08:24:28PM +0530, aneesh.kumar@gmail.com wrote:
> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
>
> topgit: Implement tg-import
>
> This can be used to import a set of commits
> between range specified by range1..range2
> This should help us to convert an already
> existing quilt, stgit branches to topgit
> managed one
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
>
> ---
> Makefile | 2 +-
> README | 7 ++++++
> tg-create.sh | 22 ++++++++----------
> tg-export.sh | 2 +-
> tg-import.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 14 deletions(-)
>
tg-create.sh and tg-export.sh should not be part of this patch. I will
send a new version.
-aneesh
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2008-07-27 1:11 David Boulding
2008-07-28 14:14 ` your mail Eric Leblond
0 siblings, 1 reply; 669+ messages in thread
From: David Boulding @ 2008-07-27 1:11 UTC (permalink / raw)
To: netfilter
Hey all,
I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
capture packets of interest on a bridge for analysis (firewall).
I use nfq_get_payload() to grab everything from the IP layer and on, but I
was wondering if there was any way to get the raw MAC layer.
Is there any command like nfq_get_payload() that will return everything
similar to what you would get using wireshark or ethereal?
Thanks,
Dave
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2008-07-27 1:11 (unknown), David Boulding
@ 2008-07-28 14:14 ` Eric Leblond
2008-07-28 14:42 ` David Boulding
[not found] ` <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
0 siblings, 2 replies; 669+ messages in thread
From: Eric Leblond @ 2008-07-28 14:14 UTC (permalink / raw)
To: David Boulding; +Cc: netfilter
Hello,
On Saturday, 2008 July 26 at 21:11:08 -0400, David Boulding wrote:
> Hey all,
>
> I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> capture packets of interest on a bridge for analysis (firewall).
> I use nfq_get_payload() to grab everything from the IP layer and on, but I
> was wondering if there was any way to get the raw MAC layer.
> Is there any command like nfq_get_payload() that will return everything
> similar to what you would get using wireshark or ethereal?
You can use nfq_get_packet_hw():
Retrieves the hardware address associated with the given queued packet.
For ethernet packets, the hardware address returned (if any) will be the
MAC address of the packet source host. The destination MAC address is not
known until after POSTROUTING and a successful ARP request, so cannot
currently be retrieved.
The nfqnl_msg_packet_hw structure is defined in "libnetfilter_queue/libnetfilter_queue.h" as:
struct nfqnl_msg_packet_hw {
u_int16_t hw_addrlen;
u_int16_t _pad;
u_int8_t hw_addr[8];
} __attribute__ ((packed));
.
http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html
BR,
--
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2008-07-28 14:14 ` your mail Eric Leblond
@ 2008-07-28 14:42 ` David Boulding
[not found] ` <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
1 sibling, 0 replies; 669+ messages in thread
From: David Boulding @ 2008-07-28 14:42 UTC (permalink / raw)
To: Eric Leblond, David Boulding, netfilter
Thanks for the reply.
I knew of nfq_get_packet_hw(), but I'm looking for a way to get the
raw byte array of the header that I get from the nfq_get_payload()
call. I'm not only looking for the MAC header information (which
nfq_get_packet_hw() will give me easy enough), but whatever else is
there, for example PPPoE and PPP header information. Is there anyway
to get that?
Thanks,
Dave
On Mon, Jul 28, 2008 at 10:14 AM, Eric Leblond <eric@inl.fr> wrote:
>
> Hello,
>
> On Saturday, 2008 July 26 at 21:11:08 -0400, David Boulding wrote:
> > Hey all,
> >
> > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> > capture packets of interest on a bridge for analysis (firewall).
> > I use nfq_get_payload() to grab everything from the IP layer and on, but I
> > was wondering if there was any way to get the raw MAC layer.
> > Is there any command like nfq_get_payload() that will return everything
> > similar to what you would get using wireshark or ethereal?
>
> You can use nfq_get_packet_hw():
>
> Retrieves the hardware address associated with the given queued packet.
> For ethernet packets, the hardware address returned (if any) will be the
> MAC address of the packet source host. The destination MAC address is not
> known until after POSTROUTING and a successful ARP request, so cannot
> currently be retrieved.
>
> The nfqnl_msg_packet_hw structure is defined in "libnetfilter_queue/libnetfilter_queue.h" as:
>
> struct nfqnl_msg_packet_hw {
> u_int16_t hw_addrlen;
> u_int16_t _pad;
> u_int8_t hw_addr[8];
> } __attribute__ ((packed));
> .
>
> http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
^ permalink raw reply [flat|nested] 669+ messages in thread[parent not found: <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>]
* Re: your mail
[not found] ` <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
@ 2008-07-28 14:43 ` Eric Leblond
2008-07-28 15:33 ` David Boulding
0 siblings, 1 reply; 669+ messages in thread
From: Eric Leblond @ 2008-07-28 14:43 UTC (permalink / raw)
To: David Boulding; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Hello,
On Monday, 2008 July 28 at 10:21:43 -0400, David Boulding wrote:
> Thanks for the reply.
> I knew of nfq_get_packet_hw(), but I'm looking for a way to get the raw byte
> > >
> > > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> > > capture packets of interest on a bridge for analysis (firewall).
As you said "analysis", you may only want to "sniff" packet. In that case,
you can use NFLOG (latest git) or ULOG.
NFQUEUE moudle uses the dev_parse_header() function which only return the
source hardware address. You will not be able to retrieve the wanted
information without patching the kernel.
BR,
--
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2008-07-28 14:43 ` Eric Leblond
@ 2008-07-28 15:33 ` David Boulding
2008-07-29 7:11 ` Eric Leblond
0 siblings, 1 reply; 669+ messages in thread
From: David Boulding @ 2008-07-28 15:33 UTC (permalink / raw)
To: Eric Leblond, David Boulding, netfilter
I've never heard of NFLOG or ULOG, is there any documentation under
netfilter on how to use it? How would I get the data that I want (to
sniff) using NFLOG/ULOG?
Dave
On Mon, Jul 28, 2008 at 10:43 AM, Eric Leblond <eric@inl.fr> wrote:
> Hello,
>
> On Monday, 2008 July 28 at 10:21:43 -0400, David Boulding wrote:
>> Thanks for the reply.
>> I knew of nfq_get_packet_hw(), but I'm looking for a way to get the raw byte
>> > >
>> > > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
>> > > capture packets of interest on a bridge for analysis (firewall).
>
> As you said "analysis", you may only want to "sniff" packet. In that case,
> you can use NFLOG (latest git) or ULOG.
>
> NFQUEUE moudle uses the dev_parse_header() function which only return the
> source hardware address. You will not be able to retrieve the wanted
> information without patching the kernel.
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkiN2x0ACgkQnxA7CdMWjzJSmQCdHBt2ro5Tx7m5GbWhl7uGZz7l
> 5H8Anjc9CaBwO/tOVaywfm+WwzeeBayE
> =felb
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2008-07-28 15:33 ` David Boulding
@ 2008-07-29 7:11 ` Eric Leblond
2008-07-29 20:09 ` David Boulding
0 siblings, 1 reply; 669+ messages in thread
From: Eric Leblond @ 2008-07-29 7:11 UTC (permalink / raw)
To: David Boulding; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Hello,
On Monday, 2008 July 28 at 11:33:24 -0400, David Boulding wrote:
> I've never heard of NFLOG or ULOG, is there any documentation under
> netfilter on how to use it? How would I get the data that I want (to
> sniff) using NFLOG/ULOG?
For ULOG, you can have a look at ulogd or ulogd2 code.
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=blob;f=input/packet/ulogd_inppkt_ULOG.c;h=c00d9bf8a965be7f961738892e19191efcf8f691;hb=0b789ea9bf810497845456e9b83bff8c5ae5ca23
By the way, as ulogd2 uses a plugin mechanism, you may be able to build
what you want by coding an ulogd2 plugin. It can provide you a way to
code something independant from low level (NFLOG or ULOG can be used as
input without changing your plugin).
A mini doc about ulogd2 hacking is available here:
http://home.regit.org/?page_id=90
For NFLOG, you need to use latest git for kernel and libnetfilter_log.
The following functions are available:
- nflog_get_hwtype: to fetch hardware type (and thus give the parser to
use)
- nflog_get_msg_packet_hwhdrlen: to get hardware header len
- nflog_get_msg_packet_hwhdr: get hardware datas
BR,
--
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2008-07-29 7:11 ` Eric Leblond
@ 2008-07-29 20:09 ` David Boulding
0 siblings, 0 replies; 669+ messages in thread
From: David Boulding @ 2008-07-29 20:09 UTC (permalink / raw)
To: Eric Leblond, David Boulding, netfilter
Thanks for the help!
Dave
On Tue, Jul 29, 2008 at 3:11 AM, Eric Leblond <eric@inl.fr> wrote:
> Hello,
>
> On Monday, 2008 July 28 at 11:33:24 -0400, David Boulding wrote:
>> I've never heard of NFLOG or ULOG, is there any documentation under
>> netfilter on how to use it? How would I get the data that I want (to
>> sniff) using NFLOG/ULOG?
>
> For ULOG, you can have a look at ulogd or ulogd2 code.
> http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=blob;f=input/packet/ulogd_inppkt_ULOG.c;h=c00d9bf8a965be7f961738892e19191efcf8f691;hb=0b789ea9bf810497845456e9b83bff8c5ae5ca23
> By the way, as ulogd2 uses a plugin mechanism, you may be able to build
> what you want by coding an ulogd2 plugin. It can provide you a way to
> code something independant from low level (NFLOG or ULOG can be used as
> input without changing your plugin).
>
> A mini doc about ulogd2 hacking is available here:
> http://home.regit.org/?page_id=90
>
> For NFLOG, you need to use latest git for kernel and libnetfilter_log.
>
> The following functions are available:
>
> - nflog_get_hwtype: to fetch hardware type (and thus give the parser to
> use)
> - nflog_get_msg_packet_hwhdrlen: to get hardware header len
> - nflog_get_msg_packet_hwhdr: get hardware datas
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIjsKinxA7CdMWjzIRAofmAJ9mi4P5SRkPugu8wADwtmB2LlHmigCfWjNn
> E77TPzKV3LStdfYgpFCobVA=
> =ruvK
> -----END PGP SIGNATURE-----
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2008-07-01 22:48 Henrique de Moraes Holschuh
2008-07-01 22:53 ` your mail Henrique de Moraes Holschuh
0 siblings, 1 reply; 669+ messages in thread
From: Henrique de Moraes Holschuh @ 2008-07-01 22:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Buesch, Adel Gadllah, linux-wireless, stefano.brivio,
Larry Finger, John W. Linville, Ivo van Doorn
Bcc:
Subject: Re: [PATCH/RFC] b43: remove input device usage for rfkill
Reply-To:
In-Reply-To: <1214937876.3462.10.camel@johannes.berg>
X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F
1CDB 0FE3
Dmitry (input layer maintainer) added to CC. This is a [gross misuse of
the] input layer issue.
On Tue, 01 Jul 2008, Johannes Berg wrote:
> On Tue, 2008-07-01 at 15:41 -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, 01 Jul 2008, Johannes Berg wrote:
> > > > This is very important. It will caracterize that input pin as either an
> > > > hardware rfkill line, or as an input device (in which case I would be wrong
> > > > when I asked to remove the input support from b43, but one step at a time).
> > >
> > > Sorry, no, I think I got confused, it should be a hardware rfkill line.
> >
> > I'd like to have a certain response for this. Can you test, and assert
> > whether it is a rfkill line or not?
> >
> > And, if it IS a rfkill line, I still need to know if it is flip-flop-like or
> > not... I am not certain I got the right idea (I understood it was NOT
> > flip-flop-like).
>
> No, it's not flip-flop, there's definitely an on/off bit that always
> matches the button/hardware state.
Ok, so based on the above information, here is the sad truth: B43 has been
buggy all along, and in more ways than I would have expected.
1. That input pin is a hardware rfkill line. It has to contribute to the
device-wide rfkill class state. The rfkill API, before my patchset, simply
did NOT support such a thing (but some where in the incorrect impression
that it could, through the input layer. That's not true).
2. hardware rfkill lines are NOT flip-flop, so if it is ever connected to an
input device, it has to work like a switch. It has to tell the world
whether it is active or not active. It doesn't go "pressed/unpressed" to
switch from active to inactive, then "pressed/unpressed" to switch to
inactive back to active (THAT would be a KEY_*).
So, b43 should NEVER have issued KEY_WLAN in the first place. It should
have asked for a EV_SW SW_WLAN event, added EV_SW SW_WLAN handling to
rfkill-input (for completeness), and used that one instead of KEY_WLAN.
And this has *nothing* to do with rfkill at all. It is pure input layer
stuff.
For those who are not used to the input layer, the rule is very simple (as
it was explained to me): Input events come from anywhere and evertwhere, and
are all equal. You are not, and I do mean NOT allowed to have KEY_WLAN
coming from b43 be any more special to the system than KEY_WLAN coming from
a USB keyboard that was plugged into the system.
The entire system fights against you if you try to go against this rule.
Userspace doesn't, as a rule, expect that EV_KEY KEY_FOO from one input
device is to be treated any differently than EV_KEY KEY_FOO from some other
input device. rfkill-input and other in-kernel input handlers don't,
either.
b43 cannot even add an input handle to trap and update its "emulation of a
switch through KEY_*" state, as it has no way of knowing WHAT userspace or
rfkill-input is going to do with KEY_WLAN in the first place. What if it is
not a toggle, but rather it is being diverted to launch an application that
asks the user? What if it is a multi-value selector, that changes state at
every KEY_WLAN event, and has more than two states?
THIS is the reason why the input layer must not EVER be used as an IPC to
propagate state changes, BTW. Handlers *are* allowed to just ignore events,
for one.
So, unless that input pin in b43 is really a flip-flop and point (1) above
is wrong (thus making most of this email not apply to b43), I see no way to
salvage this mess, at all.
IMO, this all means that the input layer support in b43 has to go. It is
not the best place to add a EV_SW SW_WLAN-issuing input device anyway, and
userspace will already need to be reconfigured to deal with the fact that
b43 simply cannot issue KEY_WLAN, so it is not even worth the effort to add
a temporary hack to issue such events.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2008-07-01 22:48 Henrique de Moraes Holschuh
@ 2008-07-01 22:53 ` Henrique de Moraes Holschuh
0 siblings, 0 replies; 669+ messages in thread
From: Henrique de Moraes Holschuh @ 2008-07-01 22:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Buesch, Adel Gadllah, linux-wireless, stefano.brivio,
Larry Finger, John W. Linville, Ivo van Doorn
On Tue, 01 Jul 2008, Henrique de Moraes Holschuh wrote:
> Bcc:
> Subject: Re: [PATCH/RFC] b43: remove input device usage for rfkill
> Reply-To:
> In-Reply-To: <1214937876.3462.10.camel@johannes.berg>
> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F
> 1CDB 0FE3
>
[...]
Sorry about this, hit the wrong key while adding Dmitry to the CC. I have
resent it properly.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2008-05-24 20:05 Thomas Gleixner
2008-05-24 21:06 ` Daniel Walker
0 siblings, 1 reply; 669+ messages in thread
From: Thomas Gleixner @ 2008-05-24 20:05 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-kernel
On Sat, 24 May 2008, Daniel Walker wrote:
> > There is no kernel side controlled handover of a normal futex. The
> > woken up waiters race for it and a low prio thread on another CPU can
> > steal it even if there is a high prio waiter woken up.
>
> After reading futex_wake, Doesn't it depend how many waiters are woken?
> Given that comes from userspace, glibc could wake a single waiter and
> obtain a priority ordering, couldn't it?
It could and it does. Still this does not protect against another
lower prio task taking the futex before the woken waiter can do it,
which is happening way more often than your theoretical setscheduler
case. Again, setscheduler is called in startup code of a program not
at arbitrary points during runtime, which rely on lock ordering.
> > The plist add on works correct in most of the cases, nothing else. To
> > achieve full correctness there is much more necessary than this
> > setscheduler issue. The plist changes were accepted because the
> > overhead is really minimal, but achieving full correctness would hurt
> > performance badly.
>
> If that's the requirement then code that cleans up the corner case that
> I've identified, which is also minimal should be acceptable .. Since
> it's meeting the same requirement you layed out above for the original
> plist changes.
Your code solves the least to worry about corner case and hurts
performance for nothing. You take extra locks in the hot path for no
benefit.
Aside of that it introduces lock order problems and we can really do
without extra useless complexity in the futex code.
You can argue in circles. This is not going anywhere near mainline.
Thanks,
tglx
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2008-05-24 20:05 Thomas Gleixner
@ 2008-05-24 21:06 ` Daniel Walker
0 siblings, 0 replies; 669+ messages in thread
From: Daniel Walker @ 2008-05-24 21:06 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
On Sat, 2008-05-24 at 22:05 +0200, Thomas Gleixner wrote:
> > If that's the requirement then code that cleans up the corner case that
> > I've identified, which is also minimal should be acceptable .. Since
> > it's meeting the same requirement you layed out above for the original
> > plist changes.
>
> Your code solves the least to worry about corner case and hurts
> performance for nothing. You take extra locks in the hot path for no
> benefit.
>
> Aside of that it introduces lock order problems and we can really do
> without extra useless complexity in the futex code.
>
> You can argue in circles. This is not going anywhere near mainline.
Above I'm not speaking about my code, I'm only speaking in terms of a
solution to this case, even if it isn't mine..
Daniel
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2008-05-20 12:34 Lukas Hejtmanek
2008-05-20 15:20 ` your mail Alan Stern
0 siblings, 1 reply; 669+ messages in thread
From: Lukas Hejtmanek @ 2008-05-20 12:34 UTC (permalink / raw)
To: Oliver Neukum
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, stern, greg, linux-usb
<stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
Bcc:
Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
until reload of ehci-hcd
Reply-To:
In-Reply-To: <200805201327.34678.oliver@neukum.org>
X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > done.
> > http://bugzilla.kernel.org/show_bug.cgi?id=10630
>
> Aha. Thanks.
> Please recompile without CONFIG_USB_SUSPEND
Hm, without USB_SUSPEND it works. So what next, considered fixed or any
further investigation is needed?
--
Lukáš Hejtmánek
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2008-05-20 12:34 Lukas Hejtmanek
@ 2008-05-20 15:20 ` Alan Stern
0 siblings, 0 replies; 669+ messages in thread
From: Alan Stern @ 2008-05-20 15:20 UTC (permalink / raw)
To: Lukas Hejtmanek
Cc: Oliver Neukum, Rafael J. Wysocki, Linux Kernel Mailing List,
greg, linux-usb
On Tue, 20 May 2008, Lukas Hejtmanek wrote:
> <stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
> Bcc:
> Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
> until reload of ehci-hcd
> Reply-To:
> In-Reply-To: <200805201327.34678.oliver@neukum.org>
> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
>
> On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > > done.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=10630
> >
> > Aha. Thanks.
> > Please recompile without CONFIG_USB_SUSPEND
>
> Hm, without USB_SUSPEND it works. So what next, considered fixed or any
> further investigation is needed?
No further investigation is needed. I tried doing essentially the same
thing on my system and the same problem occurred.
It is caused by the way ehci-hcd "auto-clears" the port
change-suspend feature. This patch should fix the problem. Please
try it out and let us know if it works.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci.h
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci.h
+++ usb-2.6/drivers/usb/host/ehci.h
@@ -97,6 +97,8 @@ struct ehci_hcd { /* one per controlle
dedicated to the companion controller */
unsigned long owned_ports; /* which ports are
owned by the companion during a bus suspend */
+ unsigned long port_c_suspend; /* which ports have
+ the change-suspend feature turned on */
/* per-HC memory pools (could be per-bus, but ...) */
struct dma_pool *qh_pool; /* qh per active urb */
Index: usb-2.6/drivers/usb/host/ehci-hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-hub.c
+++ usb-2.6/drivers/usb/host/ehci-hub.c
@@ -609,7 +609,7 @@ static int ehci_hub_control (
}
break;
case USB_PORT_FEAT_C_SUSPEND:
- /* we auto-clear this feature */
+ clear_bit(wIndex, &ehci->port_c_suspend);
break;
case USB_PORT_FEAT_POWER:
if (HCS_PPC (ehci->hcs_params))
@@ -688,7 +688,7 @@ static int ehci_hub_control (
/* resume completed? */
else if (time_after_eq(jiffies,
ehci->reset_done[wIndex])) {
- status |= 1 << USB_PORT_FEAT_C_SUSPEND;
+ set_bit(wIndex, &ehci->port_c_suspend);
ehci->reset_done[wIndex] = 0;
/* stop resume signaling */
@@ -765,6 +765,8 @@ static int ehci_hub_control (
status |= 1 << USB_PORT_FEAT_RESET;
if (temp & PORT_POWER)
status |= 1 << USB_PORT_FEAT_POWER;
+ if (test_bit(wIndex, &ehci->port_c_suspend))
+ status |= 1 << USB_PORT_FEAT_C_SUSPEND;
#ifndef VERBOSE_DEBUG
if (status & ~0xffff) /* only if wPortChange is interesting */
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2008-01-22 0:00 Thiemo Seufer
2008-01-28 17:51 ` your mail Ralf Baechle
0 siblings, 1 reply; 669+ messages in thread
From: Thiemo Seufer @ 2008-01-22 0:00 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
Hello All,
This patch moves the micro-assembler in a separate implementation, as
it is useful for further run-time optimizations. The only change in
behaviour is cutting down printk noise at kernel startup time.
Checkpatch complains about macro parameters which aren't protected by
parentheses. I believe this is a flaw in checkpatch, the paste operator
used in those macros won't work with parenthesised parameters.
Tested on:
- Qemu 32-bit little endian
- BCM1480 64-bit big endian
Thiemo
---
Split the micro-assembler from tlbex.c.
Signed-off-by: Thiemo Seufer <ths@networkno.de>
diff --git a/arch/mips/mm/Makefile b/arch/mips/mm/Makefile
index 32fd5db..c6f832e 100644
--- a/arch/mips/mm/Makefile
+++ b/arch/mips/mm/Makefile
@@ -3,7 +3,8 @@
#
obj-y += cache.o dma-default.o extable.o fault.o \
- init.o pgtable.o tlbex.o tlbex-fault.o
+ init.o pgtable.o tlbex.o tlbex-fault.o \
+ uasm.o
obj-$(CONFIG_32BIT) += ioremap.o pgtable-32.o
obj-$(CONFIG_64BIT) += pgtable-64.o
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index a61246d..48a2589 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -5,7 +5,7 @@
*
* Synthesize TLB refill handlers at runtime.
*
- * Copyright (C) 2004,2005,2006 by Thiemo Seufer
+ * Copyright (C) 2004,2005,2006,2008 Thiemo Seufer
* Copyright (C) 2005 Maciej W. Rozycki
* Copyright (C) 2006 Ralf Baechle (ralf@linux-mips.org)
*
@@ -19,8 +19,6 @@
* (Condolences to Napoleon XIV)
*/
-#include <stdarg.h>
-
#include <linux/mm.h>
#include <linux/kernel.h>
#include <linux/types.h>
@@ -30,11 +28,11 @@
#include <asm/pgtable.h>
#include <asm/cacheflush.h>
#include <asm/mmu_context.h>
-#include <asm/inst.h>
-#include <asm/elf.h>
#include <asm/smp.h>
#include <asm/war.h>
+#include "uasm.h"
+
static inline int r45k_bvahwbug(void)
{
/* XXX: We should probe for the presence of this bug, but we don't. */
@@ -72,371 +70,9 @@ static __init int __attribute__((unused)) m4kc_tlbp_war(void)
(PRID_COMP_MIPS | PRID_IMP_4KC);
}
-/*
- * A little micro-assembler, intended for TLB refill handler
- * synthesizing. It is intentionally kept simple, does only support
- * a subset of instructions, and does not try to hide pipeline effects
- * like branch delay slots.
- */
-
-enum fields
-{
- RS = 0x001,
- RT = 0x002,
- RD = 0x004,
- RE = 0x008,
- SIMM = 0x010,
- UIMM = 0x020,
- BIMM = 0x040,
- JIMM = 0x080,
- FUNC = 0x100,
- SET = 0x200
-};
-
-#define OP_MASK 0x3f
-#define OP_SH 26
-#define RS_MASK 0x1f
-#define RS_SH 21
-#define RT_MASK 0x1f
-#define RT_SH 16
-#define RD_MASK 0x1f
-#define RD_SH 11
-#define RE_MASK 0x1f
-#define RE_SH 6
-#define IMM_MASK 0xffff
-#define IMM_SH 0
-#define JIMM_MASK 0x3ffffff
-#define JIMM_SH 0
-#define FUNC_MASK 0x3f
-#define FUNC_SH 0
-#define SET_MASK 0x7
-#define SET_SH 0
-
-enum opcode {
- insn_invalid,
- insn_addu, insn_addiu, insn_and, insn_andi, insn_beq,
- insn_beql, insn_bgez, insn_bgezl, insn_bltz, insn_bltzl,
- insn_bne, insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0,
- insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32,
- insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld,
- insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0,
- insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll,
- insn_sra, insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi,
- insn_tlbwr, insn_xor, insn_xori
-};
-
-struct insn {
- enum opcode opcode;
- u32 match;
- enum fields fields;
-};
-
-/* This macro sets the non-variable bits of an instruction. */
-#define M(a, b, c, d, e, f) \
- ((a) << OP_SH \
- | (b) << RS_SH \
- | (c) << RT_SH \
- | (d) << RD_SH \
- | (e) << RE_SH \
- | (f) << FUNC_SH)
-
-static __initdata struct insn insn_table[] = {
- { insn_addiu, M(addiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_addu, M(spec_op, 0, 0, 0, 0, addu_op), RS | RT | RD },
- { insn_and, M(spec_op, 0, 0, 0, 0, and_op), RS | RT | RD },
- { insn_andi, M(andi_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
- { insn_beq, M(beq_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
- { insn_beql, M(beql_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
- { insn_bgez, M(bcond_op, 0, bgez_op, 0, 0, 0), RS | BIMM },
- { insn_bgezl, M(bcond_op, 0, bgezl_op, 0, 0, 0), RS | BIMM },
- { insn_bltz, M(bcond_op, 0, bltz_op, 0, 0, 0), RS | BIMM },
- { insn_bltzl, M(bcond_op, 0, bltzl_op, 0, 0, 0), RS | BIMM },
- { insn_bne, M(bne_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
- { insn_daddiu, M(daddiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_daddu, M(spec_op, 0, 0, 0, 0, daddu_op), RS | RT | RD },
- { insn_dmfc0, M(cop0_op, dmfc_op, 0, 0, 0, 0), RT | RD | SET},
- { insn_dmtc0, M(cop0_op, dmtc_op, 0, 0, 0, 0), RT | RD | SET},
- { insn_dsll, M(spec_op, 0, 0, 0, 0, dsll_op), RT | RD | RE },
- { insn_dsll32, M(spec_op, 0, 0, 0, 0, dsll32_op), RT | RD | RE },
- { insn_dsra, M(spec_op, 0, 0, 0, 0, dsra_op), RT | RD | RE },
- { insn_dsrl, M(spec_op, 0, 0, 0, 0, dsrl_op), RT | RD | RE },
- { insn_dsrl32, M(spec_op, 0, 0, 0, 0, dsrl32_op), RT | RD | RE },
- { insn_dsubu, M(spec_op, 0, 0, 0, 0, dsubu_op), RS | RT | RD },
- { insn_eret, M(cop0_op, cop_op, 0, 0, 0, eret_op), 0 },
- { insn_j, M(j_op, 0, 0, 0, 0, 0), JIMM },
- { insn_jal, M(jal_op, 0, 0, 0, 0, 0), JIMM },
- { insn_jr, M(spec_op, 0, 0, 0, 0, jr_op), RS },
- { insn_ld, M(ld_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_ll, M(ll_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_lld, M(lld_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_lui, M(lui_op, 0, 0, 0, 0, 0), RT | SIMM },
- { insn_lw, M(lw_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_mfc0, M(cop0_op, mfc_op, 0, 0, 0, 0), RT | RD | SET},
- { insn_mtc0, M(cop0_op, mtc_op, 0, 0, 0, 0), RT | RD | SET},
- { insn_ori, M(ori_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
- { insn_rfe, M(cop0_op, cop_op, 0, 0, 0, rfe_op), 0 },
- { insn_sc, M(sc_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_scd, M(scd_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_sd, M(sd_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_sll, M(spec_op, 0, 0, 0, 0, sll_op), RT | RD | RE },
- { insn_sra, M(spec_op, 0, 0, 0, 0, sra_op), RT | RD | RE },
- { insn_srl, M(spec_op, 0, 0, 0, 0, srl_op), RT | RD | RE },
- { insn_subu, M(spec_op, 0, 0, 0, 0, subu_op), RS | RT | RD },
- { insn_sw, M(sw_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
- { insn_tlbp, M(cop0_op, cop_op, 0, 0, 0, tlbp_op), 0 },
- { insn_tlbwi, M(cop0_op, cop_op, 0, 0, 0, tlbwi_op), 0 },
- { insn_tlbwr, M(cop0_op, cop_op, 0, 0, 0, tlbwr_op), 0 },
- { insn_xor, M(spec_op, 0, 0, 0, 0, xor_op), RS | RT | RD },
- { insn_xori, M(xori_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
- { insn_invalid, 0, 0 }
-};
-
-#undef M
-
-static __init u32 build_rs(u32 arg)
-{
- if (arg & ~RS_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return (arg & RS_MASK) << RS_SH;
-}
-
-static __init u32 build_rt(u32 arg)
-{
- if (arg & ~RT_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return (arg & RT_MASK) << RT_SH;
-}
-
-static __init u32 build_rd(u32 arg)
-{
- if (arg & ~RD_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return (arg & RD_MASK) << RD_SH;
-}
-
-static __init u32 build_re(u32 arg)
-{
- if (arg & ~RE_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return (arg & RE_MASK) << RE_SH;
-}
-
-static __init u32 build_simm(s32 arg)
-{
- if (arg > 0x7fff || arg < -0x8000)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return arg & 0xffff;
-}
-
-static __init u32 build_uimm(u32 arg)
-{
- if (arg & ~IMM_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return arg & IMM_MASK;
-}
-
-static __init u32 build_bimm(s32 arg)
-{
- if (arg > 0x1ffff || arg < -0x20000)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- if (arg & 0x3)
- printk(KERN_WARNING "Invalid TLB synthesizer branch target\n");
-
- return ((arg < 0) ? (1 << 15) : 0) | ((arg >> 2) & 0x7fff);
-}
-
-static __init u32 build_jimm(u32 arg)
-{
- if (arg & ~((JIMM_MASK) << 2))
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return (arg >> 2) & JIMM_MASK;
-}
-
-static __init u32 build_func(u32 arg)
-{
- if (arg & ~FUNC_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return arg & FUNC_MASK;
-}
-
-static __init u32 build_set(u32 arg)
-{
- if (arg & ~SET_MASK)
- printk(KERN_WARNING "TLB synthesizer field overflow\n");
-
- return arg & SET_MASK;
-}
-
-/*
- * The order of opcode arguments is implicitly left to right,
- * starting with RS and ending with FUNC or IMM.
- */
-static void __init build_insn(u32 **buf, enum opcode opc, ...)
-{
- struct insn *ip = NULL;
- unsigned int i;
- va_list ap;
- u32 op;
-
- for (i = 0; insn_table[i].opcode != insn_invalid; i++)
- if (insn_table[i].opcode == opc) {
- ip = &insn_table[i];
- break;
- }
-
- if (!ip)
- panic("Unsupported TLB synthesizer instruction %d", opc);
-
- op = ip->match;
- va_start(ap, opc);
- if (ip->fields & RS) op |= build_rs(va_arg(ap, u32));
- if (ip->fields & RT) op |= build_rt(va_arg(ap, u32));
- if (ip->fields & RD) op |= build_rd(va_arg(ap, u32));
- if (ip->fields & RE) op |= build_re(va_arg(ap, u32));
- if (ip->fields & SIMM) op |= build_simm(va_arg(ap, s32));
- if (ip->fields & UIMM) op |= build_uimm(va_arg(ap, u32));
- if (ip->fields & BIMM) op |= build_bimm(va_arg(ap, s32));
- if (ip->fields & JIMM) op |= build_jimm(va_arg(ap, u32));
- if (ip->fields & FUNC) op |= build_func(va_arg(ap, u32));
- if (ip->fields & SET) op |= build_set(va_arg(ap, u32));
- va_end(ap);
-
- **buf = op;
- (*buf)++;
-}
-
-#define I_u1u2u3(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- unsigned int b, unsigned int c) \
- { \
- build_insn(buf, insn##op, a, b, c); \
- }
-
-#define I_u2u1u3(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- unsigned int b, unsigned int c) \
- { \
- build_insn(buf, insn##op, b, a, c); \
- }
-
-#define I_u3u1u2(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- unsigned int b, unsigned int c) \
- { \
- build_insn(buf, insn##op, b, c, a); \
- }
-
-#define I_u1u2s3(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- unsigned int b, signed int c) \
- { \
- build_insn(buf, insn##op, a, b, c); \
- }
-
-#define I_u2s3u1(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- signed int b, unsigned int c) \
- { \
- build_insn(buf, insn##op, c, a, b); \
- }
-
-#define I_u2u1s3(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- unsigned int b, signed int c) \
- { \
- build_insn(buf, insn##op, b, a, c); \
- }
-
-#define I_u1u2(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- unsigned int b) \
- { \
- build_insn(buf, insn##op, a, b); \
- }
-
-#define I_u1s2(op) \
- static inline void __init i##op(u32 **buf, unsigned int a, \
- signed int b) \
- { \
- build_insn(buf, insn##op, a, b); \
- }
-
-#define I_u1(op) \
- static inline void __init i##op(u32 **buf, unsigned int a) \
- { \
- build_insn(buf, insn##op, a); \
- }
-
-#define I_0(op) \
- static inline void __init i##op(u32 **buf) \
- { \
- build_insn(buf, insn##op); \
- }
-
-I_u2u1s3(_addiu);
-I_u3u1u2(_addu);
-I_u2u1u3(_andi);
-I_u3u1u2(_and);
-I_u1u2s3(_beq);
-I_u1u2s3(_beql);
-I_u1s2(_bgez);
-I_u1s2(_bgezl);
-I_u1s2(_bltz);
-I_u1s2(_bltzl);
-I_u1u2s3(_bne);
-I_u1u2u3(_dmfc0);
-I_u1u2u3(_dmtc0);
-I_u2u1s3(_daddiu);
-I_u3u1u2(_daddu);
-I_u2u1u3(_dsll);
-I_u2u1u3(_dsll32);
-I_u2u1u3(_dsra);
-I_u2u1u3(_dsrl);
-I_u2u1u3(_dsrl32);
-I_u3u1u2(_dsubu);
-I_0(_eret);
-I_u1(_j);
-I_u1(_jal);
-I_u1(_jr);
-I_u2s3u1(_ld);
-I_u2s3u1(_ll);
-I_u2s3u1(_lld);
-I_u1s2(_lui);
-I_u2s3u1(_lw);
-I_u1u2u3(_mfc0);
-I_u1u2u3(_mtc0);
-I_u2u1u3(_ori);
-I_0(_rfe);
-I_u2s3u1(_sc);
-I_u2s3u1(_scd);
-I_u2s3u1(_sd);
-I_u2u1u3(_sll);
-I_u2u1u3(_sra);
-I_u2u1u3(_srl);
-I_u3u1u2(_subu);
-I_u2s3u1(_sw);
-I_0(_tlbp);
-I_0(_tlbwi);
-I_0(_tlbwr);
-I_u3u1u2(_xor)
-I_u2u1u3(_xori);
-
-/*
- * handling labels
- */
-
+/* Handle labels (which must be positive integers). */
enum label_id {
- label_invalid,
- label_second_part,
+ label_second_part = 1,
label_leave,
#ifdef MODULE_START
label_module_alloc,
@@ -452,267 +88,20 @@ enum label_id {
label_r3000_write_probe_fail,
};
-struct label {
- u32 *addr;
- enum label_id lab;
-};
-
-static __init void build_label(struct label **lab, u32 *addr,
- enum label_id l)
-{
- (*lab)->addr = addr;
- (*lab)->lab = l;
- (*lab)++;
-}
-
-#define L_LA(lb) \
- static inline void l##lb(struct label **lab, u32 *addr) \
- { \
- build_label(lab, addr, label##lb); \
- }
-
-L_LA(_second_part)
-L_LA(_leave)
+UASM_L_LA(_second_part)
+UASM_L_LA(_leave)
#ifdef MODULE_START
-L_LA(_module_alloc)
-#endif
-L_LA(_vmalloc)
-L_LA(_vmalloc_done)
-L_LA(_tlbw_hazard)
-L_LA(_split)
-L_LA(_nopage_tlbl)
-L_LA(_nopage_tlbs)
-L_LA(_nopage_tlbm)
-L_LA(_smp_pgtable_change)
-L_LA(_r3000_write_probe_fail)
-
-/* convenience macros for instructions */
-#ifdef CONFIG_64BIT
-# define i_LW(buf, rs, rt, off) i_ld(buf, rs, rt, off)
-# define i_SW(buf, rs, rt, off) i_sd(buf, rs, rt, off)
-# define i_SLL(buf, rs, rt, sh) i_dsll(buf, rs, rt, sh)
-# define i_SRA(buf, rs, rt, sh) i_dsra(buf, rs, rt, sh)
-# define i_SRL(buf, rs, rt, sh) i_dsrl(buf, rs, rt, sh)
-# define i_MFC0(buf, rt, rd...) i_dmfc0(buf, rt, rd)
-# define i_MTC0(buf, rt, rd...) i_dmtc0(buf, rt, rd)
-# define i_ADDIU(buf, rs, rt, val) i_daddiu(buf, rs, rt, val)
-# define i_ADDU(buf, rs, rt, rd) i_daddu(buf, rs, rt, rd)
-# define i_SUBU(buf, rs, rt, rd) i_dsubu(buf, rs, rt, rd)
-# define i_LL(buf, rs, rt, off) i_lld(buf, rs, rt, off)
-# define i_SC(buf, rs, rt, off) i_scd(buf, rs, rt, off)
-#else
-# define i_LW(buf, rs, rt, off) i_lw(buf, rs, rt, off)
-# define i_SW(buf, rs, rt, off) i_sw(buf, rs, rt, off)
-# define i_SLL(buf, rs, rt, sh) i_sll(buf, rs, rt, sh)
-# define i_SRA(buf, rs, rt, sh) i_sra(buf, rs, rt, sh)
-# define i_SRL(buf, rs, rt, sh) i_srl(buf, rs, rt, sh)
-# define i_MFC0(buf, rt, rd...) i_mfc0(buf, rt, rd)
-# define i_MTC0(buf, rt, rd...) i_mtc0(buf, rt, rd)
-# define i_ADDIU(buf, rs, rt, val) i_addiu(buf, rs, rt, val)
-# define i_ADDU(buf, rs, rt, rd) i_addu(buf, rs, rt, rd)
-# define i_SUBU(buf, rs, rt, rd) i_subu(buf, rs, rt, rd)
-# define i_LL(buf, rs, rt, off) i_ll(buf, rs, rt, off)
-# define i_SC(buf, rs, rt, off) i_sc(buf, rs, rt, off)
-#endif
-
-#define i_b(buf, off) i_beq(buf, 0, 0, off)
-#define i_beqz(buf, rs, off) i_beq(buf, rs, 0, off)
-#define i_beqzl(buf, rs, off) i_beql(buf, rs, 0, off)
-#define i_bnez(buf, rs, off) i_bne(buf, rs, 0, off)
-#define i_bnezl(buf, rs, off) i_bnel(buf, rs, 0, off)
-#define i_move(buf, a, b) i_ADDU(buf, a, 0, b)
-#define i_nop(buf) i_sll(buf, 0, 0, 0)
-#define i_ssnop(buf) i_sll(buf, 0, 0, 1)
-#define i_ehb(buf) i_sll(buf, 0, 0, 3)
-
-#ifdef CONFIG_64BIT
-static __init int __maybe_unused in_compat_space_p(long addr)
-{
- /* Is this address in 32bit compat space? */
- return (((addr) & 0xffffffff00000000L) == 0xffffffff00000000L);
-}
-
-static __init int __maybe_unused rel_highest(long val)
-{
- return ((((val + 0x800080008000L) >> 48) & 0xffff) ^ 0x8000) - 0x8000;
-}
-
-static __init int __maybe_unused rel_higher(long val)
-{
- return ((((val + 0x80008000L) >> 32) & 0xffff) ^ 0x8000) - 0x8000;
-}
-#endif
-
-static __init int rel_hi(long val)
-{
- return ((((val + 0x8000L) >> 16) & 0xffff) ^ 0x8000) - 0x8000;
-}
-
-static __init int rel_lo(long val)
-{
- return ((val & 0xffff) ^ 0x8000) - 0x8000;
-}
-
-static __init void i_LA_mostly(u32 **buf, unsigned int rs, long addr)
-{
-#ifdef CONFIG_64BIT
- if (!in_compat_space_p(addr)) {
- i_lui(buf, rs, rel_highest(addr));
- if (rel_higher(addr))
- i_daddiu(buf, rs, rs, rel_higher(addr));
- if (rel_hi(addr)) {
- i_dsll(buf, rs, rs, 16);
- i_daddiu(buf, rs, rs, rel_hi(addr));
- i_dsll(buf, rs, rs, 16);
- } else
- i_dsll32(buf, rs, rs, 0);
- } else
+UASM_L_LA(_module_alloc)
#endif
- i_lui(buf, rs, rel_hi(addr));
-}
-
-static __init void __maybe_unused i_LA(u32 **buf, unsigned int rs,
- long addr)
-{
- i_LA_mostly(buf, rs, addr);
- if (rel_lo(addr))
- i_ADDIU(buf, rs, rs, rel_lo(addr));
-}
-
-/*
- * handle relocations
- */
-
-struct reloc {
- u32 *addr;
- unsigned int type;
- enum label_id lab;
-};
-
-static __init void r_mips_pc16(struct reloc **rel, u32 *addr,
- enum label_id l)
-{
- (*rel)->addr = addr;
- (*rel)->type = R_MIPS_PC16;
- (*rel)->lab = l;
- (*rel)++;
-}
-
-static inline void __resolve_relocs(struct reloc *rel, struct label *lab)
-{
- long laddr = (long)lab->addr;
- long raddr = (long)rel->addr;
-
- switch (rel->type) {
- case R_MIPS_PC16:
- *rel->addr |= build_bimm(laddr - (raddr + 4));
- break;
-
- default:
- panic("Unsupported TLB synthesizer relocation %d",
- rel->type);
- }
-}
-
-static __init void resolve_relocs(struct reloc *rel, struct label *lab)
-{
- struct label *l;
-
- for (; rel->lab != label_invalid; rel++)
- for (l = lab; l->lab != label_invalid; l++)
- if (rel->lab == l->lab)
- __resolve_relocs(rel, l);
-}
-
-static __init void move_relocs(struct reloc *rel, u32 *first, u32 *end,
- long off)
-{
- for (; rel->lab != label_invalid; rel++)
- if (rel->addr >= first && rel->addr < end)
- rel->addr += off;
-}
-
-static __init void move_labels(struct label *lab, u32 *first, u32 *end,
- long off)
-{
- for (; lab->lab != label_invalid; lab++)
- if (lab->addr >= first && lab->addr < end)
- lab->addr += off;
-}
-
-static __init void copy_handler(struct reloc *rel, struct label *lab,
- u32 *first, u32 *end, u32 *target)
-{
- long off = (long)(target - first);
-
- memcpy(target, first, (end - first) * sizeof(u32));
-
- move_relocs(rel, first, end, off);
- move_labels(lab, first, end, off);
-}
-
-static __init int __maybe_unused insn_has_bdelay(struct reloc *rel,
- u32 *addr)
-{
- for (; rel->lab != label_invalid; rel++) {
- if (rel->addr == addr
- && (rel->type == R_MIPS_PC16
- || rel->type == R_MIPS_26))
- return 1;
- }
-
- return 0;
-}
-
-/* convenience functions for labeled branches */
-static void __init __maybe_unused
- il_bltz(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_bltz(p, reg, 0);
-}
-
-static void __init __maybe_unused il_b(u32 **p, struct reloc **r,
- enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_b(p, 0);
-}
-
-static void __init il_beqz(u32 **p, struct reloc **r, unsigned int reg,
- enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_beqz(p, reg, 0);
-}
-
-static void __init __maybe_unused
-il_beqzl(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_beqzl(p, reg, 0);
-}
-
-static void __init il_bnez(u32 **p, struct reloc **r, unsigned int reg,
- enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_bnez(p, reg, 0);
-}
-
-static void __init il_bgezl(u32 **p, struct reloc **r, unsigned int reg,
- enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_bgezl(p, reg, 0);
-}
-
-static void __init __maybe_unused
-il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
-{
- r_mips_pc16(r, *p, l);
- i_bgez(p, reg, 0);
-}
+UASM_L_LA(_vmalloc)
+UASM_L_LA(_vmalloc_done)
+UASM_L_LA(_tlbw_hazard)
+UASM_L_LA(_split)
+UASM_L_LA(_nopage_tlbl)
+UASM_L_LA(_nopage_tlbs)
+UASM_L_LA(_nopage_tlbm)
+UASM_L_LA(_smp_pgtable_change)
+UASM_L_LA(_r3000_write_probe_fail)
/* The only general purpose registers allowed in TLB handlers. */
#define K0 26
@@ -730,9 +119,9 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
#define C0_XCONTEXT 20, 0
#ifdef CONFIG_64BIT
-# define GET_CONTEXT(buf, reg) i_MFC0(buf, reg, C0_XCONTEXT)
+# define GET_CONTEXT(buf, reg) UASM_i_MFC0(buf, reg, C0_XCONTEXT)
#else
-# define GET_CONTEXT(buf, reg) i_MFC0(buf, reg, C0_CONTEXT)
+# define GET_CONTEXT(buf, reg) UASM_i_MFC0(buf, reg, C0_CONTEXT)
#endif
/* The worst case length of the handler is around 18 instructions for
@@ -746,8 +135,8 @@ il_bgez(u32 **p, struct reloc **r, unsigned int reg, enum label_id l)
static __initdata u32 tlb_handler[128];
/* simply assume worst case size for labels and relocs */
-static __initdata struct label labels[128];
-static __initdata struct reloc relocs[128];
+static __initdata struct uasm_label labels[128];
+static __initdata struct uasm_reloc relocs[128];
/*
* The R3000 TLB handler is simple.
@@ -761,29 +150,29 @@ static void __init build_r3000_tlb_refill_handler(void)
memset(tlb_handler, 0, sizeof(tlb_handler));
p = tlb_handler;
- i_mfc0(&p, K0, C0_BADVADDR);
- i_lui(&p, K1, rel_hi(pgdc)); /* cp0 delay */
- i_lw(&p, K1, rel_lo(pgdc), K1);
- i_srl(&p, K0, K0, 22); /* load delay */
- i_sll(&p, K0, K0, 2);
- i_addu(&p, K1, K1, K0);
- i_mfc0(&p, K0, C0_CONTEXT);
- i_lw(&p, K1, 0, K1); /* cp0 delay */
- i_andi(&p, K0, K0, 0xffc); /* load delay */
- i_addu(&p, K1, K1, K0);
- i_lw(&p, K0, 0, K1);
- i_nop(&p); /* load delay */
- i_mtc0(&p, K0, C0_ENTRYLO0);
- i_mfc0(&p, K1, C0_EPC); /* cp0 delay */
- i_tlbwr(&p); /* cp0 delay */
- i_jr(&p, K1);
- i_rfe(&p); /* branch delay */
+ uasm_i_mfc0(&p, K0, C0_BADVADDR);
+ uasm_i_lui(&p, K1, uasm_rel_hi(pgdc)); /* cp0 delay */
+ uasm_i_lw(&p, K1, uasm_rel_lo(pgdc), K1);
+ uasm_i_srl(&p, K0, K0, 22); /* load delay */
+ uasm_i_sll(&p, K0, K0, 2);
+ uasm_i_addu(&p, K1, K1, K0);
+ uasm_i_mfc0(&p, K0, C0_CONTEXT);
+ uasm_i_lw(&p, K1, 0, K1); /* cp0 delay */
+ uasm_i_andi(&p, K0, K0, 0xffc); /* load delay */
+ uasm_i_addu(&p, K1, K1, K0);
+ uasm_i_lw(&p, K0, 0, K1);
+ uasm_i_nop(&p); /* load delay */
+ uasm_i_mtc0(&p, K0, C0_ENTRYLO0);
+ uasm_i_mfc0(&p, K1, C0_EPC); /* cp0 delay */
+ uasm_i_tlbwr(&p); /* cp0 delay */
+ uasm_i_jr(&p, K1);
+ uasm_i_rfe(&p); /* branch delay */
if (p > tlb_handler + 32)
panic("TLB refill handler space exceeded");
- pr_info("Synthesized TLB refill handler (%u instructions).\n",
- (unsigned int)(p - tlb_handler));
+ pr_debug("Wrote TLB refill handler (%u instructions).\n",
+ (unsigned int)(p - tlb_handler));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
@@ -833,12 +222,12 @@ static __init void __maybe_unused build_tlb_probe_entry(u32 **p)
case CPU_R5000:
case CPU_R5000A:
case CPU_NEVADA:
- i_nop(p);
- i_tlbp(p);
+ uasm_i_nop(p);
+ uasm_i_tlbp(p);
break;
default:
- i_tlbp(p);
+ uasm_i_tlbp(p);
break;
}
}
@@ -849,15 +238,15 @@ static __init void __maybe_unused build_tlb_probe_entry(u32 **p)
*/
enum tlb_write_entry { tlb_random, tlb_indexed };
-static __init void build_tlb_write_entry(u32 **p, struct label **l,
- struct reloc **r,
+static __init void build_tlb_write_entry(u32 **p, struct uasm_label **l,
+ struct uasm_reloc **r,
enum tlb_write_entry wmode)
{
void(*tlbw)(u32 **) = NULL;
switch (wmode) {
- case tlb_random: tlbw = i_tlbwr; break;
- case tlb_indexed: tlbw = i_tlbwi; break;
+ case tlb_random: tlbw = uasm_i_tlbwr; break;
+ case tlb_indexed: tlbw = uasm_i_tlbwi; break;
}
switch (current_cpu_type()) {
@@ -871,19 +260,19 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
* This branch uses up a mtc0 hazard nop slot and saves
* two nops after the tlbw instruction.
*/
- il_bgezl(p, r, 0, label_tlbw_hazard);
+ uasm_il_bgezl(p, r, 0, label_tlbw_hazard);
tlbw(p);
- l_tlbw_hazard(l, *p);
- i_nop(p);
+ uasm_l_tlbw_hazard(l, *p);
+ uasm_i_nop(p);
break;
case CPU_R4600:
case CPU_R4700:
case CPU_R5000:
case CPU_R5000A:
- i_nop(p);
+ uasm_i_nop(p);
tlbw(p);
- i_nop(p);
+ uasm_i_nop(p);
break;
case CPU_R4300:
@@ -895,7 +284,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
case CPU_AU1550:
case CPU_AU1200:
case CPU_PR4450:
- i_nop(p);
+ uasm_i_nop(p);
tlbw(p);
break;
@@ -912,26 +301,26 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
case CPU_BCM4710:
case CPU_LOONGSON2:
if (m4kc_tlbp_war())
- i_nop(p);
+ uasm_i_nop(p);
tlbw(p);
break;
case CPU_NEVADA:
- i_nop(p); /* QED specifies 2 nops hazard */
+ uasm_i_nop(p); /* QED specifies 2 nops hazard */
/*
* This branch uses up a mtc0 hazard nop slot and saves
* a nop after the tlbw instruction.
*/
- il_bgezl(p, r, 0, label_tlbw_hazard);
+ uasm_il_bgezl(p, r, 0, label_tlbw_hazard);
tlbw(p);
- l_tlbw_hazard(l, *p);
+ uasm_l_tlbw_hazard(l, *p);
break;
case CPU_RM7000:
- i_nop(p);
- i_nop(p);
- i_nop(p);
- i_nop(p);
+ uasm_i_nop(p);
+ uasm_i_nop(p);
+ uasm_i_nop(p);
+ uasm_i_nop(p);
tlbw(p);
break;
@@ -939,7 +328,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
case CPU_24K:
case CPU_34K:
case CPU_74K:
- i_ehb(p);
+ uasm_i_ehb(p);
tlbw(p);
break;
@@ -950,15 +339,15 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
* cpu cycles and use for data translations should not occur
* for 3 cpu cycles.
*/
- i_ssnop(p);
- i_ssnop(p);
- i_ssnop(p);
- i_ssnop(p);
+ uasm_i_ssnop(p);
+ uasm_i_ssnop(p);
+ uasm_i_ssnop(p);
+ uasm_i_ssnop(p);
tlbw(p);
- i_ssnop(p);
- i_ssnop(p);
- i_ssnop(p);
- i_ssnop(p);
+ uasm_i_ssnop(p);
+ uasm_i_ssnop(p);
+ uasm_i_ssnop(p);
+ uasm_i_ssnop(p);
break;
case CPU_VR4111:
@@ -966,18 +355,18 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
case CPU_VR4122:
case CPU_VR4181:
case CPU_VR4181A:
- i_nop(p);
- i_nop(p);
+ uasm_i_nop(p);
+ uasm_i_nop(p);
tlbw(p);
- i_nop(p);
- i_nop(p);
+ uasm_i_nop(p);
+ uasm_i_nop(p);
break;
case CPU_VR4131:
case CPU_VR4133:
case CPU_R5432:
- i_nop(p);
- i_nop(p);
+ uasm_i_nop(p);
+ uasm_i_nop(p);
tlbw(p);
break;
@@ -994,7 +383,7 @@ static __init void build_tlb_write_entry(u32 **p, struct label **l,
* TMP will be clobbered, PTR will hold the pmd entry.
*/
static __init void
-build_get_pmde64(u32 **p, struct label **l, struct reloc **r,
+build_get_pmde64(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
unsigned int tmp, unsigned int ptr)
{
long pgdc = (long)pgd_current;
@@ -1002,52 +391,52 @@ build_get_pmde64(u32 **p, struct label **l, struct reloc **r,
/*
* The vmalloc handling is not in the hotpath.
*/
- i_dmfc0(p, tmp, C0_BADVADDR);
+ uasm_i_dmfc0(p, tmp, C0_BADVADDR);
#ifdef MODULE_START
- il_bltz(p, r, tmp, label_module_alloc);
+ uasm_il_bltz(p, r, tmp, label_module_alloc);
#else
- il_bltz(p, r, tmp, label_vmalloc);
+ uasm_il_bltz(p, r, tmp, label_vmalloc);
#endif
- /* No i_nop needed here, since the next insn doesn't touch TMP. */
+ /* No uasm_i_nop needed here, since the next insn doesn't touch TMP. */
#ifdef CONFIG_SMP
# ifdef CONFIG_MIPS_MT_SMTC
/*
* SMTC uses TCBind value as "CPU" index
*/
- i_mfc0(p, ptr, C0_TCBIND);
- i_dsrl(p, ptr, ptr, 19);
+ uasm_i_mfc0(p, ptr, C0_TCBIND);
+ uasm_i_dsrl(p, ptr, ptr, 19);
# else
/*
* 64 bit SMP running in XKPHYS has smp_processor_id() << 3
* stored in CONTEXT.
*/
- i_dmfc0(p, ptr, C0_CONTEXT);
- i_dsrl(p, ptr, ptr, 23);
+ uasm_i_dmfc0(p, ptr, C0_CONTEXT);
+ uasm_i_dsrl(p, ptr, ptr, 23);
#endif
- i_LA_mostly(p, tmp, pgdc);
- i_daddu(p, ptr, ptr, tmp);
- i_dmfc0(p, tmp, C0_BADVADDR);
- i_ld(p, ptr, rel_lo(pgdc), ptr);
+ UASM_i_LA_mostly(p, tmp, pgdc);
+ uasm_i_daddu(p, ptr, ptr, tmp);
+ uasm_i_dmfc0(p, tmp, C0_BADVADDR);
+ uasm_i_ld(p, ptr, uasm_rel_lo(pgdc), ptr);
#else
- i_LA_mostly(p, ptr, pgdc);
- i_ld(p, ptr, rel_lo(pgdc), ptr);
+ UASM_i_LA_mostly(p, ptr, pgdc);
+ uasm_i_ld(p, ptr, uasm_rel_lo(pgdc), ptr);
#endif
- l_vmalloc_done(l, *p);
+ uasm_l_vmalloc_done(l, *p);
if (PGDIR_SHIFT - 3 < 32) /* get pgd offset in bytes */
- i_dsrl(p, tmp, tmp, PGDIR_SHIFT-3);
+ uasm_i_dsrl(p, tmp, tmp, PGDIR_SHIFT-3);
else
- i_dsrl32(p, tmp, tmp, PGDIR_SHIFT - 3 - 32);
-
- i_andi(p, tmp, tmp, (PTRS_PER_PGD - 1)<<3);
- i_daddu(p, ptr, ptr, tmp); /* add in pgd offset */
- i_dmfc0(p, tmp, C0_BADVADDR); /* get faulting address */
- i_ld(p, ptr, 0, ptr); /* get pmd pointer */
- i_dsrl(p, tmp, tmp, PMD_SHIFT-3); /* get pmd offset in bytes */
- i_andi(p, tmp, tmp, (PTRS_PER_PMD - 1)<<3);
- i_daddu(p, ptr, ptr, tmp); /* add in pmd offset */
+ uasm_i_dsrl32(p, tmp, tmp, PGDIR_SHIFT - 3 - 32);
+
+ uasm_i_andi(p, tmp, tmp, (PTRS_PER_PGD - 1)<<3);
+ uasm_i_daddu(p, ptr, ptr, tmp); /* add in pgd offset */
+ uasm_i_dmfc0(p, tmp, C0_BADVADDR); /* get faulting address */
+ uasm_i_ld(p, ptr, 0, ptr); /* get pmd pointer */
+ uasm_i_dsrl(p, tmp, tmp, PMD_SHIFT-3); /* get pmd offset in bytes */
+ uasm_i_andi(p, tmp, tmp, (PTRS_PER_PMD - 1)<<3);
+ uasm_i_daddu(p, ptr, ptr, tmp); /* add in pmd offset */
}
/*
@@ -1055,7 +444,7 @@ build_get_pmde64(u32 **p, struct label **l, struct reloc **r,
* PTR will hold the pgd for vmalloc.
*/
static __init void
-build_get_pgd_vmalloc64(u32 **p, struct label **l, struct reloc **r,
+build_get_pgd_vmalloc64(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
unsigned int bvaddr, unsigned int ptr)
{
long swpd = (long)swapper_pg_dir;
@@ -1063,52 +452,54 @@ build_get_pgd_vmalloc64(u32 **p, struct label **l, struct reloc **r,
#ifdef MODULE_START
long modd = (long)module_pg_dir;
- l_module_alloc(l, *p);
+ uasm_l_module_alloc(l, *p);
/*
* Assumption:
* VMALLOC_START >= 0xc000000000000000UL
* MODULE_START >= 0xe000000000000000UL
*/
- i_SLL(p, ptr, bvaddr, 2);
- il_bgez(p, r, ptr, label_vmalloc);
+ UASM_i_SLL(p, ptr, bvaddr, 2);
+ uasm_il_bgez(p, r, ptr, label_vmalloc);
- if (in_compat_space_p(MODULE_START) && !rel_lo(MODULE_START)) {
- i_lui(p, ptr, rel_hi(MODULE_START)); /* delay slot */
+ if (uasm_in_compat_space_p(MODULE_START) &&
+ !uasm_rel_lo(MODULE_START)) {
+ uasm_i_lui(p, ptr, uasm_rel_hi(MODULE_START)); /* delay slot */
} else {
/* unlikely configuration */
- i_nop(p); /* delay slot */
- i_LA(p, ptr, MODULE_START);
+ uasm_i_nop(p); /* delay slot */
+ UASM_i_LA(p, ptr, MODULE_START);
}
- i_dsubu(p, bvaddr, bvaddr, ptr);
+ uasm_i_dsubu(p, bvaddr, bvaddr, ptr);
- if (in_compat_space_p(modd) && !rel_lo(modd)) {
- il_b(p, r, label_vmalloc_done);
- i_lui(p, ptr, rel_hi(modd));
+ if (uasm_in_compat_space_p(modd) && !uasm_rel_lo(modd)) {
+ uasm_il_b(p, r, label_vmalloc_done);
+ uasm_i_lui(p, ptr, uasm_rel_hi(modd));
} else {
- i_LA_mostly(p, ptr, modd);
- il_b(p, r, label_vmalloc_done);
- i_daddiu(p, ptr, ptr, rel_lo(modd));
+ UASM_i_LA_mostly(p, ptr, modd);
+ uasm_il_b(p, r, label_vmalloc_done);
+ uasm_i_daddiu(p, ptr, ptr, uasm_rel_lo(modd));
}
- l_vmalloc(l, *p);
- if (in_compat_space_p(MODULE_START) && !rel_lo(MODULE_START) &&
+ uasm_l_vmalloc(l, *p);
+ if (uasm_in_compat_space_p(MODULE_START) &&
+ !uasm_rel_lo(MODULE_START) &&
MODULE_START << 32 == VMALLOC_START)
- i_dsll32(p, ptr, ptr, 0); /* typical case */
+ uasm_i_dsll32(p, ptr, ptr, 0); /* typical case */
else
- i_LA(p, ptr, VMALLOC_START);
+ UASM_i_LA(p, ptr, VMALLOC_START);
#else
- l_vmalloc(l, *p);
- i_LA(p, ptr, VMALLOC_START);
+ uasm_l_vmalloc(l, *p);
+ UASM_i_LA(p, ptr, VMALLOC_START);
#endif
- i_dsubu(p, bvaddr, bvaddr, ptr);
+ uasm_i_dsubu(p, bvaddr, bvaddr, ptr);
- if (in_compat_space_p(swpd) && !rel_lo(swpd)) {
- il_b(p, r, label_vmalloc_done);
- i_lui(p, ptr, rel_hi(swpd));
+ if (uasm_in_compat_space_p(swpd) && !uasm_rel_lo(swpd)) {
+ uasm_il_b(p, r, label_vmalloc_done);
+ uasm_i_lui(p, ptr, uasm_rel_hi(swpd));
} else {
- i_LA_mostly(p, ptr, swpd);
- il_b(p, r, label_vmalloc_done);
- i_daddiu(p, ptr, ptr, rel_lo(swpd));
+ UASM_i_LA_mostly(p, ptr, swpd);
+ uasm_il_b(p, r, label_vmalloc_done);
+ uasm_i_daddiu(p, ptr, ptr, uasm_rel_lo(swpd));
}
}
@@ -1129,26 +520,26 @@ build_get_pgde32(u32 **p, unsigned int tmp, unsigned int ptr)
/*
* SMTC uses TCBind value as "CPU" index
*/
- i_mfc0(p, ptr, C0_TCBIND);
- i_LA_mostly(p, tmp, pgdc);
- i_srl(p, ptr, ptr, 19);
+ uasm_i_mfc0(p, ptr, C0_TCBIND);
+ UASM_i_LA_mostly(p, tmp, pgdc);
+ uasm_i_srl(p, ptr, ptr, 19);
#else
/*
* smp_processor_id() << 3 is stored in CONTEXT.
*/
- i_mfc0(p, ptr, C0_CONTEXT);
- i_LA_mostly(p, tmp, pgdc);
- i_srl(p, ptr, ptr, 23);
+ uasm_i_mfc0(p, ptr, C0_CONTEXT);
+ UASM_i_LA_mostly(p, tmp, pgdc);
+ uasm_i_srl(p, ptr, ptr, 23);
#endif
- i_addu(p, ptr, tmp, ptr);
+ uasm_i_addu(p, ptr, tmp, ptr);
#else
- i_LA_mostly(p, ptr, pgdc);
+ UASM_i_LA_mostly(p, ptr, pgdc);
#endif
- i_mfc0(p, tmp, C0_BADVADDR); /* get faulting address */
- i_lw(p, ptr, rel_lo(pgdc), ptr);
- i_srl(p, tmp, tmp, PGDIR_SHIFT); /* get pgd only bits */
- i_sll(p, tmp, tmp, PGD_T_LOG2);
- i_addu(p, ptr, ptr, tmp); /* add in pgd offset */
+ uasm_i_mfc0(p, tmp, C0_BADVADDR); /* get faulting address */
+ uasm_i_lw(p, ptr, uasm_rel_lo(pgdc), ptr);
+ uasm_i_srl(p, tmp, tmp, PGDIR_SHIFT); /* get pgd only bits */
+ uasm_i_sll(p, tmp, tmp, PGD_T_LOG2);
+ uasm_i_addu(p, ptr, ptr, tmp); /* add in pgd offset */
}
#endif /* !CONFIG_64BIT */
@@ -1175,8 +566,8 @@ static __init void build_adjust_context(u32 **p, unsigned int ctx)
}
if (shift)
- i_SRL(p, ctx, ctx, shift);
- i_andi(p, ctx, ctx, mask);
+ UASM_i_SRL(p, ctx, ctx, shift);
+ uasm_i_andi(p, ctx, ctx, mask);
}
static __init void build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr)
@@ -1190,18 +581,18 @@ static __init void build_get_ptep(u32 **p, unsigned int tmp, unsigned int ptr)
*/
switch (current_cpu_type()) {
case CPU_NEVADA:
- i_LW(p, ptr, 0, ptr);
+ UASM_i_LW(p, ptr, 0, ptr);
GET_CONTEXT(p, tmp); /* get context reg */
break;
default:
GET_CONTEXT(p, tmp); /* get context reg */
- i_LW(p, ptr, 0, ptr);
+ UASM_i_LW(p, ptr, 0, ptr);
break;
}
build_adjust_context(p, tmp);
- i_ADDU(p, ptr, ptr, tmp); /* add in offset */
+ UASM_i_ADDU(p, ptr, ptr, tmp); /* add in offset */
}
static __init void build_update_entries(u32 **p, unsigned int tmp,
@@ -1213,45 +604,45 @@ static __init void build_update_entries(u32 **p, unsigned int tmp,
*/
#ifdef CONFIG_64BIT_PHYS_ADDR
if (cpu_has_64bits) {
- i_ld(p, tmp, 0, ptep); /* get even pte */
- i_ld(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
- i_dsrl(p, tmp, tmp, 6); /* convert to entrylo0 */
- i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
- i_dsrl(p, ptep, ptep, 6); /* convert to entrylo1 */
- i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
+ uasm_i_ld(p, tmp, 0, ptep); /* get even pte */
+ uasm_i_ld(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
+ uasm_i_dsrl(p, tmp, tmp, 6); /* convert to entrylo0 */
+ uasm_i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
+ uasm_i_dsrl(p, ptep, ptep, 6); /* convert to entrylo1 */
+ uasm_i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
} else {
int pte_off_even = sizeof(pte_t) / 2;
int pte_off_odd = pte_off_even + sizeof(pte_t);
/* The pte entries are pre-shifted */
- i_lw(p, tmp, pte_off_even, ptep); /* get even pte */
- i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
- i_lw(p, ptep, pte_off_odd, ptep); /* get odd pte */
- i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
+ uasm_i_lw(p, tmp, pte_off_even, ptep); /* get even pte */
+ uasm_i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
+ uasm_i_lw(p, ptep, pte_off_odd, ptep); /* get odd pte */
+ uasm_i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
}
#else
- i_LW(p, tmp, 0, ptep); /* get even pte */
- i_LW(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
+ UASM_i_LW(p, tmp, 0, ptep); /* get even pte */
+ UASM_i_LW(p, ptep, sizeof(pte_t), ptep); /* get odd pte */
if (r45k_bvahwbug())
build_tlb_probe_entry(p);
- i_SRL(p, tmp, tmp, 6); /* convert to entrylo0 */
+ UASM_i_SRL(p, tmp, tmp, 6); /* convert to entrylo0 */
if (r4k_250MHZhwbug())
- i_mtc0(p, 0, C0_ENTRYLO0);
- i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
- i_SRL(p, ptep, ptep, 6); /* convert to entrylo1 */
+ uasm_i_mtc0(p, 0, C0_ENTRYLO0);
+ uasm_i_mtc0(p, tmp, C0_ENTRYLO0); /* load it */
+ UASM_i_SRL(p, ptep, ptep, 6); /* convert to entrylo1 */
if (r45k_bvahwbug())
- i_mfc0(p, tmp, C0_INDEX);
+ uasm_i_mfc0(p, tmp, C0_INDEX);
if (r4k_250MHZhwbug())
- i_mtc0(p, 0, C0_ENTRYLO1);
- i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
+ uasm_i_mtc0(p, 0, C0_ENTRYLO1);
+ uasm_i_mtc0(p, ptep, C0_ENTRYLO1); /* load it */
#endif
}
static void __init build_r4000_tlb_refill_handler(void)
{
u32 *p = tlb_handler;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
u32 *f;
unsigned int final_len;
int i;
@@ -1265,12 +656,12 @@ static void __init build_r4000_tlb_refill_handler(void)
* create the plain linear handler
*/
if (bcm1250_m3_war()) {
- i_MFC0(&p, K0, C0_BADVADDR);
- i_MFC0(&p, K1, C0_ENTRYHI);
- i_xor(&p, K0, K0, K1);
- i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
- il_bnez(&p, &r, K0, label_leave);
- /* No need for i_nop */
+ UASM_i_MFC0(&p, K0, C0_BADVADDR);
+ UASM_i_MFC0(&p, K1, C0_ENTRYHI);
+ uasm_i_xor(&p, K0, K0, K1);
+ UASM_i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
+ uasm_il_bnez(&p, &r, K0, label_leave);
+ /* No need for uasm_i_nop */
}
#ifdef CONFIG_64BIT
@@ -1282,8 +673,8 @@ static void __init build_r4000_tlb_refill_handler(void)
build_get_ptep(&p, K0, K1);
build_update_entries(&p, K0, K1);
build_tlb_write_entry(&p, &l, &r, tlb_random);
- l_leave(&l, p);
- i_eret(&p); /* return from trap */
+ uasm_l_leave(&l, p);
+ uasm_i_eret(&p); /* return from trap */
#ifdef CONFIG_64BIT
build_get_pgd_vmalloc64(&p, &l, &r, K0, K1);
@@ -1303,7 +694,7 @@ static void __init build_r4000_tlb_refill_handler(void)
#else
if (((p - tlb_handler) > 63)
|| (((p - tlb_handler) > 61)
- && insn_has_bdelay(relocs, tlb_handler + 29)))
+ && uasm_insn_has_bdelay(relocs, tlb_handler + 29)))
panic("TLB refill handler space exceeded");
#endif
@@ -1313,13 +704,13 @@ static void __init build_r4000_tlb_refill_handler(void)
#if defined(CONFIG_32BIT) || defined(CONFIG_CPU_LOONGSON2)
f = final_handler;
/* Simplest case, just copy the handler. */
- copy_handler(relocs, labels, tlb_handler, p, f);
+ uasm_copy_handler(relocs, labels, tlb_handler, p, f);
final_len = p - tlb_handler;
#else /* CONFIG_64BIT */
f = final_handler + 32;
if ((p - tlb_handler) <= 32) {
/* Just copy the handler. */
- copy_handler(relocs, labels, tlb_handler, p, f);
+ uasm_copy_handler(relocs, labels, tlb_handler, p, f);
final_len = p - tlb_handler;
} else {
u32 *split = tlb_handler + 30;
@@ -1327,34 +718,34 @@ static void __init build_r4000_tlb_refill_handler(void)
/*
* Find the split point.
*/
- if (insn_has_bdelay(relocs, split - 1))
+ if (uasm_insn_has_bdelay(relocs, split - 1))
split--;
/* Copy first part of the handler. */
- copy_handler(relocs, labels, tlb_handler, split, f);
+ uasm_copy_handler(relocs, labels, tlb_handler, split, f);
f += split - tlb_handler;
/* Insert branch. */
- l_split(&l, final_handler);
- il_b(&f, &r, label_split);
- if (insn_has_bdelay(relocs, split))
- i_nop(&f);
+ uasm_l_split(&l, final_handler);
+ uasm_il_b(&f, &r, label_split);
+ if (uasm_insn_has_bdelay(relocs, split))
+ uasm_i_nop(&f);
else {
- copy_handler(relocs, labels, split, split + 1, f);
- move_labels(labels, f, f + 1, -1);
+ uasm_copy_handler(relocs, labels, split, split + 1, f);
+ uasm_move_labels(labels, f, f + 1, -1);
f++;
split++;
}
/* Copy the rest of the handler. */
- copy_handler(relocs, labels, split, p, final_handler);
+ uasm_copy_handler(relocs, labels, split, p, final_handler);
final_len = (f - (final_handler + 32)) + (p - split);
}
#endif /* CONFIG_64BIT */
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB refill handler (%u instructions).\n",
- final_len);
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB refill handler (%u instructions).\n",
+ final_len);
f = final_handler;
#if defined(CONFIG_64BIT) && !defined(CONFIG_CPU_LOONGSON2)
@@ -1395,75 +786,75 @@ u32 __tlb_handler_align handle_tlbs[FASTPATH_SIZE];
u32 __tlb_handler_align handle_tlbm[FASTPATH_SIZE];
static void __init
-iPTE_LW(u32 **p, struct label **l, unsigned int pte, unsigned int ptr)
+iPTE_LW(u32 **p, struct uasm_label **l, unsigned int pte, unsigned int ptr)
{
#ifdef CONFIG_SMP
# ifdef CONFIG_64BIT_PHYS_ADDR
if (cpu_has_64bits)
- i_lld(p, pte, 0, ptr);
+ uasm_i_lld(p, pte, 0, ptr);
else
# endif
- i_LL(p, pte, 0, ptr);
+ UASM_i_LL(p, pte, 0, ptr);
#else
# ifdef CONFIG_64BIT_PHYS_ADDR
if (cpu_has_64bits)
- i_ld(p, pte, 0, ptr);
+ uasm_i_ld(p, pte, 0, ptr);
else
# endif
- i_LW(p, pte, 0, ptr);
+ UASM_i_LW(p, pte, 0, ptr);
#endif
}
static void __init
-iPTE_SW(u32 **p, struct reloc **r, unsigned int pte, unsigned int ptr,
+iPTE_SW(u32 **p, struct uasm_reloc **r, unsigned int pte, unsigned int ptr,
unsigned int mode)
{
#ifdef CONFIG_64BIT_PHYS_ADDR
unsigned int hwmode = mode & (_PAGE_VALID | _PAGE_DIRTY);
#endif
- i_ori(p, pte, pte, mode);
+ uasm_i_ori(p, pte, pte, mode);
#ifdef CONFIG_SMP
# ifdef CONFIG_64BIT_PHYS_ADDR
if (cpu_has_64bits)
- i_scd(p, pte, 0, ptr);
+ uasm_i_scd(p, pte, 0, ptr);
else
# endif
- i_SC(p, pte, 0, ptr);
+ UASM_i_SC(p, pte, 0, ptr);
if (r10000_llsc_war())
- il_beqzl(p, r, pte, label_smp_pgtable_change);
+ uasm_il_beqzl(p, r, pte, label_smp_pgtable_change);
else
- il_beqz(p, r, pte, label_smp_pgtable_change);
+ uasm_il_beqz(p, r, pte, label_smp_pgtable_change);
# ifdef CONFIG_64BIT_PHYS_ADDR
if (!cpu_has_64bits) {
- /* no i_nop needed */
- i_ll(p, pte, sizeof(pte_t) / 2, ptr);
- i_ori(p, pte, pte, hwmode);
- i_sc(p, pte, sizeof(pte_t) / 2, ptr);
- il_beqz(p, r, pte, label_smp_pgtable_change);
- /* no i_nop needed */
- i_lw(p, pte, 0, ptr);
+ /* no uasm_i_nop needed */
+ uasm_i_ll(p, pte, sizeof(pte_t) / 2, ptr);
+ uasm_i_ori(p, pte, pte, hwmode);
+ uasm_i_sc(p, pte, sizeof(pte_t) / 2, ptr);
+ uasm_il_beqz(p, r, pte, label_smp_pgtable_change);
+ /* no uasm_i_nop needed */
+ uasm_i_lw(p, pte, 0, ptr);
} else
- i_nop(p);
+ uasm_i_nop(p);
# else
- i_nop(p);
+ uasm_i_nop(p);
# endif
#else
# ifdef CONFIG_64BIT_PHYS_ADDR
if (cpu_has_64bits)
- i_sd(p, pte, 0, ptr);
+ uasm_i_sd(p, pte, 0, ptr);
else
# endif
- i_SW(p, pte, 0, ptr);
+ UASM_i_SW(p, pte, 0, ptr);
# ifdef CONFIG_64BIT_PHYS_ADDR
if (!cpu_has_64bits) {
- i_lw(p, pte, sizeof(pte_t) / 2, ptr);
- i_ori(p, pte, pte, hwmode);
- i_sw(p, pte, sizeof(pte_t) / 2, ptr);
- i_lw(p, pte, 0, ptr);
+ uasm_i_lw(p, pte, sizeof(pte_t) / 2, ptr);
+ uasm_i_ori(p, pte, pte, hwmode);
+ uasm_i_sw(p, pte, sizeof(pte_t) / 2, ptr);
+ uasm_i_lw(p, pte, 0, ptr);
}
# endif
#endif
@@ -1475,18 +866,18 @@ iPTE_SW(u32 **p, struct reloc **r, unsigned int pte, unsigned int ptr,
* with it's original value.
*/
static void __init
-build_pte_present(u32 **p, struct label **l, struct reloc **r,
+build_pte_present(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
unsigned int pte, unsigned int ptr, enum label_id lid)
{
- i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
- i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
- il_bnez(p, r, pte, lid);
+ uasm_i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
+ uasm_i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_READ);
+ uasm_il_bnez(p, r, pte, lid);
iPTE_LW(p, l, pte, ptr);
}
/* Make PTE valid, store result in PTR. */
static void __init
-build_make_valid(u32 **p, struct reloc **r, unsigned int pte,
+build_make_valid(u32 **p, struct uasm_reloc **r, unsigned int pte,
unsigned int ptr)
{
unsigned int mode = _PAGE_VALID | _PAGE_ACCESSED;
@@ -1499,12 +890,12 @@ build_make_valid(u32 **p, struct reloc **r, unsigned int pte,
* restore PTE with value from PTR when done.
*/
static void __init
-build_pte_writable(u32 **p, struct label **l, struct reloc **r,
+build_pte_writable(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
unsigned int pte, unsigned int ptr, enum label_id lid)
{
- i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
- i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
- il_bnez(p, r, pte, lid);
+ uasm_i_andi(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
+ uasm_i_xori(p, pte, pte, _PAGE_PRESENT | _PAGE_WRITE);
+ uasm_il_bnez(p, r, pte, lid);
iPTE_LW(p, l, pte, ptr);
}
@@ -1512,7 +903,7 @@ build_pte_writable(u32 **p, struct label **l, struct reloc **r,
* at PTR.
*/
static void __init
-build_make_write(u32 **p, struct reloc **r, unsigned int pte,
+build_make_write(u32 **p, struct uasm_reloc **r, unsigned int pte,
unsigned int ptr)
{
unsigned int mode = (_PAGE_ACCESSED | _PAGE_MODIFIED | _PAGE_VALID
@@ -1526,11 +917,11 @@ build_make_write(u32 **p, struct reloc **r, unsigned int pte,
* restore PTE with value from PTR when done.
*/
static void __init
-build_pte_modifiable(u32 **p, struct label **l, struct reloc **r,
+build_pte_modifiable(u32 **p, struct uasm_label **l, struct uasm_reloc **r,
unsigned int pte, unsigned int ptr, enum label_id lid)
{
- i_andi(p, pte, pte, _PAGE_WRITE);
- il_beqz(p, r, pte, lid);
+ uasm_i_andi(p, pte, pte, _PAGE_WRITE);
+ uasm_il_beqz(p, r, pte, lid);
iPTE_LW(p, l, pte, ptr);
}
@@ -1545,11 +936,11 @@ build_pte_modifiable(u32 **p, struct label **l, struct reloc **r,
static void __init
build_r3000_pte_reload_tlbwi(u32 **p, unsigned int pte, unsigned int tmp)
{
- i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
- i_mfc0(p, tmp, C0_EPC); /* cp0 delay */
- i_tlbwi(p);
- i_jr(p, tmp);
- i_rfe(p); /* branch delay */
+ uasm_i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
+ uasm_i_mfc0(p, tmp, C0_EPC); /* cp0 delay */
+ uasm_i_tlbwi(p);
+ uasm_i_jr(p, tmp);
+ uasm_i_rfe(p); /* branch delay */
}
/*
@@ -1559,20 +950,21 @@ build_r3000_pte_reload_tlbwi(u32 **p, unsigned int pte, unsigned int tmp)
* kseg2 access, i.e. without refill. Then it returns.
*/
static void __init
-build_r3000_tlb_reload_write(u32 **p, struct label **l, struct reloc **r,
- unsigned int pte, unsigned int tmp)
-{
- i_mfc0(p, tmp, C0_INDEX);
- i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
- il_bltz(p, r, tmp, label_r3000_write_probe_fail); /* cp0 delay */
- i_mfc0(p, tmp, C0_EPC); /* branch delay */
- i_tlbwi(p); /* cp0 delay */
- i_jr(p, tmp);
- i_rfe(p); /* branch delay */
- l_r3000_write_probe_fail(l, *p);
- i_tlbwr(p); /* cp0 delay */
- i_jr(p, tmp);
- i_rfe(p); /* branch delay */
+build_r3000_tlb_reload_write(u32 **p, struct uasm_label **l,
+ struct uasm_reloc **r, unsigned int pte,
+ unsigned int tmp)
+{
+ uasm_i_mfc0(p, tmp, C0_INDEX);
+ uasm_i_mtc0(p, pte, C0_ENTRYLO0); /* cp0 delay */
+ uasm_il_bltz(p, r, tmp, label_r3000_write_probe_fail); /* cp0 delay */
+ uasm_i_mfc0(p, tmp, C0_EPC); /* branch delay */
+ uasm_i_tlbwi(p); /* cp0 delay */
+ uasm_i_jr(p, tmp);
+ uasm_i_rfe(p); /* branch delay */
+ uasm_l_r3000_write_probe_fail(l, *p);
+ uasm_i_tlbwr(p); /* cp0 delay */
+ uasm_i_jr(p, tmp);
+ uasm_i_rfe(p); /* branch delay */
}
static void __init
@@ -1581,25 +973,25 @@ build_r3000_tlbchange_handler_head(u32 **p, unsigned int pte,
{
long pgdc = (long)pgd_current;
- i_mfc0(p, pte, C0_BADVADDR);
- i_lui(p, ptr, rel_hi(pgdc)); /* cp0 delay */
- i_lw(p, ptr, rel_lo(pgdc), ptr);
- i_srl(p, pte, pte, 22); /* load delay */
- i_sll(p, pte, pte, 2);
- i_addu(p, ptr, ptr, pte);
- i_mfc0(p, pte, C0_CONTEXT);
- i_lw(p, ptr, 0, ptr); /* cp0 delay */
- i_andi(p, pte, pte, 0xffc); /* load delay */
- i_addu(p, ptr, ptr, pte);
- i_lw(p, pte, 0, ptr);
- i_tlbp(p); /* load delay */
+ uasm_i_mfc0(p, pte, C0_BADVADDR);
+ uasm_i_lui(p, ptr, uasm_rel_hi(pgdc)); /* cp0 delay */
+ uasm_i_lw(p, ptr, uasm_rel_lo(pgdc), ptr);
+ uasm_i_srl(p, pte, pte, 22); /* load delay */
+ uasm_i_sll(p, pte, pte, 2);
+ uasm_i_addu(p, ptr, ptr, pte);
+ uasm_i_mfc0(p, pte, C0_CONTEXT);
+ uasm_i_lw(p, ptr, 0, ptr); /* cp0 delay */
+ uasm_i_andi(p, pte, pte, 0xffc); /* load delay */
+ uasm_i_addu(p, ptr, ptr, pte);
+ uasm_i_lw(p, pte, 0, ptr);
+ uasm_i_tlbp(p); /* load delay */
}
static void __init build_r3000_tlb_load_handler(void)
{
u32 *p = handle_tlbl;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
int i;
memset(handle_tlbl, 0, sizeof(handle_tlbl));
@@ -1608,20 +1000,20 @@ static void __init build_r3000_tlb_load_handler(void)
build_r3000_tlbchange_handler_head(&p, K0, K1);
build_pte_present(&p, &l, &r, K0, K1, label_nopage_tlbl);
- i_nop(&p); /* load delay */
+ uasm_i_nop(&p); /* load delay */
build_make_valid(&p, &r, K0, K1);
build_r3000_tlb_reload_write(&p, &l, &r, K0, K1);
- l_nopage_tlbl(&l, p);
- i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
- i_nop(&p);
+ uasm_l_nopage_tlbl(&l, p);
+ uasm_i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
+ uasm_i_nop(&p);
if ((p - handle_tlbl) > FASTPATH_SIZE)
panic("TLB load handler fastpath space exceeded");
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB load handler fastpath (%u instructions).\n",
- (unsigned int)(p - handle_tlbl));
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB load handler fastpath (%u instructions).\n",
+ (unsigned int)(p - handle_tlbl));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
@@ -1633,8 +1025,8 @@ static void __init build_r3000_tlb_load_handler(void)
static void __init build_r3000_tlb_store_handler(void)
{
u32 *p = handle_tlbs;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
int i;
memset(handle_tlbs, 0, sizeof(handle_tlbs));
@@ -1643,20 +1035,20 @@ static void __init build_r3000_tlb_store_handler(void)
build_r3000_tlbchange_handler_head(&p, K0, K1);
build_pte_writable(&p, &l, &r, K0, K1, label_nopage_tlbs);
- i_nop(&p); /* load delay */
+ uasm_i_nop(&p); /* load delay */
build_make_write(&p, &r, K0, K1);
build_r3000_tlb_reload_write(&p, &l, &r, K0, K1);
- l_nopage_tlbs(&l, p);
- i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
- i_nop(&p);
+ uasm_l_nopage_tlbs(&l, p);
+ uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+ uasm_i_nop(&p);
if ((p - handle_tlbs) > FASTPATH_SIZE)
panic("TLB store handler fastpath space exceeded");
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB store handler fastpath (%u instructions).\n",
- (unsigned int)(p - handle_tlbs));
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB store handler fastpath (%u instructions).\n",
+ (unsigned int)(p - handle_tlbs));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
@@ -1668,8 +1060,8 @@ static void __init build_r3000_tlb_store_handler(void)
static void __init build_r3000_tlb_modify_handler(void)
{
u32 *p = handle_tlbm;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
int i;
memset(handle_tlbm, 0, sizeof(handle_tlbm));
@@ -1678,20 +1070,20 @@ static void __init build_r3000_tlb_modify_handler(void)
build_r3000_tlbchange_handler_head(&p, K0, K1);
build_pte_modifiable(&p, &l, &r, K0, K1, label_nopage_tlbm);
- i_nop(&p); /* load delay */
+ uasm_i_nop(&p); /* load delay */
build_make_write(&p, &r, K0, K1);
build_r3000_pte_reload_tlbwi(&p, K0, K1);
- l_nopage_tlbm(&l, p);
- i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
- i_nop(&p);
+ uasm_l_nopage_tlbm(&l, p);
+ uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+ uasm_i_nop(&p);
if ((p - handle_tlbm) > FASTPATH_SIZE)
panic("TLB modify handler fastpath space exceeded");
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB modify handler fastpath (%u instructions).\n",
- (unsigned int)(p - handle_tlbm));
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB modify handler fastpath (%u instructions).\n",
+ (unsigned int)(p - handle_tlbm));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
@@ -1704,8 +1096,8 @@ static void __init build_r3000_tlb_modify_handler(void)
* R4000 style TLB load/store/modify handlers.
*/
static void __init
-build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
- struct reloc **r, unsigned int pte,
+build_r4000_tlbchange_handler_head(u32 **p, struct uasm_label **l,
+ struct uasm_reloc **r, unsigned int pte,
unsigned int ptr)
{
#ifdef CONFIG_64BIT
@@ -1714,14 +1106,14 @@ build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
build_get_pgde32(p, pte, ptr); /* get pgd in ptr */
#endif
- i_MFC0(p, pte, C0_BADVADDR);
- i_LW(p, ptr, 0, ptr);
- i_SRL(p, pte, pte, PAGE_SHIFT + PTE_ORDER - PTE_T_LOG2);
- i_andi(p, pte, pte, (PTRS_PER_PTE - 1) << PTE_T_LOG2);
- i_ADDU(p, ptr, ptr, pte);
+ UASM_i_MFC0(p, pte, C0_BADVADDR);
+ UASM_i_LW(p, ptr, 0, ptr);
+ UASM_i_SRL(p, pte, pte, PAGE_SHIFT + PTE_ORDER - PTE_T_LOG2);
+ uasm_i_andi(p, pte, pte, (PTRS_PER_PTE - 1) << PTE_T_LOG2);
+ UASM_i_ADDU(p, ptr, ptr, pte);
#ifdef CONFIG_SMP
- l_smp_pgtable_change(l, *p);
+ uasm_l_smp_pgtable_change(l, *p);
# endif
iPTE_LW(p, l, pte, ptr); /* get even pte */
if (!m4kc_tlbp_war())
@@ -1729,16 +1121,16 @@ build_r4000_tlbchange_handler_head(u32 **p, struct label **l,
}
static void __init
-build_r4000_tlbchange_handler_tail(u32 **p, struct label **l,
- struct reloc **r, unsigned int tmp,
+build_r4000_tlbchange_handler_tail(u32 **p, struct uasm_label **l,
+ struct uasm_reloc **r, unsigned int tmp,
unsigned int ptr)
{
- i_ori(p, ptr, ptr, sizeof(pte_t));
- i_xori(p, ptr, ptr, sizeof(pte_t));
+ uasm_i_ori(p, ptr, ptr, sizeof(pte_t));
+ uasm_i_xori(p, ptr, ptr, sizeof(pte_t));
build_update_entries(p, tmp, ptr);
build_tlb_write_entry(p, l, r, tlb_indexed);
- l_leave(l, *p);
- i_eret(p); /* return from trap */
+ uasm_l_leave(l, *p);
+ uasm_i_eret(p); /* return from trap */
#ifdef CONFIG_64BIT
build_get_pgd_vmalloc64(p, l, r, tmp, ptr);
@@ -1748,8 +1140,8 @@ build_r4000_tlbchange_handler_tail(u32 **p, struct label **l,
static void __init build_r4000_tlb_load_handler(void)
{
u32 *p = handle_tlbl;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
int i;
memset(handle_tlbl, 0, sizeof(handle_tlbl));
@@ -1757,12 +1149,12 @@ static void __init build_r4000_tlb_load_handler(void)
memset(relocs, 0, sizeof(relocs));
if (bcm1250_m3_war()) {
- i_MFC0(&p, K0, C0_BADVADDR);
- i_MFC0(&p, K1, C0_ENTRYHI);
- i_xor(&p, K0, K0, K1);
- i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
- il_bnez(&p, &r, K0, label_leave);
- /* No need for i_nop */
+ UASM_i_MFC0(&p, K0, C0_BADVADDR);
+ UASM_i_MFC0(&p, K1, C0_ENTRYHI);
+ uasm_i_xor(&p, K0, K0, K1);
+ UASM_i_SRL(&p, K0, K0, PAGE_SHIFT + 1);
+ uasm_il_bnez(&p, &r, K0, label_leave);
+ /* No need for uasm_i_nop */
}
build_r4000_tlbchange_handler_head(&p, &l, &r, K0, K1);
@@ -1772,16 +1164,16 @@ static void __init build_r4000_tlb_load_handler(void)
build_make_valid(&p, &r, K0, K1);
build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
- l_nopage_tlbl(&l, p);
- i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
- i_nop(&p);
+ uasm_l_nopage_tlbl(&l, p);
+ uasm_i_j(&p, (unsigned long)tlb_do_page_fault_0 & 0x0fffffff);
+ uasm_i_nop(&p);
if ((p - handle_tlbl) > FASTPATH_SIZE)
panic("TLB load handler fastpath space exceeded");
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB load handler fastpath (%u instructions).\n",
- (unsigned int)(p - handle_tlbl));
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB load handler fastpath (%u instructions).\n",
+ (unsigned int)(p - handle_tlbl));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
@@ -1793,8 +1185,8 @@ static void __init build_r4000_tlb_load_handler(void)
static void __init build_r4000_tlb_store_handler(void)
{
u32 *p = handle_tlbs;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
int i;
memset(handle_tlbs, 0, sizeof(handle_tlbs));
@@ -1808,16 +1200,16 @@ static void __init build_r4000_tlb_store_handler(void)
build_make_write(&p, &r, K0, K1);
build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
- l_nopage_tlbs(&l, p);
- i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
- i_nop(&p);
+ uasm_l_nopage_tlbs(&l, p);
+ uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+ uasm_i_nop(&p);
if ((p - handle_tlbs) > FASTPATH_SIZE)
panic("TLB store handler fastpath space exceeded");
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB store handler fastpath (%u instructions).\n",
- (unsigned int)(p - handle_tlbs));
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB store handler fastpath (%u instructions).\n",
+ (unsigned int)(p - handle_tlbs));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
@@ -1829,8 +1221,8 @@ static void __init build_r4000_tlb_store_handler(void)
static void __init build_r4000_tlb_modify_handler(void)
{
u32 *p = handle_tlbm;
- struct label *l = labels;
- struct reloc *r = relocs;
+ struct uasm_label *l = labels;
+ struct uasm_reloc *r = relocs;
int i;
memset(handle_tlbm, 0, sizeof(handle_tlbm));
@@ -1845,16 +1237,16 @@ static void __init build_r4000_tlb_modify_handler(void)
build_make_write(&p, &r, K0, K1);
build_r4000_tlbchange_handler_tail(&p, &l, &r, K0, K1);
- l_nopage_tlbm(&l, p);
- i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
- i_nop(&p);
+ uasm_l_nopage_tlbm(&l, p);
+ uasm_i_j(&p, (unsigned long)tlb_do_page_fault_1 & 0x0fffffff);
+ uasm_i_nop(&p);
if ((p - handle_tlbm) > FASTPATH_SIZE)
panic("TLB modify handler fastpath space exceeded");
- resolve_relocs(relocs, labels);
- pr_info("Synthesized TLB modify handler fastpath (%u instructions).\n",
- (unsigned int)(p - handle_tlbm));
+ uasm_resolve_relocs(relocs, labels);
+ pr_debug("Wrote TLB modify handler fastpath (%u instructions).\n",
+ (unsigned int)(p - handle_tlbm));
pr_debug("\t.set push\n");
pr_debug("\t.set noreorder\n");
diff --git a/arch/mips/mm/uasm.c b/arch/mips/mm/uasm.c
new file mode 100644
index 0000000..889176a
--- /dev/null
+++ b/arch/mips/mm/uasm.c
@@ -0,0 +1,566 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * A small micro-assembler. It is intentionally kept simple, does only
+ * support a subset of instructions, and does not try to hide pipeline
+ * effects like branch delay slots.
+ *
+ * Copyright (C) 2004,2005,2006,2008 Thiemo Seufer
+ * Copyright (C) 2005 Maciej W. Rozycki
+ * Copyright (C) 2006 Ralf Baechle (ralf@linux-mips.org)
+ */
+
+#include <stdarg.h>
+
+#include <linux/mm.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/init.h>
+
+#include <asm/inst.h>
+#include <asm/elf.h>
+
+#include "uasm.h"
+
+enum fields {
+ RS = 0x001,
+ RT = 0x002,
+ RD = 0x004,
+ RE = 0x008,
+ SIMM = 0x010,
+ UIMM = 0x020,
+ BIMM = 0x040,
+ JIMM = 0x080,
+ FUNC = 0x100,
+ SET = 0x200
+};
+
+#define OP_MASK 0x3f
+#define OP_SH 26
+#define RS_MASK 0x1f
+#define RS_SH 21
+#define RT_MASK 0x1f
+#define RT_SH 16
+#define RD_MASK 0x1f
+#define RD_SH 11
+#define RE_MASK 0x1f
+#define RE_SH 6
+#define IMM_MASK 0xffff
+#define IMM_SH 0
+#define JIMM_MASK 0x3ffffff
+#define JIMM_SH 0
+#define FUNC_MASK 0x3f
+#define FUNC_SH 0
+#define SET_MASK 0x7
+#define SET_SH 0
+
+enum opcode {
+ insn_invalid,
+ insn_addu, insn_addiu, insn_and, insn_andi, insn_beq,
+ insn_beql, insn_bgez, insn_bgezl, insn_bltz, insn_bltzl,
+ insn_bne, insn_daddu, insn_daddiu, insn_dmfc0, insn_dmtc0,
+ insn_dsll, insn_dsll32, insn_dsra, insn_dsrl, insn_dsrl32,
+ insn_dsubu, insn_eret, insn_j, insn_jal, insn_jr, insn_ld,
+ insn_ll, insn_lld, insn_lui, insn_lw, insn_mfc0, insn_mtc0,
+ insn_ori, insn_rfe, insn_sc, insn_scd, insn_sd, insn_sll,
+ insn_sra, insn_srl, insn_subu, insn_sw, insn_tlbp, insn_tlbwi,
+ insn_tlbwr, insn_xor, insn_xori
+};
+
+struct insn {
+ enum opcode opcode;
+ u32 match;
+ enum fields fields;
+};
+
+/* This macro sets the non-variable bits of an instruction. */
+#define M(a, b, c, d, e, f) \
+ ((a) << OP_SH \
+ | (b) << RS_SH \
+ | (c) << RT_SH \
+ | (d) << RD_SH \
+ | (e) << RE_SH \
+ | (f) << FUNC_SH)
+
+static __initdata struct insn insn_table[] = {
+ { insn_addiu, M(addiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_addu, M(spec_op, 0, 0, 0, 0, addu_op), RS | RT | RD },
+ { insn_and, M(spec_op, 0, 0, 0, 0, and_op), RS | RT | RD },
+ { insn_andi, M(andi_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
+ { insn_beq, M(beq_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
+ { insn_beql, M(beql_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
+ { insn_bgez, M(bcond_op, 0, bgez_op, 0, 0, 0), RS | BIMM },
+ { insn_bgezl, M(bcond_op, 0, bgezl_op, 0, 0, 0), RS | BIMM },
+ { insn_bltz, M(bcond_op, 0, bltz_op, 0, 0, 0), RS | BIMM },
+ { insn_bltzl, M(bcond_op, 0, bltzl_op, 0, 0, 0), RS | BIMM },
+ { insn_bne, M(bne_op, 0, 0, 0, 0, 0), RS | RT | BIMM },
+ { insn_daddiu, M(daddiu_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_daddu, M(spec_op, 0, 0, 0, 0, daddu_op), RS | RT | RD },
+ { insn_dmfc0, M(cop0_op, dmfc_op, 0, 0, 0, 0), RT | RD | SET},
+ { insn_dmtc0, M(cop0_op, dmtc_op, 0, 0, 0, 0), RT | RD | SET},
+ { insn_dsll, M(spec_op, 0, 0, 0, 0, dsll_op), RT | RD | RE },
+ { insn_dsll32, M(spec_op, 0, 0, 0, 0, dsll32_op), RT | RD | RE },
+ { insn_dsra, M(spec_op, 0, 0, 0, 0, dsra_op), RT | RD | RE },
+ { insn_dsrl, M(spec_op, 0, 0, 0, 0, dsrl_op), RT | RD | RE },
+ { insn_dsrl32, M(spec_op, 0, 0, 0, 0, dsrl32_op), RT | RD | RE },
+ { insn_dsubu, M(spec_op, 0, 0, 0, 0, dsubu_op), RS | RT | RD },
+ { insn_eret, M(cop0_op, cop_op, 0, 0, 0, eret_op), 0 },
+ { insn_j, M(j_op, 0, 0, 0, 0, 0), JIMM },
+ { insn_jal, M(jal_op, 0, 0, 0, 0, 0), JIMM },
+ { insn_jr, M(spec_op, 0, 0, 0, 0, jr_op), RS },
+ { insn_ld, M(ld_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_ll, M(ll_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_lld, M(lld_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_lui, M(lui_op, 0, 0, 0, 0, 0), RT | SIMM },
+ { insn_lw, M(lw_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_mfc0, M(cop0_op, mfc_op, 0, 0, 0, 0), RT | RD | SET},
+ { insn_mtc0, M(cop0_op, mtc_op, 0, 0, 0, 0), RT | RD | SET},
+ { insn_ori, M(ori_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
+ { insn_rfe, M(cop0_op, cop_op, 0, 0, 0, rfe_op), 0 },
+ { insn_sc, M(sc_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_scd, M(scd_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_sd, M(sd_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_sll, M(spec_op, 0, 0, 0, 0, sll_op), RT | RD | RE },
+ { insn_sra, M(spec_op, 0, 0, 0, 0, sra_op), RT | RD | RE },
+ { insn_srl, M(spec_op, 0, 0, 0, 0, srl_op), RT | RD | RE },
+ { insn_subu, M(spec_op, 0, 0, 0, 0, subu_op), RS | RT | RD },
+ { insn_sw, M(sw_op, 0, 0, 0, 0, 0), RS | RT | SIMM },
+ { insn_tlbp, M(cop0_op, cop_op, 0, 0, 0, tlbp_op), 0 },
+ { insn_tlbwi, M(cop0_op, cop_op, 0, 0, 0, tlbwi_op), 0 },
+ { insn_tlbwr, M(cop0_op, cop_op, 0, 0, 0, tlbwr_op), 0 },
+ { insn_xor, M(spec_op, 0, 0, 0, 0, xor_op), RS | RT | RD },
+ { insn_xori, M(xori_op, 0, 0, 0, 0, 0), RS | RT | UIMM },
+ { insn_invalid, 0, 0 }
+};
+
+#undef M
+
+static inline __init u32 build_rs(u32 arg)
+{
+ if (arg & ~RS_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return (arg & RS_MASK) << RS_SH;
+}
+
+static inline __init u32 build_rt(u32 arg)
+{
+ if (arg & ~RT_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return (arg & RT_MASK) << RT_SH;
+}
+
+static inline __init u32 build_rd(u32 arg)
+{
+ if (arg & ~RD_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return (arg & RD_MASK) << RD_SH;
+}
+
+static inline __init u32 build_re(u32 arg)
+{
+ if (arg & ~RE_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return (arg & RE_MASK) << RE_SH;
+}
+
+static inline __init u32 build_simm(s32 arg)
+{
+ if (arg > 0x7fff || arg < -0x8000)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return arg & 0xffff;
+}
+
+static inline __init u32 build_uimm(u32 arg)
+{
+ if (arg & ~IMM_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return arg & IMM_MASK;
+}
+
+static inline __init u32 build_bimm(s32 arg)
+{
+ if (arg > 0x1ffff || arg < -0x20000)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ if (arg & 0x3)
+ printk(KERN_WARNING "Invalid micro-assembler branch target\n");
+
+ return ((arg < 0) ? (1 << 15) : 0) | ((arg >> 2) & 0x7fff);
+}
+
+static inline __init u32 build_jimm(u32 arg)
+{
+ if (arg & ~((JIMM_MASK) << 2))
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return (arg >> 2) & JIMM_MASK;
+}
+
+static inline __init u32 build_func(u32 arg)
+{
+ if (arg & ~FUNC_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return arg & FUNC_MASK;
+}
+
+static inline __init u32 build_set(u32 arg)
+{
+ if (arg & ~SET_MASK)
+ printk(KERN_WARNING "Micro-assembler field overflow\n");
+
+ return arg & SET_MASK;
+}
+
+/*
+ * The order of opcode arguments is implicitly left to right,
+ * starting with RS and ending with FUNC or IMM.
+ */
+static void __init build_insn(u32 **buf, enum opcode opc, ...)
+{
+ struct insn *ip = NULL;
+ unsigned int i;
+ va_list ap;
+ u32 op;
+
+ for (i = 0; insn_table[i].opcode != insn_invalid; i++)
+ if (insn_table[i].opcode == opc) {
+ ip = &insn_table[i];
+ break;
+ }
+
+ if (!ip)
+ panic("Unsupported Micro-assembler instruction %d", opc);
+
+ op = ip->match;
+ va_start(ap, opc);
+ if (ip->fields & RS)
+ op |= build_rs(va_arg(ap, u32));
+ if (ip->fields & RT)
+ op |= build_rt(va_arg(ap, u32));
+ if (ip->fields & RD)
+ op |= build_rd(va_arg(ap, u32));
+ if (ip->fields & RE)
+ op |= build_re(va_arg(ap, u32));
+ if (ip->fields & SIMM)
+ op |= build_simm(va_arg(ap, s32));
+ if (ip->fields & UIMM)
+ op |= build_uimm(va_arg(ap, u32));
+ if (ip->fields & BIMM)
+ op |= build_bimm(va_arg(ap, s32));
+ if (ip->fields & JIMM)
+ op |= build_jimm(va_arg(ap, u32));
+ if (ip->fields & FUNC)
+ op |= build_func(va_arg(ap, u32));
+ if (ip->fields & SET)
+ op |= build_set(va_arg(ap, u32));
+ va_end(ap);
+
+ **buf = op;
+ (*buf)++;
+}
+
+#define I_u1u2u3(op) \
+Ip_u1u2u3(op) \
+{ \
+ build_insn(buf, insn##op, a, b, c); \
+}
+
+#define I_u2u1u3(op) \
+Ip_u2u1u3(op) \
+{ \
+ build_insn(buf, insn##op, b, a, c); \
+}
+
+#define I_u3u1u2(op) \
+Ip_u3u1u2(op) \
+{ \
+ build_insn(buf, insn##op, b, c, a); \
+}
+
+#define I_u1u2s3(op) \
+Ip_u1u2s3(op) \
+{ \
+ build_insn(buf, insn##op, a, b, c); \
+}
+
+#define I_u2s3u1(op) \
+Ip_u2s3u1(op) \
+{ \
+ build_insn(buf, insn##op, c, a, b); \
+}
+
+#define I_u2u1s3(op) \
+Ip_u2u1s3(op) \
+{ \
+ build_insn(buf, insn##op, b, a, c); \
+}
+
+#define I_u1u2(op) \
+Ip_u1u2(op) \
+{ \
+ build_insn(buf, insn##op, a, b); \
+}
+
+#define I_u1s2(op) \
+Ip_u1s2(op) \
+{ \
+ build_insn(buf, insn##op, a, b); \
+}
+
+#define I_u1(op) \
+Ip_u1(op) \
+{ \
+ build_insn(buf, insn##op, a); \
+}
+
+#define I_0(op) \
+Ip_0(op) \
+{ \
+ build_insn(buf, insn##op); \
+}
+
+I_u2u1s3(_addiu)
+I_u3u1u2(_addu)
+I_u2u1u3(_andi)
+I_u3u1u2(_and)
+I_u1u2s3(_beq)
+I_u1u2s3(_beql)
+I_u1s2(_bgez)
+I_u1s2(_bgezl)
+I_u1s2(_bltz)
+I_u1s2(_bltzl)
+I_u1u2s3(_bne)
+I_u1u2u3(_dmfc0)
+I_u1u2u3(_dmtc0)
+I_u2u1s3(_daddiu)
+I_u3u1u2(_daddu)
+I_u2u1u3(_dsll)
+I_u2u1u3(_dsll32)
+I_u2u1u3(_dsra)
+I_u2u1u3(_dsrl)
+I_u2u1u3(_dsrl32)
+I_u3u1u2(_dsubu)
+I_0(_eret)
+I_u1(_j)
+I_u1(_jal)
+I_u1(_jr)
+I_u2s3u1(_ld)
+I_u2s3u1(_ll)
+I_u2s3u1(_lld)
+I_u1s2(_lui)
+I_u2s3u1(_lw)
+I_u1u2u3(_mfc0)
+I_u1u2u3(_mtc0)
+I_u2u1u3(_ori)
+I_0(_rfe)
+I_u2s3u1(_sc)
+I_u2s3u1(_scd)
+I_u2s3u1(_sd)
+I_u2u1u3(_sll)
+I_u2u1u3(_sra)
+I_u2u1u3(_srl)
+I_u3u1u2(_subu)
+I_u2s3u1(_sw)
+I_0(_tlbp)
+I_0(_tlbwi)
+I_0(_tlbwr)
+I_u3u1u2(_xor)
+I_u2u1u3(_xori)
+
+/* Handle labels. */
+__init void uasm_build_label(struct uasm_label **lab, u32 *addr, int lid)
+{
+ (*lab)->addr = addr;
+ (*lab)->lab = lid;
+ (*lab)++;
+}
+
+#ifdef CONFIG_64BIT
+__init int uasm_in_compat_space_p(long addr)
+{
+ /* Is this address in 32bit compat space? */
+ return (((addr) & 0xffffffff00000000L) == 0xffffffff00000000L);
+}
+
+__init int uasm_rel_highest(long val)
+{
+ return ((((val + 0x800080008000L) >> 48) & 0xffff) ^ 0x8000) - 0x8000;
+}
+
+__init int uasm_rel_higher(long val)
+{
+ return ((((val + 0x80008000L) >> 32) & 0xffff) ^ 0x8000) - 0x8000;
+}
+#endif
+
+__init int uasm_rel_hi(long val)
+{
+ return ((((val + 0x8000L) >> 16) & 0xffff) ^ 0x8000) - 0x8000;
+}
+
+__init int uasm_rel_lo(long val)
+{
+ return ((val & 0xffff) ^ 0x8000) - 0x8000;
+}
+
+__init void UASM_i_LA_mostly(u32 **buf, unsigned int rs, long addr)
+{
+#ifdef CONFIG_64BIT
+ if (!uasm_in_compat_space_p(addr)) {
+ uasm_i_lui(buf, rs, uasm_rel_highest(addr));
+ if (uasm_rel_higher(addr))
+ uasm_i_daddiu(buf, rs, rs, uasm_rel_higher(addr));
+ if (uasm_rel_hi(addr)) {
+ uasm_i_dsll(buf, rs, rs, 16);
+ uasm_i_daddiu(buf, rs, rs, uasm_rel_hi(addr));
+ uasm_i_dsll(buf, rs, rs, 16);
+ } else
+ uasm_i_dsll32(buf, rs, rs, 0);
+ } else
+#endif
+ uasm_i_lui(buf, rs, uasm_rel_hi(addr));
+}
+
+__init void UASM_i_LA(u32 **buf, unsigned int rs, long addr)
+{
+ UASM_i_LA_mostly(buf, rs, addr);
+ if (uasm_rel_lo(addr))
+ UASM_i_ADDIU(buf, rs, rs, uasm_rel_lo(addr));
+}
+
+/* Handle relocations. */
+__init void
+uasm_r_mips_pc16(struct uasm_reloc **rel, u32 *addr, int lid)
+{
+ (*rel)->addr = addr;
+ (*rel)->type = R_MIPS_PC16;
+ (*rel)->lab = lid;
+ (*rel)++;
+}
+
+static inline void
+__resolve_relocs(struct uasm_reloc *rel, struct uasm_label *lab)
+{
+ long laddr = (long)lab->addr;
+ long raddr = (long)rel->addr;
+
+ switch (rel->type) {
+ case R_MIPS_PC16:
+ *rel->addr |= build_bimm(laddr - (raddr + 4));
+ break;
+
+ default:
+ panic("Unsupported Micro-assembler relocation %d",
+ rel->type);
+ }
+}
+
+__init void
+uasm_resolve_relocs(struct uasm_reloc *rel, struct uasm_label *lab)
+{
+ struct uasm_label *l;
+
+ for (; rel->lab != UASM_LABEL_INVALID; rel++)
+ for (l = lab; l->lab != UASM_LABEL_INVALID; l++)
+ if (rel->lab == l->lab)
+ __resolve_relocs(rel, l);
+}
+
+__init void
+uasm_move_relocs(struct uasm_reloc *rel, u32 *first, u32 *end, long off)
+{
+ for (; rel->lab != UASM_LABEL_INVALID; rel++)
+ if (rel->addr >= first && rel->addr < end)
+ rel->addr += off;
+}
+
+__init void
+uasm_move_labels(struct uasm_label *lab, u32 *first, u32 *end, long off)
+{
+ for (; lab->lab != UASM_LABEL_INVALID; lab++)
+ if (lab->addr >= first && lab->addr < end)
+ lab->addr += off;
+}
+
+__init void
+uasm_copy_handler(struct uasm_reloc *rel, struct uasm_label *lab, u32 *first,
+ u32 *end, u32 *target)
+{
+ long off = (long)(target - first);
+
+ memcpy(target, first, (end - first) * sizeof(u32));
+
+ uasm_move_relocs(rel, first, end, off);
+ uasm_move_labels(lab, first, end, off);
+}
+
+__init int uasm_insn_has_bdelay(struct uasm_reloc *rel, u32 *addr)
+{
+ for (; rel->lab != UASM_LABEL_INVALID; rel++) {
+ if (rel->addr == addr
+ && (rel->type == R_MIPS_PC16
+ || rel->type == R_MIPS_26))
+ return 1;
+ }
+
+ return 0;
+}
+
+/* Convenience functions for labeled branches. */
+void __init
+uasm_il_bltz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_bltz(p, reg, 0);
+}
+
+void __init
+uasm_il_b(u32 **p, struct uasm_reloc **r, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_b(p, 0);
+}
+
+void __init
+uasm_il_beqz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_beqz(p, reg, 0);
+}
+
+void __init
+uasm_il_beqzl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_beqzl(p, reg, 0);
+}
+
+void __init
+uasm_il_bnez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_bnez(p, reg, 0);
+}
+
+void __init
+uasm_il_bgezl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_bgezl(p, reg, 0);
+}
+
+void __init
+uasm_il_bgez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid)
+{
+ uasm_r_mips_pc16(r, *p, lid);
+ uasm_i_bgez(p, reg, 0);
+}
diff --git a/arch/mips/mm/uasm.h b/arch/mips/mm/uasm.h
new file mode 100644
index 0000000..e0053b0
--- /dev/null
+++ b/arch/mips/mm/uasm.h
@@ -0,0 +1,192 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2004,2005,2006,2008 Thiemo Seufer
+ * Copyright (C) 2005 Maciej W. Rozycki
+ * Copyright (C) 2006 Ralf Baechle (ralf@linux-mips.org)
+ */
+
+#include <linux/types.h>
+
+#define Ip_u1u2u3(op) \
+void __init \
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, unsigned int c)
+
+#define Ip_u2u1u3(op) \
+void __init \
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, unsigned int c)
+
+#define Ip_u3u1u2(op) \
+void __init \
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, unsigned int c)
+
+#define Ip_u1u2s3(op) \
+void __init \
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, signed int c)
+
+#define Ip_u2s3u1(op) \
+void __init \
+uasm_i##op(u32 **buf, unsigned int a, signed int b, unsigned int c)
+
+#define Ip_u2u1s3(op) \
+void __init \
+uasm_i##op(u32 **buf, unsigned int a, unsigned int b, signed int c)
+
+#define Ip_u1u2(op) \
+void __init uasm_i##op(u32 **buf, unsigned int a, unsigned int b)
+
+#define Ip_u1s2(op) \
+void __init uasm_i##op(u32 **buf, unsigned int a, signed int b)
+
+#define Ip_u1(op) void __init uasm_i##op(u32 **buf, unsigned int a)
+
+#define Ip_0(op) void __init uasm_i##op(u32 **buf)
+
+Ip_u2u1s3(_addiu);
+Ip_u3u1u2(_addu);
+Ip_u2u1u3(_andi);
+Ip_u3u1u2(_and);
+Ip_u1u2s3(_beq);
+Ip_u1u2s3(_beql);
+Ip_u1s2(_bgez);
+Ip_u1s2(_bgezl);
+Ip_u1s2(_bltz);
+Ip_u1s2(_bltzl);
+Ip_u1u2s3(_bne);
+Ip_u1u2u3(_dmfc0);
+Ip_u1u2u3(_dmtc0);
+Ip_u2u1s3(_daddiu);
+Ip_u3u1u2(_daddu);
+Ip_u2u1u3(_dsll);
+Ip_u2u1u3(_dsll32);
+Ip_u2u1u3(_dsra);
+Ip_u2u1u3(_dsrl);
+Ip_u2u1u3(_dsrl32);
+Ip_u3u1u2(_dsubu);
+Ip_0(_eret);
+Ip_u1(_j);
+Ip_u1(_jal);
+Ip_u1(_jr);
+Ip_u2s3u1(_ld);
+Ip_u2s3u1(_ll);
+Ip_u2s3u1(_lld);
+Ip_u1s2(_lui);
+Ip_u2s3u1(_lw);
+Ip_u1u2u3(_mfc0);
+Ip_u1u2u3(_mtc0);
+Ip_u2u1u3(_ori);
+Ip_0(_rfe);
+Ip_u2s3u1(_sc);
+Ip_u2s3u1(_scd);
+Ip_u2s3u1(_sd);
+Ip_u2u1u3(_sll);
+Ip_u2u1u3(_sra);
+Ip_u2u1u3(_srl);
+Ip_u3u1u2(_subu);
+Ip_u2s3u1(_sw);
+Ip_0(_tlbp);
+Ip_0(_tlbwi);
+Ip_0(_tlbwr);
+Ip_u3u1u2(_xor);
+Ip_u2u1u3(_xori);
+
+/* Handle labels. */
+struct uasm_label {
+ u32 *addr;
+ int lab;
+};
+
+__init void uasm_build_label(struct uasm_label **lab, u32 *addr, int lid);
+#ifdef CONFIG_64BIT
+__init int uasm_in_compat_space_p(long addr);
+__init int uasm_rel_highest(long val);
+__init int uasm_rel_higher(long val);
+#endif
+__init int uasm_rel_hi(long val);
+__init int uasm_rel_lo(long val);
+__init void UASM_i_LA_mostly(u32 **buf, unsigned int rs, long addr);
+__init void UASM_i_LA(u32 **buf, unsigned int rs, long addr);
+
+#define UASM_L_LA(lb) \
+static inline void uasm_l##lb(struct uasm_label **lab, u32 *addr) \
+{ \
+ uasm_build_label(lab, addr, label##lb); \
+}
+
+/* convenience macros for instructions */
+#ifdef CONFIG_64BIT
+# define UASM_i_LW(buf, rs, rt, off) uasm_i_ld(buf, rs, rt, off)
+# define UASM_i_SW(buf, rs, rt, off) uasm_i_sd(buf, rs, rt, off)
+# define UASM_i_SLL(buf, rs, rt, sh) uasm_i_dsll(buf, rs, rt, sh)
+# define UASM_i_SRA(buf, rs, rt, sh) uasm_i_dsra(buf, rs, rt, sh)
+# define UASM_i_SRL(buf, rs, rt, sh) uasm_i_dsrl(buf, rs, rt, sh)
+# define UASM_i_MFC0(buf, rt, rd...) uasm_i_dmfc0(buf, rt, rd)
+# define UASM_i_MTC0(buf, rt, rd...) uasm_i_dmtc0(buf, rt, rd)
+# define UASM_i_ADDIU(buf, rs, rt, val) uasm_i_daddiu(buf, rs, rt, val)
+# define UASM_i_ADDU(buf, rs, rt, rd) uasm_i_daddu(buf, rs, rt, rd)
+# define UASM_i_SUBU(buf, rs, rt, rd) uasm_i_dsubu(buf, rs, rt, rd)
+# define UASM_i_LL(buf, rs, rt, off) uasm_i_lld(buf, rs, rt, off)
+# define UASM_i_SC(buf, rs, rt, off) uasm_i_scd(buf, rs, rt, off)
+#else
+# define UASM_i_LW(buf, rs, rt, off) uasm_i_lw(buf, rs, rt, off)
+# define UASM_i_SW(buf, rs, rt, off) uasm_i_sw(buf, rs, rt, off)
+# define UASM_i_SLL(buf, rs, rt, sh) uasm_i_sll(buf, rs, rt, sh)
+# define UASM_i_SRA(buf, rs, rt, sh) uasm_i_sra(buf, rs, rt, sh)
+# define UASM_i_SRL(buf, rs, rt, sh) uasm_i_srl(buf, rs, rt, sh)
+# define UASM_i_MFC0(buf, rt, rd...) uasm_i_mfc0(buf, rt, rd)
+# define UASM_i_MTC0(buf, rt, rd...) uasm_i_mtc0(buf, rt, rd)
+# define UASM_i_ADDIU(buf, rs, rt, val) uasm_i_addiu(buf, rs, rt, val)
+# define UASM_i_ADDU(buf, rs, rt, rd) uasm_i_addu(buf, rs, rt, rd)
+# define UASM_i_SUBU(buf, rs, rt, rd) uasm_i_subu(buf, rs, rt, rd)
+# define UASM_i_LL(buf, rs, rt, off) uasm_i_ll(buf, rs, rt, off)
+# define UASM_i_SC(buf, rs, rt, off) uasm_i_sc(buf, rs, rt, off)
+#endif
+
+#define uasm_i_b(buf, off) uasm_i_beq(buf, 0, 0, off)
+#define uasm_i_beqz(buf, rs, off) uasm_i_beq(buf, rs, 0, off)
+#define uasm_i_beqzl(buf, rs, off) uasm_i_beql(buf, rs, 0, off)
+#define uasm_i_bnez(buf, rs, off) uasm_i_bne(buf, rs, 0, off)
+#define uasm_i_bnezl(buf, rs, off) uasm_i_bnel(buf, rs, 0, off)
+#define uasm_i_move(buf, a, b) UASM_i_ADDU(buf, a, 0, b)
+#define uasm_i_nop(buf) uasm_i_sll(buf, 0, 0, 0)
+#define uasm_i_ssnop(buf) uasm_i_sll(buf, 0, 0, 1)
+#define uasm_i_ehb(buf) uasm_i_sll(buf, 0, 0, 3)
+
+/* Handle relocations. */
+struct uasm_reloc {
+ u32 *addr;
+ unsigned int type;
+ int lab;
+};
+
+/* This is zero so we can use zeroed label arrays. */
+#define UASM_LABEL_INVALID 0
+
+__init void uasm_r_mips_pc16(struct uasm_reloc **rel, u32 *addr, int lid);
+__init void
+uasm_resolve_relocs(struct uasm_reloc *rel, struct uasm_label *lab);
+__init void
+uasm_move_relocs(struct uasm_reloc *rel, u32 *first, u32 *end, long off);
+__init void
+uasm_move_labels(struct uasm_label *lab, u32 *first, u32 *end, long off);
+__init void
+uasm_copy_handler(struct uasm_reloc *rel, struct uasm_label *lab, u32 *first,
+ u32 *end, u32 *target);
+__init int uasm_insn_has_bdelay(struct uasm_reloc *rel, u32 *addr);
+
+/* Convenience functions for labeled branches. */
+void __init
+uasm_il_bltz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init uasm_il_b(u32 **p, struct uasm_reloc **r, int lid);
+void __init
+uasm_il_beqz(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_beqzl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_bnez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_bgezl(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
+void __init
+uasm_il_bgez(u32 **p, struct uasm_reloc **r, unsigned int reg, int lid);
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2008-01-22 0:00 (no subject) Thiemo Seufer
@ 2008-01-28 17:51 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 2008-01-28 17:51 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: linux-mips
On Tue, Jan 22, 2008 at 12:00:26AM +0000, Thiemo Seufer wrote:
> This patch moves the micro-assembler in a separate implementation, as
> it is useful for further run-time optimizations. The only change in
> behaviour is cutting down printk noise at kernel startup time.
>
> Checkpatch complains about macro parameters which aren't protected by
> parentheses. I believe this is a flaw in checkpatch, the paste operator
> used in those macros won't work with parenthesised parameters.
>
> Tested on:
> - Qemu 32-bit little endian
> - BCM1480 64-bit big endian
>
>
> Thiemo
>
>
> ---
> Split the micro-assembler from tlbex.c.
>
> Signed-off-by: Thiemo Seufer <ths@networkno.de>
Looks technically ok but conflicts with these 7 other patches which also
touch arch/mips/mm/tlbex.c:
Please keep all the stuff the stuff that should go into the commit
message - and only that - above the "---" tearline. git-am will drop
anything below it and friendly greetings, signatures etc. should not go
into the log message so keep that below the tearoff line.
commit 699a78e99f302003ae6d6090bf7f35eb69b772e0
Author: Manuel Lauss <mano@roarinelk.homelinux.net>
Date: Thu Dec 6 09:07:55 2007 +0100
[MIPS] Alchemy: Au1210/Au1250 CPU support
This patch adds IDs for new Au1200 variants: Au1210 and Au1250.
They are essentially identical to the Au1200 except for the Au1210
which has a different SoC-ID in the PRId register [bits 31:24].
The Au1250 is a "Au1200 V0.2".
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 56bccd5921f7b1160ddab0f9c3e9cc227ecd9aef
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date: Thu Oct 18 09:11:17 2007 +0200
[MIPS] tlbex.c: cleanup debug code
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 97432dc56d464006a62b1cd3ee6484828bde816c
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date: Thu Oct 18 09:11:16 2007 +0200
[MIPS] tlbex.c: use __cacheline_aligned instead of __tlb_handler_align
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 82e27810cd28e4322bd400640c8627ceacfc29f5
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date: Thu Oct 18 09:11:15 2007 +0200
[MIPS] tlbex.c: cleanup include files
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit b849ac81b87278c9b9e17aef8f4d82a30578ec93
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date: Thu Oct 18 09:11:14 2007 +0200
[MIPS] tlbex.c: Cleanup __init usages.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit bf672b2f700d031d933c7dadcd9fae5edaa019b4
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date: Tue Oct 23 12:43:25 2007 +0100
[MIPS] R4000/R4400 daddiu erratum workaround
This complements the generic R4000/R4400 errata workaround code and adds
bits for the daddiu problem. In most places it just modifies handwritten
assembly code so that the assembler is allowed to use a temporary register
as daddiu may now be treated as a macro that expands to a sequence of li
and daddu. It is the AT register or, where AT is unavailable or used
explicitly for another purpose, an explicitly-named register is selected,
using the .set at=<reg> feature added recently to gas. This feature is
only used if CONFIG_CPU_DADDI_WORKAROUNDS has been set, so if the
workaround remains disabled, the required version of binutils stays
unchanged.
Similarly, daddiu instructions put in branch delay slots in noreorder
fragments are now taken out of them and the assembler is allowed to
reorder them itself as possible (which it does making the whole idea of
scheduling them into delay slots manually questionable).
Also in the very few places where such a simple conversion was not
possible, a handcoded longer sequence is implemented.
Other than that there are changes to code responsible for building the
TLB fault and page clear/copy handlers to avoid daddiu as appropriate.
These are only effective if the erratum is verified to be present at the
run time.
Finally there is a trivial update to __delay(), because it uses daddiu in
a branch delay slot.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
commit 2d220349159729f143570673f8752aafd6d8da74
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Mon Jan 28 17:14:10 2008 +0000
[MIPS] tlbex: Cleanup handling of R2 hazards in TLB handlers.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
But I'm really happing to see the generalization we've been talking about
to finally proceed.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* [PATCH 0/6] builtin-remote
@ 2007-12-05 19:00 Johannes Schindelin
2007-12-05 19:00 ` (unknown) Johannes Schindelin
0 siblings, 1 reply; 669+ messages in thread
From: Johannes Schindelin @ 2007-12-05 19:00 UTC (permalink / raw)
To: git, gitster
Hi,
this series introduces remote as a builtin, and fixes a long-standing bug
(if you created a remote with --mirror, prune would not do the right
thing).
I know it is pretty late in the game for 1.5.4, but then, I do not expect
this to go into that version...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
2007-12-05 19:00 [PATCH 0/6] builtin-remote Johannes Schindelin
@ 2007-12-05 19:00 ` Johannes Schindelin
2007-12-05 19:01 ` your mail Johannes Schindelin
0 siblings, 1 reply; 669+ messages in thread
From: Johannes Schindelin @ 2007-12-05 19:00 UTC (permalink / raw)
To: git, gitster
[PATCH 1/6] path-list: add functions to work with unsorted lists
Up to now, path-lists were sorted at all times. But sometimes it
is much more convenient to build the list and sort it at the end,
or sort it not at all.
Add path_list_append() and sort_path_list() to allow that.
Also, add the unsorted_path_list_has_path() function, to do a linear
search.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I should have done this much earlier...
path-list.c | 30 ++++++++++++++++++++++++++++++
path-list.h | 8 +++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/path-list.c b/path-list.c
index 3d83b7b..92e5cf2 100644
--- a/path-list.c
+++ b/path-list.c
@@ -102,3 +102,33 @@ void print_path_list(const char *text, const struct path_list *p)
for (i = 0; i < p->nr; i++)
printf("%s:%p\n", p->items[i].path, p->items[i].util);
}
+
+struct path_list_item *path_list_append(const char *path, struct path_list *list)
+{
+ ALLOC_GROW(list->items, list->nr + 1, list->alloc);
+ list->items[list->nr].path =
+ list->strdup_paths ? xstrdup(path) : (char *)path;
+ return list->items + list->nr++;
+}
+
+static int cmp_items(const void *a, const void *b)
+{
+ const struct path_list_item *one = a;
+ const struct path_list_item *two = b;
+ return strcmp(one->path, two->path);
+}
+
+void sort_path_list(struct path_list *list)
+{
+ qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
+}
+
+int unsorted_path_list_has_path(struct path_list *list, const char *path)
+{
+ int i;
+ for (i = 0; i < list->nr; i++)
+ if (!strcmp(path, list->items[i].path))
+ return 1;
+ return 0;
+}
+
diff --git a/path-list.h b/path-list.h
index 5931e2c..ca2cbba 100644
--- a/path-list.h
+++ b/path-list.h
@@ -13,10 +13,16 @@ struct path_list
};
void print_path_list(const char *text, const struct path_list *p);
+void path_list_clear(struct path_list *list, int free_util);
+/* Use these functions only on sorted lists: */
int path_list_has_path(const struct path_list *list, const char *path);
-void path_list_clear(struct path_list *list, int free_util);
struct path_list_item *path_list_insert(const char *path, struct path_list *list);
struct path_list_item *path_list_lookup(const char *path, struct path_list *list);
+/* Use these functions only on unsorted lists: */
+struct path_list_item *path_list_append(const char *path, struct path_list *list);
+void sort_path_list(struct path_list *list);
+int unsorted_path_list_has_path(struct path_list *list, const char *path);
+
#endif /* PATH_LIST_H */
--
1.5.3.7.2157.g9598e
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
@ 2007-10-17 18:28 nicholas.thompson1
0 siblings, 0 replies; 669+ messages in thread
From: nicholas.thompson1 @ 2007-10-17 18:28 UTC (permalink / raw)
To: linux-kernel
>Nope, wrong clues.
>The right clues are in the footer of this message after it travels thru the list.
>
>I supplied them to Nicholas already, but apparently others need to be reminded of
>them every now and then :-] That footer is in these list messages for a reason!
>
> /Matti Aarnio -- one of <postmaster@vger.kernel.org>
>
>PS: You want to contact VGER's email and list managers ?
> We use the internet email standard address "postmaster"
>
Jan, Matti, + List,
I am very sorry about the noise, that's what I get for using cut and paste while tired and before my third cup of coffee. ;p Apologies.
Nick
>>On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote:
>> Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
>> From: Jan Engelhardt <jengelh@computergmbh.de>
>> To: nicholas.thompson1@mchsi.com
>> cc: linux-kernel@vger.kernel.org
>> Subject: Re: your mail
>>
>> On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
>> >Date: Wed, 17 Oct 2007 16:30:24 +0000
>> >From: <nicholas.thompson1@mchsi.com>
>> >To: <linux-kernel@vger.kernel.org>
>> ^^^^^^
> >>
> >>subscribe linux-alpha
>> ^^^^^
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2007-10-17 16:30 nicholas.thompson1
2007-10-17 16:36 ` your mail Jan Engelhardt
0 siblings, 1 reply; 669+ messages in thread
From: nicholas.thompson1 @ 2007-10-17 16:30 UTC (permalink / raw)
To: linux-kernel
subscribe linux-alpha
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-10-17 16:30 nicholas.thompson1
@ 2007-10-17 16:36 ` Jan Engelhardt
2007-10-17 17:50 ` Matti Aarnio
0 siblings, 1 reply; 669+ messages in thread
From: Jan Engelhardt @ 2007-10-17 16:36 UTC (permalink / raw)
To: nicholas.thompson1; +Cc: linux-kernel
On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
>Date: Wed, 17 Oct 2007 16:30:24 +0000
>From: <nicholas.thompson1@mchsi.com>
>To: <linux-kernel@vger.kernel.org>
^^^^^^
>
>subscribe linux-alpha
^^^^^
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2007-10-17 16:36 ` your mail Jan Engelhardt
@ 2007-10-17 17:50 ` Matti Aarnio
0 siblings, 0 replies; 669+ messages in thread
From: Matti Aarnio @ 2007-10-17 17:50 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel
Nope, wrong clues.
The right clues are in the footer of this message after it travels thru the list.
I supplied them to Nicholas already, but apparently others need to be reminded of
them every now and then :-] That footer is in these list messages for a reason!
/Matti Aarnio -- one of <postmaster@vger.kernel.org>
PS: You want to contact VGER's email and list managers ?
We use the internet email standard address "postmaster"
On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote:
> Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
> From: Jan Engelhardt <jengelh@computergmbh.de>
> To: nicholas.thompson1@mchsi.com
> cc: linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
> >Date: Wed, 17 Oct 2007 16:30:24 +0000
> >From: <nicholas.thompson1@mchsi.com>
> >To: <linux-kernel@vger.kernel.org>
> ^^^^^^
> >
> >subscribe linux-alpha
> ^^^^^
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2007-10-13 4:01 Michael Witten
2007-10-13 4:07 ` your mail Jeff King
0 siblings, 1 reply; 669+ messages in thread
From: Michael Witten @ 2007-10-13 4:01 UTC (permalink / raw)
To: git; +Cc: Jeff King
I apologize if this is received twice.
I did add some comments, though!
On 12 Oct 2007, at 10:49:10 PM, Jeff King wrote:
> You are presumably doing a 'git-pull' on the cvsimport-ed commits. Try
> doing a git-rebase, which will filter out commits which make the same
> changes. Yes, it means throwing away your original commits, but the
> new
> ones should be morally equivalent (and are now the "official" upstream
> of the CVS repository).
Now that you mention it, I think the best approach would be to:
(1) cvsexportcommit
(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
(3) git cvsimport ..... # and merge
I think this is what you mean; it seems to me that rebasing isn't
quite that.
However, this will not preserve more complicated history such as merges
from another git repository.
Basically, I want to treat my git repository as the official
repository; the CVS
repo is just their for the old farts to get the latest stuff ;-P
Thanks!
Michael
PS
Please send me other opinions.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-10-13 4:01 (unknown), Michael Witten
@ 2007-10-13 4:07 ` Jeff King
0 siblings, 0 replies; 669+ messages in thread
From: Jeff King @ 2007-10-13 4:07 UTC (permalink / raw)
To: Michael Witten; +Cc: git
On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:
> Now that you mention it, I think the best approach would be to:
>
> (1) cvsexportcommit
> (2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> (3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite
> that.
No, I mean rebasing instead of merge. As in, you have a history like
this:
/--C---D <-- your master
A--B
\--C'--D' <-- cvsimport merge tip
where "C" and "D" are your commits in git, and C' and D' are pulled in
from cvsimport. You want to rebase your work like this:
A--B--C'--D'--C--D
except that git-rebase is smart enough to realize that C == C' and skip
it (so it's a "safe" way of moving forward).
> However, this will not preserve more complicated history such as merges
> from another git repository.
Correct. Rebasing doesn't really handle merges, but I assumed you were
just making simple commits on top of a cvs master.
> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P
Then my suggestion doesn't really work. You might consider using git as
the official server and letting the old farts use git-cvsserver.
HTH,
-Peff
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2007-10-09 9:56 Frédéric Mantegazza
2007-10-09 10:46 ` your mail Justin Piszcz
0 siblings, 1 reply; 669+ messages in thread
From: Frédéric Mantegazza @ 2007-10-09 9:56 UTC (permalink / raw)
To: linux-raid
subscribe linux-raid
--
Frédéric
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2007-09-27 18:03 Gangadhar Kodishala
2007-09-27 20:06 ` your mail Ricard Wanderlof
0 siblings, 1 reply; 669+ messages in thread
From: Gangadhar Kodishala @ 2007-09-27 18:03 UTC (permalink / raw)
To: linux-mtd
Hi All,
I have a NAND flash of 64 MB on my board with separate partitions for root
file system and data.
My board boots up with the root file system (jffs2) on NAND flash. This root
file system partition is made smaller enough to hold all the root file
system data.
I created another partition on NAND to use specifically for the data. I
would like to create a JFFS2 file system on this data partition, mount it
and use it to store my application code and data files,
I do not know exactly how to create the JFFS2 file system on data partition.
Could you please explain me how to do this ?
Thank you.
Best Regards,
Gangadhar
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.13.30/1030 - Release Date: 9/25/2007
8:02 AM
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
Contact your Administrator for further information.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-09-27 18:03 Gangadhar Kodishala
@ 2007-09-27 20:06 ` Ricard Wanderlof
0 siblings, 0 replies; 669+ messages in thread
From: Ricard Wanderlof @ 2007-09-27 20:06 UTC (permalink / raw)
To: Linux mtd
On Thu, 27 Sep 2007, Gangadhar Kodishala wrote:
> I created another partition on NAND to use specifically for the data. I
> would like to create a JFFS2 file system on this data partition, mount it
> and use it to store my application code and data files,
If you just want to create an empty JFFS2 file system, then just erase the
partition, and mount it.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2007-09-24 20:44 Steven Rostedt
2007-09-24 20:50 ` your mail Steven Rostedt
0 siblings, 1 reply; 669+ messages in thread
From: Steven Rostedt @ 2007-09-24 20:44 UTC (permalink / raw)
To: Jaswinder Singh; +Cc: linux-kernel, mingo, linux-rt-users
linux-rt-users@vger.kernel.org
Bcc:
Subject: Re: realtime preemption performance difference
Reply-To:
In-Reply-To: <3f9a31f40709240448h4a9e8337t437328b5c675ecd5@mail.gmail.com>
On Mon, Sep 24, 2007 at 05:18:01PM +0530, Jaswinder Singh wrote:
> Hi all,
>
> I want to check performance difference by using realtime preemption patch :
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Please let me know from where I can download samples to test realtime
> preemption performance difference.
>
> Can someone please share performance numbers for your hardware:-
>
> 1. Interrupt latency
> 2. Task switching time
> 3. hard-realtime scheduling latency
>
see http://rt.wiki.kernel.org/index.php/Main_Page
There's also an RT mailing list for users (CC'd).
-- Steve
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
@ 2007-08-15 13:53 Stefan Richter
2007-08-15 14:35 ` Satyam Sharma
0 siblings, 1 reply; 669+ messages in thread
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
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 [flat|nested] 669+ messages in thread* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 13:53 [PATCH 0/24] make atomic_read() behave consistently across all architectures Stefan Richter
@ 2007-08-15 14:35 ` Satyam Sharma
2007-08-15 14:52 ` Herbert Xu
0 siblings, 1 reply; 669+ messages in thread
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
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 [flat|nested] 669+ messages in thread* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 14:35 ` Satyam Sharma
@ 2007-08-15 14:52 ` Herbert Xu
2007-08-15 16:09 ` Stefan Richter
0 siblings, 1 reply; 669+ messages in thread
From: Herbert Xu @ 2007-08-15 14:52 UTC (permalink / raw)
To: Satyam Sharma
Cc: Stefan Richter, Heiko Carstens, 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
On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
>
> > 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 :-)
Nope, we're calling schedule which is a rather heavy-weight
barrier.
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 [flat|nested] 669+ messages in thread* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 14:52 ` Herbert Xu
@ 2007-08-15 16:09 ` Stefan Richter
2007-08-15 16:27 ` Paul E. McKenney
0 siblings, 1 reply; 669+ messages in thread
From: Stefan Richter @ 2007-08-15 16:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Satyam Sharma, Heiko Carstens, 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
Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
>>> I don't know if this here is affected:
[...something like]
b = atomic_read(a);
for (i = 0; i < 4; i++) {
msleep_interruptible(63);
c = atomic_read(a);
if (c != b) {
b = c;
i = 0;
}
}
> Nope, we're calling schedule which is a rather heavy-weight
> barrier.
How does the compiler know that msleep() has got barrier()s?
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 16:09 ` Stefan Richter
@ 2007-08-15 16:27 ` Paul E. McKenney
2007-08-15 18:31 ` Segher Boessenkool
0 siblings, 1 reply; 669+ messages in thread
From: Paul E. McKenney @ 2007-08-15 16:27 UTC (permalink / raw)
To: Stefan Richter
Cc: Herbert Xu, Satyam Sharma, Heiko Carstens, 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
On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
> Herbert Xu wrote:
> > On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
> >>> I don't know if this here is affected:
>
> [...something like]
> b = atomic_read(a);
> for (i = 0; i < 4; i++) {
> msleep_interruptible(63);
> c = atomic_read(a);
> if (c != b) {
> b = c;
> i = 0;
> }
> }
>
> > Nope, we're calling schedule which is a rather heavy-weight
> > barrier.
>
> How does the compiler know that msleep() has got barrier()s?
Because msleep_interruptible() is in a separate compilation unit,
the compiler has to assume that it might modify any arbitrary global.
In many cases, the compiler also has to assume that msleep_interruptible()
might call back into a function in the current compilation unit, thus
possibly modifying global static variables.
Thanx, Paul
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 16:27 ` Paul E. McKenney
@ 2007-08-15 18:31 ` Segher Boessenkool
2007-08-15 18:57 ` Paul E. McKenney
0 siblings, 1 reply; 669+ messages in thread
From: Segher Boessenkool @ 2007-08-15 18:31 UTC (permalink / raw)
To: paulmck
Cc: horms, Stefan Richter, Satyam Sharma, Linux Kernel Mailing List,
rpjday, netdev, ak, cfriesen, Heiko Carstens, jesper.juhl,
linux-arch, Andrew Morton, zlynx, clameter, schwidefsky,
Chris Snook, Herbert Xu, davem, Linus Torvalds, wensong, wjiang
>> How does the compiler know that msleep() has got barrier()s?
>
> Because msleep_interruptible() is in a separate compilation unit,
> the compiler has to assume that it might modify any arbitrary global.
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit boundaries just fine, if you tell it to
compile more than one compilation unit at once.
What you probably mean is that the compiler has to assume any code
it cannot currently see can do anything (insofar as allowed by the
relevant standards etc.)
> In many cases, the compiler also has to assume that
> msleep_interruptible()
> might call back into a function in the current compilation unit, thus
> possibly modifying global static variables.
It most often is smart enough to see what compilation-unit-local
variables might be modified that way, though :-)
Segher
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 18:31 ` Segher Boessenkool
@ 2007-08-15 18:57 ` Paul E. McKenney
2007-08-15 19:54 ` Satyam Sharma
0 siblings, 1 reply; 669+ messages in thread
From: Paul E. McKenney @ 2007-08-15 18:57 UTC (permalink / raw)
To: Segher Boessenkool
Cc: horms, Stefan Richter, Satyam Sharma, Linux Kernel Mailing List,
rpjday, netdev, ak, cfriesen, Heiko Carstens, jesper.juhl,
linux-arch, Andrew Morton, zlynx, clameter, schwidefsky,
Chris Snook, Herbert Xu, davem, Linus Torvalds, wensong, wjiang
On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> >>How does the compiler know that msleep() has got barrier()s?
> >
> >Because msleep_interruptible() is in a separate compilation unit,
> >the compiler has to assume that it might modify any arbitrary global.
>
> No; compilation units have nothing to do with it, GCC can optimise
> across compilation unit boundaries just fine, if you tell it to
> compile more than one compilation unit at once.
Last I checked, the Linux kernel build system did compile each .c file
as a separate compilation unit.
> What you probably mean is that the compiler has to assume any code
> it cannot currently see can do anything (insofar as allowed by the
> relevant standards etc.)
Indeed.
> >In many cases, the compiler also has to assume that
> >msleep_interruptible()
> >might call back into a function in the current compilation unit, thus
> >possibly modifying global static variables.
>
> It most often is smart enough to see what compilation-unit-local
> variables might be modified that way, though :-)
Yep. For example, if it knows the current value of a given such local
variable, and if all code paths that would change some other variable
cannot be reached given that current value of the first variable.
At least given that gcc doesn't know about multiple threads of execution!
Thanx, Paul
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 18:57 ` Paul E. McKenney
@ 2007-08-15 19:54 ` Satyam Sharma
2007-08-15 20:47 ` Segher Boessenkool
0 siblings, 1 reply; 669+ messages in thread
From: Satyam Sharma @ 2007-08-15 19:54 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Segher Boessenkool, horms, Stefan Richter,
Linux Kernel Mailing List, rpjday, netdev, ak, cfriesen,
Heiko Carstens, jesper.juhl, linux-arch, Andrew Morton, zlynx,
clameter, schwidefsky, Chris Snook, Herbert Xu, davem,
Linus Torvalds, wensong, wjiang
[ The Cc: list scares me. Should probably trim it. ]
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > >>How does the compiler know that msleep() has got barrier()s?
> > >
> > >Because msleep_interruptible() is in a separate compilation unit,
> > >the compiler has to assume that it might modify any arbitrary global.
> >
> > No; compilation units have nothing to do with it, GCC can optimise
> > across compilation unit boundaries just fine, if you tell it to
> > compile more than one compilation unit at once.
>
> Last I checked, the Linux kernel build system did compile each .c file
> as a separate compilation unit.
>
> > What you probably mean is that the compiler has to assume any code
> > it cannot currently see can do anything (insofar as allowed by the
> > relevant standards etc.)
I think this was just terminology confusion here again. Isn't "any code
that it cannot currently see" the same as "another compilation unit",
and wouldn't the "compilation unit" itself expand if we ask gcc to
compile more than one unit at once? Or is there some more specific
"definition" for "compilation unit" (in gcc lingo, possibly?)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 19:54 ` Satyam Sharma
@ 2007-08-15 20:47 ` Segher Boessenkool
2007-08-16 0:36 ` Satyam Sharma
0 siblings, 1 reply; 669+ messages in thread
From: Segher Boessenkool @ 2007-08-15 20:47 UTC (permalink / raw)
To: Satyam Sharma
Cc: horms, Stefan Richter, Linux Kernel Mailing List,
Paul E. McKenney, ak, netdev, cfriesen, Heiko Carstens, rpjday,
jesper.juhl, linux-arch, Andrew Morton, zlynx, clameter,
schwidefsky, Chris Snook, Herbert Xu, davem, Linus Torvalds,
wensong, wjiang
>>> What you probably mean is that the compiler has to assume any code
>>> it cannot currently see can do anything (insofar as allowed by the
>>> relevant standards etc.)
>
> I think this was just terminology confusion here again. Isn't "any code
> that it cannot currently see" the same as "another compilation unit",
It is not; try gcc -combine or the upcoming link-time optimisation
stuff, for example.
> and wouldn't the "compilation unit" itself expand if we ask gcc to
> compile more than one unit at once? Or is there some more specific
> "definition" for "compilation unit" (in gcc lingo, possibly?)
"compilation unit" is a C standard term. It typically boils down
to "single .c file".
Segher
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
2007-08-15 20:47 ` Segher Boessenkool
@ 2007-08-16 0:36 ` Satyam Sharma
2007-08-16 0:32 ` your mail Herbert Xu
0 siblings, 1 reply; 669+ messages in thread
From: Satyam Sharma @ 2007-08-16 0:36 UTC (permalink / raw)
To: Segher Boessenkool
Cc: horms, Stefan Richter, Linux Kernel Mailing List,
Paul E. McKenney, ak, netdev, cfriesen, Heiko Carstens, rpjday,
jesper.juhl, linux-arch, Andrew Morton, zlynx, clameter,
schwidefsky, Chris Snook, Herbert Xu, davem, Linus Torvalds,
wensong, wjiang
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again. Isn't "any code
> > that it cannot currently see" the same as "another compilation unit",
>
> It is not; try gcc -combine or the upcoming link-time optimisation
> stuff, for example.
>
> > and wouldn't the "compilation unit" itself expand if we ask gcc to
> > compile more than one unit at once? Or is there some more specific
> > "definition" for "compilation unit" (in gcc lingo, possibly?)
>
> "compilation unit" is a C standard term. It typically boils down
> to "single .c file".
As you mentioned later, "single .c file with all the other files (headers
or other .c files) that it pulls in via #include" is actually "translation
unit", both in the C standard as well as gcc docs. "Compilation unit"
doesn't seem to be nearly as standard a term, though in most places it
is indeed meant to be same as "translation unit", but with the new gcc
inter-module-analysis stuff that you referred to above, I suspect one may
reasonably want to call a "compilation unit" as all that the compiler sees
at a given instant.
BTW I did some auditing (only inside include/asm-{i386,x86_64}/ and
arch/{i386,x86_64}/) and found a couple more callsites that don't use
cpu_relax():
arch/i386/kernel/crash.c:101
arch/x86_64/kernel/crash.c:97
that are:
while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
mdelay(1);
msecs--;
}
where mdelay() becomes __const_udelay() which happens to be in another
translation unit (arch/i386/lib/delay.c) and hence saves this callsite
from being a bug :-)
Curiously, __const_udelay() is still marked as "inline" where it is
implemented in lib/delay.c which is weird, considering it won't ever
be inlined, would it? With the kernel presently being compiled one
translation unit at a time, I don't see how the implementation would
be visible to any callsite out there to be able to inline it.
Satyam
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2007-08-16 0:36 ` Satyam Sharma
@ 2007-08-16 0:32 ` Herbert Xu
0 siblings, 0 replies; 669+ messages in thread
From: Herbert Xu @ 2007-08-16 0:32 UTC (permalink / raw)
To: Satyam Sharma
Cc: Segher Boessenkool, horms, Stefan Richter,
Linux Kernel Mailing List, Paul E. McKenney, ak, netdev,
cfriesen, Heiko Carstens, rpjday, jesper.juhl, linux-arch,
Andrew Morton, zlynx, clameter, schwidefsky, Chris Snook, davem,
Linus Torvalds, wensong, wjiang
On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wrote:
>
> that are:
>
> while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
> mdelay(1);
> msecs--;
> }
>
> where mdelay() becomes __const_udelay() which happens to be in another
> translation unit (arch/i386/lib/delay.c) and hence saves this callsite
> from being a bug :-)
The udelay itself certainly should have some form of cpu_relax in it.
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 [flat|nested] 669+ messages in thread
* (no subject)
@ 2007-05-16 13:30 Bob Picco
2007-05-16 16:43 ` Linas Vepstas
0 siblings, 1 reply; 669+ messages in thread
From: Bob Picco @ 2007-05-16 13:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev
bob.picco@hp.com
Bcc:
Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
Reply-To:
In-Reply-To: <20070515201914.16944e04.akpm@linux-foundation.org>
/usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
/usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[3]: *** [drivers/pci/hotplug] Error 2
make[2]: *** [drivers/pci] Error 2
make[1]: *** [drivers] Error 2
make: *** [_all] Error 2
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc1-mm1
# Wed May 16 06:51:38 2007
#
CONFIG_PPC64=y
CONFIG_64BIT=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_PPC_UDBG_16550=y
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
#
# Processor support
#
# CONFIG_POWER4_ONLY is not set
CONFIG_POWER3=y
CONFIG_POWER4=y
CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
# CONFIG_ALTIVEC is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=32
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_SMAPS=y
CONFIG_PROC_CLEAR_REFS=y
CONFIG_PROC_PAGEMAP=y
CONFIG_PROC_KPAGEMAP=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
CONFIG_PPC_PSERIES=y
# CONFIG_PPC_SPLPAR is not set
CONFIG_EEH=y
CONFIG_SCANLOG=y
CONFIG_LPARCFG=y
# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
CONFIG_PPC_PASEMI=y
#
# PA Semi PWRficient options
#
# CONFIG_PPC_PASEMI_IOMMU is not set
CONFIG_PPC_PASEMI_MDIO=y
# CONFIG_PPC_CELLEB is not set
# CONFIG_PPC_PS3 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PPC_IBM_CELL_BLADE is not set
# CONFIG_PQ2ADS is not set
CONFIG_PPC_NATIVE=y
# CONFIG_UDBG_RTAS_CONSOLE is not set
CONFIG_XICS=y
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
CONFIG_PPC_I8259=y
# CONFIG_U3_DART is not set
CONFIG_PPC_RTAS=y
CONFIG_RTAS_ERROR_LOGGING=y
CONFIG_RTAS_PROC=y
CONFIG_RTAS_FLASH=y
# CONFIG_MMIO_NVRAM is not set
CONFIG_IBMVIO=y
CONFIG_IBMEBUS=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
#
# Kernel options
#
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_FORCE_MAX_ZONEORDER=13
# CONFIG_IOMMU_VMERGE is not set
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_IRQ_ALL_CPUS is not set
CONFIG_NUMA=y
CONFIG_NODES_SHIFT=4
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_EXTREME=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_PPC_HAS_HASH_64K is not set
# CONFIG_PPC_64K_PAGES is not set
CONFIG_SCHED_SMT=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
CONFIG_SECCOMP=y
# CONFIG_WANT_DEVICE_TREE is not set
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_HOTPLUG_PCI_RPA=y
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
CONFIG_KERNEL_START=0xc000000000000000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NF_CONNTRACK_ENABLED is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_QUEUE=y
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_STRANGE_DEV=y
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_BLINK is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SL82C105=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_IPS=y
CONFIG_SCSI_IBMVSCSI=y
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=y
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
CONFIG_SCSI_LPFC=y
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_ESP_CORE is not set
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_IEEE1394_SUPPORT=y
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
# CONFIG_WINDFARM is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_BONDING=y
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_FIXED_PHY is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBMVETH=y
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_PCNET32_NAPI is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
CONFIG_EHEA=y
CONFIG_IXGB=y
# CONFIG_IXGB_NAPI is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_PASEMI_MAC is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_RTL818X is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_ICOM is not set
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_HVC_DRIVER=y
CONFIG_HVC_CONSOLE=y
# CONFIG_HVC_RTAS is not set
# CONFIG_HVCS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_PASEMI=y
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PASEMI is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
CONFIG_DAB=y
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=y
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
CONFIG_FB_MACMODES=y
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_OF=y
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set
#
# HID Devices
#
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PPC_OF=y
CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
# CONFIG_USB_OHCI_HCD_PPC_OF_LE is not set
CONFIG_USB_OHCI_HCD_PCI=y
CONFIG_USB_OHCI_BIG_ENDIAN_DESC=y
CONFIG_USB_OHCI_BIG_ENDIAN_MMIO=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=y
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
CONFIG_INFINIBAND=y
# CONFIG_INFINIBAND_USER_MAD is not set
# CONFIG_INFINIBAND_USER_ACCESS is not set
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=y
CONFIG_INFINIBAND_MTHCA_DEBUG=y
# CONFIG_INFINIBAND_IPATH is not set
# CONFIG_INFINIBAND_EHCA is not set
# CONFIG_INFINIBAND_AMSO1100 is not set
# CONFIG_MLX4_INFINIBAND is not set
CONFIG_INFINIBAND_IPOIB=y
# CONFIG_INFINIBAND_IPOIB_CM is not set
CONFIG_INFINIBAND_IPOIB_DEBUG=y
# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
# CONFIG_INFINIBAND_SRP is not set
# CONFIG_INFINIBAND_ISER is not set
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
#
# DMA Devices
#
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4DEV_FS=y
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
# CONFIG_REISERFS_FS_SECURITY is not set
CONFIG_JFS_FS=y
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
# Layered filesystems
#
# CONFIG_UNION_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_BIND34 is not set
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
# CONFIG_UCC_SLOW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
# CONFIG_LZO is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_UNWIND_INFO is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HCALL_STATS=y
# CONFIG_DEBUGGER is not set
# CONFIG_IRQSTACKS is not set
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_INTEGRITY is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_HW=y
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-05-16 13:30 Bob Picco
@ 2007-05-16 16:43 ` Linas Vepstas
0 siblings, 0 replies; 669+ messages in thread
From: Linas Vepstas @ 2007-05-16 16:43 UTC (permalink / raw)
To: Bob Picco, johnrose; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
>
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> make[3]: *** [drivers/pci/hotplug] Error 2
> make[2]: *** [drivers/pci] Error 2
> make[1]: *** [drivers] Error 2
> make: *** [_all] Error 2
John Rose is working to fix this "real soon now".
--linas
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2007-05-16 16:43 ` Linas Vepstas
0 siblings, 0 replies; 669+ messages in thread
From: Linas Vepstas @ 2007-05-16 16:43 UTC (permalink / raw)
To: Bob Picco, johnrose; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
>
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> make[3]: *** [drivers/pci/hotplug] Error 2
> make[2]: *** [drivers/pci] Error 2
> make[1]: *** [drivers] Error 2
> make: *** [_all] Error 2
John Rose is working to fix this "real soon now".
--linas
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-05-16 16:43 ` Linas Vepstas
@ 2007-05-16 17:11 ` Olof Johansson
-1 siblings, 0 replies; 669+ messages in thread
From: Olof Johansson @ 2007-05-16 17:11 UTC (permalink / raw)
To: Linas Vepstas
Cc: Bob Picco, johnrose, linuxppc-dev, Andrew Morton, linux-kernel
On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> >
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > make[3]: *** [drivers/pci/hotplug] Error 2
> > make[2]: *** [drivers/pci] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [_all] Error 2
>
> John Rose is working to fix this "real soon now".
Do you mean the fix Al Viro posted yesterday?
http://patchwork.ozlabs.org/linuxppc/patch?id=11177
-Olof
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2007-05-16 17:11 ` Olof Johansson
0 siblings, 0 replies; 669+ messages in thread
From: Olof Johansson @ 2007-05-16 17:11 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, Andrew Morton, johnrose, linux-kernel, Bob Picco
On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> >
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > make[3]: *** [drivers/pci/hotplug] Error 2
> > make[2]: *** [drivers/pci] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [_all] Error 2
>
> John Rose is working to fix this "real soon now".
Do you mean the fix Al Viro posted yesterday?
http://patchwork.ozlabs.org/linuxppc/patch?id=11177
-Olof
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-05-16 17:11 ` Olof Johansson
@ 2007-05-16 17:24 ` Bob Picco
-1 siblings, 0 replies; 669+ messages in thread
From: Bob Picco @ 2007-05-16 17:24 UTC (permalink / raw)
To: Olof Johansson
Cc: Linas Vepstas, Bob Picco, johnrose, linuxppc-dev, Andrew Morton,
linux-kernel
Olof Johansson wrote: [Wed May 16 2007, 01:11:00PM EDT]
> On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> > On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > >
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > > make[3]: *** [drivers/pci/hotplug] Error 2
> > > make[2]: *** [drivers/pci] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [_all] Error 2
> >
> > John Rose is working to fix this "real soon now".
>
> Do you mean the fix Al Viro posted yesterday?
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=11177
>
>
> -Olof
Missed that patch.
thanks,
bob
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2007-05-16 17:24 ` Bob Picco
0 siblings, 0 replies; 669+ messages in thread
From: Bob Picco @ 2007-05-16 17:24 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-kernel, Bob Picco, linuxppc-dev, Andrew Morton, johnrose
Olof Johansson wrote: [Wed May 16 2007, 01:11:00PM EDT]
> On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> > On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > >
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > > make[3]: *** [drivers/pci/hotplug] Error 2
> > > make[2]: *** [drivers/pci] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [_all] Error 2
> >
> > John Rose is working to fix this "real soon now".
>
> Do you mean the fix Al Viro posted yesterday?
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=11177
>
>
> -Olof
Missed that patch.
thanks,
bob
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2007-03-29 21:39 Gerard Braad Jr.
2007-03-29 21:42 ` your mail Jan Engelhardt
0 siblings, 1 reply; 669+ messages in thread
From: Gerard Braad Jr. @ 2007-03-29 21:39 UTC (permalink / raw)
To: linux-kernel
unsubscribe linux-kernel gbraad@member.fsf.org
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2007-02-05 15:41 logic
2007-02-05 12:36 ` Joerg Roedel
0 siblings, 1 reply; 669+ messages in thread
From: logic @ 2007-02-05 15:41 UTC (permalink / raw)
To: linux-kernel
Good morning,
I am experiencing a bug i think. I am running a 2.6.19.2 kernel on a 3Ghz
Intel with HT activated, 1 gb ram, and noname motherboard. Here is the
output of the hang:
------------[ cut here ]------------
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: kernel BUG at mm/slab.c:607!
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: invalid opcode: 0000 [#1]
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: CPU: 1
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: EIP: 0060:[<c0155ebb>] Not tainted VLI
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: eax: 1af3a451 ebx: c89ba000 ecx: 4a5ffc80 edx: c214bfe0
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: ds: 007b es: 007b ss: 0068
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: EIP is at free_block+0x44/0xda
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: PREEMPT SMP
mail kernel: EFLAGS: 00010046 (2.6.19.2 #1)
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: Call Trace:
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: =======================
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: Process events/1 (pid: 9, ti=c19b6000 task=c1983a90
task.ti=c19b6000)
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: Stack: 00000000 0000001e c196d018 c196d018 0000001e c196d000
00000000 c015664d
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: 00000000 00000000 c196fc80 c19485c0 c196fc80 c19485c0
c194b140 00000213
--
--
Va salut,
Alexandru Gheorghita
Technical Manager
Think.Net
phone: 0788.700.842
mail: logic@thinknet.ro
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-02-05 15:41 logic
@ 2007-02-05 12:36 ` Joerg Roedel
0 siblings, 0 replies; 669+ messages in thread
From: Joerg Roedel @ 2007-02-05 12:36 UTC (permalink / raw)
To: logic; +Cc: linux-kernel
On Mon, Feb 05, 2007 at 05:41:29PM +0200, logic@thinknet.ro wrote:
> Good morning,
>
> I am experiencing a bug i think. I am running a 2.6.19.2 kernel on a 3Ghz
> Intel with HT activated, 1 gb ram, and noname motherboard. Here is the
> output of the hang:
Hmm, this seems to be the same issue as in [1] and [2]. A page that is
assumed to belong to the slab but is not longer marked as a slab page.
Could this be a bug in the memory management?
Joerg
[1] http://lkml.org/lkml/2007/2/4/77
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406477
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2007-02-05 12:36 ` Joerg Roedel
0 siblings, 0 replies; 669+ messages in thread
From: Joerg Roedel @ 2007-02-05 12:36 UTC (permalink / raw)
To: logic; +Cc: linux-kernel, linux-mm
On Mon, Feb 05, 2007 at 05:41:29PM +0200, logic@thinknet.ro wrote:
> Good morning,
>
> I am experiencing a bug i think. I am running a 2.6.19.2 kernel on a 3Ghz
> Intel with HT activated, 1 gb ram, and noname motherboard. Here is the
> output of the hang:
Hmm, this seems to be the same issue as in [1] and [2]. A page that is
assumed to belong to the slab but is not longer marked as a slab page.
Could this be a bug in the memory management?
Joerg
[1] http://lkml.org/lkml/2007/2/4/77
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406477
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2007-02-05 12:36 ` Joerg Roedel
(?)
@ 2007-02-05 14:01 ` Pekka Enberg
2007-02-06 9:41 ` Joerg Roedel
-1 siblings, 1 reply; 669+ messages in thread
From: Pekka Enberg @ 2007-02-05 14:01 UTC (permalink / raw)
To: Joerg Roedel; +Cc: logic, linux-kernel
Hi Joerg,
On 2/5/07, Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hmm, this seems to be the same issue as in [1] and [2]. A page that is
> assumed to belong to the slab but is not longer marked as a slab page.
> Could this be a bug in the memory management?
The BUG_ON triggers whenever you feed an invalid pointer to kfree() or
kmem_cache_free() so I am guessing the caller is simply broken. Note
that kernels prior to 2.6.18 would quietly corrupt the slab unless
CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been
noticed before.
Pekka
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2007-02-05 14:01 ` Pekka Enberg
@ 2007-02-06 9:41 ` Joerg Roedel
0 siblings, 0 replies; 669+ messages in thread
From: Joerg Roedel @ 2007-02-06 9:41 UTC (permalink / raw)
To: Pekka Enberg; +Cc: logic, linux-kernel
On Mon, Feb 05, 2007 at 04:01:23PM +0200, Pekka Enberg wrote:
> Hi Joerg,
>
> On 2/5/07, Joerg Roedel <joerg.roedel@amd.com> wrote:
> >Hmm, this seems to be the same issue as in [1] and [2]. A page that is
> >assumed to belong to the slab but is not longer marked as a slab page.
> >Could this be a bug in the memory management?
>
> The BUG_ON triggers whenever you feed an invalid pointer to kfree() or
> kmem_cache_free() so I am guessing the caller is simply broken. Note
> that kernels prior to 2.6.18 would quietly corrupt the slab unless
> CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been
> noticed before.
Ok. I was not aware of that. Thanks for clarification.
Joerg
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2006-11-21 22:24 Johannes Schindelin
2006-11-22 20:16 ` your mail Davide Libenzi
0 siblings, 1 reply; 669+ messages in thread
From: Johannes Schindelin @ 2006-11-21 22:24 UTC (permalink / raw)
To: Davide Libenzi, git
[PATCH] xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This code is only lightly tested, but I am tired and hungry.
My hopes are that when I wake up in the morning, all bugs are
fixed, git-merge-one-file is rewritten as a builtin,
git-merge-index defaults to calling xdl_merge() directly when
no program is passed with "-o", and git-merge-recursive also
avoids fork()ing RCS' merge.
A funny side effect is that you can merge with white space
corruption by setting the xpparam flags to ignore whitespace.
The file passed as mf1 wins over mf2 in that case.
Oh, and maybe I did not need to use xdl_change_compact() (and
thus could have left that static to xdiffi.c)? Davide, if you
could enlighten me, I will take the time next weekend to port this
to LibXDiff ;-)
BTW if anybody wonders why these diffstats do not look correct:
"git apply --stat" does not yet have our new scaling...
Makefile | 3
xdiff/xdiff.h | 7 +
xdiff/xdiffi.c | 3
xdiff/xdiffi.h | 1
xdiff/xmerge.c | 433 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 444 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 4c3f87f..b10d65e 100644
--- a/Makefile
+++ b/Makefile
@@ -769,7 +769,8 @@ $(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
-XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
+XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
+ xdiff/xmerge.o
$(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index c9f8178..fa409d5 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -49,6 +49,9 @@ extern "C" {
#define XDL_BDOP_CPY 2
#define XDL_BDOP_INSB 3
+#define XDL_MERGE_MINIMAL 0
+#define XDL_MERGE_EAGER 1
+#define XDL_MERGE_ZEALOUS 2
typedef struct s_mmfile {
char *ptr;
@@ -90,6 +93,10 @@ long xdl_mmfile_size(mmfile_t *mmf);
int xdl_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdemitconf_t const *xecfg, xdemitcb_t *ecb);
+int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
+ mmfile_t *mf2, const char *name2,
+ xpparam_t const *xpp, int level, mmbuffer_t *result);
+
#ifdef __cplusplus
}
#endif /* #ifdef __cplusplus */
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index d76e76a..9aeebc4 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -45,7 +45,6 @@ static long xdl_split(unsigned long cons
long *kvdf, long *kvdb, int need_min, xdpsplit_t *spl,
xdalgoenv_t *xenv);
static xdchange_t *xdl_add_change(xdchange_t *xscr, long i1, long i2, long chg1, long chg2);
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
@@ -397,7 +396,7 @@ static xdchange_t *xdl_add_change(xdchan
}
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
+int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
long ix, ixo, ixs, ixref, grpsiz, nrec = xdf->nrec;
char *rchg = xdf->rchg, *rchgo = xdfo->rchg;
xrecord_t **recs = xdf->recs;
diff --git a/xdiff/xdiffi.h b/xdiff/xdiffi.h
index d3b7271..472aeae 100644
--- a/xdiff/xdiffi.h
+++ b/xdiff/xdiffi.h
@@ -50,6 +50,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o
long *kvdf, long *kvdb, int need_min, xdalgoenv_t *xenv);
int xdl_do_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdfenv_t *xe);
+int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
int xdl_build_script(xdfenv_t *xe, xdchange_t **xscr);
void xdl_free_script(xdchange_t *xscr);
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
new file mode 100644
index 0000000..7b85aa5
--- /dev/null
+++ b/xdiff/xmerge.c
@@ -0,0 +1,433 @@
+/*
+ * LibXDiff by Davide Libenzi ( File Differential Library )
+ * Copyright (C) 2003-2006 Davide Libenzi, Johannes E. Schindelin
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Davide Libenzi <davidel@xmailserver.org>
+ *
+ */
+
+#include "xinclude.h"
+
+typedef struct s_xdmerge {
+ struct s_xdmerge *next;
+ /*
+ * 0 = conflict,
+ * 1 = no conflict, take first,
+ * 2 = no conflict, take second.
+ */
+ int mode;
+ long i1, i2;
+ long chg1, chg2;
+} xdmerge_t;
+
+static int xdl_append_merge(xdmerge_t **merge, int mode,
+ long i1, long chg1, long i2, long chg2)
+{
+ xdmerge_t *m = *merge;
+ if (m && mode == m->mode &&
+ (i1 == m->i1 + m->chg1 || i2 == m->i2 + m->chg2)) {
+ m->chg1 = i1 + chg1 - m->i1;
+ m->chg2 = i2 + chg2 - m->i2;
+ } else {
+ m = xdl_malloc(sizeof(xdmerge_t));
+ if (!m)
+ return -1;
+ m->next = NULL;
+ m->mode = mode;
+ m->i1 = i1;
+ m->chg1 = chg1;
+ m->i2 = i2;
+ m->chg2 = chg2;
+ if (*merge)
+ (*merge)->next = m;
+ *merge = m;
+ }
+ return 0;
+}
+
+static int xdl_cleanup_merge(xdmerge_t *c)
+{
+ int count = 0;
+ xdmerge_t *next_c;
+
+ /* were there conflicts? */
+ for (; c; c = next_c) {
+ if (c->mode == 0)
+ count++;
+ next_c = c->next;
+ free(c);
+ }
+ return count;
+}
+
+static int xdl_merge_cmp_lines(xdfenv_t *xe1, int i1, xdfenv_t *xe2, int i2,
+ int line_count, long flags)
+{
+ int i;
+ xrecord_t **rec1 = xe1->xdf2.recs + i1;
+ xrecord_t **rec2 = xe2->xdf2.recs + i2;
+
+ for (i = 0; i < line_count; i++) {
+ int result = xdl_recmatch(rec1[i]->ptr, rec1[i]->size,
+ rec2[i]->ptr, rec2[i]->size, flags);
+ if (!result)
+ return -1;
+ }
+ return 0;
+}
+
+static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int add_nl, char *dest)
+{
+ xrecord_t **recs = xe->xdf2.recs + i;
+ int size = 0;
+
+ if (count < 1)
+ return 0;
+
+ for (i = 0; i < count; size += recs[i++]->size)
+ if (dest)
+ memcpy(dest + size, recs[i]->ptr, recs[i]->size);
+ if (add_nl) {
+ i = recs[count - 1]->size;
+ if (i == 0 || recs[count - 1]->ptr[i - 1] != '\n') {
+ if (dest)
+ dest[size] = '\n';
+ size++;
+ }
+ }
+ return size;
+}
+
+static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
+ xdfenv_t *xe2, const char *name2, xdmerge_t *m, char *dest)
+{
+ const int marker_size = 7;
+ int marker1_size = (name1 ? strlen(name1) + 1 : 0);
+ int marker2_size = (name2 ? strlen(name2) + 1 : 0);
+ int conflict_marker_size = 3 * (marker_size + 1)
+ + marker1_size + marker2_size;
+ int size, i1, j;
+
+ for (size = i1 = 0; m; m = m->next) {
+ if (m->mode == 0) {
+ size += xdl_recs_copy(xe1, i1, m->i1 - i1, 0,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '<';
+ if (marker1_size) {
+ dest[size] = ' ';
+ memcpy(dest + size + 1, name1,
+ marker1_size - 1);
+ size += marker1_size;
+ }
+ dest[size++] = '\n';
+ } else
+ size += conflict_marker_size;
+ size += xdl_recs_copy(xe1, m->i1, m->chg1, 1,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '=';
+ dest[size++] = '\n';
+ }
+ size += xdl_recs_copy(xe2, m->i2, m->chg2, 1,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '>';
+ if (marker2_size) {
+ dest[size] = ' ';
+ memcpy(dest + size + 1, name2,
+ marker2_size - 1);
+ size += marker2_size;
+ }
+ dest[size++] = '\n';
+ }
+ } else if (m->mode == 1)
+ size += xdl_recs_copy(xe1, i1, m->i1 + m->chg1 - i1, 0,
+ dest ? dest + size : NULL);
+ else if (m->mode == 2)
+ size += xdl_recs_copy(xe2, m->i2 - m->i1 + i1,
+ m->i1 + m->chg2 - i1, 0,
+ dest ? dest + size : NULL);
+ i1 = m->i1 + m->chg1;
+ }
+ size += xdl_recs_copy(xe1, i1, xe1->xdf2.nrec - i1, 0,
+ dest ? dest + size : NULL);
+ return size;
+}
+
+/*
+ * Sometimes, changes are not quite identical, but differ in only a few
+ * lines. Try hard to show only these few lines as conflicting.
+ */
+static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
+ xpparam_t const *xpp)
+{
+ for (; m; m = m->next) {
+ mmfile_t t1, t2;
+ xdfenv_t xe;
+ xdchange_t *xscr, *x;
+ int i1 = m->i1, i2 = m->i2;
+
+ /* let's handle just the conflicts */
+ if (m->mode)
+ continue;
+
+ /*
+ * This probably does not work outside git, since
+ * we have a very simple mmfile structure.
+ */
+ t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
+ t1.size = xe1->xdf2.recs[m->i1 + m->chg1]->ptr
+ + xe1->xdf2.recs[m->i1 + m->chg1]->size - t1.ptr;
+ t2.ptr = (char *)xe2->xdf2.recs[m->i1]->ptr;
+ t2.size = xe2->xdf2.recs[m->i1 + m->chg1]->ptr
+ + xe2->xdf2.recs[m->i1 + m->chg1]->size - t2.ptr;
+ if (xdl_do_diff(&t1, &t2, xpp, &xe) < 0)
+ return -1;
+ if (xdl_change_compact(&xe.xdf1, &xe.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe.xdf2, &xe.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe, &xscr) < 0) {
+ xdl_free_env(&xe);
+ return -1;
+ }
+ if (!xscr) {
+ /* If this happens, it's a bug. */
+ xdl_free_env(&xe);
+ return -2;
+ }
+ x = xscr;
+ m->i1 = xscr->i1 + i1;
+ m->chg1 = xscr->chg1;
+ m->i2 = xscr->i2 + i2;
+ m->chg2 = xscr->chg2;
+ while (xscr->next) {
+ xdmerge_t *m2 = xdl_malloc(sizeof(xdmerge_t));
+ if (!m2) {
+ xdl_free_env(&xe);
+ xdl_free_script(x);
+ return -1;
+ }
+ xscr = xscr->next;
+ m2->next = m->next;
+ m->next = m2;
+ m = m2;
+ m->mode = 0;
+ m->i1 = xscr->i1 + i1;
+ m->chg1 = xscr->chg1;
+ m->i2 = xscr->i2 + i2;
+ m->chg2 = xscr->chg2;
+ }
+ xdl_free_env(&xe);
+ xdl_free_script(x);
+ }
+ return 0;
+}
+
+/*
+ * level == 0: mark all overlapping changes as conflict
+ * level == 1: mark overlapping changes as conflict only if not identical
+ * level == 2: analyze non-identical changes for minimal conflict set
+ *
+ * returns < 0 on error, == 0 for no conflicts, else number of conflicts
+ */
+static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
+ xdfenv_t *xe2, xdchange_t *xscr2, const char *name2,
+ int level, xpparam_t const *xpp, mmbuffer_t *result) {
+ xdmerge_t *changes, *c;
+ int i1, i2, chg1, chg2;
+
+ c = changes = NULL;
+
+ while (xscr1 && xscr2) {
+ if (!changes)
+ changes = c;
+ if (xscr1->i1 + xscr1->chg1 < xscr2->i1) {
+ i1 = xscr1->i2;
+ i2 = xscr2->i2 - xscr2->i1 + xscr1->i1;
+ chg1 = xscr1->chg2;
+ chg2 = xscr1->chg1;
+ if (xdl_append_merge(&c, 1, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr1 = xscr1->next;
+ continue;
+ }
+ if (xscr2->i1 + xscr2->chg1 < xscr1->i1) {
+ i1 = xscr1->i2 - xscr1->i1 + xscr2->i1;
+ i2 = xscr2->i2;
+ chg1 = xscr2->chg1;
+ chg2 = xscr2->chg2;
+ if (xdl_append_merge(&c, 2, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr2 = xscr2->next;
+ continue;
+ }
+ if (level < 1 || xscr1->i1 != xscr2->i1 ||
+ xscr1->chg1 != xscr2->chg1 ||
+ xscr1->chg2 != xscr2->chg2 ||
+ xdl_merge_cmp_lines(xe1, xscr1->i2,
+ xe2, xscr2->i2,
+ xscr1->chg2, xpp->flags)) {
+ /* conflict */
+ int off = xscr1->i1 - xscr2->i1;
+ int ffo = off + xscr1->chg1 - xscr2->chg1;
+
+ i1 = xscr1->i2;
+ i2 = xscr2->i2;
+ if (off > 0)
+ i1 -= off;
+ else
+ i2 += off;
+ chg1 = xscr1->i2 + xscr1->chg2 - i1;
+ chg2 = xscr2->i2 + xscr2->chg2 - i2;
+ if (ffo > 0)
+ chg2 += ffo;
+ else
+ chg1 -= ffo;
+ if (xdl_append_merge(&c, 0, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ }
+
+ i1 = xscr1->i1 + xscr1->chg1;
+ i2 = xscr2->i1 + xscr2->chg1;
+
+ if (i1 > i2) {
+ xscr1->chg1 -= i1 - i2;
+ xscr1->i1 = i2;
+ xscr1->i2 += xscr1->chg2;
+ xscr1->chg2 = 0;
+ xscr1 = xscr1->next;
+ } else if (i2 > i1) {
+ xscr2->chg1 -= i2 - i1;
+ xscr2->i1 = i1;
+ xscr2->i2 += xscr2->chg2;
+ xscr2->chg2 = 0;
+ xscr2 = xscr2->next;
+ } else {
+ xscr1 = xscr1->next;
+ xscr2 = xscr2->next;
+ }
+ }
+ while (xscr1) {
+ if (!changes)
+ changes = c;
+ i1 = xscr1->i2;
+ i2 = xscr1->i1 + xe2->xdf2.nrec - xe2->xdf1.nrec;
+ chg1 = xscr1->chg2;
+ chg2 = xscr1->chg1;
+ if (xdl_append_merge(&c, 1, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr1 = xscr1->next;
+ }
+ while (xscr2) {
+ if (!changes)
+ changes = c;
+ i1 = xscr2->i1 + xe1->xdf2.nrec - xe1->xdf1.nrec;
+ i2 = xscr2->i2;
+ chg1 = xscr2->chg1;
+ chg2 = xscr2->chg2;
+ if (xdl_append_merge(&c, 2, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr2 = xscr2->next;
+ }
+ if (!changes)
+ changes = c;
+ /* refine conflicts */
+ if (level > 1 && xdl_refine_conflicts(xe1, xe2, changes, xpp) < 0) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ /* output */
+ if (result) {
+ int size = xdl_fill_merge_buffer(xe1, name1, xe2, name2,
+ changes, NULL);
+ result->ptr = xdl_malloc(size);
+ if (!result->ptr) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ result->size = size;
+ xdl_fill_merge_buffer(xe1, name1, xe2, name2, changes,
+ result->ptr);
+ }
+ return xdl_cleanup_merge(changes);
+}
+
+int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
+ mmfile_t *mf2, const char *name2,
+ xpparam_t const *xpp, int level, mmbuffer_t *result) {
+ xdchange_t *xscr1, *xscr2;
+ xdfenv_t xe1, xe2;
+
+ result->ptr = NULL;
+ result->size = 0;
+
+ if (xdl_do_diff(orig, mf1, xpp, &xe1) < 0 ||
+ xdl_do_diff(orig, mf2, xpp, &xe2) < 0) {
+ return -1;
+ }
+ if (xdl_change_compact(&xe1.xdf1, &xe1.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe1.xdf2, &xe1.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe1, &xscr1) < 0) {
+ xdl_free_env(&xe1);
+ return -1;
+ }
+ if (xdl_change_compact(&xe2.xdf1, &xe2.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe2.xdf2, &xe2.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe2, &xscr2) < 0) {
+ xdl_free_env(&xe2);
+ return -1;
+ }
+ if (xscr1 || xscr2) {
+ if (!xscr1) {
+ result->ptr = xdl_malloc(mf2->size);
+ memcpy(result->ptr, mf2->ptr, mf2->size);
+ result->size = mf2->size;
+ } else if (!xscr2) {
+ result->ptr = xdl_malloc(mf1->size);
+ memcpy(result->ptr, mf1->ptr, mf1->size);
+ result->size = mf1->size;
+ } else if (xdl_do_merge(&xe1, xscr1, name1,
+ &xe2, xscr2, name2,
+ level, xpp, result) < 0) {
+ xdl_free_script(xscr1);
+ xdl_free_script(xscr2);
+ xdl_free_env(&xe1);
+ xdl_free_env(&xe2);
+ return -1;
+ }
+ xdl_free_script(xscr1);
+ xdl_free_script(xscr2);
+ }
+ xdl_free_env(&xe1);
+ xdl_free_env(&xe2);
+
+ return 0;
+}
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2006-11-21 22:24 (unknown) Johannes Schindelin
@ 2006-11-22 20:16 ` Davide Libenzi
0 siblings, 0 replies; 669+ messages in thread
From: Davide Libenzi @ 2006-11-22 20:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On Tue, 21 Nov 2006, Johannes Schindelin wrote:
> [PATCH] xdiff: add xdl_merge()
>
> This new function implements the functionality of RCS merge, but
> in-memory. It returns < 0 on error, otherwise the number of conflicts.
>
> Finding the conflicting lines can be a very expensive task. You can
> control the eagerness of this algorithm:
>
> - a level value of 0 means that all overlapping changes are treated
> as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
> it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
> almost identical changes will not result in huge conflicts. Rather,
> only the conflicting lines will be shown inside conflict markers.
>
> With each increasing level, the algorithm gets slower, but more accurate.
> Note that the code for level 2 depends on the simple definition of
> mmfile_t specific to git, and therefore it will be harder to port that
> to LibXDiff.
Johannes, at the moment I'm chased by a huge storm of never ending emails,
so I won't be able to follow up this one soon. A smart 3-way merge is in
my plans for LibXDiff though.
There is quite some nice code around, that does pretty smart tricks and
goes down to resolve sub-hunk non-trivial conflicts. You may want to take
a look at that code too.
- Davide
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <D3E576A1A7C7134694A0DDA7C2CA4B884C3985@hyd-mail2.bbnet.ad>]
* (unknown)
@ 2006-10-20 14:24 andyparkins
2006-10-20 14:42 ` your mail Johannes Schindelin
0 siblings, 1 reply; 669+ messages in thread
From: andyparkins @ 2006-10-20 14:24 UTC (permalink / raw)
>From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:24:22 +0100
Subject: [PATCH] Remove git-send-email references from documentation
MIME-Version: 1.0
X-TUID: 1fbae8e75caaf795
X-Length: 1933
To: git@vger.kernel.org
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_WwNOFc8Re2ORHlu"
Message-Id: <200610201524.22493.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_WwNOFc8Re2ORHlu
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
git-send-email doesn't exist; so don't refer to it in the documentation.
Perhaps git-send-email.perl is meant to do this job? It runs with an error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-format-patch.txt | 2 +-
Documentation/git.txt | 3 ---
2 files changed, 1 insertions(+), 4 deletions(-)
--Boundary-00=_WwNOFc8Re2ORHlu
Content-Type: text/x-patch;
name="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 67425dc..9257030 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -112,7 +112,7 @@ git-format-patch -M -B origin::
See Also
--------
-gitlink:git-am[1], gitlink:git-send-email[1]
+gitlink:git-am[1]
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3af6fc6..1f60d3f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,9 +478,6 @@ gitlink:git-request-pull[1]::
gitlink:git-rev-parse[1]::
Pick out and massage parameters.
-gitlink:git-send-email[1]::
- Send patch e-mails out of "format-patch --mbox" output.
-
gitlink:git-symbolic-ref[1]::
Read and modify symbolic refs.
--Boundary-00=_WwNOFc8Re2ORHlu--
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2006-10-20 14:24 (unknown) andyparkins
@ 2006-10-20 14:42 ` Johannes Schindelin
0 siblings, 0 replies; 669+ messages in thread
From: Johannes Schindelin @ 2006-10-20 14:42 UTC (permalink / raw)
To: andyparkins; +Cc: git
Hi,
your email is horridly mixed here. I get an empty subject here, and the
complete email header at the beginning of the email:
On Fri, 20 Oct 2006, andyparkins@gmail.com wrote:
> >From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> [... complete email header including MIME header ...]
> Content-Disposition: inline
>
> git-send-email doesn't exist; so don't refer to it in the documentation.
But it does! I just removed it, and "make" remade it. I don't even see in
the Makefile why it should _not_ be made...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <C8DBC54F2A9BAD4FA7F445CC7ADD963B0232474F@sslmexchange1.paymentech.us>]
* Re: your mail
[not found] <C8DBC54F2A9BAD4FA7F445CC7ADD963B0232474F@sslmexchange1.paymentech.us>
@ 2006-09-26 19:56 ` Linus Torvalds
0 siblings, 0 replies; 669+ messages in thread
From: Linus Torvalds @ 2006-09-26 19:56 UTC (permalink / raw)
To: Zhao, Jing; +Cc: Andy Whitcroft, Git Mailing List
On Tue, 26 Sep 2006, Zhao, Jing wrote:
>
> I subscribed git emailing list (git@vger.kernel.org). I don't know for
> what reason, my post emails all have been rejected. Could you post this
> for me and shed some light on this issue? thanks,
The vger.kernel.org lists have various spam detectors, and I suspect a
combination of your email address and the signature you use just triggers
that system to believe that you are trying to sell us house payment plans
or something..
So I would suggest removing your signature in particular, that points to a
web-site that is associated with an industry that has over-used the email
medium for selling their services...
> I tried to port git to VOS system (Stratus). When i compiled it, i
> found it did not have 'regex.h' and its library. Do you know any
> workaround for this problem? Or which package contains these code i can
> port at first?
I do not know if stratus has regex libraries anywhere, but googling for
"VOS Stratus regex" seems to be saying that this isn't the first time that
platform has had problems compiling various programs.
I suspect you'd just have to compile one of the regex libraries that are
out there as source. I think Henry Spencer's libraries are likely the
canonical ones, but there's a "GNU regex" too, and that's probably the
basis for the ones that are used in glibc. Dunno.
Google for either of those, you'll find them. It's not new code, but I
doubt it needs to be ;)
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2006-05-21 23:53 J. Bruce Fields
2006-05-21 23:55 ` your mail J. Bruce Fields
0 siblings, 1 reply; 669+ messages in thread
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:52:34 -0400
Subject: [PATCH 1/3] tutorial: replace "whatchanged" by "log"
Junio suggested changing references to git-whatchanged to git-log.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
d1177b299b449e9eb63d963ee118a5e0283aa611
Documentation/tutorial.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
d1177b299b449e9eb63d963ee118a5e0283aa611
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index fa79b01..cd0f0df 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -80,13 +80,13 @@ file; just remove it, then commit.
At any point you can view the history of your changes using
------------------------------------------------
-$ git whatchanged
+$ git log
------------------------------------------------
If you also want to see complete diffs at each step, use
------------------------------------------------
-$ git whatchanged -p
+$ git log -p
------------------------------------------------
Managing branches
@@ -216,7 +216,7 @@ This actually pulls changes from the bra
"master". Alice could request a different branch by adding the name
of the branch to the end of the git pull command line.
-This merges Bob's changes into her repository; "git whatchanged" will
+This merges Bob's changes into her repository; "git log" will
now show the new commits. If Alice has made her own changes in the
meantime, then Bob's changes will be merged in, and she will need to
manually fix any conflicts.
@@ -234,7 +234,7 @@ named bob-incoming. (Unlike git pull, g
of Bob's line of development without doing any merging). Then
-------------------------------------
-$ git whatchanged -p master..bob-incoming
+$ git log -p master..bob-incoming
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -330,13 +330,13 @@ But you may find it more useful to see t
the experimental branch but not in the current branch, and
-------------------------------------
-git whatchanged HEAD..experimental
+git log HEAD..experimental
-------------------------------------
will do that, just as
-------------------------------------
-git whatchanged experimental..HEAD
+git log experimental..HEAD
-------------------------------------
will show the list of commits made on the HEAD but not included in
--
1.3.3.gff62
^ permalink raw reply related [flat|nested] 669+ messages in thread
* Re: your mail
2006-05-21 23:53 (unknown) J. Bruce Fields
@ 2006-05-21 23:55 ` J. Bruce Fields
2006-05-22 0:16 ` Junio C Hamano
0 siblings, 1 reply; 669+ messages in thread
From: J. Bruce Fields @ 2006-05-21 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
Oops, sorry, I screwed up sending those; let me know if you'd like them
resent....
--b.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2006-05-21 23:55 ` your mail J. Bruce Fields
@ 2006-05-22 0:16 ` Junio C Hamano
2006-05-22 1:33 ` J. Bruce Fields
0 siblings, 1 reply; 669+ messages in thread
From: Junio C Hamano @ 2006-05-22 0:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
>> >From nobody Mon Sep 17 00:00:00 2001
>> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Oops, sorry, I screwed up sending those; let me know if you'd like them
> resent....
That's OK. I just cooked up this one ;-).
-- >8 --
From 03946787890c12fbb6ecfbe0382cbf02ac209801 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 21 May 2006 17:15:06 -0700
Subject: [PATCH] mailinfo: skip bogus UNIX From line inside body
Sometimes people just include the whole format-patch output in
the commit e-mail. Detect it and skip the bogus ">From " line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
mailinfo.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/mailinfo.c b/mailinfo.c
index b276519..a133e6d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,10 +237,17 @@ static int eatspace(char *line)
#define SEEN_FROM 01
#define SEEN_DATE 02
#define SEEN_SUBJECT 04
+#define SEEN_BOGUS_UNIX_FROM 010
/* First lines of body can have From:, Date:, and Subject: */
static int handle_inbody_header(int *seen, char *line)
{
+ if (!memcmp(">From", line, 5) && isspace(line[5])) {
+ if (!(*seen & SEEN_BOGUS_UNIX_FROM)) {
+ *seen |= SEEN_BOGUS_UNIX_FROM;
+ return 1;
+ }
+ }
if (!memcmp("From:", line, 5) && isspace(line[5])) {
if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
*seen |= SEEN_FROM;
--
1.3.3.g292f
^ permalink raw reply related [flat|nested] 669+ messages in thread* Re: your mail
2006-05-22 0:16 ` Junio C Hamano
@ 2006-05-22 1:33 ` J. Bruce Fields
0 siblings, 0 replies; 669+ messages in thread
From: J. Bruce Fields @ 2006-05-22 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
>
> That's OK. I just cooked up this one ;-).
Thanks!--b.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2006-01-11 14:47 bhess
2006-01-11 17:44 ` your mail Ross Vandegrift
0 siblings, 1 reply; 669+ messages in thread
From: bhess @ 2006-01-11 14:47 UTC (permalink / raw)
To: linux-raid
linux-raid@vger.kernel.org
I originally sent this to Neil Brown who suggested I sent it to you.
Any help would be appreciated.
Has anyone put an effort into building a raid 1 based on USB connected
drives under Redhat 3/4 not as the root/boot
drive. A year ago I don't think this made any sense but with the
price of drives being far less that then the equivalent tape media
and the simple USB to IDE smart cable I am evaluating an expandable
USB disk farm for two uses. A reasonable robust place to store
data until I can select what I want to put on tape. The second
is secondary storage for all of the family video tapes that I am
capturing in preparation for editing to DVD. The system does not
have to be fast just large, robust, expandable and cheep.
I currently run a Redhat sandbox with a hardware raid 5 and 4 120G
SATA drives. I have added USB drives and have them mount with
the LABEL=/PNAME option in fstab. In this manner they end up
in the right place after reboot. I do not know enough about
the Linux drive interface to know if USB attached devices will
get properly mounted into the raid at reboot and after changes
or additions of drives to the USB.
I am a retired Bell Labs Research supervisor. I was in Murray Hill
when UNIX was born and still use Intel based UNIX in the current
form of SCO Unixware both professionally and personally. Unixware
is no longer a viable product since I see no future in it and
Oracle is not supported. I know way to much about how the guts
of Unixware works thanks to a friend who was one of SCO's kernel
and storage designers. I know way to little how Linux works to
get a USB based raid up without a lot of research and tinkering.
I don't mind research and tinkering but I don't like reinventing
the wheel.
I have read The Software-RAID HOWTO by Jakob 0stergaard and
Emilio Bueso and downloaded mdadm. I have not tried it yet.
The system I have in mind uses a Intel server motherboard,
hardware raid 1 SATA root/boot/swap drive, SCSI tape drive
and a 4 port USB card. In a 2U chasses. A second 2U chassis
will contain a supply, up to 14 drives and lots of fans.
I have everything except the drives. The sole use of this system
will be a disk farm with a NFS and Samba server. It will run
under Redhat 3 or 4. I am leaning toward Redhat 4 since I
understand SCSI tape support is more stable under 4. Any
comment in this area would also be appreciated.
Can you point me in the direction of newer articles that cover
Linux raid using USB connected drives or do you have any
suggestions on the configuration of a system. My main concern
is how to get USB drives correctly put back in the raid after
boot and/or a USB change since I do not know how they are assigned
to /dev/sdxy in the first place and how USB hubs interact with
the assignments. I realize I should have other concerns and
just don't know enough. Ignorance is bliss, up to an init 6.
Thank You for your time.
Bill Hess
bhess@patmedia.net
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2006-01-11 14:47 (unknown) bhess
@ 2006-01-11 17:44 ` Ross Vandegrift
0 siblings, 0 replies; 669+ messages in thread
From: Ross Vandegrift @ 2006-01-11 17:44 UTC (permalink / raw)
To: bhess; +Cc: linux-raid
On Wed, Jan 11, 2006 at 09:47:03AM -0500, bhess@patmedia.net wrote:
> Has anyone put an effort into building a raid 1 based on USB connected
> drives under Redhat 3/4 not as the root/boot
> drive.
No, I haven't actually tried this, but I do know that it'll work
without any problem.
The main issue that you'll confront - USB devices do not have fixed
device numbers. They can change every time they are plugged/unplugged.
As a result, you may not be able to depend on your disks to always be
(for example) /dev/sde and /dev/sdf.
There's a user-space daemon called hotplug that manages this stuff.
It load appropriate drivers for the devices it sees plugged into the
USB bus. I don't know enough about to tell you specifically how it
will handle your setup.
My initial suggestion:
1) Start with no driver plugged
2) cat /proc/partitions > ~/nousb
3) Plug one drive in
4) cat /proc/partitions > ~/oneusb
5) Plug second drive in
6) cat /proc/parititons > ~/twousb
7) diff -u ~/nousb ~/oneusb
8) diff -u ~/oneusb ~/twousb
This should give you a good idea of how the kernel treats the
situation from the device perspective.
As far as the RAID part - that's easy. Once you know what the block
devices look like, make your RAID. I promise the md driver will work.
I've run md across all sorts of weird device setups and so long as
it's a working block device, md is happy!
Finally, if you use mdadm's --uuid option to assemble your array after
creating it, it should just find the USB disks, regardless of where
they came up. That way, you only need to worry about what device node
they are using when you first create the array.
Good luck!
--
Ross Vandegrift
ross@lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2005-11-25 22:06 root
2005-11-26 0:11 ` your mail Hugh Dickins
0 siblings, 1 reply; 669+ messages in thread
From: root @ 2005-11-25 22:06 UTC (permalink / raw)
To: linux-kernel
Nov 25 21:59:24 txiringo kernel: [17182458.504000] program ddcprobe is using MAP_PRIVATE, PROT_WRITE mmap of VM_RESERVED memory, which is deprecated. Please report this to linux-kernel@vger.kernel.org
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2005-11-25 22:06 root
@ 2005-11-26 0:11 ` Hugh Dickins
0 siblings, 0 replies; 669+ messages in thread
From: Hugh Dickins @ 2005-11-26 0:11 UTC (permalink / raw)
To: root; +Cc: linux-kernel
On Fri, 25 Nov 2005, root wrote:
> Nov 25 21:59:24 txiringo kernel: [17182458.504000] program ddcprobe
> is using MAP_PRIVATE, PROT_WRITE mmap of VM_RESERVED memory, which
> is deprecated. Please report this to linux-kernel@vger.kernel.org
Thanks for the report: now fixed, please upgrade to 2.6.15-rc2-git3 or later.
Hugh
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2005-10-05 6:10 Willem Swart
2005-10-06 10:52 ` your mail Elfyn McBratney
0 siblings, 1 reply; 669+ messages in thread
From: Willem Swart @ 2005-10-05 6:10 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <200508301321.j7UDLV9k002943@toshiba.co.jp>]
* Re: your mail
[not found] <200508301321.j7UDLV9k002943@toshiba.co.jp>
@ 2005-08-30 14:09 ` Harald Welte
0 siblings, 0 replies; 669+ messages in thread
From: Harald Welte @ 2005-08-30 14:09 UTC (permalink / raw)
To: Yasuyuki KOZAKAI; +Cc: netfilter-devel, pablo
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On Tue, Aug 30, 2005 at 10:21:31PM +0900, Yasuyuki KOZAKAI wrote:
>
> Hi,
>
> If CONFIG_NF_IP_CONNTRACK=y, CONFIG_NETFILTER_NETLINK=m, and
> CONFIG_NF_CONNTRACK_NETLINK=m, it's failed to build kernel
> of netfilter-2.6.14 git tree. Because __nfa_fill() in nfnetlink
> called from ip_conntrack isn't built into kernel image in this case.
> It's necessary to fix Kconfig or change source code to make dependencies
> more simple.
Thanks for pointing this out.
This problem will be fixed by Thomas Graf's generic netlink macros
(which will be part of the core network stack) which will be merged
during the net-2.6.14 process, so I think we can ignore
this for now.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2005-06-16 23:08 trmcneal
2005-06-16 23:32 ` your mail Chris Wedgwood
0 siblings, 1 reply; 669+ messages in thread
From: trmcneal @ 2005-06-16 23:08 UTC (permalink / raw)
To: linux-kernel
I posted this on linux-net, and got only one reply, saying that they
had run into this as well. Not much help. I'm thinking that I need to
tune the kernel somehow to prevent this, but I'm not sure how. It doesn't
happen on Solaris, and seems to be a resource issue, but its probably
not memory. Here are the details:
> I've been working with some tcp network test programs that have
> multiple clients opening nonblocking sockets to a single server port,
> sending a short message, and then closing the socket, 100,000 times.
> Since the socket is non-blocking, it generally tries to connect and then
> does a poll since the socket is busy. The test fails if the poll times out in
> 10 seconds. It fails consistently on Linux servers but succeeds on Solaris
> servers; the client is a non-issue unless its loopback on the Linux server.
> This issue crops up both on 2.4 and 2.6 kernels; the main feature seen
> in tcp dumps is that the server gets inundated with retrys, and then starts
> sending RST responses to everything (labelled as ZeroWindow in a
> Ethereal dump). One interesting feature is that many clients thinks the
> 3-way connection handshake is complete, when the server actually
> doesn't get the final ACK; The client starts sending and then retransmitting
> the data, and the server keeps sending back the SYN/ACK part of the
> handshake. Another interesting feature is a group of retries from various
> client ports, followed by a group of ACK,RST responses from the server,
> followed by the ZeroWindow RST to everything.
> On Linux, the only way to succeed is to use remote clients - thus avoiding
> extra work on the server -and changing test parameters to put in a longer
> server delay, which is inserted between the closing of one connection and
> the opening of the next. I'm assuming that the tcp network queues are just
> getting overloaded with the data retransmissions, but I don't know enough
> about the queue management yet. Any suggestions/pointers/fixes?
Any ideas about tuning, or what resource I'm running out of?
Regards -
Tom McNeal
--
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2005-06-16 23:08 trmcneal
@ 2005-06-16 23:32 ` Chris Wedgwood
2005-06-17 1:46 ` Tom McNeal
0 siblings, 1 reply; 669+ messages in thread
From: Chris Wedgwood @ 2005-06-16 23:32 UTC (permalink / raw)
To: trmcneal; +Cc: linux-kernel
On Thu, Jun 16, 2005 at 11:08:28PM +0000, trmcneal@comcast.net wrote:
> > I've been working with some tcp network test programs that have
> > multiple clients opening nonblocking sockets to a single server
> > port, sending a short message, and then closing the socket,
> > 100,000 times. Since the socket is non-blocking, it generally
> > tries to connect and then does a poll since the socket is busy.
> > The test fails if the poll times out in 10 seconds. It fails
> > consistently on Linux servers but succeeds on Solaris servers; the
> > client is a non-issue unless its loopback on the Linux server.
where is the code for this? are you sure you're not overflowing the
listen backlog somewhere? that would show up in some cases but not
all depending on latencies and local scheduler behavior
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2005-06-16 23:32 ` your mail Chris Wedgwood
@ 2005-06-17 1:46 ` Tom McNeal
0 siblings, 0 replies; 669+ messages in thread
From: Tom McNeal @ 2005-06-17 1:46 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: linux-kernel
I'll look at that. This occurs on all Linux platforms, including a generic
2.4.31 I downloaded from kernel.org. The user test is trivial, just doing
the nonblocking connect, the poll, the send, and then the close, in that loop.
Tom
Chris Wedgwood wrote:
> On Thu, Jun 16, 2005 at 11:08:28PM +0000, trmcneal@comcast.net wrote:
>
>
>>>I've been working with some tcp network test programs that have
>>>multiple clients opening nonblocking sockets to a single server
>>>port, sending a short message, and then closing the socket,
>>>100,000 times. Since the socket is non-blocking, it generally
>>>tries to connect and then does a poll since the socket is busy.
>>>The test fails if the poll times out in 10 seconds. It fails
>>>consistently on Linux servers but succeeds on Solaris servers; the
>>>client is a non-issue unless its loopback on the Linux server.
>
>
> where is the code for this? are you sure you're not overflowing the
> listen backlog somewhere? that would show up in some cases but not
> all depending on latencies and local scheduler behavior
>
--
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
Email: trmcneal@comcast.net
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2005-04-28 19:15 Bryan Althouse
2005-04-29 11:02 ` your mail Ralf Baechle
0 siblings, 1 reply; 669+ messages in thread
From: Bryan Althouse @ 2005-04-28 19:15 UTC (permalink / raw)
To: linux-mips; +Cc: TheNop
Hello,
I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
Somehow, I am unable to compile the kernel. I have tried the 2.6.10 kernel
trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
linux-mips. I am using the 3.3.x cross compile tools from
ftp.pmc-sierra.com . The 2.4.x kernels from PMC compile fine.
In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
Make[3]: *** [drivers/char/agp/backend.o] Error 1
In the case of 2.6.12 from linux-mips, my error looks like:
drivers/net/titan_ge.c1950: error: 'titan_device_remove" undeclared
here (not in a function)
My compile process is like so:
make mrproper
make xconfig
make oldconfig
make ARCH=mips CROSS_COMPILE=/<tool_path>/mips64-linux-gnu- vmlinux
Could someone share their .config with me, or make some suggestions?
Thank you,
Bryan
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2005-04-28 19:15 Bryan Althouse
@ 2005-04-29 11:02 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 2005-04-29 11:02 UTC (permalink / raw)
To: Bryan Althouse; +Cc: linux-mips, TheNop
On Thu, Apr 28, 2005 at 03:15:49PM -0400, Bryan Althouse wrote:
> I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
> Somehow, I am unable to compile the kernel. I have tried the 2.6.10 kernel
> trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
> linux-mips. I am using the 3.3.x cross compile tools from
> ftp.pmc-sierra.com . The 2.4.x kernels from PMC compile fine.
>
> In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
> Make[3]: *** [drivers/char/agp/backend.o] Error 1
Configuring AGP support for a MIPS kernel is obviously nonsense. Disable
CONFIG_AGP.
> In the case of 2.6.12 from linux-mips, my error looks like:
> drivers/net/titan_ge.c1950: error: 'titan_device_remove" undeclared
> here (not in a function)
Whoops, a bug. The function indeed doesn't exist even though it should,
will fix that. You will hit this bug only if compiling the titan driver
as a module, so workaround set CONFIG_TITAN_GE=y. Which for the typical
titan-based device seems to be the preferable choice anyway.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2005-02-03 0:17 Aleksey Gorelov
2005-02-03 1:12 ` your mail Matthew Dharm
2005-02-03 16:03 ` Alan Stern
0 siblings, 2 replies; 669+ messages in thread
From: Aleksey Gorelov @ 2005-02-03 0:17 UTC (permalink / raw)
To: stern, mdharm-usb; +Cc: linux-kernel
Hi Matt, Alan,
Could you please tell me (link would do) why it makes default
delay_use=5
really necessary (from the patch below)?
https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
7.html
It makes USB boot really painfull and slow :(
I understand there should be a good reason for it. I've tried to find
an answer in
archives, without much success though.
Thanks,
Aleks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2005-02-03 0:17 Aleksey Gorelov
@ 2005-02-03 1:12 ` Matthew Dharm
2005-02-03 16:03 ` Alan Stern
1 sibling, 0 replies; 669+ messages in thread
From: Matthew Dharm @ 2005-02-03 1:12 UTC (permalink / raw)
To: Aleksey Gorelov; +Cc: stern, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
It's basically just like the code says.
A lot of devices choke if you access them too quickly after enumeration.
The 5 second delay seems to be enough for most devices. But we made it
adjustable exactly for people like you.
Matt
On Wed, Feb 02, 2005 at 04:17:13PM -0800, Aleksey Gorelov wrote:
> Hi Matt, Alan,
>
> Could you please tell me (link would do) why it makes default
> delay_use=5
> really necessary (from the patch below)?
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
> 7.html
>
> It makes USB boot really painfull and slow :(
>
> I understand there should be a good reason for it. I've tried to find
> an answer in
> archives, without much success though.
>
> Thanks,
> Aleks.
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Now payink attention, please. This is mouse. Click-click. Easy to
use, da? Now you try...
-- Pitr to Miranda
User Friendly, 10/11/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2005-02-03 0:17 Aleksey Gorelov
2005-02-03 1:12 ` your mail Matthew Dharm
@ 2005-02-03 16:03 ` Alan Stern
1 sibling, 0 replies; 669+ messages in thread
From: Alan Stern @ 2005-02-03 16:03 UTC (permalink / raw)
To: Aleksey Gorelov; +Cc: mdharm-usb, linux-kernel
On Wed, 2 Feb 2005, Aleksey Gorelov wrote:
> Hi Matt, Alan,
>
> Could you please tell me (link would do) why it makes default
> delay_use=5
> really necessary (from the patch below)?
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
> 7.html
>
> It makes USB boot really painfull and slow :(
>
> I understand there should be a good reason for it. I've tried to find
> an answer in
> archives, without much success though.
Lots of devices don't need that delay, but enough of them do that we
decided to add it. The value of 5 seconds was more or less arbitrary; it
was long enough for every device we could test and it didn't seem _too_
long. Maybe 1 second would be long enough -- we just didn't know so we
were conservative.
Alan Stern
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-11-16 13:48 Artem B. Bityuckiy
2004-11-16 13:55 ` David Woodhouse
0 siblings, 1 reply; 669+ messages in thread
From: Artem B. Bityuckiy @ 2004-11-16 13:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: MTD List
Hello David,
When I create checkpoints, I read all the nodes which will be referred by
this checkpoint and check their CRCs. This is because we must trust
checkpoints and do not check CRCs for them on the iget() call.
When the Garbage Collector moves node, which is currently referred by an
checkpoint inact (I mean the jffs2_garbage_collect_pristine() function),
we have to read this node after we GC it. This is the problem. The unclean
reboot may happed and we can not guarantee that all noted in checkpoint
are OK. :-(
So, how do you think is it absolutely necessary to check that nodes which
are reffered by checkpoint are OK? Is it OK if we just detect errors when
we actually read file?
Thanks.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
2004-11-16 13:48 (no subject) Artem B. Bityuckiy
@ 2004-11-16 13:55 ` David Woodhouse
2004-11-16 14:21 ` your mail Artem B. Bityuckiy
0 siblings, 1 reply; 669+ messages in thread
From: David Woodhouse @ 2004-11-16 13:55 UTC (permalink / raw)
To: Artem B. Bityuckiy; +Cc: MTD List
On Tue, 2004-11-16 at 13:48 +0000, Artem B. Bityuckiy wrote:
> Hello David,
>
> When I create checkpoints, I read all the nodes which will be referred by
> this checkpoint and check their CRCs. This is because we must trust
> checkpoints and do not check CRCs for them on the iget() call.
>
> When the Garbage Collector moves node, which is currently referred by an
> checkpoint inact (I mean the jffs2_garbage_collect_pristine() function),
> we have to read this node after we GC it. This is the problem. The unclean
> reboot may happed and we can not guarantee that all noted in checkpoint
> are OK. :-(
>
> So, how do you think is it absolutely necessary to check that nodes which
> are reffered by checkpoint are OK? Is it OK if we just detect errors when
> we actually read file?
No, that's not OK. We'd actually lose the data in that case, surely? We
_need_ to pick up the new copy of the node, if the old one is absent.
Either we have to obsolete the newer checkpoint or we have to ignore the
checkpoint data if we get a failure, and rescan properly.
--
dwmw2
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-11-16 13:55 ` David Woodhouse
@ 2004-11-16 14:21 ` Artem B. Bityuckiy
2004-11-16 14:29 ` David Woodhouse
0 siblings, 1 reply; 669+ messages in thread
From: Artem B. Bityuckiy @ 2004-11-16 14:21 UTC (permalink / raw)
To: David Woodhouse; +Cc: MTD List
On Tue, 16 Nov 2004, David Woodhouse wrote:
> On Tue, 2004-11-16 at 13:48 +0000, Artem B. Bityuckiy wrote:
> > Hello David,
> >
> > When I create checkpoints, I read all the nodes which will be referred by
> > this checkpoint and check their CRCs. This is because we must trust
> > checkpoints and do not check CRCs for them on the iget() call.
> >
> > When the Garbage Collector moves node, which is currently referred by an
> > checkpoint inact (I mean the jffs2_garbage_collect_pristine() function),
> > we have to read this node after we GC it. This is the problem. The unclean
> > reboot may happed and we can not guarantee that all noted in checkpoint
> > are OK. :-(
> >
> > So, how do you think is it absolutely necessary to check that nodes which
> > are reffered by checkpoint are OK? Is it OK if we just detect errors when
> > we actually read file?
>
> No, that's not OK. We'd actually lose the data in that case, surely? We
> _need_ to pick up the new copy of the node, if the old one is absent.
> Either we have to obsolete the newer checkpoint or we have to ignore the
> checkpoint data if we get a failure, and rescan properly.
>
> --
> dwmw2
>
>
:-((
Very bad...
This means that checkpoints will have short live-time. I mean, that if we
have some read-only file and have generated the checkpoint for this file,
we will need to rewrite the checkpoint periodically when it becomes
obsolete because the file's nodes are moved by the GC.... :-(
I call checkpoint obsolete when:
1. The newer checkpoint exist (usual meaning)
2. More that N % of nodes, referred by the checkpoint are disappeared
since were Garbage Collected.
I dreamed about checkpoints which we may write only once for constant
files (for example, glibc libraries) ....
So, this problem is solvable I believe, but no I'm not quite sure are
checkpoints will be so useful as I thought ...
-- Best
Regards, Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-11-16 14:21 ` your mail Artem B. Bityuckiy
@ 2004-11-16 14:29 ` David Woodhouse
2004-11-16 14:54 ` Artem B. Bityuckiy
0 siblings, 1 reply; 669+ messages in thread
From: David Woodhouse @ 2004-11-16 14:29 UTC (permalink / raw)
To: Artem B. Bityuckiy; +Cc: MTD List
On Tue, 2004-11-16 at 14:21 +0000, Artem B. Bityuckiy wrote:
> I dreamed about checkpoints which we may write only once for constant
> files (for example, glibc libraries) ....
>
> So, this problem is solvable I believe, but no I'm not quite sure are
> checkpoints will be so useful as I thought ...
Hm. I was imagining that we'd read in the information from the
checkpoint, and then pull in anything _new_ -- which would include any
nodes which weren't included in the checkpoint.
--
dwmw2
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-11-16 14:29 ` David Woodhouse
@ 2004-11-16 14:54 ` Artem B. Bityuckiy
2004-11-16 15:03 ` David Woodhouse
0 siblings, 1 reply; 669+ messages in thread
From: Artem B. Bityuckiy @ 2004-11-16 14:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: MTD List
On Tue, 16 Nov 2004, David Woodhouse wrote:
> On Tue, 2004-11-16 at 14:21 +0000, Artem B. Bityuckiy wrote:
> > I dreamed about checkpoints which we may write only once for constant
> > files (for example, glibc libraries) ....
> >
> > So, this problem is solvable I believe, but no I'm not quite sure are
> > checkpoints will be so useful as I thought ...
>
> Hm. I was imagining that we'd read in the information from the
> checkpoint, and then pull in anything _new_ -- which would include any
> nodes which weren't included in the checkpoint.
Yes. But imagine some file which is constant and is never changed. We
create checkpoint for it and this checkpoint covers all the nodes. So, we
will need to rewrite new checkpoint even for this file when its nodes are
garbage collected...
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-11-16 14:54 ` Artem B. Bityuckiy
@ 2004-11-16 15:03 ` David Woodhouse
2004-11-16 15:09 ` Artem B. Bityuckiy
0 siblings, 1 reply; 669+ messages in thread
From: David Woodhouse @ 2004-11-16 15:03 UTC (permalink / raw)
To: Artem B. Bityuckiy; +Cc: MTD List
On Tue, 2004-11-16 at 14:54 +0000, Artem B. Bityuckiy wrote:
> Yes. But imagine some file which is constant and is never changed. We
> create checkpoint for it and this checkpoint covers all the nodes. So, we
> will need to rewrite new checkpoint even for this file when its nodes are
> garbage collected...
Yeah. In particular we'd nee to rewrite a new checkpoint when the block
containing the old checkpoint was garbage-collected anyway.
--
dwmw2
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-11-16 15:03 ` David Woodhouse
@ 2004-11-16 15:09 ` Artem B. Bityuckiy
0 siblings, 0 replies; 669+ messages in thread
From: Artem B. Bityuckiy @ 2004-11-16 15:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: MTD List
On Tue, 16 Nov 2004, David Woodhouse wrote:
> On Tue, 2004-11-16 at 14:54 +0000, Artem B. Bityuckiy wrote:
> > Yes. But imagine some file which is constant and is never changed. We
> > create checkpoint for it and this checkpoint covers all the nodes. So, we
> > will need to rewrite new checkpoint even for this file when its nodes are
> > garbage collected...
>
> Yeah. In particular we'd nee to rewrite a new checkpoint when the block
> containing the old checkpoint was garbage-collected anyway.
>
Hmm, do not get it why. Why we need this? We may just copu old checkpoint
inact I believe. What happen If we do this?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-09-19 12:29 plt
2004-09-19 18:22 ` your mail Jesper Juhl
0 siblings, 1 reply; 669+ messages in thread
From: plt @ 2004-09-19 12:29 UTC (permalink / raw)
To: linux-kernel
Question: Are you guys going to work on please cleaning up some of the errors in
the code so we can get please get a more clean compile?
drivers/mtd/nftlmount.c:44: warning: unused variable `oob'
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-09-19 12:29 plt
@ 2004-09-19 18:22 ` Jesper Juhl
0 siblings, 0 replies; 669+ messages in thread
From: Jesper Juhl @ 2004-09-19 18:22 UTC (permalink / raw)
To: plt; +Cc: linux-kernel
On Sun, 19 Sep 2004 plt@taylorassociate.com wrote:
> Question: Are you guys going to work on please cleaning up some of the errors in
> the code so we can get please get a more clean compile?
>
I think it's safe to say that there is an ongoing effort to do that.
Some more strict typechecking has recently been introduced (read more
here: http://kerneltrap.org/node/view/3848 ) and this currently cause a
lot of compiler warnings that have yet to be cleaned, but that will happen
in time - faster if you lend a hand.
>
> drivers/mtd/nftlmount.c:44: warning: unused variable `oob'
>
This is due to the fact that the code using that variable is currently
within an #if 0 block. I am not familiar with the mtd code, but the
comment in there has this to say :
#if 0 /* Some people seem to have devices without ECC or erase marks
on the Media Header blocks. There are enough other sanity
checks in here that we can probably do without it.
*/
...
#endif
So it would seem that this bit of code could be on its way out. I'd assume
that once it goes (if it does) that the variable will then be removed as
well.
Ohh and btw, if you want people to pay attention to your emails you should
try adding a descriptive Subject: :)
--
Jesper Juhl
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2004-08-24 6:05 Francisco M. Marzoa Alonso
2004-08-24 9:39 ` your mail Jan-Benedict Glaw
0 siblings, 1 reply; 669+ messages in thread
From: Francisco M. Marzoa Alonso @ 2004-08-24 6:05 UTC (permalink / raw)
To: linux-serial
>> TOut.tv_sec = Wait / 1000;
>> TOut.tv_usec = Wait % 1000;
>
>So "Wait" is in milli-seconds? That doesn't look correct, then:)
>
> TOut.tv_sec = Wait / 1000;
> TOut.tv_usec = (Wait % 1000) * 1000;
Sure you're right, but this is a thing that I do not understand. I made a
function GetTickCount to emulate Window's one based on gettimeofday and see
that milliseconds on timeval structure can have values up to 999999 when I
expect to found a maximum value of 999 as there are only 1000 milliseconds in
a second.
>> if ( select ( FD_SETSIZE, &readfs, NULL, NULL, &TOut ) ) {
>That's most probably wrong. "FD_SETSIZE" should be "HND + 1". ...and the
>"if" should fire like "if (select (...) > 0)"
Ok, I've tried some different values, I'll use only HND+1 from now.
>This could hand because you didn't select() on HND *before* writing to
>it.
You're right. I've fixed this.
>> if ( ! select ( FD_SETSIZE, NULL, &writefs, NULL, &TOut ) ) {
>> perror ( "Timeout waiting on CommWriteChar");
>> return 0;
>> }
>select() checks if the next access won't hand (but may return
>successfull or with an error instead). It doesn't make much sense to do
>that *after* having something written down there:)
>> return ( bcount );
>> }
>Btw: return isn't a function. It's return value doesn't need an own pair
>of parentheses.
I usually forget this, but I think this makes no efective difference and the
code generated by the compiler is the same and I feel more comfortable using
them.
I've done this changes, that I've no doubt that are needed, but I continue
having the same problems as described in my previous e-mail.
Thanks a lot.
--
Francisco M. Marzoa Alonso
Responsable de Software - Softrónica S.A.
http://www.softronica.org/
C/Herrerías, 14 - 28760 Tres Cantos (Madrid)
tfno. +34 918 038 600 fax. +34 918 032 297
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2004-08-24 6:05 (unknown) Francisco M. Marzoa Alonso
@ 2004-08-24 9:39 ` Jan-Benedict Glaw
0 siblings, 0 replies; 669+ messages in thread
From: Jan-Benedict Glaw @ 2004-08-24 9:39 UTC (permalink / raw)
To: Francisco M. Marzoa Alonso; +Cc: linux-serial
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
On Tue, 2004-08-24 08:05:08 +0200, Francisco M. Marzoa Alonso <fmmarzoa@softronica.org>
wrote in message <200408240805.08811.fmmarzoa@softronica.org>:
> >> TOut.tv_sec = Wait / 1000;
> >> TOut.tv_usec = Wait % 1000;
> >
> >So "Wait" is in milli-seconds? That doesn't look correct, then:)
> >
> > TOut.tv_sec = Wait / 1000;
> > TOut.tv_usec = (Wait % 1000) * 1000;
>
> Sure you're right, but this is a thing that I do not understand. I made a
> function GetTickCount to emulate Window's one based on gettimeofday and see
> that milliseconds on timeval structure can have values up to 999999 when I
> expect to found a maximum value of 999 as there are only 1000 milliseconds in
> a second.
Notice, it's not "tv_msec" but "tv_usec", which is micro-seconde and
not milli-seconds. A small 'u' is commonly used instead of the greek
'µ', because 'µ' won't be properly handled by all email clients, let
alone in code to be compiled.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2004-08-16 15:42 Jon Smirl
2004-08-16 23:55 ` Dave Airlie
0 siblings, 1 reply; 669+ messages in thread
From: Jon Smirl @ 2004-08-16 15:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel, Dave Airlie
Graphics drivers in the kernel are broken. The kernel was never
designed to have two device drivers trying to control the same piece of
hardware.
I have posted a long list of 25 points that we are working towards to
unify things. http://lkml.org/lkml/2004/8/2/111 The PCI ROM patch that
has been posted recently addresses the first one.
In the meanwhile we have to transition somehow between what we have and
where we are going. Since fbdev has taken the path to pretend that DRM
doesn't exist DRM has to go through a lot of trouble to work when fbdev
is in the system. DRM also has to work when fbdev is not in the system.
DRM is being reworked into a first class driver with full support for
2.6 and hotplug. Part of being a first class driver means that DRM has
to register itself with the kernel like a real driver and claim all of
it's resources. I'm also fixing the driver to use 2.6 module parameters
and to support dynamic assignment of minors. Sysfs support is in the
patch being discussed.
But DRM still has to live with existing fbdev drivers. The same DRM
code is used in 2.4 and 2.6 so existing fbdev drivers are not going
away anytime soon. When DRM detects a fbdev it will revert back into
stealth mode where is attaches itself to the hardware without telling
the kernel that it is doing so. DRM can not use stealth mode when
running without fbdev present since it will mess up hotplug by not
marking the resources in use.
I don't believe the ordering between fbdev and DRM is an issue. If you
are using fbdev you likely have it compiled in. In that case fbdev
always loads first and DRM second. In the non-ppc world, most of us
have x86 boxes which don't use fbdev. In those machines DRM needs to be
a first class driver. In the real world I don't know anyone other than
a developer who would load DRM first and then fbdev. If this is a
problem you will need to fixed fbdev to fall back into stealth mode
like DRM does.
I would like to encourage you to work towards the points on the above
referenced list. It has been widely distributed and commented on. It
has been posted to lkml, dri-dev, fb-dev and xorg lists and discussed
at OLS.
Sorry, but I can't add an In-Reply-To header in the middle of thread on
yahoo. cc me on a reply to the main thread so that I will pick up the header.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 15:42 Jon Smirl
@ 2004-08-16 23:55 ` Dave Airlie
0 siblings, 0 replies; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 23:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
> But DRM still has to live with existing fbdev drivers. The same DRM
> code is used in 2.4 and 2.6 so existing fbdev drivers are not going
> away anytime soon. When DRM detects a fbdev it will revert back into
> stealth mode where is attaches itself to the hardware without telling
> the kernel that it is doing so. DRM can not use stealth mode when
> running without fbdev present since it will mess up hotplug by not
> marking the resources in use.
>
> I don't believe the ordering between fbdev and DRM is an issue. If you
> are using fbdev you likely have it compiled in. In that case fbdev
> always loads first and DRM second. In the non-ppc world, most of us
> have x86 boxes which don't use fbdev. In those machines DRM needs to be
> a first class driver. In the real world I don't know anyone other than
> a developer who would load DRM first and then fbdev. If this is a
> problem you will need to fixed fbdev to fall back into stealth mode
> like DRM does.
This is a good point, we are being forced into stealth mode by the fb
driver if they want to load after us they should respsect us and do the
same, (nope this isn't an us and them, DRM vs fb - I think we have a
solution and are heading the correct direction)...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-08-15 12:19 Dave Airlie
2004-08-15 12:34 ` your mail Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Dave Airlie @ 2004-08-15 12:19 UTC (permalink / raw)
To: torvalds, Andrew Morton; +Cc: linux-kernel
Hi Linus/Andrew,
I'd like to merge up the DRM tree to the stable branch, these patches have
been in -mm since I added them, they include a new i915 drm from Tungsten
Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
(it falls back if framebuffer is enabled...), the next DRM changes are
lined up on a CVS branch - they start detemplating the DRM...
Please do a
bk pull bk://drm.bkbits.net/drm-2.6
This will include the latest DRM changes and will update the following files:
drivers/char/drm/Kconfig | 17
drivers/char/drm/Makefile | 2
drivers/char/drm/drm.h | 4
drivers/char/drm/drmP.h | 18
drivers/char/drm/drm_bufs.h | 1
drivers/char/drm/drm_drv.h | 188 ++++++---
drivers/char/drm/drm_ioctl.h | 2
drivers/char/drm/drm_os_linux.h | 4
drivers/char/drm/drm_pciids.h | 8
drivers/char/drm/drm_proc.h | 17
drivers/char/drm/drm_stub.h | 201 +++++++---
drivers/char/drm/gamma_old_dma.h | 69 ++-
drivers/char/drm/i810_dma.c | 7
drivers/char/drm/i830_dma.c | 12
drivers/char/drm/i915.h | 95 ++++
drivers/char/drm/i915_dma.c | 760 +++++++++++++++++++++++++++++++++++++++
drivers/char/drm/i915_drm.h | 162 ++++++++
drivers/char/drm/i915_drv.c | 31 +
drivers/char/drm/i915_drv.h | 228 +++++++++++
drivers/char/drm/i915_irq.c | 173 ++++++++
drivers/char/drm/i915_mem.c | 361 ++++++++++++++++++
drivers/char/drm/sis_mm.c | 7
22 files changed, 2194 insertions(+), 173 deletions(-)
through these ChangeSets:
<airlied@starflyer.(none)> (04/08/02 1.1823)
Fix up multiple devices issues with creating /proc/dri/
From: Jon Smirl
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/08/02 1.1822)
add hotplug support function
From: Jon Smirl
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/08/02 1.1821)
fixup prototype..
<airlied@starflyer.(none)> (04/07/31 1.1820)
switch to using i915_dma_cleanup as this conflicts on BSD builds..
<airlied@starflyer.(none)> (04/07/31 1.1819)
sparse: use of user space pointer in kernel...
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/31 1.1818)
sparse: 0->NULL conversions.
From: Dave Airlie
<airlied@starflyer.(none)> (04/07/31 1.1817)
the patch below optimises the drm code to not do put_user() on memory the
kernel allocated and then mmap-installed to userspace, but instead makes it
use the kernel virtual address directly instead.
From: Arjan van de Ven <arjanv@redhat.com>
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/26 1.1816)
ATI Rage 128 and Radeon DRM unconditionally depend on PCI
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
<airlied@starflyer.(none)> (04/07/26 1.1815)
Correct a couple of packet length calculations. - keithw
<airlied@starflyer.(none)> (04/07/25 1.1814)
define user if not already.. this isn't needed in kernel but for building against the kernel headers it is ...
<airlied@starflyer.(none)> (04/07/25 1.1813)
sync up device/driver tracking with CVS,
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/25 1.1812)
fix whitespace on tabbing
<airlied@starflyer.(none)> (04/07/25 1.1811)
add some annotations Als patch missed
add annotations for i915 driver
<airlied@starflyer.(none)> (04/07/25 1.1810)
add missing prototype
<airlied@starflyer.(none)> (04/07/25 1.1809)
fixup annotation
<airlied@starflyer.(none)> (04/07/25 1.1808)
patch from Tom Arbuckle for missing bus_address
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/20 1.1807)
use NULLs instead of 0s
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/20 1.1806)
fixup drm_stub so it works with two-headed cards properly...
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/15 1.1784.4.6)
Add new i915 driver from Tungsten Graphics Inc. This driver covers the i830
chipsets also, a new X 2D + 3D driver are needed to use this but they have
been integrated into at least the X.org tree at this point and I think the
XFree86 tree. There are probably a few cleanups necessary for this driver.
From: Keith Whitwell <keith@tungstengraphics.com>
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/15 1.1784.4.5)
Fix issue with keeping count of registered DRMs with new driver model
Submitted-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/06 1.1784.4.4)
changes for better hotplug and proper PCI device support from Jon Smirl and
Dave Airlie, along with a big fix from Paul Mackerras.
Note: these are complex due to the need for the DRM to fallback if the
framebuffer driver has already taken the device.
These changes have been in the DRM CVS tree for about 3 months, style
comments are appreciated...
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-15 12:19 Dave Airlie
@ 2004-08-15 12:34 ` Christoph Hellwig
2004-08-15 23:40 ` Dave Airlie
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-15 12:34 UTC (permalink / raw)
To: Dave Airlie; +Cc: torvalds, Andrew Morton, linux-kernel
On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> (it falls back if framebuffer is enabled...),
Can you explain what this means?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-15 12:34 ` your mail Christoph Hellwig
@ 2004-08-15 23:40 ` Dave Airlie
2004-08-16 9:17 ` Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Dave Airlie @ 2004-08-15 23:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
> On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> > Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> > (it falls back if framebuffer is enabled...),
>
> Can you explain what this means?
>
Probably should say PCI APIs properly, it now does enable/disable devices
and registers the DRM as owning the memory regions, does proper PCI
probing .. in cases where the fb is loaded on the card already it falls
back to the old ways (evil direct register writing.. ), this change will
stop you loading the fb driver adter the drm driver but this shouldn't be
a common case at all..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-15 23:40 ` Dave Airlie
@ 2004-08-16 9:17 ` Christoph Hellwig
2004-08-16 9:30 ` Dave Airlie
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-16 9:17 UTC (permalink / raw)
To: Dave Airlie; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 12:40:43AM +0100, Dave Airlie wrote:
> Probably should say PCI APIs properly, it now does enable/disable devices
> and registers the DRM as owning the memory regions, does proper PCI
> probing .. in cases where the fb is loaded on the card already it falls
> back to the old ways (evil direct register writing.. ), this change will
> stop you loading the fb driver adter the drm driver but this shouldn't be
> a common case at all..
Eeek, doing different styles of probing is even worse than what you did
before. Please revert to pci_find_device() util you havea proper common
driver ready.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 9:17 ` Christoph Hellwig
@ 2004-08-16 9:30 ` Dave Airlie
2004-08-16 9:50 ` Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 9:30 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
>
> Eeek, doing different styles of probing is even worse than what you did
> before. Please revert to pci_find_device() util you havea proper common
> driver ready.
There was nothing wrong with what we did before it just happened to work
like 2.4. we are now acting like real 2.6 drivers, which we need to do for
sysfs and hotplug to work, Jon Smirl is working on a proper minor device
support (like USB does I think)... we need to get this work done before we
can have proper common drivers and I don't want to do all this work in
hiding and then have it refused because we told no-one,
The DRM will flux a lot over the next while (while we get this common
drm/fb stuff together) and as long as we can keep the changes from
actually breaking it I think people should be able to live with it ...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 9:30 ` Dave Airlie
@ 2004-08-16 9:50 ` Christoph Hellwig
2004-08-16 10:29 ` Dave Airlie
2004-08-16 11:12 ` Alan Cox
0 siblings, 2 replies; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-16 9:50 UTC (permalink / raw)
To: Dave Airlie; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 10:30:55AM +0100, Dave Airlie wrote:
> >
> > Eeek, doing different styles of probing is even worse than what you did
> > before. Please revert to pci_find_device() util you havea proper common
> > driver ready.
>
> There was nothing wrong with what we did before it just happened to work
> like 2.4. we are now acting like real 2.6 drivers,
no, now you're acting like an even more broken driver, preventing a fbdev
driver to be loaded afterwards and doing all kinds of funny things. Please
revert to the old method until you have a common pci_driver for fbdev and dri.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 9:50 ` Christoph Hellwig
@ 2004-08-16 10:29 ` Dave Airlie
2004-08-16 10:38 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
1 sibling, 1 reply; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 10:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
>
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things. Please
> revert to the old method until you have a common pci_driver for fbdev and dri.
>
the options we have are
1) move the DRM to be a real PCI driver now - stop fb from working on same
card
2) move the DRM to act like a real PCI driver when fb isn't loaded, when
we merge we rip the code out..
the other option is not going to happen unless Linus/Andrew/Alan tell us
to go away do it that away and will then unconditionally merge a
mega-patch when I'm finished - you can't have it both ways we fix things
step-by-step or we leave it as is and nobody fixes it, so Christoph I
repsect your opinion but unless you care about this enough to do the work
on it, the way we are going seems to be the best way to avoid breaking
things and I'm leaving the decision on whether to merge this stuff or not
to Linus/Andrew - btw in case anyone wants to look the patch is whats at:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc4/2.6.8-rc4-mm1/broken-out/bk-drm.patch
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 10:29 ` Dave Airlie
@ 2004-08-16 10:38 ` Christoph Hellwig
2004-08-16 11:02 ` Dave Airlie
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-16 10:38 UTC (permalink / raw)
To: Dave Airlie; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 11:29:48AM +0100, Dave Airlie wrote:
> 1) move the DRM to be a real PCI driver now - stop fb from working on same
> card
>
> 2) move the DRM to act like a real PCI driver when fb isn't loaded, when
> we merge we rip the code out..
3) stop making broken changes.
You do stop fb from beeing loaded after drm
and thus break perfectly working setups during stable series. And you
introduce indeterministic behaviour, and although I haven't looked at the
code because unlike every guideline tells you you didn't post it to do the
list, probably horribly broken code.
If you want pci_driver semantics - and apparently you do - move fbdev
and drm into a common driver or introduce a stub. This was discussed to
death and all kinds of list and Kernel Summit and now please follow what
was agreed on instead of introducing subtile hacks.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 10:38 ` Christoph Hellwig
@ 2004-08-16 11:02 ` Dave Airlie
2004-08-16 11:08 ` Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 11:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
>
> 3) stop making broken changes.
The current system is broken in way more subtle ways...
> You do stop fb from beeing loaded after drm
> and thus break perfectly working setups during stable series. And you
I doubt anyone has a system that does it and they should have a broken one
if they do it.. drm has also said you should load fb before it.. and
having both fb and drm loaded on the same hardware is a hack anyways..
> introduce indeterministic behaviour, and although I haven't looked at the
> code because unlike every guideline tells you you didn't post it to do the
> list, probably horribly broken code.
I just did post it, it's been in the DRM CVS tree for 3-6 mths now, it's
been in -mm for 1.5 mths, I've followed what Andrew and Linus told me to
do to get the DRM maintained... the link I posted in the last mail to the
broken out patch in the -mm tree, the only file to change is really
drm_drv.h and some bits in drm_stub.h... the current code is we have
discovered horribly broken in a lot of cases.. I've gotten nothing back to
say this code is any worse....
> If you want pci_driver semantics - and apparently you do - move fbdev
> and drm into a common driver or introduce a stub. This was discussed to
> death and all kinds of list and Kernel Summit and now please follow what
> was agreed on instead of introducing subtile hacks.
Yes and that is the final goal but you are dodging the point we cannot
jump to a fully finished state in one simple transition, it is great to
hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
it must be simple, well its not and we are taking the route that should
affect the least people, I'm majorly involved in the discussion and I was
the one to agree to carry out the maintenance paths between DRM and LK,
this code is needed for us to move forward with the merged drivers - if
Linus/Andrew decide not to merge it I'll go back to the DRM team and it'll
be reworked until they do accept it, but we have to stop the fb from
loading after the DRM at some stage and it may as well be earlier.. (if
2.7 was going to happen I'd wait but kernel development seems to be
changing...)
You seem to want us to go down the finished unmergeable mega-patch road
to avoid breaking something that is broken and might work, the benefits
don't outweight the costs.. so it makes no sense..
Again if Linus/Andrew bounce this we will have to rework it but something
like this has to go in at some stage...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 11:02 ` Dave Airlie
@ 2004-08-16 11:08 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
2004-08-16 11:47 ` Dave Airlie
0 siblings, 2 replies; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-16 11:08 UTC (permalink / raw)
To: Dave Airlie; +Cc: torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 12:02:15PM +0100, Dave Airlie wrote:
> > You do stop fb from beeing loaded after drm
> > and thus break perfectly working setups during stable series. And you
>
> I doubt anyone has a system that does it and they should have a broken one
> if they do it.. drm has also said you should load fb before it.. and
> having both fb and drm loaded on the same hardware is a hack anyways..
So fix it properly instead of making it even more broken.
> Yes and that is the final goal but you are dodging the point we cannot
> jump to a fully finished state in one simple transition, it is great to
> hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> it must be simple, well its not and we are taking the route that should
It _is+ simple. Look at drivers/message/fusion/ for a driver doing multiple
protocol on a single pci_driver. I don't demand full-blown memory management
integration or anything pother fancy. Just get your crap sorted out.
ou could propably have done a prototype in the time you wasted arguing here.
> You seem to want us to go down the finished unmergeable mega-patch road
> to avoid breaking something that is broken and might work, the benefits
> don't outweight the costs.. so it makes no sense..
I want you a) to back out this particular broken change in your current
mega-patch. and b) submit small reviewable changes in the future, as every
other driver maintainer does.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 11:08 ` Christoph Hellwig
@ 2004-08-16 11:12 ` Alan Cox
2004-08-16 11:47 ` Dave Airlie
1 sibling, 0 replies; 669+ messages in thread
From: Alan Cox @ 2004-08-16 11:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Airlie, torvalds, Andrew Morton, Linux Kernel Mailing List
On Llu, 2004-08-16 at 12:08, Christoph Hellwig wrote:
> I want you a) to back out this particular broken change in your current
> mega-patch. and b) submit small reviewable changes in the future, as every
> other driver maintainer does.
DRI is done as small reviewable changes. If you want to be involved then
follow the DRI list too or ask for the entire list to be gated to
linux-kernel for your pleasure...
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 11:08 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
@ 2004-08-16 11:47 ` Dave Airlie
1 sibling, 0 replies; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 11:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
> > Yes and that is the final goal but you are dodging the point we cannot
> > jump to a fully finished state in one simple transition, it is great to
> > hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> > it must be simple, well its not and we are taking the route that should
>
> It _is+ simple. Look at drivers/message/fusion/ for a driver doing multiple
> protocol on a single pci_driver. I don't demand full-blown memory management
> integration or anything pother fancy. Just get your crap sorted out.
>
> ou could propably have done a prototype in the time you wasted arguing here.
we could write one quick enough for one card but now make it work on
combinations of mach64/i810/radeon/r128/i830/i915/mga cards and tested so
that it doesn't break current setups, its just not going to happen, this
change doesn't break near as many setups (I'd be surprised if it broke any
real world setups at all...) I don't have the hardware to test this on all
those cards, the hope is to get the DRM into a state that we can start
proving the shared idea on one card.. it will also make changes to fb
drivers which I'm not comfortable with doing and will cause more hassles..
> I want you a) to back out this particular broken change in your current
> mega-patch. and b) submit small reviewable changes in the future, as every
> other driver maintainer does.
I'm considering your argument and have taken it on-board, I await Linus's
decision for now, I'll start looking into the info you've given me and
I'll talk to the DRM people actually doing the work (not one line of this
is orignally from me!!..)
All DRM changes are available in small chunks in DRM CVS and DRM bk trees,
the -mm tree picks up the DRM changes and I fix the bugs that come up in
the -mm tree and then I submit the bk tree to Linus, I thought this was
how kernel development worked these days,
The patch you are against is
http://drm.bkbits.net:8080/drm-2.6/patch@1.1784.4.4?nav=index.html|tags|ChangeSet@1.1722.154.18..|cset@1.1784.4.4
with a couple of bugfixes on top of it from testing in -mm.. if I'm
missing the kernel development process somehow please inform me.. I'm new
to this maintainer job and the drm hasn't been maintained in years so I'm
not starting from a good place...
Thanks,
Dave.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 9:50 ` Christoph Hellwig
2004-08-16 10:29 ` Dave Airlie
@ 2004-08-16 11:12 ` Alan Cox
2004-08-16 12:20 ` Christoph Hellwig
1 sibling, 1 reply; 669+ messages in thread
From: Alan Cox @ 2004-08-16 11:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Airlie, torvalds, Andrew Morton, Linux Kernel Mailing List
On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things. Please
> revert to the old method until you have a common pci_driver for fbdev and dri.
fbdev and DRI are not functional together in the general case. They
sometimes happen to work by luck. fbdev and X for that matter are
generally incompatible except unaccelerated.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 11:12 ` Alan Cox
@ 2004-08-16 12:20 ` Christoph Hellwig
2004-08-16 12:24 ` Dave Airlie
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-16 12:20 UTC (permalink / raw)
To: Alan Cox
Cc: Christoph Hellwig, Dave Airlie, torvalds, Andrew Morton,
Linux Kernel Mailing List
On Mon, Aug 16, 2004 at 12:12:00PM +0100, Alan Cox wrote:
> On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> > no, now you're acting like an even more broken driver, preventing a fbdev
> > driver to be loaded afterwards and doing all kinds of funny things. Please
> > revert to the old method until you have a common pci_driver for fbdev and dri.
>
> fbdev and DRI are not functional together in the general case. They
> sometimes happen to work by luck. fbdev and X for that matter are
> generally incompatible except unaccelerated.
Works fine on all my pmacs here. In fact X works only on fbdev for
full features.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 12:20 ` Christoph Hellwig
@ 2004-08-16 12:24 ` Dave Airlie
2004-08-16 12:37 ` Christoph Hellwig
0 siblings, 1 reply; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 12:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alan Cox, torvalds, Andrew Morton, Linux Kernel Mailing List
>
> Works fine on all my pmacs here. In fact X works only on fbdev for
> full features.
I think Alan would classify that as luck rathar than design... and I would
tend to agree, does it work if you load the driver modules in any order?
or do you always to fb then drm? or the other way around?
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 12:24 ` Dave Airlie
@ 2004-08-16 12:37 ` Christoph Hellwig
2004-08-16 23:33 ` Dave Airlie
0 siblings, 1 reply; 669+ messages in thread
From: Christoph Hellwig @ 2004-08-16 12:37 UTC (permalink / raw)
To: Dave Airlie
Cc: Christoph Hellwig, Alan Cox, torvalds, Andrew Morton,
Linux Kernel Mailing List
On Mon, Aug 16, 2004 at 01:24:30PM +0100, Dave Airlie wrote:
> >
> > Works fine on all my pmacs here. In fact X works only on fbdev for
> > full features.
>
> I think Alan would classify that as luck rathar than design... and I would
All the fbdev handling code in X is also an accident?
Really, why do you even push for this change if the better fix isn't that
far away. Send the i915 driver and the other misc cleanups to Linus now
and get a proper graphics stub driver done, it's not that much work. I'll
hack up the fbdev side once I'll get a little time, but the drm code is
far to disgusting to touch, sorry.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-08-16 12:37 ` Christoph Hellwig
@ 2004-08-16 23:33 ` Dave Airlie
0 siblings, 0 replies; 669+ messages in thread
From: Dave Airlie @ 2004-08-16 23:33 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alan Cox, torvalds, Andrew Morton, Linux Kernel Mailing List
>
> All the fbdev handling code in X is also an accident?
I've no idea I've nothing to do with X... but the fact that graphics work
at all with fb/drm/X is by no fault of any design it is pure hack ...
> Really, why do you even push for this change if the better fix isn't that
> far away. Send the i915 driver and the other misc cleanups to Linus now
> and get a proper graphics stub driver done, it's not that much work. I'll
> hack up the fbdev side once I'll get a little time, but the drm code is
> far to disgusting to touch, sorry.
It means writing 6 or 7 stub drivers, for cards we don't have, it means
making PCI probing different for some fbdev drivers and some DRM drivers
(e.g. the i915 doesn't have a framebuffer driver in 2.6 so do I write a
stub on the chance that someone writes an fb driver for it? - why do this
when the DRM will start encompassing the fb soon..) it is a lot of work
that we intend throwing away, the final solution is not to merge DRM/fb
via a stub, it is to create a single driver for each card, what happens
when the DRM starts doing memory management and 2d stuff.. we won't want
fb to be able to load anymore as it will break the DRM...I see Jon Smirl
has found the thread, please discuss with him as he was the one doing all
the legwork at the kernel summit...
again this doesn't break any real setups, it is the path of least
resistance as it doesn't affect fb drivers, why should DRM be a second
class citizen, when it is clearly going to have to be a first class 2.6
driver to do its job... if you can find someone with a real world setup
that this breaks I'll consider it a really bad idea... but I think Jon has
made his point far better than I...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2004-05-24 23:15 Laughlin, Joseph V
0 siblings, 0 replies; 669+ messages in thread
From: Laughlin, Joseph V @ 2004-05-24 23:15 UTC (permalink / raw)
To: Bernd Petrovitsch, linux-kernel
> -----Original Message-----
> From: Bernd Petrovitsch [mailto:bernd@firmix.at]
> Sent: Monday, May 24, 2004 4:13 PM
> To: Laughlin, Joseph V; linux-kernel@vger.kernel.org
> Subject: RE: your mail
>
>
> On Tue, 2004-05-25 at 01:04, Laughlin, Joseph V wrote:
> > > -----Original Message-----
> [...]
> > > On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin,
> Joseph V wrote:
> > > > I've been tasked with modifying a 2.4 kernel so that a
> > > non-root user
> > > > can do the following:
> > > >
> > > > Dynamically change the priorities of processes (up and
> down) Lock
> > > > processes in memory Can change process cpu affinity
> [...]
> > Currently, we're using sched_setaffinity() to control it, which
> > existed in our 2.4.19 kernel. (but, you have to be root to use it,
> > and we'd like non-root users to be able to change the affinity.)
>
> And using sudo or setuid Binaries?
>
> Bernd
> --
Not an option, unfortunately.
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2004-05-24 23:04 Laughlin, Joseph V
2004-05-24 23:13 ` Bernd Petrovitsch
2004-05-24 23:21 ` Chris Wright
0 siblings, 2 replies; 669+ messages in thread
From: Laughlin, Joseph V @ 2004-05-24 23:04 UTC (permalink / raw)
To: Herbert Poetzl; +Cc: linux-kernel
> -----Original Message-----
> From: Herbert Poetzl [mailto:herbert@13thfloor.at]
> Sent: Monday, May 24, 2004 3:30 PM
> To: Laughlin, Joseph V
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
>
> On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> > I've been tasked with modifying a 2.4 kernel so that a
> non-root user
> > can do the following:
> >
> > Dynamically change the priorities of processes (up and down) Lock
> > processes in memory Can change process cpu affinity
> >
> > Anyone got any ideas about how I could start doing this?
> (I'm new to
> > kernel development, btw.)
>
> check the kernel capability system ...
> (it's quite simple)
>
> #define CAP_SYS_NICE 23
> #define CAP_IPC_LOCK 14
>
> cpu scheduler affinity isn't part of 2.4 AFAIK
> so there is no easy way to 'control' it ...
>
Currently, we're using sched_setaffinity() to control it, which existed
in our 2.4.19 kernel. (but, you have to be root to use it, and we'd
like non-root users to be able to change the affinity.)
Joe
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
2004-05-24 23:04 Laughlin, Joseph V
@ 2004-05-24 23:13 ` Bernd Petrovitsch
2004-05-24 23:21 ` Chris Wright
1 sibling, 0 replies; 669+ messages in thread
From: Bernd Petrovitsch @ 2004-05-24 23:13 UTC (permalink / raw)
To: Laughlin, Joseph V, linux-kernel
On Tue, 2004-05-25 at 01:04, Laughlin, Joseph V wrote:
> > -----Original Message-----
[...]
> > On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> > > I've been tasked with modifying a 2.4 kernel so that a
> > non-root user
> > > can do the following:
> > >
> > > Dynamically change the priorities of processes (up and down) Lock
> > > processes in memory Can change process cpu affinity
[...]
> Currently, we're using sched_setaffinity() to control it, which existed
> in our 2.4.19 kernel. (but, you have to be root to use it, and we'd
> like non-root users to be able to change the affinity.)
And using sudo or setuid Binaries?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2004-05-24 23:04 Laughlin, Joseph V
2004-05-24 23:13 ` Bernd Petrovitsch
@ 2004-05-24 23:21 ` Chris Wright
1 sibling, 0 replies; 669+ messages in thread
From: Chris Wright @ 2004-05-24 23:21 UTC (permalink / raw)
To: Laughlin, Joseph V; +Cc: Herbert Poetzl, linux-kernel
* Laughlin, Joseph V (Joseph.V.Laughlin@boeing.com) wrote:
> Currently, we're using sched_setaffinity() to control it, which existed
> in our 2.4.19 kernel. (but, you have to be root to use it, and we'd
> like non-root users to be able to change the affinity.)
Sounds like it's patched in. And it likely doesn't require root per se,
but CAP_SYS_NICE (as the 2.6 code does).
So, you've got choices of how to disable those capability checks to do
what you want.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-05-24 22:20 Laughlin, Joseph V
2004-05-24 22:30 ` your mail Herbert Poetzl
2004-05-24 22:33 ` Chris Wright
0 siblings, 2 replies; 669+ messages in thread
From: Laughlin, Joseph V @ 2004-05-24 22:20 UTC (permalink / raw)
To: linux-kernel
I've been tasked with modifying a 2.4 kernel so that a non-root user can
do the following:
Dynamically change the priorities of processes (up and down)
Lock processes in memory
Can change process cpu affinity
Anyone got any ideas about how I could start doing this? (I'm new to
kernel development, btw.)
Thanks,
Joe Laughlin
Phantom Works - Integrated Technology Development Labs
The Boeing Company
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-05-24 22:20 Laughlin, Joseph V
@ 2004-05-24 22:30 ` Herbert Poetzl
2004-05-24 22:34 ` Marc-Christian Petersen
2004-05-24 22:33 ` Chris Wright
1 sibling, 1 reply; 669+ messages in thread
From: Herbert Poetzl @ 2004-05-24 22:30 UTC (permalink / raw)
To: Laughlin, Joseph V; +Cc: linux-kernel
On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> I've been tasked with modifying a 2.4 kernel so that a non-root user can
> do the following:
>
> Dynamically change the priorities of processes (up and down)
> Lock processes in memory
> Can change process cpu affinity
>
> Anyone got any ideas about how I could start doing this? (I'm new to
> kernel development, btw.)
check the kernel capability system ...
(it's quite simple)
#define CAP_SYS_NICE 23
#define CAP_IPC_LOCK 14
cpu scheduler affinity isn't part of 2.4 AFAIK
so there is no easy way to 'control' it ...
HTH,
Herbert
> Thanks,
>
> Joe Laughlin
> Phantom Works - Integrated Technology Development Labs
> The Boeing Company
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-05-24 22:30 ` your mail Herbert Poetzl
@ 2004-05-24 22:34 ` Marc-Christian Petersen
0 siblings, 0 replies; 669+ messages in thread
From: Marc-Christian Petersen @ 2004-05-24 22:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Herbert Poetzl, Laughlin, Joseph V
On Tuesday 25 May 2004 00:30, Herbert Poetzl wrote:
Hi Joseph,
> > Dynamically change the priorities of processes (up and down)
> > Lock processes in memory
> > Can change process cpu affinity
> > Anyone got any ideas about how I could start doing this? (I'm new to
> > kernel development, btw.)
> check the kernel capability system ...
> (it's quite simple)
> #define CAP_SYS_NICE 23
> #define CAP_IPC_LOCK 14
> cpu scheduler affinity isn't part of 2.4 AFAIK
> so there is no easy way to 'control' it ...
at least I have a patch in my 2.4-tree where a user in a predefined GID
(changeable via /proc) can change his/her nice of his/her own processes up
and down.
ciao, Marc
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-05-24 22:20 Laughlin, Joseph V
2004-05-24 22:30 ` your mail Herbert Poetzl
@ 2004-05-24 22:33 ` Chris Wright
1 sibling, 0 replies; 669+ messages in thread
From: Chris Wright @ 2004-05-24 22:33 UTC (permalink / raw)
To: Laughlin, Joseph V; +Cc: linux-kernel
* Laughlin, Joseph V (Joseph.V.Laughlin@boeing.com) wrote:
> I've been tasked with modifying a 2.4 kernel so that a non-root user can
> do the following:
>
> Dynamically change the priorities of processes (up and down)
Requires CAP_SYS_NICE.
> Lock processes in memory
Currently requires CAP_IPC_LOCK. However, this one is already been
done using rlimits (at least via mlock() and friends, SHM_LOCK has
different issue).
> Can change process cpu affinity
Requires CAP_SYS_NICE (but I believe this was a 2.6 feature).
> Anyone got any ideas about how I could start doing this? (I'm new to
> kernel development, btw.)
There's a few approaches floating about. Probably the simplest is to
disable the checks globally, but this will also be less secure. I have
an example of this in 2.6 if you'd like.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-04-29 3:03 whitehorse
2004-04-29 3:21 ` your mail Jon
0 siblings, 1 reply; 669+ messages in thread
From: whitehorse @ 2004-04-29 3:03 UTC (permalink / raw)
To: linux-kernel
dear Sir,
I have a problem in compiling kernel 2.6.4 from kernel 2.4.19. I use
Debian woody. When I rebooting new kernel, some message occur such:
"modprobe: QM_MODULES: function not implemented"
and I can't load my modules when boot. I would like to waiting any one who
answer this. Please send to this mail. Thanks
Best regards,
Hafid
Indonesia
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-04-12 13:23 Denis Vlasenko
2004-04-13 13:46 ` your mail James Morris
0 siblings, 1 reply; 669+ messages in thread
From: Denis Vlasenko @ 2004-04-12 13:23 UTC (permalink / raw)
To: David S. Miller, netdev, jmorris, yoshfuji; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
According to my measurements,
ip_vs_control_add() (from include/net/ip_vs.h) is called twice
and
sock_queue_rcv_skb() (from include/net/sock.h) is called 19 times
from various kernel .c files.
Both these includes generate more than 500 bytes of code on x86.
These patches uninline them. Please apply.
--
vda
[-- Attachment #2: net_inline1.patch --]
[-- Type: text/x-diff, Size: 3711 bytes --]
diff -urN linux-2.6.5.orig/include/net/ip_vs.h linux-2.6.5.net_inline/include/net/ip_vs.h
--- linux-2.6.5.orig/include/net/ip_vs.h Mon Apr 12 15:42:10 2004
+++ linux-2.6.5.net_inline/include/net/ip_vs.h Mon Apr 12 15:46:43 2004
@@ -766,53 +766,8 @@
extern void ip_vs_random_dropentry(void);
extern int ip_vs_conn_init(void);
extern void ip_vs_conn_cleanup(void);
-
-static inline void ip_vs_control_del(struct ip_vs_conn *cp)
-{
- struct ip_vs_conn *ctl_cp = cp->control;
- if (!ctl_cp) {
- IP_VS_ERR("request control DEL for uncontrolled: "
- "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
- NIPQUAD(cp->caddr),ntohs(cp->cport),
- NIPQUAD(cp->vaddr),ntohs(cp->vport));
- return;
- }
-
- IP_VS_DBG(7, "DELeting control for: "
- "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
- NIPQUAD(cp->caddr),ntohs(cp->cport),
- NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
-
- cp->control = NULL;
- if (atomic_read(&ctl_cp->n_control) == 0) {
- IP_VS_ERR("BUG control DEL with n=0 : "
- "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
- NIPQUAD(cp->caddr),ntohs(cp->cport),
- NIPQUAD(cp->vaddr),ntohs(cp->vport));
- return;
- }
- atomic_dec(&ctl_cp->n_control);
-}
-
-static inline void
-ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp)
-{
- if (cp->control) {
- IP_VS_ERR("request control ADD for already controlled: "
- "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
- NIPQUAD(cp->caddr),ntohs(cp->cport),
- NIPQUAD(cp->vaddr),ntohs(cp->vport));
- ip_vs_control_del(cp);
- }
-
- IP_VS_DBG(7, "ADDing control for: "
- "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
- NIPQUAD(cp->caddr),ntohs(cp->cport),
- NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
-
- cp->control = ctl_cp;
- atomic_inc(&ctl_cp->n_control);
-}
+extern void ip_vs_control_del(struct ip_vs_conn *cp);
+extern void ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp);
/*
diff -urN linux-2.6.5.orig/net/ipv4/ipvs/ip_vs_core.c linux-2.6.5.net_inline/net/ipv4/ipvs/ip_vs_core.c
--- linux-2.6.5.orig/net/ipv4/ipvs/ip_vs_core.c Sun Apr 4 06:36:13 2004
+++ linux-2.6.5.net_inline/net/ipv4/ipvs/ip_vs_core.c Mon Apr 12 15:59:10 2004
@@ -199,6 +199,57 @@
return 1;
}
+
+void
+ip_vs_control_del(struct ip_vs_conn *cp)
+{
+ struct ip_vs_conn *ctl_cp = cp->control;
+ if (!ctl_cp) {
+ IP_VS_ERR("request control DEL for uncontrolled: "
+ "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
+ NIPQUAD(cp->caddr),ntohs(cp->cport),
+ NIPQUAD(cp->vaddr),ntohs(cp->vport));
+ return;
+ }
+
+ IP_VS_DBG(7, "DELeting control for: "
+ "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
+ NIPQUAD(cp->caddr),ntohs(cp->cport),
+ NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
+
+ cp->control = NULL;
+ if (atomic_read(&ctl_cp->n_control) == 0) {
+ IP_VS_ERR("BUG control DEL with n=0 : "
+ "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
+ NIPQUAD(cp->caddr),ntohs(cp->cport),
+ NIPQUAD(cp->vaddr),ntohs(cp->vport));
+ return;
+ }
+ atomic_dec(&ctl_cp->n_control);
+}
+
+
+void
+ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp)
+{
+ if (cp->control) {
+ IP_VS_ERR("request control ADD for already controlled: "
+ "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n",
+ NIPQUAD(cp->caddr),ntohs(cp->cport),
+ NIPQUAD(cp->vaddr),ntohs(cp->vport));
+ ip_vs_control_del(cp);
+ }
+
+ IP_VS_DBG(7, "ADDing control for: "
+ "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n",
+ NIPQUAD(cp->caddr),ntohs(cp->cport),
+ NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport));
+
+ cp->control = ctl_cp;
+ atomic_inc(&ctl_cp->n_control);
+}
+
+
/*
* IPVS persistent scheduling function
* It creates a connection entry according to its template if exists,
[-- Attachment #3: net_inline2.patch --]
[-- Type: text/x-diff, Size: 2731 bytes --]
diff -urN linux-2.6.5.orig/include/net/sock.h linux-2.6.5.net_inline2/include/net/sock.h
--- linux-2.6.5.orig/include/net/sock.h Sun Apr 4 06:37:37 2004
+++ linux-2.6.5.net_inline2/include/net/sock.h Mon Apr 12 16:05:03 2004
@@ -898,45 +898,7 @@
atomic_add(skb->truesize, &sk->sk_rmem_alloc);
}
-static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
-{
- int err = 0;
- int skb_len;
-
- /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
- number of warnings when compiling with -W --ANK
- */
- if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
- (unsigned)sk->sk_rcvbuf) {
- err = -ENOMEM;
- goto out;
- }
-
- /* It would be deadlock, if sock_queue_rcv_skb is used
- with socket lock! We assume that users of this
- function are lock free.
- */
- err = sk_filter(sk, skb, 1);
- if (err)
- goto out;
-
- skb->dev = NULL;
- skb_set_owner_r(skb, sk);
-
- /* Cache the SKB length before we tack it onto the receive
- * queue. Once it is added it no longer belongs to us and
- * may be freed by other threads of control pulling packets
- * from the queue.
- */
- skb_len = skb->len;
-
- skb_queue_tail(&sk->sk_receive_queue, skb);
-
- if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_data_ready(sk, skb_len);
-out:
- return err;
-}
+int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb);
static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb)
{
diff -urN linux-2.6.5.orig/net/core/sock.c linux-2.6.5.net_inline2/net/core/sock.c
--- linux-2.6.5.orig/net/core/sock.c Sun Apr 4 06:37:37 2004
+++ linux-2.6.5.net_inline2/net/core/sock.c Mon Apr 12 16:05:39 2004
@@ -1138,6 +1138,46 @@
atomic_set(&sk->sk_refcnt, 1);
}
+int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
+{
+ int err = 0;
+ int skb_len;
+
+ /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces
+ number of warnings when compiling with -W --ANK
+ */
+ if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
+ (unsigned)sk->sk_rcvbuf) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ /* It would be deadlock, if sock_queue_rcv_skb is used
+ with socket lock! We assume that users of this
+ function are lock free.
+ */
+ err = sk_filter(sk, skb, 1);
+ if (err)
+ goto out;
+
+ skb->dev = NULL;
+ skb_set_owner_r(skb, sk);
+
+ /* Cache the SKB length before we tack it onto the receive
+ * queue. Once it is added it no longer belongs to us and
+ * may be freed by other threads of control pulling packets
+ * from the queue.
+ */
+ skb_len = skb->len;
+
+ skb_queue_tail(&sk->sk_receive_queue, skb);
+
+ if (!sock_flag(sk, SOCK_DEAD))
+ sk->sk_data_ready(sk, skb_len);
+out:
+ return err;
+}
+
void lock_sock(struct sock *sk)
{
might_sleep();
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2004-04-12 13:23 (no subject) Denis Vlasenko
@ 2004-04-13 13:46 ` James Morris
0 siblings, 0 replies; 669+ messages in thread
From: James Morris @ 2004-04-13 13:46 UTC (permalink / raw)
To: Denis Vlasenko
Cc: David S. Miller, netdev,
YOSHIFUJI Hideaki / 吉藤英明,
linux-kernel
On Mon, 12 Apr 2004, Denis Vlasenko wrote:
> According to my measurements,
>
> ip_vs_control_add() (from include/net/ip_vs.h) is called twice
> and
> sock_queue_rcv_skb() (from include/net/sock.h) is called 19 times
> from various kernel .c files.
>
> Both these includes generate more than 500 bytes of code on x86.
>
> These patches uninline them. Please apply.
What kind of performance impact (if any) does this patch have?
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-04-09 17:54 Martin Knoblauch
2004-04-09 18:12 ` your mail Joel Jaeggli
0 siblings, 1 reply; 669+ messages in thread
From: Martin Knoblauch @ 2004-04-09 17:54 UTC (permalink / raw)
To: linux-kernel
>I was wondering if for linux or better for a linux filesystem
>there is something like dynamic swapping of files possible.
>For explanation: I habeaccess to an Infinstor via NFS and
>linux is runnig there. This server has a nice funtion I'd
>like to have: if there are files that are not used for a
>specified time (i.e. 30 days) they are moved to another storage
>(disk and after that to an streamer tape) and are replaced
>by some kind of 'link'. So if you look at your directory you
>can see everything that was there, but if you try to open it,
>you have to wait a moment (some seconds if the file was
>swapped to another disk) oder just another moment (some
>minutes if the file is on a tape) and then it restored at
>it's old place.
>
Good description of a HSM (Hierarchical Storage Management)
System.
>So is there anything which provides such a feature? By now
>I have a little script that moves such files out of the way and
>replaces them by links. But restoring is somewhat harder and
>it's not automatic.
>
>Any ideas?
>
Really depends. As far as I know thare are no "free" HSM Systems
out there for Linux The only one that I am faintly familiar with
that runs on Linux is StorNext from ADIC. Definitely not free.
DMF/Irix may now be ported to Linux (Altix/IA64), but I doubt
it will be free.
Sun is most likely not (yet) interested in doing a Linux port
of SAM-FS (there are still Sparc/Solaris Machines to sell).
And it won't be free (my guess).
Tivoli/IBM and UniTree are also sold for Linux. Again "sold" is
the important word
Martin
=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-04-09 17:54 Martin Knoblauch
@ 2004-04-09 18:12 ` Joel Jaeggli
0 siblings, 0 replies; 669+ messages in thread
From: Joel Jaeggli @ 2004-04-09 18:12 UTC (permalink / raw)
To: Martin Knoblauch; +Cc: linux-kernel
On Fri, 9 Apr 2004, Martin Knoblauch wrote:
> >I was wondering if for linux or better for a linux filesystem
> >there is something like dynamic swapping of files possible.
> >For explanation: I habeaccess to an Infinstor via NFS and
> >linux is runnig there. This server has a nice funtion I'd
> >like to have: if there are files that are not used for a
> >specified time (i.e. 30 days) they are moved to another storage
> >(disk and after that to an streamer tape) and are replaced
> >by some kind of 'link'. So if you look at your directory you
> >can see everything that was there, but if you try to open it,
> >you have to wait a moment (some seconds if the file was
> >swapped to another disk) oder just another moment (some
> >minutes if the file is on a tape) and then it restored at
> >it's old place.
> >
>
> Good description of a HSM (Hierarchical Storage Management)
> System.
>
> >So is there anything which provides such a feature? By now
> >I have a little script that moves such files out of the way and
> >replaces them by links. But restoring is somewhat harder and
> >it's not automatic.
> >
> >Any ideas?
> >
part of the thing for us (my group at UO) right now, is tape robots aren't
cheaper than disk, so a lot of our offline/near-line backup is slowly
moving in that direction... 1TB lto jukeboxs cost order of $8-9K ea and
the driver for your commercial tabe-backup software can cost nearly that
much on top of it, but I can put 3.5TB of disk in a 5u enclosure and
locate in some other building for a similar price if not less. Even If buy
it in something like a netapp filer it's still only around $10,000 a TB so
HSM systems involving tape don't really have the same apeal as when we
were paying $1200ea for 4GB scsi disks. If I had sunk costs in something
like a storagetek powerhorn with 6000 tape capacity I might think a little
differently but I suspect your situation is closer to mine that it is to
the sorts of people who buy those.
> Really depends. As far as I know thare are no "free" HSM Systems
> out there for Linux The only one that I am faintly familiar with
> that runs on Linux is StorNext from ADIC. Definitely not free.
>
> DMF/Irix may now be ported to Linux (Altix/IA64), but I doubt
> it will be free.
>
> Sun is most likely not (yet) interested in doing a Linux port
> of SAM-FS (there are still Sparc/Solaris Machines to sell).
> And it won't be free (my guess).
>
> Tivoli/IBM and UniTree are also sold for Linux. Again "sold" is
> the important word
>
> Martin
>
>
> =====
> ------------------------------------------------------
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www: http://www.knobisoft.de
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-03-15 22:49 Kevin Leung
2004-03-15 23:26 ` your mail Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: Kevin Leung @ 2004-03-15 22:49 UTC (permalink / raw)
To: linux-kernel
Hello All,
I am very new to Linux and am working on a project. The nature of the
project is to essentially record all process/thread scheduling activity for
use in a later application. I wanted to know if any experts out there knew
of any libraries that could essentially "monitor" or "listen" for any
scheduling changes made. For instance if the kernel decides to set process A
from "sleeping" to "running" and process B from "running" to "sleeping", I
wanted to know if there was a function that could generate an immediate
notification of this event. Priority change information is also desireable.
The more aspects which trigger notificaiton, the better. As a first attempt,
I tried understanding the source code of the system monitor application. I
gained some insight, but still have questions. Mainly questions pertaining
to how the system monitor application receives the most "up-to-the-minute"
information on what process are running, what processes are sleeping etc. I
got stuck in the code and decided to explore another means. Any advice or
insight into the matter would be greatly appreciated. If a library isn't
available, does anyone know the difficulty involved if I tried to modify the
kernel to provide this information?
Please CC me the comments and responses posted to the list in response to my
posting
Thank You in advance
_________________________________________________________________
Frustrated with dial-up? Lightning-fast Internet access for as low as
$29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-03-15 22:49 Kevin Leung
@ 2004-03-15 23:26 ` Richard B. Johnson
0 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2004-03-15 23:26 UTC (permalink / raw)
To: Kevin Leung; +Cc: linux-kernel
On Mon, 15 Mar 2004, Kevin Leung wrote:
> Hello All,
>
> I am very new to Linux and am working on a project. The nature of the
> project is to essentially record all process/thread scheduling activity for
> use in a later application. I wanted to know if any experts out there knew
> of any libraries that could essentially "monitor" or "listen" for any
> scheduling changes made. For instance if the kernel decides to set process A
> from "sleeping" to "running" and process B from "running" to "sleeping", I
> wanted to know if there was a function that could generate an immediate
> notification of this event.
No. FYI, there are hundreds-of-thousands of such "events" per second
of operation! Basically, any time some task is waiting for I/O its
CPU is taken away and given to somebody else. This is what "sleeping"
usually means. Once the I/O completes, the task gets the CPU
again and that's what "running" means. If you were to instrument
these two state-changes for all tasks, it would certainly leave
only a new percent of CPU available for the tasks. This would
royally screw up the meaning of anything you were trying to
instrument.
> Priority change information is also desireable.
If you mean the dynamic priority that keeps changing until
the task is executed, no. If you mean priority like
'nice', you can instrument the sys-call.
> The more aspects which trigger notificaiton, the better. As a first attempt,
There is a kernel logging daemon that writes 'printk' messages. This
works by having a user-mode daemon open and read /proc/kmsg. You can
make a similar communications interface, using the existing daemon
as a template, that will instrument anything you want.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-02-24 13:58 Jim Deas
2004-02-24 14:44 ` your mail Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: Jim Deas @ 2004-02-24 13:58 UTC (permalink / raw)
To: linux-kernel
Can someone point me in the right direction.
I am getting a oops on a driver I am porting from 2.4 to 2.6.2 kernel.
I have expanded the file_operations structures and have a driver that loads and inits the hardware but when I call the open function I get an oops. The best I can track it is
EIP 0060:[c0188954]
chrdev_open +0x104
What is the best debug tool to put this oops information in clear sight? It appears to never get to my modules open routine so I am at a debugging crossroad. What is the option on a kernel compile to get the compile listing so I can see what is at 0x104 in this block of code?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-02-24 13:58 Jim Deas
@ 2004-02-24 14:44 ` Richard B. Johnson
0 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2004-02-24 14:44 UTC (permalink / raw)
To: Jim Deas; +Cc: linux-kernel
On Tue, 24 Feb 2004, Jim Deas wrote:
> Can someone point me in the right direction.
> I am getting a oops on a driver I am porting from 2.4 to 2.6.2 kernel.
> I have expanded the file_operations structures and have a driver that
> loads and inits the hardware but when I call the open function I
> get an oops. The best I can track it is
>
Fix your line-warp!
> EIP 0060:[c0188954]
> chrdev_open +0x104
>
> What is the best debug tool to put this oops information in clear
> sight? It appears to never get to my modules open routine so I am
> at a debugging crossroad. What is the option on a kernel compile
> to get the compile listing so I can see what is at 0x104 in this
> block of code?
>
Nothing is going to help with that EIP with a segment value of
0x60. It looks like some dumb coding error, using a pointer
that disappeared after the module init function. In other
words, it's probably something like:
int __init init_module()
{
struct file_operations fops;
mset(&fops, 0x00, sizeof(fops));
fops.open = open;
fops.release = close;
fops.owner = THIS_MODULE;
register_chrdev(DEV_MAJOR, dev, &fops);
}
So, everything in init_module is GONE. Your program calls open()
and the pointer in the kernel gets dereferenced to junk.
There are kernel debugging tools, however I have found that
the most useful tools are printk() and some discipline.
In the case of code above, don't just change the declaration
of the fops object to static. Instead, move it outside the
function, so it's obviously where it won't go away.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2004-02-19 13:52 Joilnen Leite
2004-02-19 14:12 ` your mail Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: Joilnen Leite @ 2004-02-19 13:52 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-ide
excuse me friends shcedule_timeout(1) is not a problem
for spin_lock_irqsave ?
drivers/scsi/ide-scsi.c:897
spin_lock_irqsave(&ide_lock, flags);
while (HWGROUP(drive)->handler) {
HWGROUP(drive)->handler = NULL;
schedule_timeout(1);
}
pub 1024D/5139533E Joilnen Batista Leite
F565 BD0B 1A39 390D 827E 03E5 0CD4 0F20 5139 533E
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2004-02-19 13:52 (unknown) Joilnen Leite
@ 2004-02-19 14:12 ` Richard B. Johnson
0 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2004-02-19 14:12 UTC (permalink / raw)
To: Joilnen Leite; +Cc: linux-kernel, linux-ide
On Thu, 19 Feb 2004, Joilnen Leite wrote:
> excuse me friends shcedule_timeout(1) is not a problem
> for spin_lock_irqsave ?
>
> drivers/scsi/ide-scsi.c:897
>
> spin_lock_irqsave(&ide_lock, flags);
> while (HWGROUP(drive)->handler) {
> HWGROUP(drive)->handler = NULL;
> schedule_timeout(1);
> }
>
> pub 1024D/5139533E Joilnen Batista Leite
> F565 BD0B 1A39 390D 827E 03E5 0CD4 0F20 5139 533E
What kernel version? It is very bad. You can't sleep with
a spin-lock being held!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an Intel Pentium III machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2004-02-13 19:23 Bloch, Jack
0 siblings, 0 replies; 669+ messages in thread
From: Bloch, Jack @ 2004-02-13 19:23 UTC (permalink / raw)
To: 'Maciej Zenczykowski'; +Cc: 'linux-kernel@vger.kernel.org'
By the way shouldn't a munmap call really free the memory. I have an strace
showing that the process calls munmap a lot but I do not seeany gaps in the
map file
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
-----Original Message-----
From: Bloch, Jack
Sent: Friday, February 13, 2004 2:14 PM
To: 'Maciej Zenczykowski'
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail
Yes, your assumtion about the 1GB is correct.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
The deleted marks in question mean that the file in question has been
unlinked (rm'ed), however it is still being used and the inode in question
still exists. This memory is in use and thus validly takes up mapping
space. You'd need to unmap inorder to free that memory. Deleting a file
does not delete that file until _all_ processes close and unmap any
references to it. What's more worrying is the large area of unmapped
memory below 1GB (0x40000000), wonder why it doesn't get allocated? But I
think the answer is that the standard allocator only searches 1GB..3GB for
free areas...
Cheers,
MaZe.
On Fri, 13 Feb 2004, Bloch, Jack wrote:
> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
>
> <<9369>>
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2004-02-13 19:14 Bloch, Jack
0 siblings, 0 replies; 669+ messages in thread
From: Bloch, Jack @ 2004-02-13 19:14 UTC (permalink / raw)
To: 'Maciej Zenczykowski'; +Cc: linux-kernel
Yes, your assumtion about the 1GB is correct.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
The deleted marks in question mean that the file in question has been
unlinked (rm'ed), however it is still being used and the inode in question
still exists. This memory is in use and thus validly takes up mapping
space. You'd need to unmap inorder to free that memory. Deleting a file
does not delete that file until _all_ processes close and unmap any
references to it. What's more worrying is the large area of unmapped
memory below 1GB (0x40000000), wonder why it doesn't get allocated? But I
think the answer is that the standard allocator only searches 1GB..3GB for
free areas...
Cheers,
MaZe.
On Fri, 13 Feb 2004, Bloch, Jack wrote:
> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
>
> <<9369>>
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-02-13 16:45 Bloch, Jack
2004-02-13 18:11 ` your mail Maciej Zenczykowski
0 siblings, 1 reply; 669+ messages in thread
From: Bloch, Jack @ 2004-02-13 16:45 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
I am running a 2.4.19 Kernel and have a problem where a process is using the
up to the 0xC0000000 of space. It is no longer possible for this process to
get any more memory vi mmap or via shmget. However, when I dump the
/procs/#/maps file, I see large chunks of memory deleted. i.e this should be
freely available to be used by the next call. I do not see these addresses
get re-used. The maps file is attached.
<<9369>>
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
[-- Attachment #2: 9369 --]
[-- Type: application/octet-stream, Size: 39780 bytes --]
08048000-08165000 r-xp 00000000 08:02 1229201 /unisphere/srx3000/callp/bin/ucemain
08165000-08181000 rw-p 0011d000 08:02 1229201 /unisphere/srx3000/callp/bin/ucemain
08181000-08259000 rwxp 00000000 00:00 0
40000000-40012000 r-xp 00000000 08:02 3473423 /lib/ld-2.2.5.so
40012000-40013000 rw-p 00011000 08:02 3473423 /lib/ld-2.2.5.so
40013000-40014000 rw-p 00000000 00:00 0
40014000-4002d000 r-xp 00000000 08:02 3146425 /unisphere/srx3000/callp/lib/libUceMsg.so
4002d000-40032000 rw-p 00018000 08:02 3146425 /unisphere/srx3000/callp/lib/libUceMsg.so
40032000-4003b000 rw-p 00000000 00:00 0
4003b000-4014a000 r-xp 00000000 08:02 3146373 /unisphere/srx3000/callp/lib/librss.so
4014a000-40167000 rw-p 0010f000 08:02 3146373 /unisphere/srx3000/callp/lib/librss.so
40167000-40169000 rw-p 00000000 00:00 0
40169000-40173000 r-xp 00000000 08:02 3146393 /unisphere/srx3000/callp/lib/libdbal_no_LDAP.so
40173000-40174000 rw-p 0000a000 08:02 3146393 /unisphere/srx3000/callp/lib/libdbal_no_LDAP.so
40174000-4017f000 r-xp 00000000 08:02 3146419 /unisphere/srx3000/callp/lib/libstormgr.so
4017f000-40181000 rw-p 0000b000 08:02 3146419 /unisphere/srx3000/callp/lib/libstormgr.so
40181000-40182000 rw-p 00000000 00:00 0
40182000-40186000 r-xp 00000000 08:02 901822 /opt/SMAW/SMAWrtp/lib/libRtpSta.so
40186000-40187000 rw-p 00004000 08:02 901822 /opt/SMAW/SMAWrtp/lib/libRtpSta.so
40187000-4018d000 r-xp 00000000 08:02 901825 /opt/SMAW/SMAWrtp/lib/libRtpTic.so
4018d000-40190000 rw-p 00006000 08:02 901825 /opt/SMAW/SMAWrtp/lib/libRtpTic.so
40190000-40192000 r-xp 00000000 08:02 901790 /opt/SMAW/SMAWrtp/lib/libRtpUtil.so
40192000-40193000 rw-p 00002000 08:02 901790 /opt/SMAW/SMAWrtp/lib/libRtpUtil.so
40193000-401bf000 r-xp 00000000 08:02 901786 /opt/SMAW/SMAWrtp/lib/libRtpTm.so
401bf000-401c1000 rw-p 0002b000 08:02 901786 /opt/SMAW/SMAWrtp/lib/libRtpTm.so
401c1000-401c9000 rw-p 00000000 00:00 0
401c9000-40256000 r-xp 00000000 08:02 901780 /opt/SMAW/SMAWrtp/lib/libRtpCtx.so
40256000-40263000 rw-p 0008d000 08:02 901780 /opt/SMAW/SMAWrtp/lib/libRtpCtx.so
40263000-4027b000 rw-p 00000000 00:00 0
4027b000-4030d000 r-xp 00000000 08:02 901782 /opt/SMAW/SMAWrtp/lib/libRtpEvent.so
4030d000-4031d000 rw-p 00091000 08:02 901782 /opt/SMAW/SMAWrtp/lib/libRtpEvent.so
4031d000-40328000 r-xp 00000000 08:02 901773 /opt/SMAW/SMAWrtp/lib/libRtpCfg.so
40328000-40330000 rw-p 0000b000 08:02 901773 /opt/SMAW/SMAWrtp/lib/libRtpCfg.so
40330000-40331000 rw-p 00000000 00:00 0
40331000-40341000 r-xp 00000000 08:02 901817 /opt/SMAW/SMAWrtp/lib/libRtpDbiSolid.so
40341000-40342000 rw-p 0000f000 08:02 901817 /opt/SMAW/SMAWrtp/lib/libRtpDbiSolid.so
40342000-40344000 rw-p 00000000 00:00 0
40344000-4034b000 r-xp 00000000 08:02 901787 /opt/SMAW/SMAWrtp/lib/libRtpTrc.so
4034b000-4034c000 rw-p 00007000 08:02 901787 /opt/SMAW/SMAWrtp/lib/libRtpTrc.so
4034c000-40375000 r-xp 00000000 08:02 901778 /opt/SMAW/SMAWrtp/lib/libRtpCom.so
40375000-40383000 rw-p 00028000 08:02 901778 /opt/SMAW/SMAWrtp/lib/libRtpCom.so
40383000-40386000 r-xp 00000000 08:02 901789 /opt/SMAW/SMAWrtp/lib/libRtpUpdate.so
40386000-4038a000 rw-p 00003000 08:02 901789 /opt/SMAW/SMAWrtp/lib/libRtpUpdate.so
4038a000-4038d000 r-xp 00000000 08:02 901785 /opt/SMAW/SMAWrtp/lib/libRtpSnm.so
4038d000-4038e000 rw-p 00002000 08:02 901785 /opt/SMAW/SMAWrtp/lib/libRtpSnm.so
4038e000-40390000 r-xp 00000000 08:02 901779 /opt/SMAW/SMAWrtp/lib/libRtpCommon.so
40390000-40391000 rw-p 00001000 08:02 901779 /opt/SMAW/SMAWrtp/lib/libRtpCommon.so
40391000-40392000 rw-p 00000000 00:00 0
40392000-4039b000 r-xp 00000000 08:02 901774 /opt/SMAW/SMAWrtp/lib/libRtpCfgAdm.so
4039b000-403a3000 rw-p 00009000 08:02 901774 /opt/SMAW/SMAWrtp/lib/libRtpCfgAdm.so
403a3000-403a4000 rw-p 00000000 00:00 0
403a4000-4046d000 r-xp 00000000 08:02 409972 /usr/local/solid41/lib/socl2x41.so
4046d000-40479000 rw-p 000c9000 08:02 409972 /usr/local/solid41/lib/socl2x41.so
40479000-40486000 rw-p 00000000 00:00 0
40486000-40495000 r-xp 00000000 08:02 3146382 /unisphere/srx3000/callp/lib/libSrxCommon.so
40495000-40498000 rw-p 0000f000 08:02 3146382 /unisphere/srx3000/callp/lib/libSrxCommon.so
40498000-4049a000 r-xp 00000000 08:02 3146384 /unisphere/srx3000/callp/lib/libuce.so
4049a000-4049b000 rw-p 00002000 08:02 3146384 /unisphere/srx3000/callp/lib/libuce.so
4049b000-405a6000 r-xp 00000000 08:02 3146420 /unisphere/srx3000/callp/lib/libxla.so
405a6000-405cb000 rw-p 0010a000 08:02 3146420 /unisphere/srx3000/callp/lib/libxla.so
405cb000-405ce000 rw-p 00000000 00:00 0
405ce000-405e0000 r-xp 00000000 08:02 3146412 /unisphere/srx3000/callp/lib/libCdmInterface.so
405e0000-405e3000 rw-p 00011000 08:02 3146412 /unisphere/srx3000/callp/lib/libCdmInterface.so
405e3000-40770000 r-xp 00000000 08:02 3146418 /unisphere/srx3000/callp/lib/librtm.so
40770000-4079e000 rw-p 0018c000 08:02 3146418 /unisphere/srx3000/callp/lib/librtm.so
4079e000-4079f000 rw-s 00000000 00:05 7340244 /SYSV580202a1 (deleted)
4079f000-407a0000 rw-s 00000000 00:05 524292 /SYSVa800e006 (deleted)
407a0000-407a1000 rw-p 00000000 00:00 0
407a1000-407a2000 rw-s 00000000 00:05 7340244 /SYSV580202a1 (deleted)
407a2000-407a3000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
407a3000-407ab000 rw-p 00000000 00:00 0
407ab000-407ac000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
407ac000-407ad000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
407ad000-407b1000 rw-p 0000a000 00:00 0
407b1000-407b3000 r-xp 00000000 08:02 3473433 /lib/libdl.so.2
407b3000-407b4000 rw-p 00001000 08:02 3473433 /lib/libdl.so.2
407b4000-407b5000 rw-p 00000000 00:00 0
407b5000-407c7000 r-xp 00000000 08:02 3473436 /lib/libnsl.so.1
407c7000-407c8000 rw-p 00011000 08:02 3473436 /lib/libnsl.so.1
407c8000-407ca000 rw-p 00000000 00:00 0
407ca000-407d1000 r-xp 00000000 08:02 3146383 /unisphere/srx3000/callp/lib/libftp.so
407d1000-407d2000 rw-p 00006000 08:02 3146383 /unisphere/srx3000/callp/lib/libftp.so
407d2000-407f0000 r-xp 00000000 08:02 3146421 /unisphere/srx3000/callp/lib/libsdal.so
407f0000-407f3000 rw-p 0001e000 08:02 3146421 /unisphere/srx3000/callp/lib/libsdal.so
407f3000-4087d000 r-xp 00000000 08:02 3146371 /unisphere/srx3000/callp/lib/libinal.so
4087d000-40889000 rw-p 00089000 08:02 3146371 /unisphere/srx3000/callp/lib/libinal.so
40889000-4088a000 rw-p 00000000 00:00 0
4088a000-408ca000 r-xp 00000000 08:02 3146427 /unisphere/srx3000/callp/lib/libssal.so
408ca000-408cf000 rw-p 0003f000 08:02 3146427 /unisphere/srx3000/callp/lib/libssal.so
408cf000-40cdb000 rw-p 00000000 00:00 0
40cdb000-40ce2000 r-xp 00000000 08:02 3146426 /unisphere/srx3000/callp/lib/libgenbcid.so
40ce2000-40ce3000 rw-p 00007000 08:02 3146426 /unisphere/srx3000/callp/lib/libgenbcid.so
40ce3000-40d02000 r-xp 00000000 08:02 3146380 /unisphere/srx3000/callp/lib/libSVCcommon.so
40d02000-40d04000 rw-p 0001f000 08:02 3146380 /unisphere/srx3000/callp/lib/libSVCcommon.so
40d04000-40d05000 rw-p 00000000 00:00 0
40d05000-40d1e000 r-xp 00000000 08:02 3146372 /unisphere/srx3000/callp/lib/libAuthClient.so
40d1e000-40d20000 rw-p 00018000 08:02 3146372 /unisphere/srx3000/callp/lib/libAuthClient.so
40d20000-40d2e000 r-xp 00000000 08:02 3146410 /unisphere/srx3000/callp/lib/libAuc.so
40d2e000-40d31000 rw-p 0000d000 08:02 3146410 /unisphere/srx3000/callp/lib/libAuc.so
40d31000-40d51000 r-xp 00000000 08:02 3146377 /unisphere/srx3000/callp/lib/libCDR.so
40d51000-40d55000 rw-p 0001f000 08:02 3146377 /unisphere/srx3000/callp/lib/libCDR.so
40d55000-40d57000 rw-p 00000000 00:00 0
40d57000-40d5b000 r-xp 00000000 08:02 3146408 /unisphere/srx3000/callp/lib/libOpRtt.so
40d5b000-40d5c000 rw-p 00004000 08:02 3146408 /unisphere/srx3000/callp/lib/libOpRtt.so
40d5c000-40d7c000 r-xp 00000000 08:02 3146376 /unisphere/srx3000/callp/lib/libSrxTrcMgr.so
40d7c000-40d7f000 rw-p 0001f000 08:02 3146376 /unisphere/srx3000/callp/lib/libSrxTrcMgr.so
40d7f000-40d80000 rw-p 00000000 00:00 0
40d80000-40d82000 r-xp 00000000 08:02 3146375 /unisphere/srx3000/callp/lib/libSrxTrcCli.so
40d82000-40d83000 rw-p 00001000 08:02 3146375 /unisphere/srx3000/callp/lib/libSrxTrcCli.so
40d83000-40d8d000 r-xp 00000000 08:02 3146378 /unisphere/srx3000/callp/lib/libEM.so
40d8d000-40d8e000 rw-p 0000a000 08:02 3146378 /unisphere/srx3000/callp/lib/libEM.so
40d8e000-40d8f000 rw-p 00000000 00:00 0
40d8f000-40da1000 r-xp 00000000 08:02 3146374 /unisphere/srx3000/callp/lib/libBgApi.so
40da1000-40da3000 rw-p 00011000 08:02 3146374 /unisphere/srx3000/callp/lib/libBgApi.so
40da3000-40e0b000 r-xp 00000000 08:02 3146414 /unisphere/srx3000/callp/lib/libXdmInterface.so
40e0b000-40e1d000 rw-p 00067000 08:02 3146414 /unisphere/srx3000/callp/lib/libXdmInterface.so
40e1d000-40eb6000 r-xp 00000000 08:02 1474757 /usr/lib/libstdc++.so.5.0.0
40eb6000-40ecb000 rw-p 00098000 08:02 1474757 /usr/lib/libstdc++.so.5.0.0
40ecb000-40ed0000 rw-p 00000000 00:00 0
40ed0000-40ef2000 r-xp 00000000 08:02 3473434 /lib/libm.so.6
40ef2000-40ef3000 rw-p 00021000 08:02 3473434 /lib/libm.so.6
40ef3000-40efa000 r-xp 00000000 08:02 3473460 /lib/libgcc_s.so.1
40efa000-40efb000 rw-p 00007000 08:02 3473460 /lib/libgcc_s.so.1
40efb000-4100f000 r-xp 00000000 08:02 3473429 /lib/libc.so.6
4100f000-41015000 rw-p 00113000 08:02 3473429 /lib/libc.so.6
41015000-41019000 rw-p 00000000 00:00 0
41019000-41027000 r-xp 00000000 08:02 3473445 /lib/libpthread.so.0
41027000-4102e000 rw-p 0000e000 08:02 3473445 /lib/libpthread.so.0
4102e000-41030000 rw-p 00000000 00:00 0
41030000-63d46000 rw-s 00000000 00:05 6947016 /SYSV01020282 (deleted)
63d46000-63d86000 rw-p 00000000 00:00 0
63d86000-63d8f000 rw-s 00000000 00:05 753675 /SYSVa8001005 (deleted)
63d8f000-63d90000 rw-s 00000000 00:05 2293818 /SYSVa8006046 (deleted)
63d90000-63d91000 rw-s 00000000 00:05 2326587 /SYSVa8006048 (deleted)
63d91000-63d9a000 r-xp 00000000 08:02 3473440 /lib/libnss_files.so.2
63d9a000-63d9b000 rw-p 00008000 08:02 3473440 /lib/libnss_files.so.2
63d9b000-6455c000 rw-s 00000000 00:05 720906 /SYSVa8001000 (deleted)
6455c000-647b2000 rw-s 00000000 00:05 8257772 /SYSVa8020040 (deleted)
647b2000-65013000 rw-s 00000000 00:05 819213 /SYSVa8001001 (deleted)
65013000-6512d000 rw-s 00000000 00:05 786444 /SYSVa8020000 (deleted)
6512d000-651cf000 rw-s 00000000 00:05 458753 /SYSVa8004001 (deleted)
651cf000-65391000 rw-s 00000000 00:05 2064435 /SYSVa8006000 (deleted)
65391000-653a6000 rw-s 00000000 00:05 2228280 /SYSVa8006003 (deleted)
653a6000-653b1000 rw-s 00000000 00:05 2261049 /SYSVa8006047 (deleted)
653b1000-653b2000 rw-s 00000000 00:05 2359356 /SYSVa8006049 (deleted)
653b2000-653bd000 rw-s 00000000 00:05 2392125 /SYSVa8006051 (deleted)
653bd000-653c0000 rw-s 00000000 00:05 2424894 /SYSVa8006050 (deleted)
653c0000-653c1000 rw-s 00000000 00:05 2457663 /SYSVa8006052 (deleted)
653c1000-653d1000 rw-s 00000000 00:05 2490432 /SYSVa8006053 (deleted)
653d1000-653dc000 rw-s 00000000 00:05 2523201 /SYSVa8006209 (deleted)
653dc000-653f3000 rw-s 00000000 00:05 2555970 /SYSVa8006208 (deleted)
653f3000-653f4000 rw-s 00000000 00:05 2588739 /SYSVa800620a (deleted)
653f4000-654ee000 rw-s 00000000 00:05 2621508 /SYSVa800620b (deleted)
654ee000-65519000 rw-s 00000000 00:05 2654277 /SYSVa8006231 (deleted)
65519000-6589c000 rw-s 00000000 00:05 2687046 /SYSVa8006230 (deleted)
6589c000-6589e000 rw-s 00000000 00:05 2719815 /SYSVa8006232 (deleted)
6589e000-6b614000 rw-s 00000000 00:05 2752584 /SYSVa8006233 (deleted)
6b614000-6b63f000 rw-s 00000000 00:05 2785353 /SYSVa800623b (deleted)
6b63f000-6b9c2000 rw-s 00000000 00:05 2818122 /SYSVa800623a (deleted)
6b9c2000-6b9c4000 rw-s 00000000 00:05 2850891 /SYSVa800623c (deleted)
6b9c4000-6cb51000 rw-s 00000000 00:05 2883660 /SYSVa800623d (deleted)
6cb51000-6cb7c000 rw-s 00000000 00:05 2916429 /SYSVa800624f (deleted)
6cb7c000-6ceff000 rw-s 00000000 00:05 2949198 /SYSVa800624e (deleted)
6ceff000-6cf01000 rw-s 00000000 00:05 2981967 /SYSVa8006250 (deleted)
6cf01000-6d2d2000 rw-s 00000000 00:05 3014736 /SYSVa8006251 (deleted)
6d2d2000-6d2fd000 rw-s 00000000 00:05 3047505 /SYSVa800626d (deleted)
6d2fd000-6d680000 rw-s 00000000 00:05 3080274 /SYSVa800626c (deleted)
6d680000-6d682000 rw-s 00000000 00:05 3113043 /SYSVa800626e (deleted)
6d682000-6e046000 rw-s 00000000 00:05 3145812 /SYSVa800626f (deleted)
6e046000-6e051000 rw-s 00000000 00:05 3178581 /SYSVa8006277 (deleted)
6e051000-6e052000 rw-s 00000000 00:05 3211350 /SYSVa8006276 (deleted)
6e052000-6e053000 rw-s 00000000 00:05 3244119 /SYSVa8006278 (deleted)
6e053000-6e054000 rw-s 00000000 00:05 3276888 /SYSVa8006279 (deleted)
6e054000-6e06f000 rw-s 00000000 00:05 3309657 /SYSVa8006281 (deleted)
6e06f000-6e1e0000 rw-s 00000000 00:05 3342426 /SYSVa8006280 (deleted)
6e1e0000-6e1e1000 rw-s 00000000 00:05 3375195 /SYSVa8006282 (deleted)
6e1e1000-6e9e3000 rw-s 00000000 00:05 3407964 /SYSVa8006283 (deleted)
6e9e3000-6ea0e000 rw-s 00000000 00:05 3440733 /SYSVa800628b (deleted)
6ea0e000-6ed91000 rw-s 00000000 00:05 3473502 /SYSVa800628a (deleted)
6ed91000-6ed93000 rw-s 00000000 00:05 3506271 /SYSVa800628c (deleted)
6ed93000-6ef7c000 rw-s 00000000 00:05 3539040 /SYSVa800628d (deleted)
6ef7c000-6ef87000 rw-s 00000000 00:05 3571809 /SYSVa800629f (deleted)
6ef87000-6ef9e000 rw-s 00000000 00:05 3604578 /SYSVa800629e (deleted)
6ef9e000-6ef9f000 rw-s 00000000 00:05 3637347 /SYSVa80062a0 (deleted)
6ef9f000-6f099000 rw-s 00000000 00:05 3670116 /SYSVa80062a1 (deleted)
6f099000-6f0a4000 rw-s 00000000 00:05 3702885 /SYSVa80062c7 (deleted)
6f0a4000-6f0bb000 rw-s 00000000 00:05 3735654 /SYSVa80062c6 (deleted)
6f0bb000-6f0bc000 rw-s 00000000 00:05 3768423 /SYSVa80062c8 (deleted)
6f0bc000-6fc5f000 rw-s 00000000 00:05 3801192 /SYSVa80062c9 (deleted)
6fc5f000-6fc8a000 rw-s 00000000 00:05 3833961 /SYSVa80062db (deleted)
6fc8a000-7000d000 rw-s 00000000 00:05 3866730 /SYSVa80062da (deleted)
7000d000-7000f000 rw-s 00000000 00:05 3899499 /SYSVa80062dc (deleted)
7000f000-703e0000 rw-s 00000000 00:05 3932268 /SYSVa80062dd (deleted)
703e0000-7040b000 rw-s 00000000 00:05 3965037 /SYSVa80062f9 (deleted)
7040b000-7078e000 rw-s 00000000 00:05 3997806 /SYSVa80062f8 (deleted)
7078e000-70790000 rw-s 00000000 00:05 4030575 /SYSVa80062fa (deleted)
70790000-71154000 rw-s 00000000 00:05 4063344 /SYSVa80062fb (deleted)
71154000-7115f000 rw-s 00000000 00:05 4096113 /SYSVa8006303 (deleted)
7115f000-71160000 rw-s 00000000 00:05 4128882 /SYSVa8006302 (deleted)
71160000-71161000 rw-s 00000000 00:05 4161651 /SYSVa8006304 (deleted)
71161000-71162000 rw-s 00000000 00:05 4194420 /SYSVa8006305 (deleted)
71162000-7117d000 rw-s 00000000 00:05 4227189 /SYSVa800630d (deleted)
7117d000-712ee000 rw-s 00000000 00:05 4259958 /SYSVa800630c (deleted)
712ee000-712ef000 rw-s 00000000 00:05 4292727 /SYSVa800630e (deleted)
712ef000-71af1000 rw-s 00000000 00:05 4325496 /SYSVa800630f (deleted)
71af1000-71b1c000 rw-s 00000000 00:05 4358265 /SYSVa8006317 (deleted)
71b1c000-71e9f000 rw-s 00000000 00:05 4391034 /SYSVa8006316 (deleted)
71e9f000-71ea1000 rw-s 00000000 00:05 4423803 /SYSVa8006318 (deleted)
71ea1000-7208a000 rw-s 00000000 00:05 4456572 /SYSVa8006319 (deleted)
7208a000-720b5000 rw-s 00000000 00:05 4489341 /SYSVa800632b (deleted)
720b5000-72438000 rw-s 00000000 00:05 4522110 /SYSVa800632a (deleted)
72438000-7243a000 rw-s 00000000 00:05 4554879 /SYSVa800632c (deleted)
7243a000-73b1e000 rw-s 00000000 00:05 4587648 /SYSVa800632d (deleted)
73b1e000-73b49000 rw-s 00000000 00:05 4620417 /SYSVa8006335 (deleted)
73b49000-73ecc000 rw-s 00000000 00:05 4653186 /SYSVa8006334 (deleted)
73ecc000-73ece000 rw-s 00000000 00:05 4685955 /SYSVa8006336 (deleted)
73ece000-755b2000 rw-s 00000000 00:05 4718724 /SYSVa8006337 (deleted)
755b2000-755dd000 rw-s 00000000 00:05 4751493 /SYSVa800633f (deleted)
755dd000-75960000 rw-s 00000000 00:05 4784262 /SYSVa800633e (deleted)
75960000-75962000 rw-s 00000000 00:05 4817031 /SYSVa8006340 (deleted)
75962000-78072000 rw-s 00000000 00:05 4849800 /SYSVa8006341 (deleted)
78072000-7809d000 rw-s 00000000 00:05 4882569 /SYSVa8006349 (deleted)
7809d000-78420000 rw-s 00000000 00:05 4915338 /SYSVa8006348 (deleted)
78420000-78422000 rw-s 00000000 00:05 4948107 /SYSVa800634a (deleted)
78422000-7ab32000 rw-s 00000000 00:05 4980876 /SYSVa800634b (deleted)
7ab32000-7ab4d000 rw-s 00000000 00:05 5013645 /SYSVa8006353 (deleted)
7ab4d000-7ae1c000 rw-s 00000000 00:05 5046414 /SYSVa8006352 (deleted)
7ae1c000-7ae1d000 rw-s 00000000 00:05 5079183 /SYSVa8006354 (deleted)
7ae1d000-7ba52000 rw-s 00000000 00:05 5111952 /SYSVa8006355 (deleted)
7ba52000-7ba6d000 rw-s 00000000 00:05 5144721 /SYSVa800635d (deleted)
7ba6d000-7bd3c000 rw-s 00000000 00:05 5177490 /SYSVa800635c (deleted)
7bd3c000-7bd3d000 rw-s 00000000 00:05 5210259 /SYSVa800635e (deleted)
7bd3d000-7c972000 rw-s 00000000 00:05 5243028 /SYSVa800635f (deleted)
7c972000-7c99d000 rw-s 00000000 00:05 5275797 /SYSVa8006367 (deleted)
7c99d000-7cd20000 rw-s 00000000 00:05 5308566 /SYSVa8006366 (deleted)
7cd20000-7cd22000 rw-s 00000000 00:05 5341335 /SYSVa8006368 (deleted)
7cd22000-7deaf000 rw-s 00000000 00:05 5374104 /SYSVa8006369 (deleted)
7deaf000-7deda000 rw-s 00000000 00:05 5406873 /SYSVa8006371 (deleted)
7deda000-7df34000 rw-s 00000000 00:05 5439642 /SYSVa8006370 (deleted)
7df34000-7df35000 rw-s 00000000 00:05 5472411 /SYSVa8006372 (deleted)
7df35000-7dfe4000 rw-s 00000000 00:05 5505180 /SYSVa8006373 (deleted)
7dfe4000-7dfef000 rw-s 00000000 00:05 5537949 /SYSVa800637b (deleted)
7dfef000-7dff0000 rw-s 00000000 00:05 5570718 /SYSVa800637a (deleted)
7dff0000-7dff1000 rw-s 00000000 00:05 5603487 /SYSVa800637c (deleted)
7dff1000-7dff5000 rw-s 00000000 00:05 5636256 /SYSVa800637d (deleted)
7dff5000-7e000000 rw-s 00000000 00:05 5669025 /SYSVa8006385 (deleted)
7e000000-7e001000 rw-s 00000000 00:05 5701794 /SYSVa8006384 (deleted)
7e001000-7e002000 rw-s 00000000 00:05 5734563 /SYSVa8006386 (deleted)
7e002000-7e006000 rw-s 00000000 00:05 5767332 /SYSVa8006387 (deleted)
7e006000-7e031000 rw-s 00000000 00:05 5800101 /SYSVa800638f (deleted)
7e031000-7e3b4000 rw-s 00000000 00:05 5832870 /SYSVa800638e (deleted)
7e3b4000-7e3b6000 rw-s 00000000 00:05 5865639 /SYSVa8006390 (deleted)
7e3b6000-83002000 rw-s 00000000 00:05 5898408 /SYSVa8006391 (deleted)
83002000-8302d000 rw-s 00000000 00:05 5931177 /SYSVa8006399 (deleted)
8302d000-833b0000 rw-s 00000000 00:05 5963946 /SYSVa8006398 (deleted)
833b0000-833b2000 rw-s 00000000 00:05 5996715 /SYSVa800639a (deleted)
833b2000-8453f000 rw-s 00000000 00:05 6029484 /SYSVa800639b (deleted)
8453f000-8456a000 rw-s 00000000 00:05 6062253 /SYSVa80063a3 (deleted)
8456a000-848ed000 rw-s 00000000 00:05 6095022 /SYSVa80063a2 (deleted)
848ed000-848ef000 rw-s 00000000 00:05 6127791 /SYSVa80063a4 (deleted)
848ef000-85a7c000 rw-s 00000000 00:05 6160560 /SYSVa80063a5 (deleted)
85a7c000-85aa7000 rw-s 00000000 00:05 6193329 /SYSVa80063ad (deleted)
85aa7000-85b88000 rw-s 00000000 00:05 6226098 /SYSVa80063ac (deleted)
85b88000-85b89000 rw-s 00000000 00:05 6258867 /SYSVa80063ae (deleted)
85b89000-85beb000 rw-s 00000000 00:05 6291636 /SYSVa80063af (deleted)
85beb000-85c06000 rw-s 00000000 00:05 6324405 /SYSVa80063b7 (deleted)
85c06000-85d77000 rw-s 00000000 00:05 6357174 /SYSVa80063b6 (deleted)
85d77000-85d78000 rw-s 00000000 00:05 6389943 /SYSVa80063b8 (deleted)
85d78000-8657a000 rw-s 00000000 00:05 6422712 /SYSVa80063b9 (deleted)
8657a000-8657b000 r--s 00000000 00:05 0 /SYSV8901a000 (deleted)
8657b000-86587000 rw-s 00000000 00:05 622599 /SYSVa800e001 (deleted)
86587000-86588000 rw-s 00000000 00:05 655368 /SYSVa800e002 (deleted)
86588000-86589000 rw-s 00000000 00:05 1638438 /SYSVa8003000 (deleted)
86589000-8658b000 rw-s 00000000 00:05 1703976 /SYSVa800300a (deleted)
8658b000-8658c000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
8658c000-86594000 rw-p 00004000 00:00 0
86594000-865cb000 rw-s 00000000 00:05 983058 /SYSVa802000e (deleted)
865cb000-870dc000 rw-s 00000000 00:05 1769514 /SYSVa8003002 (deleted)
870dc000-870de000 rw-s 00000000 00:05 1671207 /SYSVa8003026 (deleted)
870de000-870e2000 rw-p 00000000 00:00 0
870e2000-871db000 rw-s 00000000 08:02 1262235 /unisphere/srx3000/callp/etc/rss/mappedSubEndpointIndexTbl
871db000-8ab18000 rw-s 00000000 08:02 1262233 /unisphere/srx3000/callp/etc/rss/mappedSubSvcTbl
8ab18000-8afe1000 rw-s 00000000 08:02 1262237 /unisphere/srx3000/callp/etc/rss/mappedRetailerSvcTbl
8afe1000-8b4aa000 rw-s 00000000 08:02 1262239 /unisphere/srx3000/callp/etc/rss/mappedRetailerIndexTbl
8b4aa000-8b5a3000 rw-s 00000000 08:02 1262241 /unisphere/srx3000/callp/etc/rss/mappedTimezoneTbl
8b5a3000-8e557000 rw-s 00000000 08:02 1262243 /unisphere/srx3000/callp/etc/rss/mappedSubSipTbl
8e557000-8e744000 rw-s 00000000 08:02 1262245 /unisphere/srx3000/callp/etc/rss/mappedSysSipTbl
8e744000-8e931000 rw-s 00000000 08:02 1262247 /unisphere/srx3000/callp/etc/rss/mappedSysSipIndexTbl
8e931000-8ea2a000 rw-s 00000000 08:02 1262249 /unisphere/srx3000/callp/etc/rss/mappedBGBusinessGrpTbl
8ea2a000-8eb23000 rw-s 00000000 08:02 1262251 /unisphere/srx3000/callp/etc/rss/mappedBGMainNumTbl
8eb23000-8ec1c000 rw-s 00000000 08:02 1262253 /unisphere/srx3000/callp/etc/rss/mappedBGDialPlanTbl
8ec1c000-8ed15000 rw-s 00000000 08:02 1262255 /unisphere/srx3000/callp/etc/rss/mappedBGSvcTbl
8ed15000-8ee0e000 rw-s 00000000 08:02 1262257 /unisphere/srx3000/callp/etc/rss/mappedBGTrafficCountTbl
8ee0e000-8ef07000 rw-s 00000000 08:02 1262259 /unisphere/srx3000/callp/etc/rss/mappedTeenChildTbl
8ef07000-8f000000 rw-s 00000000 08:02 1262261 /unisphere/srx3000/callp/etc/rss/mappedTeenParentTbl
8f000000-8f0f9000 rw-s 00000000 08:02 1262263 /unisphere/srx3000/callp/etc/rss/mappedBGAttendantNumTbl
8f0f9000-8f1f2000 rw-s 00000000 08:02 1262265 /unisphere/srx3000/callp/etc/rss/mappedBGSvcAccessCodeTbl
8f1f2000-8f6bb000 rw-s 00000000 08:02 1262267 /unisphere/srx3000/callp/etc/rss/mappedKeysetInfoTbl
8f6bb000-8fb84000 rw-s 00000000 08:02 1262269 /unisphere/srx3000/callp/etc/rss/mappedCustomerTbl
8fb84000-9004d000 rw-s 00000000 08:02 1262271 /unisphere/srx3000/callp/etc/rss/mappedNumberPlanTbl
9004d000-9004e000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
9004e000-90052000 rw-p 00000000 00:00 0
90052000-9007e000 rw-s 00000000 00:05 1966128 /SYSVa8005000 (deleted)
9007e000-9007f000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
9007f000-90097000 rw-p 00001000 00:00 0
90097000-900bc000 rw-s 00000000 00:05 1409055 /SYSVa8020018 (deleted)
900bc000-b2dd2000 rw-s 00000000 00:05 6947016 /SYSV01020282 (deleted)
b2dd2000-b2dd6000 rw-p 00000000 00:00 0
b2dd6000-b2ecf000 rw-s 00000000 08:02 2343590 /unisphere/srx3000/callp/etc/xla/mappedDomainTbl
b2ecf000-b46ab000 rw-s 00000000 08:02 2343592 /unisphere/srx3000/callp/etc/xla/mappedZoneTbl
b46ab000-b5039000 rw-s 00000000 08:02 2343594 /unisphere/srx3000/callp/etc/xla/mappedE164DestTbl
b5039000-b55f6000 rw-s 00000000 08:02 2343596 /unisphere/srx3000/callp/etc/xla/mappedTODDestTbl
b55f6000-b6449000 rw-s 00000000 08:02 2343600 /unisphere/srx3000/callp/etc/xla/mappedHomeDnTbl
b6449000-b729c000 rw-s 00000000 08:02 2343602 /unisphere/srx3000/callp/etc/xla/mappedPNPCodeTbl
b729c000-b757d000 rw-s 00000000 08:02 2343598 /unisphere/srx3000/callp/etc/xla/mappedE164PrefixTbl
b757d000-b7a46000 rw-s 00000000 08:02 2343604 /unisphere/srx3000/callp/etc/xla/mappedCarrDestTbl
b7a46000-b7a4d000 rw-s 00000000 08:02 2343606 /unisphere/srx3000/callp/etc/xla/mappedChargeRateTbl
b7a4d000-b9229000 rw-s 00000000 08:02 2343608 /unisphere/srx3000/callp/etc/xla/mappedIntcptTbl
b9229000-b9246000 rw-s 00000000 08:02 2343610 /unisphere/srx3000/callp/etc/xla/mappedNtmOmTbl
b9246000-ba55d000 rw-s 00000000 08:02 2343612 /unisphere/srx3000/callp/etc/xla/mappedE164DnTbl
ba55d000-ba569000 rw-p 00000000 00:00 0
ba569000-bd51d000 rw-s 00000000 08:02 1737316 /unisphere/srx3000/callp/etc/sdal/mappedSvcData
bd51d000-bd9e6000 rw-s 00000000 08:02 1917616 /unisphere/srx3000/callp/etc/ssal/mappedCallData
bd9e6000-bdeaf000 rw-s 00000000 08:02 1917618 /unisphere/srx3000/callp/etc/ssal/mappedCpuRingList
bdeaf000-bdebb000 rw-s 00000000 08:02 672432 /global/user/bcid/mappedBcidCountData
bdebb000-bdebc000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bdebc000-bdec8000 rw-p 00001000 00:00 0
bdec8000-bdee5000 rw-s 00000000 08:02 639428 /unisphere/srx3000/callp/etc/inal/mappedINFaultHandlingTbl
bdee5000-bdf02000 rw-s 00000000 08:02 639477 /unisphere/srx3000/callp/etc/inal/mappedINSvcLogicHostRouteTbl
bdf02000-bdf1f000 rw-s 00000000 08:02 639479 /unisphere/srx3000/callp/etc/inal/mappedINEscCodeGrpTbl
bdf1f000-bdf3c000 rw-s 00000000 08:02 639481 /unisphere/srx3000/callp/etc/inal/mappedINEscCodeEntryTbl
bdf3c000-bdfbb000 rw-s 00000000 08:02 639483 /unisphere/srx3000/callp/etc/inal/mappedINTriggerTbl
bdfbb000-be0b4000 rw-s 00000000 08:02 639485 /unisphere/srx3000/callp/etc/inal/mappedINProfileTbl
be0b4000-be57d000 rw-s 00000000 08:02 639487 /unisphere/srx3000/callp/etc/inal/mappedINProfileTrigTbl
be57d000-be59a000 r-xp 00000000 08:02 3244502 /unisphere/srx3000/callp/lib/services/libSVCac.so
be59a000-be59d000 rw-p 0001d000 08:02 3244502 /unisphere/srx3000/callp/lib/services/libSVCac.so
be59d000-be59e000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
be59e000-be5b2000 rw-p 00001000 00:00 0
be5b2000-be5d6000 r-xp 00000000 08:02 3244503 /unisphere/srx3000/callp/lib/services/libSVCacr.so
be5d6000-be5d9000 rw-p 00024000 08:02 3244503 /unisphere/srx3000/callp/lib/services/libSVCacr.so
be5d9000-be5e5000 rw-p 00000000 00:00 0
be5e5000-be63c000 r-xp 00000000 08:02 3244504 /unisphere/srx3000/callp/lib/services/libSVCin.so
be63c000-be643000 rw-p 00057000 08:02 3244504 /unisphere/srx3000/callp/lib/services/libSVCin.so
be643000-be663000 r-xp 00000000 08:02 3244505 /unisphere/srx3000/callp/lib/services/libSVCar.so
be663000-be666000 rw-p 0001f000 08:02 3244505 /unisphere/srx3000/callp/lib/services/libSVCar.so
be666000-be667000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
be667000-be668000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
be668000-be67c000 rw-p 00001000 00:00 0
be67c000-be689000 r-xp 00000000 08:02 3244506 /unisphere/srx3000/callp/lib/services/libSVCmn.so
be689000-be68a000 rw-p 0000d000 08:02 3244506 /unisphere/srx3000/callp/lib/services/libSVCmn.so
be68a000-be69b000 r-xp 00000000 08:02 3244507 /unisphere/srx3000/callp/lib/services/libSVCbgsr.so
be69b000-be69d000 rw-p 00010000 08:02 3244507 /unisphere/srx3000/callp/lib/services/libSVCbgsr.so
be69d000-be6a8000 r-xp 00000000 08:02 3244508 /unisphere/srx3000/callp/lib/services/libSVCbgsvc.so
be6a8000-be6a9000 rw-p 0000a000 08:02 3244508 /unisphere/srx3000/callp/lib/services/libSVCbgsvc.so
be6a9000-be6ba000 r-xp 00000000 08:02 3244509 /unisphere/srx3000/callp/lib/services/libSVCblv.so
be6ba000-be6bc000 rw-p 00010000 08:02 3244509 /unisphere/srx3000/callp/lib/services/libSVCblv.so
be6bc000-be6f7000 r-xp 00000000 08:02 3244512 /unisphere/srx3000/callp/lib/services/caleaaf.so
be6f7000-be6fd000 rw-p 0003b000 08:02 3244512 /unisphere/srx3000/callp/lib/services/caleaaf.so
be6fd000-be70b000 r-xp 00000000 08:02 3244513 /unisphere/srx3000/callp/lib/services/libSVCccw.so
be70b000-be70d000 rw-p 0000d000 08:02 3244513 /unisphere/srx3000/callp/lib/services/libSVCccw.so
be70d000-be774000 r-xp 00000000 08:02 3244514 /unisphere/srx3000/callp/lib/services/libSVCcf.so
be774000-be77c000 rw-p 00067000 08:02 3244514 /unisphere/srx3000/callp/lib/services/libSVCcf.so
be77c000-be780000 rw-p 00000000 00:00 0
be780000-be7af000 r-xp 00000000 08:02 3244515 /unisphere/srx3000/callp/lib/services/libSVCchd.so
be7af000-be7b3000 rw-p 0002f000 08:02 3244515 /unisphere/srx3000/callp/lib/services/libSVCchd.so
be7b3000-be7bd000 r-xp 00000000 08:02 3244516 /unisphere/srx3000/callp/lib/services/libSVCcidcw.so
be7bd000-be7be000 rw-p 00009000 08:02 3244516 /unisphere/srx3000/callp/lib/services/libSVCcidcw.so
be7be000-be7cb000 r-xp 00000000 08:02 3244517 /unisphere/srx3000/callp/lib/services/libSVCcid.so
be7cb000-be7cc000 rw-p 0000d000 08:02 3244517 /unisphere/srx3000/callp/lib/services/libSVCcid.so
be7cc000-be7d8000 r-xp 00000000 08:02 3244518 /unisphere/srx3000/callp/lib/services/libSVCcidsd.so
be7d8000-be7da000 rw-p 0000b000 08:02 3244518 /unisphere/srx3000/callp/lib/services/libSVCcidsd.so
be7da000-be7e6000 r-xp 00000000 08:02 3244519 /unisphere/srx3000/callp/lib/services/libSVCcidss.so
be7e6000-be7e8000 rw-p 0000b000 08:02 3244519 /unisphere/srx3000/callp/lib/services/libSVCcidss.so
be7e8000-be7f8000 r-xp 00000000 08:02 3244520 /unisphere/srx3000/callp/lib/services/libSVCcisname.so
be7f8000-be7fa000 rw-p 0000f000 08:02 3244520 /unisphere/srx3000/callp/lib/services/libSVCcisname.so
be7fa000-be808000 r-xp 00000000 08:02 3244521 /unisphere/srx3000/callp/lib/services/libSVCcisnum.so
be808000-be80a000 rw-p 0000d000 08:02 3244521 /unisphere/srx3000/callp/lib/services/libSVCcisnum.so
be80a000-be83d000 r-xp 00000000 08:02 3244522 /unisphere/srx3000/callp/lib/services/libSVCct.so
be83d000-be841000 rw-p 00033000 08:02 3244522 /unisphere/srx3000/callp/lib/services/libSVCct.so
be841000-be851000 r-xp 00000000 08:02 3244523 /unisphere/srx3000/callp/lib/services/libSVCcm.so
be851000-be853000 rw-p 0000f000 08:02 3244523 /unisphere/srx3000/callp/lib/services/libSVCcm.so
be853000-be85f000 r-xp 00000000 08:02 3244524 /unisphere/srx3000/callp/lib/services/libSVCcnab.so
be85f000-be861000 rw-p 0000b000 08:02 3244524 /unisphere/srx3000/callp/lib/services/libSVCcnab.so
be861000-be874000 r-xp 00000000 08:02 3244525 /unisphere/srx3000/callp/lib/services/libSVCcnam.so
be874000-be876000 rw-p 00012000 08:02 3244525 /unisphere/srx3000/callp/lib/services/libSVCcnam.so
be876000-be882000 r-xp 00000000 08:02 3244526 /unisphere/srx3000/callp/lib/services/libSVCcndb.so
be882000-be884000 rw-p 0000b000 08:02 3244526 /unisphere/srx3000/callp/lib/services/libSVCcndb.so
be884000-be8b4000 r-xp 00000000 08:02 3244527 /unisphere/srx3000/callp/lib/services/libSVCcpk.so
be8b4000-be8b8000 rw-p 0002f000 08:02 3244527 /unisphere/srx3000/callp/lib/services/libSVCcpk.so
be8b8000-be8b9000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
be8b9000-be8ba000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
be8ba000-be8d6000 rw-p 00001000 00:00 0
be8d6000-be8fd000 r-xp 00000000 08:02 3244528 /unisphere/srx3000/callp/lib/services/libSVCcpu.so
be8fd000-be900000 rw-p 00027000 08:02 3244528 /unisphere/srx3000/callp/lib/services/libSVCcpu.so
be900000-be959000 r-xp 00000000 08:02 3244529 /unisphere/srx3000/callp/lib/services/libSVCcsta.so
be959000-be961000 rw-p 00059000 08:02 3244529 /unisphere/srx3000/callp/lib/services/libSVCcsta.so
be961000-be962000 rw-p 00000000 00:00 0
be962000-be96b000 r-xp 00000000 08:02 3244530 /unisphere/srx3000/callp/lib/services/libSVCcvb.so
be96b000-be96c000 rw-p 00009000 08:02 3244530 /unisphere/srx3000/callp/lib/services/libSVCcvb.so
be96c000-be96d000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
be96d000-be979000 rw-p 00001000 00:00 0
be979000-be986000 r-xp 00000000 08:02 3244531 /unisphere/srx3000/callp/lib/services/libSVCcwt.so
be986000-be987000 rw-p 0000d000 08:02 3244531 /unisphere/srx3000/callp/lib/services/libSVCcwt.so
be987000-be9a6000 r-xp 00000000 08:02 3244532 /unisphere/srx3000/callp/lib/services/libSVCdrcw.so
be9a6000-be9a9000 rw-p 0001e000 08:02 3244532 /unisphere/srx3000/callp/lib/services/libSVCdrcw.so
be9a9000-bea14000 r-xp 00000000 08:02 3244550 /unisphere/srx3000/callp/lib/services/libSVCsle.so
bea14000-bea1d000 rw-p 0006b000 08:02 3244550 /unisphere/srx3000/callp/lib/services/libSVCsle.so
bea1d000-bea29000 rw-p 00000000 00:00 0
bea29000-bea49000 r-xp 00000000 08:02 3244533 /unisphere/srx3000/callp/lib/services/libSVCeacr.so
bea49000-bea4c000 rw-p 00020000 08:02 3244533 /unisphere/srx3000/callp/lib/services/libSVCeacr.so
bea4c000-bea4d000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bea4d000-bea4e000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bea4e000-bea6a000 rw-p 00001000 00:00 0
bea6a000-bea77000 r-xp 00000000 08:02 3244534 /unisphere/srx3000/callp/lib/services/libSVCecf.so
bea77000-bea79000 rw-p 0000d000 08:02 3244534 /unisphere/srx3000/callp/lib/services/libSVCecf.so
bea79000-bea8d000 r-xp 00000000 08:02 3244535 /unisphere/srx3000/callp/lib/services/libSVCems.so
bea8d000-bea8f000 rw-p 00013000 08:02 3244535 /unisphere/srx3000/callp/lib/services/libSVCems.so
bea8f000-beaa8000 r-xp 00000000 08:02 3244536 /unisphere/srx3000/callp/lib/services/libSVCkey.so
beaa8000-beaab000 rw-p 00018000 08:02 3244536 /unisphere/srx3000/callp/lib/services/libSVCkey.so
beaab000-beab8000 r-xp 00000000 08:02 3244537 /unisphere/srx3000/callp/lib/services/libSVClnp.so
beab8000-beaba000 rw-p 0000c000 08:02 3244537 /unisphere/srx3000/callp/lib/services/libSVClnp.so
beaba000-bead0000 r-xp 00000000 08:02 3244538 /unisphere/srx3000/callp/lib/services/libSVCmct.so
bead0000-bead2000 rw-p 00015000 08:02 3244538 /unisphere/srx3000/callp/lib/services/libSVCmct.so
bead2000-bead3000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bead3000-beae2000 rw-p 00001000 00:00 0
beae2000-beb43000 r-xp 00000000 08:02 3244539 /unisphere/srx3000/callp/lib/services/libSVCmlhg.so
beb43000-beb4a000 rw-p 00061000 08:02 3244539 /unisphere/srx3000/callp/lib/services/libSVCmlhg.so
beb4a000-beb72000 r-xp 00000000 08:02 3146400 /unisphere/srx3000/callp/lib/libMLHGSMif.so
beb72000-beb77000 rw-p 00028000 08:02 3146400 /unisphere/srx3000/callp/lib/libMLHGSMif.so
beb77000-beb7c000 rw-p 00000000 00:00 0
beb7c000-beb84000 r-xp 00000000 08:02 3244541 /unisphere/srx3000/callp/lib/services/libSVCpmcnab.so
beb84000-beb85000 rw-p 00008000 08:02 3244541 /unisphere/srx3000/callp/lib/services/libSVCpmcnab.so
beb85000-beb8b000 rw-p 00000000 00:00 0
beb8b000-beb9a000 r-xp 00000000 08:02 3473446 /lib/libresolv.so.2
beb9a000-beb9b000 rw-p 0000e000 08:02 3473446 /lib/libresolv.so.2
beb9b000-beb9d000 rw-p 00000000 00:00 0
beb9d000-bebbf000 r-xp 00000000 08:02 3244540 /unisphere/srx3000/callp/lib/services/libSVCms.so
bebbf000-bebc2000 rw-p 00021000 08:02 3244540 /unisphere/srx3000/callp/lib/services/libSVCms.so
bebc2000-bebcc000 r-xp 00000000 08:02 3244542 /unisphere/srx3000/callp/lib/services/libSVCpmcndb.so
bebcc000-bebcd000 rw-p 0000a000 08:02 3244542 /unisphere/srx3000/callp/lib/services/libSVCpmcndb.so
bebcd000-bebdd000 r-xp 00000000 08:02 3244543 /unisphere/srx3000/callp/lib/services/libSVCracf.so
bebdd000-bebdf000 rw-p 00010000 08:02 3244543 /unisphere/srx3000/callp/lib/services/libSVCracf.so
bebdf000-bebf7000 rw-p 00000000 00:00 0
bebf7000-bec03000 r-xp 00000000 08:02 3244544 /unisphere/srx3000/callp/lib/services/libSVCrcf.so
bec03000-bec04000 rw-p 0000c000 08:02 3244544 /unisphere/srx3000/callp/lib/services/libSVCrcf.so
bec04000-bec15000 r-xp 00000000 08:02 3244545 /unisphere/srx3000/callp/lib/services/libSVCrfa.so
bec15000-bec17000 rw-p 00010000 08:02 3244545 /unisphere/srx3000/callp/lib/services/libSVCrfa.so
bec17000-bec29000 rw-p 00000000 00:00 0
bec29000-bec4f000 r-xp 00000000 08:02 3244546 /unisphere/srx3000/callp/lib/services/libSVCsca.so
bec4f000-bec53000 rw-p 00025000 08:02 3244546 /unisphere/srx3000/callp/lib/services/libSVCsca.so
bec53000-bec54000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bec54000-bec58000 rw-p 00000000 00:00 0
bec58000-bec76000 r-xp 00000000 08:02 3244547 /unisphere/srx3000/callp/lib/services/libSVCscf.so
bec76000-bec79000 rw-p 0001d000 08:02 3244547 /unisphere/srx3000/callp/lib/services/libSVCscf.so
bec79000-bec7a000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bec7a000-bec7b000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bec7b000-bec87000 rw-p 00001000 00:00 0
bec87000-becb2000 r-xp 00000000 08:02 3244548 /unisphere/srx3000/callp/lib/services/libSVCsc.so
becb2000-becb6000 rw-p 0002b000 08:02 3244548 /unisphere/srx3000/callp/lib/services/libSVCsc.so
becb6000-becb7000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
becb7000-becd3000 rw-p 00001000 00:00 0
becd3000-becf6000 r-xp 00000000 08:02 3244549 /unisphere/srx3000/callp/lib/services/libSVCscr.so
becf6000-becf9000 rw-p 00023000 08:02 3244549 /unisphere/srx3000/callp/lib/services/libSVCscr.so
becf9000-becfa000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
becfa000-bed06000 rw-p 00001000 00:00 0
bed06000-bed07000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bed07000-bed13000 rw-p 0000e000 00:00 0
bed13000-bed43000 r-xp 00000000 08:02 3244551 /unisphere/srx3000/callp/lib/services/libSVCsrs.so
bed43000-bed48000 rw-p 00030000 08:02 3244551 /unisphere/srx3000/callp/lib/services/libSVCsrs.so
bed48000-bed49000 rw-p 00000000 00:00 0
bed49000-bed4a000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bed4a000-bed56000 rw-p 00002000 00:00 0
bed56000-bed61000 r-xp 00000000 08:02 3244555 /unisphere/srx3000/callp/lib/services/libSVCteen.so
bed61000-bed62000 rw-p 0000b000 08:02 3244555 /unisphere/srx3000/callp/lib/services/libSVCteen.so
bed62000-bed63000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bed63000-bed7f000 rw-p 00001000 00:00 0
bed7f000-bed8e000 r-xp 00000000 08:02 3244556 /unisphere/srx3000/callp/lib/services/libSVCtfs.so
bed8e000-bed90000 rw-p 0000e000 08:02 3244556 /unisphere/srx3000/callp/lib/services/libSVCtfs.so
bed90000-bed9e000 r-xp 00000000 08:02 3244557 /unisphere/srx3000/callp/lib/services/libSVCtpcc.so
bed9e000-beda0000 rw-p 0000d000 08:02 3244557 /unisphere/srx3000/callp/lib/services/libSVCtpcc.so
beda0000-bedab000 r-xp 00000000 08:02 3244558 /unisphere/srx3000/callp/lib/services/libSVCtrs.so
bedab000-bedac000 rw-p 0000b000 08:02 3244558 /unisphere/srx3000/callp/lib/services/libSVCtrs.so
bedac000-bedad000 rw-s 00000000 00:05 6848709 /SYSV28024276 (deleted)
bedad000-bedb9000 rw-p 00001000 00:00 0
bedb9000-bedeb000 r-xp 00000000 08:02 3244559 /unisphere/srx3000/callp/lib/services/libSVCtwc.so
bedeb000-bedef000 rw-p 00031000 08:02 3244559 /unisphere/srx3000/callp/lib/services/libSVCtwc.so
bedef000-bee05000 r-xp 00000000 08:02 3244561 /unisphere/srx3000/callp/lib/services/libSVCuscn.so
bee05000-bee07000 rw-p 00015000 08:02 3244561 /unisphere/srx3000/callp/lib/services/libSVCuscn.so
bee07000-bee13000 rw-p 00000000 00:00 0
bee13000-bee2c000 rw-s 00000000 00:05 7405782 /SYSVa8020046 (deleted)
bee2c000-bee2d000 rw-p 00000000 00:00 0
bee30000-bee48000 rw-p 00004000 00:00 0
bff2e000-c0000000 rwxp fff2f000 00:00 0
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2004-02-13 16:45 Bloch, Jack
@ 2004-02-13 18:11 ` Maciej Zenczykowski
0 siblings, 0 replies; 669+ messages in thread
From: Maciej Zenczykowski @ 2004-02-13 18:11 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
The deleted marks in question mean that the file in question has been
unlinked (rm'ed), however it is still being used and the inode in question
still exists. This memory is in use and thus validly takes up mapping
space. You'd need to unmap inorder to free that memory. Deleting a file
does not delete that file until _all_ processes close and unmap any
references to it. What's more worrying is the large area of unmapped
memory below 1GB (0x40000000), wonder why it doesn't get allocated? But I
think the answer is that the standard allocator only searches 1GB..3GB for
free areas...
Cheers,
MaZe.
On Fri, 13 Feb 2004, Bloch, Jack wrote:
> I am running a 2.4.19 Kernel and have a problem where a process is using the
> up to the 0xC0000000 of space. It is no longer possible for this process to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
>
> <<9369>>
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2004-02-10 23:36 Bloch, Jack
2004-02-11 1:09 ` your mail Maciej Zenczykowski
0 siblings, 1 reply; 669+ messages in thread
From: Bloch, Jack @ 2004-02-10 23:36 UTC (permalink / raw)
To: linux-kernel
I have a system with 2GB of memory. One of my processes calls mmap to try to
map a 100MB file into memory. This calls fails with -ENOMEM. I rebuilt the
kernel with a few debug printk statements in mmap.c to see where the failure
was occurring it occurred in the function arch_get_unmapped_area. the code
is as follows:
for (vma = find_vma(mm, addr); ; vma = vma->vm_next) {
/* At this point: (!vma || addr < vma->vm_end). */
unsigned long __heap_stack_gap;
if (TASK_SIZE - len < addr)
{
printk("%d TASK SIZE - LEN LESS THAN
ADDR\n",__LINE__);
return -ENOMEM;
}
if (!found_hole && (!vma || addr < vma->vm_start)) {
mm->free_area_cache = addr;
found_hole = 1;
}
if (!vma)
return addr;
__heap_stack_gap = 0;
if (vma->vm_flags & VM_GROWSDOWN)
__heap_stack_gap = heap_stack_gap << PAGE_SHIFT;
if (addr + len + __heap_stack_gap <= vma->vm_start)
return addr;
addr = vma->vm_end;
}
The printk is mine. What exactly is meant by the fact that TASK_SIZE - len <
addr?
Regards,
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2004-02-10 23:36 Bloch, Jack
@ 2004-02-11 1:09 ` Maciej Zenczykowski
0 siblings, 0 replies; 669+ messages in thread
From: Maciej Zenczykowski @ 2004-02-11 1:09 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
On Tue, 10 Feb 2004, Bloch, Jack wrote:
> I have a system with 2GB of memory. One of my processes calls mmap to try to
> map a 100MB file into memory. This calls fails with -ENOMEM. I rebuilt the
> kernel with a few debug printk statements in mmap.c to see where the failure
> was occurring it occurred in the function arch_get_unmapped_area. the code
> is as follows:
>
> for (vma = find_vma(mm, addr); ; vma = vma->vm_next) {
> /* At this point: (!vma || addr < vma->vm_end). */
> unsigned long __heap_stack_gap;
> if (TASK_SIZE - len < addr)
> {
it's valid there's no point in searching further for an area of at least
len bytes. The user area is 0 .. TASK_SIZE-1. The addr is the address
currently being checked, the len is the requested length. if addr+len is
greater or equal to TASK_SIZE then the current addr (which is increasing
within this loop) already causes such a mapping to overflow into kernel
space (exceeds the TASK_SIZE virtual address limit). This is precisely as
expected.
I'd assume your program has fragmented memory to such a level that a
single consecutive 100 MB area is no longer free (not that hard to do,
since TASK_SIZE is 3 GB).
Cheers,
MaZe.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-12-26 20:20 caszonyi
2003-12-26 22:27 ` your mail Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: caszonyi @ 2003-12-26 20:20 UTC (permalink / raw)
To: linux-kernel; +Cc: kraxel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 245 bytes --]
Hi
I was trying to capture a tv program with mencoder when the oops occured
a couple of hours later the system froze without leaving a single trace
in logs. I was able to reboot with SysRq.
Programs versions, config and dmesg are attached.
[-- Attachment #2: Type: TEXT/PLAIN, Size: 772 bytes --]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux grinch 2.6.0 #3 Fri Dec 19 23:02:04 EET 2003 i686 unknown
Gnu C 3.2.3
Gnu make 3.80
util-linux 2.11z
mount 2.11z
module-init-tools 0.9.9
e2fsprogs 1.32
jfsutils 1.1.4
reiserfsprogs 3.6.4
xfsprogs 2.3.5
quota-tools 3.08.
PPP 2.4.1
nfs-utils 1.0.4
Dynamic linker (ldd) 2.3.1
Linux C++ Library 5.0.3
Procps 3.1.8
Net-tools 1.60
Kbd 1.08
Sh-utils 2.0
Modules Loaded
[-- Attachment #3: Type: TEXT/PLAIN, Size: 10207 bytes --]
Dec 26 17:57:21 grinch -- MARK --
Dec 26 17:59:08 grinch kernel: Unable to handle kernel paging request at virtual address c4bea00c
Dec 26 17:59:08 grinch kernel: printing eip:
Dec 26 17:59:08 grinch kernel: c0333f60
Dec 26 17:59:08 grinch kernel: *pde = 00011067
Dec 26 17:59:08 grinch kernel: *pte = 04bea000
Dec 26 17:59:08 grinch kernel: Oops: 0000 [#1]
Dec 26 17:59:08 grinch kernel: CPU: 0
Dec 26 17:59:08 grinch kernel: EIP: 0060:[<c0333f60>] Not tainted
Dec 26 17:59:08 grinch kernel: EFLAGS: 00210206
Dec 26 17:59:08 grinch kernel: EIP is at bttv_risc_planar+0x140/0x2c0
Dec 26 17:59:08 grinch kernel: eax: 00000000 ebx: 00001000 ecx: 00000000 edx: c4bea000
Dec 26 17:59:08 grinch kernel: esi: 00001000 edi: c4be9a20 ebp: 00000b64 esp: c5455b50
Dec 26 17:59:08 grinch kernel: ds: 007b es: 007b ss: 0068
Dec 26 17:59:08 grinch kernel: Process mencoder (pid: 572, threadinfo=c5454000 task=c6ca2040)
Dec 26 17:59:08 grinch kernel: Stack: cfe40000 c56df6a8 000020bc 00000000 c4bea000 c4be9810 c68e98a4 00000000
Dec 26 17:59:08 grinch kernel: 0000039c 0000011f 000820ce 00081f00 c56df600 000a26c0 c0335197 c0556e00
Dec 26 17:59:08 grinch kernel: c56df6a8 c4be9000 0000039c 0000039c 0000039c 00000120 0000088e 0000004e
Dec 26 17:59:08 grinch kernel: Call Trace:
Dec 26 17:59:08 grinch kernel: [<c0335197>] bttv_buffer_risc+0x1f7/0x6a0
Dec 26 17:59:08 grinch kernel: [<c032d7f0>] bttv_prepare_buffer+0xf0/0x190
Dec 26 17:59:08 grinch kernel: [<c032d952>] buffer_prepare+0x42/0x50
Dec 26 17:59:08 grinch kernel: [<c033ea8f>] videobuf_qbuf+0xbf/0x160
Dec 26 17:59:08 grinch kernel: [<c032fe91>] bttv_do_ioctl+0x11e1/0x14e0
Dec 26 17:59:08 grinch kernel: [<c012572b>] update_wall_time+0xb/0x40
Dec 26 17:59:08 grinch kernel: [<c0125b9f>] do_timer+0xdf/0xf0
Dec 26 17:59:08 grinch kernel: [<c0138f21>] mempool_alloc+0x91/0x180
Dec 26 17:59:08 grinch kernel: [<c0138f21>] mempool_alloc+0x91/0x180
Dec 26 17:59:08 grinch kernel: [<c011b840>] autoremove_wake_function+0x0/0x50
Dec 26 17:59:08 grinch kernel: [<c013e9cc>] mark_page_accessed+0x2c/0x40
Dec 26 17:59:08 grinch kernel: [<c011a181>] __wake_up_common+0x31/0x50
Dec 26 17:59:08 grinch kernel: [<c011a181>] __wake_up_common+0x31/0x50
Dec 26 17:59:08 grinch kernel: [<c02ce732>] n_tty_receive_buf+0x192/0xff0
Dec 26 17:59:08 grinch kernel: [<c01699aa>] d_splice_alias+0x4a/0x110
Dec 26 17:59:08 grinch kernel: [<c02d1421>] pty_write+0x1a1/0x1b0
Dec 26 17:59:08 grinch kernel: [<c0118fd8>] kernel_map_pages+0x28/0x90
Dec 26 17:59:08 grinch kernel: [<c013a50c>] __alloc_pages+0x35c/0x3b0
Dec 26 17:59:08 grinch kernel: [<c0329d28>] video_usercopy+0xd8/0x1d0
Dec 26 17:59:08 grinch kernel: [<c0145824>] do_mmap_pgoff+0x434/0x710
Dec 26 17:59:08 grinch kernel: [<c03301ce>] bttv_ioctl+0x3e/0x70
Dec 26 17:59:08 grinch kernel: [<c032ecb0>] bttv_do_ioctl+0x0/0x14e0
Dec 26 17:59:08 grinch kernel: [<c0163e33>] sys_ioctl+0xf3/0x280
Dec 26 17:59:08 grinch kernel: [<c0109367>] syscall_call+0x7/0xb
Dec 26 17:59:08 grinch kernel:
Dec 26 17:59:08 grinch kernel: Code: 8b 52 0c 39 54 24 5c 89 54 24 0c 89 d0 73 e4 8b 4c 24 20 89
Dec 26 17:59:23 grinch kernel: <1>Unable to handle kernel paging request at virtual address c4bea00c
Dec 26 17:59:23 grinch kernel: printing eip:
Dec 26 17:59:23 grinch kernel: c0333f60
Dec 26 17:59:23 grinch kernel: *pde = 00011067
Dec 26 17:59:23 grinch kernel: *pte = 04bea000
Dec 26 17:59:23 grinch kernel: Oops: 0000 [#2]
Dec 26 17:59:23 grinch kernel: CPU: 0
Dec 26 17:59:23 grinch kernel: EIP: 0060:[<c0333f60>] Not tainted
Dec 26 17:59:23 grinch kernel: EFLAGS: 00210206
Dec 26 17:59:23 grinch kernel: EIP is at bttv_risc_planar+0x140/0x2c0
Dec 26 17:59:23 grinch kernel: eax: 00000000 ebx: 00001000 ecx: 00000000 edx: c4bea000
Dec 26 17:59:23 grinch kernel: esi: 00001000 edi: c4be9a20 ebp: 00000b64 esp: c5455b50
Dec 26 17:59:23 grinch kernel: ds: 007b es: 007b ss: 0068
Dec 26 17:59:23 grinch kernel: Process mencoder (pid: 573, threadinfo=c5454000 task=c6ca2660)
Dec 26 17:59:23 grinch kernel: Stack: cfe40000 c56df2e8 000020bc 00000000 c4bea000 c4be9810 c68e98a4 00000000
Dec 26 17:59:23 grinch kernel: 0000039c 0000011f 000820ce 00081f00 c56df240 000a26c0 c0335197 c0556e00
Dec 26 17:59:23 grinch kernel: c56df2e8 c4be9000 0000039c 0000039c 0000039c 00000120 0000088e 0000004e
Dec 26 17:59:23 grinch kernel: Call Trace:
Dec 26 17:59:23 grinch kernel: [<c0335197>] bttv_buffer_risc+0x1f7/0x6a0
Dec 26 17:59:23 grinch kernel: [<c032d7f0>] bttv_prepare_buffer+0xf0/0x190
Dec 26 17:59:23 grinch kernel: [<c032d952>] buffer_prepare+0x42/0x50
Dec 26 17:59:23 grinch kernel: [<c033ea8f>] videobuf_qbuf+0xbf/0x160
Dec 26 17:59:23 grinch kernel: [<c032fe91>] bttv_do_ioctl+0x11e1/0x14e0
Dec 26 17:59:23 grinch kernel: [<c012572b>] update_wall_time+0xb/0x40
Dec 26 17:59:23 grinch kernel: [<c0125b9f>] do_timer+0xdf/0xf0
Dec 26 17:59:23 grinch kernel: [<c01094d4>] common_interrupt+0x18/0x20
Dec 26 17:59:23 grinch kernel: [<c01142d4>] delay_tsc+0x14/0x20
Dec 26 17:59:23 grinch kernel: [<c02b4132>] __delay+0x12/0x20
Dec 26 17:59:23 grinch kernel: [<c036b2a4>] i2c_outb+0x104/0x2f0
Dec 26 17:59:23 grinch kernel: [<c0163b3f>] kill_fasync+0x2f/0x70
Dec 26 17:59:23 grinch kernel: [<c02ce732>] n_tty_receive_buf+0x192/0xff0
Dec 26 17:59:23 grinch kernel: [<c036b14e>] i2c_stop+0x9e/0xf0
Dec 26 17:59:23 grinch kernel: [<c0163b3f>] kill_fasync+0x2f/0x70
Dec 26 17:59:23 grinch kernel: [<c02ce732>] n_tty_receive_buf+0x192/0xff0
Dec 26 17:59:23 grinch kernel: [<c036616d>] i2c_master_send+0x6d/0xc0
Dec 26 17:59:23 grinch kernel: [<c033cd2d>] set_tv_freq+0x11d/0x280
Dec 26 17:59:23 grinch kernel: [<c02d1421>] pty_write+0x1a1/0x1b0
Dec 26 17:59:23 grinch kernel: [<c0118fd8>] kernel_map_pages+0x28/0x90
Dec 26 17:59:23 grinch kernel: [<c013a50c>] __alloc_pages+0x35c/0x3b0
Dec 26 17:59:23 grinch kernel: [<c0329d28>] video_usercopy+0xd8/0x1d0
Dec 26 17:59:23 grinch kernel: [<c0145824>] do_mmap_pgoff+0x434/0x710
Dec 26 17:59:23 grinch kernel: [<c03301ce>] bttv_ioctl+0x3e/0x70
Dec 26 17:59:23 grinch kernel: [<c032ecb0>] bttv_do_ioctl+0x0/0x14e0
Dec 26 17:59:23 grinch kernel: [<c0163e33>] sys_ioctl+0xf3/0x280
Dec 26 17:59:23 grinch kernel: [<c0109367>] syscall_call+0x7/0xb
Dec 26 17:59:23 grinch kernel:
Dec 26 17:59:23 grinch kernel: Code: 8b 52 0c 39 54 24 5c 89 54 24 0c 89 d0 73 e4 8b 4c 24 20 89
Dec 26 17:59:36 grinch kernel: <1>Unable to handle kernel paging request at virtual address c4bea00c
Dec 26 17:59:36 grinch kernel: printing eip:
Dec 26 17:59:36 grinch kernel: c0333f60
Dec 26 17:59:36 grinch kernel: *pde = 00011067
Dec 26 17:59:36 grinch kernel: *pte = 04bea000
Dec 26 17:59:36 grinch kernel: Oops: 0000 [#3]
Dec 26 17:59:36 grinch kernel: CPU: 0
Dec 26 17:59:36 grinch kernel: EIP: 0060:[<c0333f60>] Not tainted
Dec 26 17:59:36 grinch kernel: EFLAGS: 00210206
Dec 26 17:59:36 grinch kernel: EIP is at bttv_risc_planar+0x140/0x2c0
Dec 26 17:59:36 grinch kernel: eax: 00000000 ebx: 00001000 ecx: 00000000 edx: c4bea000
Dec 26 17:59:36 grinch kernel: esi: 00001000 edi: c4be9a20 ebp: 00000b64 esp: c6567b50
Dec 26 17:59:36 grinch kernel: ds: 007b es: 007b ss: 0068
Dec 26 17:59:36 grinch kernel: Process mencoder (pid: 575, threadinfo=c6566000 task=c6ca2c80)
Dec 26 17:59:36 grinch kernel: Stack: cfe40000 cd1cbd28 000020bc 00000000 c4bea000 c4be9810 c68e98a4 00000000
Dec 26 17:59:36 grinch kernel: 0000039c 0000011f 000820ce 00081f00 cd1cbc80 000a26c0 c0335197 c0556e00
Dec 26 17:59:36 grinch kernel: cd1cbd28 c4be9000 0000039c 0000039c 0000039c 00000120 0000088e 0000004e
Dec 26 17:59:36 grinch kernel: Call Trace:
Dec 26 17:59:36 grinch kernel: [<c0335197>] bttv_buffer_risc+0x1f7/0x6a0
Dec 26 17:59:36 grinch kernel: [<c032d7f0>] bttv_prepare_buffer+0xf0/0x190
Dec 26 17:59:36 grinch kernel: [<c032d952>] buffer_prepare+0x42/0x50
Dec 26 17:59:36 grinch kernel: [<c033ea8f>] videobuf_qbuf+0xbf/0x160
Dec 26 17:59:36 grinch kernel: [<c032fe91>] bttv_do_ioctl+0x11e1/0x14e0
Dec 26 17:59:36 grinch kernel: [<c01198d6>] scheduler_tick+0x226/0x4a0
Dec 26 17:59:36 grinch kernel: [<c01258c6>] update_process_times+0x46/0x60
Dec 26 17:59:36 grinch kernel: [<c0125a10>] run_timer_softirq+0x110/0x1b0
Dec 26 17:59:36 grinch kernel: [<c0125b9f>] do_timer+0xdf/0xf0
Dec 26 17:59:36 grinch kernel: [<c0119120>] recalc_task_prio+0x90/0x1a0
Dec 26 17:59:36 grinch kernel: [<c01192ce>] try_to_wake_up+0x9e/0x160
Dec 26 17:59:36 grinch kernel: [<c01192ce>] try_to_wake_up+0x9e/0x160
Dec 26 17:59:36 grinch kernel: [<c011a181>] __wake_up_common+0x31/0x50
Dec 26 17:59:36 grinch kernel: [<c02ce732>] n_tty_receive_buf+0x192/0xff0
Dec 26 17:59:36 grinch kernel: [<c01258c6>] update_process_times+0x46/0x60
Dec 26 17:59:36 grinch kernel: [<c010b1f7>] do_IRQ+0x107/0x140
Dec 26 17:59:36 grinch kernel: [<c02d1421>] pty_write+0x1a1/0x1b0
Dec 26 17:59:36 grinch kernel: [<c0119120>] recalc_task_prio+0x90/0x1a0
Dec 26 17:59:36 grinch kernel: [<c01192ce>] try_to_wake_up+0x9e/0x160
Dec 26 17:59:36 grinch kernel: [<c011a181>] __wake_up_common+0x31/0x50
Dec 26 17:59:36 grinch kernel: [<c0329d28>] video_usercopy+0xd8/0x1d0
Dec 26 17:59:36 grinch kernel: [<c0119bb1>] schedule+0x51/0x570
Dec 26 17:59:36 grinch kernel: [<c03301ce>] bttv_ioctl+0x3e/0x70
Dec 26 17:59:36 grinch kernel: [<c032ecb0>] bttv_do_ioctl+0x0/0x14e0
Dec 26 17:59:36 grinch kernel: [<c0163e33>] sys_ioctl+0xf3/0x280
Dec 26 17:59:36 grinch kernel: [<c010dbf2>] do_syscall_trace+0x42/0x90
Dec 26 17:59:36 grinch kernel: [<c0109367>] syscall_call+0x7/0xb
Dec 26 17:59:36 grinch kernel:
Dec 26 17:59:36 grinch kernel: Code: 8b 52 0c 39 54 24 5c 89 54 24 0c 89 d0 73 e4 8b 4c 24 20 89
Dec 26 18:17:21 grinch -- MARK --
Dec 26 18:37:21 grinch -- MARK --
Dec 26 18:57:21 grinch -- MARK --
Dec 26 19:17:21 grinch -- MARK --
Dec 26 19:37:21 grinch -- MARK --
Dec 26 19:57:21 grinch -- MARK --
Dec 26 20:17:21 grinch -- MARK --
Dec 26 20:37:21 grinch -- MARK --
Dec 26 20:47:02 grinch syslogd 1.4.1: restart.
[-- Attachment #4: Type: TEXT/PLAIN, Size: 10850 bytes --]
Linux version 2.6.0 (root@grinch) (gcc version 3.2.3) #3 Fri Dec 19 23:02:04 EET 2003
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61424 pages, LIFO batch:14
HighMem zone: 0 pages, LIFO batch:1
DMI not present.
Building zonelist for node : 0
Kernel command line: BOOT_IMAGE=k260 ro root=306 psmouse_noext nmi_watchdog=2
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 700.411 MHz processor.
Console: colour VGA+ 132x25
Memory: 253804k/262080k available (3093k kernel code, 7548k reserved, 842k data, 356k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1372.16 BogoMIPS
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183fbff c1c7fbff 00000000 00000000
CPU: After vendor identify, caps: 0183fbff c1c7fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0183fbf7 c1c7fbff 00000000 00000020
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) Processor stepping 01
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
testing NMI watchdog ... OK.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 699.0952 MHz.
..... host bus clock speed is 199.0986 MHz.
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: the driver 'system' has been registered
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fbdf0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xbe20, dseg 0xf0000
pnp: match found with the PnP device '00:07' and the driver 'system'
pnp: match found with the PnP device '00:08' and the driver 'system'
pnp: match found with the PnP device '00:0b' and the driver 'system'
pnp: 00:0b: ioport range 0x208-0x20f has been reserved
PnPBIOS: 16 nodes reported by PnP BIOS; 16 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Disabling VIA memory write queue (PCI ID 0305, rev 02): [55] 81 & 1f -> 01
PCI: Using IRQ router VIA [1106/0686] at 0000:00:07.0
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
Coda Kernel/Venus communications, v6.0.0, coda@cs.cmu.edu
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
udf: registering filesystem
SGI XFS for Linux with ACLs, no debug enabled
isapnp: Scanning for PnP cards...
isapnp: Card 'Crystal Codec'
isapnp: 1 Plug & Play card detected total
pty: 512 Unix98 ptys configured
request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
ppdev: user-space parallel port driver
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: AGP aperture is 128M @ 0xd0000000
[drm] Initialized radeon 1.9.0 20020828 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
pnp: the driver 'serial' has been registered
pnp: match found with the PnP device '00:0d' and the driver 'serial'
pnp: match found with the PnP device '00:0e' and the driver 'serial'
pnp: the driver 'parport_pc' has been registered
pnp: match found with the PnP device '00:10' and the driver 'parport_pc'
parport0: PC-style at 0x3bc (0x7bc) [PCSPP,TRISTATE]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
lp0: using parport0 (polling).
lp0: console ready
parport_pc: Via 686A parallel port: io=0x3BC
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
spurious 8259A interrupt: IRQ7.
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256) (6 bit encapsulation enabled).
CSLIP: code copyright 1989 Regents of the University of California.
SLIP linefill/keepalive option.
8139too Fast Ethernet driver 0.9.26
PCI: Found IRQ 10 for device 0000:00:08.0
eth0: RealTek RTL8139 at 0xd0883000, 00:40:f4:72:99:b3, IRQ 10
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
PCI: Found IRQ 11 for device 0000:00:0a.0
eth1: RealTek RTL8139 at 0xd0885000, 00:40:f4:74:6d:fb, IRQ 11
eth1: Identified 8139 chip type 'RTL-8100B/8139D'
Linux video capture interface: v1.00
bttv: driver version 0.9.12 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
PCI: Found IRQ 9 for device 0000:00:09.0
PCI: Sharing IRQ 9 with 0000:00:09.1
bttv0: Bt878 (rev 2) at 0000:00:09.0, irq: 9, latency: 32, mmio: 0xe2001000
bttv0: detected: AVermedia TVCapture 98 [card=13], PCI subsystem ID is 1461:0002
bttv0: using: AVerMedia TVCapture 98 [card=13,autodetected]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [11]
bttv0: Avermedia eeprom[0x4011]: tuner=5 radio:no remote control:yes
bttv0: using tuner=5
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for MSP34xx (alternate address) @ 0x88... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
tvaudio: TV audio decoder + audio/video mux driver
tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6420,tda8425,pic16c54 (PV951),ta8874z
tuner: chip found @ 0xc2
tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
registering 0-0061
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 2F040J0, ATA DISK drive
hdb: SONY CDU4811, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: TEAC CD-W552E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66)
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 >
end_request: I/O error, dev hdb, sector 0
hdb: ATAPI 48X CD-ROM drive, 120kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
end_request: I/O error, dev hdc, sector 0
hdc: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
mice: PS/2 mouse device common for all mice
input: PC Speaker
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
i2c /dev entries driver
tuner: type already set (5)
registering 0-0050
tuner: type already set (5)
registering 0-0051
tuner: type already set (5)
registering 0-0052
tuner: type already set (5)
registering 0-0053
tuner: type already set (5)
registering 0-0054
tuner: type already set (5)
registering 0-0055
tuner: type already set (5)
registering 0-0056
tuner: type already set (5)
registering 0-0057
registering 1-0050
registering 1-0051
pnp: the driver 'cs4232' has been registered
pnp: match found with the PnP device '01:01.00' and the driver 'cs4232'
pnp: Device 01:01.00 activated.
<Crystal audio controller (CS4239)> at 0x534 irq 5 dma 1,0
ad1848: Interrupt test failed (IRQ5)
ad1848/cs4248 codec driver Copyright (C) by Hannu Savolainen 1993-1996
ad1848: No ISAPnP cards found, trying standard ones...
YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996
btaudio: driver version 0.7 loaded [digital+analog]
PCI: Found IRQ 9 for device 0000:00:09.1
PCI: Sharing IRQ 9 with 0000:00:09.0
btaudio: Bt878 (rev 2) at 00:09.1, irq: 9, latency: 32, mmio: 0xe2002000
btaudio: using card config "default"
btaudio: registered device dsp1 [digital]
btaudio: registered device dsp2 [analog]
btaudio: registered device mixer1
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
IPv4 over IPv4 tunneling driver
ip_conntrack version 2.1 (2047 buckets, 16376 max) - 300 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
You didn't specify the type of your ufs filesystem
mount -t ufs -o ufstype=sun|sunx86|44bsd|old|hp|nextstep|netxstep-cd|openstep ...
>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
ufs_read_super: bad magic number
UDF-fs DEBUG fs/udf/lowlevel.c:65:udf_get_last_session: CDROMMULTISESSION not supported: rc=-22
UDF-fs DEBUG fs/udf/super.c:1544:udf_fill_super: Multi-session=0
UDF-fs DEBUG fs/udf/super.c:532:udf_vrs: Starting at sector 16 (2048 byte sectors)
UDF-fs: No VRS found
VFS: Mounted root (jfs filesystem) readonly.
Freeing unused kernel memory: 356k freed
Adding 530104k swap on /dev/hda7. Priority:-1 extents:1
eth0: link down
eth1: link down
[-- Attachment #5: Type: TEXT/PLAIN, Size: 6670 bytes --]
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MK7=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PM=y
CONFIG_APM=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_PCI=y
CONFIG_PCI_GODIRECT=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_BINFMT_ELF=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG=y
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_TASKFILE_IO=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_NET_IPIP=y
CONFIG_ARPD=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_XFRM=y
CONFIG_IPV6_SCTP__=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_PPP=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_SLIP=y
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_SHAPER=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_MULTIPORT=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=512
CONFIG_PRINTER=y
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_VIA=y
CONFIG_I2C_VIAPRO=y
CONFIG_I2C_SENSOR=y
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_VIA686A=y
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_BT848=y
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_BUF=y
CONFIG_VIDEO_BTCX=y
CONFIG_VIDEO_SELECT=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SOUND_PRIME=y
CONFIG_SOUND_BT878=y
CONFIG_SOUND_OSS=y
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_CS4232=y
CONFIG_SOUND_YM3812=y
CONFIG_SOUND_TVMIXER=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_JFS_FS=y
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_DEBUG=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_UFS_FS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SMB_FS=y
CONFIG_CODA_FS=y
CONFIG_CODA_FS_OLD_API=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-2"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-12-26 20:20 caszonyi
@ 2003-12-26 22:27 ` Linus Torvalds
2004-01-05 10:59 ` Gerd Knorr
0 siblings, 1 reply; 669+ messages in thread
From: Linus Torvalds @ 2003-12-26 22:27 UTC (permalink / raw)
To: caszonyi; +Cc: linux-kernel, kraxel
On Fri, 26 Dec 2003 caszonyi@rdslink.ro wrote:
>
> I was trying to capture a tv program with mencoder when the oops occured
> a couple of hours later the system froze without leaving a single trace
> in logs. I was able to reboot with SysRq.
>
> Programs versions, config and dmesg are attached.
Looks like this loop:
....
while (voffset >= sg_dma_len(vsg)) {
voffset -= sg_dma_len(vsg);
vsg++;
}
....
and in particular, it's the "sg_dma_len()" access that oopses, apparently
because vsg was stale to begin with, or because it incremented past the
last pointer.
The pointer that fails (0xc4bea00c) looks reasonable, so it's almost
certainly due to CONFIG_PAGE_DEBUG showing some kind of use-after-free
problem (ie the pointer is stale, and the memory has already been freed).
I suspect the problem is that
"voffset >= sg_dma_len(vsg)"
test: if "voffset" is _exactly_ the same as sg_dma_len(), then we will
test one more iteration (when "voffset" is 0), and that iteration may be
past the end of the "vsg" array.
I suspect the fix might be to change the test to
"voffset && voffset >= sg_dma_len(vsg)"
to make sure that we never access vsg past the end of the array.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-12-26 22:27 ` your mail Linus Torvalds
@ 2004-01-05 10:59 ` Gerd Knorr
0 siblings, 0 replies; 669+ messages in thread
From: Gerd Knorr @ 2004-01-05 10:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: caszonyi, linux-kernel
> ....
> while (voffset >= sg_dma_len(vsg)) {
> voffset -= sg_dma_len(vsg);
> vsg++;
> }
> ....
> I suspect the problem is that
>
> "voffset >= sg_dma_len(vsg)"
>
> test: if "voffset" is _exactly_ the same as sg_dma_len(), then we will
> test one more iteration (when "voffset" is 0), and that iteration may be
> past the end of the "vsg" array.
That certainly makes sense, the 'v' plane is the last one in the memory
block for the video frame to be captured, so voffset / vsg will walk to
the last sg entry and may overrun described. Good catch, I'm impressed.
> I suspect the fix might be to change the test to
>
> "voffset && voffset >= sg_dma_len(vsg)"
Merged into my tree, thanks.
still busy with the xmas mail backlog,
Gerd
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-12-23 14:16 dublinux
2003-12-23 14:54 ` your mail Matti Aarnio
0 siblings, 1 reply; 669+ messages in thread
From: dublinux @ 2003-12-23 14:16 UTC (permalink / raw)
To: linux-kernel
unsubscribe linux-kernel
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-12-23 14:16 dublinux
@ 2003-12-23 14:54 ` Matti Aarnio
2003-12-23 17:36 ` Norberto Bensa
0 siblings, 1 reply; 669+ messages in thread
From: Matti Aarnio @ 2003-12-23 14:54 UTC (permalink / raw)
To: dublinux; +Cc: linux-kernel
Folks, I don't understand you...
In EVERY list posting there are explicite instructions
of how to unsubscribe, and STILL people do it wrong...
Do tell us (postmaster@vger.kernel.org) if you do find that
there is something confusing, and should be improved.
/Matti Aarnio -- one of <postmaster@vger.kernel.org>
On Tue, Dec 23, 2003 at 03:16:22PM +0100, dublinux wrote:
> Date: Tue, 23 Dec 2003 15:16:22 +0100
> From: dublinux <dublinux@box.it>
> To: linux-kernel@vger.kernel.org
>
> unsubscribe linux-kernel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-12-23 14:54 ` your mail Matti Aarnio
@ 2003-12-23 17:36 ` Norberto Bensa
0 siblings, 0 replies; 669+ messages in thread
From: Norberto Bensa @ 2003-12-23 17:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Matti Aarnio
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 354 bytes --]
Matti Aarnio wrote:
> Folks, I don't understand you...
> In EVERY list posting there are explicite instructions
> of how to unsubscribe, and STILL people do it wrong...
People doesn't read.
Regards,
Norberto
--
Linux 2.6.0-mm1 Pentium III (Coppermine) GenuineIntel GNU/Linux
14:35:46 up 39 min, 1 user, load average: 0.34, 0.18, 0.13
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20031210120336.GU8039@holomorphy.com>]
* Re: your mail
[not found] <20031210120336.GU8039@holomorphy.com>
@ 2003-12-10 13:17 ` Stephan von Krawczynski
0 siblings, 0 replies; 669+ messages in thread
From: Stephan von Krawczynski @ 2003-12-10 13:17 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: paul, marcelo.tosatti, thornber, linux-kernel
On Wed, 10 Dec 2003 04:03:36 -0800
William Lee Irwin III <wli@holomorphy.com> wrote:
> On Tue, 9 Dec 2003, William Lee Irwin III wrote:
> >>> Just apply the patch if you're for some reason terrified of 2.6.
>
> On Wed, 10 Dec 2003 00:15:17 +0000 (GMT) Paul Jakma <paul@clubi.ie> wrote:
> >> Or get RedHat or Fedora to apply the patch.
>
> On Wed, Dec 10, 2003 at 11:49:28AM +0000, skraw@ithnet.com wrote:
> > There it is again, this /dev/null argument.
> > "Multi-billion dollar companies" have gone bancrupt on the simple
> > fact that diversification of one product can rattle customers/users
> > to a degree that they in fact decide against the whole product range.
> > IOW go on with the idea to spread around an unknown number of kernel
> > versions and you can be sure that linux as a whole will greatly suffer.
> > This is a "user" issue, not a "developer" issue of course. Developers
> > can apply any kind of patches they like, but don't go and tell the
> > vast user base to "just apply patch xyz". They won't honor this at
> > all, your level of acceptance will dramatically drop.
>
> One of the main reasons to have an open source OS is customization.
> Arguing that it's not truly feasible to customize will not hold water.
Are you calling a user-configured (not user-patched) kernel "customized" or
not?
_The_ top reason (at least when reading Al's posts :-) is probably that the
source is cross-checked by many eyes. If you create a infinite number of
patched kernel-versions it is obvious you will loose this primary advantage.
The more versions the fewer cross-checking.
IOW a "customized" but instable OS values exactly zero.
> Pretty much every "productized" version of Linux is heavily customized
> to get some kind of value-add. There's no reason to bother mainline
> with this; if it's a serious user issue of that magnitude vendors will
> pick it up.
"Serious" is a subjective argument, therefore different people see different
issues as serious. In my opinion a kernel.org kernel should cover most if not
all possible stable customizations, see it as a pool.
So my primary question for inclusion would not be "what is it worth?" but "does
it do any harm?". I am not god, therefore I do not and can not judge
"worthness". Can you?
Regards,
Stephan
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2003-12-03 16:19 Bloch, Jack
0 siblings, 0 replies; 669+ messages in thread
From: Bloch, Jack @ 2003-12-03 16:19 UTC (permalink / raw)
To: 'Linus Torvalds'; +Cc: linux-kernel
Thanks,
I found the problem. I do have errno.h included. I was doing a read of errno
after calling perror. If I read it directly after getting the neagtive 0ne
back, it contains the right value.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
-----Original Message-----
From: Linus Torvalds [mailto:torvalds@osdl.org]
Sent: Wednesday, December 03, 2003 11:04 AM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
On Wed, 3 Dec 2003, Bloch, Jack wrote:
>
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it
contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?
Because you forgot a "#include <errno.h>"? Or you have something else
wrong in your program that makes "errno" mean the wrong thing?
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-12-03 15:08 Bloch, Jack
2003-12-03 15:43 ` your mail Richard B. Johnson
2003-12-03 16:03 ` Linus Torvalds
0 siblings, 2 replies; 669+ messages in thread
From: Bloch, Jack @ 2003-12-03 15:08 UTC (permalink / raw)
To: linux-kernel
I try to open a non-existan device driver node file. The Kernel returns a
value of -1 (expected). However, when I read the value of errno it contains
a value of 29. A call to the perror functrion does print out the correct
error message (a value of 2). Why does this happen?
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-12-03 15:08 Bloch, Jack
@ 2003-12-03 15:43 ` Richard B. Johnson
2003-12-03 16:03 ` Linus Torvalds
1 sibling, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2003-12-03 15:43 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
On Wed, 3 Dec 2003, Bloch, Jack wrote:
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
Because it doesn't happen! You are likely polluting the errno
variable either with another system call before you test it
or by not including the correct header file (errno may be a
MACRO).
Try this program:
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>
int main(int args, char *argv[])
{
int fd, save_errno;
if(args < 2) {
fprintf(stderr, "Usage:\n%s <filename>\n", argv[0]);
exit(EXIT_FAILURE);
}
if((fd = open(argv[1], O_RDONLY)) < 0) {
save_errno = errno;
perror("open");
fprintf(stderr, "Was %d (%s)\n", save_errno, strerror(save_errno));
exit(EXIT_FAILURE);
}
(void)close(fd);
return 0;
}
Script started on Wed Dec 3 10:41:24 2003
# ./xxx /dev/XXX
open: No such file or directory
Was 2 (No such file or directory)
# ./xxx /dev/VXI
open: Operation not supported by device
Was 19 (Operation not supported by device)
# exit
exit
Script done on Wed Dec 3 10:42:12 2003
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-12-03 15:08 Bloch, Jack
2003-12-03 15:43 ` your mail Richard B. Johnson
@ 2003-12-03 16:03 ` Linus Torvalds
1 sibling, 0 replies; 669+ messages in thread
From: Linus Torvalds @ 2003-12-03 16:03 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
On Wed, 3 Dec 2003, Bloch, Jack wrote:
>
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?
Because you forgot a "#include <errno.h>"? Or you have something else
wrong in your program that makes "errno" mean the wrong thing?
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <13724513568.20031119014829@internetplustravel.ru>]
* Re: your mail
[not found] <13724513568.20031119014829@internetplustravel.ru>
@ 2003-12-03 12:02 ` Harald Welte
0 siblings, 0 replies; 669+ messages in thread
From: Harald Welte @ 2003-12-03 12:02 UTC (permalink / raw)
To: Oleg Savostyanov; +Cc: Netfilter Development Mailinglist, Martin Josefsson
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Wed, Nov 19, 2003 at 01:48:07AM +0300, Oleg Savostyanov wrote:
> Hello , Harald
> I tryed to install extra package, written by you -
> pptp-conntrack-nat
> but failed to do this.
please report such problems to netfilter@lists.gnumonks.org, or
netfilter-devel@lists.gnumonks.org (like documented on
http://www.netfilter.org/contact.html).
also, which version of patch-o-matic were you using?
> Do you have any ideas what to do?
Martin Josefsson is the patch-o-matic maintainer, maybe he can help you.
--
- Harald Welte <laforge@gnumonks.org> http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-09-30 8:17 John Bradford
2003-09-30 13:31 ` your mail Dave Jones
0 siblings, 1 reply; 669+ messages in thread
From: John Bradford @ 2003-09-30 8:17 UTC (permalink / raw)
To: Jamie Lokier, akpm; +Cc: torvalds, linux-kernel
richard.brunner@amd.com
In-Reply-To: <20030930073814.GA26649@mail.jlokier.co.uk>
References: <20030930073814.GA26649@mail.jlokier.co.uk>
Subject: Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch
Quote from Jamie Lokier <jamie@shareable.org>:
> 2. Nevertheless, when a kernel _not_ optimised for those AMD processors
> is run on one, the "alternative" mechanism now correctly replaces
> prefetch instructions with nops.
> It's a reasonable argument that if a kernel version, say 2.6.0, promises
> to hide the errata from _userspace_ programs, then the generic or
> not-AMD-optimised kernels should do that too. Otherwise userspace may
> as well provide the workaround itself, by catching SIGSEGV - because it
> is perfectly normal and common to run a generic kernel on an AMD.
This problem, and others like it, would be solved for ever with
Adrian's bitmap-of-supported-cpus patch, though. With that, there is
no 'generic' kernel, either it supports Athlons, or it doesn't. 100%
elimination of Athlon specific code for other CPUs. Everybody is
happy.
Of course a kernel compiled strictly for 386s may seem to boot on an
Athlon but not work properly. So what? Just don't run the 'wrong'
kernel.
John.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 8:17 John Bradford
@ 2003-09-30 13:31 ` Dave Jones
2003-09-30 14:06 ` Jamie Lokier
2003-09-30 14:10 ` John Bradford
0 siblings, 2 replies; 669+ messages in thread
From: Dave Jones @ 2003-09-30 13:31 UTC (permalink / raw)
To: John Bradford; +Cc: Jamie Lokier, akpm, torvalds, linux-kernel
On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
> Of course a kernel compiled strictly for 386s may seem to boot on an
> Athlon but not work properly. So what? Just don't run the 'wrong'
> kernel.
Wrong answer. How do you intend to install Linux when a distro boot
kernel is compiled for lowest-common-denominator (386), and is the
'wrong' kernel for an Athlon ?
We hashed this argument out a week or so ago, it seems the message
didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.
clearer ?
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 13:31 ` your mail Dave Jones
@ 2003-09-30 14:06 ` Jamie Lokier
2003-09-30 14:50 ` Dave Jones
2003-09-30 14:10 ` John Bradford
1 sibling, 1 reply; 669+ messages in thread
From: Jamie Lokier @ 2003-09-30 14:06 UTC (permalink / raw)
To: Dave Jones, John Bradford, akpm, torvalds, linux-kernel
Dave Jones wrote:
> On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
> > Of course a kernel compiled strictly for 386s may seem to boot on an
> > Athlon but not work properly. So what? Just don't run the 'wrong'
> > kernel.
>
> Wrong answer. How do you intend to install Linux when a distro boot
> kernel is compiled for lowest-common-denominator (386), and is the
> 'wrong' kernel for an Athlon ?
I'm not sure what the fuss is; a strict 386 kernel runs just fine
without any problems on an Athlon. But anyway...
Dave, you are conflating "kernel compiled strictly for 386s" with
"compiled for lowest-common-denominator".
They are totally different configurations. Isn't that why we have
"generic" now?
The latter is for distro boots. The former is for that
386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
everything it can, and no errata thank you.
I've not heard of anyone actually wanting a strict 386 kernel lately,
but strict 486 is not so unusual.
Just as some people want a P4 optimised kernel, and some people want a
K7 optimised kernel, so some people want a 386 or 486 or Pentium
optimised kernel. Lowest-common-denominator means it runs on
everything, and isn't really anything to do with 386 any more - that's
not really the lowest-common-denominator, by virtue of the obvious
fact that pure 386 code isn't reliable on all other CPUs.
> We hashed this argument out a week or so ago, it seems the message
> didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.
I agree. It shouln't be possible to boot on the wrong hardware: it
should refuse.
There is precedent: X86_GOOD_APIC && X86_LOCAL_APIC: when booted on a
non-MMX P5, it refuses to boot, because it does not contain the errata
workaround.
Unfortunately the kernel has opposite precedents too.
By selecting a PII kernel, it is possible to configure out the code
for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
_can_ possibly boot on kernels where the errata are needed, and nary a
printk is emitted for it. Nasty bugs they are, too.
More generally than the CPU, you can also configure out BLK_DEV_RZ1000
which is another crucial workaround that needs to go in any
lowest-common-denominator kernel. Basically, if you're building a
distro boot kernel, you must turn on all known workarounds. That's
certainly lowest-common-denominator, but it's a far cry from the
configuration that a 386-as-firewall user wants.
> clearer?
If the kernel had a consistent policy so far, it would be more clear,
but it doesn't.
-- Jamie
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 14:06 ` Jamie Lokier
@ 2003-09-30 14:50 ` Dave Jones
2003-09-30 15:30 ` Jamie Lokier
2003-09-30 16:34 ` Adrian Bunk
0 siblings, 2 replies; 669+ messages in thread
From: Dave Jones @ 2003-09-30 14:50 UTC (permalink / raw)
To: Jamie Lokier; +Cc: John Bradford, akpm, torvalds, linux-kernel
On Tue, Sep 30, 2003 at 03:06:27PM +0100, Jamie Lokier wrote:
> Dave Jones wrote:
> > On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
> > > Of course a kernel compiled strictly for 386s may seem to boot on an
> > > Athlon but not work properly. So what? Just don't run the 'wrong'
> > > kernel.
> > Wrong answer. How do you intend to install Linux when a distro boot
> > kernel is compiled for lowest-common-denominator (386), and is the
> > 'wrong' kernel for an Athlon ?
> I'm not sure what the fuss is; a strict 386 kernel runs just fine
> without any problems on an Athlon. But anyway...
Unless it got configured away as proposed in your earlier patch.
> Dave, you are conflating "kernel compiled strictly for 386s" with
> "compiled for lowest-common-denominator".
>
> They are totally different configurations. Isn't that why we have
> "generic" now?
CONFIG_GENERIC could be extended to offer other options yes,
but right now what it does doesn't really match the name IMO.
Right now its closer to a CONFIG_MAX_CACHELINE_SIZE
> The latter is for distro boots. The former is for that
> 386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
> everything it can, and no errata thank you.
Again, 'trimming' away a few hundred bytes of errata workarounds
is ridiculous when we have bigger fish to fry where we can save
KBs of .text size, and MB's of runtime memory.
> I've not heard of anyone actually wanting a strict 386 kernel lately,
> but strict 486 is not so unusual.
ISTR that current gcc's emit 486 instructions anyway, so its possible
that with a modern toolchain, you can't *build* a 386 kernel.
I'm not sure if that got fixed or not, I don't track gcc lists any more.
> Just as some people want a P4 optimised kernel, and some people want a
> K7 optimised kernel, so some people want a 386 or 486 or Pentium
> optimised kernel. Lowest-common-denominator means it runs on
> everything, and isn't really anything to do with 386 any more - that's
> not really the lowest-common-denominator, by virtue of the obvious
> fact that pure 386 code isn't reliable on all other CPUs.
Elaborate? "pure 386 code" (whatever that means in your definition)
should run perfectly reliable on every CPU we care about.
> > We hashed this argument out a week or so ago, it seems the message
> > didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> > THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.
> I agree. It shouln't be possible to boot on the wrong hardware: it
> should refuse.
So first you argue for compiling out a few hundred bytes of errata
workaround, now you want to instead compile in checks & printk's
(which probably add up to not far off the same amount of space).
> By selecting a PII kernel, it is possible to configure out the code
> for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
> _can_ possibly boot on kernels where the errata are needed, and nary a
> printk is emitted for it. Nasty bugs they are, too.
Indeed. That's arguably a bug that occured when someone split the
original CONFIG_M686 into _M686 & MPENTIUMII.
> More generally than the CPU, you can also configure out BLK_DEV_RZ1000
> which is another crucial workaround that needs to go in any
> lowest-common-denominator kernel.
I wouldn't look at the history of drivers/ide/ as a shining example of
good design 8-)
> Basically, if you're building a
> distro boot kernel, you must turn on all known workarounds. That's
> certainly lowest-common-denominator, but it's a far cry from the
> configuration that a 386-as-firewall user wants.
Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
and arch/i386/Makefile into guacamole. After spending so much time
getting that crap into something maintainable, it seemed a huge step
backwards to litter it with dozens of ifdefs and duplication.
There has to be a cleaner way of pleasing everyone.
> > clearer?
> If the kernel had a consistent policy so far, it would be more clear,
> but it doesn't.
Agreed, there are some questionable parts.
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 14:50 ` Dave Jones
@ 2003-09-30 15:30 ` Jamie Lokier
2003-09-30 16:34 ` Adrian Bunk
1 sibling, 0 replies; 669+ messages in thread
From: Jamie Lokier @ 2003-09-30 15:30 UTC (permalink / raw)
To: Dave Jones, John Bradford, akpm, torvalds, linux-kernel
Dave Jones wrote:
> > I'm not sure what the fuss is; a strict 386 kernel runs just fine
> > without any problems on an Athlon. But anyway...
>
> Unless it got configured away as proposed in your earlier patch.
No, I don't understand. What about my patch, or indeed anything else,
stops a "strict 386" kernel from running on an Athlon?
> > The latter is for distro boots. The former is for that
> > 386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
> > everything it can, and no errata thank you.
>
> Again, 'trimming' away a few hundred bytes of errata workarounds
> is ridiculous when we have bigger fish to fry where we can save
> KBs of .text size, and MB's of runtime memory.
Well I think both are worthwhile. Low hanging fruit and all that -
this is an example of a small saving that's very clear and easy.
> > I've not heard of anyone actually wanting a strict 386 kernel lately,
> > but strict 486 is not so unusual.
>
> ISTR that current gcc's emit 486 instructions anyway, so its possible
> that with a modern toolchain, you can't *build* a 386 kernel.
> I'm not sure if that got fixed or not, I don't track gcc lists any more.
Afaict GCC has fine targetting for the 386, better than it did years
ago. It didn't used to use the "leave" instruction, have an option to
optimise for size, or options for selecting exactly which
architectural instruction set it would use.
Anyway, that there is very little difference between 386 and 486 from
an application point of view anyway. You may be thinking of the
recent C++ ABI debacle, I think it was, which accidentially turned out
to require some instruction emulation in the Debian kernel. I think
they've fixed it in GCC now.
> > Just as some people want a P4 optimised kernel, and some people want a
> > K7 optimised kernel, so some people want a 386 or 486 or Pentium
> > optimised kernel. Lowest-common-denominator means it runs on
> > everything, and isn't really anything to do with 386 any more - that's
> > not really the lowest-common-denominator, by virtue of the obvious
> > fact that pure 386 code isn't reliable on all other CPUs.
>
> Elaborate? "pure 386 code" (whatever that means in your definition)
> should run perfectly reliable on every CPU we care about.
If that were true, why are we talking about needing workarounds for
non-386 chips to work correctly?
The canonical example is the F00F sequence: reliable on a 386, crashes
a Pentium. That's a fine example of pure 386 code not being reliable
on a higher CPU. And that's why it isn't safe to run Linux 1.0 on
your Pentium web server.
> So first you argue for compiling out a few hundred bytes of errata
> workaround, now you want to instead compile in checks & printk's
> (which probably add up to not far off the same amount of space).
Oh, I have nothing against __init space :)
> > By selecting a PII kernel, it is possible to configure out the code
> > for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
> > _can_ possibly boot on kernels where the errata are needed, and nary a
> > printk is emitted for it. Nasty bugs they are, too.
>
> Indeed. That's arguably a bug that occured when someone split the
> original CONFIG_M686 into _M686 & MPENTIUMII.
It's a bit more complicated. It dates from before we had the
"alternative" macro, and it was still cool to optimise spin_unlock()
into the most minimal instruction sequence at compile time.
It's only since then that we've been generalising to "M586 should run
on all later models correctly". Arguably, tidying up in the process.
Now we could use "alternative" to put the locked store or non-locked
store there and it would not look out of place.
If we're honest, Linux seems to have evolved through the 2.5 series
from "optimise the primitives as tight as reasonable for a target
architecture" to "a few nops here and there won't hurt". Perhaps
Transmeta's malign influence, as nops cost virtually nothing on those :)
Or perhaps it's because CPU models have branched and don't make a
straight line any more. So we have to do more run-time checking to
keep it sane.
> > More generally than the CPU, you can also configure out BLK_DEV_RZ1000
> > which is another crucial workaround that needs to go in any
> > lowest-common-denominator kernel.
>
> I wouldn't look at the history of drivers/ide/ as a shining example of
> good design 8-)
No, but as an example of needing to enable all the workarounds for a
distro boot kernel, it's a glorious gem. Even now people aren't quite
sure if multi-sector mode or DMA should be enabled by default :)
> > Basically, if you're building a
> > distro boot kernel, you must turn on all known workarounds. That's
> > certainly lowest-common-denominator, but it's a far cry from the
> > configuration that a 386-as-firewall user wants.
>
> Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
> and arch/i386/Makefile into guacamole. After spending so much time
> getting that crap into something maintainable, it seemed a huge step
> backwards to litter it with dozens of ifdefs and duplication.
> There has to be a cleaner way of pleasing everyone.
Perhaps it's in a name. It doesn't help that there's an assumed
linear progression of CPUs to support, up to the point where they
branch off all over the place in feature space. In the linear part,
CONFIG_M586, CONFIG_M686 etc. seem to mean "support this CPU or
later", whatever later means (and it's not stated exactly). After the
explosion of different feature directions, they stop meaning that and
just become optimisation knobs, as all the different essential features
are supported at run time.
Personally I think Adrian's patch's heart is in the right place,
simply because the menu options make more sense than the present
rather confusion decision, if you intend to (or might ever, take your
pick) run a kernel compiled for one CPU on another. I am never sure,
for example, if it's safe to take the hard disk from my K6 and drop it
into a P5MMX box and boot from it. The kernel config just doesn't
make that clear.
With Adrian's it does, even if the code behind it is a little like
guacamole. Perhaps the code could be cleaner; I don't see that
individual CPU model support is much different than what we already
have, except for the option to fix features at compile time rather than
run time.
And that gives me an idea.... ;)
-- Jamie
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 14:50 ` Dave Jones
2003-09-30 15:30 ` Jamie Lokier
@ 2003-09-30 16:34 ` Adrian Bunk
1 sibling, 0 replies; 669+ messages in thread
From: Adrian Bunk @ 2003-09-30 16:34 UTC (permalink / raw)
To: Dave Jones, Jamie Lokier, John Bradford, akpm, torvalds, linux-kernel
On Tue, Sep 30, 2003 at 03:50:08PM +0100, Dave Jones wrote:
>...
> > Basically, if you're building a
> > distro boot kernel, you must turn on all known workarounds. That's
> > certainly lowest-common-denominator, but it's a far cry from the
> > configuration that a 386-as-firewall user wants.
>
> Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
> and arch/i386/Makefile into guacamole. After spending so much time
> getting that crap into something maintainable, it seemed a huge step
> backwards to litter it with dozens of ifdefs and duplication.
> There has to be a cleaner way of pleasing everyone.
>...
Referring to the latest patch I sent:
arch/i386/Kconfig:
The only problems seem to be some CPU_ONLY_* derived symbols I haven't
yet found a better solution for.
arch/i386/Makefile:
There are two ifdefs to deal with Pentium 4 and K7/K8 selected at the
same time:
ifdef CONFIG_CPU_PENTIUM4
cpuflags-$(CONFIG_CPU_K{7,8}) := ...
else
cpuflags-$(CONFIG_CPU_K{7,8}) := ...
endif
That's perhaps not optimal but IMHO not that bad.
The dozens of ifdefs were in other areas where I tried to add some
additional space optimizations. It was a mistake to put them into the
same patch and in the latest patches I sent they were already separated
and they are _not_ required for the CPU selection scheme.
> Dave
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 13:31 ` your mail Dave Jones
2003-09-30 14:06 ` Jamie Lokier
@ 2003-09-30 14:10 ` John Bradford
2003-09-30 14:58 ` Jamie Lokier
1 sibling, 1 reply; 669+ messages in thread
From: John Bradford @ 2003-09-30 14:10 UTC (permalink / raw)
To: Dave Jones; +Cc: Jamie Lokier, akpm, torvalds, linux-kernel
Quote from Dave Jones <davej@redhat.com>:
> On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
>
> > Of course a kernel compiled strictly for 386s may seem to boot on an
> > Athlon but not work properly. So what? Just don't run the 'wrong'
> > kernel.
>
> Wrong answer. How do you intend to install Linux when a distro boot
> kernel is compiled for lowest-common-denominator (386), and is the
> 'wrong' kernel for an Athlon ?
I don't. I *never* suggested doing that. I clearly said a kernel
compiled *strictly* for 386s. I.E. Without support for other
processors.
> We hashed this argument out a week or so ago, it seems the message
> didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.
It seems the message didn't get across to you.
Have you actually looked at Adrian's patch?
*Forget* that 386=lowest-common-denominator. This
'386=lowest-common-denominator' theme is out of date, and we should be
moving away from it - oh, hang on, that's exactly what Adrian's patch
allows us to do.
A distribution installation kernel needs to boot all supported
hardware - of course it does. So what? Just select support for all
the processors in the configurator. No, don't just select 386,
because 386 doesn't mean 386 and above anymore with Adrian's patch, it
means support 386 and don't bloat the kernel with workarounds for
other processors. Select *all* processors. Now you have a nice,
(bloated), kernel that boots on the same hardware that you old '386'
one did. Fine for installation on diverse hardware. Rubbish for
performance.
Unless, of course, you object to the possibility that somebody might
go out of their way to compile a 386 specific kernel from source
themselves, then run it on an Athlon. By chance it will probably
appear to work OK, but won't have the workaround enabled. So what?
Only somebody who knows exactly what they were doing is likely to do
that - how could it happen by accident? If you really must, put a
warning in to say, 'This kernel doesn't support your processor', but
doing that just adds more bloat. OK, so the bloat will be freed after
boot, but it's still bloat on the boot device, which matters in some
embedded systems.
> clearer ?
It's clear that you didn't read my original post, yes.
John.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 14:10 ` John Bradford
@ 2003-09-30 14:58 ` Jamie Lokier
2003-09-30 15:11 ` Dave Jones
0 siblings, 1 reply; 669+ messages in thread
From: Jamie Lokier @ 2003-09-30 14:58 UTC (permalink / raw)
To: John Bradford; +Cc: Dave Jones, akpm, torvalds, linux-kernel
John Bradford wrote:
> Unless, of course, you object to the possibility that somebody might
> go out of their way to compile a 386 specific kernel from source
> themselves, then run it on an Athlon. By chance it will probably
> appear to work OK, but won't have the workaround enabled. So what?
Actually the 386 kernel will work just fine on the AMD... The
workaround is only needed, in the kernel, to protect against the
kernel's own use of non-386 features...
Userspace is a different matter, but userspace has a lot of
model-specific things to worry about beyond this one instruction on
AMD. In practice: bswap, cmov, cmpxchg, mmx, sse, sse2, so knowing
whether to use prefetch or not is just one more variable for userspace
- and one which any portable app or library will have to know about in
any case.
(Aside: It is quite an anomaly that those cumbersome floating point
instructions are emulated on the older CPUs, yet all the other
instructions aren't emulated. Emulation is very slow, and forcing
userspace to just use different code instead is good, but that's just
as valid for floating point as it is for MMX, cmpxchg etc.)
> Only somebody who knows exactly what they were doing is likely to do
> that - how could it happen by accident? If you really must, put a
> warning in to say, 'This kernel doesn't support your processor', but
> doing that just adds more bloat. OK, so the bloat will be freed after
> boot, but it's still bloat on the boot device, which matters in some
> embedded systems.
To be fair, the kernel really ought to just say that and halt. That
is a fine compromise. It won't make embedded systems folks completely
happy, because if you've only got 2MB of NVRAM for your whole kernel
_and_ filesystem including user data (think PDA or cellphone), then a
hundred bytes here or there is actually worth trimming.
But then, those sort of embedded folks should just figure out
compressed software-suspend, and then they can ditch __init data from
the NVRAM image completely. It's much better to lose all of __init
than just a few bytes here or there, isn't it?
-- Jamie
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-09-30 14:58 ` Jamie Lokier
@ 2003-09-30 15:11 ` Dave Jones
0 siblings, 0 replies; 669+ messages in thread
From: Dave Jones @ 2003-09-30 15:11 UTC (permalink / raw)
To: Jamie Lokier; +Cc: John Bradford, akpm, torvalds, linux-kernel
On Tue, Sep 30, 2003 at 03:58:54PM +0100, Jamie Lokier wrote:
> (Aside: It is quite an anomaly that those cumbersome floating point
> instructions are emulated on the older CPUs, yet all the other
> instructions aren't emulated. Emulation is very slow, and forcing
> userspace to just use different code instead is good, but that's just
> as valid for floating point as it is for MMX, cmpxchg etc.)
There was a patch around a while back that did 486 emulation on 386
kernels. I think it even made into the Mandrake kernel.
> To be fair, the kernel really ought to just say that and halt. That
> is a fine compromise. It won't make embedded systems folks completely
> happy, because if you've only got 2MB of NVRAM for your whole kernel
> _and_ filesystem including user data (think PDA or cellphone), then a
> hundred bytes here or there is actually worth trimming.
With such tight constraints, why not just use 2.4 (or even 2.2) which
has much lower memory usage and diskspace requirements ?
Dave
--
Dave Jones http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-09-18 18:35 Robert Olsson
2003-09-18 19:38 ` your mail Jeff Garzik
0 siblings, 1 reply; 669+ messages in thread
From: Robert Olsson @ 2003-09-18 18:35 UTC (permalink / raw)
To: netdev, davem, jgarzik, akpm
From: Robert Olsson <robert@robur.slu.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16233.64248.666702.679433@robur.slu.se>
Date: Thu, 18 Sep 2003 20:35:36 +0200
To: Andrew Morton <akpm@osdl.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
davem@redhat.com,
netdev@oss.sgi.com
Subject: Re: netif_poll_disable() hangs
In-Reply-To: <20030908002914.737122a9.akpm@osdl.org>
References: <20030907232145.6ec197fd.akpm@osdl.org>
<3F5C2D1A.5050500@pobox.com>
<20030908002914.737122a9.akpm@osdl.org>
X-Mailer: VM 6.92 under Emacs 21.2.1
Andrew Morton writes:
> > >
> > > ifup eth0
> > > ifdown eth0
> > > ifup eth0
> > > ifdown eth0 <- hangs in dev_close -> netif_poll_disable()
> 2.4 does test_bit, 2.6 does test_and_set_bit.
Yeep. I noticed this too in 2.6.0-test5
--- include/linux/netdevice.h.orig 2003-09-08 21:50:31.000000000 +0200
+++ include/linux/netdevice.h 2003-09-17 17:27:58.000000000 +0200
@@ -830,9 +830,9 @@
local_irq_restore(flags);
}
-static inline void netif_poll_disable(struct net_device *dev)
+static inline void netif_poll_sync(struct net_device *dev)
{
- while (test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
+ while (test_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
/* No hurry. */
current->state = TASK_INTERRUPTIBLE;
schedule_timeout(1);
--- net/core/dev.c.orig 2003-09-08 21:50:06.000000000 +0200
+++ net/core/dev.c 2003-09-17 17:28:32.000000000 +0200
@@ -841,7 +841,7 @@
* engine, but this requires more changes in devices. */
smp_mb__after_clear_bit(); /* Commit netif_running(). */
- netif_poll_disable(dev);
+ netif_poll_sync(dev);
/*
* Call the device specific close. This cannot fail.
Cheers.
--ro
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-09-18 18:35 (no subject) Robert Olsson
@ 2003-09-18 19:38 ` Jeff Garzik
0 siblings, 0 replies; 669+ messages in thread
From: Jeff Garzik @ 2003-09-18 19:38 UTC (permalink / raw)
To: Robert Olsson; +Cc: netdev, davem, akpm
On Thu, Sep 18, 2003 at 08:35:36PM +0200, Robert Olsson wrote:
This issue is already fixed in 2.4 and 2.5 :)
> --- include/linux/netdevice.h.orig 2003-09-08 21:50:31.000000000 +0200
> +++ include/linux/netdevice.h 2003-09-17 17:27:58.000000000 +0200
> @@ -830,9 +830,9 @@
> local_irq_restore(flags);
> }
>
> -static inline void netif_poll_disable(struct net_device *dev)
> +static inline void netif_poll_sync(struct net_device *dev)
> {
> - while (test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
> + while (test_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
> /* No hurry. */
> current->state = TASK_INTERRUPTIBLE;
> schedule_timeout(1);
This patch breaks tg3 build, and operation...
tg3 wants a different operation than net/core/dev.c.
Jeff
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <Law11-F24DVK3aXvlcq000025d9@hotmail.com>]
* Re: your mail
[not found] <Law11-F24DVK3aXvlcq000025d9@hotmail.com>
@ 2003-09-09 16:26 ` Jörn Engel
0 siblings, 0 replies; 669+ messages in thread
From: Jörn Engel @ 2003-09-09 16:26 UTC (permalink / raw)
To: J B; +Cc: linux-mtd, jffs-dev
On Tue, 9 September 2003 08:44:21 -0500, J B wrote:
>
> A jffs2 internals question for the masses:
>
> Besides the 128Kb max kmalloc issue, is there any restriction on the size
> of an eraseblock that jffs2 can use?
>
> I am using the slram driver with a 4Kb eraseblock size to create a 4Mb ram
> device. I mount jffs2 on top of this and everything appears to work until
> the filesystem becomes full. I try removing a file and the remove command
> returns "rm: cannot unlink `foo' : No space left on device". df reports
> 100% usage.
>
> Also, looking at the output from having CONFIG_JFFS2_FS_DEBUG=1, it appears
> that garbage collection is constantly running and picking blocks from the
> clean list because there are none on the dirty list. Eventually even this
> fails and the garbage collector loops and complains repeatedly:
>
> "Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks
> is 0. (erasingempty: yes, erasependingempty: yes)
> jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28"
>
> The thread_should_wake is returning 1 because the dirty size is > an
> eraseblock, so it loops forever.
>
> If I switch the eraseblock size in slram back to 64Kb, this problem does
> not appear. So again, are there any restricitons on how small of an
> eraseblock size you can use, or is this something that hasn't ever really
> been an issue?
Not completely unexpected. I've always disliked the 5-eraseblock
number and started a discussion with David on the mtd list some time
ago. For some reason, other matters occupied our minds so this was
unfinished. But it is still in the archives.
The problem is that jffs2 doesn't need 5 eraseblocks, but rather 2 +
number_of_eraseblocks / some_constant. So with 1024 eraseblocks, you
appear to need more than 5 (empirically proven :), while with 64
eraseblocks, you could get away with 5. Maybe not, but there are very
few (no) bug reports, so it should be safe.
What jffs2 needs is to get rid of the constants for
JFFS2_RESERVED_BLOCKS_* and make them superblock variables instead.
Then we have to calculate them during mount time using some formula.
A patch doing the first step should still be in the archives, in the
same thread as the discussion or nearby.
Hope that helps!
Jörn
--
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-08-28 2:25 warudkar
2003-08-27 16:02 ` your mail William Lee Irwin III
0 siblings, 1 reply; 669+ messages in thread
From: warudkar @ 2003-08-28 2:25 UTC (permalink / raw)
To: kernel, wli, linux-kernel; +Cc: Andrew Morton
Con - With swappiness set to 100, the apps do start up in 3 minutes and kswapd doesn't hog the CPU. But X is still unusable till all of them have started up.
Wli - Sorry, vmstat segfaults on 2.6!
kernel@kolivas.org wrote
On Thu, 28 Aug 2003 07:38, warudkar@vsnl.net wrote:
> Trying out 2.6.0-test4-mm1. Inside KDE, I start OpenOffice.org, Rational
> Rose and Konsole at a time. All of these take extremely long time to
> startup. (approx > 5 minutes). Kswapd hogs the CPU all the time. X becomes
> unusable till all of them startup, although I can telnet and run top. Same
> thing run under 2.4.18 starts up in 3 minutes, X stays usable and kswapd
> never take more than 2% CPU.
Yes I can reproduce this with a memory heavy load as well on low memory
(linking at the end of a big kernel compile is standard problem). I actually
found the best workaround was to increase the swappiness instead of
decreasing it.
Try
echo 100 > /proc/sys/vm/swappiness
time it
then try
echo 0 > /proc/sys/vm/swappiness
you'll see that at low swappiness kswapd0 can use ridiculous amounts of cpu
trying to avoid swap. The default is 60.
Con
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-08-28 2:25 warudkar
@ 2003-08-27 16:02 ` William Lee Irwin III
0 siblings, 0 replies; 669+ messages in thread
From: William Lee Irwin III @ 2003-08-27 16:02 UTC (permalink / raw)
To: warudkar; +Cc: kernel, linux-kernel, Andrew Morton
On Wed, Aug 27, 2003 at 09:25:23PM -0500, warudkar@vsnl.net wrote:
> Con - With swappiness set to 100, the apps do start up in 3 minutes and kswapd doesn't hog the CPU. But X is still unusable till all of them have started up.
> Wli - Sorry, vmstat segfaults on 2.6!
This is a bug in older versions of vmstat. Upgrade vmstat.
-- wli
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-08-25 16:45 Marcelo Tosatti
2003-08-25 16:59 ` Herbert Pötzl
0 siblings, 1 reply; 669+ messages in thread
From: Marcelo Tosatti @ 2003-08-25 16:45 UTC (permalink / raw)
To: Herbert Pötzl; +Cc: lkml
On Mon, 25 Aug 2003, Herbert Pötzl wrote:
> On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> >
> > >
> > >
> > > Matthias Andree wrote:
> > >
> > > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > > >
> > > >
> > > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > > >>
> > > >
> > > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > > >
> > >
> > > Maybe some of Andrea's VM stuff?
> >
> > Definately. Thats the first thing I'm going to do after looking
through
> > "2.4.23-pre-patches" folder.
>
> any chance for the Bind Mount Extensions? 8-)
I haven't found time to at the patch yet but will do so soon.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-08-25 16:45 Marcelo Tosatti
@ 2003-08-25 16:59 ` Herbert Pötzl
0 siblings, 0 replies; 669+ messages in thread
From: Herbert Pötzl @ 2003-08-25 16:59 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
On Mon, Aug 25, 2003 at 01:45:25PM -0300, Marcelo Tosatti wrote:
> On Mon, 25 Aug 2003, Herbert Pötzl wrote:
>
> > On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> > >
> > > >
> > > >
> > > > Matthias Andree wrote:
> > > >
> > > > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > > > >
> > > > >
> > > > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > > > >>
> > > > >
> > > > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > > > >
> > > >
> > > > Maybe some of Andrea's VM stuff?
> > >
> > > Definately. Thats the first thing I'm going to do after looking
> through
> > > "2.4.23-pre-patches" folder.
> >
> > any chance for the Bind Mount Extensions? 8-)
>
> I haven't found time to at the patch yet but will do so soon.
fine, no problem, let me know if you need something
(like rediff, resend, explanation, etc ...)
best,
Herbert
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-08-25 13:53 Marcelo Tosatti
2003-08-25 14:30 ` your mail Herbert Pötzl
0 siblings, 1 reply; 669+ messages in thread
From: Marcelo Tosatti @ 2003-08-25 13:53 UTC (permalink / raw)
To: Nick Piggin; +Cc: lkml
>
>
> Matthias Andree wrote:
>
> >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> >
> >
> >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> >>
> >
> >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> >
>
> Maybe some of Andrea's VM stuff?
Definately. Thats the first thing I'm going to do after looking through
"2.4.23-pre-patches" folder.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-08-25 13:53 Marcelo Tosatti
@ 2003-08-25 14:30 ` Herbert Pötzl
0 siblings, 0 replies; 669+ messages in thread
From: Herbert Pötzl @ 2003-08-25 14:30 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
>
> >
> >
> > Matthias Andree wrote:
> >
> > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > >
> > >
> > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > >>
> > >
> > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > >
> >
> > Maybe some of Andrea's VM stuff?
>
> Definately. Thats the first thing I'm going to do after looking through
> "2.4.23-pre-patches" folder.
any chance for the Bind Mount Extensions? 8-)
best,
Herbert
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-08-18 6:21 "Andrey Borzenkov"
2003-08-18 20:42 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: "Andrey Borzenkov" @ 2003-08-18 6:21 UTC (permalink / raw)
To: "jw schultz" ; +Cc: "Greg KH" , linux-kernel
> Actually you have not answered his question. And i think it
> a reasonable one. It could be it was answered elsewhere.
No it was not answered. Yes you got this exactly. Aparently my
englisg is not as bad after all ... :)
>>>>> Question: how to configure udev so that "database" always refers to LUN 0
>>>>> on target 0 on bus 0 on HBA in PCI slot 1.
>>> Let's avoid this communication problem. You show me namedev.config line that
>>> implements the above.
> I'll try to put slightly differently. I'll concede that we
> cannot positionaly identify USB devices so lets set that
> aside for the nonce. We can persistently, positionaly
> identify a device within the HBA context (BUS +ID + LUN) and
> should be able to do the same for a PCI HBA (PCI slot +
> device) or (PCI bridge topology).
actually you can. As Greg pointed out, topology rarely changes,
so it gives you enough information (of course if you constantly
add and remove USB hubs it becomes a bit of pain). But it has
the same problem - USB bus grows off PCI bus (usually) so adding
new USB controller possibly invalidates all configuration.
> So can i uniquely identify using persistent positional
> information a drive at PCI_slot=1, HBA_on_card=0, BUS=0,
> ID=1, LUN=0? And how do i uniquely identify it in the udev
> config file so that adding the same model drive in the same
> BUS+ID+LUN on an same model HBA card in another PCI slot
> does not confuse the two? If i cannot, can i at least do
> the identification so that adding ID=0,LUN=0 to the scsi buss
> doesn't cause a name change.
yep.
just to show what I expected from sysfs - here is entry from Solaris
/devices:
brw-r----- 1 root sys 32,240 Jan 24 2002 /devices/pci@16,4000/scsi@5,1/sd@0,0:a
this entry identifies disk partition 0 on drive with SCSI ID 0, LUN 0
connected to bus 1 of controller in slot 5 of PCI bus identified
by 16. Now you can use whatever policy you like to give human
meaningful name to this entry. And if you have USB it will continue
further giving you exact topology starting from the root of your
device tree.
and this path does not contain single logical id so it is not subject
to change if I add the same controller somewhere else.
hopefully it clarifies what I mean ...
regards
-andrey
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-08-18 6:21 "Andrey Borzenkov"
@ 2003-08-18 20:42 ` Greg KH
0 siblings, 0 replies; 669+ messages in thread
From: Greg KH @ 2003-08-18 20:42 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: jw schultz, linux-kernel
On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov" wrote:
>
> just to show what I expected from sysfs - here is entry from Solaris
> /devices:
>
> brw-r----- 1 root sys 32,240 Jan 24 2002 /devices/pci@16,4000/scsi@5,1/sd@0,0:a
>
> this entry identifies disk partition 0 on drive with SCSI ID 0, LUN 0
> connected to bus 1 of controller in slot 5 of PCI bus identified
> by 16. Now you can use whatever policy you like to give human
> meaningful name to this entry. And if you have USB it will continue
> further giving you exact topology starting from the root of your
> device tree.
>
> and this path does not contain single logical id so it is not subject
> to change if I add the same controller somewhere else.
>
> hopefully it clarifies what I mean ...
Hm, a bit. First, have you looked at what sysfs provides? Here's one
of my machines and tell me if it has all the info you are looking for:
$ tree /sys/bus/scsi/
/sys/bus/scsi/
|-- devices
| `-- 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
`-- drivers
`-- sd
`-- 0:0:0:0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
$ tree /sys/block/sda/
/sys/block/sda/
|-- dev
|-- device -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
|-- queue
| |-- iosched
| | |-- antic_expire
| | |-- read_batch_expire
| | |-- read_expire
| | |-- write_batch_expire
| | `-- write_expire
| `-- nr_requests
|-- range
|-- sda1
| |-- dev
| |-- size
| |-- start
| `-- stat
|-- sda2
| |-- dev
| |-- size
| |-- start
| `-- stat
|-- sda3
| |-- dev
| |-- size
| |-- start
| `-- stat
|-- sda4
| |-- dev
| |-- size
| |-- start
| `-- stat
|-- size
`-- stat
Now, from that you can see exactly where my scsi device is in the pci
tree, and you can see in the block directory, what block device is
assigned to what physical device in the device tree. Then there are 4
partitions on this disk, all what those specific paramaters.
So, when sda shows up, udev can determine that it lives on a specific
scsi device, located in a specific place in the pci space, and that it
has some number of partitions, all of specific sizes, wich specific
major/minor numbers. It can then create all of the /dev links based on
this.
Please, take a few minutes looking at the existing sysfs tree on Linux.
If you then have any specific questions, I would be glad to answer
them.
Hope this helps,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-08-14 21:57 kartikey bhatt
2003-08-15 3:31 ` your mail James Morris
0 siblings, 1 reply; 669+ messages in thread
From: kartikey bhatt @ 2003-08-14 21:57 UTC (permalink / raw)
To: jmorris; +Cc: davem, linux-kernel, alan
Hi James.
A little bit work for you.
Somebody on mailing list commented that you should *really* go for better
algorithm like CAST6 (rfc2612) to be included in kernel.
This time I'm sending you cast6.c (cast6 cipher algorithm) implementation.
But this time it's a patch.
I just want it get tested.
I've tested it on i386 against kernel version 2.6.0-test3.
Patch includes.
1. cast6.c (new).
2. tcrypt.c and tcrypt.h (modified).
-Bhatt Kartikey Mahendra <cloud # 9>
/*-------------------------------Begin
Patch----------------------------------*/
diff -u --recursive -N linux-2.6.0-test3/crypto/cast6.c linux/crypto/cast6.c
--- linux-2.6.0-test3/crypto/cast6.c 1970-01-01 05:30:00.000000000 +0530
+++ linux/crypto/cast6.c 2003-08-15 02:31:39.000000000 +0530
@@ -0,0 +1,562 @@
+/* Kernel cryptographic api.
+ * cast6.c - Cast6 cipher algorithm [rfc2612].
+ *
+ * CAST-256 (*cast6*) is a DES like Substitution-Permutation Network (SPN)
+ * cryptosystem built upon the CAST-128 (*cast5*) [rfc2144] encryption
+ * algorithm.
+ *
+ * Copyright (C) 2003 Kartikey Mahendra Bhatt <kartik_me@hotmail.com>.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your
option)
+ * any later version.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA
+ */
+
+
+#include <linux/init.h>
+#include <linux/crypto.h>
+#include <linux/module.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+
+#define CAST6_BLOCK_SIZE 16
+#define CAST6_MIN_KEY_SIZE 16
+#define CAST6_MAX_KEY_SIZE 32
+
+struct cast6_ctx {
+ u32 Km[12][4];
+ u8 Kr[12][4];
+};
+
+#define rol(n,x) ( ((x) << (n)) | ((x) >> (32-(n))) )
+
+#define F1(D,r,m) ( (I = ((m) + (D))), (I=rol((r),I)), \
+ (((s1[I >> 24] ^ s2[(I>>16)&0xff]) - s3[(I>>8)&0xff]) + s4[I&0xff]) )
+#define F2(D,r,m) ( (I = ((m) ^ (D))), (I=rol((r),I)), \
+ (((s1[I >> 24] - s2[(I>>16)&0xff]) + s3[(I>>8)&0xff]) ^ s4[I&0xff]) )
+#define F3(D,r,m) ( (I = ((m) - (D))), (I=rol((r),I)), \
+ (((s1[I >> 24] + s2[(I>>16)&0xff]) ^ s3[(I>>8)&0xff]) - s4[I&0xff]) )
+
+static const u32 s1[256] = {
+ 0x30fb40d4, 0x9fa0ff0b, 0x6beccd2f, 0x3f258c7a, 0x1e213f2f,
+ 0x9c004dd3, 0x6003e540, 0xcf9fc949,
+ 0xbfd4af27, 0x88bbbdb5, 0xe2034090, 0x98d09675, 0x6e63a0e0,
+ 0x15c361d2, 0xc2e7661d, 0x22d4ff8e,
+ 0x28683b6f, 0xc07fd059, 0xff2379c8, 0x775f50e2, 0x43c340d3,
+ 0xdf2f8656, 0x887ca41a, 0xa2d2bd2d,
+ 0xa1c9e0d6, 0x346c4819, 0x61b76d87, 0x22540f2f, 0x2abe32e1,
+ 0xaa54166b, 0x22568e3a, 0xa2d341d0,
+ 0x66db40c8, 0xa784392f, 0x004dff2f, 0x2db9d2de, 0x97943fac,
+ 0x4a97c1d8, 0x527644b7, 0xb5f437a7,
+ 0xb82cbaef, 0xd751d159, 0x6ff7f0ed, 0x5a097a1f, 0x827b68d0,
+ 0x90ecf52e, 0x22b0c054, 0xbc8e5935,
+ 0x4b6d2f7f, 0x50bb64a2, 0xd2664910, 0xbee5812d, 0xb7332290,
+ 0xe93b159f, 0xb48ee411, 0x4bff345d,
+ 0xfd45c240, 0xad31973f, 0xc4f6d02e, 0x55fc8165, 0xd5b1caad,
+ 0xa1ac2dae, 0xa2d4b76d, 0xc19b0c50,
+ 0x882240f2, 0x0c6e4f38, 0xa4e4bfd7, 0x4f5ba272, 0x564c1d2f,
+ 0xc59c5319, 0xb949e354, 0xb04669fe,
+ 0xb1b6ab8a, 0xc71358dd, 0x6385c545, 0x110f935d, 0x57538ad5,
+ 0x6a390493, 0xe63d37e0, 0x2a54f6b3,
+ 0x3a787d5f, 0x6276a0b5, 0x19a6fcdf, 0x7a42206a, 0x29f9d4d5,
+ 0xf61b1891, 0xbb72275e, 0xaa508167,
+ 0x38901091, 0xc6b505eb, 0x84c7cb8c, 0x2ad75a0f, 0x874a1427,
+ 0xa2d1936b, 0x2ad286af, 0xaa56d291,
+ 0xd7894360, 0x425c750d, 0x93b39e26, 0x187184c9, 0x6c00b32d,
+ 0x73e2bb14, 0xa0bebc3c, 0x54623779,
+ 0x64459eab, 0x3f328b82, 0x7718cf82, 0x59a2cea6, 0x04ee002e,
+ 0x89fe78e6, 0x3fab0950, 0x325ff6c2,
+ 0x81383f05, 0x6963c5c8, 0x76cb5ad6, 0xd49974c9, 0xca180dcf,
+ 0x380782d5, 0xc7fa5cf6, 0x8ac31511,
+ 0x35e79e13, 0x47da91d0, 0xf40f9086, 0xa7e2419e, 0x31366241,
+ 0x051ef495, 0xaa573b04, 0x4a805d8d,
+ 0x548300d0, 0x00322a3c, 0xbf64cddf, 0xba57a68e, 0x75c6372b,
+ 0x50afd341, 0xa7c13275, 0x915a0bf5,
+ 0x6b54bfab, 0x2b0b1426, 0xab4cc9d7, 0x449ccd82, 0xf7fbf265,
+ 0xab85c5f3, 0x1b55db94, 0xaad4e324,
+ 0xcfa4bd3f, 0x2deaa3e2, 0x9e204d02, 0xc8bd25ac, 0xeadf55b3,
+ 0xd5bd9e98, 0xe31231b2, 0x2ad5ad6c,
+ 0x954329de, 0xadbe4528, 0xd8710f69, 0xaa51c90f, 0xaa786bf6,
+ 0x22513f1e, 0xaa51a79b, 0x2ad344cc,
+ 0x7b5a41f0, 0xd37cfbad, 0x1b069505, 0x41ece491, 0xb4c332e6,
+ 0x032268d4, 0xc9600acc, 0xce387e6d,
+ 0xbf6bb16c, 0x6a70fb78, 0x0d03d9c9, 0xd4df39de, 0xe01063da,
+ 0x4736f464, 0x5ad328d8, 0xb347cc96,
+ 0x75bb0fc3, 0x98511bfb, 0x4ffbcc35, 0xb58bcf6a, 0xe11f0abc,
+ 0xbfc5fe4a, 0xa70aec10, 0xac39570a,
+ 0x3f04442f, 0x6188b153, 0xe0397a2e, 0x5727cb79, 0x9ceb418f,
+ 0x1cacd68d, 0x2ad37c96, 0x0175cb9d,
+ 0xc69dff09, 0xc75b65f0, 0xd9db40d8, 0xec0e7779, 0x4744ead4,
+ 0xb11c3274, 0xdd24cb9e, 0x7e1c54bd,
+ 0xf01144f9, 0xd2240eb1, 0x9675b3fd, 0xa3ac3755, 0xd47c27af,
+ 0x51c85f4d, 0x56907596, 0xa5bb15e6,
+ 0x580304f0, 0xca042cf1, 0x011a37ea, 0x8dbfaadb, 0x35ba3e4a,
+ 0x3526ffa0, 0xc37b4d09, 0xbc306ed9,
+ 0x98a52666, 0x5648f725, 0xff5e569d, 0x0ced63d0, 0x7c63b2cf,
+ 0x700b45e1, 0xd5ea50f1, 0x85a92872,
+ 0xaf1fbda7, 0xd4234870, 0xa7870bf3, 0x2d3b4d79, 0x42e04198,
+ 0x0cd0ede7, 0x26470db8, 0xf881814c,
+ 0x474d6ad7, 0x7c0c5e5c, 0xd1231959, 0x381b7298, 0xf5d2f4db,
+ 0xab838653, 0x6e2f1e23, 0x83719c9e,
+ 0xbd91e046, 0x9a56456e, 0xdc39200c, 0x20c8c571, 0x962bda1c,
+ 0xe1e696ff, 0xb141ab08, 0x7cca89b9,
+ 0x1a69e783, 0x02cc4843, 0xa2f7c579, 0x429ef47d, 0x427b169c,
+ 0x5ac9f049, 0xdd8f0f00, 0x5c8165bf
+};
+
+static const u32 s2[256] = {
+ 0x1f201094, 0xef0ba75b, 0x69e3cf7e, 0x393f4380, 0xfe61cf7a,
+ 0xeec5207a, 0x55889c94, 0x72fc0651,
+ 0xada7ef79, 0x4e1d7235, 0xd55a63ce, 0xde0436ba, 0x99c430ef,
+ 0x5f0c0794, 0x18dcdb7d, 0xa1d6eff3,
+ 0xa0b52f7b, 0x59e83605, 0xee15b094, 0xe9ffd909, 0xdc440086,
+ 0xef944459, 0xba83ccb3, 0xe0c3cdfb,
+ 0xd1da4181, 0x3b092ab1, 0xf997f1c1, 0xa5e6cf7b, 0x01420ddb,
+ 0xe4e7ef5b, 0x25a1ff41, 0xe180f806,
+ 0x1fc41080, 0x179bee7a, 0xd37ac6a9, 0xfe5830a4, 0x98de8b7f,
+ 0x77e83f4e, 0x79929269, 0x24fa9f7b,
+ 0xe113c85b, 0xacc40083, 0xd7503525, 0xf7ea615f, 0x62143154,
+ 0x0d554b63, 0x5d681121, 0xc866c359,
+ 0x3d63cf73, 0xcee234c0, 0xd4d87e87, 0x5c672b21, 0x071f6181,
+ 0x39f7627f, 0x361e3084, 0xe4eb573b,
+ 0x602f64a4, 0xd63acd9c, 0x1bbc4635, 0x9e81032d, 0x2701f50c,
+ 0x99847ab4, 0xa0e3df79, 0xba6cf38c,
+ 0x10843094, 0x2537a95e, 0xf46f6ffe, 0xa1ff3b1f, 0x208cfb6a,
+ 0x8f458c74, 0xd9e0a227, 0x4ec73a34,
+ 0xfc884f69, 0x3e4de8df, 0xef0e0088, 0x3559648d, 0x8a45388c,
+ 0x1d804366, 0x721d9bfd, 0xa58684bb,
+ 0xe8256333, 0x844e8212, 0x128d8098, 0xfed33fb4, 0xce280ae1,
+ 0x27e19ba5, 0xd5a6c252, 0xe49754bd,
+ 0xc5d655dd, 0xeb667064, 0x77840b4d, 0xa1b6a801, 0x84db26a9,
+ 0xe0b56714, 0x21f043b7, 0xe5d05860,
+ 0x54f03084, 0x066ff472, 0xa31aa153, 0xdadc4755, 0xb5625dbf,
+ 0x68561be6, 0x83ca6b94, 0x2d6ed23b,
+ 0xeccf01db, 0xa6d3d0ba, 0xb6803d5c, 0xaf77a709, 0x33b4a34c,
+ 0x397bc8d6, 0x5ee22b95, 0x5f0e5304,
+ 0x81ed6f61, 0x20e74364, 0xb45e1378, 0xde18639b, 0x881ca122,
+ 0xb96726d1, 0x8049a7e8, 0x22b7da7b,
+ 0x5e552d25, 0x5272d237, 0x79d2951c, 0xc60d894c, 0x488cb402,
+ 0x1ba4fe5b, 0xa4b09f6b, 0x1ca815cf,
+ 0xa20c3005, 0x8871df63, 0xb9de2fcb, 0x0cc6c9e9, 0x0beeff53,
+ 0xe3214517, 0xb4542835, 0x9f63293c,
+ 0xee41e729, 0x6e1d2d7c, 0x50045286, 0x1e6685f3, 0xf33401c6,
+ 0x30a22c95, 0x31a70850, 0x60930f13,
+ 0x73f98417, 0xa1269859, 0xec645c44, 0x52c877a9, 0xcdff33a6,
+ 0xa02b1741, 0x7cbad9a2, 0x2180036f,
+ 0x50d99c08, 0xcb3f4861, 0xc26bd765, 0x64a3f6ab, 0x80342676,
+ 0x25a75e7b, 0xe4e6d1fc, 0x20c710e6,
+ 0xcdf0b680, 0x17844d3b, 0x31eef84d, 0x7e0824e4, 0x2ccb49eb,
+ 0x846a3bae, 0x8ff77888, 0xee5d60f6,
+ 0x7af75673, 0x2fdd5cdb, 0xa11631c1, 0x30f66f43, 0xb3faec54,
+ 0x157fd7fa, 0xef8579cc, 0xd152de58,
+ 0xdb2ffd5e, 0x8f32ce19, 0x306af97a, 0x02f03ef8, 0x99319ad5,
+ 0xc242fa0f, 0xa7e3ebb0, 0xc68e4906,
+ 0xb8da230c, 0x80823028, 0xdcdef3c8, 0xd35fb171, 0x088a1bc8,
+ 0xbec0c560, 0x61a3c9e8, 0xbca8f54d,
+ 0xc72feffa, 0x22822e99, 0x82c570b4, 0xd8d94e89, 0x8b1c34bc,
+ 0x301e16e6, 0x273be979, 0xb0ffeaa6,
+ 0x61d9b8c6, 0x00b24869, 0xb7ffce3f, 0x08dc283b, 0x43daf65a,
+ 0xf7e19798, 0x7619b72f, 0x8f1c9ba4,
+ 0xdc8637a0, 0x16a7d3b1, 0x9fc393b7, 0xa7136eeb, 0xc6bcc63e,
+ 0x1a513742, 0xef6828bc, 0x520365d6,
+ 0x2d6a77ab, 0x3527ed4b, 0x821fd216, 0x095c6e2e, 0xdb92f2fb,
+ 0x5eea29cb, 0x145892f5, 0x91584f7f,
+ 0x5483697b, 0x2667a8cc, 0x85196048, 0x8c4bacea, 0x833860d4,
+ 0x0d23e0f9, 0x6c387e8a, 0x0ae6d249,
+ 0xb284600c, 0xd835731d, 0xdcb1c647, 0xac4c56ea, 0x3ebd81b3,
+ 0x230eabb0, 0x6438bc87, 0xf0b5b1fa,
+ 0x8f5ea2b3, 0xfc184642, 0x0a036b7a, 0x4fb089bd, 0x649da589,
+ 0xa345415e, 0x5c038323, 0x3e5d3bb9,
+ 0x43d79572, 0x7e6dd07c, 0x06dfdf1e, 0x6c6cc4ef, 0x7160a539,
+ 0x73bfbe70, 0x83877605, 0x4523ecf1
+};
+
+static const u32 s3[256] = {
+ 0x8defc240, 0x25fa5d9f, 0xeb903dbf, 0xe810c907, 0x47607fff,
+ 0x369fe44b, 0x8c1fc644, 0xaececa90,
+ 0xbeb1f9bf, 0xeefbcaea, 0xe8cf1950, 0x51df07ae, 0x920e8806,
+ 0xf0ad0548, 0xe13c8d83, 0x927010d5,
+ 0x11107d9f, 0x07647db9, 0xb2e3e4d4, 0x3d4f285e, 0xb9afa820,
+ 0xfade82e0, 0xa067268b, 0x8272792e,
+ 0x553fb2c0, 0x489ae22b, 0xd4ef9794, 0x125e3fbc, 0x21fffcee,
+ 0x825b1bfd, 0x9255c5ed, 0x1257a240,
+ 0x4e1a8302, 0xbae07fff, 0x528246e7, 0x8e57140e, 0x3373f7bf,
+ 0x8c9f8188, 0xa6fc4ee8, 0xc982b5a5,
+ 0xa8c01db7, 0x579fc264, 0x67094f31, 0xf2bd3f5f, 0x40fff7c1,
+ 0x1fb78dfc, 0x8e6bd2c1, 0x437be59b,
+ 0x99b03dbf, 0xb5dbc64b, 0x638dc0e6, 0x55819d99, 0xa197c81c,
+ 0x4a012d6e, 0xc5884a28, 0xccc36f71,
+ 0xb843c213, 0x6c0743f1, 0x8309893c, 0x0feddd5f, 0x2f7fe850,
+ 0xd7c07f7e, 0x02507fbf, 0x5afb9a04,
+ 0xa747d2d0, 0x1651192e, 0xaf70bf3e, 0x58c31380, 0x5f98302e,
+ 0x727cc3c4, 0x0a0fb402, 0x0f7fef82,
+ 0x8c96fdad, 0x5d2c2aae, 0x8ee99a49, 0x50da88b8, 0x8427f4a0,
+ 0x1eac5790, 0x796fb449, 0x8252dc15,
+ 0xefbd7d9b, 0xa672597d, 0xada840d8, 0x45f54504, 0xfa5d7403,
+ 0xe83ec305, 0x4f91751a, 0x925669c2,
+ 0x23efe941, 0xa903f12e, 0x60270df2, 0x0276e4b6, 0x94fd6574,
+ 0x927985b2, 0x8276dbcb, 0x02778176,
+ 0xf8af918d, 0x4e48f79e, 0x8f616ddf, 0xe29d840e, 0x842f7d83,
+ 0x340ce5c8, 0x96bbb682, 0x93b4b148,
+ 0xef303cab, 0x984faf28, 0x779faf9b, 0x92dc560d, 0x224d1e20,
+ 0x8437aa88, 0x7d29dc96, 0x2756d3dc,
+ 0x8b907cee, 0xb51fd240, 0xe7c07ce3, 0xe566b4a1, 0xc3e9615e,
+ 0x3cf8209d, 0x6094d1e3, 0xcd9ca341,
+ 0x5c76460e, 0x00ea983b, 0xd4d67881, 0xfd47572c, 0xf76cedd9,
+ 0xbda8229c, 0x127dadaa, 0x438a074e,
+ 0x1f97c090, 0x081bdb8a, 0x93a07ebe, 0xb938ca15, 0x97b03cff,
+ 0x3dc2c0f8, 0x8d1ab2ec, 0x64380e51,
+ 0x68cc7bfb, 0xd90f2788, 0x12490181, 0x5de5ffd4, 0xdd7ef86a,
+ 0x76a2e214, 0xb9a40368, 0x925d958f,
+ 0x4b39fffa, 0xba39aee9, 0xa4ffd30b, 0xfaf7933b, 0x6d498623,
+ 0x193cbcfa, 0x27627545, 0x825cf47a,
+ 0x61bd8ba0, 0xd11e42d1, 0xcead04f4, 0x127ea392, 0x10428db7,
+ 0x8272a972, 0x9270c4a8, 0x127de50b,
+ 0x285ba1c8, 0x3c62f44f, 0x35c0eaa5, 0xe805d231, 0x428929fb,
+ 0xb4fcdf82, 0x4fb66a53, 0x0e7dc15b,
+ 0x1f081fab, 0x108618ae, 0xfcfd086d, 0xf9ff2889, 0x694bcc11,
+ 0x236a5cae, 0x12deca4d, 0x2c3f8cc5,
+ 0xd2d02dfe, 0xf8ef5896, 0xe4cf52da, 0x95155b67, 0x494a488c,
+ 0xb9b6a80c, 0x5c8f82bc, 0x89d36b45,
+ 0x3a609437, 0xec00c9a9, 0x44715253, 0x0a874b49, 0xd773bc40,
+ 0x7c34671c, 0x02717ef6, 0x4feb5536,
+ 0xa2d02fff, 0xd2bf60c4, 0xd43f03c0, 0x50b4ef6d, 0x07478cd1,
+ 0x006e1888, 0xa2e53f55, 0xb9e6d4bc,
+ 0xa2048016, 0x97573833, 0xd7207d67, 0xde0f8f3d, 0x72f87b33,
+ 0xabcc4f33, 0x7688c55d, 0x7b00a6b0,
+ 0x947b0001, 0x570075d2, 0xf9bb88f8, 0x8942019e, 0x4264a5ff,
+ 0x856302e0, 0x72dbd92b, 0xee971b69,
+ 0x6ea22fde, 0x5f08ae2b, 0xaf7a616d, 0xe5c98767, 0xcf1febd2,
+ 0x61efc8c2, 0xf1ac2571, 0xcc8239c2,
+ 0x67214cb8, 0xb1e583d1, 0xb7dc3e62, 0x7f10bdce, 0xf90a5c38,
+ 0x0ff0443d, 0x606e6dc6, 0x60543a49,
+ 0x5727c148, 0x2be98a1d, 0x8ab41738, 0x20e1be24, 0xaf96da0f,
+ 0x68458425, 0x99833be5, 0x600d457d,
+ 0x282f9350, 0x8334b362, 0xd91d1120, 0x2b6d8da0, 0x642b1e31,
+ 0x9c305a00, 0x52bce688, 0x1b03588a,
+ 0xf7baefd5, 0x4142ed9c, 0xa4315c11, 0x83323ec5, 0xdfef4636,
+ 0xa133c501, 0xe9d3531c, 0xee353783
+};
+
+static const u32 s4[256] = {
+ 0x9db30420, 0x1fb6e9de, 0xa7be7bef, 0xd273a298, 0x4a4f7bdb,
+ 0x64ad8c57, 0x85510443, 0xfa020ed1,
+ 0x7e287aff, 0xe60fb663, 0x095f35a1, 0x79ebf120, 0xfd059d43,
+ 0x6497b7b1, 0xf3641f63, 0x241e4adf,
+ 0x28147f5f, 0x4fa2b8cd, 0xc9430040, 0x0cc32220, 0xfdd30b30,
+ 0xc0a5374f, 0x1d2d00d9, 0x24147b15,
+ 0xee4d111a, 0x0fca5167, 0x71ff904c, 0x2d195ffe, 0x1a05645f,
+ 0x0c13fefe, 0x081b08ca, 0x05170121,
+ 0x80530100, 0xe83e5efe, 0xac9af4f8, 0x7fe72701, 0xd2b8ee5f,
+ 0x06df4261, 0xbb9e9b8a, 0x7293ea25,
+ 0xce84ffdf, 0xf5718801, 0x3dd64b04, 0xa26f263b, 0x7ed48400,
+ 0x547eebe6, 0x446d4ca0, 0x6cf3d6f5,
+ 0x2649abdf, 0xaea0c7f5, 0x36338cc1, 0x503f7e93, 0xd3772061,
+ 0x11b638e1, 0x72500e03, 0xf80eb2bb,
+ 0xabe0502e, 0xec8d77de, 0x57971e81, 0xe14f6746, 0xc9335400,
+ 0x6920318f, 0x081dbb99, 0xffc304a5,
+ 0x4d351805, 0x7f3d5ce3, 0xa6c866c6, 0x5d5bcca9, 0xdaec6fea,
+ 0x9f926f91, 0x9f46222f, 0x3991467d,
+ 0xa5bf6d8e, 0x1143c44f, 0x43958302, 0xd0214eeb, 0x022083b8,
+ 0x3fb6180c, 0x18f8931e, 0x281658e6,
+ 0x26486e3e, 0x8bd78a70, 0x7477e4c1, 0xb506e07c, 0xf32d0a25,
+ 0x79098b02, 0xe4eabb81, 0x28123b23,
+ 0x69dead38, 0x1574ca16, 0xdf871b62, 0x211c40b7, 0xa51a9ef9,
+ 0x0014377b, 0x041e8ac8, 0x09114003,
+ 0xbd59e4d2, 0xe3d156d5, 0x4fe876d5, 0x2f91a340, 0x557be8de,
+ 0x00eae4a7, 0x0ce5c2ec, 0x4db4bba6,
+ 0xe756bdff, 0xdd3369ac, 0xec17b035, 0x06572327, 0x99afc8b0,
+ 0x56c8c391, 0x6b65811c, 0x5e146119,
+ 0x6e85cb75, 0xbe07c002, 0xc2325577, 0x893ff4ec, 0x5bbfc92d,
+ 0xd0ec3b25, 0xb7801ab7, 0x8d6d3b24,
+ 0x20c763ef, 0xc366a5fc, 0x9c382880, 0x0ace3205, 0xaac9548a,
+ 0xeca1d7c7, 0x041afa32, 0x1d16625a,
+ 0x6701902c, 0x9b757a54, 0x31d477f7, 0x9126b031, 0x36cc6fdb,
+ 0xc70b8b46, 0xd9e66a48, 0x56e55a79,
+ 0x026a4ceb, 0x52437eff, 0x2f8f76b4, 0x0df980a5, 0x8674cde3,
+ 0xedda04eb, 0x17a9be04, 0x2c18f4df,
+ 0xb7747f9d, 0xab2af7b4, 0xefc34d20, 0x2e096b7c, 0x1741a254,
+ 0xe5b6a035, 0x213d42f6, 0x2c1c7c26,
+ 0x61c2f50f, 0x6552daf9, 0xd2c231f8, 0x25130f69, 0xd8167fa2,
+ 0x0418f2c8, 0x001a96a6, 0x0d1526ab,
+ 0x63315c21, 0x5e0a72ec, 0x49bafefd, 0x187908d9, 0x8d0dbd86,
+ 0x311170a7, 0x3e9b640c, 0xcc3e10d7,
+ 0xd5cad3b6, 0x0caec388, 0xf73001e1, 0x6c728aff, 0x71eae2a1,
+ 0x1f9af36e, 0xcfcbd12f, 0xc1de8417,
+ 0xac07be6b, 0xcb44a1d8, 0x8b9b0f56, 0x013988c3, 0xb1c52fca,
+ 0xb4be31cd, 0xd8782806, 0x12a3a4e2,
+ 0x6f7de532, 0x58fd7eb6, 0xd01ee900, 0x24adffc2, 0xf4990fc5,
+ 0x9711aac5, 0x001d7b95, 0x82e5e7d2,
+ 0x109873f6, 0x00613096, 0xc32d9521, 0xada121ff, 0x29908415,
+ 0x7fbb977f, 0xaf9eb3db, 0x29c9ed2a,
+ 0x5ce2a465, 0xa730f32c, 0xd0aa3fe8, 0x8a5cc091, 0xd49e2ce7,
+ 0x0ce454a9, 0xd60acd86, 0x015f1919,
+ 0x77079103, 0xdea03af6, 0x78a8565e, 0xdee356df, 0x21f05cbe,
+ 0x8b75e387, 0xb3c50651, 0xb8a5c3ef,
+ 0xd8eeb6d2, 0xe523be77, 0xc2154529, 0x2f69efdf, 0xafe67afb,
+ 0xf470c4b2, 0xf3e0eb5b, 0xd6cc9876,
+ 0x39e4460c, 0x1fda8538, 0x1987832f, 0xca007367, 0xa99144f8,
+ 0x296b299e, 0x492fc295, 0x9266beab,
+ 0xb5676e69, 0x9bd3ddda, 0xdf7e052f, 0xdb25701c, 0x1b5e51ee,
+ 0xf65324e6, 0x6afce36c, 0x0316cc04,
+ 0x8644213e, 0xb7dc59d0, 0x7965291f, 0xccd6fd43, 0x41823979,
+ 0x932bcdf6, 0xb657c34d, 0x4edfd282,
+ 0x7ae5290c, 0x3cb9536b, 0x851e20fe, 0x9833557e, 0x13ecf0b0,
+ 0xd3ffb372, 0x3f85c5c1, 0x0aef7ed2
+};
+
+static const u32 Tm[24][8] = {
+ { 0x5a827999, 0xc95c653a, 0x383650db, 0xa7103c7c, 0x15ea281d,
+ 0x84c413be, 0xf39dff5f, 0x6277eb00 } ,
+ { 0xd151d6a1, 0x402bc242, 0xaf05ade3, 0x1ddf9984, 0x8cb98525,
+ 0xfb9370c6, 0x6a6d5c67, 0xd9474808 } ,
+ { 0x482133a9, 0xb6fb1f4a, 0x25d50aeb, 0x94aef68c, 0x0388e22d,
+ 0x7262cdce, 0xe13cb96f, 0x5016a510 } ,
+ { 0xbef090b1, 0x2dca7c52, 0x9ca467f3, 0x0b7e5394, 0x7a583f35,
+ 0xe9322ad6, 0x580c1677, 0xc6e60218 } ,
+ { 0x35bfedb9, 0xa499d95a, 0x1373c4fb, 0x824db09c, 0xf1279c3d,
+ 0x600187de, 0xcedb737f, 0x3db55f20 } ,
+ { 0xac8f4ac1, 0x1b693662, 0x8a432203, 0xf91d0da4, 0x67f6f945,
+ 0xd6d0e4e6, 0x45aad087, 0xb484bc28 } ,
+ { 0x235ea7c9, 0x9238936a, 0x01127f0b, 0x6fec6aac, 0xdec6564d,
+ 0x4da041ee, 0xbc7a2d8f, 0x2b541930 } ,
+ { 0x9a2e04d1, 0x0907f072, 0x77e1dc13, 0xe6bbc7b4, 0x5595b355,
+ 0xc46f9ef6, 0x33498a97, 0xa2237638 } ,
+ { 0x10fd61d9, 0x7fd74d7a, 0xeeb1391b, 0x5d8b24bc, 0xcc65105d,
+ 0x3b3efbfe, 0xaa18e79f, 0x18f2d340 } ,
+ { 0x87ccbee1, 0xf6a6aa82, 0x65809623, 0xd45a81c4, 0x43346d65,
+ 0xb20e5906, 0x20e844a7, 0x8fc23048 } ,
+ { 0xfe9c1be9, 0x6d76078a, 0xdc4ff32b, 0x4b29decc, 0xba03ca6d,
+ 0x28ddb60e, 0x97b7a1af, 0x06918d50 } ,
+ { 0x756b78f1, 0xe4456492, 0x531f5033, 0xc1f93bd4, 0x30d32775,
+ 0x9fad1316, 0x0e86feb7, 0x7d60ea58 } ,
+ { 0xec3ad5f9, 0x5b14c19a, 0xc9eead3b, 0x38c898dc, 0xa7a2847d,
+ 0x167c701e, 0x85565bbf, 0xf4304760 } ,
+ { 0x630a3301, 0xd1e41ea2, 0x40be0a43, 0xaf97f5e4, 0x1e71e185,
+ 0x8d4bcd26, 0xfc25b8c7, 0x6affa468 } ,
+ { 0xd9d99009, 0x48b37baa, 0xb78d674b, 0x266752ec, 0x95413e8d,
+ 0x041b2a2e, 0x72f515cf, 0xe1cf0170 } ,
+ { 0x50a8ed11, 0xbf82d8b2, 0x2e5cc453, 0x9d36aff4, 0x0c109b95,
+ 0x7aea8736, 0xe9c472d7, 0x589e5e78 } ,
+ { 0xc7784a19, 0x365235ba, 0xa52c215b, 0x14060cfc, 0x82dff89d,
+ 0xf1b9e43e, 0x6093cfdf, 0xcf6dbb80 } ,
+ { 0x3e47a721, 0xad2192c2, 0x1bfb7e63, 0x8ad56a04, 0xf9af55a5,
+ 0x68894146, 0xd7632ce7, 0x463d1888 } ,
+ { 0xb5170429, 0x23f0efca, 0x92cadb6b, 0x01a4c70c, 0x707eb2ad,
+ 0xdf589e4e, 0x4e3289ef, 0xbd0c7590 } ,
+ { 0x2be66131, 0x9ac04cd2, 0x099a3873, 0x78742414, 0xe74e0fb5,
+ 0x5627fb56, 0xc501e6f7, 0x33dbd298 } ,
+ { 0xa2b5be39, 0x118fa9da, 0x8069957b, 0xef43811c, 0x5e1d6cbd,
+ 0xccf7585e, 0x3bd143ff, 0xaaab2fa0 } ,
+ { 0x19851b41, 0x885f06e2, 0xf738f283, 0x6612de24, 0xd4ecc9c5,
+ 0x43c6b566, 0xb2a0a107, 0x217a8ca8 } ,
+ { 0x90547849, 0xff2e63ea, 0x6e084f8b, 0xdce23b2c, 0x4bbc26cd,
+ 0xba96126e, 0x296ffe0f, 0x9849e9b0 } ,
+ { 0x0723d551, 0x75fdc0f2, 0xe4d7ac93, 0x53b19834, 0xc28b83d5,
+ 0x31656f76, 0xa03f5b17, 0x0f1946b8 }
+};
+
+static const u8 Tr[4][8] = {
+ { 0x13, 0x04, 0x15, 0x06, 0x17, 0x08, 0x19, 0x0a } ,
+ { 0x1b, 0x0c, 0x1d, 0x0e, 0x1f, 0x10, 0x01, 0x12 } ,
+ { 0x03, 0x14, 0x05, 0x16, 0x07, 0x18, 0x09, 0x1a } ,
+ { 0x0b, 0x1c, 0x0d, 0x1e, 0x0f, 0x00, 0x11, 0x02 }
+};
+
+/* forward octave */
+static inline void W(u32 *key, unsigned int i) {
+ u32 I;
+ key[6] ^= F1(key[7], Tr[i % 4][0], Tm[i][0]);
+ key[5] ^= F2(key[6], Tr[i % 4][1], Tm[i][1]);
+ key[4] ^= F3(key[5], Tr[i % 4][2], Tm[i][2]);
+ key[3] ^= F1(key[4], Tr[i % 4][3], Tm[i][3]);
+ key[2] ^= F2(key[3], Tr[i % 4][4], Tm[i][4]);
+ key[1] ^= F3(key[2], Tr[i % 4][5], Tm[i][5]);
+ key[0] ^= F1(key[1], Tr[i % 4][6], Tm[i][6]);
+ key[7] ^= F2(key[0], Tr[i % 4][7], Tm[i][7]);
+}
+
+static int
+cast6_setkey(void *ctx, const u8 * in_key, unsigned key_len, u32 * flags)
+{
+ int i;
+ u32 key[8];
+ u8 p_key[32]; /* padded key */
+
+ if (key_len < 16 || key_len > 32 || key_len % 4 != 0) {
+ *flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+ return -EINVAL;
+ }
+
+ memset (p_key, 0, 32);
+ memcpy (p_key, in_key, key_len);
+
+ key[0] = p_key[0] << 24 | p_key[1] << 16 | p_key[2] << 8 | p_key[3]; /* A
*/
+ key[1] = p_key[4] << 24 | p_key[5] << 16 | p_key[6] << 8 | p_key[7]; /* B
*/
+ key[2] = p_key[8] << 24 | p_key[9] << 16 | p_key[10] << 8 | p_key[11]; /*
C */
+ key[3] = p_key[12] << 24 | p_key[13] << 16 | p_key[14] << 8 |
p_key[15]; /* D */
+ key[4] = p_key[16] << 24 | p_key[17] << 16 | p_key[18] << 8 |
p_key[19]; /* E */
+ key[5] = p_key[20] << 24 | p_key[21] << 16 | p_key[22] << 8 |
p_key[23]; /* F */
+ key[6] = p_key[24] << 24 | p_key[25] << 16 | p_key[26] << 8 |
p_key[27]; /* G */
+ key[7] = p_key[28] << 24 | p_key[29] << 16 | p_key[30] << 8 |
p_key[31]; /* H */
+
+ struct cast6_ctx *c = (struct cast6_ctx *) ctx;
+
+ for (i = 0; i < 12; i++) {
+ W (key, 2 * i);
+ W (key, 2 * i + 1);
+
+ c->Kr[i][0] = key[0] & 0x1f;
+ c->Kr[i][1] = key[2] & 0x1f;
+ c->Kr[i][2] = key[4] & 0x1f;
+ c->Kr[i][3] = key[6] & 0x1f;
+
+ c->Km[i][0] = key[7];
+ c->Km[i][1] = key[5];
+ c->Km[i][2] = key[3];
+ c->Km[i][3] = key[1];
+ }
+
+ return 0;
+}
+
+/*forward quad round*/
+static inline void Q (u32 * block, u8 * Kr, u32 * Km) {
+ u32 I;
+ block[2] ^= F1(block[3], Kr[0], Km[0]);
+ block[1] ^= F2(block[2], Kr[1], Km[1]);
+ block[0] ^= F3(block[1], Kr[2], Km[2]);
+ block[3] ^= F1(block[0], Kr[3], Km[3]);
+}
+
+/*reverse quad round*/
+static inline void QBAR (u32 * block, u8 * Kr, u32 * Km) {
+ u32 I;
+ block[3] ^= F1(block[0], Kr[3], Km[3]);
+ block[0] ^= F3(block[1], Kr[2], Km[2]);
+ block[1] ^= F2(block[2], Kr[1], Km[1]);
+ block[2] ^= F1(block[3], Kr[0], Km[0]);
+}
+
+static void cast6_encrypt (void * ctx, u8 * outbuf, const u8 * inbuf) {
+ struct cast6_ctx * c = (struct cast6_ctx *)ctx;
+ u32 block[4];
+ u32 * Km;
+ u8 * Kr;
+
+ block[0] = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3];
+ block[1] = inbuf[4] << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7];
+ block[2] = inbuf[8] << 24 | inbuf[9] << 16 | inbuf[10] << 8 | inbuf[11];
+ block[3] = inbuf[12] << 24 | inbuf[13] << 16 | inbuf[14] << 8 | inbuf[15];
+
+ Km = c->Km[0]; Kr = c->Kr[0]; Q (block, Kr, Km);
+ Km = c->Km[1]; Kr = c->Kr[1]; Q (block, Kr, Km);
+ Km = c->Km[2]; Kr = c->Kr[2]; Q (block, Kr, Km);
+ Km = c->Km[3]; Kr = c->Kr[3]; Q (block, Kr, Km);
+ Km = c->Km[4]; Kr = c->Kr[4]; Q (block, Kr, Km);
+ Km = c->Km[5]; Kr = c->Kr[5]; Q (block, Kr, Km);
+ Km = c->Km[6]; Kr = c->Kr[6]; QBAR (block, Kr, Km);
+ Km = c->Km[7]; Kr = c->Kr[7]; QBAR (block, Kr, Km);
+ Km = c->Km[8]; Kr = c->Kr[8]; QBAR (block, Kr, Km);
+ Km = c->Km[9]; Kr = c->Kr[9]; QBAR (block, Kr, Km);
+ Km = c->Km[10]; Kr = c->Kr[10]; QBAR (block, Kr, Km);
+ Km = c->Km[11]; Kr = c->Kr[11]; QBAR (block, Kr, Km);
+
+ outbuf[0] = (block[0] >> 24) & 0xff;
+ outbuf[1] = (block[0] >> 16) & 0xff;
+ outbuf[2] = (block[0] >> 8) & 0xff;
+ outbuf[3] = block[0] & 0xff;
+ outbuf[4] = (block[1] >> 24) & 0xff;
+ outbuf[5] = (block[1] >> 16) & 0xff;
+ outbuf[6] = (block[1] >> 8) & 0xff;
+ outbuf[7] = block[1] & 0xff;
+ outbuf[8] = (block[2] >> 24) & 0xff;
+ outbuf[9] = (block[2] >> 16) & 0xff;
+ outbuf[10] = (block[2] >> 8) & 0xff;
+ outbuf[11] = block[2] & 0xff;
+ outbuf[12] = (block[3] >> 24) & 0xff;
+ outbuf[13] = (block[3] >> 16) & 0xff;
+ outbuf[14] = (block[3] >> 8) & 0xff;
+ outbuf[15] = block[3] & 0xff;
+}
+
+static void cast6_decrypt (void * ctx, u8 * outbuf, const u8 * inbuf) {
+ struct cast6_ctx * c = (struct cast6_ctx *)ctx;
+ u32 block[4];
+ u32 * Km;
+ u8 * Kr;
+
+ block[0] = inbuf[0] << 24 | inbuf[1] << 16 | inbuf[2] << 8 | inbuf[3];
+ block[1] = inbuf[4] << 24 | inbuf[5] << 16 | inbuf[6] << 8 | inbuf[7];
+ block[2] = inbuf[8] << 24 | inbuf[9] << 16 | inbuf[10] << 8 | inbuf[11];
+ block[3] = inbuf[12] << 24 | inbuf[13] << 16 | inbuf[14] << 8 | inbuf[15];
+
+ Km = c->Km[11]; Kr = c->Kr[11]; Q (block, Kr, Km);
+ Km = c->Km[10]; Kr = c->Kr[10]; Q (block, Kr, Km);
+ Km = c->Km[9]; Kr = c->Kr[9]; Q (block, Kr, Km);
+ Km = c->Km[8]; Kr = c->Kr[8]; Q (block, Kr, Km);
+ Km = c->Km[7]; Kr = c->Kr[7]; Q (block, Kr, Km);
+ Km = c->Km[6]; Kr = c->Kr[6]; Q (block, Kr, Km);
+ Km = c->Km[5]; Kr = c->Kr[5]; QBAR (block, Kr, Km);
+ Km = c->Km[4]; Kr = c->Kr[4]; QBAR (block, Kr, Km);
+ Km = c->Km[3]; Kr = c->Kr[3]; QBAR (block, Kr, Km);
+ Km = c->Km[2]; Kr = c->Kr[2]; QBAR (block, Kr, Km);
+ Km = c->Km[1]; Kr = c->Kr[1]; QBAR (block, Kr, Km);
+ Km = c->Km[0]; Kr = c->Kr[0]; QBAR (block, Kr, Km);
+
+ outbuf[0] = (block[0] >> 24) & 0xff;
+ outbuf[1] = (block[0] >> 16) & 0xff;
+ outbuf[2] = (block[0] >> 8) & 0xff;
+ outbuf[3] = block[0] & 0xff;
+ outbuf[4] = (block[1] >> 24) & 0xff;
+ outbuf[5] = (block[1] >> 16) & 0xff;
+ outbuf[6] = (block[1] >> 8) & 0xff;
+ outbuf[7] = block[1] & 0xff;
+ outbuf[8] = (block[2] >> 24) & 0xff;
+ outbuf[9] = (block[2] >> 16) & 0xff;
+ outbuf[10] = (block[2] >> 8) & 0xff;
+ outbuf[11] = block[2] & 0xff;
+ outbuf[12] = (block[3] >> 24) & 0xff;
+ outbuf[13] = (block[3] >> 16) & 0xff;
+ outbuf[14] = (block[3] >> 8) & 0xff;
+ outbuf[15] = block[3] & 0xff;
+}
+
+static struct crypto_alg alg = {
+ .cra_name = "cast6",
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra_blocksize = CAST6_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct cast6_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_list = LIST_HEAD_INIT(alg.cra_list),
+ .cra_u = {
+ .cipher = {
+ .cia_min_keysize = CAST6_MIN_KEY_SIZE,
+ .cia_max_keysize = CAST6_MAX_KEY_SIZE,
+ .cia_ivsize = CAST6_BLOCK_SIZE,
+ .cia_setkey = cast6_setkey,
+ .cia_encrypt = cast6_encrypt,
+ .cia_decrypt = cast6_decrypt}
+ }
+};
+
+static int __init init(void)
+{
+ return crypto_register_alg(&alg);
+}
+
+static void __exit fini(void)
+{
+ crypto_unregister_alg(&alg);
+}
+
+module_init(init);
+module_exit(fini);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Cast6 Cipher Algorithm");
diff -u --recursive -N linux-2.6.0-test3/crypto/tcrypt.c
linux/crypto/tcrypt.c
--- linux-2.6.0-test3/crypto/tcrypt.c 2003-08-15 02:27:13.000000000 +0530
+++ linux/crypto/tcrypt.c 2003-08-15 02:31:54.000000000 +0530
@@ -48,8 +48,8 @@
static char *check[] = {
"des", "md5", "des3_ede", "rot13", "sha1", "sha256", "blowfish",
- "twofish", "serpent", "sha384", "sha512", "md4", "aes", "deflate",
- NULL
+ "twofish", "serpent", "sha384", "sha512", "md4", "aes", "cast6",
+ "deflate", NULL
};
static void
@@ -2087,6 +2087,105 @@
crypto_free_tfm(tfm);
}
+static void
+test_cast6(void)
+{
+ unsigned int ret, i, tsize;
+ u8 *p, *q, *key;
+ struct crypto_tfm *tfm;
+ struct cast6_tv *cast_tv;
+ struct scatterlist sg[1];
+
+ printk("\ntesting cast6 encryption\n");
+
+ tfm = crypto_alloc_tfm("cast6", 0);
+ if (tfm == NULL) {
+ printk("failed to load transform for cast6 (default ecb)\n");
+ return;
+ }
+
+ tsize = sizeof (cast6_enc_tv_template);
+ if (tsize > TVMEMSIZE) {
+ printk("template (%u) too big for tvmem (%u)\n", tsize,
+ TVMEMSIZE);
+ return;
+ }
+
+ memcpy(tvmem, cast6_enc_tv_template, tsize);
+ cast_tv = (void *) tvmem;
+ for (i = 0; i < CAST6_ENC_TEST_VECTORS; i++) {
+ printk("test %u (%d bit key):\n", i + 1, cast_tv[i].keylen * 8);
+ key = cast_tv[i].key;
+
+ ret = crypto_cipher_setkey(tfm, key, cast_tv[i].keylen);
+ if (ret) {
+ printk("setkey() failed flags=%x\n", tfm->crt_flags);
+
+ if (!cast_tv[i].fail)
+ goto out;
+ }
+
+ p = cast_tv[i].plaintext;
+ sg[0].page = virt_to_page(p);
+ sg[0].offset = ((long) p & ~PAGE_MASK);
+ sg[0].length = sizeof(cast_tv[i].plaintext);
+ ret = crypto_cipher_encrypt(tfm, sg, sg, sg[0].length);
+ if (ret) {
+ printk("encrypt() failed flags=%x\n", tfm->crt_flags);
+ goto out;
+ }
+
+ q = kmap(sg[0].page) + sg[0].offset;
+ hexdump(q, sizeof(cast_tv[i].result));
+
+ printk("%s\n", memcmp(q, cast_tv[i].result,
+ sizeof(cast_tv[i].result)) ? "fail" : "pass");
+ }
+
+ printk("\ntesting cast6 decryption\n");
+
+ tsize = sizeof (cast6_dec_tv_template);
+ if (tsize > TVMEMSIZE) {
+ printk("template (%u) too big for tvmem (%u)\n", tsize,
+ TVMEMSIZE);
+ return;
+ }
+
+ memcpy(tvmem, cast6_dec_tv_template, tsize);
+ cast_tv = (void *) tvmem;
+ for (i = 0; i < CAST6_DEC_TEST_VECTORS; i++) {
+ printk("test %u (%d bit key):\n", i + 1, cast_tv[i].keylen * 8);
+ key = cast_tv[i].key;
+
+ ret = crypto_cipher_setkey(tfm, key, cast_tv[i].keylen);
+ if (ret) {
+ printk("setkey() failed flags=%x\n", tfm->crt_flags);
+
+ if (!cast_tv[i].fail)
+ goto out;
+ }
+
+ p = cast_tv[i].plaintext;
+ sg[0].page = virt_to_page(p);
+ sg[0].offset = ((long) p & ~PAGE_MASK);
+ sg[0].length = sizeof(cast_tv[i].plaintext);
+ ret = crypto_cipher_decrypt(tfm, sg, sg, sg[0].length);
+ if (ret) {
+ printk("decrypt() failed flags=%x\n", tfm->crt_flags);
+ goto out;
+ }
+
+ q = kmap(sg[0].page) + sg[0].offset;
+ hexdump(q, sizeof(cast_tv[i].result));
+
+ printk("%s\n", memcmp(q, cast_tv[i].result,
+ sizeof(cast_tv[i].result)) ? "fail" : "pass");
+ }
+
+out:
+ crypto_free_tfm(tfm);
+}
+
void
test_aes(void)
{
@@ -2300,6 +2399,7 @@
test_blowfish();
test_twofish();
test_serpent();
+ test_cast6();
test_aes();
test_sha384();
test_sha512();
@@ -2363,6 +2463,8 @@
test_deflate();
break;
+ case 14: test_cast6();
+
#ifdef CONFIG_CRYPTO_HMAC
case 100:
test_hmac_md5();
diff -u --recursive -N linux-2.6.0-test3/crypto/tcrypt.h
linux/crypto/tcrypt.h
--- linux-2.6.0-test3/crypto/tcrypt.h 2003-07-14 09:08:01.000000000 +0530
+++ linux/crypto/tcrypt.h 2003-08-15 02:31:54.000000000 +0530
@@ -1589,6 +1589,93 @@
}
};
+/* Cast6 test vectors from RFC 2144 */
+#define CAST6_ENC_TEST_VECTORS 3
+#define CAST6_DEC_TEST_VECTORS 3
+
+struct cast6_tv {
+ unsigned keylen;
+ unsigned fail;
+ u8 key[32];
+ u8 plaintext[16];
+ u8 result[16];
+};
+
+struct cast6_tv cast6_enc_tv_template[] =
+{
+ {
+ 16,
+ 0,
+ { 0x23, 0x42, 0xbb, 0x9e, 0xfa, 0x38, 0x54, 0x2c,
+ 0x0a, 0xf7, 0x56, 0x47, 0xf2, 0x9f, 0x61, 0x5d },
+ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },
+ { 0xc8, 0x42, 0xa0, 0x89, 0x72, 0xb4, 0x3d, 0x20,
+ 0x83, 0x6c, 0x91, 0xd1, 0xb7, 0x53, 0x0f, 0x6b },
+ },
+ {
+ 24,
+ 0,
+ { 0x23, 0x42, 0xbb, 0x9e, 0xfa, 0x38, 0x54, 0x2c,
+ 0xbe, 0xd0, 0xac, 0x83, 0x94, 0x0a, 0xc2, 0x98,
+ 0xba, 0xc7, 0x7a, 0x77, 0x17, 0x94, 0x28, 0x63 },
+ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },
+ { 0x1b, 0x38, 0x6c, 0x02, 0x10, 0xdc, 0xad, 0xcb,
+ 0xdd, 0x0e, 0x41, 0xaa, 0x08, 0xa7, 0xa7, 0xe8 },
+ },
+ {
+ 32,
+ 0,
+ { 0x23, 0x42, 0xbb, 0x9e, 0xfa, 0x38, 0x54, 0x2c,
+ 0xbe, 0xd0, 0xac, 0x83, 0x94, 0x0a, 0xc2, 0x98,
+ 0x8d, 0x7c, 0x47, 0xce, 0x26, 0x49, 0x08, 0x46,
+ 0x1c, 0xc1, 0xb5, 0x13, 0x7a, 0xe6, 0xb6, 0x04 },
+ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },
+ { 0x4f, 0x6a, 0x20, 0x38, 0x28, 0x68, 0x97, 0xb9,
+ 0xc9, 0x87, 0x01, 0x36, 0x55, 0x33, 0x17, 0xfa },
+ }
+};
+
+struct cast6_tv cast6_dec_tv_template[] =
+{
+ {
+ 16,
+ 0,
+ { 0x23, 0x42, 0xbb, 0x9e, 0xfa, 0x38, 0x54, 0x2c,
+ 0x0a, 0xf7, 0x56, 0x47, 0xf2, 0x9f, 0x61, 0x5d },
+ { 0xc8, 0x42, 0xa0, 0x89, 0x72, 0xb4, 0x3d, 0x20,
+ 0x83, 0x6c, 0x91, 0xd1, 0xb7, 0x53, 0x0f, 0x6b },
+ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },
+ },
+ {
+ 24,
+ 0,
+ { 0x23, 0x42, 0xbb, 0x9e, 0xfa, 0x38, 0x54, 0x2c,
+ 0xbe, 0xd0, 0xac, 0x83, 0x94, 0x0a, 0xc2, 0x98,
+ 0xba, 0xc7, 0x7a, 0x77, 0x17, 0x94, 0x28, 0x63 },
+ { 0x1b, 0x38, 0x6c, 0x02, 0x10, 0xdc, 0xad, 0xcb,
+ 0xdd, 0x0e, 0x41, 0xaa, 0x08, 0xa7, 0xa7, 0xe8 },
+ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },
+ },
+ {
+ 32,
+ 0,
+ { 0x23, 0x42, 0xbb, 0x9e, 0xfa, 0x38, 0x54, 0x2c,
+ 0xbe, 0xd0, 0xac, 0x83, 0x94, 0x0a, 0xc2, 0x98,
+ 0x8d, 0x7c, 0x47, 0xce, 0x26, 0x49, 0x08, 0x46,
+ 0x1c, 0xc1, 0xb5, 0x13, 0x7a, 0xe6, 0xb6, 0x04 },
+ { 0x4f, 0x6a, 0x20, 0x38, 0x28, 0x68, 0x97, 0xb9,
+ 0xc9, 0x87, 0x01, 0x36, 0x55, 0x33, 0x17, 0xfa },
+ { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 },
+ }
+};
+
+
/*
* AES test vectors.
*/
/*-------------------------------End
Patch-----------------------------------*/
_________________________________________________________________
Race along with NK. The fastest Indian.
http://server1.msn.co.in/sp03/tataracing/index.asp Feel the thrill!
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-08-14 21:57 kartikey bhatt
@ 2003-08-15 3:31 ` James Morris
0 siblings, 0 replies; 669+ messages in thread
From: James Morris @ 2003-08-15 3:31 UTC (permalink / raw)
To: kartikey bhatt; +Cc: davem, linux-kernel, alan
On Fri, 15 Aug 2003, kartikey bhatt wrote:
> Hi James.
> A little bit work for you.
> Somebody on mailing list commented that you should *really* go for better
> algorithm like CAST6 (rfc2612) to be included in kernel.
> This time I'm sending you cast6.c (cast6 cipher algorithm) implementation.
> But this time it's a patch.
Cool. Unfortunately the patch is corrupted, please try sending as an
attachment or via a different mail system.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <200308031136.17768.lx@lxhp.in-berlin.de>]
* Re: your mail
[not found] <200308031136.17768.lx@lxhp.in-berlin.de>
@ 2003-08-03 18:30 ` Linus Torvalds
0 siblings, 0 replies; 669+ messages in thread
From: Linus Torvalds @ 2003-08-03 18:30 UTC (permalink / raw)
To: hp; +Cc: linux-assembly, Kernel Mailing List, David S. Miller
On Sun, 3 Aug 2003, hp wrote:
>
> so He/You did lock me out, too?
> whithout any notice. by what reason?
Maybe because this has nothing to do with the kernel?
It's ok to discuss kernel issues on the kernel mailing list, but we've had
tons of totally off-topic flames, rants and general noise.
To the point that a lot of people don't even have time to follow
linux-kernel any more, since a lot of the discussion has nothing to do
with the technical kernel work.
Since some of these rants are started (and kept going) by people who don't
ever seem to actually get involved in _real_ kernel-related technical
discussions, David felt that one way to curb it was to just blacklist
people who repeatedly post things that aren't related to the kernel.
It's ok to be off-topic every once in a while, but it's not ok to
consistently be so.
That said, David is also not the most politic person I know, and I suspect
this could have been handled slightly more gracefully. One potential less
annoying approach is to not block posting from people, but rewrite the
subject line for such posters with a prepended "[OFF-TOPIC]", and just let
people filter those out on the receiving end. Or just automatically shunt
them off to another list.
I dunno. I don't personally much care - but I've never been the maintainer
of the mailing list, and I sure as hell don't ever want to be. Whoever is
the maintainer gets to set the rules.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2003-07-04 18:10 Darryl Perry
2003-07-04 18:21 ` your mail Ged Haywood
0 siblings, 1 reply; 669+ messages in thread
From: Darryl Perry @ 2003-07-04 18:10 UTC (permalink / raw)
To: linux-msdos
Does anybody have an hdimage file with MSDOS6.x
installed that I can use? It dosen't matter what size
it is.
I'd make it myself, but I don't have a floppy drive on
my linux box.
-Regards,
Darryl
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-07-04 18:10 (unknown) Darryl Perry
@ 2003-07-04 18:21 ` Ged Haywood
2003-07-05 14:48 ` Jim Hartley
0 siblings, 1 reply; 669+ messages in thread
From: Ged Haywood @ 2003-07-04 18:21 UTC (permalink / raw)
To: Darryl Perry; +Cc: linux-msdos
Hi there,
On Fri, 4 Jul 2003, Darryl Perry wrote:
> Does anybody have an hdimage file with MSDOS6.x
> installed that I can use?
Do be careful. That sounds like abuse of copyright to me.
> I'd make it myself, but I don't have a floppy drive on my linux box.
Installing a floppy drive is a lot cheaper than defending a lawsuit...
73,
Ged.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-07-04 18:21 ` your mail Ged Haywood
@ 2003-07-05 14:48 ` Jim Hartley
2003-07-05 14:53 ` Ged Haywood
0 siblings, 1 reply; 669+ messages in thread
From: Jim Hartley @ 2003-07-05 14:48 UTC (permalink / raw)
To: linux-msdos
If he owns a legal copy of the product (he says he'd do it himself if he
had a floppy drive on the machine), one would have to be nitpicking in
the extreme to call this a violation. He COULD send his copy to someone
who would build the hdimage and send it back to him, that would be
legal, wouldn't it? (IANAL) Getting someone who owns an identical copy
of the DOS to send him the image without all the bother really doesn't
sound any worse.
In any case, who is going to bother about suing one individual over a
copy of **DOS** in this day and age? Most people have forgotten what DOS
is by now! If he was doing a few thousand copies it might be a problem,
but I think this one is WAY, WAY under the radar.
Jim Hartley
Ged Haywood wrote:
>Hi there,
>
>On Fri, 4 Jul 2003, Darryl Perry wrote:
>
>
>
>>Does anybody have an hdimage file with MSDOS6.x
>>installed that I can use?
>>
>>
>
>Do be careful. That sounds like abuse of copyright to me.
>
>
>
>>I'd make it myself, but I don't have a floppy drive on my linux box.
>>
>>
>
>Installing a floppy drive is a lot cheaper than defending a lawsuit...
>
>73,
>Ged.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-05-14 18:41 dirf
2003-05-16 10:00 ` your mail Maciej Soltysiak
0 siblings, 1 reply; 669+ messages in thread
From: dirf @ 2003-05-14 18:41 UTC (permalink / raw)
To: linux-kernel
Hi,
My questions, for a moment, are very simple. I hope that you can help me.
- Where I can find a list of RFCs?
- Where I can find a cdfs format ( cd file system format)?
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <053C05D4.4D025D2E.0005F166@netscape.net>]
* Re: your mail
[not found] <053C05D4.4D025D2E.0005F166@netscape.net>
@ 2003-05-08 9:06 ` Gerd Knorr
0 siblings, 0 replies; 669+ messages in thread
From: Gerd Knorr @ 2003-05-08 9:06 UTC (permalink / raw)
To: ark925; +Cc: Kernel List
> Actually it does in some cases. I know of two devices that have analog
> tuners on an smbus-like interface (OV511 USB TV and W9967CF USB TV). The
> tuner can be controlled using a pair of i2c_smbus_write_byte_data()
> calls.
Hmm, maybe we should rename the SMBUS class to SENSORS or MAINBOARD or
something like that? I assumed you smbus interfaces are used for
mainboard sensors only ...
> Would a patch that adds smbus algorithm support to tuner.c be
> acceptable?
Yes. Certainly makes more sense than duplicating the whole rest of
tuner.c just for a smbus-aware tuner driver ;)
Gerd
--
sigfault
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-04-30 21:39 Mauricio Oliveira Carneiro
2003-05-01 0:05 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: Mauricio Oliveira Carneiro @ 2003-04-30 21:39 UTC (permalink / raw)
To: linux-kernel
Hi everyone,
I'm almost hanging myself.. it's been a week trying without success :-(
Maybe someone here could help me out. Sorry for the disturbance !
I have bought a USB FLASH MEMORY device from Kmit Co. The model is : "Unity
ITS". I bought it from FRY's Electronics in Palo Alto, CA (USA)
It works perfectly with windows, but i'm having problems with linux 2.4.20-
9 kernel.
It detects the existance of the USB FLASH MEMORY device, as of my
/proc/bus/usb/device file says :
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 98mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=hid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=hid
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=16 #Cfgs= 1
P: Vendor=09a6 ProdID=8001 Rev= 1.00
S: Manufacturer=KMIT CO.,LTD
S: Product=KM USB Removable Disk
S: SerialNumber=20021226113657-00
At the /proc/scsi/usb-storage-0/0 file I get :
Host scsi0: usb-storage
Vendor: KMIT CO.,LTD
Product: KM USB Removable Disk
Serial Number: 20021226113657-00
Protocol: 8070i
Transport: Bulk
GUID: 09a68001002122fffffff600
Attached: Yes
In /etc/mtab :
usbdevfs on /proc/bus/usb type usbdevfs (rw)
But I can't see it mounted anywhere in my system, nor can I mount it by
hand since I don't know the device filename (/dev/?) .
I believe it works the same way for every flash memory drive.
if someone have already suffered of the same cause, I thank for the help :)
Mauricio Oliveira Carneiro
^ permalink raw reply [flat|nested] 669+ messages in thread* (no subject)
@ 2003-04-25 17:35 Bloch, Jack
2003-04-25 19:43 ` your mail Francois Romieu
0 siblings, 1 reply; 669+ messages in thread
From: Bloch, Jack @ 2003-04-25 17:35 UTC (permalink / raw)
To: linux-kernel
Is there example driver source code available for a MUSYCC CN8478 device?
Please CC me directly on any answers.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2003-04-18 0:08 Dennis Castleman
0 siblings, 0 replies; 669+ messages in thread
From: Dennis Castleman @ 2003-04-18 0:08 UTC (permalink / raw)
To: 'Ralf Baechle', Dennis Castleman; +Cc: linux-mips
[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]
Thanks Ralf
Looks like I made the correct call when I picked MIPS32 Kernel.
Look like some of my preformance issues are in Montavistas 2.95.3 toolchain,
it's generating code that looks like this
0000000000000000 <bitBufferCreate>:
0: 27bdffe0 addiu $sp,$sp,-32
4: afbf001c sw $ra,28($sp)
8: afb20018 sw $s2,24($sp)
c: afb10014 sw $s1,20($sp)
10: afb00010 sw $s0,16($sp)
14: 00809021 move $s2,$a0
18: 00a08021 move $s0,$a1
1c: 00c08821 move $s1,$a2
20: 24040001 li $a0,1
24: 24050010 li $a1,16
28: 3c020000 lui $v0,0x0
2c: 24420000 addiu $v0,$v0,0
but if I use the 2.95.3 toolchain I build myself it's
generating code that looks like this.
0000000000000000 <bitBufferCreate>:
0: 27bdffe0 addiu $sp,$sp,-32
4: afb20018 sw $s2,24($sp)
8: 00809021 move $s2,$a0
c: afb00010 sw $s0,16($sp)
10: 00a08021 move $s0,$a1
14: afb10014 sw $s1,20($sp)
18: 00c08821 move $s1,$a2
1c: 24040001 li $a0,1
20: 24050010 li $a1,16
24: 3c020000 lui $v0,0x0
28: 24420000 addiu $v0,$v0,0
Any idea whats up MV tool-chain.
Dennis
-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, April 17, 2003 5:04 PM
To: Dennis Castleman
Cc: linux-mips@linux-mips.org
Subject: Re: your mail
On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:
> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?
As a rule of thumb - less performance. 64-bit code is typically larger
resulting in lower cache hit rate. And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.
On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.
The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace. There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem. That's
fairly inefficient and requires alot of special care when writing new
kernel software. For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either. So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software. That in particular applies
to very I/O intensive stuff.
In short - the right choice is a tradeoff between the hardware platform
and the application's requirements. Choose wrong and you'll curse
loudly :-)
Ralf
[-- Attachment #2: Type: text/html, Size: 5525 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-04-17 17:53 Dennis Castleman
2003-04-17 18:17 ` your mail Jun Sun
2003-04-18 0:03 ` Ralf Baechle
0 siblings, 2 replies; 669+ messages in thread
From: Dennis Castleman @ 2003-04-17 17:53 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 132 bytes --]
ALL
Anybody know the performance differences I can expect using a MIPS 5K core
@250 Mhz in 64bit mode versus 32bit mode?
Dennis
[-- Attachment #2: Type: text/html, Size: 539 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-17 17:53 Dennis Castleman
@ 2003-04-17 18:17 ` Jun Sun
2003-04-17 20:15 ` Greg Lindahl
2003-04-18 0:03 ` Ralf Baechle
1 sibling, 1 reply; 669+ messages in thread
From: Jun Sun @ 2003-04-17 18:17 UTC (permalink / raw)
To: Dennis Castleman; +Cc: linux-mips, jsun
On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:
> ALL
>
> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?
>
It really depends on the applications. The biggest gain from 64bit,
other than the obviously bigger address space, is 64bit data
manipulation. A single 64bit instruction (add/sub/...) is carried
out by several instructions in 32bit.
If your apps are heavy on 64bit operations, then you gain.
Otherwise I suspect no performance gain or even possibly a little
worse performance due more stress on cache/memory subsystems.
I am sure others with more 64bit experience probably have more
to say. :)
Jun
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-17 18:17 ` your mail Jun Sun
@ 2003-04-17 20:15 ` Greg Lindahl
0 siblings, 0 replies; 669+ messages in thread
From: Greg Lindahl @ 2003-04-17 20:15 UTC (permalink / raw)
To: linux-mips
On Thu, Apr 17, 2003 at 11:17:10AM -0700, Jun Sun wrote:
> It really depends on the applications. The biggest gain from 64bit,
> other than the obviously bigger address space, is 64bit data
> manipulation. A single 64bit instruction (add/sub/...) is carried
> out by several instructions in 32bit.
A big gain is the increased # of registers and better calling
sequence. Everyone sees that, not just people who want to use 64-bit
integers. At the moment you need to run the 64-bit kernel -- and the
new binutils & glibc -- in order to get n32 programs to work.
-- greg
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-17 17:53 Dennis Castleman
2003-04-17 18:17 ` your mail Jun Sun
@ 2003-04-18 0:03 ` Ralf Baechle
1 sibling, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 2003-04-18 0:03 UTC (permalink / raw)
To: Dennis Castleman; +Cc: linux-mips
On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:
> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?
As a rule of thumb - less performance. 64-bit code is typically larger
resulting in lower cache hit rate. And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.
On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.
The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace. There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem. That's
fairly inefficient and requires alot of special care when writing new
kernel software. For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either. So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software. That in particular applies
to very I/O intensive stuff.
In short - the right choice is a tradeoff between the hardware platform
and the application's requirements. Choose wrong and you'll curse
loudly :-)
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2003-04-05 0:38 Ed Vance
2003-04-05 4:51 ` Keith Owens
0 siblings, 1 reply; 669+ messages in thread
From: Ed Vance @ 2003-04-05 0:38 UTC (permalink / raw)
To: 'Keith Owens', 'Matti Aarnio'; +Cc: linux-kernel
On Fri, Apr 04, 2003 at 3:21 PM, Keith Owens wrote:
>
> On Fri, 4 Apr 2003 14:10:16 -0800 ,
> Ed Vance <EdV@macrolink.com> wrote:
> >Perhaps there is a middle ground. Leave the list open, but require a
> >confirmation reply prior to passing along posts from addresses that:
> >
> >1. are not members of the list, AND
> >2. have not previously done a proper confirmation reply.
>
> 30 seconds after doing that, the spammers will forge email that claims
> to be from LT, AC, DM, MT etc. Not to mention all the viruses that
> forge the headers. Verification by 'From:' line on an open list is
> pointless.
>
Keith,
No single method is perfect. Your point is well taken.
The goal was to greatly reduce, in one swell foop, the volume of spam that
the filters (and postmaster) must interactively deal with. I thought that
perhaps this method could replace one of more of the troublesome filtering
techniques to achieve the same net spam reduction without evoking as much
whining.
imperfect != pointless
Matti,
Roughly what percentage of the spam actually hitting vger today (and
bouncing off) is based on Keith's flavor of spoofing? Is it even 1 percent?
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-05 0:38 Ed Vance
@ 2003-04-05 4:51 ` Keith Owens
0 siblings, 0 replies; 669+ messages in thread
From: Keith Owens @ 2003-04-05 4:51 UTC (permalink / raw)
To: Ed Vance; +Cc: linux-kernel
On Fri, 4 Apr 2003 16:38:50 -0800 ,
Ed Vance <EdV@macrolink.com> wrote:
>On Fri, Apr 04, 2003 at 3:21 PM, Keith Owens wrote:
>>
>> On Fri, 4 Apr 2003 14:10:16 -0800 ,
>> Ed Vance <EdV@macrolink.com> wrote:
>> >Perhaps there is a middle ground. Leave the list open, but require a
>> >confirmation reply prior to passing along posts from addresses that:
>> >
>> >1. are not members of the list, AND
>> >2. have not previously done a proper confirmation reply.
>>
>> 30 seconds after doing that, the spammers will forge email that claims
>> to be from LT, AC, DM, MT etc. Not to mention all the viruses that
>> forge the headers. Verification by 'From:' line on an open list is
>> pointless.
>>
>The goal was to greatly reduce, in one swell foop, the volume of spam that
>the filters (and postmaster) must interactively deal with. I thought that
>perhaps this method could replace one of more of the troublesome filtering
>techniques to achieve the same net spam reduction without evoking as much
>whining.
Paraphrase: Replace filtering code that catches spam with filtering
code based on checking header content that can be trivially forged by
spammers.
>Matti,
>Roughly what percentage of the spam actually hitting vger today (and
>bouncing off) is based on Keith's flavor of spoofing? Is it even 1 percent?
Current figures are irrelevant, spammers react to spam filters and they
react very quickly[*]. If you replace "reject HTML bodies" with "allow
HTML based on known From: lines" then the spammers will send HTML
bodies with forged headers, because they know it will get through.
That will require the original HTML filters to be reintroduced, the end
result is you added an extra step for new posters without reducing the
spam or users whining "my mail does not get through".
[*] About 24 hours after slashdot carried a story on Baysian spam
filters, I started receiving HTML spam that contained comments that
were designed to fool the Baysian filters, like this.
FREE 1 MONTH SUPP<!--kernel-->Y WITH THIS
The comment has no effect on the spam display but the use of
non-spam words skews the Baysian rules on whether the content is
spam or not.
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2003-04-04 22:10 Ed Vance
2003-04-04 23:19 ` William Scott Lockwood III
2003-04-04 23:21 ` Keith Owens
0 siblings, 2 replies; 669+ messages in thread
From: Ed Vance @ 2003-04-04 22:10 UTC (permalink / raw)
To: 'Matti Aarnio'; +Cc: William Scott Lockwood III, linux-kernel
On Fri, Apr 04, 2003 at 12:38 PM, Matti Aarnio wrote:
> [snip]
> A somewhat better anti-spam filter method, than what we use presently
> is to use strictly CLOSED list -- e.g. must be a member to post.
> I have seen what kind of pains closed lists are, I even moderate
> couple small ones.
>
> However we are deliberately running "open for posting, subject to
> filters" policy, which lets questions and reports to come from
> non-subscribers.
>
Perhaps there is a middle ground. Leave the list open, but require a
confirmation reply prior to passing along posts from addresses that:
1. are not members of the list, AND
2. have not previously done a proper confirmation reply.
The unconfirmed posts would time out and disappear after a decent interval,
to prevent constipation.
So, anybody could still post, the members would not be inconvenienced, and
non-members would be inconvenienced only on their first post from each
address they post from. This would preserve the "real time" nature of the
list, while gaining the assurance that all who post are life-forms, even if
they live in front of a keyboard and have no real life. ;-)
Of course, this would require storage for the list of confirmed addresses
and pending unconfirmed posts, and the bandwidth and other overhead of the
infrequent confirmation messages.
Just a thought.
Cheers,
Ed
----------------------------------------------------------------
Ed Vance edv (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
2003-04-04 22:10 Ed Vance
@ 2003-04-04 23:19 ` William Scott Lockwood III
2003-04-04 23:21 ` Keith Owens
1 sibling, 0 replies; 669+ messages in thread
From: William Scott Lockwood III @ 2003-04-04 23:19 UTC (permalink / raw)
To: Ed Vance; +Cc: 'Matti Aarnio', linux-kernel
That is the best suggestion I've yet seen. It's an excellent idea!
On Fri, 4 Apr 2003, Ed Vance wrote:
> On Fri, Apr 04, 2003 at 12:38 PM, Matti Aarnio wrote:
> > [snip]
> > A somewhat better anti-spam filter method, than what we use presently
> > is to use strictly CLOSED list -- e.g. must be a member to post.
> > I have seen what kind of pains closed lists are, I even moderate
> > couple small ones.
> >
> > However we are deliberately running "open for posting, subject to
> > filters" policy, which lets questions and reports to come from
> > non-subscribers.
> >
>
> Perhaps there is a middle ground. Leave the list open, but require a
> confirmation reply prior to passing along posts from addresses that:
>
> 1. are not members of the list, AND
> 2. have not previously done a proper confirmation reply.
>
> The unconfirmed posts would time out and disappear after a decent interval,
> to prevent constipation.
>
> So, anybody could still post, the members would not be inconvenienced, and
> non-members would be inconvenienced only on their first post from each
> address they post from. This would preserve the "real time" nature of the
> list, while gaining the assurance that all who post are life-forms, even if
> they live in front of a keyboard and have no real life. ;-)
>
> Of course, this would require storage for the list of confirmed addresses
> and pending unconfirmed posts, and the bandwidth and other overhead of the
> infrequent confirmation messages.
>
> Just a thought.
>
> Cheers,
> Ed
>
> ----------------------------------------------------------------
> Ed Vance edv (at) macrolink (dot) com
> Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
> ----------------------------------------------------------------
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 22:10 Ed Vance
2003-04-04 23:19 ` William Scott Lockwood III
@ 2003-04-04 23:21 ` Keith Owens
1 sibling, 0 replies; 669+ messages in thread
From: Keith Owens @ 2003-04-04 23:21 UTC (permalink / raw)
To: Ed Vance; +Cc: linux-kernel
On Fri, 4 Apr 2003 14:10:16 -0800 ,
Ed Vance <EdV@macrolink.com> wrote:
>Perhaps there is a middle ground. Leave the list open, but require a
>confirmation reply prior to passing along posts from addresses that:
>
>1. are not members of the list, AND
>2. have not previously done a proper confirmation reply.
30 seconds after doing that, the spammers will forge email that claims
to be from LT, AC, DM, MT etc. Not to mention all the viruses that
forge the headers. Verification by 'From:' line on an open list is
pointless.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-04-03 16:22 Richard B. Johnson
2003-04-03 19:22 ` David S. Miller
0 siblings, 1 reply; 669+ messages in thread
From: Richard B. Johnson @ 2003-04-03 16:22 UTC (permalink / raw)
To: Linux kernel
FYI vger rejects mail sent from yahoo.com, claims that it
has a HTML subpart and considers it spam or Outlook Virus.
FYI any mail sent from yahoo will end up using the yahoo tools
(qmail). This will put an empty HTML section in all mail. It
is not a good thing to reject this because that means you reject
all mail from yahoo.
I have gotten several messages of this kind by persons who are
not bold enough to report problems on their own. The last rejection
of which I speak was rejected from N26835@yahoo.com on april 2
at 19:38:00
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
2003-04-03 16:22 Richard B. Johnson
@ 2003-04-03 19:22 ` David S. Miller
2003-04-03 20:02 ` your mail Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: David S. Miller @ 2003-04-03 19:22 UTC (permalink / raw)
To: root; +Cc: Linux kernel
On Thu, 2003-04-03 at 08:22, Richard B. Johnson wrote:
> FYI vger rejects mail sent from yahoo.com, claims that it
> has a HTML subpart and considers it spam or Outlook Virus.
>
> FYI any mail sent from yahoo will end up using the yahoo tools
> (qmail). This will put an empty HTML section in all mail. It
> is not a good thing to reject this because that means you reject
> all mail from yahoo.
That's yahoo users problem not ours. If you can't be bothered
to get a plain text email out, you shouldn't be using these
lists.
VGER isn't the only place outright blocking HTML attached emails.
--
David S. Miller <davem@redhat.com>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-03 19:22 ` David S. Miller
@ 2003-04-03 20:02 ` Richard B. Johnson
2003-04-03 19:24 ` Alan Cox
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Richard B. Johnson @ 2003-04-03 20:02 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux kernel
On Thu, 3 Apr 2003, David S. Miller wrote:
> On Thu, 2003-04-03 at 08:22, Richard B. Johnson wrote:
> > FYI vger rejects mail sent from yahoo.com, claims that it
> > has a HTML subpart and considers it spam or Outlook Virus.
> >
> > FYI any mail sent from yahoo will end up using the yahoo tools
> > (qmail). This will put an empty HTML section in all mail. It
> > is not a good thing to reject this because that means you reject
> > all mail from yahoo.
>
> That's yahoo users problem not ours. If you can't be bothered
> to get a plain text email out, you shouldn't be using these
> lists.
>
Well it's not a yahoo users problem because yahoo users can't fix
it. Some yahoo users have yahoo "free" mail as their only connection
to the internet because of facist network administrators. It gets
worse how that you can't tell a company to go screw themselves and
get another job. The three engineers that I know who use yahoo do
so because they don't have any choice and there is no way that they
can configure the mailer to get rid of the empty HTML section.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-04-03 20:02 ` your mail Richard B. Johnson
@ 2003-04-03 19:24 ` Alan Cox
2003-04-03 20:00 ` David S. Miller
2003-04-03 20:40 ` Trever L. Adams
2 siblings, 0 replies; 669+ messages in thread
From: Alan Cox @ 2003-04-03 19:24 UTC (permalink / raw)
To: root; +Cc: David S. Miller, Linux Kernel Mailing List
On Iau, 2003-04-03 at 21:02, Richard B. Johnson wrote:
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators. It gets
> worse how that you can't tell a company to go screw themselves and
> get another job. The three engineers that I know who use yahoo do
> so because they don't have any choice and there is no way that they
> can configure the mailer to get rid of the empty HTML section.
There are lots of other free email providers.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-03 20:02 ` your mail Richard B. Johnson
2003-04-03 19:24 ` Alan Cox
@ 2003-04-03 20:00 ` David S. Miller
2003-04-03 20:21 ` Richard B. Johnson
2003-04-04 0:31 ` William Scott Lockwood III
2003-04-03 20:40 ` Trever L. Adams
2 siblings, 2 replies; 669+ messages in thread
From: David S. Miller @ 2003-04-03 20:00 UTC (permalink / raw)
To: root; +Cc: linux-kernel
From: "Richard B. Johnson" <root@chaos.analogic.com>
Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
Well it's not a yahoo users problem because yahoo users can't fix
it. Some yahoo users have yahoo "free" mail as their only connection
to the internet because of facist network administrators.
If you want all the SPAM that will result on Linux-kernel, we
can disable the filter if you want.
I refuse to sit here and listen to all the "this is the only
connection person FOO has to the internet" stories, quite frankly I'm
absolutely sick of hearing them.
If you don't have properly functioning mail, you can't use these
lists.
Period.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-03 20:00 ` David S. Miller
@ 2003-04-03 20:21 ` Richard B. Johnson
2003-04-03 20:15 ` David S. Miller
2003-04-04 0:31 ` William Scott Lockwood III
1 sibling, 1 reply; 669+ messages in thread
From: Richard B. Johnson @ 2003-04-03 20:21 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
On Thu, 3 Apr 2003, David S. Miller wrote:
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
>
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators.
>
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.
No. I think you can let empty HTML sections go through.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-03 20:21 ` Richard B. Johnson
@ 2003-04-03 20:15 ` David S. Miller
0 siblings, 0 replies; 669+ messages in thread
From: David S. Miller @ 2003-04-03 20:15 UTC (permalink / raw)
To: root; +Cc: linux-kernel
From: "Richard B. Johnson" <root@chaos.analogic.com>
Date: Thu, 3 Apr 2003 15:21:25 -0500 (EST)
On Thu, 3 Apr 2003, David S. Miller wrote:
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.
No. I think you can let empty HTML sections go through.
I think these people who it matters to can petition yahoo.com to drop
this dumb empty HTML section.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-03 20:00 ` David S. Miller
2003-04-03 20:21 ` Richard B. Johnson
@ 2003-04-04 0:31 ` William Scott Lockwood III
2003-04-04 0:40 ` David S. Miller
2003-04-04 12:57 ` Richard B. Johnson
1 sibling, 2 replies; 669+ messages in thread
From: William Scott Lockwood III @ 2003-04-04 0:31 UTC (permalink / raw)
To: David S. Miller; +Cc: root, linux-kernel
On Thu, 3 Apr 2003, David S. Miller wrote:
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators.
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.
> I refuse to sit here and listen to all the "this is the only
> connection person FOO has to the internet" stories, quite frankly I'm
> absolutely sick of hearing them.
> If you don't have properly functioning mail, you can't use these
> lists.
> Period.
When did that become your call? I didn't realize you owned LKML.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 0:31 ` William Scott Lockwood III
@ 2003-04-04 0:40 ` David S. Miller
2003-04-04 0:47 ` William Scott Lockwood III
2003-04-04 12:57 ` Richard B. Johnson
1 sibling, 1 reply; 669+ messages in thread
From: David S. Miller @ 2003-04-04 0:40 UTC (permalink / raw)
To: vlad; +Cc: root, linux-kernel
From: William Scott Lockwood III <vlad@geekizoid.com>
Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)
When did that become your call? I didn't realize you owned LKML.
Maybe this is news to you, but I've been running LKML for
6 or so years now.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 0:40 ` David S. Miller
@ 2003-04-04 0:47 ` William Scott Lockwood III
0 siblings, 0 replies; 669+ messages in thread
From: William Scott Lockwood III @ 2003-04-04 0:47 UTC (permalink / raw)
To: David S. Miller; +Cc: root, linux-kernel
Yeah, sorry - I thought HPA was running it for some reason. I still don't
think you should make that kind of a call unilaterally, but hey - after
all the incessant whining I put up with about using OE, I finally caved
and moved to a real email address myself. I guess it just goes to show
that if you while and act petulant long enough...
On Thu, 3 Apr 2003, David S. Miller wrote:
> From: William Scott Lockwood III <vlad@geekizoid.com>
> Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)
>
> When did that become your call? I didn't realize you owned LKML.
>
> Maybe this is news to you, but I've been running LKML for
> 6 or so years now.
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 0:31 ` William Scott Lockwood III
2003-04-04 0:40 ` David S. Miller
@ 2003-04-04 12:57 ` Richard B. Johnson
2003-04-04 15:28 ` William Scott Lockwood III
1 sibling, 1 reply; 669+ messages in thread
From: Richard B. Johnson @ 2003-04-04 12:57 UTC (permalink / raw)
To: William Scott Lockwood III; +Cc: David S. Miller, linux-kernel
On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> On Thu, 3 Apr 2003, David S. Miller wrote:
> > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > Well it's not a yahoo users problem because yahoo users can't fix
> > it. Some yahoo users have yahoo "free" mail as their only connection
> > to the internet because of facist network administrators.
> > If you want all the SPAM that will result on Linux-kernel, we
> > can disable the filter if you want.
> > I refuse to sit here and listen to all the "this is the only
> > connection person FOO has to the internet" stories, quite frankly I'm
> > absolutely sick of hearing them.
> > If you don't have properly functioning mail, you can't use these
> > lists.
> > Period.
>
> When did that become your call? I didn't realize you owned LKML.
>
Well it's his "baseball" and; "You'll play by my rules or you won't
play at all..."
FYI, there is no Major Domo. It's Latin, major domus, "master of
the house". He doith whatever he careth...
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 12:57 ` Richard B. Johnson
@ 2003-04-04 15:28 ` William Scott Lockwood III
2003-04-04 16:04 ` Richard B. Johnson
` (3 more replies)
0 siblings, 4 replies; 669+ messages in thread
From: William Scott Lockwood III @ 2003-04-04 15:28 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: David S. Miller, linux-kernel
On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > Well it's not a yahoo users problem because yahoo users can't fix
> > > it. Some yahoo users have yahoo "free" mail as their only connection
> > > to the internet because of facist network administrators.
> > > If you want all the SPAM that will result on Linux-kernel, we
> > > can disable the filter if you want.
> > > I refuse to sit here and listen to all the "this is the only
> > > connection person FOO has to the internet" stories, quite frankly I'm
> > > absolutely sick of hearing them.
> > > If you don't have properly functioning mail, you can't use these
> > > lists.
> > > Period.
> > When did that become your call? I didn't realize you owned LKML.
> Well it's his "baseball" and; "You'll play by my rules or you won't
> play at all..."
> FYI, there is no Major Domo. It's Latin, major domus, "master of
> the house". He doith whatever he careth...
Yes, I can see that. No matter who it alienates. Weither or not he's
checked with anyone else either. How about leting those of us who (like
Linus) choose to use a commercial email product do so? Garbage about
headers, etc. is just that - garbage. The best list is one that is
inclusive. One that tollerates other opinions and choices. LKML has
turned into the largest, nastiest click I've ever seen, and that's really
sad, as I'm sure it scares some good people away. Look at all the crap I
and others got for using hotmail - I finally got sick and tired of the
whining and now have to take 3x as long to read my mail - but it's not a
hotmail address anymore, so the whining stoped. Why not spend less timing
restricting what people can read and post from, and just let people
participate?
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-04-04 15:28 ` William Scott Lockwood III
@ 2003-04-04 16:04 ` Richard B. Johnson
2003-04-04 16:04 ` Christoph Hellwig
` (2 subsequent siblings)
3 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2003-04-04 16:04 UTC (permalink / raw)
To: William Scott Lockwood III; +Cc: David S. Miller, Linux kernel
On Fri, 4 Apr 2003, William Scott Lockwood III wrote:
> On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> > On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > > Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > > Well it's not a yahoo users problem because yahoo users can't fix
> > > > it. Some yahoo users have yahoo "free" mail as their only connection
> > > > to the internet because of facist network administrators.
> > > > If you want all the SPAM that will result on Linux-kernel, we
> > > > can disable the filter if you want.
> > > > I refuse to sit here and listen to all the "this is the only
> > > > connection person FOO has to the internet" stories, quite frankly I'm
> > > > absolutely sick of hearing them.
> > > > If you don't have properly functioning mail, you can't use these
> > > > lists.
> > > > Period.
> > > When did that become your call? I didn't realize you owned LKML.
> > Well it's his "baseball" and; "You'll play by my rules or you won't
> > play at all..."
> > FYI, there is no Major Domo. It's Latin, major domus, "master of
> > the house". He doith whatever he careth...
>
> Yes, I can see that. No matter who it alienates. Weither or not he's
> checked with anyone else either. How about leting those of us who (like
> Linus) choose to use a commercial email product do so? Garbage about
> headers, etc. is just that - garbage. The best list is one that is
> inclusive. One that tollerates other opinions and choices. LKML has
> turned into the largest, nastiest click I've ever seen, and that's really
> sad, as I'm sure it scares some good people away. Look at all the crap I
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped. Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?
>
Well SPAM is a very big problem and I can see that David is trying.
Sometimes he has a bad day and pisses a few off with his answers.
However, in every case in which somebody that I know of has complained,
the problems did get "mysteriously" fixed so, like they say; "Don't go
away mad. Just go away!".
Once you get flammed for a few years, you get used to it. That's why
some people send email to me rather than "the list". Sometimes I am
able to help without having to forward their problems to the list.
Sometimes I have to take a work-break and can't help, and other times
I can't help because I don't know what they are talking about. Anyway
if David wants invoke the rage of the Gods, yawn... It doesn't bother
me anymore....
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-04-04 15:28 ` William Scott Lockwood III
2003-04-04 16:04 ` Richard B. Johnson
@ 2003-04-04 16:04 ` Christoph Hellwig
2003-04-04 16:10 ` Jens Axboe
2003-04-04 20:37 ` Matti Aarnio
3 siblings, 0 replies; 669+ messages in thread
From: Christoph Hellwig @ 2003-04-04 16:04 UTC (permalink / raw)
To: William Scott Lockwood III
Cc: Richard B. Johnson, David S. Miller, linux-kernel
On Fri, Apr 04, 2003 at 07:28:12AM -0800, William Scott Lockwood III wrote:
> Yes, I can see that. No matter who it alienates. Weither or not he's
> checked with anyone else either.
LKML is DaveM's list. If the choice he and his co-postmaster make don't
suit yours or others need setup your own linux kernel list.
> How about leting those of us who (like
> Linus) choose to use a commercial email product do so? Garbage about
> headers, etc. is just that - garbage.
Who said anything about commercial products? lkml refuses _broken_
mails, it doesn't check what MUA you used.
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped. Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?
Please red the mail RFC and the nettiquette and come back once you've
done that. Your current whining wastes our time.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 15:28 ` William Scott Lockwood III
2003-04-04 16:04 ` Richard B. Johnson
2003-04-04 16:04 ` Christoph Hellwig
@ 2003-04-04 16:10 ` Jens Axboe
2003-04-04 20:37 ` Matti Aarnio
3 siblings, 0 replies; 669+ messages in thread
From: Jens Axboe @ 2003-04-04 16:10 UTC (permalink / raw)
To: William Scott Lockwood III
Cc: Richard B. Johnson, David S. Miller, linux-kernel
On Fri, Apr 04 2003, William Scott Lockwood III wrote:
> On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> > On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > > Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > > Well it's not a yahoo users problem because yahoo users can't fix
> > > > it. Some yahoo users have yahoo "free" mail as their only connection
> > > > to the internet because of facist network administrators.
> > > > If you want all the SPAM that will result on Linux-kernel, we
> > > > can disable the filter if you want.
> > > > I refuse to sit here and listen to all the "this is the only
> > > > connection person FOO has to the internet" stories, quite frankly I'm
> > > > absolutely sick of hearing them.
> > > > If you don't have properly functioning mail, you can't use these
> > > > lists.
> > > > Period.
> > > When did that become your call? I didn't realize you owned LKML.
> > Well it's his "baseball" and; "You'll play by my rules or you won't
> > play at all..."
> > FYI, there is no Major Domo. It's Latin, major domus, "master of
> > the house". He doith whatever he careth...
>
> Yes, I can see that. No matter who it alienates. Weither or not he's
> checked with anyone else either. How about leting those of us who (like
> Linus) choose to use a commercial email product do so? Garbage about
> headers, etc. is just that - garbage. The best list is one that is
> inclusive. One that tollerates other opinions and choices. LKML has
> turned into the largest, nastiest click I've ever seen, and that's really
> sad, as I'm sure it scares some good people away. Look at all the crap I
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped. Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?
Oh please go away. Would you rather see lkml be as ridden with spam as
other lists? You have the right to use a commercial product, and you may
also exercise your right to choose a _bad_ one.
Besides, crap like the above doesn't carry much weight. Especially not
from someone who rarely contributes anything but noise on the list. No
time for whiners, to the kill file you go.
--
Jens Axboe
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-04 15:28 ` William Scott Lockwood III
` (2 preceding siblings ...)
2003-04-04 16:10 ` Jens Axboe
@ 2003-04-04 20:37 ` Matti Aarnio
3 siblings, 0 replies; 669+ messages in thread
From: Matti Aarnio @ 2003-04-04 20:37 UTC (permalink / raw)
To: William Scott Lockwood III; +Cc: linux-kernel
On Fri, Apr 04, 2003 at 07:28:12AM -0800, William Scott Lockwood III wrote:
...
> The best list is one that is inclusive. One that tollerates other opinions
> and choices. LKML has turned into the largest, nastiest click I've ever
> seen, and that's really sad, as I'm sure it scares some good people away.
Are you speaking about PEOPLE who react on emails by flaming, or
something of list filtering "technology" ?
> Look at all the crap I and others got for using hotmail - I finally
> got sick and tired of the whining and now have to take 3x as long to
> read my mail - but it's not a hotmail address anymore, so the whining
> stoped.
About people, then.. There I can't help, unfortunately.
We have lots of people subscribing on Hotmail addresses, and only
complaint I can voice is that those people will at times let their
mailbox quotas overflow, which leads to bounces, and then subscription
revocation... (Hard controlled quotas are not unique to Hotmail, nor
people who let them overflow...)
> Why not spend less timing restricting what people can read and post
> from, and just let people participate?
There is this small thing called spam...
We have various filters (see my other posting), but obviously they
are not infallible, a few spams do leak thru, and earn new filter
rules (if I can think up something suitably specific, while generic..)
A somewhat better anti-spam filter method, than what we use presently
is to use strictly CLOSED list -- e.g. must be a member to post.
I have seen what kind of pains closed lists are, I even moderate
couple small ones.
However we are deliberately running "open for posting, subject to
filters" policy, which lets questions and reports to come from
non-subscribers.
/Matti Aarnio
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-04-03 20:02 ` your mail Richard B. Johnson
2003-04-03 19:24 ` Alan Cox
2003-04-03 20:00 ` David S. Miller
@ 2003-04-03 20:40 ` Trever L. Adams
2 siblings, 0 replies; 669+ messages in thread
From: Trever L. Adams @ 2003-04-03 20:40 UTC (permalink / raw)
To: root; +Cc: David S. Miller, Linux Kernel Mailing List
On Thu, 2003-04-03 at 15:02, Richard B. Johnson wrote:
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators. It gets
> worse how that you can't tell a company to go screw themselves and
> get another job. The three engineers that I know who use yahoo do
> so because they don't have any choice and there is no way that they
> can configure the mailer to get rid of the empty HTML section.
I would suggest that those who think Yahoo is there only option, check
out digitalme.com or myrealbox.com. Web, pop, imap, etc. All free.
Trever
--
"Never raise your hand to your children - it leaves your midsection
unprotected." -- Matthew Harrell
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-03-29 6:54 Avinash S.
2003-03-29 7:25 ` your mail Thiemo Seufer
0 siblings, 1 reply; 669+ messages in thread
From: Avinash S. @ 2003-03-29 6:54 UTC (permalink / raw)
To: linux
Hello,
Im trying to build a kernel config for a big endian IDT79S334 board. I
have sucessfully mangaged to get a vmlinux image using Embedix tools for
little endian but am having problems with big endian configs. I am using
binutils version 2.8. I get an error when i reaches irq.c saying:
Unknown ISA level
Unknown opcode 'clz'
im using a mips-linux-gcc from egcs pacakge(1.1.2-4). Does anyone know
how to solve this problem or where can i get a mips-linux-gcc that
supports the opcode.
Thanks in advance
Avinash
pS: here is the make dump that shows the error.
--------------------------------------------------------------------------
make[1]: Entering directory
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
make all_targets
make[2]: Entering directory
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
mips-linux-gcc -I /home1/ixe2424/proj/ixe2424/IDT/linux/include/asm/gcc -
D__KERNEL__ -I/home1/ixe2424/proj/ixe2424/IDT/linux/include -Wall -
Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-common -
fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--
trap -pipe -DKBUILD_BASENAME=irq -c -o irq.o irq.c
{standard input}: Assembler messages:
{standard input}:1076: Error: unknown ISA level
{standard input}:1077: Error: unrecognized opcode `clz'
{standard input}:1116: Error: unknown ISA level
{standard input}:1117: Error: unrecognized opcode `clz'
{standard input}:1193: Error: unknown ISA level
{standard input}:1194: Error: unrecognized opcode `clz'
make[2]: *** [irq.o] Error 1
make[2]: Leaving directory
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory
`/home1/ixe2424/proj/ixe2424/IDT/linux/arch/mips/rc32300/79S334'
make: *** [_dir_arch/mips/rc32300/79S334] Error 2
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-03-29 6:54 Avinash S.
@ 2003-03-29 7:25 ` Thiemo Seufer
0 siblings, 0 replies; 669+ messages in thread
From: Thiemo Seufer @ 2003-03-29 7:25 UTC (permalink / raw)
To: Avinash S.; +Cc: linux
Avinash S. wrote:
> Hello,
>
> Im trying to build a kernel config for a big endian IDT79S334 board. I
> have sucessfully mangaged to get a vmlinux image using Embedix tools for
> little endian but am having problems with big endian configs. I am using
> binutils version 2.8. I get an error when i reaches irq.c saying:
^^^
That's _very_ old.
> Unknown ISA level
> Unknown opcode 'clz'
>
> im using a mips-linux-gcc from egcs pacakge(1.1.2-4). Does anyone know
> how to solve this problem or where can i get a mips-linux-gcc that
> supports the opcode.
It's the assembler, not the compiler. Upgrade binutils.
Thiemo
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-01-31 18:46 saurabh khanna
2003-02-03 12:53 ` your mail Alexander Kellett
0 siblings, 1 reply; 669+ messages in thread
From: saurabh khanna @ 2003-01-31 18:46 UTC (permalink / raw)
To: linux-kernel
Problem: My xwindows did not open and my sound card don't work.
Xwindows:
I am a novice. I am using redhat linux 8. It detects my graphics
card
correctly but when i tried to open xwindows, my system hangs.
Sound:
Linux has detected my sound card once but not configured it and
after
that nor it is working nither it is detected by my linux.
GRUB:
Also, i can boot my linux through LILO only. GRUB wont work, it
gives
error "Not enough memory".
I have re-installed linux on my computer but the problem
remains.
All other detailes are follows.
Kernel version:
Linux version 2.4.18-14 (bhcompile@astest.test.redhat.com)
(gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7))
#1 Wed Sep 4 12:13:11 EDT 2002
Commond which triggers the problem:
startx
Processor information:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(TM) XP 1700+
stepping : 2
cpu MHz : 1469.861
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 2920.57
Module information:
nls_iso8859-1 3516 1 (autoclean)
nls_cp437 5116 1 (autoclean)
vfat 13084 1 (autoclean)
fat 38744 0 (autoclean)
[vfat]
autofs 13348 0 (autoclean) (unused)
ipt_REJECT 3736 2 (autoclean)
iptable_filter 2412 1 (autoclean)
ip_tables 14840 2 [ipt_REJECT iptable_filter]
mousedev 5524 0 (unused)
keybdev 2976 0 (unused)
hid 22244 0 (unused)
input 5888 0 [mousedev keybdev hid]
usb-ohci 21288 0 (unused)
usbcore 77056 1 [hid usb-ohci]
ext3 70400 1
jbd 52212 1 [ext3]
Loaded driver and hardware information:
0000-001f : dma
1
0020-003f : pic
1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic
2
00c0-00df : dma
2
00f0-00ff : fpu
01f0-01f7 : ide
0
02f8-02ff : serial(auto)
03c0-03df : vga+
03f6-03f6 : ide
0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf
1
5000-500f : PCI device 10de:01b4 (nVidia Corporation)
5100-511f : PCI device 10de:01b4 (nVidia Corporation)
5500-550f : PCI device 10de:01b4 (nVidia Corporation)
a800-a80f : nVidia Corporation nForce IDE
a800-a807 : ide0
a808-a80f : ide1
b000-bfff : PCI Bus #01
b800-b807 : Rockwell International HCF 56k Data/Fax/Voice/Spkp
(w/Handset) Modem
d800-d807 : PCI device 10de:01c3 (nVidia Corporation)
e000-e07f : PCI device 10de:01b1 (nVidia Corporation)
e100-e1ff : PCI device 10de:01b1 (nVidia Corporation)
00000000-0007ffff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-06febfff : System RAM
00100000-00247f2e : Kernel code
00247f2f-0033ed03 : Kernel data
06fec000-06feefff : ACPI Tables
06fef000-06ffefff : reserved
06fff000-06ffffff : ACPI Non-volatile Storage
eb000000-ec7fffff : PCI Bus #02
eb000000-ebffffff : nVidia Corporation GeForce2 Integrated GPU
ec800000-ecffffff : PCI Bus #01
ec800000-ec80ffff : Rockwell International HCF 56k
Data/Fax/Voice/Spkp (w/Handset) Modem
ed000000-ed000fff : PCI device 10de:01b1 (nVidia Corporation)
ed800000-ed87ffff : PCI device 10de:01b0 (nVidia Corporation)
ee000000-ee0003ff : PCI device 10de:01c3 (nVidia Corporation)
ee800000-ee800fff : PCI device 10de:01c2 (nVidia Corporation)
ee800000-ee800fff : usb-ohci
e
f000000-ef000fff : PCI device
10de:01c2 (nVidia Corporation)
ef000000-ef000fff : usb-ohci
e
ff00000-f7ffffff : PCI Bus #02
f0000000-f7ffffff : nVidia Corporation GeForce2 Integrated GPU
f8000000-fbffffff : PCI device
10de:01a4 (nVidia Corporation)
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved
PCI information:
00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev
b2)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [40] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x1
Capabilities: [60] #08 [2001]
00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory
Controller (rev b2)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory
Controller (rev b2)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:00.3 RAM memory: nVidia Corporation: Unknown device 01aa (rev
b2)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev
c3)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [50] #08 [01e1]
00:01.1 SMBus: nVidia Corporation nForce PCI System Management
(rev c1)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 5000 [size=16]
Region 1: I/O ports at 5500 [size=16]
Region 2: I/O ports at 5100 [size=32]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:02.0 USB Controller: nVidia Corporation: Unknown device 01c2
(rev c3) (prog-if 10 [OHCI])
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at ef000000 (32-bit, non-prefetchable)
[size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:03.0 USB Controller: nVidia Corporation: Unknown device 01c2
(rev c3) (prog-if 10 [OHCI])
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at ee800000 (32-bit, non-prefetchable)
[size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:04.0 Ethernet controller: nVidia Corporation: Unknown device
01c3 (rev c2)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at ee000000 (32-bit, non-prefetchable)
[size=1K]
Region 1: I/O ports at d800 [size=8]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:05.0 Multimedia audio controller: nVidia Corporation: Unknown
device 01b0 (rev c2)
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 3000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at ed800000 (32-bit, non-prefetchable)
[size=512K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:06.0 Multimedia audio controller: nVidia Corporation nForce
Audio (rev c2)
Subsystem: nVidia Corporation: Unknown device 8384
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e100 [size=256]
Region 1: I/O ports at e000 [size=128]
Region 2: Memory at ed000000 (32-bit, non-prefetchable)
[disabled] [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge
(rev c2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: ec800000-ecffffff
Prefetchable memory behind bridge: f8000000-f7ffffff
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3)
(prog-if 8a [Master SecP PriP])
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at a800 [size=16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge
(rev b2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
I/O behind bridge: 0000a000-00009fff
Memory behind bridge: eb000000-ec7fffff
Prefetchable memory behind bridge: eff00000-f7ffffff
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
01:08.0 Communication controller: Rockwell International HCF 56k
Data/Fax/Voice/Spkp (w/Handset) Modem (rev 01)
Subsystem: Rockwell International HCF 56k Data/Fax/Voice/Spkp
(w/Handset) Modem
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin A routed to IRQ 5
Region 0: Memory at ec800000 (32-bit, non-prefetchable)
[size=64K]
Region 1: I/O ports at b800 [size=8]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
02:00.0 VGA compatible controller: nVidia Corporation NV15
[GeForce2 - nForce GPU] (rev b1) (prog-if 00 [VGA])
Subsystem: nVidia Corporation: Unknown device 0c11
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at eb000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at f0000000 (32-bit, prefetchable)
[size=128M]
Expansion ROM at efff0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
XF86Config:
# File generated by anaconda.
Section "ServerLayout"
Identifier "Anaconda Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Mouse1" "SendCoreEvents"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "Files"
# The location of the RGB database. Note, this is the name of
the
# file minus the extension (like ".txt" or ".db"). There is
normally
# no need to change the default.
RgbPath "/usr/X11R6/lib/X11/rgb"
# Multiple FontPath entries are allowed (they are concatenated
together)
# By default, Red Hat 6.0 and later now use a font server
independent of
# the X server to render fonts.
FontPath "unix/:7100"
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "fbdevhw"
Load "dri"
Load "glx"
Load "record"
Load "freetype"
Load "type1"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
# Option "AutoRepeat" "500 5"
# when using XQUEUE, comment out the above line, and uncomment
the
# following line
# Option "Protocol" "Xqueue"
# Specify which keyboard LEDs can be user-controlled (eg, with
xset(1))
# Option "Xleds" "1 2 3"
# To disable the XKEYBOARD extension, uncomment XkbDisable.
# Option "XkbDisable"
# To customise the XKB settings to suit your keyboard, modify
the
# lines below (which are the defaults). For example, for a
non-U.S.
# keyboard, you will probably want to use:
# Option "XkbModel" "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
# Option "XkbModel" "microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
# Option "XkbLayout" "de"
# or:
# Option "XkbLayout" "de"
# Option "XkbVariant" "nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
# Option "XkbOptions" "ctrl:swapcaps"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
#Option "XkbVariant" ""
#Option "XkbOptions" ""
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "PS/2"
Option "Device" "/dev/psaux"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "yes"
EndSection
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Device" "/dev/input/mice"
Option "Protocol" "IMPS/2"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 30-55
VertRefresh 50-120
Option "dpms"
EndSection
Section "Device"
# no known options
Identifier "NVIDIA GeForce 2 MX (generic)"
Driver "nv"
VendorName "NVIDIA GeForce 2 MX (generic)"
BoardName "NVIDIA GeForce 2 MX (generic)"
#BusID
EndSection
Section "Screen"
Identifier "Screen0"
Device "NVIDIA GeForce 2 MX (generic)"
Monitor "Monitor0"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1024x768" "800x600" "640x480"
EndSubsection
EndSection
Section "DRI"
Mode 0666
EndSection
cmdline:
auto BOOT_IMAGE=linux ro BOOT_FILE=/boot/vmlinuz-2.4.18-14
root=LABEL=/
dma:
4: cascade
intrrupts:
CPU0
0: 337647 XT-PIC timer
1: 2694 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 0 XT-PIC usb-ohci, usb-ohci
8: 1 XT-PIC rtc
12: 20 XT-PIC PS/2 Mouse
14: 27338 XT-PIC ide0
NMI: 0
ERR: 2
partitions:
major minor #blocks name rio rmerge rsect ruse wio wmerge
wsect wuse running use aveq
3 0 39121488 hda 2567 4181 52107 22201 1417 1941 26952
45880 -2 329576 7788488
3 1 5245191 hda1 9 43 104 109 0 0 0 0 0 109 109
3 2 1 hda2 0 0 0 0 0 0 0 0 0 0 0
3 5 10490413 hda5 9 43 104 95 0 0 0 0 0 95 95
3 6 11695288 hda6 50 43 145 214 7 1 8 95 0 230 310
3 7 8104761 hda7 9 43 104 132 0 0 0 0 0 132 132
3 8 3277228 hda8 2475 3966 51498 21527 1410 1940 26944
45785 0 22394 67314
3 9 305203 hda9 9 25 104 56 0 0 0 0 0 56 56
My e-mail addresses are: linux_guyus@yahoo.com and
linux_guyus@rediff.com
My postel address: 80, Ahilya Nagar Ext. Annapurna Road, Indore,
M.P.,
India. PIN 452009
please answer me soon.
Thanking you.
Saurabh Khanna.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2003-01-31 18:46 saurabh khanna
@ 2003-02-03 12:53 ` Alexander Kellett
0 siblings, 0 replies; 669+ messages in thread
From: Alexander Kellett @ 2003-02-03 12:53 UTC (permalink / raw)
To: saurabh khanna; +Cc: linux-kernel
hiya,
unfortunately this list isn't for such problems and it
would be better to contact your distribution or the various
forums it has. try google.
/me wonders again why this list isn't called linux-kernel-dev@...
Alex
On Fri, Jan 31, 2003 at 06:46:05PM -0000, saurabh khanna wrote:
> Problem: My xwindows did not open and my sound card don't work.
>
> Xwindows:
> I am a novice. I am using redhat linux 8. It detects my graphics
> card
> correctly but when i tried to open xwindows, my system hangs.
>
> Sound:
> Linux has detected my sound card once but not configured it and
> after
> that nor it is working nither it is detected by my linux.
>
> GRUB:
> Also, i can boot my linux through LILO only. GRUB wont work, it
> gives
> error "Not enough memory".
>
> I have re-installed linux on my computer but the problem
> remains.
> All other detailes are follows.
>
> Kernel version:
> Linux version 2.4.18-14 (bhcompile@astest.test.redhat.com)
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7))
> #1 Wed Sep 4 12:13:11 EDT 2002
>
>
> Commond which triggers the problem:
> startx
>
> Processor information:
> processor : 0
>
> vendor_id : AuthenticAMD
>
> cpu family : 6
>
> model : 6
>
> model name : AMD Athlon(TM) XP 1700+
>
> stepping : 2
>
> cpu MHz : 1469.861
>
> cache size : 256 KB
>
> fdiv_bug : no
>
> hlt_bug : no
>
> f00f_bug : no
>
> coma_bug : no
>
> fpu : yes
>
> fpu_exception : yes
>
> cpuid level : 1
>
> wp : yes
>
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
>
> bogomips : 2920.57
>
>
>
> Module information:
> nls_iso8859-1 3516 1 (autoclean)
>
> nls_cp437 5116 1 (autoclean)
>
> vfat 13084 1 (autoclean)
>
> fat 38744 0 (autoclean)
> [vfat]
> autofs 13348 0 (autoclean) (unused)
>
> ipt_REJECT 3736 2 (autoclean)
>
> iptable_filter 2412 1 (autoclean)
>
> ip_tables 14840 2 [ipt_REJECT iptable_filter]
>
> mousedev 5524 0 (unused)
>
> keybdev 2976 0 (unused)
>
> hid 22244 0 (unused)
>
> input 5888 0 [mousedev keybdev hid]
>
> usb-ohci 21288 0 (unused)
>
> usbcore 77056 1 [hid usb-ohci]
>
> ext3 70400 1
>
> jbd 52212 1 [ext3]
>
>
>
> Loaded driver and hardware information:
> 0000-001f : dma
> 1
> 0020-003f : pic
> 1
> 0040-005f : timer
>
> 0060-006f : keyboard
>
> 0070-007f : rtc
>
> 0080-008f : dma page reg
>
> 00a0-00bf : pic
> 2
> 00c0-00df : dma
> 2
> 00f0-00ff : fpu
>
> 01f0-01f7 : ide
> 0
> 02f8-02ff : serial(auto)
>
> 03c0-03df : vga+
>
> 03f6-03f6 : ide
> 0
> 03f8-03ff : serial(auto)
>
> 0cf8-0cff : PCI conf
> 1
> 5000-500f : PCI device 10de:01b4 (nVidia Corporation)
>
> 5100-511f : PCI device 10de:01b4 (nVidia Corporation)
>
> 5500-550f : PCI device 10de:01b4 (nVidia Corporation)
>
> a800-a80f : nVidia Corporation nForce IDE
>
> a800-a807 : ide0
>
> a808-a80f : ide1
>
> b000-bfff : PCI Bus #01
>
> b800-b807 : Rockwell International HCF 56k Data/Fax/Voice/Spkp
> (w/Handset) Modem
>
> d800-d807 : PCI device 10de:01c3 (nVidia Corporation)
>
> e000-e07f : PCI device 10de:01b1 (nVidia Corporation)
>
> e100-e1ff : PCI device 10de:01b1 (nVidia Corporation)
>
> 00000000-0007ffff : System RAM
>
> 0009fc00-0009ffff : reserved
>
> 000a0000-000bffff : Video RAM area
>
> 000c0000-000c7fff : Video ROM
>
> 000f0000-000fffff : System ROM
>
> 00100000-06febfff : System RAM
>
> 00100000-00247f2e : Kernel code
>
> 00247f2f-0033ed03 : Kernel data
>
> 06fec000-06feefff : ACPI Tables
>
> 06fef000-06ffefff : reserved
>
> 06fff000-06ffffff : ACPI Non-volatile Storage
>
> eb000000-ec7fffff : PCI Bus #02
>
> eb000000-ebffffff : nVidia Corporation GeForce2 Integrated GPU
>
> ec800000-ecffffff : PCI Bus #01
>
> ec800000-ec80ffff : Rockwell International HCF 56k
> Data/Fax/Voice/Spkp (w/Handset) Modem
>
> ed000000-ed000fff : PCI device 10de:01b1 (nVidia Corporation)
>
> ed800000-ed87ffff : PCI device 10de:01b0 (nVidia Corporation)
>
> ee000000-ee0003ff : PCI device 10de:01c3 (nVidia Corporation)
>
> ee800000-ee800fff : PCI device 10de:01c2 (nVidia Corporation)
>
> ee800000-ee800fff : usb-ohci
> e
> f000000-ef000fff : PCI device
> 10de:01c2 (nVidia Corporation)
>
> ef000000-ef000fff : usb-ohci
> e
> ff00000-f7ffffff : PCI Bus #02
>
> f0000000-f7ffffff : nVidia Corporation GeForce2 Integrated GPU
>
> f8000000-fbffffff : PCI device
> 10de:01a4 (nVidia Corporation)
>
> fec00000-fec00fff : reserved
>
> fee00000-fee00fff : reserved
>
> ffff0000-ffffffff : reserved
>
>
> PCI information:
> 00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev
> b2)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [40] AGP version 2.0
> Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
> Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x1
> Capabilities: [60] #08 [2001]
>
> 00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory
> Controller (rev b2)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory
> Controller (rev b2)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:00.3 RAM memory: nVidia Corporation: Unknown device 01aa (rev
> b2)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev
> c3)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Capabilities: [50] #08 [01e1]
>
> 00:01.1 SMBus: nVidia Corporation nForce PCI System Management
> (rev c1)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 5
> Region 0: I/O ports at 5000 [size=16]
> Region 1: I/O ports at 5500 [size=16]
> Region 2: I/O ports at 5100 [size=32]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:02.0 USB Controller: nVidia Corporation: Unknown device 01c2
> (rev c3) (prog-if 10 [OHCI])
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at ef000000 (32-bit, non-prefetchable)
> [size=4K]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:03.0 USB Controller: nVidia Corporation: Unknown device 01c2
> (rev c3) (prog-if 10 [OHCI])
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at ee800000 (32-bit, non-prefetchable)
> [size=4K]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:04.0 Ethernet controller: nVidia Corporation: Unknown device
> 01c3 (rev c2)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (250ns min, 5000ns max)
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at ee000000 (32-bit, non-prefetchable)
> [size=1K]
> Region 1: I/O ports at d800 [size=8]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:05.0 Multimedia audio controller: nVidia Corporation: Unknown
> device 01b0 (rev c2)
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (250ns min, 3000ns max)
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at ed800000 (32-bit, non-prefetchable)
> [size=512K]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:06.0 Multimedia audio controller: nVidia Corporation nForce
> Audio (rev c2)
> Subsystem: nVidia Corporation: Unknown device 8384
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (500ns min, 1250ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at e100 [size=256]
> Region 1: I/O ports at e000 [size=128]
> Region 2: Memory at ed000000 (32-bit, non-prefetchable)
> [disabled] [size=4K]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge
> (rev c2) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000b000-0000bfff
> Memory behind bridge: ec800000-ecffffff
> Prefetchable memory behind bridge: f8000000-f7ffffff
> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>
> 00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3)
> (prog-if 8a [Master SecP PriP])
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Region 4: I/O ports at a800 [size=16]
> Capabilities: [44] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge
> (rev b2) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
> I/O behind bridge: 0000a000-00009fff
> Memory behind bridge: eb000000-ec7fffff
> Prefetchable memory behind bridge: eff00000-f7ffffff
> BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
>
> 01:08.0 Communication controller: Rockwell International HCF 56k
> Data/Fax/Voice/Spkp (w/Handset) Modem (rev 01)
> Subsystem: Rockwell International HCF 56k Data/Fax/Voice/Spkp
> (w/Handset) Modem
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 64
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at ec800000 (32-bit, non-prefetchable)
> [size=64K]
> Region 1: I/O ports at b800 [size=8]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
>
> 02:00.0 VGA compatible controller: nVidia Corporation NV15
> [GeForce2 - nForce GPU] (rev b1) (prog-if 00 [VGA])
> Subsystem: nVidia Corporation: Unknown device 0c11
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 32 (1250ns min, 250ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at eb000000 (32-bit, non-prefetchable)
> [size=16M]
> Region 1: Memory at f0000000 (32-bit, prefetchable)
> [size=128M]
> Expansion ROM at efff0000 [disabled] [size=64K]
> Capabilities: [60] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [44] AGP version 2.0
> Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x4
> Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
>
>
>
> XF86Config:
>
> # File generated by anaconda.
>
> Section "ServerLayout"
> Identifier "Anaconda Configured"
> Screen 0 "Screen0" 0 0
> InputDevice "Mouse0" "CorePointer"
> InputDevice "Mouse1" "SendCoreEvents"
> InputDevice "Keyboard0" "CoreKeyboard"
> EndSection
>
> Section "Files"
>
> # The location of the RGB database. Note, this is the name of
> the
> # file minus the extension (like ".txt" or ".db"). There is
> normally
> # no need to change the default.
>
> RgbPath "/usr/X11R6/lib/X11/rgb"
>
> # Multiple FontPath entries are allowed (they are concatenated
> together)
> # By default, Red Hat 6.0 and later now use a font server
> independent of
> # the X server to render fonts.
>
> FontPath "unix/:7100"
>
> EndSection
>
> Section "Module"
> Load "dbe"
> Load "extmod"
> Load "fbdevhw"
> Load "dri"
> Load "glx"
> Load "record"
> Load "freetype"
> Load "type1"
> EndSection
>
> Section "InputDevice"
> Identifier "Keyboard0"
> Driver "keyboard"
>
> # Option "AutoRepeat" "500 5"
>
> # when using XQUEUE, comment out the above line, and uncomment
> the
> # following line
> # Option "Protocol" "Xqueue"
>
> # Specify which keyboard LEDs can be user-controlled (eg, with
> xset(1))
> # Option "Xleds" "1 2 3"
>
> # To disable the XKEYBOARD extension, uncomment XkbDisable.
> # Option "XkbDisable"
>
> # To customise the XKB settings to suit your keyboard, modify
> the
> # lines below (which are the defaults). For example, for a
> non-U.S.
> # keyboard, you will probably want to use:
> # Option "XkbModel" "pc102"
> # If you have a US Microsoft Natural keyboard, you can use:
> # Option "XkbModel" "microsoft"
> #
> # Then to change the language, change the Layout setting.
> # For example, a german layout can be obtained with:
> # Option "XkbLayout" "de"
> # or:
> # Option "XkbLayout" "de"
> # Option "XkbVariant" "nodeadkeys"
> #
> # If you'd like to switch the positions of your capslock and
> # control keys, use:
> # Option "XkbOptions" "ctrl:swapcaps"
> Option "XkbRules" "xfree86"
> Option "XkbModel" "pc105"
> Option "XkbLayout" "us"
> #Option "XkbVariant" ""
> #Option "XkbOptions" ""
> EndSection
>
> Section "InputDevice"
> Identifier "Mouse0"
> Driver "mouse"
> Option "Protocol" "PS/2"
> Option "Device" "/dev/psaux"
> Option "ZAxisMapping" "4 5"
> Option "Emulate3Buttons" "yes"
> EndSection
>
>
> Section "InputDevice"
> Identifier "Mouse1"
> Driver "mouse"
> Option "Device" "/dev/input/mice"
> Option "Protocol" "IMPS/2"
> Option "Emulate3Buttons" "no"
> Option "ZAxisMapping" "4 5"
> EndSection
>
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Monitor Vendor"
> ModelName "Monitor Model"
> HorizSync 30-55
> VertRefresh 50-120
> Option "dpms"
>
>
> EndSection
>
> Section "Device"
> # no known options
> Identifier "NVIDIA GeForce 2 MX (generic)"
> Driver "nv"
> VendorName "NVIDIA GeForce 2 MX (generic)"
> BoardName "NVIDIA GeForce 2 MX (generic)"
>
> #BusID
> EndSection
>
> Section "Screen"
> Identifier "Screen0"
> Device "NVIDIA GeForce 2 MX (generic)"
> Monitor "Monitor0"
> DefaultDepth 16
>
> Subsection "Display"
> Depth 16
> Modes "1024x768" "800x600" "640x480"
> EndSubsection
>
> EndSection
>
> Section "DRI"
> Mode 0666
> EndSection
>
> cmdline:
> auto BOOT_IMAGE=linux ro BOOT_FILE=/boot/vmlinuz-2.4.18-14
> root=LABEL=/
>
>
> dma:
> 4: cascade
>
>
> intrrupts:
> CPU0
> 0: 337647 XT-PIC timer
> 1: 2694 XT-PIC keyboard
> 2: 0 XT-PIC cascade
> 5: 0 XT-PIC usb-ohci, usb-ohci
> 8: 1 XT-PIC rtc
> 12: 20 XT-PIC PS/2 Mouse
> 14: 27338 XT-PIC ide0
> NMI: 0
> ERR: 2
>
>
> partitions:
> major minor #blocks name rio rmerge rsect ruse wio wmerge
> wsect wuse running use aveq
>
> 3 0 39121488 hda 2567 4181 52107 22201 1417 1941 26952
> 45880 -2 329576 7788488
> 3 1 5245191 hda1 9 43 104 109 0 0 0 0 0 109 109
> 3 2 1 hda2 0 0 0 0 0 0 0 0 0 0 0
> 3 5 10490413 hda5 9 43 104 95 0 0 0 0 0 95 95
> 3 6 11695288 hda6 50 43 145 214 7 1 8 95 0 230 310
> 3 7 8104761 hda7 9 43 104 132 0 0 0 0 0 132 132
> 3 8 3277228 hda8 2475 3966 51498 21527 1410 1940 26944
> 45785 0 22394 67314
> 3 9 305203 hda9 9 25 104 56 0 0 0 0 0 56 56
>
>
>
> My e-mail addresses are: linux_guyus@yahoo.com and
> linux_guyus@rediff.com
> My postel address: 80, Ahilya Nagar Ext. Annapurna Road, Indore,
> M.P.,
> India. PIN 452009
> please answer me soon.
> Thanking you.
> Saurabh Khanna.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
mvg,
Alex
--
"[...] Konqueror open source project. Weighing in at less than
one tenth the size of another open source renderer"
Apple, Jan 2003 (http://www.apple.com/safari/)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 5:54 Anoop J.
2003-01-24 6:28 ` David Lang
0 siblings, 1 reply; 669+ messages in thread
From: Anoop J. @ 2003-01-24 5:54 UTC (permalink / raw)
To: linux-mm, linux-kernel
How is this different from a fully associative cache .Would be better if u
could deal it based on the address bits used
Thanks
David Lang wrote:
>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>>From: Anoop J. <cs99001@nitc.ac.in>
>>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>>How does page coloring work. Iwant its mechanism not the implementation.
>>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>>able to grasp it .
>>
>>
>>Thanks in advance
>>
>>
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 5:54 Anoop J.
@ 2003-01-24 6:28 ` David Lang
0 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 6:28 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-mm, linux-kernel
implementing a fully associative cache eliminates the need for page
coloring, but it has to be implemented in hardware. if you don't have
fully associative caches in your hardware page coloring helps avoid the
worst case memory allocations.
from what I have seen on the attempts to implement it the problem is that
the calculations needed to do page colored allocations end up costing
enough that they end up with a net loss compared to the old method.
David Lang
On Fri, 24 Jan 2003, Anoop J.
wrote:
> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>
>
> How is this different from a fully associative cache .Would be better if u
> could deal it based on the address bits used
>
> Thanks
>
> David Lang wrote:
>
> >The idea of page coloring is based on the fact that common implementations
> >of caching can't put any page in memory in any line in the cache (such an
> >implementation is possible, but is more expensive to do so is not commonly
> >done)
> >
> >With this implementation it means that if your program happens to use
> >memory that cannot be mapped to half of the cache lines then effectivly
> >the CPU cache is half it's rated size for your program. the next time your
> >program runs it may get a more favorable memory allocation and be able to
> >use all of the cache and therefor run faster.
> >
> >Page coloring is an attampt to take this into account when allocating
> >memory to programs so that every program gets to use all of the cache.
> >
> >David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J. wrote:
> >
> >>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> >>From: Anoop J. <cs99001@nitc.ac.in>
> >>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
> >>
> >>
> >>How does page coloring work. Iwant its mechanism not the implementation.
> >>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> >>able to grasp it .
> >>
> >>
> >>Thanks in advance
> >>
> >>
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>Please read the FAQ at http://www.tux.org/lkml/
> >>
> >
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 6:28 ` David Lang
0 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 6:28 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-mm, linux-kernel
implementing a fully associative cache eliminates the need for page
coloring, but it has to be implemented in hardware. if you don't have
fully associative caches in your hardware page coloring helps avoid the
worst case memory allocations.
from what I have seen on the attempts to implement it the problem is that
the calculations needed to do page colored allocations end up costing
enough that they end up with a net loss compared to the old method.
David Lang
On Fri, 24 Jan 2003, Anoop J.
wrote:
> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>
>
> How is this different from a fully associative cache .Would be better if u
> could deal it based on the address bits used
>
> Thanks
>
> David Lang wrote:
>
> >The idea of page coloring is based on the fact that common implementations
> >of caching can't put any page in memory in any line in the cache (such an
> >implementation is possible, but is more expensive to do so is not commonly
> >done)
> >
> >With this implementation it means that if your program happens to use
> >memory that cannot be mapped to half of the cache lines then effectivly
> >the CPU cache is half it's rated size for your program. the next time your
> >program runs it may get a more favorable memory allocation and be able to
> >use all of the cache and therefor run faster.
> >
> >Page coloring is an attampt to take this into account when allocating
> >memory to programs so that every program gets to use all of the cache.
> >
> >David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J. wrote:
> >
> >>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> >>From: Anoop J. <cs99001@nitc.ac.in>
> >>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
> >>
> >>
> >>How does page coloring work. Iwant its mechanism not the implementation.
> >>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> >>able to grasp it .
> >>
> >>
> >>Thanks in advance
> >>
> >>
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>Please read the FAQ at http://www.tux.org/lkml/
> >>
> >
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 6:28 ` David Lang
@ 2003-01-24 8:51 ` Anoop J.
-1 siblings, 0 replies; 669+ messages in thread
From: Anoop J. @ 2003-01-24 8:51 UTC (permalink / raw)
To: david.lang; +Cc: linux-mm, linux-kernel
I read that the data coherency problem due to virtual indexing is avoided
through page coloring and it has also got the speed of physical indexing
can u just elaborate on how this is possible?
Thanks
> implementing a fully associative cache eliminates the need for page
> coloring, but it has to be implemented in hardware. if you don't have
> fully associative caches in your hardware page coloring helps avoid the
> worst case memory allocations.
>
> from what I have seen on the attempts to implement it the problem is
> that the calculations needed to do page colored allocations end up
> costing enough that they end up with a net loss compared to the old
> method.
>
> David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J.
> wrote:
>
>> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>>
>>
>> How is this different from a fully associative cache .Would be better
>> if u could deal it based on the address bits used
>>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 8:51 ` Anoop J.
0 siblings, 0 replies; 669+ messages in thread
From: Anoop J. @ 2003-01-24 8:51 UTC (permalink / raw)
To: david.lang; +Cc: linux-mm, linux-kernel
I read that the data coherency problem due to virtual indexing is avoided
through page coloring and it has also got the speed of physical indexing
can u just elaborate on how this is possible?
Thanks
> implementing a fully associative cache eliminates the need for page
> coloring, but it has to be implemented in hardware. if you don't have
> fully associative caches in your hardware page coloring helps avoid the
> worst case memory allocations.
>
> from what I have seen on the attempts to implement it the problem is
> that the calculations needed to do page colored allocations end up
> costing enough that they end up with a net loss compared to the old
> method.
>
> David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J.
> wrote:
>
>> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>>
>>
>> How is this different from a fully associative cache .Would be better
>> if u could deal it based on the address bits used
>>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 8:51 ` Anoop J.
@ 2003-01-24 8:48 ` David Lang
-1 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 8:48 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-mm, linux-kernel
I think this is a case of the same tuerm being used for two different
purposes. I don't know the use you are refering to.
David Lang
On Fri, 24 Jan 2003, Anoop J. wrote:
> I read that the data coherency problem due to virtual indexing is avoided
> through page coloring and it has also got the speed of physical indexing
> can u just elaborate on how this is possible?
>
>
> Thanks
>
>
>
>
> > implementing a fully associative cache eliminates the need for page
> > coloring, but it has to be implemented in hardware. if you don't have
> > fully associative caches in your hardware page coloring helps avoid the
> > worst case memory allocations.
> >
> > from what I have seen on the attempts to implement it the problem is
> > that the calculations needed to do page colored allocations end up
> > costing enough that they end up with a net loss compared to the old
> > method.
> >
> > David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J.
> > wrote:
> >
> >> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> >> From: Anoop J. <cs99001@nitc.ac.in>
> >> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> >>
> >>
> >> How is this different from a fully associative cache .Would be better
> >> if u could deal it based on the address bits used
> >>
>
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 8:48 ` David Lang
0 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 8:48 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-mm, linux-kernel
I think this is a case of the same tuerm being used for two different
purposes. I don't know the use you are refering to.
David Lang
On Fri, 24 Jan 2003, Anoop J. wrote:
> I read that the data coherency problem due to virtual indexing is avoided
> through page coloring and it has also got the speed of physical indexing
> can u just elaborate on how this is possible?
>
>
> Thanks
>
>
>
>
> > implementing a fully associative cache eliminates the need for page
> > coloring, but it has to be implemented in hardware. if you don't have
> > fully associative caches in your hardware page coloring helps avoid the
> > worst case memory allocations.
> >
> > from what I have seen on the attempts to implement it the problem is
> > that the calculations needed to do page colored allocations end up
> > costing enough that they end up with a net loss compared to the old
> > method.
> >
> > David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J.
> > wrote:
> >
> >> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> >> From: Anoop J. <cs99001@nitc.ac.in>
> >> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> >>
> >>
> >> How is this different from a fully associative cache .Would be better
> >> if u could deal it based on the address bits used
> >>
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 8:48 ` David Lang
@ 2003-01-24 9:49 ` Anoop J.
-1 siblings, 0 replies; 669+ messages in thread
From: Anoop J. @ 2003-01-24 9:49 UTC (permalink / raw)
To: david.lang; +Cc: linux-mm, linux-kernel
ok i shall put it in another way
since virtual indexing is a representation of the virtual memory,
it is possible for more multiple virtual addresses to represent the same
physical address.So the problem of aliasing occurs in the cache.Does page
coloring guarantee a unique mapping of physical address.If so how is the
maping from virtual to physical address
Thanks
> I think this is a case of the same tuerm being used for two different
> purposes. I don't know the use you are refering to.
>
> David Lang
>
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 9:49 ` Anoop J.
0 siblings, 0 replies; 669+ messages in thread
From: Anoop J. @ 2003-01-24 9:49 UTC (permalink / raw)
To: david.lang; +Cc: linux-mm, linux-kernel
ok i shall put it in another way
since virtual indexing is a representation of the virtual memory,
it is possible for more multiple virtual addresses to represent the same
physical address.So the problem of aliasing occurs in the cache.Does page
coloring guarantee a unique mapping of physical address.If so how is the
maping from virtual to physical address
Thanks
> I think this is a case of the same tuerm being used for two different
> purposes. I don't know the use you are refering to.
>
> David Lang
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 9:49 ` Anoop J.
@ 2003-01-24 19:14 ` David Lang
-1 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 19:14 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-mm, linux-kernel
the cache never sees the virtual addresses, it operated excclusivly on the
physical addresses so the problem of aliasing never comes up.
virtual to physical addres mapping is all resolved before anything hits
the cache.
David Lang
On Fri, 24 Jan 2003, Anoop J. wrote:
> Date: Fri, 24 Jan 2003 15:19:16 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: david.lang@digitalinsight.com
> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> ok i shall put it in another way
> since virtual indexing is a representation of the virtual memory,
> it is possible for more multiple virtual addresses to represent the same
> physical address.So the problem of aliasing occurs in the cache.Does page
> coloring guarantee a unique mapping of physical address.If so how is the
> maping from virtual to physical address
>
>
>
> Thanks
>
>
>
> > I think this is a case of the same tuerm being used for two different
> > purposes. I don't know the use you are refering to.
> >
> > David Lang
> >
> >
> >
>
>
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 19:14 ` David Lang
0 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 19:14 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-mm, linux-kernel
the cache never sees the virtual addresses, it operated excclusivly on the
physical addresses so the problem of aliasing never comes up.
virtual to physical addres mapping is all resolved before anything hits
the cache.
David Lang
On Fri, 24 Jan 2003, Anoop J. wrote:
> Date: Fri, 24 Jan 2003 15:19:16 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: david.lang@digitalinsight.com
> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> ok i shall put it in another way
> since virtual indexing is a representation of the virtual memory,
> it is possible for more multiple virtual addresses to represent the same
> physical address.So the problem of aliasing occurs in the cache.Does page
> coloring guarantee a unique mapping of physical address.If so how is the
> maping from virtual to physical address
>
>
>
> Thanks
>
>
>
> > I think this is a case of the same tuerm being used for two different
> > purposes. I don't know the use you are refering to.
> >
> > David Lang
> >
> >
> >
>
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 19:14 ` David Lang
@ 2003-01-24 19:40 ` Maciej W. Rozycki
-1 siblings, 0 replies; 669+ messages in thread
From: Maciej W. Rozycki @ 2003-01-24 19:40 UTC (permalink / raw)
To: David Lang; +Cc: Anoop J., linux-mm, linux-kernel
On Fri, 24 Jan 2003, David Lang wrote:
> the cache never sees the virtual addresses, it operated excclusivly on the
> physical addresses so the problem of aliasing never comes up.
It depends on the implementation.
> virtual to physical addres mapping is all resolved before anything hits
> the cache.
It depends on the processor.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 19:40 ` Maciej W. Rozycki
0 siblings, 0 replies; 669+ messages in thread
From: Maciej W. Rozycki @ 2003-01-24 19:40 UTC (permalink / raw)
To: David Lang; +Cc: Anoop J., linux-mm, linux-kernel
On Fri, 24 Jan 2003, David Lang wrote:
> the cache never sees the virtual addresses, it operated excclusivly on the
> physical addresses so the problem of aliasing never comes up.
It depends on the implementation.
> virtual to physical addres mapping is all resolved before anything hits
> the cache.
It depends on the processor.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2003-01-24 5:08 Anoop J.
2003-01-24 5:11 ` David Lang
0 siblings, 1 reply; 669+ messages in thread
From: Anoop J. @ 2003-01-24 5:08 UTC (permalink / raw)
To: linux-kernel, linux-mm
How does page coloring work. Iwant its mechanism not the implementation.
I went through some pages of W.L.Lynch's paper on cache and VM. Still not
able to grasp it .
Thanks in advance
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 5:08 Anoop J.
@ 2003-01-24 5:11 ` David Lang
0 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 5:11 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-kernel, linux-mm
The idea of page coloring is based on the fact that common implementations
of caching can't put any page in memory in any line in the cache (such an
implementation is possible, but is more expensive to do so is not commonly
done)
With this implementation it means that if your program happens to use
memory that cannot be mapped to half of the cache lines then effectivly
the CPU cache is half it's rated size for your program. the next time your
program runs it may get a more favorable memory allocation and be able to
use all of the cache and therefor run faster.
Page coloring is an attampt to take this into account when allocating
memory to programs so that every program gets to use all of the cache.
David Lang
On Fri, 24 Jan 2003, Anoop J. wrote:
> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>
>
> How does page coloring work. Iwant its mechanism not the implementation.
> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> able to grasp it .
>
>
> Thanks in advance
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 5:11 ` David Lang
0 siblings, 0 replies; 669+ messages in thread
From: David Lang @ 2003-01-24 5:11 UTC (permalink / raw)
To: Anoop J.; +Cc: linux-kernel, linux-mm
The idea of page coloring is based on the fact that common implementations
of caching can't put any page in memory in any line in the cache (such an
implementation is possible, but is more expensive to do so is not commonly
done)
With this implementation it means that if your program happens to use
memory that cannot be mapped to half of the cache lines then effectivly
the CPU cache is half it's rated size for your program. the next time your
program runs it may get a more favorable memory allocation and be able to
use all of the cache and therefor run faster.
Page coloring is an attampt to take this into account when allocating
memory to programs so that every program gets to use all of the cache.
David Lang
On Fri, 24 Jan 2003, Anoop J. wrote:
> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>
>
> How does page coloring work. Iwant its mechanism not the implementation.
> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> able to grasp it .
>
>
> Thanks in advance
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 5:11 ` David Lang
@ 2003-01-24 6:06 ` John Alvord
-1 siblings, 0 replies; 669+ messages in thread
From: John Alvord @ 2003-01-24 6:06 UTC (permalink / raw)
To: David Lang; +Cc: Anoop J., linux-kernel, linux-mm
The big challenge in Linux is that several serious attempts to add
page coloring have foundered on the shoals of "no benefit found". It
may be that the typical hardware Linux runs on just doesn't experience
the problem very much.
john
On Thu, 23 Jan 2003 21:11:10 -0800 (PST), David Lang
<david.lang@digitalinsight.com> wrote:
>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>> How does page coloring work. Iwant its mechanism not the implementation.
>> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>> able to grasp it .
>>
>>
>> Thanks in advance
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-24 6:06 ` John Alvord
0 siblings, 0 replies; 669+ messages in thread
From: John Alvord @ 2003-01-24 6:06 UTC (permalink / raw)
To: David Lang; +Cc: Anoop J., linux-kernel, linux-mm
The big challenge in Linux is that several serious attempts to add
page coloring have foundered on the shoals of "no benefit found". It
may be that the typical hardware Linux runs on just doesn't experience
the problem very much.
john
On Thu, 23 Jan 2003 21:11:10 -0800 (PST), David Lang
<david.lang@digitalinsight.com> wrote:
>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>> How does page coloring work. Iwant its mechanism not the implementation.
>> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>> able to grasp it .
>>
>>
>> Thanks in advance
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-24 6:06 ` John Alvord
@ 2003-01-25 2:29 ` Jason Papadopoulos
-1 siblings, 0 replies; 669+ messages in thread
From: Jason Papadopoulos @ 2003-01-25 2:29 UTC (permalink / raw)
To: linux-kernel, linux-mm
At 10:06 PM 1/23/03 -0800, John Alvord wrote:
>The big challenge in Linux is that several serious attempts to add
>page coloring have foundered on the shoals of "no benefit found". It
>may be that the typical hardware Linux runs on just doesn't experience
>the problem very much.
Another strike against page coloring is that it gives tremendous benefits
when caches are large and not very associative, but if both of these are
not present the benefits are much smaller. In the case of latter-day PCs,
neither of these is the case: the caches are very small and at least 8-way
set associative.
For the record, I finally got to try my own page coloring patch on a 1GHz
Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
own number crunching benchmarks and a kernel compile don't show any benefit
at all, and lmbench is completely unchanged except for the mmap latency,
which is slightly worse. Hardly a compelling case for PCs!
Oh well. At least now I'll be able to port to 2.5 :)
jasonp
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-25 2:29 ` Jason Papadopoulos
0 siblings, 0 replies; 669+ messages in thread
From: Jason Papadopoulos @ 2003-01-25 2:29 UTC (permalink / raw)
To: linux-kernel, linux-mm
At 10:06 PM 1/23/03 -0800, John Alvord wrote:
>The big challenge in Linux is that several serious attempts to add
>page coloring have foundered on the shoals of "no benefit found". It
>may be that the typical hardware Linux runs on just doesn't experience
>the problem very much.
Another strike against page coloring is that it gives tremendous benefits
when caches are large and not very associative, but if both of these are
not present the benefits are much smaller. In the case of latter-day PCs,
neither of these is the case: the caches are very small and at least 8-way
set associative.
For the record, I finally got to try my own page coloring patch on a 1GHz
Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
own number crunching benchmarks and a kernel compile don't show any benefit
at all, and lmbench is completely unchanged except for the mmap latency,
which is slightly worse. Hardly a compelling case for PCs!
Oh well. At least now I'll be able to port to 2.5 :)
jasonp
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-25 2:29 ` Jason Papadopoulos
@ 2003-01-25 2:26 ` Larry McVoy
-1 siblings, 0 replies; 669+ messages in thread
From: Larry McVoy @ 2003-01-25 2:26 UTC (permalink / raw)
To: Jason Papadopoulos; +Cc: linux-kernel, linux-mm
> For the record, I finally got to try my own page coloring patch on a 1GHz
> Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> own number crunching benchmarks and a kernel compile don't show any benefit
> at all, and lmbench is completely unchanged except for the mmap latency,
> which is slightly worse. Hardly a compelling case for PCs!
If it works correctly then the variability in lat_ctx should go away.
Try this
for p in 2 4 8 12 16 24 32 64
do for size in 0 2 4 8 16
do for i in 1 2 3 4 5 6 7 8 9 0
do lat_ctx -s$size $p
done
done
done
on both the with and without kernel. The page coloring should make the
numbers rock steady, without it, they will bounce a lot.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-25 2:26 ` Larry McVoy
0 siblings, 0 replies; 669+ messages in thread
From: Larry McVoy @ 2003-01-25 2:26 UTC (permalink / raw)
To: Jason Papadopoulos; +Cc: linux-kernel, linux-mm
> For the record, I finally got to try my own page coloring patch on a 1GHz
> Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> own number crunching benchmarks and a kernel compile don't show any benefit
> at all, and lmbench is completely unchanged except for the mmap latency,
> which is slightly worse. Hardly a compelling case for PCs!
If it works correctly then the variability in lat_ctx should go away.
Try this
for p in 2 4 8 12 16 24 32 64
do for size in 0 2 4 8 16
do for i in 1 2 3 4 5 6 7 8 9 0
do lat_ctx -s$size $p
done
done
done
on both the with and without kernel. The page coloring should make the
numbers rock steady, without it, they will bounce a lot.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-25 2:26 ` Larry McVoy
@ 2003-01-25 17:47 ` Eric W. Biederman
-1 siblings, 0 replies; 669+ messages in thread
From: Eric W. Biederman @ 2003-01-25 17:47 UTC (permalink / raw)
To: Larry McVoy; +Cc: Jason Papadopoulos, linux-kernel, linux-mm
Larry McVoy <lm@bitmover.com> writes:
> > For the record, I finally got to try my own page coloring patch on a 1GHz
> > Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> > own number crunching benchmarks and a kernel compile don't show any benefit
> > at all, and lmbench is completely unchanged except for the mmap latency,
> > which is slightly worse. Hardly a compelling case for PCs!
>
> If it works correctly then the variability in lat_ctx should go away.
> Try this
>
> for p in 2 4 8 12 16 24 32 64
> do for size in 0 2 4 8 16
> do for i in 1 2 3 4 5 6 7 8 9 0
> do lat_ctx -s$size $p
> done
> done
> done
>
> on both the with and without kernel. The page coloring should make the
> numbers rock steady, without it, they will bounce a lot.
On the same kind of vein I have seen some tremendous variability in the
stream benchmark. Under linux I have gotten it to very as much
as a 100MB/sec by running updatedb, between runs. In one case
it ran faster with updatedb running in the background.
But at the same time streams tends to be very steady if you have a quiet
machine and run it several times in a row repeatedly because it gets
allocated essentially the same memory every run.
So I do no the variables of cache contention do have effect on some
real programs. I have not yet tracked it down to see if cache coloring
could be a benefit. I suspect the buddy allocator actually comes
quite close most of the time, and tricks like allocating multiple pages
at once could improve that even more with very little effort, while reducing
page fault miss times.
I am wondering if there is any point in biasing page addresses in between
processes so that processes are less likely to have a cache conflict.
i.e. process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K
Eric
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-25 17:47 ` Eric W. Biederman
0 siblings, 0 replies; 669+ messages in thread
From: Eric W. Biederman @ 2003-01-25 17:47 UTC (permalink / raw)
To: Larry McVoy; +Cc: Jason Papadopoulos, linux-kernel, linux-mm
Larry McVoy <lm@bitmover.com> writes:
> > For the record, I finally got to try my own page coloring patch on a 1GHz
> > Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> > own number crunching benchmarks and a kernel compile don't show any benefit
> > at all, and lmbench is completely unchanged except for the mmap latency,
> > which is slightly worse. Hardly a compelling case for PCs!
>
> If it works correctly then the variability in lat_ctx should go away.
> Try this
>
> for p in 2 4 8 12 16 24 32 64
> do for size in 0 2 4 8 16
> do for i in 1 2 3 4 5 6 7 8 9 0
> do lat_ctx -s$size $p
> done
> done
> done
>
> on both the with and without kernel. The page coloring should make the
> numbers rock steady, without it, they will bounce a lot.
On the same kind of vein I have seen some tremendous variability in the
stream benchmark. Under linux I have gotten it to very as much
as a 100MB/sec by running updatedb, between runs. In one case
it ran faster with updatedb running in the background.
But at the same time streams tends to be very steady if you have a quiet
machine and run it several times in a row repeatedly because it gets
allocated essentially the same memory every run.
So I do no the variables of cache contention do have effect on some
real programs. I have not yet tracked it down to see if cache coloring
could be a benefit. I suspect the buddy allocator actually comes
quite close most of the time, and tricks like allocating multiple pages
at once could improve that even more with very little effort, while reducing
page fault miss times.
I am wondering if there is any point in biasing page addresses in between
processes so that processes are less likely to have a cache conflict.
i.e. process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-25 17:47 ` Eric W. Biederman
@ 2003-01-25 23:10 ` Larry McVoy
-1 siblings, 0 replies; 669+ messages in thread
From: Larry McVoy @ 2003-01-25 23:10 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Larry McVoy, Jason Papadopoulos, linux-kernel, linux-mm
> I am wondering if there is any point in biasing page addresses in between
> processes so that processes are less likely to have a cache conflict.
> i.e. process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K
All good page coloring implementation do exactly that. The starting
index into the page buckets is based on process id.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-25 23:10 ` Larry McVoy
0 siblings, 0 replies; 669+ messages in thread
From: Larry McVoy @ 2003-01-25 23:10 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Larry McVoy, Jason Papadopoulos, linux-kernel, linux-mm
> I am wondering if there is any point in biasing page addresses in between
> processes so that processes are less likely to have a cache conflict.
> i.e. process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K
All good page coloring implementation do exactly that. The starting
index into the page buckets is based on process id.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2003-01-25 23:10 ` Larry McVoy
@ 2003-01-26 8:12 ` David S. Miller
-1 siblings, 0 replies; 669+ messages in thread
From: David S. Miller @ 2003-01-26 8:12 UTC (permalink / raw)
To: Larry McVoy; +Cc: Eric W. Biederman, Jason Papadopoulos, linux-kernel, linux-mm
On Sat, 2003-01-25 at 15:10, Larry McVoy wrote:
> All good page coloring implementation do exactly that. The starting
> index into the page buckets is based on process id.
I think everyone interested in learning more about this
topic should go read the following papers, they were very
helpful when I was fiddling around in this area.
These papers, in turn, reference several others which are
good reads as well.
1) W. L. Lynch, B. K. Bray, and M. J. Flynn. "The effect of page
allocation on caches". In Micro-25 Conference Proceedings, pages
222-225, December 1992.
2) W. Lynch and M. Flynn. "Cache improvements through colored page
allocation". ACM Transactions on Computer Systems, 1993. Submitted
for review, 1992.
3) William L. Lynch. "The Interaction of Virtual Memory and Cache
Memory". PhD thesis, Stanford University, October
1993. CSL-TR-93-587.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2003-01-26 8:12 ` David S. Miller
0 siblings, 0 replies; 669+ messages in thread
From: David S. Miller @ 2003-01-26 8:12 UTC (permalink / raw)
To: Larry McVoy; +Cc: Eric W. Biederman, Jason Papadopoulos, linux-kernel, linux-mm
On Sat, 2003-01-25 at 15:10, Larry McVoy wrote:
> All good page coloring implementation do exactly that. The starting
> index into the page buckets is based on process id.
I think everyone interested in learning more about this
topic should go read the following papers, they were very
helpful when I was fiddling around in this area.
These papers, in turn, reference several others which are
good reads as well.
1) W. L. Lynch, B. K. Bray, and M. J. Flynn. "The effect of page
allocation on caches". In Micro-25 Conference Proceedings, pages
222-225, December 1992.
2) W. Lynch and M. Flynn. "Cache improvements through colored page
allocation". ACM Transactions on Computer Systems, 1993. Submitted
for review, 1992.
3) William L. Lynch. "The Interaction of Virtual Memory and Cache
Memory". PhD thesis, Stanford University, October
1993. CSL-TR-93-587.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2003-01-16 23:54 devnull
2003-01-17 0:35 ` your mail William Lee Irwin III
0 siblings, 1 reply; 669+ messages in thread
From: devnull @ 2003-01-16 23:54 UTC (permalink / raw)
To: linux-scsi
unsubscribe linux-scsi@vger.kernel.org
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-11-11 19:22 David Mosberger
2002-11-12 1:39 ` your mail Rik van Riel
0 siblings, 1 reply; 669+ messages in thread
From: David Mosberger @ 2002-11-11 19:22 UTC (permalink / raw)
To: Mario Smarduch; +Cc: linux-ia64, linux-kernel
>>>>> On Mon, 11 Nov 2002 10:29:29 -0600, Mario Smarduch <cms063@email.mot.com> said:
Mario> I know that on some commercial Unix systems there are ways to
Mario> cap the CPU utilization by user/group ids are there such
Mario> features/patches available on Linux?
There are probably other patches floating around, but Process Resource
Management (PRM) for Linux is/was one approach to do just that:
http://resourcemanagement.unixsolutions.hp.com/WaRM/prm_linux/
The kernel patches available from this URL are pretty old (up to
2.4.6, as far as I could see), and I'm not sure what the future plans
for PRM on Linux are. Perhaps someone else can provide more details.
--david
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-11-11 19:22 David Mosberger
@ 2002-11-12 1:39 ` Rik van Riel
0 siblings, 0 replies; 669+ messages in thread
From: Rik van Riel @ 2002-11-12 1:39 UTC (permalink / raw)
To: davidm; +Cc: Mario Smarduch, linux-ia64, linux-kernel
On Mon, 11 Nov 2002, David Mosberger wrote:
> >>>>> On Mon, 11 Nov 2002 10:29:29 -0600, Mario Smarduch <cms063@email.mot.com> said:
>
> Mario> I know that on some commercial Unix systems there are ways to
> Mario> cap the CPU utilization by user/group ids are there such
> Mario> features/patches available on Linux?
> The kernel patches available from this URL are pretty old (up to
> 2.4.6, as far as I could see), and I'm not sure what the future plans
> for PRM on Linux are. Perhaps someone else can provide more details.
I'm (slowly) working on a per-user fair scheduler on top of Ingo's
O(1) scheduler. Slowly because it's a fairly complex thing.
Once that is done it should be possible to change the accounting
to other resource containers and generally have fun assigning
priorities, though that is beyond the scope of what I'm trying to
achieve.
cheers,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2002-10-31 18:13 Bloch, Jack
0 siblings, 0 replies; 669+ messages in thread
From: Bloch, Jack @ 2002-10-31 18:13 UTC (permalink / raw)
To: 'Tom Bradley'; +Cc: linux-kernel
Thanks very much.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
-----Original Message-----
From: Tom Bradley [mailto:tojabr@tojabr.com]
Sent: Thursday, October 31, 2002 1:00 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail
They are just regular values. The UL tells the compiler to format the
number as an unsgned long.
On Thu, 31 Oct 2002, Bloch, Jack wrote:
> I am looking at some sample driver code which shows the usage of some
> unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL. I need to
> know what these are defined as. Please excuse my ignorance.
>
> Please CC me directly on any responses.
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-31 15:39 Bloch, Jack
2002-10-31 18:00 ` your mail Tom Bradley
0 siblings, 1 reply; 669+ messages in thread
From: Bloch, Jack @ 2002-10-31 15:39 UTC (permalink / raw)
To: linux-kernel
I am looking at some sample driver code which shows the usage of some
unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL. I need to
know what these are defined as. Please excuse my ignorance.
Please CC me directly on any responses.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-31 15:39 Bloch, Jack
@ 2002-10-31 18:00 ` Tom Bradley
0 siblings, 0 replies; 669+ messages in thread
From: Tom Bradley @ 2002-10-31 18:00 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
They are just regular values. The UL tells the compiler to format the
number as an unsgned long.
On Thu, 31 Oct 2002, Bloch, Jack wrote:
> I am looking at some sample driver code which shows the usage of some
> unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL. I need to
> know what these are defined as. Please excuse my ignorance.
>
> Please CC me directly on any responses.
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-30 12:45 Roberto Fichera
2002-10-30 14:04 ` your mail Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: Roberto Fichera @ 2002-10-30 12:45 UTC (permalink / raw)
To: linux-kernel
I've a problem with a DAT on a Compaq Proliant ML350 with PIII 1GHz,
1Gb RAM, RAID controller Smart Array 451 with 3 x HDD 9Gb RAID 5
and an internal SCSI controller Adaptec 7899 Ultra160 where is connected
only a DAT 12/24 Gb. Current installed distribution is RH7.3 with its kernel
2.4.18-10 but I've tryed the standard 2.4.19 with the same problem.
The problem is that the DAT don't work any more with Linux. This DAT work
well on Win2K :-(! Below there is some logs and a 'ps fax' showing a tar in
D state.
Does anyone know a solution ?
Thanks in advance,
Roberto Fichera
=====================================================
Linux version 2.4.18-10custom (root@custom) (gcc version 2.96 20000731 (Red
Hat Linux 7.3 2.96-112)) #1 Wed Oct 30 11:26:14 CET 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000048000000 (usable)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
256MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f02c0
hm, page 000f0000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f0000 reserved twice.
hm, page 000f1000 reserved twice.
On node 0 totalpages: 294912
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 65536 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: COMPAQ Product ID: PROLIANT APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 16
I/O APIC #8 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFEC01000.
Processors: 1
Kernel command line: auto BOOT_IMAGE=linux ro root=4806
BOOT_FILE=/boot/vmlinuz-2.4.18-10
Initializing CPU#0
Detected 993.400 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1979.18 BogoMIPS
Memory: 1161504k/1179648k available (855k kernel code, 17756k reserved,
218k data, 212k init, 262144k highmem)
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: 32768 (order: 6, 262144 bytes)
Buffer cache hash table entries: 131072 (order: 7, 524288 bytes)
Page-cache hash table entries: 524288 (order: 9, 2097152 bytes)
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 0a
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 993.2873 MHz.
..... host bus clock speed is 132.4380 MHz.
cpu: 0, clocks: 1324380, slice: 662190
CPU0<T0:1324368,T1:662176,D:2,S:662190,C:1324380>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xede3e, last bus=4
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
PCI: Discovered primary peer bus 04 [IRQ]
PCI: Using IRQ router ServerWorks [1166/0200] at 00:0f.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS not found.
Starting kswapd
allocated 64 pages and 64 bhs reserved for the highmem bounces
VFS: Diskquotas version dquot_6.5.0 initialized
Journalled Block Device driver loaded
parport0: PC-style at 0x378 (0x778) [PCSPP(,...)]
parport0: irq 7 detected
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.10e
block: 1024 slots per queue, batch=256
Compaq SMART2 Driver (v 2.4.21)
cpqarray: Device 0x46 has been found at bus 4 dev 4 func 0
PCI: Found IRQ 11 for device 04:04.0
cpqarray: Finding drives on ida0 (Smart Array 431)
cpqarray ida/c0d0: blksz=512 nr_blks=71106240
blk: queue c026b300, I/O limit 4095Mb (mask 0xffffffff)
Partition check:
ida/c0d0: p1 p2 < p5 p6 >
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
PCI: Found IRQ 15 for device 01:05.0
eth0: OEM i82557/i82558 10/100 Ethernet, 00:50:8B:EC:C2:DA, IRQ 15.
Board assembly 010101-034, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 212k freed
Adding Swap: 526296k swap-space (priority -1)
EXT3 FS 2.4-0.9.18, 14 May 2002 on ida0(72,6), internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.18, 14 May 2002 on ida0(72,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 11 for device 01:04.0
PCI: Sharing IRQ 11 with 01:04.1
PCI: Found IRQ 11 for device 01:04.1
PCI: Sharing IRQ 11 with 01:04.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.6
<Adaptec (Compaq OEM) 3960D Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.6
<Adaptec (Compaq OEM) 3960D Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Vendor: COMPAQ Model: SDT-9000 Rev: 4.20
Type: Sequential-Access ANSI SCSI revision: 02
st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0
(scsi0:A:6): 10.000MB/s transfers (10.000MHz, offset 15)
st0: Block limits 1 - 16777215 bytes.
=====================================================
cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 6.2.6
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Corrupted Serial EEPROM
Channel A Target 0 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 1 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 2 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 3 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 4 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 5 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 6 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 10.000MB/s transfers (10.000MHz, offset 15)
Curr: 10.000MB/s transfers (10.000MHz, offset 15)
Channel A Target 6 Lun 0 Settings
Commands Queued 14
Commands Active 1
Command Openings 0
Max Tagged Openings 0
Device Queue Frozen Count 0
Channel A Target 7 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 8 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 9 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 10 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 11 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 12 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 13 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 14 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 15 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
=====================================================
ps fax
PID TTY STAT TIME COMMAND
1 ? S 0:00 init [3]
2 ? SW 0:00 [keventd]
3 ? SWN 0:00 [ksoftirqd_CPU0]
4 ? SW 0:00 [kswapd]
5 ? SW 0:00 [bdflush]
6 ? SW 0:00 [kupdated]
8 ? SW 0:00 [kjournald]
116 ? SW 0:00 [kjournald]
419 ? S 0:00 syslogd -m 0
424 ? S 0:00 klogd -x
477 ? S 0:00 xinetd -stayalive -reuse -pidfile
/var/run/xinetd.pid
520 ? S 0:00 lpd Waiting
551 ? S 0:00 sendmail: accepting connections
570 ? S 0:00 crond
612 ? S 0:00 xfs -droppriv -daemon
630 ? S 0:00 smbd -D
635 ? S 0:00 nmbd -D
639 ? S 0:00 \_ nmbd -D
672 ? S 0:00 /usr/sbin/atd
689 tty3 S 0:00 /sbin/mingetty tty3
690 tty4 S 0:00 /sbin/mingetty tty4
691 tty5 S 0:00 /sbin/mingetty tty5
692 tty6 S 0:00 /sbin/mingetty tty6
756 ? S 0:00 acushare -start
1075 ? S 0:00 login -- root
1079 tty1 S 0:00 \_ -bash
1363 tty1 D 0:00 \_ tar cvf /dev/st0 ./linux/COPYING
./linux/CRED
1341 ? S 0:00 login -- roberto
1367 tty2 S 0:00 \_ -bash
1412 tty2 S 0:00 \_ su
1413 tty2 S 0:00 \_ bash
1505 tty2 R 0:00 \_ ps fax
1345 ? SW 0:00 [scsi_eh_0]
1346 ? SW 0:00 [scsi_eh_1]
=====================================================
lsmod
Module Size Used by Tainted: P
aic7xxx 124864 1 (autoclean)
st 28788 1 (autoclean)
scsi_mod 95648 2 (autoclean) [aic7xxx st]
nls_iso8859-1 3488 0 (autoclean)
nls_cp437 5120 0 (autoclean)
vfat 11804 0 (autoclean)
fat 36056 0 (autoclean) [vfat]
floppy 52480 0 (autoclean)
=====================================================
cat /proc/interrupts
CPU0
0: 248523 XT-PIC timer
1: 7747 XT-PIC keyboard
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
11: 7883 XT-PIC ida0, aic7xxx, aic7xxx
15: 6818 XT-PIC eth0
NMI: 0
LOC: 248489
ERR: 0
MIS: 0
=====================================================
cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0378-037a : parport0
03c0-03df : vga+
0cf8-0cff : PCI conf1
1000-2fff : PCI Bus #01
1000-10ff : Adaptec AHA-3960D / AIC-7899A U160/m
1400-14ff : Adaptec AHA-3960D / AIC-7899A U160/m (#2)
1800-18ff : ATI Technologies Inc Rage XL
1c00-1cff : Compaq Computer Corporation Advanced System Management
Controller
2000-203f : Intel Corp. 82557/8/9 [Ethernet Pro 100]
2000-203f : eepro100
3000-300f : ServerWorks OSB4 IDE Controller
b000-b0ff : Digital Equipment Corporation DECchip 21554
b000-b0ff : cpqarray
=====================================================
cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000cd000-000d0fff : Extension ROM
000f0000-000fffff : System ROM
00100000-47ffffff : System RAM
00100000-001d5fa5 : Kernel code
001d5fa6-0020caff : Kernel data
f5000000-f5000fff : Digital Equipment Corporation DECchip 21554
f5100000-f6ffffff : PCI Bus #01
f5100000-f5100fff : Adaptec AHA-3960D / AIC-7899A U160/m
f5100000-f5100fff : aic7xxx
f5200000-f5200fff : Adaptec AHA-3960D / AIC-7899A U160/m (#2)
f5200000-f5200fff : aic7xxx
f5300000-f53fffff : Intel Corp. 82557/8/9 [Ethernet Pro 100]
f5400000-f5400fff : Intel Corp. 82557/8/9 [Ethernet Pro 100]
f5400000-f5400fff : eepro100
f5500000-f5500fff : ATI Technologies Inc Rage XL
f5600000-f56000ff : Compaq Computer Corporation Advanced System
Management Controller
f6000000-f6ffffff : ATI Technologies Inc Rage XL
f7000000-f7000fff : ServerWorks OSB4/CSB5 OHCI USB Controller
fff80000-ffffffff : reserved
=====================================================
lspci -v
00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05)
Flags: bus master, medium devsel, latency 64
00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05)
Flags: bus master, medium devsel, latency 64
00:01.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
(prog-if 00 [Normal decode])
Flags: bus master, medium devsel, latency 128
Bus: primary=00, secondary=01, subordinate=01, sec-latency=255
I/O behind bridge: 00001000-00002fff
Memory behind bridge: f5100000-f6ffffff
Capabilities: [dc] Power Management version 1
00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 51)
Subsystem: ServerWorks OSB4 South Bridge
Flags: bus master, medium devsel, latency 0
00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller (prog-if 8a [Master
SecP PriP])
Flags: bus master, medium devsel, latency 66
I/O ports at 3000 [size=16]
00:0f.2 USB Controller: ServerWorks OSB4/CSB5 USB Controller (rev 04)
(prog-if 10 [OHCI])
Subsystem: ServerWorks OSB4/CSB5 USB Controller
Flags: bus master, medium devsel, latency 64, IRQ 5
Memory at f7000000 (32-bit, non-prefetchable) [size=4K]
01:04.0 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01)
Subsystem: Compaq Computer Corporation Compaq 64-Bit/66MHz Dual Channel
Wide Ultra3 SCSI Adapter
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
BIST result: 00
I/O ports at 1000 [disabled] [size=256]
Memory at f5100000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
01:04.1 SCSI storage controller: Adaptec AHA-3960D / AIC-7899A U160/m (rev 01)
Subsystem: Compaq Computer Corporation Compaq 64-Bit/66MHz Dual Channel
Wide Ultra3 SCSI Adapter
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
BIST result: 00
I/O ports at 1400 [disabled] [size=256]
Memory at f5200000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
01:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
Subsystem: Compaq Computer Corporation NC3163 Fast Ethernet NIC (embedded,
WOL)
Flags: bus master, medium devsel, latency 66, IRQ 15
Memory at f5400000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 2000 [size=64]
Memory at f5300000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
01:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
(prog-if 00 [VGA])
Subsystem: Compaq Computer Corporation: Unknown device 001e
Flags: bus master, stepping, medium devsel, latency 66, IRQ 5
Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
I/O ports at 1800 [size=256]
Memory at f5500000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [5c] Power Management version 2
01:07.0 System peripheral: Compaq Computer Corporation Advanced System
Management Controller
Subsystem: Compaq Computer Corporation: Unknown device b0f3
Flags: medium devsel, IRQ 10
I/O ports at 1c00 [size=256]
Memory at f5600000 (32-bit, non-prefetchable) [size=256]
04:04.0 RAID bus controller: Digital Equipment Corporation DECchip 21554
(rev 01)
Subsystem: Compaq Computer Corporation Integrated Smart Array
Flags: bus master, medium devsel, latency 66, IRQ 11
Memory at f5000000 (32-bit, non-prefetchable) [size=4K]
I/O ports at b000 [size=256]
Expansion ROM at <unassigned> [disabled] [size=256K]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] Slot ID: 0 slots, First-, chassis 00
Capabilities: [ec] #06 [0080]
______________________________________
E-mail protetta dal servizio antivirus di IsolaWeb Agency & ISP
http://wwww.isolaweb.it
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-10-30 12:45 Roberto Fichera
@ 2002-10-30 14:04 ` Richard B. Johnson
0 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2002-10-30 14:04 UTC (permalink / raw)
To: Roberto Fichera; +Cc: linux-kernel
On Wed, 30 Oct 2002, Roberto Fichera wrote:
> I've a problem with a DAT on a Compaq Proliant ML350 with PIII 1GHz,
> 1Gb RAM, RAID controller Smart Array 451 with 3 x HDD 9Gb RAID 5
> and an internal SCSI controller Adaptec 7899 Ultra160 where is connected
> only a DAT 12/24 Gb. Current installed distribution is RH7.3 with its kernel
> 2.4.18-10 but I've tryed the standard 2.4.19 with the same problem.
> The problem is that the DAT don't work any more with Linux. This DAT work
> well on Win2K :-(! Below there is some logs and a 'ps fax' showing a tar in
> D state.
>
> Does anyone know a solution ?
>
> Adaptec AIC7xxx driver version: 6.2.6
> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> Corrupted Serial EEPROM
^^^^^^^^^^^^^^^^^^^^^^^^^
I think your controller has fallen-back into survival mode
because it lost it's mind. You may want to upgrade the
controller BIOS to fix this problem. Then, see if it handles
tapes okay.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2002-10-30 1:26 Michael Robinton
2002-10-30 9:59 ` your mail Massimiliano Masserelli
0 siblings, 1 reply; 669+ messages in thread
From: Michael Robinton @ 2002-10-30 1:26 UTC (permalink / raw)
To: linux-raid
>I've taken a look at the ML archives, and found an old thread (06/2002)
>on this subject, but found no solution.
>
>I've a working setup with a two disks RAID1 root, which boots
>flawlessly. Troubles arise when simulating hw failure. RAID setup is as
>follows:
>
>raiddev /dev/md0
>raid-level 1
>nr-raid-disks 2
>nr-spare-disks 0
>chunk-size 4
>
>device /dev/hda1
>raid-disk 0
>
>device /dev/hdc1
>raid-disk 1
>If I disconnect /dev/hda before booting, the kernel tries to initialize
>the array, can't access /dev/hda1 (no wonder), marks it as faulty, then
>refuses to initialize the array, dieing with a kernel panic, unable to
>mount root.
>
>If I disconnect /dev/hdc before booting, the array gets started in
>degraded mode, and the startup goes on without a glitch.
>
>If I disconnect /dev/hda and move /dev/hdc to its place (so it's now
>/dev/hda), the array gets started in degraded mode and the startup goes
>on.
>
>Actually, this is already a workable solution (if the first disk dies, I
>just "promote" the second to hda and go looking for a replacement of the
>broken disk), but I think this is not _elegant_. 8)
>
>Could anyone help me shedding some light on the subject?
>
>Tnx in advance.
>--
>Massimiliano Masserelli
There is no standard for the behavior of the motherboard bios when the
first device 0x80 is not available at boot time. Some motherboards will
automove 0x81 -> 0x80, some can do it as a bios change, some you're stuck.
Most scsii controllers will do this and a few IDE controllers will as
well.
Generally for best flexibility, use an independent lilo file for each hard
disk and set the boot disk pointer individually for each drive to 0x80 or
0x81 as needed for your environment rather than using the "raid" feature
of lilo.
See the Boot-Root-Raid-LILO howto for examples. This doc is a bit out of
date, but the examples and setups are all applicable for the 2.4 series
kernels.
Michael
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-30 1:26 (unknown) Michael Robinton
@ 2002-10-30 9:59 ` Massimiliano Masserelli
0 siblings, 0 replies; 669+ messages in thread
From: Massimiliano Masserelli @ 2002-10-30 9:59 UTC (permalink / raw)
To: linux-raid
On Tue, Oct 29, 2002 at 05:26:23PM -0800, Michael Robinton wrote:
> There is no standard for the behavior of the motherboard bios when the
> first device 0x80 is not available at boot time. Some motherboards
> will automove 0x81 -> 0x80, some can do it as a bios change, some
> you're stuck.
Yes, I know. Anyway the problem doesn't seem connected with LILO, since
the kernel uncompresses smoothly, loads up the initrd image and THEN
hangs. The point is that the raidstart seems unable to initialize the
array if the /dev/hda disk is not present, and I can't understand why.
Is there some sort of priority between disks in a RAID-1 array?
Bye.
--
Massimiliano Masserelli
-------------------------------------------------------------------------------
He who hesitates is sometimes saved.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-26 19:48 Zajerko-McKee, Nick
2002-10-26 20:08 ` your mail Daniel Jacobowitz
2002-10-26 20:32 ` Greg Lindahl
0 siblings, 2 replies; 669+ messages in thread
From: Zajerko-McKee, Nick @ 2002-10-26 19:48 UTC (permalink / raw)
To: 'linux-mips@linux-mips.org'
Hi,
I'm porting some code from x86 to mips(32) and noticed that in
include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
order of elements of the sigchld structure. Was this an oversight or a
design decision? I would think that it would be desirable to be almost the
same as the x86 for userland ease of portability...
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-26 19:48 Zajerko-McKee, Nick
@ 2002-10-26 20:08 ` Daniel Jacobowitz
2002-10-26 20:32 ` Greg Lindahl
1 sibling, 0 replies; 669+ messages in thread
From: Daniel Jacobowitz @ 2002-10-26 20:08 UTC (permalink / raw)
To: Zajerko-McKee, Nick; +Cc: 'linux-mips@linux-mips.org'
On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:
> Hi,
>
> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure. Was this an oversight or a
> design decision? I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...
It's probably for compatibility with that other MIPS operating system -
IRIX.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-26 19:48 Zajerko-McKee, Nick
2002-10-26 20:08 ` your mail Daniel Jacobowitz
@ 2002-10-26 20:32 ` Greg Lindahl
1 sibling, 0 replies; 669+ messages in thread
From: Greg Lindahl @ 2002-10-26 20:32 UTC (permalink / raw)
To: 'linux-mips@linux-mips.org'
On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:
> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure. Was this an oversight or a
> design decision? I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...
User programs normally get recompiled, so anything using the proper
includes IS portable.
The issue only appears if you are using binary translation of x86
programs on mips. For example, this is one:
http://www.transitives.com/products.htm
For this, you need to write a system call translation layer which
rearranges things appropriately. An existing example is the o32 layer
in mips64, and soon the n32 layer in mips64.
-- greg
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-17 7:41 Rusty Russell
2002-10-17 14:56 ` your mail Kai Germaschewski
0 siblings, 1 reply; 669+ messages in thread
From: Rusty Russell @ 2002-10-17 7:41 UTC (permalink / raw)
To: Daniel Phillips, S; +Cc: Roman Zippel, linux-kernel
In message <E181zuY-0004Fl-00@starship> you write:
> On Thursday 17 October 2002 00:48, Rusty Russell wrote:
> > > On Wednesday 16 October 2002 08:11, Rusty Russell wrote:
> > > > It needs to be turned off when dealing with any interface which might
> > > > be used by one of the hard modules. Which is pretty bad.
> > >
> > > As far as I can see, preemption only has to be disabled during the
> > > synchronize_kernel phase of unloading that one module, and this requireme
nt
> > > is inherited neither by dependant or depending modules.
> >
> > No, someone could already have been preempted before you start
> > synchronize_kernel().
>
> I don't get that. The sequence is:
>
> - turn off preemption
> - unhook call points
> - synchronize_kernel
> - ...
>
> which doesn't leave any preemption hole that I can see, so I can't comment
> on a couple of the other points until you clear that one up.
You mean that "turn off preemption" also wakes up anyone currently
preempted? Otherwise they're preempted just inside one of those call
points.
> > Still a race between the zero check and the can't-increment state
> > setting.
>
> But that one is easy: the zero check just takes the same spinlock as
> TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count
> is zero, considerably simpler than:
The current spinlock is horrible. You could use a brlock, of course,
but I didn't mainly because of code bloat and speed. My current code
looks like:
static inline int try_module_get(struct module *module)
{
int ret = 1;
if (module) {
unsigned int cpu = get_cpu();
if (likely(module->ref[cpu].live))
local_inc(&module->ref[cpu].counter);
else
ret = 0;
put_cpu();
}
return ret;
}
Which is small enough to be inlined quite nicely, and very fast.
Adding br_read_lock_irqsave() starts to get big and slow (at that
point it's more likely we want to move the module case out of line).
> > This is what my current code does: rmmod itself checks (if
> > /proc/modules available), then the kernel sets the module to
> > can't-increment, then checks again. If the non-blocking flag is set,
> > it then re-animates the module and fails, otherwise it waits.
>
> and leaves no window for spurious failure. The still-initializing case is
> also easy, e.g., a filesystem module simply doesn't call register_filesystem
> until it's completely ready to service calls, so nobody is able to do
> TRY_INC_MOD_COUNT.
Consider some code which needs to know when cpus go up and down, so
registers a notifier. If the notifier fires before the init is
finished, the notifier code will fail to "try_inc_mod_count()" and
won't call it (it doesn't do try_inc_mod_count at the moment, but
that's a bug).
I don't know of any code which does this now, but it is at least a
theoretical problem.
> > BTW, current patchset (2.5.43):
>
> Thanks, I'll read them all on the 21st ;-) The other thing I need to read
> closely is Roman's strategy for changing the module format, and the weird
> linker connections.
Roman dislikes linking in the kernel. So did I until I wrote it: it's
really trivial (esp. compared with the code to coordinate with the
userspace linker properly). And it exists today. The linking takes
around 200 lines. But, let's say his solution is 500 lines shorter
than mine.
For those five hundred lines, the new parameter infrastructure and
module versioning changes can be done *without* requiring any changes
in modutils. If you've been following the module changes closely in
the last couple of years, you'll realize what a pain it has been to
introduce changes like licensing, etc. This frees up our hand.
IMHO, the benifits of having it in-kernel outweigh the slight extra
size.
> > ...The second is the "die-mother-fucker-die"
> > version, which taints the kernel and just removes the damn thing. For
> > most people, this is better than a reboot, and will usually "work".
>
> Is there a case where removing a module would actually help? What is
> the user going to do next, try to reinsert the same module?
Insert a fixed one, hopefully 8). I was thinking for kernel
developers, and general robustness (eg. an oops inside a module leaves
its refcount at 1).
> > http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/force-un
load.patch.gz
>
> ERROR 404: Not Found.
Damn my fingers. Updated (now applies on top of the others) but I
haven't tested this version yet (that's what I'm doing now):
http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/forceunload.patch.gz
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-10-17 7:41 Rusty Russell
@ 2002-10-17 14:56 ` Kai Germaschewski
2002-10-18 2:47 ` Rusty Russell
0 siblings, 1 reply; 669+ messages in thread
From: Kai Germaschewski @ 2002-10-17 14:56 UTC (permalink / raw)
To: Rusty Russell; +Cc: Daniel Phillips, S, Roman Zippel, linux-kernel
On Thu, 17 Oct 2002, Rusty Russell wrote:
> > But that one is easy: the zero check just takes the same spinlock as
> > TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count
> > is zero, considerably simpler than:
>
> The current spinlock is horrible. You could use a brlock, of course,
> but I didn't mainly because of code bloat and speed. My current code
> looks like:
>
> static inline int try_module_get(struct module *module)
> {
> int ret = 1;
>
> if (module) {
> unsigned int cpu = get_cpu();
> if (likely(module->ref[cpu].live))
> local_inc(&module->ref[cpu].counter);
> else
> ret = 0;
> put_cpu();
> }
> return ret;
> }
Since I made the mistake of getting involved into this discussion lately,
I wonder if this new method is going to be mandatory (the only one
available) or optional. I think there's two different kind of users, for
one modules which use an API which provides its own infrastructure for
dealing with modules via ->owner, on the other hand things like netfilter
(that's probably where you are coming from) where calls into a module,
which need protection are really frequent.
Note that for the vast majority of modules, dealing with unload races is
as simple as setting ->owner, for example filesystems, network drivers.
Sure, we need a global lock (unload_lock) when calling into these modules
initially, but these "binding/unbinding" calls are really rare. For
filesystems, they happen once per mount, for network drivers only for
ifconfig up/down. Afterwards, calling into the module (e.g. accessing the
mounted filesystem, xmitting/receiving data) doesn't have any overhead at
all compared to a linked-in filesystem/driver (well, ignore TLB misses)
I don't see a good reason to change this, in particular, since it provides
useful information to the user, that is the mod_use_count. It means "Is it
possible to successfully unload the module now?", and since looking at
the count and the actual unload is protected by unload_lock, the unload
will either succeed basically immediately, or fail with -EBUSY right away.
I see that your approach makes frequent calls into the module cheaper, but
I'm not totally convinced that the current safe interfaces need to change
just to accomodate rare cases like netfilter (there's most likely some
more cases like it, but the majority of modules is not).
Anyway, I may see further problems, but let me check first: Is your count
supposed to only count users which are currently executing in the module's
.text, or is it also to count references to data allocated in the module?
(I.e. when I register_netdev(), does that keep a reference to the module
even after the code has left the module's .text?)
--Kai
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-10-17 14:56 ` your mail Kai Germaschewski
@ 2002-10-18 2:47 ` Rusty Russell
2002-10-18 21:50 ` Kai Germaschewski
0 siblings, 1 reply; 669+ messages in thread
From: Rusty Russell @ 2002-10-18 2:47 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Daniel Phillips, S, Roman Zippel, linux-kernel
In message <Pine.LNX.4.44.0210170930410.6301-100000@chaos.physics.uiowa.edu> yo
u write:
> Since I made the mistake of getting involved into this discussion lately,
My condolences. 8)
> I wonder if this new method is going to be mandatory (the only one
> available) or optional. I think there's two different kind of users, for
> one modules which use an API which provides its own infrastructure for
> dealing with modules via ->owner, on the other hand things like netfilter
> (that's probably where you are coming from) where calls into a module,
> which need protection are really frequent.
Mandatory for interfaces where the function can sleep (or be preempted).
> Note that for the vast majority of modules, dealing with unload races is
> as simple as setting ->owner, for example filesystems, network drivers.
Yes. We do not have complete coverage though, this policy would
extend it.
> I see that your approach makes frequent calls into the module cheaper, but
> I'm not totally convinced that the current safe interfaces need to change
> just to accomodate rare cases like netfilter (there's most likely some
> more cases like it, but the majority of modules is not).
They're not changing. The current users doing try_inc_mod_count() are
fine. It's the ones not doing it which are problematic.
> Anyway, I may see further problems, but let me check first: Is your count
> supposed to only count users which are currently executing in the module's
> .text, or is it also to count references to data allocated in the module?
> (I.e. when I register_netdev(), does that keep a reference to the module
> even after the code has left the module's .text?)
It's to protect entry to the function, but of course, some interfaces
(eg. filesystems) lend themselves very neatly to batching this at
mount/unmount time. Data is already protected by the usual means.
At risk of boring you, here's the document from the documentation
patch. Suggestions welcome.
+Writing Modules and the Interfaces To Be Used By Them: A Gentle Guide.
+Copyright 2002, Rusty Russell IBM Corportation
+
+Modules are running parts of the kernel which can be added, and
+sometimes removed, while the kernel is operational.
+
+There are several delicate issues involved in this procedure which
+indicate special care should be taken.
+
+There are three cases you need to be careful:
+
+1) Any code which creates an interface for callbacks (ie. almost any
+ function called register_*)
+ => See Rule #1
+
+2) Any modules which use (old) interfaces which do not obey Rule #1
+ => See Rule #2
+
+Rule #1: Module-safe Interfaces. Any interface which allows
+ registration of callbacks, must also allow registration of a
+ "struct module *owner", either in the structure or as a
+ function parameter, and it must use them to protect the
+ callbacks. See "MAKING INTERFACES SAFE".
+
+Exception #1: As an optimization, you may skip this protection if you
+ *know* that the callbacks are non-preemtible and never
+ sleep (eg. registration of interrupt handlers).
+
+
+Rule #2: Modules using unsafe interfaces. If your module is using any
+ interface which does not obey rule number 1, that means your
+ module functions may be called from the rest of the kernel
+ without the caller first doing a successful try_module_get().
+
+ You must not register a "module_cleanup" handler, and your module
+ cannot be unloaded except by force. You must be especially
+ careful in this case with initialization: see "INITIALIZING
+ MODULES WHICH USE UNSAFE INTERFACES".
+
+MAKING INTERFACES SAFE
+
+A caller must always call "try_module_get()" on a function pointers's
+owner before calling through that function pointer. If
+"try_module_get()" returns 0 (false), the function pointer must *not*
+be called, and the caller should pretend that registration does not
+exist: this means the (module) owner is closing down and doesn't want
+any more calls, or in the process of starting up and isn't ready yet.
+
+For many interfaces, this can be optimized by assuming that a
+structure containing function pointers has the same owner, and knowing
+that one function is always called before the others, such as the
+filesystem code which knows a mount must succeed before any other
+methods can be accessed.
+
+You must call "module_put()" on the owner sometime after you have
+called the function(s).
+
+If you cannot make your interface module-safe in this way, you can at
+least split registration into a "reserve" stage and an "activate"
+stage, so that modules can use the interface, even if they cannot
+(easily) unload.
+
+
+INITIALIZING MODULES WHICH USE UNSAFE INTERFACES
+
+Safe interfaces will never enter your module before module_init() has
+successfully finished, but unsafe interfaces may. The rule is simple:
+your init_module() function *must* succeed (by returning 0) if it has
+successfully used any unsafe interfaces.
+
+So, if you are only using ONE unsafe interface, simply use that
+interface last. Otherwise you will have to use printk() to report
+failure and leave the module initialized (but possibly useless).
+
+
+
+If you have questions about how to apply this document to your own
+modules, please ask rusty@rustcorp.com.au or linux-kernel@vger.kernel.org.
+
+Thankyou,
+Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-18 2:47 ` Rusty Russell
@ 2002-10-18 21:50 ` Kai Germaschewski
0 siblings, 0 replies; 669+ messages in thread
From: Kai Germaschewski @ 2002-10-18 21:50 UTC (permalink / raw)
To: Rusty Russell; +Cc: Daniel Phillips, S, Roman Zippel, linux-kernel
On Fri, 18 Oct 2002, Rusty Russell wrote:
> > I wonder if this new method is going to be mandatory (the only one
> > available) or optional. I think there's two different kind of users, for
> > one modules which use an API which provides its own infrastructure for
> > dealing with modules via ->owner, on the other hand things like netfilter
> > (that's probably where you are coming from) where calls into a module,
> > which need protection are really frequent.
>
> Mandatory for interfaces where the function can sleep (or be preempted).
and is not protected by other means (try_inc_mod_count()), I presume.
> > I see that your approach makes frequent calls into the module cheaper, but
> > I'm not totally convinced that the current safe interfaces need to change
> > just to accomodate rare cases like netfilter (there's most likely some
> > more cases like it, but the majority of modules is not).
>
> They're not changing. The current users doing try_inc_mod_count() are
> fine. It's the ones not doing it which are problematic.
Alright, so I'm fine with it ;) (not that makes a difference, but...)
--Kai
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-14 6:28 Maros RAJNOCH /HiaeR Silvanna/
2002-10-14 12:28 ` your mail Dave Jones
0 siblings, 1 reply; 669+ messages in thread
From: Maros RAJNOCH /HiaeR Silvanna/ @ 2002-10-14 6:28 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5837 bytes --]
Unmounting file systems: Kernel BUG at page_alloc.c:90!
invalid operand: 0000
CPU: 0
EIP: 0010:[<co12d0ea>]
EFLAGS: 00010286
eax: 0000001f ebx: 00000000 ecx: 00000001 edx: c02575a4
esi: 00000000 edi: c1452c7c ebp: 00000000 esp: d1b51e8c
ds: 0018 es: 0018 ss: 0018
Process umount (pid:11412, stackpage=d1b51000)
Stack: c020ea7b c020ec89 0000005a c1452c7c c0135b93 c1452c7c 00000000 c1452c7c
c1452c7c c1452c7c c1452c7c 00000000 c0124d6c c1452c7c 00000000 c0113c31
d1b51ef8 c01356e1 d3895f60 d1b51ef0 d1244c28 00000000 00000000 c0124e1b
Call Trace: [<c020ea7b>] [<c020ec89>] [<c0135b93>] [<c0124d6c>] [<c0113c31>]
[<c01356e1>] [<c0124e1b>] [<c01471d7>] [<c01472f8>] [<c0138fa9>]
[<c01393b1>] [<c013949a>] [<c010901b>] [<c010002b>]
Code: 0f 0b 83 c4 0c 8b 47 18 83 e0 20 74 16 6a 5c 68 98 ec 20 c0
Linux version 2.4.2-2 (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001
BIOS-provided physical RAM map:
BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
BIOS-e820: 0000000000000400 @ 000000000009fc00 (reserved)
BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
BIOS-e820: 0000000013ef0000 @ 0000000000100000 (usable)
BIOS-e820: 000000000000d000 @ 0000000013ff3000 (ACPI data)
BIOS-e820: 0000000000003000 @ 0000000013ff0000 (ACPI NVS)
On node 0 totalpages: 81904
zone(0): 4096 pages.
zone DMA has max 32 cached pages.
zone(1): 77808 pages.
zone Normal has max 607 cached pages.
zone(2): 0 pages.
zone HighMem has max 1 cached pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=306 BOOT_FILE=/boot/vmlinuz-2.4.2-2 video=vesa:mtrr
Initializing CPU#0
Detected 374.843 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 748.74 BogoMIPS
Memory: 319732k/327616k available (1365k kernel code, 7496k reserved, 92k data, 236k init, 0k highmem)
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 0183f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb2b0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
PCI: Found IRQ 5 for device 00:07.2
PCI: The same IRQ used for device 00:09.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
Starting kswapd v1.8
vesafb: framebuffer at 0xe6000000, mapped to 0xd4800000, size 7936k
vesafb: mode is 1024x768x16, linelength=2048, pages=3
vesafb: protected mode interface info at c000:0444
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
pty: 256 Unix98 ptys configured
block: queued sectors max/low 211784kB/80712kB, 640 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
hda: WDC AC26400B, ATA DISK drive
hdc: CD-532E-B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 12594960 sectors (6449 MB) w/512KiB Cache, CHS=784/255/63, UDMA(33)
Partition check:
hda: hda1 hda2 hda4 < hda5 hda6 hda7 hda8 hda9 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Real Time Clock Driver v1.10d
md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md.c: sizeof(mdp_super_t) = 4096
autodetecting RAID arrays
autorun ...
... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 236k freed
Adding Swap: 104380k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.251 $ time 20:53:29 Apr 8 2001
usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 5 for device 00:07.2
PCI: The same IRQ used for device 00:09.0
usb-uhci.c: USB UHCI at I/O 0x9000, IRQ 5
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* (unknown)
@ 2002-10-09 16:31 Joshua Hudson
2002-10-09 18:04 ` your mail Konstantin Boldyshev
0 siblings, 1 reply; 669+ messages in thread
From: Joshua Hudson @ 2002-10-09 16:31 UTC (permalink / raw)
To: linux-assembly; +Cc: konst
When hunting down the last errors remaining in tar, I came across
a particularly weird one in both tar and chmod.
Try chmod 4755 true. True will have mode 755.
This happens in linux 2.0.63, 2.2.22, 2.4.18-3
Is anybody else getting this? Anybody have a solution?
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-09 16:31 (unknown) Joshua Hudson
@ 2002-10-09 18:04 ` Konstantin Boldyshev
0 siblings, 0 replies; 669+ messages in thread
From: Konstantin Boldyshev @ 2002-10-09 18:04 UTC (permalink / raw)
To: Joshua Hudson; +Cc: linux-assembly, konst
On Wed, 9 Oct 2002, Joshua Hudson wrote:
> When hunting down the last errors remaining in tar, I came across
> a particularly weird one in both tar and chmod.
>
> Try chmod 4755 true. True will have mode 755.
> This happens in linux 2.0.63, 2.2.22, 2.4.18-3
> Is anybody else getting this? Anybody have a solution?
It is chmod bug, it did 'mul bl' instead of mul bx.
CVS version has this bug fixed.
--
Regards,
Konstantin
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-02 19:58 Mark Peloquin
2002-10-02 20:19 ` your mail jbradford
0 siblings, 1 reply; 669+ messages in thread
From: Mark Peloquin @ 2002-10-02 19:58 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Wed, 2002-10-02 at 17:09, Alan Cox wrote:
> Look at history - if such a mess got in, it would never get sorted.
Instead of throwing around vague statements with little
context like "compost heap" and "such a mess", why don't
you spell out the specific design points of EVMS that you
disagree with. The advantages and disadvantages of
each point can then be discussed.
Mark
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-02 19:58 Mark Peloquin
@ 2002-10-02 20:19 ` jbradford
0 siblings, 0 replies; 669+ messages in thread
From: jbradford @ 2002-10-02 20:19 UTC (permalink / raw)
To: Mark Peloquin; +Cc: alan, linux-kernel
> On Wed, 2002-10-02 at 17:09, Alan Cox wrote:
> > Look at history - if such a mess got in, it would never get sorted.
>
> Instead of throwing around vague statements with little
> context like "compost heap" and "such a mess", why don't
> you spell out the specific design points of EVMS that you
> disagree with. The advantages and disadvantages of
> each point can then be discussed.
Yeah, but he is right in any case - look how the IDE mess of 2.5.x, which, frankly, I don't believe was ever as bad as people seem to be saying it was, has put people off testing 2.5.x. Instead they are waiting for Linus to type
mv linux-2.5.x linux-2.6.0
at which point they think that all remaining bugs will auto-magically correct themselves and the tree is one again safe to use. WRONG answer!
Simply from the point of view of not wanting to 'scare off' people from a whole tree, (which is so rediculous, I think I'll go and patent it), and as a result get less testing, we're better off trying to stop weirdness from getting in.
John.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-10-02 12:41 s.stoklossa
2002-10-02 12:51 ` your mail Sam Ravnborg
0 siblings, 1 reply; 669+ messages in thread
From: s.stoklossa @ 2002-10-02 12:41 UTC (permalink / raw)
To: mec; +Cc: linux-kernel
beim versuch, die Einstellungen von alsa aufzurufen, kam folgende FM:
Q> ./scripts/Menuconfig: MCmenu74: command not found
grusz
Sven
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-10-02 12:41 s.stoklossa
@ 2002-10-02 12:51 ` Sam Ravnborg
0 siblings, 0 replies; 669+ messages in thread
From: Sam Ravnborg @ 2002-10-02 12:51 UTC (permalink / raw)
To: s.stoklossa; +Cc: mec, linux-kernel
On Wed, Oct 02, 2002 at 02:41:42PM +0200, s.stoklossa@mentopolis.de wrote:
> beim versuch, die Einstellungen von alsa aufzurufen, kam folgende FM:
>
> Q> ./scripts/Menuconfig: MCmenu74: command not found
>
> grusz
>
> Sven
Known problem, try this patch:
copy-n-pated so may not apply cleanly, try by hand.
Ps. Please in english next time.
Sam
--- linux/sound/Config.in 2002-10-01 12:09:44.000000000 +0200
+++ linux/sound/Config.in 2002-10-01 12:21:05.000000000 +0200
@@ -31,10 +31,7 @@
if [ "$CONFIG_SND" != "n" -a "$CONFIG_ARM" = "y" ]; then
source sound/arm/Config.in
fi
-if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ]; then
- source sound/sparc/Config.in
-fi
-if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC64" = "y" ]; then
+if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ] || [ "$CONFIG_SND" !=
"n" -a "$CONFIG_SPARC64" = "y" ] ; then
source sound/sparc/Config.in
fi
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-09-21 5:32 Greg KH
2002-09-23 18:35 ` your mail Patrick Mochel
0 siblings, 1 reply; 669+ messages in thread
From: Greg KH @ 2002-09-21 5:32 UTC (permalink / raw)
To: Rhoads, Rob, linux-kernel, hardeneddrivers-discuss, cgl_discussion
cgl_discussion@lists.osdl.org, hardeneddrivers-discuss@lists.sourceforge.net
Cc:
Bcc:
Subject:
Reply-To:
hardeneddrivers-discuss@lists.sourceforge.net,
cgl_discussion@lists.osdl.org
Bcc:
Subject: my review of the Device Driver Hardening Design Spec
Reply-To:
In-Reply-To: <20020921014054.GA25665@kroah.com>
On Fri, Sep 20, 2002 at 06:40:54PM -0700, Greg KH wrote:
> Hi,
>
> I've just started to read over the published spec, and will reserve
> comment on it, and the example code you've created after I'm done
> reading it.
Ok, here's some comments on the 0.5h release of the Device Driver
Hardening Design Specification:
(I'll skip the intro, and feel good sections and get into the details
that you lay out, starting in section 2)
Section 2:
2.1:
- do NOT use /proc for driver info. Use driverfs.
- If you are using a kernel version that does not have driverfs,
put all /proc driver info under /proc/drivers, which is where
it belongs.
- Only have 1 value per file, and no binary data in the files.
- Do not put the "kernel version for which the driver was
compiled", as that _always_ much match the kernel version that
is running, so is redundant.
2.2:
- do NOT use typedef
2.5.5:
- you do not have to always check data returned from functions,
if you wrote the functions in the first place. Redundant
checking of all data within the kernel, slows things down.
Sure, some checking is good, but do not say that it is a
requirement, or no one will want to use your driver.
The majority of section 2 is very nice, it's a good list of things that
drivers should do.
Section 3:
Wow, where to start...
The Common Statistic Manager:
- why does this have to live in the kernel? It should be in
userspace, grabbing all of the data from the /proc files you
just specified in section 2.1.
POSIX event logging:
- wow, not much I can say here, that hasn't already been said
before :(
Diagnostics:
- now these are a good idea. A common subsystem that drivers
can register what kind of diagnostics they can run on their
hardware, nice.
3.1.1:
- UUIDs!!!??? You have got to be kidding. Here, for the
benefit of those who have not read this, I'll quote:
"Each subsystem, and each resource contained within each
subsystem, needs to be uniquely identified. In order to
do this a hardened driver developer shall pre-assign a
Universally Unique Identifier (UUID) as the Subsystem ID
for each subsystem, and shall provide a means to assign
a unique Resource ID string for each resource within a
subsystem."
So for every resource, a string shall be associated with it.
But that means for most resources, the string will take up more
memory than the resource itself does. Does that make sense?
It's also up to the driver to create these resource ids at
runtime and guarantee their uniqueness over the lifetime of the
kernel. How in the world can you expect every driver author to
do this? Any example code out there?
And what are these UUIDs going to be used for, ah, event
logging. Enough said.
3.2 Statistics:
You actually want every driver to support SNMP compliant
statistics groups within themselves? Why? What a bloat of a
kernel.
All of this should be done (if at all) from userspace.
3.2.5.2:
(I'm not condoning ANY of these functions or code, just trying to point out how
you should, if they were to be in the kernel, done properly.)
- do not use typedef
- struct stat_info does not need *unit, as that is already
specified in the scale field, right?
- the stat_value_t union is just a horrible abomination, don't
do that.
3.3 Diagnostics:
- not a bad idea, but some work could be done on the
implementation. Would fit in nicely with the device driver
model in 2.5. For 2.4, it would be another subsystem a driver
would register with.
3.3.3.2:
- no typedefs
- run() is horrible, you are trying to fit all kinds of possible
diagnosis into one function callback. Not a good idea.
Break the different kinds of callbacks out into different
functions. That ensures type safety, right now you are just
creating another ioctl() type mess.
3.4 Event logging:
- I'm not even going to touch this, sorry.
4: High Availability
- are you all working with the existing HA group?
4.1:
- um, what are you trying to say here. This section is
pointless. Yes we all think Hot Swap is a good idea, that's
why Linux currently supports it.
4.2:
- RAID and ethernet bonding is nice. Again, Linux already has
projects and support for these things. Why mention them?
The rest of this section is fine, and I welcome any test harnesses that
are created to do this kind of fault injection for driver testing.
5:
- Here you back-pedal on everything you said up till now. Let
me summarize what is said in these 3 paragraphs in 1 sentence:
"Yes, all these things are well and good, but don't let
them effect the currently great performance Linux has
today."
Sorry, but you can't have it both ways.
5.1:
- do NOT use #ifdef in the .c files. Only in .h files.
- why is CONFIG_DRIVER_HOTSWAP an option. What does it do that
CONFIG_HOTPLUG does not do today?
- actually, what do any of these CONFIG_ options do, and why
would someone not want the CONFIG_DRIVER_ROBUST to be always
enabled?
In summary, I think that a lot of people have spent a lot of time in
creating this document, and the surrounding code that matches this
document. I really wish that a tiny bit of that effort had gone into
contacting the Linux kernel development community, and asking to work
with them on a project like this. Due to that not happening, and by
looking at the resultant spec and code, I'm really afraid the majority
of that time and effort will have been wasted.
What do I think can be salvaged? Diagnostics are a good idea, and I
think they fit into the driver model in 2.5 pretty well. A lot of
kernel janitoring work could be done by the CG team to clean up, and
harden (by applying the things in section 2) the existing kernel
drivers. That effort alone would go a long way in helping the stability
of Linux, and also introduce the CG developers into the kernel community
as active, helping developers. It would allow the CG developers to
learn from the existing developers, as we must be doing something right
for Linux to be working as well as it does :)
Also, open specs for the hardware the CG members produce, to allow
existing kernel drivers to be enhanced (instead of having to be reverse
engineered), and new kernel drivers to be created, would also go a long
way in helping out both the CG's members and the entire Linux
community's cause of having a robust, stable kernel be achived easier.
Closed specs, and closed drivers do not help anyone.
thanks for reading this far,
greg k-h
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-09-21 5:32 Greg KH
@ 2002-09-23 18:35 ` Patrick Mochel
0 siblings, 0 replies; 669+ messages in thread
From: Patrick Mochel @ 2002-09-23 18:35 UTC (permalink / raw)
To: Rhoads, Rob
Cc: Greg KH, linux-kernel, hardeneddrivers-discuss, cgl_discussion
In general, I agree completely with what Greg says (as usual), but I do
have a few additional comments.
> (I'll skip the intro, and feel good sections and get into the details
> that you lay out, starting in section 2)
>
> Section 2:
> 2.1:
> - do NOT use /proc for driver info. Use driverfs.
> - If you are using a kernel version that does not have driverfs,
> put all /proc driver info under /proc/drivers, which is where
> it belongs.
Actually, they mention using driverfs in Section 3: Instrumentation. I
can't tell if this was around before, or this was just added. The date is
the same (16 Aug), but there is no changelog information about the spec.
I would suggest not using procfs at all, even if driverfs is not avaiable.
If you're using 2.4, backport driverfs, or clone it for your own
filesystem. It's not dependent on the driver model at all, and has been
done at least once before (Greg's pcihpfs).
> Section 3:
> The Common Statistic Manager:
Please drop the term 'Manager' from your nomenclature. It is ambiguous,
because of the context in which its generally used in. Windows uses the
term for any collection of kernel or device data and/or kernel policy.
It's not a bad term, but it fails to make a clear distinction between
kernel space and user space, which we insist on.
Only the mechanism for setting the policy should exist in the kernel, and
itself my be very intelligent. But, the policy itself should exist outside
of the kernel.
> 3.2.5.2:
> (I'm not condoning ANY of these functions or code, just trying to point out how
> you should, if they were to be in the kernel, done properly.)
> - do not use typedef
> - struct stat_info does not need *unit, as that is already
> specified in the scale field, right?
> - the stat_value_t union is just a horrible abomination, don't
> do that.
Please do not pass void *. You should only pass type-safe structures. If
you cannot get that information, you should redesign the API.
> 3.4 Event logging:
> - I'm not even going to touch this, sorry.
There are a lot of topics in this spec, most of which are irrelevant to
actually hardening drivers. They may be features dependent on your APIs,
but they are completely optional and may hinder acceptance of your primary
objectives.
Event logging is definitely one of them, esp. with a function like
evl_log_event_string(
ME_EVENT_BUCKET_EMPTY,
LOG_WARNING,
"Leaky bucket exception (bucket empty):\
Bucket_Level <= Observed_Value - Last_Value\
|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s\
|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|",
RMGT_FacilityIDAttrStr, RMUUID,
RMGT_SubsystemIDAttrStr, SUBSYSTEM_UUID,
RMGT_SubsystemNameAttrStr, subsystem_name,
RMGT_ResourceIDAttrStr, resource_id,
RMGT_ResourceNameAttrStr, resource_name,
ME_MonitorIDAttrStr, monitor_uuid,
ME_StatisticIDAttrStr, statistic_id,
ME_StatisticNameAttrStr, statistic_name,
ME_BucketSizeAttrStr, bucketsz,
ME_FillValueAttrStr, fillval,
ME_FillIntervalAttrStr, fillint,
ME_BucketLevelAttrStr, bucketlvl,
ME_ObservedValueAttrStr, obsval,
ME_LastValueAttrStr, lastval);
> In summary, I think that a lot of people have spent a lot of time in
> creating this document, and the surrounding code that matches this
> document. I really wish that a tiny bit of that effort had gone into
> contacting the Linux kernel development community, and asking to work
> with them on a project like this. Due to that not happening, and by
> looking at the resultant spec and code, I'm really afraid the majority
> of that time and effort will have been wasted.
I completely agree. There is definitely good intention in some aspects of
the spec, and definitely in the effort put forth to support this type of
work. But, in order to gain the support of kernel developers, or even the
blessing of a few, you should be working with them on the design from the
beginnging.
Designing APIs is hard. Doing it well is very hard. I'm not claiming I've
done a stellar job, but I have at least learned that. I've made a lot of
poor design decisions, many of which are also evident in your code
descriptions and examples. I can't tell you how many times I've rewritten
things over and over and over because someone hated them (usually Linus or
Greg).
There are people that are willing to help, as we are trying to do. But,
it's much easier if you do things gradually and get that help from the
beginning.
> What do I think can be salvaged? Diagnostics are a good idea, and I
> think they fit into the driver model in 2.5 pretty well. A lot of
> kernel janitoring work could be done by the CG team to clean up, and
> harden (by applying the things in section 2) the existing kernel
> drivers. That effort alone would go a long way in helping the stability
> of Linux, and also introduce the CG developers into the kernel community
> as active, helping developers. It would allow the CG developers to
> learn from the existing developers, as we must be doing something right
> for Linux to be working as well as it does :)
Which kernel are you targeting? I didn't see it in the spec, though I
could have easily missed it. CGL is based on 2.4, so I would assume that.
But, I would think the ideal choice would be to start in 2.5 and backport
it to 2.4.
If that's the case, how do you intend to work with the driver model?
There will be quite a bit of code and interface duplication between
your code and the driver model. I can see ways to support many of the
things you want in a relatively easy manner, and not punish the common
user or developer; but the margin is to small to write the answer... ;)
Also, there are many projects in areas similar to what your doing:
diganostics, HA, etc, etc. It would be nice to see some collaboration
between the developers of those projects instead of having many disparate
projects with similar goals.
-pat
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-09-14 12:39 Paolo Ciarrocchi
2002-09-14 17:05 ` your mail Rik van Riel
0 siblings, 1 reply; 669+ messages in thread
From: Paolo Ciarrocchi @ 2002-09-14 12:39 UTC (permalink / raw)
To: linux-kernel; +Cc: conman
[...]
>http://kernel.kolivas.net under the FAQ. A final >reminder note: it won't work on
>2.5.x
Con,
I think that only the _memload_ test is not
working with 2.5.*, am I wrong?
Paolo
--
Get your free email from www.linuxmail.org
Powered by Outblaze
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-09-14 12:39 Paolo Ciarrocchi
@ 2002-09-14 17:05 ` Rik van Riel
0 siblings, 0 replies; 669+ messages in thread
From: Rik van Riel @ 2002-09-14 17:05 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: linux-kernel, conman
On Sat, 14 Sep 2002, Paolo Ciarrocchi wrote:
> I think that only the _memload_ test is not
> working with 2.5.*, am I wrong?
You're right, the memload test doesn't work with 2.5 but
needs the following patch...
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: september@surriel.com trac@trac.org
--- contest-0.1/mem_load.c.orig 2002-09-13 23:36:47.000000000 -0400
+++ contest-0.1/mem_load.c 2002-09-14 11:10:07.000000000 -0400
@@ -47,24 +47,25 @@
switch (type) {
case 0: /* RAM */
- if ((position = strstr(buffer, "Mem:")) == (char *) NULL) {
- fprintf (stderr, "Can't parse \"Mem:\" in /proc/meminfo\n");
+ if ((position = strstr(buffer, "MemTotal:")) == (char *) NULL) {
+ fprintf (stderr, "Can't parse \"MemTotal:\" in /proc/meminfo\n");
exit (-1);
}
- sscanf (position, "Mem: %ul", &size);
+ sscanf (position, "MemTotal: %ul", &size);
break;
case 1:
- if ((position = strstr(buffer, "Swap:")) == (char *) NULL) {
- fprintf (stderr, "Can't parse \"Swap:\" in /proc/meminfo\n");
+ if ((position = strstr(buffer, "SwapTotal:")) == (char *) NULL) {
+ fprintf (stderr, "Can't parse \"SwapTotal:\" in /proc/meminfo\n");
exit (-1);
}
- sscanf (position, "Swap: %ul", &size);
+ sscanf (position, "SwapTotal: %ul", &size);
break;
}
- return (size / MB);
+ /* convert from kB to MB */
+ return (size / KB);
}
--- contest-0.1/mem_load.h.orig 2002-09-14 11:09:28.000000000 -0400
+++ contest-0.1/mem_load.h 2002-09-14 11:09:42.000000000 -0400
@@ -24,6 +24,7 @@
#define MAX_BUF_SIZE 1024 /* size of /proc/meminfo in bytes */
#define MB (1024 * 1024) /* 2^20 bytes */
+#define KB 1024
#define MAX_MEM_IN_MB (1024 * 64) /* 64 GB */
/* Tuning parameter. Increase if you are getting an 'unreasonable' load
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <200208312335.g7VNZmk37659@sullivan.realtime.net>]
* Re: your mail
[not found] <200208312335.g7VNZmk37659@sullivan.realtime.net>
@ 2002-09-01 9:53 ` Krzysiek Taraszka
0 siblings, 0 replies; 669+ messages in thread
From: Krzysiek Taraszka @ 2002-09-01 9:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
On Sat, 31 Aug 2002, Milton Miller wrote:
> At Fri Aug 30 2002 - 12:54:37 EST Krzysiek Taraszka (dzimi@pld.org.pl) wrote:
> > Great work, but in 2.2.22rc2 powerpc's still broken.
> > First of All Sources have got a lot of unsed stuff.
> > For example look like that:
> >
> > [dzimi@cyborg linux]$ rgrep -n -R '*.*' 'CONFIG_PPC64' .
> ...
>
> Doesn't sound like -rc (release canidate) changes.
Well yes, in 2.2.10 someone tried to add CONFIG_PPC64 support in to 2.2
kernel.
In 2.2.11 someone add CONFIG_PPC64 in to Config.in! but on 2.2.12 or
2.2.13 someone remove it ...
(without remove it from directory != arch/ppc/kernel/ )
> > Second kernel-2.2.21 still have got time init problems in symbios driver
> > on powerpc platform.
> > I send to you my ugly hack witch work, but IMHO he's ugly ;) I need to do
> > it correct.
>
> > Third, kernel for powerpc boot and work on g3-266 but on g3-333 Ops ...
> > (kernel traps, kernel wrote: Caused by SRR1 or somethink like that, in 2.3
> > i saw #define FIX_SRR1 macro ...)
>
> Well, SRR1 doesn't cause traps, but it does help tell you why they occurred.
> And the FIX_SRR1 stuff isn't the solution either if you look at it closer.
> How about a decoded oops? Also, you didn't say what platform you were using.
I used g3 (pmac). My based system was PLD with 2.4.18 tree.
I used gcc-2.95.4 to build 2.2.21 vmlinux.
> As far as the open-pic changes you posted, how about explaining what your
> trying to fix (partly hidden by the rename and move to chrp_setup.c from
> open_pic.c)?
I tried to fix problem witch is on my IBM RS/6000 (model b50).
Openpic can't initialize propertly my scsi system. (sym82c8xx scsi
driver). Some time init problems.
Oh I forgot, 2.2.22rc1/2 or kernel >= 2.2.16 (2.2 tree) didn't work on my
IBM RS/6000 (b50).
Build with egcs work, but work slow (Bogomips: 16MHz!) and won't reboot
and shutdown -h now.
The same code build with gcc Ops (Kernel Exception, look like openpic
allocation address.)
I'll post the Ops later.
> I see you are wrapping the 8259 checks, but it also refers to a few new
> functions/macros I didn't see defined.
Hmm, yes, that why my patch is ugly. I want to do this correctly.
> How about discussing these problems and patches over at
> linuxppc-dev@lists.linuxppc.org ? (I set the reply-to there).
Ok, but first of all i should subscribe there.
Krzysiek Taraszka (dzimi@pld.org.pl)
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-08-30 18:43 Bloch, Jack
2002-08-30 18:55 ` your mail Matthew Dharm
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Bloch, Jack @ 2002-08-30 18:43 UTC (permalink / raw)
To: linux-kernel
I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
compact flash disk (emulates an IDE interface). I am using an EXT2
filesystem. During some power-off/power-on testing, the disk check failed.
It dropped me to a shell and I had to run e2fsck -cfv to correct this
problem. This is all good and well in a lab environment, but in reality,
there is nobody there to perform the repair (running system is not equipped
with keyboard and monitor). Is there any way to invoke e2fsck automatically
or inhibit the failure detection mechanism? Please CC me directly on any
responses.
Thanks in advance....
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-08-30 18:43 Bloch, Jack
@ 2002-08-30 18:55 ` Matthew Dharm
2002-08-30 19:22 ` Andreas Dilger
2002-08-31 0:12 ` David Woodhouse
2 siblings, 0 replies; 669+ messages in thread
From: Matthew Dharm @ 2002-08-30 18:55 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]
I would simply recommend switching to ext3, where these types of errors
generally don't occur.
Oh, and if you just edit your initscripts, you can do anything you want.
Matt
On Fri, Aug 30, 2002 at 02:43:52PM -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.
>
>
> Thanks in advance....
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
My mother not mind to die for stoppink Windows NT! She is rememberink
Stalin!
-- Pitr
User Friendly, 9/6/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-08-30 18:43 Bloch, Jack
2002-08-30 18:55 ` your mail Matthew Dharm
@ 2002-08-30 19:22 ` Andreas Dilger
2002-08-31 0:12 ` David Woodhouse
2 siblings, 0 replies; 669+ messages in thread
From: Andreas Dilger @ 2002-08-30 19:22 UTC (permalink / raw)
To: Bloch, Jack; +Cc: linux-kernel
On Aug 30, 2002 14:43 -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.
I would instead suggest using a filesystem like JFFS2 for flash devices.
This is journaled like ext3, but it also has the benefit of doing wear
levelling on the device, which otherwise will probably wear out the
superblock part of the flash rather quickly.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-08-30 18:43 Bloch, Jack
2002-08-30 18:55 ` your mail Matthew Dharm
2002-08-30 19:22 ` Andreas Dilger
@ 2002-08-31 0:12 ` David Woodhouse
2 siblings, 0 replies; 669+ messages in thread
From: David Woodhouse @ 2002-08-31 0:12 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Bloch, Jack, linux-kernel
adilger@clusterfs.com said:
> I would instead suggest using a filesystem like JFFS2 for flash
> devices. This is journaled like ext3, but it also has the benefit of
> doing wear levelling on the device, which otherwise will probably wear
> out the superblock part of the flash rather quickly.
He said he's using CompactFlash. CompactFlash is not flash, as far as we're
concerned: it is an IDE drive. You may think it has flash inside it; we
couldn't possibly comment.
In fact, it generally has a kind of pseudo-filesystem internally which it
uses to emulate a block device with 512-byte sectors. It may do its own
wear-levelling; the manufacturers are often quite cagey about whether it
actually does or not. Draw your own conclusions about that if you will.
It's quite common to find that this internal pseudo-filesystem _itself_ gets
screwed on power failures. This tends to manifest itself as unrecoverable
I/O errors.
There is no fundamental reason why every CF card should have these
problems, in the same way as there is no fundamental reason why all PC
BIOSes should be crap. But the same expectations apply.
If you want to pass power-fail testing, I would recommend you switch to
using real flash. JFFS2 on real flash has survived days of stress testing
whilst being power cycled randomly every ~5 minutes. The same tests were
observed to destroy CF cards¹.
CF is bog-roll technology. It's disposable storage designed for temporary
use in stuff like cameras -- not for real computing. Think of it like a
floppy disc and you won't go far wrong.
--
dwmw2
¹ http://www.embeddedlinuxworks.com/articles/jffs_guide.html²
² Constant reboots no longer screw the wear levelling, as reported there.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-08-27 18:22 Steffen Persvold
2002-08-27 19:27 ` your mail Willy Tarreau
0 siblings, 1 reply; 669+ messages in thread
From: Steffen Persvold @ 2002-08-27 18:22 UTC (permalink / raw)
To: linux-kernel
Dear list people,
Lately I've been testing out a couple of Dell PowerEdge 2650 machines.
These babies have dual onboard BCM95701A10 NICs (Tigon3 chip) mounted
in the same PCI-X 133MHz 64 bit bus.
Since they have dual onboard GbE, I've been trying to channel bond them
using just two crossover cables between two machines. The results I'm
seeing is at the first glance very strange. What I see is that the
performance when bonded (round robin) is about _half_ (and sometimes even
less) compared to just using a single interface. Here are some netpipe-2.4
results :
64k message size, single interface
1: 65536 bytes 190 times --> 760.54 Mbps in 0.000657 sec
256k message size, single interface
1: 262144 bytes 53 times --> 855.04 Mbps in 0.002339 sec
64 message size, both interfaces (using round robin)
1: 65536 bytes 65 times --> 257.06 Mbps in 0.001945 sec
256k message size, both interfaces (using round robin)
1: 262144 bytes 25 times --> 376.01 Mbps in 0.005319 sec
Looking at the output of netstat -s after a testrun with 256k message
size, I see some differences (main items) :
Single interface :
Tcp:
0 segments retransmited
TcpExt:
109616 packets directly queued to recvmsg prequeue.
52249581 packets directly received from backlog
125694404 packets directly received from prequeue
78 packets header predicted
124999 packets header predicted and directly queued to user
TCPPureAcks: 93
TCPHPAcks: 22981
Bonded interfaces :
Tcp:
234 segments retransmited
TcpExt:
1 delayed acks sent
Quick ack mode was activated 234 times
67087 packets directly queued to recvmsg prequeue.
6058227 packets directly received from backlog
13276665 packets directly received from prequeue
6232 packets header predicted
4625 packets header predicted and directly queued to user
TCPPureAcks: 25708
TCPHPAcks: 4456
The biggest difference as far as I can see is the 'packtes header
predicted', 'packets header predicted and directly queued to user',
'TCPPureAcks' and TCPHPAcks.
I have an idea that this happens because the packets are comming out of
order into the receiving node (i.e the bonding device is alternating
between each interface when sending, and when the receiving node gets the
packets it is possible that the first interface get packets number 0, 2,
4 and 6 in one interrupt and queues it to the network stack before packet
1, 3, 5 is handled on the other interface).
If this is the case, any ideas how to fix this...
I would really love to get 2Gbit/sec on these machines....
PS
I've also seen this feature on the Intel GbE cards (e1000), but these
drivers has a parameter named RxIntDelay which can be set to 0 to get
interrupt for each packet. Is this possible with the tg3 driver too ?
DS
Regards,
--
Steffen Persvold | Scali AS
mailto:sp@scali.com | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-08-27 18:22 Steffen Persvold
@ 2002-08-27 19:27 ` Willy Tarreau
0 siblings, 0 replies; 669+ messages in thread
From: Willy Tarreau @ 2002-08-27 19:27 UTC (permalink / raw)
To: Steffen Persvold; +Cc: linux-kernel
On Tue, Aug 27, 2002 at 08:22:03PM +0200, Steffen Persvold wrote:
> I have an idea that this happens because the packets are comming out of
> order into the receiving node (i.e the bonding device is alternating
> between each interface when sending, and when the receiving node gets the
> packets it is possible that the first interface get packets number 0, 2,
> 4 and 6 in one interrupt and queues it to the network stack before packet
> 1, 3, 5 is handled on the other interface).
You pointed your finger on this exact common problem.
You can use the XOR bonding mode (modprobe bonding mode=2), which uses a
hash of mac addresses to select the outgoing interface. This is interesting
if you have lots of L2 hosts on the same network switch.
Or if you have a few hosts on the same switch, you'd better use the "nexthop"
parameter of "ip route". IIRC, it should be something like :
ip route add <destination> nexthop dev eth0 nexthop dev eth1
but read the help, I'm not certain.
Cheers,
Willy
^ permalink raw reply [flat|nested] 669+ messages in thread
* RE: your mail
@ 2002-08-27 16:55 Alex Pavloff
0 siblings, 0 replies; 669+ messages in thread
From: Alex Pavloff @ 2002-08-27 16:55 UTC (permalink / raw)
To: 'Gerald Emig'; +Cc: 'linux-serial@vger.kernel.org'
Hi Gerald, here's some more info:
Sending data isn't the problem. The problem is acting as a slave and
receiving unsolicited packets from a master. I need to determine when a
packet is complete. If I was sending the packets (which I have done before
and am doing now), I can cheat a bit because I know the length of the packet
I'm "supposed" to be getting back. I can't do that when acting as a slave.
This is different that the other protocol I'm familiar with.
GE's SNP uses two packets -- the first fixed size and containing the length
of the second size.
AB's DF1 has a fixed packet structure with many special characaters that
makes it easy to pull in a piece at a time
With Modbus RTU I neither know how long a packet is going to be, nor do I
have a sequence of bytes that can be used to judge the end of a packet. I
need to be able to understand that 3.5 characters times of nothing means the
end of the packet.
Do I need a line discipline for this one portion of the driver?
Alex Pavloff
Software Engineer
Eason Technology
-----Original Message-----
From: Gerald Emig [mailto:gme@emig-software.de]
Sent: Tuesday, August 27, 2002 3:00 AM
To: Alex Pavloff
Cc: 'linux-serial@vger.kernel.org'
Subject: Re: your mail
To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.
On Mon, 26 Aug 2002, Alex Pavloff wrote:
>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19. While seeminly simple to
do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation.
First
> used by the Modicon PLCs, it's found on a variety of devices from a
variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library",
and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5
character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in
the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed
device.
>
> Following the last transmitted character, a similar interval of at least
3.5
> character times marks the end of the message. A new message can begin
after
> this interval.
>
> The entire message frame must be transmitted as a continuous stream. If a
> silent interval of more than 1.5 character times occurs before completion
of
> the frame, the receiving device flushes the incomplete message and assumes
> that the next byte will be the address field of a new message.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off
with
> termios. To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>
Gerald Emig
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown)
@ 2002-08-27 1:48 Alex Pavloff
2002-08-27 9:59 ` your mail Gerald Emig
0 siblings, 1 reply; 669+ messages in thread
From: Alex Pavloff @ 2002-08-27 1:48 UTC (permalink / raw)
To: 'linux-serial@vger.kernel.org'
Good (morning/afternoon/evening) folks,
I am writing Modbus RTU code for Linux 2.4.19. While seeminly simple to do
in userspace, there's one big kicker that I can't handle there easily.
Modbus RTU is a binary serial protocol used in industrial automation. First
used by the Modicon PLCs, it's found on a variety of devices from a variety
of manufacturers.
The specification is at www.modbus.org, under "Modbus Standard Library", and
its the Modbus Serial Protocol Reference Guide.
Here's the part that I don't think I can resolve in userspace:
-----
RTU Framing
In RTU mode, messages start with a silent interval of at least 3.5 character
times. This is most easily implemented as a multiple of character times at
the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the
figure below). The first field then transmitted is the device address.
The allowable characters transmitted for all fields are hexadecimal 0-9,
A-F. Networked devices monitor the network bus continuously, including
during the 'silent' intervals. When the first field (the address field) is
received, each device decodes it to find out if it is the addressed device.
Following the last transmitted character, a similar interval of at least 3.5
character times marks the end of the message. A new message can begin after
this interval.
The entire message frame must be transmitted as a continuous stream. If a
silent interval of more than 1.5 character times occurs before completion of
the frame, the receiving device flushes the incomplete message and assumes
that the next byte will be the address field of a new message.
-----
3.5 character times at high baud rates is not something I can pull off with
termios. To get the Modbus RTU frames without resorting to some really
strange code in userspace, should I write a line-discipline module whose
sole purpose is to deal with the character timing?
Any comments (yay/nay/huh?) appreciated.
Alex Pavloff
Software Engineer
Eason Technology
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-08-27 1:48 (unknown) Alex Pavloff
@ 2002-08-27 9:59 ` Gerald Emig
0 siblings, 0 replies; 669+ messages in thread
From: Gerald Emig @ 2002-08-27 9:59 UTC (permalink / raw)
To: Alex Pavloff; +Cc: 'linux-serial@vger.kernel.org'
To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.
On Mon, 26 Aug 2002, Alex Pavloff wrote:
>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19. While seeminly simple to do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation. First
> used by the Modicon PLCs, it's found on a variety of devices from a variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library", and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5 character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed device.
>
> Following the last transmitted character, a similar interval of at least 3.5
> character times marks the end of the message. A new message can begin after
> this interval.
>
> The entire message frame must be transmitted as a continuous stream. If a
> silent interval of more than 1.5 character times occurs before completion of
> the frame, the receiving device flushes the incomplete message and assumes
> that the next byte will be the address field of a new message.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off with
> termios. To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>
Gerald Emig
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-08-23 14:45 Mike Dresser
2002-08-23 15:12 ` your mail Bill Unruh
0 siblings, 1 reply; 669+ messages in thread
From: Mike Dresser @ 2002-08-23 14:45 UTC (permalink / raw)
To: linux-ppp; +Cc: linux-kernel
I'm having problems with pppd under 2.4.19, with pppd 2.4.1
I can establish a new connection, and no problems. But once the ISP on
the other end hangs up, this is what i get in my syslog.
Repeats over and over. I saw a few google postings about this, but those
were back in _1999_, so I would think they were fixed by now.
Doesn't matter if PPP is compiled in with the kernel, or modules.
I'm running Debian 3.0(woody)
This worked under Debian 2.2 and kernel 2.2.21
Aug 23 10:25:55 tilburybackup chat[9825]: abort on (BUSY)
Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO CARRIER)
Aug 23 10:25:55 tilburybackup chat[9825]: abort on (VOICE)
Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIALTONE)
Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIAL TONE)
Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO ANSWER)
Aug 23 10:25:55 tilburybackup chat[9825]: send (ATZ^M)
Aug 23 10:25:55 tilburybackup chat[9825]: expect (OK)
Aug 23 10:25:55 tilburybackup chat[9825]: ATZ^M^M
Aug 23 10:25:55 tilburybackup chat[9825]: OK
Aug 23 10:25:55 tilburybackup chat[9825]: -- got it
Aug 23 10:25:55 tilburybackup chat[9825]: send (ATDT3806600^M)
Aug 23 10:25:55 tilburybackup chat[9825]: expect (CONNECT)
Aug 23 10:25:55 tilburybackup chat[9825]: ^M
Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoReq id=0x4 magic=0x96835d5b]
Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoRep id=0x4 magic=0x72c56787]
Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoReq id=0x4 magic=0x72c56787]
Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoRep id=0x4 magic=0x96835d5b]
Aug 23 10:26:16 tilburybackup chat[9825]: ATDT3806600^M^M
Aug 23 10:26:16 tilburybackup chat[9825]: CONNECT
Aug 23 10:26:16 tilburybackup chat[9825]: -- got it
Aug 23 10:26:16 tilburybackup chat[9825]: send (\d)
Aug 23 10:26:17 tilburybackup pppd[329]: Serial connection established.
Aug 23 10:26:17 tilburybackup pppd[329]: using channel 1179
Aug 23 10:26:17 tilburybackup pppd[329]: Couldn't create new ppp unit: Inappropriate ioctl for device
Aug 23 10:26:18 tilburybackup pppd[329]: Hangup (SIGHUP)
tilburybackup:/etc/ppp# egrep -v '#|^ *$' /etc/ppp/options
asyncmap 0
auth
crtscts
lock
hide-password
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx
persist
maxfail 0
ttyS04 at port 0xcc00 (irq = 5) is a 16550A
00:0b.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01) (prog-if 02 [16550])
Subsystem: US Robotics/3Com USR 56k Internal FAX Modem (Model 2977)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at cc00 [size=8]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Any ideas?
Mike
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-08-23 14:45 Mike Dresser
@ 2002-08-23 15:12 ` Bill Unruh
2002-08-23 15:26 ` Mike Dresser
0 siblings, 1 reply; 669+ messages in thread
From: Bill Unruh @ 2002-08-23 15:12 UTC (permalink / raw)
To: Mike Dresser; +Cc: linux-ppp, linux-kernel
Well, it would be good if you actually told us what problem you were
describing. Is this a new connection attempt after the first hang up?
What?
What repeats over and over-- I see no repeat.
You also do not tell us info like what kind of modem is this-- external,
internal, serial, usb, pci, winmodem,....
I assume what you are refering to is the "inappropriate ioctl" line.
This indicates a hardware problem.
Actually, it looks to me like another pppd is up on the line. Those
EchoReq are another pppd receiving stuff on an open pppd on another
line. More information on what it is you are trying to do, on what your
system is, and what the problem is might get you help.
On Fri, 23 Aug 2002, Mike Dresser wrote:
> I'm having problems with pppd under 2.4.19, with pppd 2.4.1
>
> I can establish a new connection, and no problems. But once the ISP on
> the other end hangs up, this is what i get in my syslog.
> Repeats over and over. I saw a few google postings about this, but those
> were back in _1999_, so I would think they were fixed by now.
>
> Doesn't matter if PPP is compiled in with the kernel, or modules.
>
> I'm running Debian 3.0(woody)
>
> This worked under Debian 2.2 and kernel 2.2.21
>
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (BUSY)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO CARRIER)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (VOICE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIALTONE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIAL TONE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO ANSWER)
> Aug 23 10:25:55 tilburybackup chat[9825]: send (ATZ^M)
> Aug 23 10:25:55 tilburybackup chat[9825]: expect (OK)
> Aug 23 10:25:55 tilburybackup chat[9825]: ATZ^M^M
> Aug 23 10:25:55 tilburybackup chat[9825]: OK
> Aug 23 10:25:55 tilburybackup chat[9825]: -- got it
> Aug 23 10:25:55 tilburybackup chat[9825]: send (ATDT3806600^M)
> Aug 23 10:25:55 tilburybackup chat[9825]: expect (CONNECT)
> Aug 23 10:25:55 tilburybackup chat[9825]: ^M
> Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoReq id=0x4 magic=0x96835d5b]
> Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoRep id=0x4 magic=0x72c56787]
> Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoReq id=0x4 magic=0x72c56787]
> Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoRep id=0x4 magic=0x96835d5b]
> Aug 23 10:26:16 tilburybackup chat[9825]: ATDT3806600^M^M
> Aug 23 10:26:16 tilburybackup chat[9825]: CONNECT
> Aug 23 10:26:16 tilburybackup chat[9825]: -- got it
> Aug 23 10:26:16 tilburybackup chat[9825]: send (\d)
> Aug 23 10:26:17 tilburybackup pppd[329]: Serial connection established.
> Aug 23 10:26:17 tilburybackup pppd[329]: using channel 1179
> Aug 23 10:26:17 tilburybackup pppd[329]: Couldn't create new ppp unit: Inappropriate ioctl for device
> Aug 23 10:26:18 tilburybackup pppd[329]: Hangup (SIGHUP)
>
> tilburybackup:/etc/ppp# egrep -v '#|^ *$' /etc/ppp/options
> asyncmap 0
> auth
> crtscts
> lock
> hide-password
> modem
> proxyarp
> lcp-echo-interval 30
> lcp-echo-failure 4
> noipx
> persist
> maxfail 0
>
> ttyS04 at port 0xcc00 (irq = 5) is a 16550A
>
> 00:0b.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01) (prog-if 02 [16550])
> Subsystem: US Robotics/3Com USR 56k Internal FAX Modem (Model 2977)
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 5
> Region 0: I/O ports at cc00 [size=8]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
> Any ideas?
>
> Mike
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
William G. Unruh Canadian Institute for Tel: +1(604)822-3273
Physics&Astronomy Advanced Research Fax: +1(604)822-5324
UBC, Vancouver,BC Program in Cosmology unruh@physics.ubc.ca
Canada V6T 1Z1 and Gravity www.theory.physics.ubc.ca/
For step by step instructions about setting up ppp under Linux, see
http://www.theory.physics.ubc.ca/ppp-linux.html
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-08-23 15:12 ` your mail Bill Unruh
@ 2002-08-23 15:26 ` Mike Dresser
2002-08-23 16:12 ` Bill Unruh
0 siblings, 1 reply; 669+ messages in thread
From: Mike Dresser @ 2002-08-23 15:26 UTC (permalink / raw)
To: Bill Unruh; +Cc: linux-ppp, linux-kernel
On Fri, 23 Aug 2002, Bill Unruh wrote:
> Well, it would be good if you actually told us what problem you were
> describing. Is this a new connection attempt after the first hang up?
> What?
>
> What repeats over and over-- I see no repeat.
I >
> You also do not tell us info like what kind of modem is this-- external,
> internal, serial, usb, pci, winmodem,....
>
> I assume what you are refering to is the "inappropriate ioctl" line.
> This indicates a hardware problem.
>
> Actually, it looks to me like another pppd is up on the line. Those
> EchoReq are another pppd receiving stuff on an open pppd on another
> line. More information on what it is you are trying to do, on what your
> system is, and what the problem is might get you help.
>
Sorry.
It's a new connection from the persist option. The exact same message
repeats for every dial out it attempts.
It's a PCI 3com 56k Sportster. It's a hardware modem.
There is sometimes another pppd up on ttys1
Here's the setup:
There is an external modem on ttyS01, irq 3, that dials in occasionally as
needed.
there is an internal PCI modem on ttyS04, irq 5, that dials in permamently
to the ISP.
Every 6 hours, the ISP enforces the 6 hour hangup rule they have.
The modem is set to persist, max-fails 0. It is not able to redial, and
keeps giving the error message that i pasted.
Under 2.2.x, this functioned properly.
System is a VIA VT82C693A/694x [Apollo PRO133x] based motherboard, from
Giga-byte, if I remember correctly. Celeron 533.
Sorry about the too brief error message, I fell into my "it makes sense to
me the way it is" trap.
Mike
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-08-23 15:26 ` Mike Dresser
@ 2002-08-23 16:12 ` Bill Unruh
2002-08-23 20:33 ` Mike Dresser
2002-08-25 2:05 ` Mike Dresser
0 siblings, 2 replies; 669+ messages in thread
From: Bill Unruh @ 2002-08-23 16:12 UTC (permalink / raw)
To: Mike Dresser; +Cc: linux-ppp, linux-kernel
OK, that problem is usually a "hardware" problem-- ie the hardware is
not responding properly to the icotl request. This could be because
there is not hardware there (eg trying to open a serial port which does
not exist on the machine), or is busy, or has been left in some weird
state. The last sounds most likely here-- eg the serial port on your
modem thinks it is still busy.
You could try running the little program I got basically from Carlson in
http://axion.physics.ubc.ca/modem-chk.html
to try resetting the serial line befor the next attempt (eg, put it into
/etc/ppp/ip-down).
Not sure if this is the problem however.
On Fri, 23 Aug 2002, Mike Dresser wrote:
> On Fri, 23 Aug 2002, Bill Unruh wrote:
>
> > Well, it would be good if you actually told us what problem you were
> > describing. Is this a new connection attempt after the first hang up?
> > What?
> >
> > What repeats over and over-- I see no repeat.
>
> I >
> > You also do not tell us info like what kind of modem is this-- external,
> > internal, serial, usb, pci, winmodem,....
> >
> > I assume what you are refering to is the "inappropriate ioctl" line.
> > This indicates a hardware problem.
> >
> > Actually, it looks to me like another pppd is up on the line. Those
> > EchoReq are another pppd receiving stuff on an open pppd on another
> > line. More information on what it is you are trying to do, on what your
> > system is, and what the problem is might get you help.
> >
>
> Sorry.
>
> It's a new connection from the persist option. The exact same message
> repeats for every dial out it attempts.
>
> It's a PCI 3com 56k Sportster. It's a hardware modem.
>
> There is sometimes another pppd up on ttys1
>
> Here's the setup:
>
> There is an external modem on ttyS01, irq 3, that dials in occasionally as
> needed.
>
> there is an internal PCI modem on ttyS04, irq 5, that dials in permamently
> to the ISP.
>
> Every 6 hours, the ISP enforces the 6 hour hangup rule they have.
>
> The modem is set to persist, max-fails 0. It is not able to redial, and
> keeps giving the error message that i pasted.
>
> Under 2.2.x, this functioned properly.
>
> System is a VIA VT82C693A/694x [Apollo PRO133x] based motherboard, from
> Giga-byte, if I remember correctly. Celeron 533.
>
> Sorry about the too brief error message, I fell into my "it makes sense to
> me the way it is" trap.
>
> Mike
>
>
--
William G. Unruh Canadian Institute for Tel: +1(604)822-3273
Physics&Astronomy Advanced Research Fax: +1(604)822-5324
UBC, Vancouver,BC Program in Cosmology unruh@physics.ubc.ca
Canada V6T 1Z1 and Gravity www.theory.physics.ubc.ca/
For step by step instructions about setting up ppp under Linux, see
http://www.theory.physics.ubc.ca/ppp-linux.html
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-08-23 16:12 ` Bill Unruh
@ 2002-08-23 20:33 ` Mike Dresser
2002-08-25 2:05 ` Mike Dresser
1 sibling, 0 replies; 669+ messages in thread
From: Mike Dresser @ 2002-08-23 20:33 UTC (permalink / raw)
To: Bill Unruh; +Cc: linux-ppp, linux-kernel
On Fri, 23 Aug 2002, Bill Unruh wrote:
>
> OK, that problem is usually a "hardware" problem-- ie the hardware is
> not responding properly to the icotl request. This could be because
> there is not hardware there (eg trying to open a serial port which does
> not exist on the machine), or is busy, or has been left in some weird
> state. The last sounds most likely here-- eg the serial port on your
> modem thinks it is still busy.
>
> You could try running the little program I got basically from Carlson in
> http://axion.physics.ubc.ca/modem-chk.html
> to try resetting the serial line befor the next attempt (eg, put it into
> /etc/ppp/ip-down).
> Not sure if this is the problem however.
Another 7 minutes, and I'll know if this worked or not.
Another data point I just thought of, if i poff chatham, and then pon
chatham, that actually works.
It just hung up.
And redialed.
And connected properly.
Thank you so very much, it looks like your reset-serial did the job.
I'll implement it on future machines, just in case the same problem
happens, rather than pray it works.
I saw a lot of postings on the 5160 USR modem on the serial-pci-info list,
perhaps it's something to do with this modem.
I'll know for sure at 10:30 this evening, if it is definately owrking or
not. I was logged in on the other line to monitor the syslog, and bring
up the internet line, just in case.
Thanks again,
Mike
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-08-23 16:12 ` Bill Unruh
2002-08-23 20:33 ` Mike Dresser
@ 2002-08-25 2:05 ` Mike Dresser
1 sibling, 0 replies; 669+ messages in thread
From: Mike Dresser @ 2002-08-25 2:05 UTC (permalink / raw)
To: Bill Unruh; +Cc: linux-ppp, linux-kernel
On Fri, 23 Aug 2002, Bill Unruh wrote:
> You could try running the little program I got basically from Carlson in
> http://axion.physics.ubc.ca/modem-chk.html
> to try resetting the serial line befor the next attempt (eg, put it into
> /etc/ppp/ip-down).
> Not sure if this is the problem however.
It died again.
I'm going to go out there and swap out the modem with a different model if
i have one. If that doesn't fix it, I'll get that VIA garbage out of the
system and replaced with a proper Intel 815 based motherboard.
Mike
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-08-19 21:29 Bloch, Jack
2002-08-20 6:47 ` your mail Philipp Matthias Hahn
0 siblings, 1 reply; 669+ messages in thread
From: Bloch, Jack @ 2002-08-19 21:29 UTC (permalink / raw)
To: linux-kernel
Are there any plans to do an SCTP (RFC 2960) implementation for Linux?
Please CC me directly on any responses.
Thanks in advance.
Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-08-16 7:51 Misha Alex
2002-08-16 9:52 ` your mail Willy Tarreau
0 siblings, 1 reply; 669+ messages in thread
From: Misha Alex @ 2002-08-16 7:51 UTC (permalink / raw)
To: linux-kernel
Hi,
1)How do convert C,H,S into bytes.
How can one read in linux if we know the C,H,S.
Also i tried the linear addressing linear = c*H*S + h*S +s -1 .But
linear or linear*512 never gave me the exact byte offset to seek.
I am working in linux and using a hexeditor to seek .How many exact bytes
should i seek to find out the extended partition.I read the MBR and found
the exteneded partiton.
00 01 01 00 02 fe 3f 01 3f 00 00 00 43 7d 00 00
80 00 01 02 0b fe bf 7e 82 7d 00 00 3d 26 9c 00
00 00 81 7f 0f fe ff ff bf a3 9c 00 f1 49 c3 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
See the third column it is 0f(extended windows).The cylinder is 639(7f81 h)
and sector is 1 .I don't know where to exactly read for the next partiton.
The byte offset for finding out the next partitions.
If i open hda3(Mind you hda3 is an extended partition on hda) with a
hexeditor i get
00 01 81 7f 83 fe ff 7d 3f 00 00 00 00 82 3e 00
00 00 c1 7e 05 fe ff ff 3f 82 3e 00 7e 04 7d 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
.Now the first partition is of type 83 which is linux and the next
extended partition is of type 05(extended) and cylinder894 and sec1.
*************************************
How do i find the next chain of extended partitions.I mean how do i convert
cylinder 894 ,sec1 and head 0 into absolute bytes so that i can hexdump the
next partition table for finding out ?
************************************
Thank you,
Misha
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-08-16 7:51 Misha Alex
@ 2002-08-16 9:52 ` Willy Tarreau
0 siblings, 0 replies; 669+ messages in thread
From: Willy Tarreau @ 2002-08-16 9:52 UTC (permalink / raw)
To: Misha Alex; +Cc: linux-kernel
Hello !
On Fri, Aug 16, 2002 at 07:51:37AM +0000, Misha Alex wrote:
> Also i tried the linear addressing linear = c*H*S + h*S +s -1 .But
> linear or linear*512 never gave me the exact byte offset to seek.
>
> I am working in linux and using a hexeditor to seek .How many exact bytes
> should i seek to find out the extended partition.I read the MBR and found
> the exteneded partiton.
> 00 01 01 00 02 fe 3f 01 3f 00 00 00 43 7d 00 00
> 80 00 01 02 0b fe bf 7e 82 7d 00 00 3d 26 9c 00
> 00 00 81 7f 0f fe ff ff bf a3 9c 00 f1 49 c3 01
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I haven't played with this for a long time, but I still have some memory
about this. First, when an offset is higher than 8GB, there's no way to
code it with the bios' CHS scheme as you find it in the partition table.
I see that you know how to decode this, so set all the CHS bits to ones
and look at the offset. For this reason, we often use only the size to
locate these partitions. If I recall correctly, the last 4 bytes of your
parts are the sizes in sectors. For example, hda2 is 9c263d sectors long,
which equals 5.2 GB. You'll notice that bytes 8 to 11 of each partitions
are nearly equivalent to the size of the previous part. They should be
the start offset in sectors. So in this case, hda3 begins at 9ca3bf
(byte 5255953920), and is 1c349f1 sectors long (15.1 GB).
I think that 'fe ff ff' after the partition type indicates that only the
linear mode should be used, but I'm not sure about this nor I do I have
any proof. You should read the partition code to get more clues, IMHO.
Hoping this helps,
Willy
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-08-08 11:28 Samarth Sharma
2002-08-08 13:01 ` your mail Wayne Salamon
0 siblings, 1 reply; 669+ messages in thread
From: Samarth Sharma @ 2002-08-08 11:28 UTC (permalink / raw)
To: selinux
hi,
A security aware application like the sshd daemon acts as an
object manager for all its related processes..is this correct?? or
are object managers are a part of the kernel.
if sshd does act as an object manager who enforces the access
decisions for the sshd daemon..
Also if the daemon does act as an object manager does it not
involve incorporating policy logic in the manager therby violating
the primary principle of Flask architecture..
Please clarify
thanks
samarth
__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com. Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-08-08 11:28 Samarth Sharma
@ 2002-08-08 13:01 ` Wayne Salamon
0 siblings, 0 replies; 669+ messages in thread
From: Wayne Salamon @ 2002-08-08 13:01 UTC (permalink / raw)
To: Samarth Sharma; +Cc: selinux
On 8 Aug 2002, Samarth Sharma wrote:
> hi,
> A security aware application like the sshd daemon acts as an
> object manager for all its related processes..is this correct?? or
> are object managers are a part of the kernel.
> if sshd does act as an object manager who enforces the access
> decisions for the sshd daemon..
> Also if the daemon does act as an object manager does it not
> involve incorporating policy logic in the manager therby violating
> the primary principle of Flask architecture..
All object access by processes will be controlled by the SELinux
module. Security aware applications can make use of extended system calls
provided with SELinux to control security IDs on objects, but only as far
as the policy allows. Therefore, there is no violation, or bypassing, of
the controls provided by the Flask architecture.
The application can control labeling of objects, but not the enforcement
of the policy based on those labels.
--
Wayne Salamon
wsalamon@tislabs.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-07-24 13:37 Richard Mayo
2002-07-24 14:22 ` your mail Stephen Smalley
0 siblings, 1 reply; 669+ messages in thread
From: Richard Mayo @ 2002-07-24 13:37 UTC (permalink / raw)
To: SELinux
It's obvious to me how to configure my computer to boot only to SELinux,
but how do I force the computer into Enforcing mode?
Also, when a user logs on the system asks if he or she would like to switch
user contexts. Is there an easy way to suppress this?
Thanks,
R.
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-07-24 13:37 Richard Mayo
@ 2002-07-24 14:22 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2002-07-24 14:22 UTC (permalink / raw)
To: Richard Mayo; +Cc: SELinux
On Wed, 24 Jul 2002, Richard Mayo wrote:
> It's obvious to me how to configure my computer to boot only to SELinux,
> but how do I force the computer into Enforcing mode?
You need to specify enforcing=1 on the kernel command line, as noted in
selinux/README. You can add an append="enforcing=1" line to the entry in
lilo.conf if using LILO or you can add enforcing=1 to the kernel line
in grub.conf if using GRUB. If you want the kernel to always operate in
enforcing mode (i.e. never be able to toggle into permissive mode), you
can simply rebuild the kernel without the SELinux Development Module
option. See step 20 of the README.
> Also, when a user logs on the system asks if he or she would like to switch
> user contexts. Is there an easy way to suppress this?
You could change login.c to use get_default_user_sid rather than
get_user_sid if you want login to always use the default user SID.
--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-07-20 19:20 Fernando Pablo Lopez-Lezcano
2002-07-21 8:28 ` your mail Jaroslav Kysela
0 siblings, 1 reply; 669+ messages in thread
From: Fernando Pablo Lopez-Lezcano @ 2002-07-20 19:20 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Takashi Iwai, Gary Scavone, Paul Davis, alsa-devel
> > > on a related note, although the above suggestion will fix this
> > > particular problem, it seems that it might be wise to consider adding
> > > a parameter order information field to the driver API, so that drivers
> > > can say "you have to set param P first, then param N, then param
> > > O". the default would obviously be "don't care", but for devices that
> > > lose certain capabilities when certain parameters are set, it would
> > > make things very much easier.
> >
> > agreed that it's good to have such one.
> > but how to implement this?
> > from the design of hw_constraint, i don't think it's so easy...
>
> I think that this implementation will create a big mess for the
> application developers. Also, I'm not sure, if it's really needed, because
> our refining code should already reduce the available configurations.
> Applications should use *_near() functions in order of their priority. You
> can't predict, if rate or count of channels or any other parameter is more
> important for a specific application.
[not exactly an answer but more details on what is actually happening]
I think this is what is happening with the current driver (Gary, please
correct me if I'm wrong): The application looks at the configuration
space and selects from it one particular sampling rate. Then it looks at
the channel count and sees a range of channel counts (10:18 - or some
numbers like that, I don't remember). The application chooses the minimum
channel count and the set function fails.
IMHO at that point the configuration space should have changed the number
of channels available to match the sampling rate selected so that the
channel count as advertised is legal (ie: if the selected sampling rate is
one of the "single speed" rates then the range of channels should be
18:18, if the sampling rate is one of the "double speed" rates then the
range should be 10:10).
The reverse is also true, if the application first selects number of
channels the sampling rates should be constrained to the set of rates that
can be supported by that number of channels.
If it is not possible to do this with the current api, then the next best
solution I can imagine is to have a switch that changes the mode of the
card between single and double speed (that would make the dependency
between sample rate and number of channels dissapear).
-- Fernando
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-07-20 19:20 (no subject) Fernando Pablo Lopez-Lezcano
@ 2002-07-21 8:28 ` Jaroslav Kysela
0 siblings, 0 replies; 669+ messages in thread
From: Jaroslav Kysela @ 2002-07-21 8:28 UTC (permalink / raw)
To: Fernando Pablo Lopez-Lezcano
Cc: Takashi Iwai, Gary Scavone, Paul Davis, alsa-devel
On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote:
> > > > on a related note, although the above suggestion will fix this
> > > > particular problem, it seems that it might be wise to consider adding
> > > > a parameter order information field to the driver API, so that drivers
> > > > can say "you have to set param P first, then param N, then param
> > > > O". the default would obviously be "don't care", but for devices that
> > > > lose certain capabilities when certain parameters are set, it would
> > > > make things very much easier.
> > >
> > > agreed that it's good to have such one.
> > > but how to implement this?
> > > from the design of hw_constraint, i don't think it's so easy...
> >
> > I think that this implementation will create a big mess for the
> > application developers. Also, I'm not sure, if it's really needed, because
> > our refining code should already reduce the available configurations.
> > Applications should use *_near() functions in order of their priority. You
> > can't predict, if rate or count of channels or any other parameter is more
> > important for a specific application.
>
> [not exactly an answer but more details on what is actually happening]
>
> I think this is what is happening with the current driver (Gary, please
> correct me if I'm wrong): The application looks at the configuration
> space and selects from it one particular sampling rate. Then it looks at
> the channel count and sees a range of channel counts (10:18 - or some
> numbers like that, I don't remember). The application chooses the minimum
> channel count and the set function fails.
>
> IMHO at that point the configuration space should have changed the number
> of channels available to match the sampling rate selected so that the
> channel count as advertised is legal (ie: if the selected sampling rate is
> one of the "single speed" rates then the range of channels should be
> 18:18, if the sampling rate is one of the "double speed" rates then the
> range should be 10:10).
>
> The reverse is also true, if the application first selects number of
> channels the sampling rates should be constrained to the set of rates that
> can be supported by that number of channels.
You've described exactly the behaviour which should be implemented in your
paragraphs. If the current implementation is broken, then we should fix
it.
> If it is not possible to do this with the current api, then the next best
> solution I can imagine is to have a switch that changes the mode of the
> card between single and double speed (that would make the dependency
> between sample rate and number of channels dissapear).
You may look to snd_rme9652_hw_rule_channels(),
snd_rme9652_hw_rule_channels_rate() and
snd_rme9652_hw_rule_rate_channels() functions in rme9652.c.
These functions exactly describes the contraints for rate/channels.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linux http://www.suse.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-07-06 15:59 Hacksaw
2002-07-07 19:32 ` your mail Min Li
0 siblings, 1 reply; 669+ messages in thread
From: Hacksaw @ 2002-07-06 15:59 UTC (permalink / raw)
To: Min Li; +Cc: linux-kernel
Hello Min:
I suggest your questions would be better asked on the kernle newbies list:
http://mail.nl.linux.org/kernelnewbies/
and/or on the RedHat install List:
https://listman.redhat.com/mailman/listinfo/redhat-install-list.
The kernel list is strictly for talk about developing the kernel. Also, please
read the linux kernel mailing list FAQ: http://www.tux.org/lkml/
--
Powered by beta particles
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-07-05 8:47 Christian Berger
2002-07-05 13:34 ` your mail Gerhard Mack
0 siblings, 1 reply; 669+ messages in thread
From: Christian Berger @ 2002-07-05 8:47 UTC (permalink / raw)
To: linux-kernel
unsubscribe linux-kernel
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <000d01c22361$62c9d6f0$0100a8c0@digital>]
* Re: your mail
[not found] <000d01c22361$62c9d6f0$0100a8c0@digital>
@ 2002-07-04 20:45 ` Stephen Tweedie
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Tweedie @ 2002-07-04 20:45 UTC (permalink / raw)
To: Naseer Bhatti
Cc: security, security, linux-kernel, sct, akpm, adilger, ext3-users
Hi,
On Thu, Jul 04, 2002 at 06:47:11PM +0500, Naseer Bhatti <naseer@digitallinx.com> wrote:
> I got these errors in the log on a Production server. I am running ProFTPD 1.2.4 with RedHat 7.2 Kernel 2.4.7-10 not yet compiled myself and Apache 1.3.26. I got my server stop responding and after reboot I checked the logs and got a lots of kernel bugs. ProFTPD was also involved in that. httpd (Apache 1.3.26) also gave some stack output. Correct me if I am wrong. I have attached the file for detailed analysis. Please check it and let me know about the possible bug/solution.
The log shows no sign of any ext3 problem. I can't see anything in it
which would justify trying to send a compressed log of nearly 400kB to
an ext3 general users mailing list.
For what it's worth, your dcache oopses are most often associated with
bad memory --- try memtest86 on that machine before you go any
further.
--Stephen
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-06-24 5:49 pah
2002-06-24 7:34 ` your mail Zwane Mwaikambo
0 siblings, 1 reply; 669+ messages in thread
From: pah @ 2002-06-24 5:49 UTC (permalink / raw)
To: linux-kernel
Hello,
I've just found a bug (an unsignificant bug) in the panic() function!
There's a possible buffer overflow if the formated string exceeds
1024 characters (I think that the problem is in all kernel releases).
The problem is in the use of vsprintf() insted of vsnprintf()!
I know that this doesn't compromise any exploitation by an uid
different than zero, but should be fixed in the case of panic()'s arguments
exceeds the buffer limit (probably by an lkm or something like that) and
cause (probably) a system crash.
Here is the exploitation by an lkm:
/************** LKM ***********/
/*
* panic()'s buffer overflow test
*
* By: Pedro Hortas
* E-Mail: pah@promiscua.org
*
*/
#define __KERNEL__
#define MODULE
#define _LOOSE_KERNEL_NAMES
#include <linux/module.h>
#include <linux/kernel.h>
int init_module(void) {
char foo[2048];
int i;
for (i = 0; i < sizeof(foo); i++)
foo[i] = '\x90';
foo[i - 1] = 0;
panic("Overflowing panic()'s buffer: %s\n", foo);
return 0;
}
int cleanup_module(void) {
return 0;
}
/************* END OF LKM ************/
And here is the patch to fix the problem:
/************* PATCH **************/
diff -urP linux/kernel/panic.c linux-patched/kernel/panic.c
--- linux/kernel/panic.c Sun Sep 30 20:26:08 2001
+++ linux-patched/kernel/panic.c Mon Jun 24 06:18:12 2002
@@ -51,7 +51,7 @@
bust_spinlocks(1);
va_start(args, fmt);
- vsprintf(buf, fmt, args);
+ vsnprintf(buf, sizeof(buf), fmt, args);
va_end(args);
printk(KERN_EMERG "Kernel panic: %s\n",buf);
if (in_interrupt())
/************** END OF PATCH *************/
Pedro Hortas
pah@promiscua.org
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-06-24 5:49 pah
@ 2002-06-24 7:34 ` Zwane Mwaikambo
0 siblings, 0 replies; 669+ messages in thread
From: Zwane Mwaikambo @ 2002-06-24 7:34 UTC (permalink / raw)
To: pah; +Cc: linux-kernel
On 24 Jun 2002 pah@promiscua.org wrote:
> I've just found a bug (an unsignificant bug) in the panic() function!
> There's a possible buffer overflow if the formated string exceeds
> 1024 characters (I think that the problem is in all kernel releases).
> The problem is in the use of vsprintf() insted of vsnprintf()!
>
> I know that this doesn't compromise any exploitation by an uid
> different than zero, but should be fixed in the case of panic()'s arguments
> exceeds the buffer limit (probably by an lkm or something like that) and
> cause (probably) a system crash.
>
In that case there are quite a number of other places in the kernel which
can be 'exploited' in various ways.
Cheers,
Zwane
--
http://function.linuxpower.ca
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-05-16 12:40 Sanket Rathi
2002-05-16 13:38 ` your mail Alan Cox
0 siblings, 1 reply; 669+ messages in thread
From: Sanket Rathi @ 2002-05-16 12:40 UTC (permalink / raw)
To: linux-kernel
I just want to know how can we restrict the maximum virtual memory and
maximum physical memory on ia64 platform.
Is there any settings in kernel so that we can change that and recompile
kernel. Actually we have a device which can only access 44 bits so we cant
I just want to know how can we restrict the maximum virtual memory and
maximum physical memory on ia64 platform.
Is there any settings in kernel so that we can change that and recompile
kernel. Actually we have a device which can only access 44 bits so we cant
have 64 bit address. I mean is it possible to discard some bits which are
not significant.
Tell me something related to this or any link which i can refer
Thanks in advance
--- Sanket Rathi
--------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-16 12:40 Sanket Rathi
@ 2002-05-16 13:38 ` Alan Cox
2002-05-16 15:54 ` Sanket Rathi
0 siblings, 1 reply; 669+ messages in thread
From: Alan Cox @ 2002-05-16 13:38 UTC (permalink / raw)
To: Sanket Rathi; +Cc: linux-kernel
> I just want to know how can we restrict the maximum virtual memory and
> maximum physical memory on ia64 platform.
> kernel. Actually we have a device which can only access 44 bits so we cant
That won't help you. You might not be dealing with RAM at the bottom of the
address space. You might also be in platforms with an iommu, or doing DMA
to another PCI target
> Tell me something related to this or any link which i can refer
Assuming the device is doing bus mastering. Read
Documentation/DMA-mapping.txt
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-16 13:38 ` your mail Alan Cox
@ 2002-05-16 15:54 ` Sanket Rathi
2002-05-16 18:05 ` Alan Cox
2002-05-20 18:07 ` David Mosberger
0 siblings, 2 replies; 669+ messages in thread
From: Sanket Rathi @ 2002-05-16 15:54 UTC (permalink / raw)
To: Alan Cox; +Cc: Sanket Rathi, linux-kernel
No actually i don't want that for DMA it is for diffrent requirment.
actually in our device there is a page table in device which have
virtual to physical address translation we save virtual address in device
and corresponding physical address. but we can store only upto 44 bit
information of virtual address thats why i want that.
Can you help me in this
Thanks in advance
-----
--------Sanket
> > I just want to know how can we restrict the maximum virtual memory and
> > maximum physical memory on ia64 platform.
> > kernel. Actually we have a device which can only access 44 bits so we cant
>
> That won't help you. You might not be dealing with RAM at the bottom of the
> address space. You might also be in platforms with an iommu, or doing DMA
> to another PCI target
>
> > Tell me something related to this or any link which i can refer
>
> Assuming the device is doing bus mastering. Read
> Documentation/DMA-mapping.txt
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-16 15:54 ` Sanket Rathi
@ 2002-05-16 18:05 ` Alan Cox
2002-05-20 18:07 ` David Mosberger
1 sibling, 0 replies; 669+ messages in thread
From: Alan Cox @ 2002-05-16 18:05 UTC (permalink / raw)
To: Sanket Rathi; +Cc: Alan Cox, Sanket Rathi, linux-kernel
> No actually i don't want that for DMA it is for diffrent requirment.
> actually in our device there is a page table in device which have
> virtual to physical address translation we save virtual address in device
> and corresponding physical address. but we can store only upto 44 bit
> information of virtual address thats why i want that.
Still read Documentation/DMA-mapping.txt
Whether its DMA or not you are going to need to keep the allocations below
44bits and thats what the DMA allocators do
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-16 15:54 ` Sanket Rathi
2002-05-16 18:05 ` Alan Cox
@ 2002-05-20 18:07 ` David Mosberger
1 sibling, 0 replies; 669+ messages in thread
From: David Mosberger @ 2002-05-20 18:07 UTC (permalink / raw)
To: Sanket Rathi; +Cc: Alan Cox, linux-kernel
>>>>> On Thu, 16 May 2002 21:24:10 +0530 (IST), Sanket Rathi <sanket.rathi@cdac.ernet.in> said:
Sanket> No actually i don't want that for DMA it is for diffrent
Sanket> requirment. actually in our device there is a page table in
Sanket> device which have virtual to physical address translation we
Sanket> save virtual address in device and corresponding physical
Sanket> address. but we can store only upto 44 bit information of
Sanket> virtual address thats why i want that.
Sanket> Can you help me in this
There is no way to limit virtual memory to 44 bits. I don't know how
your device works, but just fyi: ia64 divides the address space into 8
equal-sized regions and user space applications tend to use at least
two regions (2 for text and 3 for data/stack). This means that even
with the smallest page size, you'll have to take virtual address bits
61-63 into account.
Hope this helps,
--david
--
Interested in learning more about IA-64 Linux? Try http://www.lia64.org/book/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-05-03 14:19 Keith Owens
2002-05-03 14:37 ` your mail tomas szepe
0 siblings, 1 reply; 669+ messages in thread
From: Keith Owens @ 2002-05-03 14:19 UTC (permalink / raw)
To: kbuild-devel; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
release 2.4.
kbuild-2.5-core-13-1.
Changes from core-9.
Update documentation for asm-offsets.h.
Remove the requirement that arch/$(ARCH)/Makefile.defs.*config had
to be in the base tree. Now a new architecture can be a completely
separate drop in tree.
Really force CONFIG_MODVERSIONS=n. Modversions will not be
supported until after kbuild 2.5 is in the main kernel.
Change phase 4 message, it does a lot of integrity checks as well
as generating the global makefile. Will that shut up people who
think that we don't need integrity checks? Probably not :(.
Correct bug in symlink message.
kbuild-2.5-common-2.5.13-1.
Changes from common-2.5.12-1.
Upgrade to kernel 2.5.13.
kbuild-2.5-i386-2.5.13-1.
Changes from i386-2.5.12-1.
Upgrade to kernel 2.5.13.
Correct CC/CC_real in arch/$(ARCH)/Makefile.defs.*config.
You should be able to use kbuild-2.5-sparc64-2.5.12-1 with this
release. ia64 is probably out of date by now and is not recommended
for use with 2.5.13. I will do the kbuild 2.5 update for ia64 after we
get a new ia64 kernel patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE80pxci4UHNye0ZOoRAvYBAJ9eaE5JxM3vH3pmzI8ho6q3VsrRlACbBspY
u7SNlyBjmhgTD4YnSxw+Jas=
=Ek9t
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-05-03 14:19 Keith Owens
@ 2002-05-03 14:37 ` tomas szepe
2002-05-03 15:07 ` tomas szepe
2002-05-03 15:29 ` Keith Owens
0 siblings, 2 replies; 669+ messages in thread
From: tomas szepe @ 2002-05-03 14:37 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
> Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> release 2.4.
>
> kbuild-2.5-core-13-1.
I believe you meant 's/13/10/'.
> kbuild-2.5-common-2.5.13-1.
> kbuild-2.5-i386-2.5.13-1.
hmmm.. doesn't look so good.
kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz
kala@nibbler:~$ cd linux-2.5.13
kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
phase 1 (find all inputs)
...
kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 installable
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
spec value %p not found
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
phase 1 (find all inputs)
phase 2 (convert all Makefile.in files)
phase 3 (evaluate selections)
phase 4 (integrity checks, write global makefile)
pp_makefile4: arch/i386/lib/lib.a is selected but is not part of vmlinux, missing link_subdirs?
make: *** [phase4] Error 1
T.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-03 14:37 ` your mail tomas szepe
@ 2002-05-03 15:07 ` tomas szepe
2002-05-03 15:29 ` Keith Owens
1 sibling, 0 replies; 669+ messages in thread
From: tomas szepe @ 2002-05-03 15:07 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
Building as follows works, though.
$ cd /usr/src && tar xzf linux-2.5.13.tar.gz
$ cd ~ && mkdir build && cd build
$ export KBUILD_OBJTREE=$PWD
$ export KBUILD_SRCTREE_000=/usr/src/linux-2.5.13
$ alias M="make -f $KBUILD_SRCTREE_000/Makefile-2.5"
$ cp /lib/modules/2.5.13/.config .
$ M oldconfig
$ M installable
T.
> > Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> > http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> > release 2.4.
> >
> > kbuild-2.5-core-13-1.
>
> I believe you meant 's/13/10/'.
>
> > kbuild-2.5-common-2.5.13-1.
> > kbuild-2.5-i386-2.5.13-1.
>
> hmmm.. doesn't look so good.
>
> kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz
> kala@nibbler:~$ cd linux-2.5.13
> kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
> kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
> kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
> phase 1 (find all inputs)
> ...
>
> kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 installable
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> spec value %p not found
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
> phase 1 (find all inputs)
> phase 2 (convert all Makefile.in files)
> phase 3 (evaluate selections)
> phase 4 (integrity checks, write global makefile)
> pp_makefile4: arch/i386/lib/lib.a is selected but is not part of vmlinux, missing link_subdirs?
> make: *** [phase4] Error 1
>
>
> T.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-03 14:37 ` your mail tomas szepe
2002-05-03 15:07 ` tomas szepe
@ 2002-05-03 15:29 ` Keith Owens
2002-05-03 15:45 ` tomas szepe
1 sibling, 1 reply; 669+ messages in thread
From: Keith Owens @ 2002-05-03 15:29 UTC (permalink / raw)
To: tomas szepe; +Cc: kbuild-devel, linux-kernel
On Fri, 3 May 2002 16:37:38 +0200,
tomas szepe <kala@pinerecords.com> wrote:
>kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz
>kala@nibbler:~$ cd linux-2.5.13
>kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
>kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
>kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
>Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
The trailing '/' is omitted in one case. Workaround for common source and object
export KBUILD_SRCTREE_000=`pwd`/
make -f Makefile-2.5 oldconfig
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-05-03 15:29 ` Keith Owens
@ 2002-05-03 15:45 ` tomas szepe
0 siblings, 0 replies; 669+ messages in thread
From: tomas szepe @ 2002-05-03 15:45 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
> On Fri, 3 May 2002 16:37:38 +0200,
> tomas szepe <kala@pinerecords.com> wrote:
>
> >kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz
> >kala@nibbler:~$ cd linux-2.5.13
> >kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
> >kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
> >kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
> >Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
>
> The trailing '/' is omitted in one case. Workaround for common source and object
>
> export KBUILD_SRCTREE_000=`pwd`/
> make -f Makefile-2.5 oldconfig
Another problem/question:
$ cd build
$ export KBUILD_OBJTREE=$PWD
$ export KBUILD_SRCTREE_000=/usr/src/linux-2.5.13
$ alias M="make -f $KBUILD_SRCTREE_000/Makefile-2.5"
$ cp /lib/modules/2.5.13/.config .
$ M oldconfig
...
$ M installable
...
[so far so good]
$ make -f Makefile-2.5 menuconfig
[enable RAMDISK support, tweak ramdisk size, enable initrd]
...
Now, issuing "M installable" will result in nearly all files getting rebuilt.
The same happens when switching ramdisk off again. How's that?
I tried enabling/disabling many other config options and doing rebuilds but
couldn't find anything as damaging buildtime-wise as the ramdisk stuff.
Hopefully I'm causing no headaches,
T.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-04-24 18:29 Debian User
2002-04-24 20:19 ` your mail Stephen Smalley
0 siblings, 1 reply; 669+ messages in thread
From: Debian User @ 2002-04-24 18:29 UTC (permalink / raw)
To: SELinux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> On Wed, 24 Apr 2002, Debian User wrote:
>
> > Im getting lots of error messages when i use my pc after installing
> > selinux. How do I fix the configs? Where should i start? Are the error
> > messages enough to be able to fix my configuration?
>
> Are you using Russell Coker's Debian selinux package or the upstream
> distribution? If the latter, I'd suggest using the former, since the
> upstream distribution isn't set up for Debian.
>
> There is a contributed script in the distribution, scripts/newrules.pl,
> that filters your dmesg output and generates the allow rules that would
> need to be added to your policy configuration to avoid these denials.
> However, you will typically need to review these rules carefully to
> determine whether they are truly acceptable. In many cases, you will need
> to add new domains and/or types rather than simply adding the allow rule
> that corresponds to the audit message. These issues are discussed briefly
> in a new report that will hopefully be available soon.
>
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
>
>
I just used the prel script. Now im working on the syntax. I have the two
white papers with me. I think I need to define new types and domains.
What would possibly be the criteria for the decision? A rule of thumb if
i may say so.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8xvktT5WfhZieiQoRAicVAJ9mt8IhesuTE+Iv0mEMY17vf8Zg2ACdEeXR
USG5L3KFDPbfNAcJEVgKPkE=
=KrLp
-----END PGP SIGNATURE-----
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-04-24 18:29 Debian User
@ 2002-04-24 20:19 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2002-04-24 20:19 UTC (permalink / raw)
To: Debian User; +Cc: SELinux
On Thu, 25 Apr 2002, Debian User wrote:
> I just used the prel script. Now im working on the syntax. I have the two
> white papers with me. I think I need to define new types and domains.
> What would possibly be the criteria for the decision? A rule of thumb if
> i may say so.
First, read the selinux/README file, particularly the post-install
instructions (starting around step 18). Make sure that you don't have any
system processes left in initrc_t, as mentioned in step 18.
Domains and types are security equivalence classes for processes and
objects, respectively. In other words, all processes in the same domain
have the same permissions, and all objects with the same type (and class)
can be accessed in the same way. You want to use a distinct domain or
type when you want to distinguish a process or an object from others in
the security policy. Processes that have the same security properties can
be placed into the same domain. Similarly for objects and types.
The new policy report should be helpful in getting you started, although
it still isn't at the level of a HOWTO, so I'm hoping that others will
start writing HOWTOs derived from it and expanding upon it. I expect this
report to be released soon, but I'm not sure exactly when. Some
people at Tresys Technology have started writing some white papers related
to the policy that you can find at http://www.tresys.com/selinux.html.
--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-04-24 7:55 Huo Zhigang
2002-04-24 7:51 ` your mail Zwane Mwaikambo
2002-04-24 8:27 ` Alan Cox
0 siblings, 2 replies; 669+ messages in thread
From: Huo Zhigang @ 2002-04-24 7:55 UTC (permalink / raw)
To: linux-kernel
Hi, all.
My cluster go wrong these days. So many times when I "/sbin/reboot" a node, the following message will be displayed on the console.
>INIT: Switching to runlevel: 6
>INIT: Send processes the TERM signal
>Unable to handle kernel NULL pointer dereference
What's wrong with my machines? They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
Thank you in advance 8-)
Zhigang Huo
zghuo@ncic.ac.cn
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-04-24 7:55 Huo Zhigang
@ 2002-04-24 7:51 ` Zwane Mwaikambo
2002-04-24 8:27 ` Alan Cox
1 sibling, 0 replies; 669+ messages in thread
From: Zwane Mwaikambo @ 2002-04-24 7:51 UTC (permalink / raw)
To: Huo Zhigang; +Cc: Linux Kernel
On Wed, 24 Apr 2002, Huo Zhigang wrote:
> Hi, all.
> My cluster go wrong these days. So many times when I "/sbin/reboot" a node, the following message will be displayed on the console.
>
> >INIT: Switching to runlevel: 6
> >INIT: Send processes the TERM signal
> >Unable to handle kernel NULL pointer dereference
>
> What's wrong with my machines? They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
> Thank you in advance 8-)
>
> Zhigang Huo
> zghuo@ncic.ac.cn
Have you tried decoding the oops? Have a look at
linux/Documentation/oops-tracing.txt
Zwane
--
http://function.linuxpower.ca
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-04-24 7:55 Huo Zhigang
2002-04-24 7:51 ` your mail Zwane Mwaikambo
@ 2002-04-24 8:27 ` Alan Cox
1 sibling, 0 replies; 669+ messages in thread
From: Alan Cox @ 2002-04-24 8:27 UTC (permalink / raw)
To: Huo Zhigang; +Cc: linux-kernel
>
> >INIT: Switching to runlevel: 6
> >INIT: Send processes the TERM signal
> >Unable to handle kernel NULL pointer dereference
>
> What's wrong with my machines? They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
> Thank you in advance 8-)
If you boot the machije without your driver, then reboot does the
same happen ? If not then it may well be your driver has an error but only
when it closes down
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-04-21 21:16 Ivan G.
2002-04-21 23:02 ` your mail Jeff Garzik
0 siblings, 1 reply; 669+ messages in thread
From: Ivan G. @ 2002-04-21 21:16 UTC (permalink / raw)
To: Urban Widmark; +Cc: LKML
Urban,
About the suggestion to make via_rhine_error handle more interrupts,
enum intr_status_bits {
IntrRxDone=0x0001, IntrRxErr=0x0004, IntrRxEmpty=0x0020,
IntrTxDone=0x0002, IntrTxAbort=0x0008, IntrTxUnderrun=0x0010,
IntrPCIErr=0x0040,
IntrStatsMax=0x0080, IntrRxEarly=0x0100, IntrMIIChange=0x0200,
IntrRxOverflow=0x0400, IntrRxDropped=0x0800, IntrRxNoBuf=0x1000,
IntrTxAborted=0x2000, IntrLinkChange=0x4000,
IntrRxWakeUp=0x8000,
IntrNormalSummary=0x0003, IntrAbnormalSummary=0xC260,
};
RxEarly, RxOverflow, RxNoBuf are not handled
(which brings up another question - how should they be handled
and where?? It doesn't seem to me that those should end up in error,
sending CmdTxDemand. )
RxErr, RxWakeUp, RxDropped, RxEmpty call via_rhine_rx
TxAbort, TxUnderrun,PCIErr, StatsMax, MIIChange call via_rhine_error
TxAborted calls via_rgine_tx
The others don't look like errors.
Martin Eriksson,
The reason my message said PCI Error and not unhandled
is because it specifies a specific interrupt - IntrPCIErr.
(basically the onle one that's left unhandled that can call via_rhine_error)
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-04-21 21:16 Ivan G.
@ 2002-04-21 23:02 ` Jeff Garzik
0 siblings, 0 replies; 669+ messages in thread
From: Jeff Garzik @ 2002-04-21 23:02 UTC (permalink / raw)
To: Ivan G.; +Cc: Urban Widmark, LKML
On Sun, Apr 21, 2002 at 03:16:40PM -0600, Ivan G. wrote:
> Urban,
>
> About the suggestion to make via_rhine_error handle more interrupts,
>
> enum intr_status_bits {
> IntrRxDone=0x0001, IntrRxErr=0x0004, IntrRxEmpty=0x0020,
> IntrTxDone=0x0002, IntrTxAbort=0x0008, IntrTxUnderrun=0x0010,
> IntrPCIErr=0x0040,
> IntrStatsMax=0x0080, IntrRxEarly=0x0100, IntrMIIChange=0x0200,
> IntrRxOverflow=0x0400, IntrRxDropped=0x0800, IntrRxNoBuf=0x1000,
> IntrTxAborted=0x2000, IntrLinkChange=0x4000,
> IntrRxWakeUp=0x8000,
> IntrNormalSummary=0x0003, IntrAbnormalSummary=0xC260,
> };
>
> RxEarly, RxOverflow, RxNoBuf are not handled
> (which brings up another question - how should they be handled
> and where?? It doesn't seem to me that those should end up in error,
> sending CmdTxDemand. )
*blink* I had not noticed that.
All drivers actually need to handle RxNoBufs and RxOverflow, assuming
they have similar meaning to what I'm familiar with on other chips.
The chip may recover transparently, but one should be at least aware of
them.
RxEarly you very likely do -not- want to handle...
Jeff
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-04-21 14:54 raciel
2002-04-21 19:12 ` your mail William Lee Irwin III
0 siblings, 1 reply; 669+ messages in thread
From: raciel @ 2002-04-21 14:54 UTC (permalink / raw)
To: linux-mm
Hello all :)
I have been trying to understand the rmap patch from Rik Van Riel, but
i dont undertand what the rmap patch do. Somebody can explain me or know
a good site where i can get documentation?
Regards Raciel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-04-21 14:54 raciel
@ 2002-04-21 19:12 ` William Lee Irwin III
0 siblings, 0 replies; 669+ messages in thread
From: William Lee Irwin III @ 2002-04-21 19:12 UTC (permalink / raw)
To: raciel; +Cc: linux-mm
On Sun, Apr 21, 2002 at 02:54:00PM +0000, raciel wrote:
> Hello all :)
> I have been trying to understand the rmap patch from Rik Van Riel, but
> i dont undertand what the rmap patch do. Somebody can explain me or know
> a good site where i can get documentation?
> Regards Raciel
The largest piece of functionality is additional accounting that enables
the kernel to find all users of a given page. This is known as physical
scanning, and other OS's call similar functionality "pmap", "ptov" (for
physical to virtual), and "HAT" (Hardware Address Translation), though
the interfaces are just as different as the names.
There are two very important translation mechanisms:
(1) physical page to page table entry
(2) 3rd-level pagetable to address space (mm_struct)
(1) is accomplished by using a singly linked list of page table entry
addresses attached to a per-physical-page structure (struct page).
(2) is accomplished by reusing one of the fields of struct page for the
3rd-level pagetable to hold the pointer to the mm_struct.
To clarify how a physical page is handled, the page replacement
algorithm might decide that a given physical page is targeted for
eviction. It then calls try_to_unmap(), which traverses the list of
3rd-level pagetable entries, and then rounds their addresses to
obtain the physical page occupied by the 3rd-level pagetable, then
it finds the struct page for that physical page, and then it tries
to obtain locks on the address space's pagetable lock and when it
does, it just removes the thing from the pagetable, otherwise it
returns an error code saying "try again later" (SWAP_AGAIN).
All this requires is
(1) putting an entry onto the per-page list when entering a page
into pagetables
(2) pulling things off the per-page list when removing a page
from pagetables
(3) marking a 3rd-level pagetable's struct page with the mm_struct
Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (unknown),
@ 2002-04-19 19:32 raciel
2002-04-19 23:33 ` your mail James Morris
0 siblings, 1 reply; 669+ messages in thread
From: raciel @ 2002-04-19 19:32 UTC (permalink / raw)
To: linux-net
Somebody can tell me where i can get the LSM patch?
Regards Raciel
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <ADEEIKPBIEHIINPOFGAOIECBCBAA.gvanuxem@club-internet.fr>]
* Re: your mail
[not found] <ADEEIKPBIEHIINPOFGAOIECBCBAA.gvanuxem@club-internet.fr>
@ 2002-03-15 15:31 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2002-03-15 15:31 UTC (permalink / raw)
To: Vanuxem grégory; +Cc: SELinux Mailing
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2499 bytes --]
On Fri, 15 Mar 2002, [iso-8859-1] Vanuxem grégory wrote:
> I try to record the PSID directly in some attribute of inodes. Particularly
> in xfs.
> What do you think about that ?
This has come up previously on the mailing list, so you might want to
review the mailing list archives. A brief review:
In the original SELinux kernel patch, we stored the PSID directly in a
spare field of the on-disk ext2 inode. When SELinux was re-implemented to
use the LSM kernel patch, the persistent label mapping was changed to
maintain the inode-to-PSID mapping in a regular file rather than using a
field in the inode since LSM does not provide any low-level
filesystem-specific hooks. That change allows SELinux to support other
filesystem types more easily, but has disadvantages in terms of
performance and consistency.
As support for extended attributes becomes mainstreamed, I'd like to see
SELinux enhanced to optionally use them for persistent labeling when they
are supported by the filesystem type. This seems reasonable for XFS (but
see my earlier email regarding other issues with using XFS -
http://marc.theaimsgroup.com/?l=selinux&m=101300861319394&w=2).
Storing PSIDs via extended attributes is certainly one option. Another
option would be to directly store file security contexts using extended
attributes, completely eliminating the separate persistent label mapping.
Regardless, you need to ensure that any changes you make don't prevent
SELinux from continuing to work with filesystems that do not support EAs.
> Another question, why the mapping inode->psid is always record in the file
> ...security/inode.
> For example, if I mount a file system that contained 50 differents types of
> files (context),the SECFILES keep all the mapping. Now I have just three
> types for the initialization, the root dir type, the fs type and the
> "file_t" type but the avc keep the precedent mapping (50 psids and
> contexts).
I'm not sure what you are asking. The SELinux kernel module opens the
mapping files and does an initial load of the PSID-to-context mapping at
mount time. The incore cache for the PSID-to-context mapping is for
performance. The inode-to-PSID mapping would be too large to keep incore.
--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-03-13 19:21 Romain Liévin
2002-03-13 19:43 ` your mail Alan Cox
2002-03-14 7:08 ` Zwane Mwaikambo
0 siblings, 2 replies; 669+ messages in thread
From: Romain Liévin @ 2002-03-13 19:21 UTC (permalink / raw)
To: Kernel List; +Cc: Linus Torvalds, Alan Cox, Tim Waugh
This is a new driver which uses parport for handling a parallel link cable
designed to connect a Texas Instruments graphing calculators to a
computer/workstation.
It has been tested on x86 for almost 2 years and on Alpha & Sparc too with
various calculators.
BTW, a such driver was requested on SlashDot in 1999.
I also have 2 similar drivers I will submit: one for the serial cable, the
other for the USB cable.
==============================[ cut here ]==============================
--- linux.orig/MAINTAINERS Wed Mar 13 18:30:35 2002
+++ linux/MAINTAINERS Wed Mar 13 19:07:55 2002
@@ -1502,6 +1502,13 @@
M: hch@infradead.org
S: Maintained
+TI PARALLEL LINK CABLE DRIVER
+P: Romain Lievin
+M: roms@lpg.ticalc.org
+P: Julien Blache
+M: jb@technologeek.org
+S: Maintained
+
TLAN NETWORK DRIVER
P: Torben Mathiasen
M: torben.mathiasen@compaq.com
--- linux.orig/drivers/char/tipar.c Wed Mar 13 19:19:10 2002
+++ linux/drivers/char/tipar.c Wed Mar 13 20:12:37 2002
@@ -0,0 +1,541 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar - low level driver for handling a parallel link cable
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#define VERSION "1.11"
+
+/* This driver should, in theory, work with any parallel port that has an
+ * appropriate low-level driver; all I/O is done through the parport
+ * abstraction layer.
+ *
+ * If this driver is built into the kernel, you can configure it using the
+ * kernel command-line. For example:
+ *
+ * tipar=timeout,delay (set timeout and delay)
+ *
+ * If the driver is loaded as a module, similar functionality is available
+ * using module parameters. The equivalent of the above commands would be:
+ *
+ * # insmod tipar.o tipar=15,10
+ */
+
+/* COMPATIBILITY WITH OLD KERNELS
+ *
+ * Usually, parallel cables were bound to ports at
+ * particular I/O addresses, as follows:
+ *
+ * tipar0 0x378
+ * tipar1 0x278
+ * tipar2 0x3bc
+ *
+ *
+ * This driver, by default, binds tipar devices according to parport and
+ * the minor number.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/config.h>
+#include <linux/version.h>
+#include <linux/init.h>
+#include <asm/uaccess.h>
+#include <linux/ioport.h>
+#include <linux/errno.h>
+#include <linux/sched.h>
+#include <linux/fs.h>
+#include <asm/io.h>
+#include <linux/poll.h>
+#include <linux/devfs_fs_kernel.h>
+#include <linux/parport.h> /* Our code depend on parport */
+
+/*
+ * TI definitions
+ */
+#include <linux/ticable.h>
+
+/*
+ * Deal with CONFIG_MODVERSIONS
+ */
+#if 0 /* Pb with MODVERSIONS */
+#if CONFIG_MODVERSIONS==1
+#define MODVERSIONS
+#include <linux/modversions.h>
+#endif
+#endif
+
+/* ----- global variables --------------------------------------------- */
+
+struct tipar_struct {
+ struct pardevice *dev; /* Parport device entry */
+};
+
+#define PP_NO 3
+struct tipar_struct table[PP_NO];
+
+static int delay = IO_DELAY; /* inter-bit delay in microseconds */
+static int timeout = TIMAXTIME; /* timeout in tenth of seconds */
+
+static devfs_handle_t devfs_handle = NULL;
+static unsigned int tp_count = 0; /* tipar_count */
+
+/* --- macros for parport access -------------------------------------- */
+
+#define r_dtr(x) (parport_read_data(table[(x)].dev->port))
+#define r_str(x) (parport_read_status(table[(x)].dev->port))
+#define w_ctr(x,y) (parport_write_control(table[(x)].dev->port, (y)))
+#define w_dtr(x,y) (parport_write_data(table[(x)].dev->port, (y)))
+
+/* --- setting states on the D-bus with the right timing: ------------- */
+
+static inline void outbyte(int value, int minor)
+{
+ w_dtr(minor, value);
+}
+
+static inline int inbyte(int minor)
+{
+ return (r_str(minor) & 0x30);
+}
+
+static inline void init_ti_parallel(int minor)
+{
+ outbyte(3, minor);
+}
+
+/* ----- global defines ----------------------------------------------- */
+
+#define START(x) { max=jiffies+HZ/(timeout/10); }
+#define WAIT(x) { if(!time_before(jiffies, (x))) return -1; schedule(); }
+
+/* ----- D-bus bit-banging functions ---------------------------------- */
+
+/* D-bus protocol:
+ 1 0 0
+ _______ ______|______ __________|________ __________
+Red : ________ | ____ | ____
+ _ ____________|________ ______|__________ _____
+White: ________ | ______ | _______
+*/
+
+/* Try to transmit a byte on the specified port (-1 if error). */
+static int put_ti_parallel(int minor, unsigned char data)
+{
+ int bit, i;
+ unsigned long max;
+
+ for (bit=0; bit<8; bit++) {
+ if (data & 1) {
+ outbyte(2, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (inbyte(minor) & 0x10);
+
+ outbyte(3, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x10));
+ } else {
+ outbyte(1, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (inbyte(minor) & 0x20);
+
+ outbyte(3, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x20));
+ }
+ data >>= 1;
+ for(i=0; i < delay; i++) {
+ inbyte(minor);
+ }
+ schedule();
+ }
+
+ return 0;
+}
+
+/* Receive a byte on the specified port or -1 if error. */
+static int get_ti_parallel(int minor)
+{
+ int bit,i;
+ unsigned char v, data=0;
+ unsigned long max;
+
+ for (bit=0; bit<8; bit++) {
+ START(max);
+ do {
+ WAIT(max);
+ } while ((v=inbyte(minor) & 0x30) == 0x30);
+
+ if (v == 0x10) {
+ data=(data>>1) | 0x80;
+ outbyte(1, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x20));
+ outbyte(3, minor);
+ } else {
+ data=data>>1;
+ outbyte(2, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x10));
+ outbyte(3, minor);
+ }
+ for(i=0; i<delay; i++) {
+ inbyte(minor);
+ }
+ schedule();
+ }
+ return (int)data;
+}
+
+/* Return non zero if both lines are at logical one */
+static int check_ti_parallel(int minor)
+{
+ return ((inbyte(minor) & 0x30) == 0x30);
+}
+
+/* Try to detect a parallel link cable on the specified port */
+static int probe_ti_parallel(int minor)
+{
+ int i, j;
+ int seq[]={ 0x00, 0x20, 0x10, 0x30 };
+ unsigned char data = 0;
+
+ for(i=3; i>=0; i--) {
+ outbyte(3, minor);
+ outbyte(i, minor);
+ for(j=0; j<delay; j++) data = inbyte(minor);
+ /*printk("Probing -> %i: 0x%02x 0x%02x\n", i, data & 0x30,
seq[i]);*/
+ if( (data & 0x30) != seq[i]) {
+ outbyte(3, minor);
+ return -1;
+ }
+ }
+ outbyte(3, minor);
+ return 0;
+}
+
+/* ----- kernel module functions--------------------------------------- */
+
+static int tipar_open(struct inode *inode, struct file *file)
+{
+ unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+
+ if (minor >= PP_NO)
+ return -ENXIO;
+
+ init_ti_parallel(minor);
+
+ MOD_INC_USE_COUNT;
+
+ return 0;
+}
+
+static int tipar_close(struct inode *inode, struct file *file)
+{
+ MOD_DEC_USE_COUNT;
+
+ return 0;
+}
+
+static ssize_t tipar_write(struct file *file,
+ const char *buf, size_t count, loff_t *ppos)
+{
+ unsigned int minor = minor(file->f_dentry->d_inode->i_rdev) -
+ TIPAR_MINOR_0;
+ ssize_t n;
+
+ if (minor >= PP_NO)
+ return -ENXIO;
+
+ if (table[minor].dev == NULL)
+ return -ENXIO;
+
+ parport_claim_or_block (table[minor].dev);
+
+ for(n=0; n<count; n++) {
+ unsigned char b;
+
+ if(get_user(b, buf + n)) {
+ n = -EFAULT;
+ goto out;
+ }
+
+ if(put_ti_parallel(minor, b) == -1) {
+ init_ti_parallel(minor);
+ n = -ETIMEDOUT;
+ goto out;
+ }
+ }
+
+ out:
+ parport_release (table[minor].dev);
+ return n;
+}
+
+static ssize_t tipar_read(struct file *file, char *buf,
+ size_t count, loff_t *ppos)
+{
+ int b=0;
+ unsigned int minor=minor(file->f_dentry->d_inode->i_rdev) -
+ TIPAR_MINOR_0;
+ ssize_t retval = 0;
+
+ if(count == 0)
+ return 0;
+
+ if(ppos != &file->f_pos)
+ return -ESPIPE;
+
+ parport_claim_or_block(table[minor].dev);
+
+ do {
+ b = get_ti_parallel(minor);
+ if(b == -1) {
+ init_ti_parallel(minor);
+ retval = -ETIMEDOUT;
+ goto out;
+ }
+ else
+ break;
+
+ /* Non-blocking mode: try again ! */
+ if (file->f_flags & O_NONBLOCK) {
+ retval = -EAGAIN;
+ goto out;
+ }
+
+ /* Signal pending, try again ! */
+ if (signal_pending(current)) {
+ retval = -ERESTARTSYS;
+ goto out;
+ }
+
+ schedule();
+ } while (1);
+
+ retval = put_user(b, (unsigned char *)buf);
+ if(!retval)
+ retval = 1;
+ else
+ retval = -EFAULT;
+
+ out:
+ parport_release(table[minor].dev);
+ return retval;
+}
+
+static unsigned int tipar_poll(struct file *file, poll_table * wait)
+{
+ unsigned int mask=0;
+ return mask;
+}
+
+static int tipar_ioctl(struct inode *inode, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+ int retval = 0;
+
+ if (minor >= PP_NO)
+ return -ENODEV;
+
+ switch (cmd) {
+ case 0:
+ break;
+ case TIPAR_DELAY:
+ delay = arg;
+ return 0;
+ case TIPAR_TIMEOUT:
+ timeout = arg;
+ return 0;
+ case O_NONBLOCK:
+ file->f_flags |= O_NONBLOCK;
+ return 0;
+ default:
+ retval = -EINVAL;
+ break;
+ }
+
+ return retval;
+}
+
+static long long tipar_lseek(struct file * file, long long offset, int origin)
+{
+ return -ESPIPE;
+}
+
+
+/* ----- kernel module registering ------------------------------------ */
+
+static struct file_operations tipar_fops = {
+ owner: THIS_MODULE,
+ llseek: tipar_lseek,
+ read: tipar_read,
+ write: tipar_write,
+ poll: tipar_poll,
+ ioctl: tipar_ioctl,
+ open: tipar_open,
+ release: tipar_close,
+};
+
+/* --- initialisation code ------------------------------------- */
+
+#ifndef MODULE
+/* You must set these - there is no sane way to probe for this cable.
+ * You can use tipar=timeout,delay to set these now. */
+static int __init tipar_setup (char *str)
+{
+ int ints[2];
+
+ str = get_options (str, ARRAY_SIZE(ints), ints);
+
+ if (ints[0] > 0) {
+ timeout = ints[1];
+ if(ints[0] > 1) {
+ delay = ints[2];
+ }
+ }
+ return 1;
+}
+#endif
+
+/*
+ * Register our module into parport.
+ * Pass also 2 callbacks functions to parport: a pre-emptive function and an
+ * interrupt handler function (unused).
+ * Display a message such "tipar0: using parport0 (polling)".
+ */
+static int tipar_register(int nr, struct parport *port)
+{
+ char name[8];
+
+ /* Register our module into parport */
+ table[nr].dev = parport_register_device(port, "tipar",
+ NULL, NULL, NULL, 0,
+ (void *) &table[nr]);
+
+ if (table[nr].dev == NULL)
+ return 1;
+
+ /* Use devfs, tree: /dev/ticables/par/[0..2] */
+ sprintf(name, "%d", nr);
+ devfs_register(devfs_handle, name,
+ DEVFS_FL_AUTO_DEVNUM, TIPAR_MAJOR, nr,
+ S_IFCHR | S_IRUGO | S_IWUGO,
+ &tipar_fops, NULL);
+
+ /* Display informations */
+ printk(KERN_INFO "tipar%d: using %s (%s).\n", nr, port->name,
+ (port->irq == PARPORT_IRQ_NONE) ? "polling" :
"interrupt-driven");
+
+ if(probe_ti_parallel(nr) != -1)
+ printk("tipar%d: link cable found !\n", nr);
+ else
+ printk("tipar%d: link cable not found (do not plug cable to
calc).\n", nr);
+
+ return 0;
+}
+
+static void tipar_attach (struct parport *port)
+{
+ if (tp_count == PP_NO) {
+ printk("tipar: ignoring parallel port (max. %d)\n",
+ PP_NO);
+ return;
+ }
+ if (!tipar_register(tp_count, port))
+ tp_count++;
+}
+
+static void tipar_detach (struct parport *port)
+{
+ /* Will be written at some point in the future */
+}
+
+static struct parport_driver tipar_driver = {
+ "tipar",
+ tipar_attach,
+ tipar_detach,
+ NULL
+};
+
+int tipar_init(void)
+{
+ unsigned int i;
+
+ /* Initialize structure */
+ for (i = 0; i < PP_NO; i++) {
+ table[i].dev = NULL;
+ }
+
+ /* Register parport device */
+ if (devfs_register_chrdev (TIPAR_MAJOR, "tipar", &tipar_fops)) {
+ printk("tipar: unable to get major %d\n", TIPAR_MAJOR);
+ return -EIO;
+ }
+
+ /* Use devfs with tree: /dev/ticables/par/[0..2] */
+ devfs_handle = devfs_mk_dir (NULL, "ticables/par", NULL);
+
+ if (parport_register_driver (&tipar_driver)) {
+ printk ("tipar: unable to register with parport\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+int __init tipar_init_module(void)
+{
+ printk("tipar: parallel link cable driver, version %s\n", VERSION);
+ return tipar_init();
+}
+
+void __exit tipar_cleanup_module(void)
+{
+ unsigned int offset;
+
+ /* Unregistering module */
+ parport_unregister_driver (&tipar_driver);
+
+ devfs_unregister (devfs_handle);
+ devfs_unregister_chrdev(TIPAR_MAJOR, "tipar");
+
+ for (offset = 0; offset < PP_NO; offset++) {
+ if (table[offset].dev == NULL)
+ continue;
+ parport_unregister_device(table[offset].dev);
+ }
+}
+
+__setup("tipar=", tipar_setup);
+module_init(tipar_init_module);
+module_exit(tipar_cleanup_module);
+
+MODULE_AUTHOR("Author/Maintainer: Romain Lievin <roms@lpg.ticalc.org>");
+MODULE_DESCRIPTION("Device driver for TI/PC parallel link cables");
+MODULE_LICENSE("GPL");
+
+EXPORT_NO_SYMBOLS;
+
+MODULE_PARM(timeout, "i");
+MODULE_PARM_DESC(timeout, "Timeout, default=1.5 seconds");
+MODULE_PARM(delay, "i");
+MODULE_PARM_DESC(delay, "Inter-bit delay, default=10 microseconds");
--- linux.orig/include/linux/ticable.h Wed Mar 13 19:42:30 2002
+++ linux/include/linux/ticable.h Wed Mar 13 19:09:57 2002
@@ -0,0 +1,41 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar/tiser/tiglusb - low level driver for handling link cables
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#ifndef TICABLE_H
+#define TICABLE_H 1
+
+/* Internal default constants for the kernel module */
+#define TIMAXTIME 10 /* 1 seconds */
+#define IO_DELAY 10 /* 10 micro-seconds */
+
+/* Major & minor number for character devices */
+#define TIPAR_MAJOR 61
+#define TIPAR_MINOR_0 1
+#define TIPAR_MINOR_1 2
+#define TIPAR_MINOR_2 3
+
+#define TISER_MAJOR 62
+#define TISER_MINOR_0 1
+#define TISER_MINOR_1 2
+#define TISER_MINOR_2 3
+#define TISER_MINOR_3 4
+
+/*
+ * Request values for the 'ioctl' function.
+ * Simply pass the appropriate value as arg of the ioctl call.
+ * These values do not conflict with other ones but they have to be
+ * allocated... (/usr/src/linux/Documentation/ioctl-number.txt).
+ */
+#define TIPAR_DELAY _IOW('p', 0xa8, int) /* set delay */
+#define TIPAR_TIMEOUT _IOW('p', 0xa9, int) /* set timeout */
+
+#define TISER_DELAY _IOW('p', 0xa0, int) /* set delay */
+#define TISER_TIMEOUT _IOW('p', 0xa1, int) /* set timeout */
+
+#endif /* TICABLE_H */
--- linux.orig/drivers/char/Config.help Fri Mar 8 03:18:28 2002
+++ linux/drivers/char/Config.help Wed Mar 13 19:08:42 2002
@@ -595,6 +595,27 @@
If unsure, say N.
+CONFIG_TI_PAR
+ If you own a Texas Instruments graphing calculator and use a
+ parallel link cable, then you might be interested in this driver.
+
+ If you enable this driver, you will be able to communicate with
+ your calculator through a set of device nodes under /dev. The
+ main advantage of this driver is that you don't have to be root
+ to use this precise link cable (depending on the permissions on
+ the device nodes, though).
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called tipar.o. If you want to compile it as a
+ module, say M here and read Documentation/modules.txt.
+
+ If you don't know what a parallel link cable is or what a Texas
+ Instruments graphing calculator is, then you probably don't need this
+ driver.
+
+ If unsure, say N.
+
CONFIG_BUSMOUSE
Say Y here if your machine has a bus mouse as opposed to a serial
mouse. Most people have a regular serial MouseSystem or
--- linux.orig/drivers/char/Config.in Fri Mar 8 03:18:17 2002
+++ linux/drivers/char/Config.in Wed Mar 13 19:09:13 2002
@@ -103,6 +103,7 @@
bool ' Support for console on line printer' CONFIG_LP_CONSOLE
fi
dep_tristate 'Support for user-space parallel port device drivers'
CONFIG_PPDEV $CONFIG_PARPORT
+ dep_tristate 'Texas Instruments parallel link cable support' CONFIG_TI_PAR
$CONFIG_PARPORT
fi
source drivers/i2c/Config.in
--- linux.orig/drivers/char/Makefile Fri Mar 8 03:18:27 2002
+++ linux/drivers/char/Makefile Wed Mar 13 19:09:28 2002
@@ -16,7 +16,7 @@
O_TARGET := char.o
-obj-y += mem.o tty_io.o n_tty.o tty_ioctl.o raw.o pty.o misc.o random.o
+obj-y += mem.o tty_io.o n_tty.o tty_ioctl.o raw.o pty.o misc.o random.o
tipar.o
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
Romain.
---
Romain Liévin (aka roms)
http://lpg.ticalc.org/prj_tilp, prj_usb, prj_tidev, prj_gtktiemu
mail: roms@lpg.ticalc.org
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-03-13 19:21 Romain Liévin
@ 2002-03-13 19:43 ` Alan Cox
2002-03-13 20:28 ` Romain Liévin
2002-03-14 7:08 ` Zwane Mwaikambo
1 sibling, 1 reply; 669+ messages in thread
From: Alan Cox @ 2002-03-13 19:43 UTC (permalink / raw)
To: Romain Liévin; +Cc: Kernel List, Linus Torvalds, Alan Cox, Tim Waugh
> It has been tested on x86 for almost 2 years and on Alpha & Sparc too with
> various calculators.
One oddity - some other comments
> +static int tipar_open(struct inode *inode, struct file *file)
> +{
> + unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
> +
> + if (minor >= PP_NO)
> + return -ENXIO;
> +
> + init_ti_parallel(minor);
> +
> + MOD_INC_USE_COUNT;
You should remove these and use in 2.4 + . Also what stops multiple
simultaneous runs of init_ti_parallel if two people open it at once ?
> +static unsigned int tipar_poll(struct file *file, poll_table * wait)
> +{
> + unsigned int mask=0;
> + return mask;
> +}
That seems unfinished ??
> +static int tipar_ioctl(struct inode *inode, struct file *file,
> + unsigned int cmd, unsigned long arg)
> + case O_NONBLOCK:
> + file->f_flags |= O_NONBLOCK;
> + return 0;
O_NDELAY is set by fcntl - your driver never needs this.
> + default:
> + retval = -EINVAL;
SuS says -ENOTTY here (lots of drivers get this wrong still)
> +static long long tipar_lseek(struct file * file, long long offset, int origin)
> +{
> + return -ESPIPE;
> +}
There is a generic no_llseek function
> +/* Major & minor number for character devices */
> +#define TIPAR_MAJOR 61
These don't appear to be officially assigned via lanana ?
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-03-13 19:43 ` your mail Alan Cox
@ 2002-03-13 20:28 ` Romain Liévin
2002-03-13 20:49 ` Richard B. Johnson
2002-03-13 22:35 ` Alan Cox
0 siblings, 2 replies; 669+ messages in thread
From: Romain Liévin @ 2002-03-13 20:28 UTC (permalink / raw)
To: Alan Cox; +Cc: Kernel List
Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > It has been tested on x86 for almost 2 years and on Alpha & Sparc too
> with
> > various calculators.
>
> One oddity - some other comments
>
> > +static int tipar_open(struct inode *inode, struct file *file)
> > +{
> > + unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
> > +
> > + if (minor >= PP_NO)
> > + return -ENXIO;
> > +
> > + init_ti_parallel(minor);
> > +
> > + MOD_INC_USE_COUNT;
>
> You should remove these and use in 2.4 + . Also what stops multiple
> simultaneous runs of init_ti_parallel if two people open it at once ?
>
>
> > +static unsigned int tipar_poll(struct file *file, poll_table *
> wait)
> > +{
> > + unsigned int mask=0;
> > + return mask;
> > +}
>
> That seems unfinished ??
>
> > +static int tipar_ioctl(struct inode *inode, struct file *file,
> > + unsigned int cmd, unsigned long arg)
> > + case O_NONBLOCK:
> > + file->f_flags |= O_NONBLOCK;
> > + return 0;
>
> O_NDELAY is set by fcntl - your driver never needs this.
>
> > + default:
> > + retval = -EINVAL;
>
> SuS says -ENOTTY here (lots of drivers get this wrong still)
>
> > +static long long tipar_lseek(struct file * file, long long offset,
> int origin)
> > +{
> > + return -ESPIPE;
> > +}
>
> There is a generic no_llseek function
>
> > +/* Major & minor number for character devices */
> > +#define TIPAR_MAJOR 61
>
> These don't appear to be officially assigned via lanana ?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Fixed some stuffs according to your remarks.
Comments are welcome...
=================== [ cuts here ] =====================
--- linux.orig/drivers/char/tipar.c Wed Mar 13 19:19:10 2002
+++ linux/drivers/char/tipar.c Wed Mar 13 21:24:51 2002
@@ -0,0 +1,543 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar - low level driver for handling a parallel link cable
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#define VERSION "1.12"
+
+/* This driver should, in theory, work with any parallel port that has an
+ * appropriate low-level driver; all I/O is done through the parport
+ * abstraction layer.
+ *
+ * If this driver is built into the kernel, you can configure it using the
+ * kernel command-line. For example:
+ *
+ * tipar=timeout,delay (set timeout and delay)
+ *
+ * If the driver is loaded as a module, similar functionality is available
+ * using module parameters. The equivalent of the above commands would be:
+ *
+ * # insmod tipar.o tipar=15,10
+ */
+
+/* COMPATIBILITY WITH OLD KERNELS
+ *
+ * Usually, parallel cables were bound to ports at
+ * particular I/O addresses, as follows:
+ *
+ * tipar0 0x378
+ * tipar1 0x278
+ * tipar2 0x3bc
+ *
+ *
+ * This driver, by default, binds tipar devices according to parport and
+ * the minor number.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/config.h>
+#include <linux/version.h>
+#include <linux/init.h>
+#include <asm/uaccess.h>
+#include <linux/ioport.h>
+#include <linux/errno.h>
+#include <linux/sched.h>
+#include <linux/fs.h>
+#include <asm/io.h>
+#include <linux/devfs_fs_kernel.h>
+#include <linux/parport.h> /* Our code depend on parport */
+
+/*
+ * TI definitions
+ */
+#include <linux/ticable.h>
+
+/*
+ * Deal with CONFIG_MODVERSIONS
+ */
+#if 0 /* Pb with MODVERSIONS */
+#if CONFIG_MODVERSIONS==1
+#define MODVERSIONS
+#include <linux/modversions.h>
+#endif
+#endif
+
+/* ----- global variables --------------------------------------------- */
+
+struct tipar_struct {
+ struct pardevice *dev; /* Parport device entry */
+ int opened;
+};
+
+#define PP_NO 3
+struct tipar_struct table[PP_NO];
+
+static int delay = IO_DELAY; /* inter-bit delay in microseconds */
+static int timeout = TIMAXTIME; /* timeout in tenth of seconds */
+
+static devfs_handle_t devfs_handle = NULL;
+static unsigned int tp_count = 0; /* tipar_count */
+
+/* --- macros for parport access -------------------------------------- */
+
+#define r_dtr(x) (parport_read_data(table[(x)].dev->port))
+#define r_str(x) (parport_read_status(table[(x)].dev->port))
+#define w_ctr(x,y) (parport_write_control(table[(x)].dev->port, (y)))
+#define w_dtr(x,y) (parport_write_data(table[(x)].dev->port, (y)))
+
+/* --- setting states on the D-bus with the right timing: ------------- */
+
+static inline void outbyte(int value, int minor)
+{
+ w_dtr(minor, value);
+}
+
+static inline int inbyte(int minor)
+{
+ return (r_str(minor) & 0x30);
+}
+
+static inline void init_ti_parallel(int minor)
+{
+ outbyte(3, minor);
+}
+
+/* ----- global defines ----------------------------------------------- */
+
+#define START(x) { max=jiffies+HZ/(timeout/10); }
+#define WAIT(x) { if(!time_before(jiffies, (x))) return -1; schedule(); }
+
+/* ----- D-bus bit-banging functions ---------------------------------- */
+
+/* D-bus protocol:
+ 1 0 0
+ _______ ______|______ __________|________ __________
+Red : ________ | ____ | ____
+ _ ____________|________ ______|__________ _____
+White: ________ | ______ | _______
+*/
+
+/* Try to transmit a byte on the specified port (-1 if error). */
+static int put_ti_parallel(int minor, unsigned char data)
+{
+ int bit, i;
+ unsigned long max;
+
+ for (bit=0; bit<8; bit++) {
+ if (data & 1) {
+ outbyte(2, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (inbyte(minor) & 0x10);
+
+ outbyte(3, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x10));
+ } else {
+ outbyte(1, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (inbyte(minor) & 0x20);
+
+ outbyte(3, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x20));
+ }
+ data >>= 1;
+ for(i=0; i < delay; i++) {
+ inbyte(minor);
+ }
+ schedule();
+ }
+
+ return 0;
+}
+
+/* Receive a byte on the specified port or -1 if error. */
+static int get_ti_parallel(int minor)
+{
+ int bit,i;
+ unsigned char v, data=0;
+ unsigned long max;
+
+ for (bit=0; bit<8; bit++) {
+ START(max);
+ do {
+ WAIT(max);
+ } while ((v=inbyte(minor) & 0x30) == 0x30);
+
+ if (v == 0x10) {
+ data=(data>>1) | 0x80;
+ outbyte(1, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x20));
+ outbyte(3, minor);
+ } else {
+ data=data>>1;
+ outbyte(2, minor);
+ START(max);
+ do {
+ WAIT(max);
+ } while (!(inbyte(minor) & 0x10));
+ outbyte(3, minor);
+ }
+ for(i=0; i<delay; i++) {
+ inbyte(minor);
+ }
+ schedule();
+ }
+ return (int)data;
+}
+
+/* Return non zero if both lines are at logical one */
+static int check_ti_parallel(int minor)
+{
+ return ((inbyte(minor) & 0x30) == 0x30);
+}
+
+/* Try to detect a parallel link cable on the specified port */
+static int probe_ti_parallel(int minor)
+{
+ int i, j;
+ int seq[]={ 0x00, 0x20, 0x10, 0x30 };
+ unsigned char data = 0;
+
+ for(i=3; i>=0; i--) {
+ outbyte(3, minor);
+ outbyte(i, minor);
+ for(j=0; j<delay; j++) data = inbyte(minor);
+ /*printk("Probing -> %i: 0x%02x 0x%02x\n", i, data & 0x30,
seq[i]);*/
+ if( (data & 0x30) != seq[i]) {
+ outbyte(3, minor);
+ return -1;
+ }
+ }
+ outbyte(3, minor);
+ return 0;
+}
+
+/* ----- kernel module functions--------------------------------------- */
+
+static int tipar_open(struct inode *inode, struct file *file)
+{
+ unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+
+ if (minor >= PP_NO)
+ return -ENXIO;
+
+ if(table[minor].opened)
+ return -EBUSY;
+
+ table[minor].opened++;
+
+ lp_claim_parport_or_block(table[minor].dev);
+ init_ti_parallel(minor);
+ lp_release_parport(table[minor].dev);
+
+ return 0;
+}
+
+static int tipar_close(struct inode *inode, struct file *file)
+{
+ if (minor >= PP_NO)
+ return -ENXIO;
+
+ if(!table[minor].opened)
+ return -EFAULT;
+
+ table[minor].opened--;
+
+ return 0;
+}
+
+static ssize_t tipar_write(struct file *file,
+ const char *buf, size_t count, loff_t *ppos)
+{
+ unsigned int minor = minor(file->f_dentry->d_inode->i_rdev) -
+ TIPAR_MINOR_0;
+ ssize_t n;
+
+ if (minor >= PP_NO)
+ return -ENXIO;
+
+ if (table[minor].dev == NULL)
+ return -ENXIO;
+
+ parport_claim_or_block (table[minor].dev);
+
+ for(n=0; n<count; n++) {
+ unsigned char b;
+
+ if(get_user(b, buf + n)) {
+ n = -EFAULT;
+ goto out;
+ }
+
+ if(put_ti_parallel(minor, b) == -1) {
+ init_ti_parallel(minor);
+ n = -ETIMEDOUT;
+ goto out;
+ }
+ }
+
+ out:
+ parport_release (table[minor].dev);
+ return n;
+}
+
+static ssize_t tipar_read(struct file *file, char *buf,
+ size_t count, loff_t *ppos)
+{
+ int b=0;
+ unsigned int minor=minor(file->f_dentry->d_inode->i_rdev) -
+ TIPAR_MINOR_0;
+ ssize_t retval = 0;
+
+ if(count == 0)
+ return 0;
+
+ if(ppos != &file->f_pos)
+ return -ESPIPE;
+
+ parport_claim_or_block(table[minor].dev);
+
+ do {
+ b = get_ti_parallel(minor);
+ if(b == -1) {
+ init_ti_parallel(minor);
+ retval = -ETIMEDOUT;
+ goto out;
+ }
+ else
+ break;
+
+ /* Non-blocking mode: try again ! */
+ if (file->f_flags & O_NONBLOCK) {
+ retval = -EAGAIN;
+ goto out;
+ }
+
+ /* Signal pending, try again ! */
+ if (signal_pending(current)) {
+ retval = -ERESTARTSYS;
+ goto out;
+ }
+
+ schedule();
+ } while (1);
+
+ retval = put_user(b, (unsigned char *)buf);
+ if(!retval)
+ retval = 1;
+ else
+ retval = -EFAULT;
+
+ out:
+ parport_release(table[minor].dev);
+ return retval;
+}
+
+static int tipar_ioctl(struct inode *inode, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+ int retval = 0;
+
+ if (minor >= PP_NO)
+ return -ENODEV;
+
+ switch (cmd) {
+ case 0:
+ break;
+ case TIPAR_DELAY:
+ delay = arg;
+ return 0;
+ case TIPAR_TIMEOUT:
+ timeout = arg;
+ return 0;
+ default:
+ retval = -ENOTTY;
+ break;
+ }
+
+ return retval;
+}
+
+static long long tipar_lseek(struct file * file, long long offset, int origin)
+{
+ return -ESPIPE;
+}
+
+
+/* ----- kernel module registering ------------------------------------ */
+
+static struct file_operations tipar_fops = {
+ owner: THIS_MODULE,
+ llseek: no_llseek,
+ read: tipar_read,
+ write: tipar_write,
+ ioctl: tipar_ioctl,
+ open: tipar_open,
+ release: tipar_close,
+};
+
+/* --- initialisation code ------------------------------------- */
+
+#ifndef MODULE
+/* You must set these - there is no sane way to probe for this cable.
+ * You can use tipar=timeout,delay to set these now. */
+static int __init tipar_setup (char *str)
+{
+ int ints[2];
+
+ str = get_options (str, ARRAY_SIZE(ints), ints);
+
+ if (ints[0] > 0) {
+ timeout = ints[1];
+ if(ints[0] > 1) {
+ delay = ints[2];
+ }
+ }
+ return 1;
+}
+#endif
+
+/*
+ * Register our module into parport.
+ * Pass also 2 callbacks functions to parport: a pre-emptive function and an
+ * interrupt handler function (unused).
+ * Display a message such "tipar0: using parport0 (polling)".
+ */
+static int tipar_register(int nr, struct parport *port)
+{
+ char name[8];
+
+ /* Register our module into parport */
+ table[nr].dev = parport_register_device(port, "tipar",
+ NULL, NULL, NULL, 0,
+ (void *) &table[nr]);
+
+ if (table[nr].dev == NULL)
+ return 1;
+
+ /* Use devfs, tree: /dev/ticables/par/[0..2] */
+ sprintf(name, "%d", nr);
+ devfs_register(devfs_handle, name,
+ DEVFS_FL_AUTO_DEVNUM, TIPAR_MAJOR, nr,
+ S_IFCHR | S_IRUGO | S_IWUGO,
+ &tipar_fops, NULL);
+
+ /* Display informations */
+ printk(KERN_INFO "tipar%d: using %s (%s).\n", nr, port->name,
+ (port->irq == PARPORT_IRQ_NONE) ? "polling" :
"interrupt-driven");
+
+ if(probe_ti_parallel(nr) != -1)
+ printk("tipar%d: link cable found !\n", nr);
+ else
+ printk("tipar%d: link cable not found (do not plug cable to
calc).\n", nr);
+
+ return 0;
+}
+
+static void tipar_attach (struct parport *port)
+{
+ if (tp_count == PP_NO) {
+ printk("tipar: ignoring parallel port (max. %d)\n",
+ PP_NO);
+ return;
+ }
+ if (!tipar_register(tp_count, port))
+ tp_count++;
+}
+
+static void tipar_detach (struct parport *port)
+{
+ /* Will be written at some point in the future */
+}
+
+static struct parport_driver tipar_driver = {
+ "tipar",
+ tipar_attach,
+ tipar_detach,
+ NULL
+};
+
+int tipar_init(void)
+{
+ unsigned int i;
+
+ /* Initialize structure */
+ for (i = 0; i < PP_NO; i++) {
+ table[i].dev = NULL;
+ table[i].opened = 0;
+ }
+
+ /* Register parport device */
+ if (devfs_register_chrdev (TIPAR_MAJOR, "tipar", &tipar_fops)) {
+ printk("tipar: unable to get major %d\n", TIPAR_MAJOR);
+ return -EIO;
+ }
+
+ /* Use devfs with tree: /dev/ticables/par/[0..2] */
+ devfs_handle = devfs_mk_dir (NULL, "ticables/par", NULL);
+
+ if (parport_register_driver (&tipar_driver)) {
+ printk ("tipar: unable to register with parport\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+int __init tipar_init_module(void)
+{
+ printk("tipar: parallel link cable driver, version %s\n", VERSION);
+ return tipar_init();
+}
+
+void __exit tipar_cleanup_module(void)
+{
+ unsigned int offset;
+
+ /* Unregistering module */
+ parport_unregister_driver (&tipar_driver);
+
+ devfs_unregister (devfs_handle);
+ devfs_unregister_chrdev(TIPAR_MAJOR, "tipar");
+
+ for (offset = 0; offset < PP_NO; offset++) {
+ if (table[offset].dev == NULL)
+ continue;
+ parport_unregister_device(table[offset].dev);
+ }
+}
+
+__setup("tipar=", tipar_setup);
+module_init(tipar_init_module);
+module_exit(tipar_cleanup_module);
+
+MODULE_AUTHOR("Author/Maintainer: Romain Lievin <roms@lpg.ticalc.org>");
+MODULE_DESCRIPTION("Device driver for TI/PC parallel link cables");
+MODULE_LICENSE("GPL");
+
+EXPORT_NO_SYMBOLS;
+
+MODULE_PARM(timeout, "i");
+MODULE_PARM_DESC(timeout, "Timeout, default=1.5 seconds");
+MODULE_PARM(delay, "i");
+MODULE_PARM_DESC(delay, "Inter-bit delay, default=10 microseconds");
--- linux.orig/include/linux/ticable.h Wed Mar 13 19:42:30 2002
+++ linux/include/linux/ticable.h Wed Mar 13 21:25:03 2002
@@ -0,0 +1,41 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar/tiser/tiglusb - low level driver for handling link cables
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#ifndef TICABLE_H
+#define TICABLE_H 1
+
+/* Internal default constants for the kernel module */
+#define TIMAXTIME 10 /* 1 seconds */
+#define IO_DELAY 10 /* 10 micro-seconds */
+
+/* Major & minor number for character devices */
+#define TIPAR_MAJOR 61
+#define TIPAR_MINOR_0 1
+#define TIPAR_MINOR_1 2
+#define TIPAR_MINOR_2 3
+
+#define TISER_MAJOR 62
+#define TISER_MINOR_0 1
+#define TISER_MINOR_1 2
+#define TISER_MINOR_2 3
+#define TISER_MINOR_3 4
+
+/*
+ * Request values for the 'ioctl' function.
+ * Simply pass the appropriate value as arg of the ioctl call.
+ * These values do not conflict with other ones but they have to be
+ * allocated... (/usr/src/linux/Documentation/ioctl-number.txt).
+ */
+#define TIPAR_DELAY _IOW('p', 0xa8, int) /* set delay */
+#define TIPAR_TIMEOUT _IOW('p', 0xa9, int) /* set timeout */
+
+#define TISER_DELAY _IOW('p', 0xa0, int) /* set delay */
+#define TISER_TIMEOUT _IOW('p', 0xa1, int) /* set timeout */
+
+#endif /* TICABLE_H */
Romain.
---
Romain Liévin (aka roms)
http://lpg.ticalc.org/prj_tilp, prj_usb, prj_tidev, prj_gtktiemu
mail: roms@lpg.ticalc.org
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-03-13 20:28 ` Romain Liévin
@ 2002-03-13 20:49 ` Richard B. Johnson
2002-03-13 22:27 ` Alan Cox
2002-03-13 22:35 ` Alan Cox
1 sibling, 1 reply; 669+ messages in thread
From: Richard B. Johnson @ 2002-03-13 20:49 UTC (permalink / raw)
To: Romain Liévin; +Cc: Alan Cox, Kernel List
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 4611 bytes --]
On Wed, 13 Mar 2002, [ISO-8859-1] Romain Liévin wrote:
I'm going to comment on a few points:
[SNIPPED most...]
> +
> +/* D-bus protocol:
> + 1 0 0
> + _______ ______|______ __________|________ __________
> +Red : ________ | ____ | ____
> + _ ____________|________ ______|__________ _____
> +White: ________ | ______ | _______
> +*/
> +
> +/* Try to transmit a byte on the specified port (-1 if error). */
> +static int put_ti_parallel(int minor, unsigned char data)
> +{
> + int bit, i;
> + unsigned long max;
> +
> + for (bit=0; bit<8; bit++) {
> + if (data & 1) {
> + outbyte(2, minor);
> + START(max);
> + do {
> + WAIT(max);
> + } while (inbyte(minor) & 0x10);
This may never happen. You end up waiting forever!
If the port doesn't exist or is broken, it may return 0xff
forever! You need to time-out and get out.
> +
> + outbyte(3, minor);
> + START(max);
> + do {
> + WAIT(max);
> + } while (!(inbyte(minor) & 0x10));
This may never happen. You end up awiting forever!
You need to time-out and get out.
> + } else {
> + outbyte(1, minor);
> + START(max);
> + do {
> + WAIT(max);
> + } while (inbyte(minor) & 0x20);
> +
This also may never happen!
Same applies, time-out and get out.
> + outbyte(3, minor);
> + START(max);
> + do {
> + WAIT(max);
> + } while (!(inbyte(minor) & 0x20));
This also may never happen!
Same applives, time-out and get out.
> + }
> + data >>= 1;
> + for(i=0; i < delay; i++) {
> + inbyte(minor);
> + }
> + schedule();
This will just spin without setting
current->policy |= SCHED_YIELD;
(you really should use sys_sched_yield())
> + }
> +
> + return 0;
> +}
> +
> +/* Receive a byte on the specified port or -1 if error. */
> +static int get_ti_parallel(int minor)
> +{
> + int bit,i;
> + unsigned char v, data=0;
> + unsigned long max;
> +
> + for (bit=0; bit<8; bit++) {
> + START(max);
> + do {
> + WAIT(max);
> + } while ((v=inbyte(minor) & 0x30) == 0x30);
> +
More wait-forever above...
> + if (v == 0x10) {
> + data=(data>>1) | 0x80;
> + outbyte(1, minor);
> + START(max);
> + do {
> + WAIT(max);
> + } while (!(inbyte(minor) & 0x20));
More wait-forever above.
> + outbyte(3, minor);
> + } else {
> + data=data>>1;
> + outbyte(2, minor);
> + START(max);
> + do {
> + WAIT(max);
> + } while (!(inbyte(minor) & 0x10));
> + outbyte(3, minor);
More wait-forever!
> + }
> + for(i=0; i<delay; i++) {
> + inbyte(minor);
> + }
> + schedule();
No current->policy
> + }
> + return (int)data;
> +}
> +
[SNIPPED rest]
Basically, this code performs a needed function. I have been waiting
for someone to write this! However, it's not yet ready for prime-time.
Never assume that hardware is going to produce what you expect. Don't
wait forever for something that was supposed to happen. You'll hang
the machine.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-03-13 20:28 ` Romain Liévin
2002-03-13 20:49 ` Richard B. Johnson
@ 2002-03-13 22:35 ` Alan Cox
1 sibling, 0 replies; 669+ messages in thread
From: Alan Cox @ 2002-03-13 22:35 UTC (permalink / raw)
To: Romain Liévin; +Cc: Alan Cox, Kernel List
> +/*
> + * Deal with CONFIG_MODVERSIONS
> + */
> +#if 0 /* Pb with MODVERSIONS */
> +#if CONFIG_MODVERSIONS==1
> +#define MODVERSIONS
> +#include <linux/modversions.h>
> +#endif
> +#endif
[modversions.h is magically included by the kernel for you when its in
kernel if you haven't worked that one out yet]
> +#define PP_NO 3
> +struct tipar_struct table[PP_NO];
static ?
> + for(i=0; i < delay; i++) {
> + inbyte(minor);
> + }
> + schedule();
Oh random tip
if(current->need_resched)
schedule();
will just give up the CPU when you are out of time
> + if(table[minor].opened)
> + return -EBUSY;
> + table[minor].opened++;
Think about open/close at the same moment or SMP - the watchdog drivers all
had this problem and now do
unsigned long opened = 0;
if(test_and_set_bit(0, &opened))
return -EBUSY;
clear_bit(0, &opened)
[this generates atomic operations so is always safe]
> + if(!table[minor].opened)
> + return -EFAULT;
BUG() may be better - it can't happen so BUG() will get a backtrace
and actually get it reported 8)
> +static long long tipar_lseek(struct file * file, long long offset, int origin)
> +{
> + return -ESPIPE;
> +}
Can go (you now use no_llseek)
Basically except for the open/close one I'm now just picking holes.
For the device major/minors see http://www.lanana.org.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-03-13 19:21 Romain Liévin
2002-03-13 19:43 ` your mail Alan Cox
@ 2002-03-14 7:08 ` Zwane Mwaikambo
1 sibling, 0 replies; 669+ messages in thread
From: Zwane Mwaikambo @ 2002-03-14 7:08 UTC (permalink / raw)
To: Romain Liévin; +Cc: Kernel List, Alan Cox, Tim Waugh
Firstly, thanks for doing this =) secondly i'll give your driver a try
when you release the serial version (i have a serial cable + TI-83)
Cheers,
Zwane
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-03-10 9:39 Samarth Sharma
2002-03-11 14:07 ` your mail Stephen Smalley
0 siblings, 1 reply; 669+ messages in thread
From: Samarth Sharma @ 2002-03-10 9:39 UTC (permalink / raw)
To: SELinux
ok i need answers to these questions :
1.On login i get the following message :
[ avc: denied {write} for pid=647 exe=/bin/login
path=/var/log/wtmp dev=03:07 ino=182350
scontext=system_u:system_r:local_login_t
tcontext=system_u:object_r:cron_log_t tclass=file ]
what does this mean and how can i get around it.
i get similar messages while loading 'atd'.
2.Can u give me a specific example where SElinux is able to solve
a security flaw in normal Linux
3.i tried loading the selinux kernel on an amd machine.
however the machine keeps rebooting immediately after the lilo
screen. Linux 7.1 (redhat) runs fine on this machine.
4.how do u add a user to the system. i added a new user in the
../policy/users file with appropriate context and compiled the
policy but security context for that user was not initialized.
thanks,
Samarth Sharma
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-03-10 9:39 Samarth Sharma
@ 2002-03-11 14:07 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2002-03-11 14:07 UTC (permalink / raw)
To: Samarth Sharma; +Cc: SELinux
On 10 Mar 2002, Samarth Sharma wrote:
> 1.On login i get the following message :
> [ avc: denied {write} for pid=647 exe=/bin/login
> path=/var/log/wtmp dev=03:07 ino=182350
> scontext=system_u:system_r:local_login_t
> tcontext=system_u:object_r:cron_log_t tclass=file ]
> what does this mean and how can i get around it.
> i get similar messages while loading 'atd'.
This indicates that your /var/log/wtmp file has the wrong security context
(system_u:object_r:cron_log_t rather than system_u:object_r:wtmp_t).
Run 'make verbose' in your setfiles directory after logging into the
sysadm_r role and sysadm_t domain to ensure that all of your file security
contexts are set properly. You should have done this originally as step
15 of the README after you first booted SELinux. You still need to figure
out why this happened to prevent a recurrence. Some possible
explanations:
1) You have a cron job set up to rotate wtmp (and other log files) using
something other than the SELinux-modified logrotate program. The
SELinux-modified logrotate program ensures that rotated files retain the
security context of the original file. If you are rotating wtmp in some
other way, then it will pick up the cron_log_t type by default, as noted
by Russell Coker. In this case, you need to ensure that you preserve
security contexts on log files when you rotate them.
2) You've switched back-and-forth between running an ordinary Linux kernel
and the SELinux kernel, and the wtmp file was re-created (possibly
rotated) while running the ordinary Linux kernel. In this case, it is
sufficient to run 'make verbose' in the setfiles directory to ensure that
the file security contexts are set properly.
> 2.Can u give me a specific example where SElinux is able to solve
> a security flaw in normal Linux
I'd suggest reading the FAQ (esp. question #2,
http://www.nsa.gov/selinux/faq.html#l2) and the two published papers
about SELinux from http://www.nsa.gov/selinux/docs.html.
The Inevitability of Failure background paper
(http://www.nsa.gov/selinux/inevit-abs.html) provides a good explanation
of why mandatory access controls are necessary in general. Two simple
examples are confining malicious mobile code that exploits a flaw in your
web browser and confining an exploit of a flaw in apache, bind, sendmail,
or any other system service.
> 3.i tried loading the selinux kernel on an amd machine.
> however the machine keeps rebooting immediately after the lilo
> screen. Linux 7.1 (redhat) runs fine on this machine.
Make sure that you set up your Processor type and features correctly in
the kernel configuration before building the SELinux kernel. You could
try using the default RedHat kernel configuration from the RedHat SRPM
with just a few alterations for the SELinux-related options.
> 4.how do u add a user to the system. i added a new user in the
> ../policy/users file with appropriate context and compiled the
> policy but security context for that user was not initialized.
You also need to update the /etc/security/default_context and
/etc/security/cron_context files to define default login and cron job
security contexts for the user. These files will become obsolete pending
some ongoing work, so at some point, you will only need to update
policy/users. Also, we've merged support for a generic unprivileged user
that will show up in the next public release, so you will no longer need
to update any of these files if the new user only requires unprivileged
access and does not need to be separated from other such users by the
policy.
--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-02-28 13:58 shura
2002-03-01 15:30 ` your mail Jan-Marek Glogowski
0 siblings, 1 reply; 669+ messages in thread
From: shura @ 2002-02-28 13:58 UTC (permalink / raw)
To: linux-kernel
I'm setting up a new machine with a pair of IDE drives connected to
HPT 370 controller. I defined a RAID-1 array using the HPT370 bios
setting utility.
Description - hard:
motherboard Abit ST6-RAID, HPT370, 2 identical hard disks as
primary/secondary master on ide3/ide4
- bios:
Primary Master: Mirror (Raid 1) for Array #0 UDMA 5 78150 BOOT
Primary Slave: No drive
Secondary Master: Mirror (Raid 1) for Array #0 UDMA 5 78150 HIDDEEN
Secondary Slave: No drive
- os:
Linux RedHat 7.1 & kernel 2.4.17
with compilation option
CONFIG_BLK_DEV_ATARAID_HPT=y
Lilo:
...
root=/dev/hde10
...
During system booting i see following
...
ataraid/d0: ataraid/d0p1 ataraid/d0p2 ataraid/d0p3 ataraid/d0p4 <>
Highpoint HPT370 Softwareraid driver for linux version 0.01
Drive 0 is 76319 Mb
Drive 6 is 76319 Mb
Raid array consists of 2 drivers
...
Kernel panic: VFS: Unable to mount root fs on 21:0a
...
And system stop
Booting with option root=/dev/atarad/d0p1 ro
(or root=/dev/ataraid/d0p10 ro)
and etc - no effect
Any hints?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-28 13:58 shura
@ 2002-03-01 15:30 ` Jan-Marek Glogowski
0 siblings, 0 replies; 669+ messages in thread
From: Jan-Marek Glogowski @ 2002-03-01 15:30 UTC (permalink / raw)
To: shura; +Cc: linux-kernel
Hi
> I'm setting up a new machine with a pair of IDE drives connected to
> HPT 370 controller. I defined a RAID-1 array using the HPT370 bios
> setting utility.
> Description - hard:
> motherboard Abit ST6-RAID, HPT370, 2 identical hard disks as
> primary/secondary master on ide3/ide4
> - bios:
> Primary Master: Mirror (Raid 1) for Array #0 UDMA 5 78150 BOOT
> Primary Slave: No drive
> Secondary Master: Mirror (Raid 1) for Array #0 UDMA 5 78150 HIDDEEN
> Secondary Slave: No drive
> - os:
> Linux RedHat 7.1 & kernel 2.4.17
> with compilation option
> CONFIG_BLK_DEV_ATARAID_HPT=y
> Lilo:
> ...
> root=/dev/hde10
The root should be /dev/ataraid/xxx for any ata raid but that is not the
real problem...
> During system booting i see following
> ...
> ataraid/d0: ataraid/d0p1 ataraid/d0p2 ataraid/d0p3 ataraid/d0p4 <>
> Highpoint HPT370 Softwareraid driver for linux version 0.01
> Drive 0 is 76319 Mb
> Drive 6 is 76319 Mb
> Raid array consists of 2 drivers
> ...
> Kernel panic: VFS: Unable to mount root fs on 21:0a
> ...
Ataraid seems to find four partitions d0p[1234]. But as far as I know
mirroring isn't supported by the in kernel open source drivers at all -
you may look at the closed source drivers at www.highpoint-tech.com, if
you really need the "hpt native" raid.
(http://people.redhat.com/arjanv/pdcraid/ataraidhowto.html)
> Booting with option root=/dev/atarad/d0p1 ro
> (or root=/dev/ataraid/d0p10 ro)
> and etc - no effect
If you just just use need to access the harddisks from linux it is
suggested to use linux software raid (there was a discussion at lkml - if
I remember right). On modern PCs it uses < 5% CPU and is faster, as it
operates high level in the kernel, not right before the hardware, as those
"big software part, small hardware part" raid controller from Promise and
Highpoint do.
HTH
Jan-Marek
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-02-27 19:02 Metrix
2002-02-27 19:33 ` your mail Stephen Smalley
0 siblings, 1 reply; 669+ messages in thread
From: Metrix @ 2002-02-27 19:02 UTC (permalink / raw)
To: selinux
with selinux is it possible to say make a file or
directory unable to be viewed, deleted or moved, or
even altered, the ONLY operation allowed is
appending....is this possible to implement with
selinux?
i am a bit unsure oh what MAC and such is, is there a
guide somewhere that clearly explains it?
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-27 19:02 Metrix
@ 2002-02-27 19:33 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2002-02-27 19:33 UTC (permalink / raw)
To: Metrix; +Cc: selinux
On Wed, 27 Feb 2002, Metrix wrote:
> with selinux is it possible to say make a file or
> directory unable to be viewed, deleted or moved, or
> even altered, the ONLY operation allowed is
> appending....is this possible to implement with
> selinux?
You can certainly define a type, only grant append permission to it in
the policy configuration, and label a file with it.
> i am a bit unsure oh what MAC and such is, is there a
> guide somewhere that clearly explains it?
I'd suggest reading the papers available from
http://www.nsa.gov/selinux/docs.html.
--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-02-27 11:31 Metrix
2002-02-27 13:36 ` your mail Stephen Smalley
0 siblings, 1 reply; 669+ messages in thread
From: Metrix @ 2002-02-27 11:31 UTC (permalink / raw)
To: selinux
Hey people, just wanted to compliment you on the good
job, I will actualy be using RSBAC as it suits my
needs a bit better...
My question is, what are the diferences of RSBAC
[rsbac.org] and SELinux from a technical standpoint?
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-27 11:31 Metrix
@ 2002-02-27 13:36 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2002-02-27 13:36 UTC (permalink / raw)
To: Metrix; +Cc: selinux
On Wed, 27 Feb 2002, Metrix wrote:
> Hey people, just wanted to compliment you on the good
> job, I will actualy be using RSBAC as it suits my
> needs a bit better...
>
> My question is, what are the diferences of RSBAC
> [rsbac.org] and SELinux from a technical standpoint?
This has been previously discussed on the mailing list, and is also
summarized in the related work section of the Freenix '01 paper. The
mailing list thread starts at
http://marc.theaimsgroup.com/?l=selinux&m=98618795624462&w=2 and the
Freenix '01 paper is available at
http://www.nsa.gov/selinux/freenix01-abs.html.
--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-02-25 1:41 Rusty Russell
2002-02-25 1:58 ` your mail Alexander Viro
2002-02-25 13:16 ` Alan Cox
0 siblings, 2 replies; 669+ messages in thread
From: Rusty Russell @ 2002-02-25 1:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: mingo, Matthew Kirkwood, Benjamin LaHaise, David Axmark,
William Lee Irwin III, linux-kernel
Subject: Re: [PATCH] Lightweight userspace semaphores...
In-reply-to: Your message of "Sun, 24 Feb 2002 17:23:59 -0800."
<Pine.LNX.4.33.0202241719330.1420-100000@home.transmeta.com>
In message <Pine.LNX.4.33.0202241719330.1420-100000@home.transmeta.com> you wri
te:
>
>
> On Mon, 25 Feb 2002, Rusty Russell wrote:
> >
> > Bugger. How about:
> >
> > sys_sem_area(void *pagestart, size_t len)
> > sys_unsem_area(void *pagestart, size_t len)
> >
> > Is that sufficient? Is sys_unsem_area required at all?
>
> The above is sufficient, but I would personally actually prefer an
> interface more like
>
> fd = sem_initialize();
> mmap(fd, ...)
> ..
> munmap(..)
>
> which gives you a handle for the semaphore.
No no no! Implemented exactly that (and posted to l-k IIRC), and it's
*horrible* to use.
> Note that getting a file descriptor is really quite useful - it means that
> you can pass the file descriptor around through unix domain sockets, for
> example, and allow sharing of the semaphore across unrelated processes
> that way.
First, fd passing sucks: you can't leave an fd somewhere and wait for
someone to pick it up, and they vanish when you exit. Secondly, you
have some arbitrary limit on the number of semaphores. Thirdly,
someone has to own them.
Consider tdb, the Trivial Database. There is no "master locking
daemon". There is no way for the first opener (who then has to create
the semaphores in your model) to pass them to other openers: this is a
library.
With this interface, I can use them on the stack with clone().
Most importantly, I can place the semaphores in a file and have them
persistant.
lock(1), unlock(1) => fast semaphores in shell scripts!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2002-02-25 1:41 Rusty Russell
@ 2002-02-25 1:58 ` Alexander Viro
2002-02-25 2:14 ` Rusty Russell
2002-02-25 13:16 ` Alan Cox
1 sibling, 1 reply; 669+ messages in thread
From: Alexander Viro @ 2002-02-25 1:58 UTC (permalink / raw)
To: Rusty Russell
Cc: Linus Torvalds, mingo, Matthew Kirkwood, Benjamin LaHaise,
David Axmark, William Lee Irwin III, linux-kernel
On Mon, 25 Feb 2002, Rusty Russell wrote:
> > Note that getting a file descriptor is really quite useful - it means that
> > you can pass the file descriptor around through unix domain sockets, for
> > example, and allow sharing of the semaphore across unrelated processes
> > that way.
>
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit. Secondly, you
Yes, you can. Please, RTFS - what is passed is not a descriptor, it's
struct file *. As soon as datagram is sent, descriptors are resolved and
after that point descriptor table of sender (or, for that matter, survival
of sender) doesn't matter.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-25 1:58 ` your mail Alexander Viro
@ 2002-02-25 2:14 ` Rusty Russell
2002-02-25 3:18 ` Davide Libenzi
2002-02-25 4:02 ` Alexander Viro
0 siblings, 2 replies; 669+ messages in thread
From: Rusty Russell @ 2002-02-25 2:14 UTC (permalink / raw)
To: Alexander Viro
Cc: Linus Torvalds, mingo, Matthew Kirkwood, Benjamin LaHaise,
David Axmark, William Lee Irwin III, linux-kernel
In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
e:
>
>
> On Mon, 25 Feb 2002, Rusty Russell wrote:
> > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > someone to pick it up, and they vanish when you exit. Secondly, you
>
> Yes, you can. Please, RTFS - what is passed is not a descriptor, it's
> struct file *. As soon as datagram is sent, descriptors are resolved and
> after that point descriptor table of sender (or, for that matter, survival
> of sender) doesn't matter.
Please explain how I leave a fd somewhere for other processes to grab
it.
And then please explain how they get the fd after I've exited.
Al, you are one of the most unpleasant people to deal with on this
list. This is *not* an honor, and I beg you to consider a different
approach in future correspondence.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-25 2:14 ` Rusty Russell
@ 2002-02-25 3:18 ` Davide Libenzi
2002-02-25 4:02 ` Alexander Viro
1 sibling, 0 replies; 669+ messages in thread
From: Davide Libenzi @ 2002-02-25 3:18 UTC (permalink / raw)
To: Rusty Russell
Cc: Alexander Viro, Linus Torvalds, mingo, Matthew Kirkwood,
Benjamin LaHaise, David Axmark, William Lee Irwin III,
linux-kernel
On Mon, 25 Feb 2002, Rusty Russell wrote:
> In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
> e:
> >
> >
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit. Secondly, you
> >
> > Yes, you can. Please, RTFS - what is passed is not a descriptor, it's
> > struct file *. As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
>
> Please explain how I leave a fd somewhere for other processes to grab
> it.
>
> And then please explain how they get the fd after I've exited.
>
> Al, you are one of the most unpleasant people to deal with on this
> list. This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.
Actually, this is one of Al's nicest posts :-)
You obviously can't share fd# but you can share file*
I don't know how you're going to have these semaphores 'externally visible',
if with numbers like IPC sems or if with pathnames like unix sockets ( or
something else ). But you can have internally a number/path/else -> file*
mapping and when a task attaches the sem you map the file* onto an fd# in
the task's file table. If you keep this mapping persistent ( until
explicit deletion ) the file* remain alive event with zero attached
processes. I think it's this what Al was trying to say.
- Davide
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-25 2:14 ` Rusty Russell
2002-02-25 3:18 ` Davide Libenzi
@ 2002-02-25 4:02 ` Alexander Viro
2002-02-26 5:50 ` Rusty Russell
1 sibling, 1 reply; 669+ messages in thread
From: Alexander Viro @ 2002-02-25 4:02 UTC (permalink / raw)
To: Rusty Russell
Cc: Linus Torvalds, mingo, Matthew Kirkwood, Benjamin LaHaise,
David Axmark, William Lee Irwin III, linux-kernel
On Mon, 25 Feb 2002, Rusty Russell wrote:
> In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
> e:
> >
> >
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit. Secondly, you
> >
> > Yes, you can. Please, RTFS - what is passed is not a descriptor, it's
> > struct file *. As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
>
> Please explain how I leave a fd somewhere for other processes to grab
> it.
>
> And then please explain how they get the fd after I've exited.
>
> Al, you are one of the most unpleasant people to deal with on this
> list. This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.
Honour or not, in this case your complaint is hardly deserved. To
compress the above a bit:
you: <false statement>
me: RTFS. <short description of the reasons why statement is wrong; further
details could be obtained by reading TFS>
As for your question, SCM_RIGHTS datagram can easily outlive the sending
process. You will need a helper process (either per-meeting point or
system-wide) to avoid GC killing the thing, but that's it.
Writing such helper is left as an exercise to reader - it _is_ trivial.
To put fd(s):
connect to (name of AF_UNIX socket)
sendmsg to it; no OOB data, one byte of data (non-0)
form an SCM_RIGHTS datagram with fds in question
sendmsg it to the same socket.
close the socket
In helper:
listen on (name)
repeat:
accept connection
read one byte
if it's non-zero
put fd of connection into a list
goto repeat
else
take first fd from list
form an SCM_RIGHTS datagram with that fd
send it into the new connection
close fd
close connection
goto repeat
To get fd(s):
connect ....
sendmsg .................................... (0)
recvmsg and pick fd from the message
close connection
recvmsg from fd and pick the set of fds from the message
close fd
End of story. In real-life situation you will want to throttle in helper,
etc., but in any case main loop is ~20 lines of code.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-25 4:02 ` Alexander Viro
@ 2002-02-26 5:50 ` Rusty Russell
0 siblings, 0 replies; 669+ messages in thread
From: Rusty Russell @ 2002-02-26 5:50 UTC (permalink / raw)
To: Alexander Viro; +Cc: linux-kernel
In message <Pine.GSO.4.21.0202242230370.1549-100000@weyl.math.psu.edu> you write:
> Honour or not, in this case your complaint is hardly deserved. To
> compress the above a bit:
>
> you: <false statement>
> me: RTFS. <short description of the reasons why statement is wrong; further
> details could be obtained by reading TFS>
Al, *please* read.
Rusty said:
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit. Secondly, you
> have some arbitrary limit on the number of semaphores. Thirdly,
> someone has to own them.
These are all true: I was criticising the "fd == semaphore" approach,
in the context of my "tied to mapped location" approach, and Linus's
"magic cookie" approach.
I went on to explain furthur:
> Consider tdb, the Trivial Database. There is no "master locking
> daemon". There is no way for the first opener (who then has to create
> the semaphores in your model) to pass them to other openers: this is a
> library.
You also managed to ignore my previous comment on the "fd ==
semaphore" approach:
> Implemented exactly that (and posted to l-k IIRC), and it's
> *horrible* to use.
And you came out assuming I had no idea how fd passing works:
> Yes, you can. Please, RTFS
...and then in the next mail you suggested I implement a "master
locking daemon".
I have taken the liberty of rewriting your reply as I might expect to
see from a peer:
================
From: Al Viro's Polite Twin
To: Rusty Russell
Subject: Re: [PATCH] Lightweight userspace semaphores...
Date: Two days after hell freezes over
On Mon, 25 Feb 2002, Rusty Russell wrote:
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit. Secondly, you
Have you considered using a daemon to hold the fds? It shouldn't be
that bad.
================
See how it doesn't assume that I am an idiot? It's not condescending,
and invites furthur consideration. It's also shorter than your other
two replies.
I might have replied as follows:
Yes, and for a "serious" database it's not a problem, as
it usually has some kind of daemon anyway. But for TDB, I
found that it's fragile and extremely unwieldy. Creating a
unix domain socket for each .tdb file may not be possible.
The tdb_open call would have to fork off a daemon if it's the
first process to access it. It starts to get fairly icky:
certainly when compared with the fairly trivial patch to
support the "semaphore tied to mapped region" approach.
You can try if you want (TDB enclosed).
Maybe I'm the only one who finds it *really* painful to continually
deal with your "Dan Bernstein of Linux" approach: enough that it
hinders my kernel work.
Genuinely hope this helps,
Rusty.
--
Taste: it's not just for source code anymore...
#ifndef __TDB_H__
#define __TDB_H__
/*
Unix SMB/Netbios implementation.
Version 3.0
Samba database functions
Copyright (C) Andrew Tridgell 1999
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#ifdef __cplusplus
extern "C" {
#endif
/* flags to tdb_store() */
#define TDB_REPLACE 1
#define TDB_INSERT 2
#define TDB_MODIFY 3
/* flags for tdb_open() */
#define TDB_DEFAULT 0 /* just a readability place holder */
#define TDB_CLEAR_IF_FIRST 1
#define TDB_INTERNAL 2 /* don't store on disk */
#define TDB_NOLOCK 4 /* don't do any locking */
#define TDB_NOMMAP 8 /* don't use mmap */
#define TDB_CONVERT 16 /* convert endian (internal use) */
#define TDB_ERRCODE(code, ret) ((tdb->ecode = (code)), ret)
/* error codes */
enum TDB_ERROR {TDB_SUCCESS=0, TDB_ERR_CORRUPT, TDB_ERR_IO, TDB_ERR_LOCK,
TDB_ERR_OOM, TDB_ERR_EXISTS, TDB_ERR_NOEXIST, TDB_ERR_NOLOCK };
#ifndef u32
#define u32 unsigned
#endif
typedef struct {
char *dptr;
size_t dsize;
} TDB_DATA;
typedef u32 tdb_len;
typedef u32 tdb_off;
/* this is stored at the front of every database */
struct tdb_header {
char magic_food[32]; /* for /etc/magic */
u32 version; /* version of the code */
u32 hash_size; /* number of hash entries */
tdb_off rwlocks;
tdb_off reserved[31];
};
struct tdb_lock_type {
u32 count;
u32 ltype;
};
struct tdb_traverse_lock {
struct tdb_traverse_lock *next;
u32 off;
u32 hash;
};
/* this is the context structure that is returned from a db open */
typedef struct tdb_context {
char *name; /* the name of the database */
void *map_ptr; /* where it is currently mapped */
int fd; /* open file descriptor for the database */
tdb_len map_size; /* how much space has been mapped */
int read_only; /* opened read-only */
struct tdb_lock_type *locked; /* array of chain locks */
enum TDB_ERROR ecode; /* error code for last tdb error */
struct tdb_header header; /* a cached copy of the header */
u32 flags; /* the flags passed to tdb_open */
u32 *lockedkeys; /* array of locked keys: first is #keys */
struct tdb_traverse_lock travlocks; /* current traversal locks */
struct tdb_context *next; /* all tdbs to avoid multiple opens */
dev_t device; /* uniquely identifies this tdb */
ino_t inode; /* uniquely identifies this tdb */
} TDB_CONTEXT;
typedef int (*tdb_traverse_func)(TDB_CONTEXT *, TDB_DATA, TDB_DATA, void *);
typedef void (*tdb_log_func)(TDB_CONTEXT *, int , const char *, ...);
TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags,
int open_flags, mode_t mode);
enum TDB_ERROR tdb_error(TDB_CONTEXT *tdb);
const char *tdb_errorstr(TDB_CONTEXT *tdb);
TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_delete(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_store(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, int flag);
int tdb_close(TDB_CONTEXT *tdb);
TDB_DATA tdb_firstkey(TDB_CONTEXT *tdb);
TDB_DATA tdb_nextkey(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_traverse(TDB_CONTEXT *tdb, tdb_traverse_func fn, void *state);
int tdb_exists(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_lockkeys(TDB_CONTEXT *tdb, u32 number, TDB_DATA keys[]);
void tdb_unlockkeys(TDB_CONTEXT *tdb);
int tdb_lockall(TDB_CONTEXT *tdb);
void tdb_unlockall(TDB_CONTEXT *tdb);
/* Low level locking functions: use with care */
int tdb_chainlock(TDB_CONTEXT *tdb, TDB_DATA key);
void tdb_chainunlock(TDB_CONTEXT *tdb, TDB_DATA key);
/* Debug functions. Not used in production. */
void tdb_dump_all(TDB_CONTEXT *tdb);
void tdb_printfreelist(TDB_CONTEXT *tdb);
extern TDB_DATA tdb_null;
#ifdef __cplusplus
}
#endif
#endif /* tdb.h */
/*
Unix SMB/Netbios implementation.
Version 3.0
Samba database functions
Copyright (C) Andrew Tridgell 1999-2000
Copyright (C) Luke Kenneth Casson Leighton 2000
Copyright (C) Paul `Rusty' Russell 2000
Copyright (C) Jeremy Allison 2000
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include "tdb.h"
#define TDB_MAGIC_FOOD "TDB file\n"
#define TDB_VERSION (0x26011967 + 6)
#define TDB_MAGIC (0x26011999U)
#define TDB_FREE_MAGIC (~TDB_MAGIC)
#define TDB_DEAD_MAGIC (0xFEE1DEAD)
#define TDB_ALIGNMENT 4
#define MIN_REC_SIZE (2*sizeof(struct list_struct) + TDB_ALIGNMENT)
#define DEFAULT_HASH_SIZE 131
#define TDB_PAGE_SIZE 0x2000
#define FREELIST_TOP (sizeof(struct tdb_header))
#define TDB_ALIGN(x,a) (((x) + (a)-1) & ~((a)-1))
#define TDB_BYTEREV(x) (((((x)&0xff)<<24)|((x)&0xFF00)<<8)|(((x)>>8)&0xFF00)|((x)>>24))
#define TDB_DEAD(r) ((r)->magic == TDB_DEAD_MAGIC)
#define TDB_BAD_MAGIC(r) ((r)->magic != TDB_MAGIC && !TDB_DEAD(r))
#define TDB_HASH_TOP(hash) (FREELIST_TOP + (BUCKET(hash)+1)*sizeof(tdb_off))
/* lock offsets */
#define GLOBAL_LOCK 0
#define ACTIVE_LOCK 4
#ifndef MAP_FILE
#define MAP_FILE 0
#endif
#ifndef MAP_FAILED
#define MAP_FAILED ((void *)-1)
#endif
#define BUCKET(hash) ((hash) % tdb->header.hash_size)
TDB_DATA tdb_null;
/* all contexts, to ensure no double-opens (fcntl locks don't nest!) */
static TDB_CONTEXT *tdbs = NULL;
static void tdb_munmap(TDB_CONTEXT *tdb)
{
if (tdb->flags & TDB_INTERNAL)
return;
if (tdb->map_ptr)
munmap(tdb->map_ptr, tdb->map_size);
tdb->map_ptr = NULL;
}
static void tdb_mmap(TDB_CONTEXT *tdb)
{
if (tdb->flags & TDB_INTERNAL)
return;
if (!(tdb->flags & TDB_NOMMAP)) {
tdb->map_ptr = mmap(NULL, tdb->map_size,
PROT_READ|(tdb->read_only? 0:PROT_WRITE),
MAP_SHARED|MAP_FILE, tdb->fd, 0);
/*
* NB. When mmap fails it returns MAP_FAILED *NOT* NULL !!!!
*/
if (tdb->map_ptr == MAP_FAILED)
tdb->map_ptr = NULL;
} else {
tdb->map_ptr = NULL;
}
}
/* Endian conversion: we only ever deal with 4 byte quantities */
static void *convert(void *buf, u32 size)
{
u32 i, *p = buf;
for (i = 0; i < size / 4; i++)
p[i] = TDB_BYTEREV(p[i]);
return buf;
}
#define DOCONV() (tdb->flags & TDB_CONVERT)
#define CONVERT(x) (DOCONV() ? convert(&x, sizeof(x)) : &x)
/* the body of the database is made of one list_struct for the free space
plus a separate data list for each hash value */
struct list_struct {
tdb_off next; /* offset of the next record in the list */
tdb_len rec_len; /* total byte length of record */
tdb_len key_len; /* byte length of key */
tdb_len data_len; /* byte length of data */
u32 full_hash; /* the full 32 bit hash of the key */
u32 magic; /* try to catch errors */
/* the following union is implied:
union {
char record[rec_len];
struct {
char key[key_len];
char data[data_len];
}
u32 totalsize; (tailer)
}
*/
};
/* a byte range locking function - return 0 on success
this functions locks/unlocks 1 byte at the specified offset.
On error, errno is also set so that errors are passed back properly
through tdb_open(). */
static int tdb_brlock(TDB_CONTEXT *tdb, tdb_off offset,
int rw_type, int lck_type)
{
struct flock fl;
if (tdb->flags & TDB_NOLOCK)
return 0;
if (tdb->read_only) {
errno = EACCES;
return -1;
}
fl.l_type = rw_type;
fl.l_whence = SEEK_SET;
fl.l_start = offset;
fl.l_len = 1;
fl.l_pid = 0;
if (fcntl(tdb->fd,lck_type,&fl)) {
/* errno set by fcntl */
return TDB_ERRCODE(TDB_ERR_LOCK, -1);
}
return 0;
}
/* lock a list in the database. list -1 is the alloc list */
static int tdb_lock(TDB_CONTEXT *tdb, int list, int ltype)
{
if (list < -1 || list >= (int)tdb->header.hash_size) {
return -1;
}
if (tdb->flags & TDB_NOLOCK)
return 0;
/* Since fcntl locks don't nest, we do a lock for the first one,
and simply bump the count for future ones */
if (tdb->locked[list+1].count == 0) {
if (tdb_brlock(tdb,FREELIST_TOP+4*list,ltype,F_SETLKW)) {
return -1;
}
tdb->locked[list+1].ltype = ltype;
}
tdb->locked[list+1].count++;
return 0;
}
/* unlock the database: returns void because it's too late for errors. */
static void tdb_unlock(TDB_CONTEXT *tdb, int list, int ltype)
{
if (tdb->flags & TDB_NOLOCK)
return;
/* Sanity checks */
if (list < -1 || list >= (int)tdb->header.hash_size)
return;
if (tdb->locked[list+1].count==0)
return;
if (tdb->locked[list+1].count == 1) {
/* Down to last nested lock: unlock underneath */
tdb_brlock(tdb, FREELIST_TOP+4*list, F_UNLCK, F_SETLKW);
}
tdb->locked[list+1].count--;
}
/* This is based on the hash agorithm from gdbm */
static u32 tdb_hash(TDB_DATA *key)
{
u32 value; /* Used to compute the hash value. */
u32 i; /* Used to cycle through random values. */
/* Set the initial value from the key size. */
for (value = 0x238F13AF * key->dsize, i=0; i < key->dsize; i++)
value = (value + (key->dptr[i] << (i*5 % 24)));
return (1103515243 * value + 12345);
}
/* check for an out of bounds access - if it is out of bounds then
see if the database has been expanded by someone else and expand
if necessary
note that "len" is the minimum length needed for the db
*/
static int tdb_oob(TDB_CONTEXT *tdb, tdb_off len)
{
struct stat st;
if (len <= tdb->map_size)
return 0;
if (tdb->flags & TDB_INTERNAL) {
return TDB_ERRCODE(TDB_ERR_IO, -1);
}
if (fstat(tdb->fd, &st) == -1)
return TDB_ERRCODE(TDB_ERR_IO, -1);
if (st.st_size < (size_t)len) {
return TDB_ERRCODE(TDB_ERR_IO, -1);
}
/* Unmap, update size, remap */
tdb_munmap(tdb);
tdb->map_size = st.st_size;
tdb_mmap(tdb);
return 0;
}
/* write a lump of data at a specified offset */
static int tdb_write(TDB_CONTEXT *tdb, tdb_off off, void *buf, tdb_len len)
{
if (tdb_oob(tdb, off + len) != 0)
return -1;
if (tdb->map_ptr)
memcpy(off + (char *)tdb->map_ptr, buf, len);
else if (lseek(tdb->fd, off, SEEK_SET) != off
|| write(tdb->fd, buf, len) != (ssize_t)len) {
return TDB_ERRCODE(TDB_ERR_IO, -1);
}
return 0;
}
/* read a lump of data at a specified offset, maybe convert */
static int tdb_read(TDB_CONTEXT *tdb,tdb_off off,void *buf,tdb_len len,int cv)
{
if (tdb_oob(tdb, off + len) != 0)
return -1;
if (tdb->map_ptr)
memcpy(buf, off + (char *)tdb->map_ptr, len);
else if (lseek(tdb->fd, off, SEEK_SET) != off
|| read(tdb->fd, buf, len) != (ssize_t)len) {
return TDB_ERRCODE(TDB_ERR_IO, -1);
}
if (cv)
convert(buf, len);
return 0;
}
/* read a lump of data, allocating the space for it */
static char *tdb_alloc_read(TDB_CONTEXT *tdb, tdb_off offset, tdb_len len)
{
char *buf;
if (!(buf = malloc(len))) {
return TDB_ERRCODE(TDB_ERR_OOM, buf);
}
if (tdb_read(tdb, offset, buf, len, 0) == -1) {
free(buf);
return NULL;
}
return buf;
}
/* read/write a tdb_off */
static int ofs_read(TDB_CONTEXT *tdb, tdb_off offset, tdb_off *d)
{
return tdb_read(tdb, offset, (char*)d, sizeof(*d), DOCONV());
}
static int ofs_write(TDB_CONTEXT *tdb, tdb_off offset, tdb_off *d)
{
tdb_off off = *d;
return tdb_write(tdb, offset, CONVERT(off), sizeof(*d));
}
/* read/write a record */
static int rec_read(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
if (tdb_read(tdb, offset, rec, sizeof(*rec),DOCONV()) == -1)
return -1;
if (TDB_BAD_MAGIC(rec)) {
return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
}
return tdb_oob(tdb, rec->next+sizeof(*rec));
}
static int rec_write(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
struct list_struct r = *rec;
return tdb_write(tdb, offset, CONVERT(r), sizeof(r));
}
/* read a freelist record and check for simple errors */
static int rec_free_read(TDB_CONTEXT *tdb, tdb_off off, struct list_struct *rec)
{
if (tdb_read(tdb, off, rec, sizeof(*rec),DOCONV()) == -1)
return -1;
if (rec->magic != TDB_FREE_MAGIC) {
return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
}
if (tdb_oob(tdb, rec->next+sizeof(*rec)) != 0)
return -1;
return 0;
}
/* update a record tailer (must hold allocation lock) */
static int update_tailer(TDB_CONTEXT *tdb, tdb_off offset,
const struct list_struct *rec)
{
tdb_off totalsize;
/* Offset of tailer from record header */
totalsize = sizeof(*rec) + rec->rec_len;
return ofs_write(tdb, offset + totalsize - sizeof(tdb_off),
&totalsize);
}
static tdb_off tdb_dump_record(TDB_CONTEXT *tdb, tdb_off offset)
{
struct list_struct rec;
tdb_off tailer_ofs, tailer;
if (tdb_read(tdb, offset, (char *)&rec, sizeof(rec), DOCONV()) == -1) {
printf("ERROR: failed to read record at %u\n", offset);
return 0;
}
printf(" rec: offset=%u next=%d rec_len=%d key_len=%d data_len=%d full_hash=0x%x magic=0x%x\n",
offset, rec.next, rec.rec_len, rec.key_len, rec.data_len, rec.full_hash, rec.magic);
tailer_ofs = offset + sizeof(rec) + rec.rec_len - sizeof(tdb_off);
if (ofs_read(tdb, tailer_ofs, &tailer) == -1) {
printf("ERROR: failed to read tailer at %u\n", tailer_ofs);
return rec.next;
}
if (tailer != rec.rec_len + sizeof(rec)) {
printf("ERROR: tailer does not match record! tailer=%u totalsize=%u\n", tailer, rec.rec_len + sizeof(rec));
}
return rec.next;
}
static void tdb_dump_chain(TDB_CONTEXT *tdb, int i)
{
tdb_off rec_ptr, top;
top = TDB_HASH_TOP(i);
tdb_lock(tdb, i, F_WRLCK);
if (ofs_read(tdb, top, &rec_ptr) == -1) {
tdb_unlock(tdb, i, F_WRLCK);
return;
}
if (rec_ptr)
printf("hash=%d\n", i);
while (rec_ptr) {
rec_ptr = tdb_dump_record(tdb, rec_ptr);
}
tdb_unlock(tdb, i, F_WRLCK);
}
void tdb_dump_all(TDB_CONTEXT *tdb)
{
int i;
for (i=0;i<tdb->header.hash_size;i++) {
tdb_dump_chain(tdb, i);
}
printf("freelist:\n");
tdb_dump_chain(tdb, -1);
}
void tdb_printfreelist(TDB_CONTEXT *tdb)
{
long total_free = 0;
tdb_off offset, rec_ptr, last_ptr;
struct list_struct rec;
tdb_lock(tdb, -1, F_WRLCK);
last_ptr = 0;
offset = FREELIST_TOP;
/* read in the freelist top */
if (ofs_read(tdb, offset, &rec_ptr) == -1) {
return;
}
printf("freelist top=[0x%08x]\n", rec_ptr );
while (rec_ptr) {
if (tdb_read(tdb, rec_ptr, (char *)&rec, sizeof(rec), DOCONV()) == -1) {
return;
}
if (rec.magic != TDB_FREE_MAGIC) {
printf("bad magic 0x%08x in free list\n", rec.magic);
return;
}
printf("entry offset=[0x%08x], rec.rec_len = [0x%08x (%d)]\n", rec.next, rec.rec_len, rec.rec_len );
total_free += rec.rec_len;
/* move to the next record */
rec_ptr = rec.next;
}
printf("total rec_len = [0x%08x (%d)]\n", (int)total_free,
(int)total_free);
tdb_unlock(tdb, -1, F_WRLCK);
}
/* Remove an element from the freelist. Must have alloc lock. */
static int remove_from_freelist(TDB_CONTEXT *tdb, tdb_off off, tdb_off next)
{
tdb_off last_ptr, i;
/* read in the freelist top */
last_ptr = FREELIST_TOP;
while (ofs_read(tdb, last_ptr, &i) != -1 && i != 0) {
if (i == off) {
/* We've found it! */
return ofs_write(tdb, last_ptr, &next);
}
/* Follow chain (next offset is at start of record) */
last_ptr = i;
}
return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
}
/* Add an element into the freelist. Merge adjacent records if
neccessary. */
static int tdb_free(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
tdb_off right, left;
/* Allocation and tailer lock */
if (tdb_lock(tdb, -1, F_WRLCK) != 0)
return -1;
/* set an initial tailer, so if we fail we don't leave a bogus record */
update_tailer(tdb, offset, rec);
/* Look right first (I'm an Australian, dammit) */
right = offset + sizeof(*rec) + rec->rec_len;
if (right + sizeof(*rec) <= tdb->map_size) {
struct list_struct r;
if (tdb_read(tdb, right, &r, sizeof(r), DOCONV()) == -1) {
goto left;
}
/* If it's free, expand to include it. */
if (r.magic == TDB_FREE_MAGIC) {
if (remove_from_freelist(tdb, right, r.next) == -1) {
goto left;
}
rec->rec_len += sizeof(r) + r.rec_len;
}
}
left:
/* Look left */
left = offset - sizeof(tdb_off);
if (left > TDB_HASH_TOP(tdb->header.hash_size-1)) {
struct list_struct l;
tdb_off leftsize;
/* Read in tailer and jump back to header */
if (ofs_read(tdb, left, &leftsize) == -1) {
goto update;
}
left = offset - leftsize;
/* Now read in record */
if (tdb_read(tdb, left, &l, sizeof(l), DOCONV()) == -1) {
goto update;
}
/* If it's free, expand to include it. */
if (l.magic == TDB_FREE_MAGIC) {
if (remove_from_freelist(tdb, left, l.next) == -1) {
goto update;
} else {
offset = left;
rec->rec_len += leftsize;
}
}
}
update:
if (update_tailer(tdb, offset, rec) == -1) {
goto fail;
}
/* Now, prepend to free list */
rec->magic = TDB_FREE_MAGIC;
if (ofs_read(tdb, FREELIST_TOP, &rec->next) == -1 ||
rec_write(tdb, offset, rec) == -1 ||
ofs_write(tdb, FREELIST_TOP, &offset) == -1) {
goto fail;
}
/* And we're done. */
tdb_unlock(tdb, -1, F_WRLCK);
return 0;
fail:
tdb_unlock(tdb, -1, F_WRLCK);
return -1;
}
/* expand a file. we prefer to use ftruncate, as that is what posix
says to use for mmap expansion */
static int expand_file(TDB_CONTEXT *tdb, tdb_off size, tdb_off addition)
{
char buf[1024];
if (ftruncate(tdb->fd, size+addition) != 0) {
return -1;
}
/* now fill the file with something. This ensures that the file isn't sparse, which would be
very bad if we ran out of disk. This must be done with write, not via mmap */
memset(buf, 0x42, sizeof(buf));
while (addition) {
int n = addition>sizeof(buf)?sizeof(buf):addition;
int ret;
if (lseek(tdb->fd, size, SEEK_SET) != size)
return -1;
ret = write(tdb->fd, buf, n);
if (ret != n) {
return -1;
}
addition -= n;
size += n;
}
return 0;
}
/* expand the database at least size bytes by expanding the underlying
file and doing the mmap again if necessary */
static int tdb_expand(TDB_CONTEXT *tdb, tdb_off size)
{
struct list_struct rec;
tdb_off offset;
if (tdb_lock(tdb, -1, F_WRLCK) == -1) {
return -1;
}
/* must know about any previous expansions by another process */
tdb_oob(tdb, tdb->map_size + 1);
/* always make room for at least 10 more records, and round
the database up to a multiple of TDB_PAGE_SIZE */
size = TDB_ALIGN(tdb->map_size + size*10, TDB_PAGE_SIZE) - tdb->map_size;
if (!(tdb->flags & TDB_INTERNAL))
tdb_munmap(tdb);
/*
* We must ensure the file is unmapped before doing this
* to ensure consistency with systems like OpenBSD where
* writes and mmaps are not consistent.
*/
/* expand the file itself */
if (!(tdb->flags & TDB_INTERNAL)) {
if (expand_file(tdb, tdb->map_size, size) != 0)
goto fail;
}
tdb->map_size += size;
if (tdb->flags & TDB_INTERNAL)
tdb->map_ptr = realloc(tdb->map_ptr, tdb->map_size);
else {
/*
* We must ensure the file is remapped before adding the space
* to ensure consistency with systems like OpenBSD where
* writes and mmaps are not consistent.
*/
/* We're ok if the mmap fails as we'll fallback to read/write */
tdb_mmap(tdb);
}
/* form a new freelist record */
memset(&rec,'\0',sizeof(rec));
rec.rec_len = size - sizeof(rec);
/* link it into the free list */
offset = tdb->map_size - size;
if (tdb_free(tdb, offset, &rec) == -1)
goto fail;
tdb_unlock(tdb, -1, F_WRLCK);
return 0;
fail:
tdb_unlock(tdb, -1, F_WRLCK);
return -1;
}
/* allocate some space from the free list. The offset returned points
to a unconnected list_struct within the database with room for at
least length bytes of total data
0 is returned if the space could not be allocated
*/
static tdb_off tdb_allocate(TDB_CONTEXT *tdb, tdb_len length,
struct list_struct *rec)
{
tdb_off rec_ptr, last_ptr, newrec_ptr;
struct list_struct newrec;
if (tdb_lock(tdb, -1, F_WRLCK) == -1)
return 0;
/* Extra bytes required for tailer */
length += sizeof(tdb_off);
again:
last_ptr = FREELIST_TOP;
/* read in the freelist top */
if (ofs_read(tdb, FREELIST_TOP, &rec_ptr) == -1)
goto fail;
/* keep looking until we find a freelist record big enough */
while (rec_ptr) {
if (rec_free_read(tdb, rec_ptr, rec) == -1)
goto fail;
if (rec->rec_len >= length) {
/* found it - now possibly split it up */
if (rec->rec_len > length + MIN_REC_SIZE) {
/* Length of left piece */
length = TDB_ALIGN(length, TDB_ALIGNMENT);
/* Right piece to go on free list */
newrec.rec_len = rec->rec_len
- (sizeof(*rec) + length);
newrec_ptr = rec_ptr + sizeof(*rec) + length;
/* And left record is shortened */
rec->rec_len = length;
} else
newrec_ptr = 0;
/* Remove allocated record from the free list */
if (ofs_write(tdb, last_ptr, &rec->next) == -1)
goto fail;
/* Update header: do this before we drop alloc
lock, otherwise tdb_free() might try to
merge with us, thinking we're free.
(Thanks Jeremy Allison). */
rec->magic = TDB_MAGIC;
if (rec_write(tdb, rec_ptr, rec) == -1)
goto fail;
/* Did we create new block? */
if (newrec_ptr) {
/* Update allocated record tailer (we
shortened it). */
if (update_tailer(tdb, rec_ptr, rec) == -1)
goto fail;
/* Free new record */
if (tdb_free(tdb, newrec_ptr, &newrec) == -1)
goto fail;
}
/* all done - return the new record offset */
tdb_unlock(tdb, -1, F_WRLCK);
return rec_ptr;
}
/* move to the next record */
last_ptr = rec_ptr;
rec_ptr = rec->next;
}
/* we didn't find enough space. See if we can expand the
database and if we can then try again */
if (tdb_expand(tdb, length + sizeof(*rec)) == 0)
goto again;
fail:
tdb_unlock(tdb, -1, F_WRLCK);
return 0;
}
/* initialise a new database with a specified hash size */
static int tdb_new_database(TDB_CONTEXT *tdb, int hash_size)
{
struct tdb_header *newdb;
int size, ret = -1;
/* We make it up in memory, then write it out if not internal */
size = sizeof(struct tdb_header) + (hash_size+1)*sizeof(tdb_off);
if (!(newdb = calloc(size, 1)))
return TDB_ERRCODE(TDB_ERR_OOM, -1);
/* Fill in the header */
newdb->version = TDB_VERSION;
newdb->hash_size = hash_size;
if (tdb->flags & TDB_INTERNAL) {
tdb->map_size = size;
tdb->map_ptr = (char *)newdb;
memcpy(&tdb->header, newdb, sizeof(tdb->header));
/* Convert the `ondisk' version if asked. */
CONVERT(*newdb);
return 0;
}
if (lseek(tdb->fd, 0, SEEK_SET) == -1)
goto fail;
if (ftruncate(tdb->fd, 0) == -1)
goto fail;
/* This creates an endian-converted header, as if read from disk */
CONVERT(*newdb);
memcpy(&tdb->header, newdb, sizeof(tdb->header));
/* Don't endian-convert the magic food! */
memcpy(newdb->magic_food, TDB_MAGIC_FOOD, strlen(TDB_MAGIC_FOOD)+1);
if (write(tdb->fd, newdb, size) != size)
ret = -1;
else
ret = 0;
fail:
free(newdb);
return ret;
}
/* Returns 0 on fail. On success, return offset of record, and fills
in rec */
static tdb_off tdb_find(TDB_CONTEXT *tdb, TDB_DATA key, u32 hash,
struct list_struct *r)
{
tdb_off rec_ptr;
/* read in the hash top */
if (ofs_read(tdb, TDB_HASH_TOP(hash), &rec_ptr) == -1)
return 0;
/* keep looking until we find the right record */
while (rec_ptr) {
if (rec_read(tdb, rec_ptr, r) == -1)
return 0;
if (!TDB_DEAD(r) && hash==r->full_hash && key.dsize==r->key_len) {
char *k;
/* a very likely hit - read the key */
k = tdb_alloc_read(tdb, rec_ptr + sizeof(*r),
r->key_len);
if (!k)
return 0;
if (memcmp(key.dptr, k, key.dsize) == 0) {
free(k);
return rec_ptr;
}
free(k);
}
rec_ptr = r->next;
}
return TDB_ERRCODE(TDB_ERR_NOEXIST, 0);
}
/* If they do lockkeys, check that this hash is one they locked */
static int tdb_keylocked(TDB_CONTEXT *tdb, u32 hash)
{
u32 i;
if (!tdb->lockedkeys)
return 1;
for (i = 0; i < tdb->lockedkeys[0]; i++)
if (tdb->lockedkeys[i+1] == hash)
return 1;
return TDB_ERRCODE(TDB_ERR_NOLOCK, 0);
}
/* As tdb_find, but if you succeed, keep the lock */
static tdb_off tdb_find_lock(TDB_CONTEXT *tdb, TDB_DATA key, int locktype,
struct list_struct *rec)
{
u32 hash, rec_ptr;
hash = tdb_hash(&key);
if (!tdb_keylocked(tdb, hash))
return 0;
if (tdb_lock(tdb, BUCKET(hash), locktype) == -1)
return 0;
if (!(rec_ptr = tdb_find(tdb, key, hash, rec)))
tdb_unlock(tdb, BUCKET(hash), locktype);
return rec_ptr;
}
enum TDB_ERROR tdb_error(TDB_CONTEXT *tdb)
{
return tdb->ecode;
}
static struct tdb_errname {
enum TDB_ERROR ecode; const char *estring;
} emap[] = { {TDB_SUCCESS, "Success"},
{TDB_ERR_CORRUPT, "Corrupt database"},
{TDB_ERR_IO, "IO Error"},
{TDB_ERR_LOCK, "Locking error"},
{TDB_ERR_OOM, "Out of memory"},
{TDB_ERR_EXISTS, "Record exists"},
{TDB_ERR_NOLOCK, "Lock exists on other keys"},
{TDB_ERR_NOEXIST, "Record does not exist"} };
/* Error string for the last tdb error */
const char *tdb_errorstr(TDB_CONTEXT *tdb)
{
u32 i;
for (i = 0; i < sizeof(emap) / sizeof(struct tdb_errname); i++)
if (tdb->ecode == emap[i].ecode)
return emap[i].estring;
return "Invalid error code";
}
/* update an entry in place - this only works if the new data size
is <= the old data size and the key exists.
on failure return -1
*/
static int tdb_update(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf)
{
struct list_struct rec;
tdb_off rec_ptr;
int ret = -1;
/* find entry */
if (!(rec_ptr = tdb_find_lock(tdb, key, F_WRLCK, &rec)))
return -1;
/* must be long enough key, data and tailer */
if (rec.rec_len < key.dsize + dbuf.dsize + sizeof(tdb_off)) {
tdb->ecode = TDB_SUCCESS; /* Not really an error */
goto out;
}
if (tdb_write(tdb, rec_ptr + sizeof(rec) + rec.key_len,
dbuf.dptr, dbuf.dsize) == -1)
goto out;
if (dbuf.dsize != rec.data_len) {
/* update size */
rec.data_len = dbuf.dsize;
ret = rec_write(tdb, rec_ptr, &rec);
} else
ret = 0;
out:
tdb_unlock(tdb, BUCKET(rec.full_hash), F_WRLCK);
return ret;
}
/* find an entry in the database given a key */
TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key)
{
tdb_off rec_ptr;
struct list_struct rec;
TDB_DATA ret;
/* find which hash bucket it is in */
if (!(rec_ptr = tdb_find_lock(tdb,key,F_RDLCK,&rec)))
return tdb_null;
ret.dptr = tdb_alloc_read(tdb, rec_ptr + sizeof(rec) + rec.key_len,
rec.data_len);
ret.dsize = rec.data_len;
tdb_unlock(tdb, BUCKET(rec.full_hash), F_RDLCK);
return ret;
}
/* check if an entry in the database exists
note that 1 is returned if the key is found and 0 is returned if not found
this doesn't match the conventions in the rest of this module, but is
compatible with gdbm
*/
int tdb_exists(TDB_CONTEXT *tdb, TDB_DATA key)
{
struct list_struct rec;
if (tdb_find_lock(tdb, key, F_RDLCK, &rec) == 0)
return 0;
tdb_unlock(tdb, BUCKET(rec.full_hash), F_RDLCK);
return 1;
}
/* record lock stops delete underneath */
static int lock_record(TDB_CONTEXT *tdb, tdb_off off)
{
return off ? tdb_brlock(tdb, off, F_RDLCK, F_SETLKW) : 0;
}
/*
Write locks override our own fcntl readlocks, so check it here.
Note this is meant to be F_SETLK, *not* F_SETLKW, as it's not
an error to fail to get the lock here.
*/
static int write_lock_record(TDB_CONTEXT *tdb, tdb_off off)
{
struct tdb_traverse_lock *i;
for (i = &tdb->travlocks; i; i = i->next)
if (i->off == off)
return -1;
return tdb_brlock(tdb, off, F_WRLCK, F_SETLK);
}
/*
Note this is meant to be F_SETLK, *not* F_SETLKW, as it's not
an error to fail to get the lock here.
*/
static int write_unlock_record(TDB_CONTEXT *tdb, tdb_off off)
{
return tdb_brlock(tdb, off, F_UNLCK, F_SETLK);
}
/* fcntl locks don't stack: avoid unlocking someone else's */
static int unlock_record(TDB_CONTEXT *tdb, tdb_off off)
{
struct tdb_traverse_lock *i;
u32 count = 0;
if (off == 0)
return 0;
for (i = &tdb->travlocks; i; i = i->next)
if (i->off == off)
count++;
return (count == 1 ? tdb_brlock(tdb, off, F_UNLCK, F_SETLKW) : 0);
}
/* actually delete an entry in the database given the offset */
static int do_delete(TDB_CONTEXT *tdb, tdb_off rec_ptr, struct list_struct*rec)
{
tdb_off last_ptr, i;
struct list_struct lastrec;
if (tdb->read_only) return -1;
if (write_lock_record(tdb, rec_ptr) == -1) {
/* Someone traversing here: mark it as dead */
rec->magic = TDB_DEAD_MAGIC;
return rec_write(tdb, rec_ptr, rec);
}
write_unlock_record(tdb, rec_ptr);
/* find previous record in hash chain */
if (ofs_read(tdb, TDB_HASH_TOP(rec->full_hash), &i) == -1)
return -1;
for (last_ptr = 0; i != rec_ptr; last_ptr = i, i = lastrec.next)
if (rec_read(tdb, i, &lastrec) == -1)
return -1;
/* unlink it: next ptr is at start of record. */
if (last_ptr == 0)
last_ptr = TDB_HASH_TOP(rec->full_hash);
if (ofs_write(tdb, last_ptr, &rec->next) == -1)
return -1;
/* recover the space */
if (tdb_free(tdb, rec_ptr, rec) == -1)
return -1;
return 0;
}
/* Uses traverse lock: 0 = finish, -1 = error, other = record offset */
static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
struct list_struct *rec)
{
int want_next = (tlock->off != 0);
/* No traversal allows if you've called tdb_lockkeys() */
if (tdb->lockedkeys)
return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
/* Lock each chain from the start one. */
for (; tlock->hash < tdb->header.hash_size; tlock->hash++) {
if (tdb_lock(tdb, tlock->hash, F_WRLCK) == -1)
return -1;
/* No previous record? Start at top of chain. */
if (!tlock->off) {
if (ofs_read(tdb, TDB_HASH_TOP(tlock->hash),
&tlock->off) == -1)
goto fail;
} else {
/* Otherwise unlock the previous record. */
unlock_record(tdb, tlock->off);
}
if (want_next) {
/* We have offset of old record: grab next */
if (rec_read(tdb, tlock->off, rec) == -1)
goto fail;
tlock->off = rec->next;
}
/* Iterate through chain */
while( tlock->off) {
tdb_off current;
if (rec_read(tdb, tlock->off, rec) == -1)
goto fail;
if (!TDB_DEAD(rec)) {
/* Woohoo: we found one! */
lock_record(tdb, tlock->off);
return tlock->off;
}
/* Try to clean dead ones from old traverses */
current = tlock->off;
tlock->off = rec->next;
do_delete(tdb, current, rec);
}
tdb_unlock(tdb, tlock->hash, F_WRLCK);
want_next = 0;
}
/* We finished iteration without finding anything */
return TDB_ERRCODE(TDB_SUCCESS, 0);
fail:
tlock->off = 0;
tdb_unlock(tdb, tlock->hash, F_WRLCK);
return -1;
}
/* traverse the entire database - calling fn(tdb, key, data) on each element.
return -1 on error or the record count traversed
if fn is NULL then it is not called
a non-zero return value from fn() indicates that the traversal should stop
*/
int tdb_traverse(TDB_CONTEXT *tdb, tdb_traverse_func fn, void *state)
{
TDB_DATA key, dbuf;
struct list_struct rec;
struct tdb_traverse_lock tl = { NULL, 0, 0 };
int ret, count = 0;
/* This was in the initializaton, above, but the IRIX compiler
* did not like it. crh
*/
tl.next = tdb->travlocks.next;
/* fcntl locks don't stack: beware traverse inside traverse */
tdb->travlocks.next = &tl;
/* tdb_next_lock places locks on the record returned, and its chain */
while ((ret = tdb_next_lock(tdb, &tl, &rec)) > 0) {
count++;
/* now read the full record */
key.dptr = tdb_alloc_read(tdb, tl.off + sizeof(rec),
rec.key_len + rec.data_len);
if (!key.dptr) {
tdb_unlock(tdb, tl.hash, F_WRLCK);
unlock_record(tdb, tl.off);
tdb->travlocks.next = tl.next;
return -1;
}
key.dsize = rec.key_len;
dbuf.dptr = key.dptr + rec.key_len;
dbuf.dsize = rec.data_len;
/* Drop chain lock, call out */
tdb_unlock(tdb, tl.hash, F_WRLCK);
if (fn && fn(tdb, key, dbuf, state)) {
/* They want us to terminate traversal */
unlock_record(tdb, tl.off);
tdb->travlocks.next = tl.next;
free(key.dptr);
return count;
}
free(key.dptr);
}
tdb->travlocks.next = tl.next;
if (ret < 0)
return -1;
else
return count;
}
/* find the first entry in the database and return its key */
TDB_DATA tdb_firstkey(TDB_CONTEXT *tdb)
{
TDB_DATA key;
struct list_struct rec;
/* release any old lock */
unlock_record(tdb, tdb->travlocks.off);
tdb->travlocks.off = tdb->travlocks.hash = 0;
if (tdb_next_lock(tdb, &tdb->travlocks, &rec) <= 0)
return tdb_null;
/* now read the key */
key.dsize = rec.key_len;
key.dptr =tdb_alloc_read(tdb,tdb->travlocks.off+sizeof(rec),key.dsize);
tdb_unlock(tdb, BUCKET(tdb->travlocks.hash), F_WRLCK);
return key;
}
/* find the next entry in the database, returning its key */
TDB_DATA tdb_nextkey(TDB_CONTEXT *tdb, TDB_DATA oldkey)
{
u32 oldhash;
TDB_DATA key = tdb_null;
struct list_struct rec;
char *k = NULL;
/* Is locked key the old key? If so, traverse will be reliable. */
if (tdb->travlocks.off) {
if (tdb_lock(tdb,tdb->travlocks.hash,F_WRLCK))
return tdb_null;
if (rec_read(tdb, tdb->travlocks.off, &rec) == -1
|| !(k = tdb_alloc_read(tdb,tdb->travlocks.off+sizeof(rec),
rec.key_len))
|| memcmp(k, oldkey.dptr, oldkey.dsize) != 0) {
/* No, it wasn't: unlock it and start from scratch */
unlock_record(tdb, tdb->travlocks.off);
tdb_unlock(tdb, tdb->travlocks.hash, F_WRLCK);
tdb->travlocks.off = 0;
}
if (k)
free(k);
}
if (!tdb->travlocks.off) {
/* No previous element: do normal find, and lock record */
tdb->travlocks.off = tdb_find_lock(tdb, oldkey, F_WRLCK, &rec);
if (!tdb->travlocks.off)
return tdb_null;
tdb->travlocks.hash = BUCKET(rec.full_hash);
lock_record(tdb, tdb->travlocks.off);
}
oldhash = tdb->travlocks.hash;
/* Grab next record: locks chain and returned record,
unlocks old record */
if (tdb_next_lock(tdb, &tdb->travlocks, &rec) > 0) {
key.dsize = rec.key_len;
key.dptr = tdb_alloc_read(tdb, tdb->travlocks.off+sizeof(rec),
key.dsize);
/* Unlock the chain of this new record */
tdb_unlock(tdb, tdb->travlocks.hash, F_WRLCK);
}
/* Unlock the chain of old record */
tdb_unlock(tdb, BUCKET(oldhash), F_WRLCK);
return key;
}
/* delete an entry in the database given a key */
int tdb_delete(TDB_CONTEXT *tdb, TDB_DATA key)
{
tdb_off rec_ptr;
struct list_struct rec;
int ret;
if (!(rec_ptr = tdb_find_lock(tdb, key, F_WRLCK, &rec)))
return -1;
ret = do_delete(tdb, rec_ptr, &rec);
tdb_unlock(tdb, BUCKET(rec.full_hash), F_WRLCK);
return ret;
}
/* store an element in the database, replacing any existing element
with the same key
return 0 on success, -1 on failure
*/
int tdb_store(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, int flag)
{
struct list_struct rec;
u32 hash;
tdb_off rec_ptr;
char *p = NULL;
int ret = 0;
/* find which hash bucket it is in */
hash = tdb_hash(&key);
if (!tdb_keylocked(tdb, hash))
return -1;
if (tdb_lock(tdb, BUCKET(hash), F_WRLCK) == -1)
return -1;
/* check for it existing, on insert. */
if (flag == TDB_INSERT) {
if (tdb_exists(tdb, key)) {
tdb->ecode = TDB_ERR_EXISTS;
goto fail;
}
} else {
/* first try in-place update, on modify or replace. */
if (tdb_update(tdb, key, dbuf) == 0)
goto out;
if (flag == TDB_MODIFY && tdb->ecode == TDB_ERR_NOEXIST)
goto fail;
}
/* reset the error code potentially set by the tdb_update() */
tdb->ecode = TDB_SUCCESS;
/* delete any existing record - if it doesn't exist we don't
care. Doing this first reduces fragmentation, and avoids
coalescing with `allocated' block before it's updated. */
if (flag != TDB_INSERT)
tdb_delete(tdb, key);
/* Copy key+value *before* allocating free space in case malloc
fails and we are left with a dead spot in the tdb. */
if (!(p = (char *)malloc(key.dsize + dbuf.dsize))) {
tdb->ecode = TDB_ERR_OOM;
goto fail;
}
memcpy(p, key.dptr, key.dsize);
memcpy(p+key.dsize, dbuf.dptr, dbuf.dsize);
/* now we're into insert / modify / replace of a record which
* we know could not be optimised by an in-place store (for
* various reasons). */
if (!(rec_ptr = tdb_allocate(tdb, key.dsize + dbuf.dsize, &rec)))
goto fail;
/* Read hash top into next ptr */
if (ofs_read(tdb, TDB_HASH_TOP(hash), &rec.next) == -1)
goto fail;
rec.key_len = key.dsize;
rec.data_len = dbuf.dsize;
rec.full_hash = hash;
rec.magic = TDB_MAGIC;
/* write out and point the top of the hash chain at it */
if (rec_write(tdb, rec_ptr, &rec) == -1
|| tdb_write(tdb, rec_ptr+sizeof(rec), p, key.dsize+dbuf.dsize)==-1
|| ofs_write(tdb, TDB_HASH_TOP(hash), &rec_ptr) == -1) {
fail:
/* Need to tdb_unallocate() here */
ret = -1;
}
out:
if (p)
free(p);
tdb_unlock(tdb, BUCKET(hash), F_WRLCK);
return ret;
}
static int tdb_already_open(dev_t device,
ino_t ino)
{
TDB_CONTEXT *i;
for (i = tdbs; i; i = i->next) {
if (i->device == device && i->inode == ino) {
return 1;
}
}
return 0;
}
/* open the database, creating it if necessary
The open_flags and mode are passed straight to the open call on the
database file. A flags value of O_WRONLY is invalid. The hash size
is advisory, use zero for a default value.
Return is NULL on error, in which case errno is also set. Don't
try to call tdb_error or tdb_errname, just do strerror(errno).
@param name may be NULL for internal databases. */
TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags,
int open_flags, mode_t mode)
{
TDB_CONTEXT *tdb;
struct stat st;
int rev = 0, locked;
if (!(tdb = calloc(1, sizeof *tdb))) {
/* Can't log this */
errno = ENOMEM;
goto fail;
}
tdb->fd = -1;
tdb->name = NULL;
tdb->map_ptr = NULL;
tdb->lockedkeys = NULL;
tdb->flags = tdb_flags;
if ((open_flags & O_ACCMODE) == O_WRONLY) {
errno = EINVAL;
goto fail;
}
if (hash_size == 0)
hash_size = DEFAULT_HASH_SIZE;
if ((open_flags & O_ACCMODE) == O_RDONLY) {
tdb->read_only = 1;
/* read only databases don't do locking or clear if first */
tdb->flags |= TDB_NOLOCK;
tdb->flags &= ~TDB_CLEAR_IF_FIRST;
}
/* internal databases don't mmap or lock, and start off cleared */
if (tdb->flags & TDB_INTERNAL) {
tdb->flags |= (TDB_NOLOCK | TDB_NOMMAP);
tdb->flags &= ~TDB_CLEAR_IF_FIRST;
tdb_new_database(tdb, hash_size);
goto internal;
}
if ((tdb->fd = open(name, open_flags, mode)) == -1) {
goto fail; /* errno set by open(2) */
}
/* ensure there is only one process initialising at once */
if (tdb_brlock(tdb, GLOBAL_LOCK, F_WRLCK, F_SETLKW) == -1) {
goto fail; /* errno set by tdb_brlock */
}
/* we need to zero database if we are the only one with it open */
if ((locked = (tdb_brlock(tdb, ACTIVE_LOCK, F_WRLCK, F_SETLK) == 0))
&& (tdb_flags & TDB_CLEAR_IF_FIRST)) {
open_flags |= O_CREAT;
if (ftruncate(tdb->fd, 0) == -1) {
goto fail; /* errno set by ftruncate */
}
}
if (read(tdb->fd, &tdb->header, sizeof(tdb->header)) != sizeof(tdb->header)
|| strcmp(tdb->header.magic_food, TDB_MAGIC_FOOD) != 0
|| (tdb->header.version != TDB_VERSION
&& !(rev = (tdb->header.version==TDB_BYTEREV(TDB_VERSION))))) {
/* its not a valid database - possibly initialise it */
if (!(open_flags & O_CREAT) || tdb_new_database(tdb, hash_size) == -1) {
errno = EIO; /* ie bad format or something */
goto fail;
}
rev = (tdb->flags & TDB_CONVERT);
}
if (!rev)
tdb->flags &= ~TDB_CONVERT;
else {
tdb->flags |= TDB_CONVERT;
convert(&tdb->header, sizeof(tdb->header));
}
if (fstat(tdb->fd, &st) == -1)
goto fail;
/* Is it already in the open list? If so, fail. */
if (tdb_already_open(st.st_dev, st.st_ino)) {
errno = EBUSY;
goto fail;
}
if (!(tdb->name = (char *)strdup(name))) {
errno = ENOMEM;
goto fail;
}
tdb->map_size = st.st_size;
tdb->device = st.st_dev;
tdb->inode = st.st_ino;
tdb->locked = calloc(tdb->header.hash_size+1, sizeof(tdb->locked[0]));
if (!tdb->locked) {
errno = ENOMEM;
goto fail;
}
tdb_mmap(tdb);
if (locked) {
if (tdb_brlock(tdb, ACTIVE_LOCK, F_UNLCK, F_SETLK) == -1) {
goto fail;
}
}
/* leave this lock in place to indicate it's in use */
if (tdb_brlock(tdb, ACTIVE_LOCK, F_RDLCK, F_SETLKW) == -1)
goto fail;
internal:
/* Internal (memory-only) databases skip all the code above to
* do with disk files, and resume here by releasing their
* global lock and hooking into the active list. */
if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW) == -1)
goto fail;
tdb->next = tdbs;
tdbs = tdb;
return tdb;
fail:
{ int save_errno = errno;
if (!tdb)
return NULL;
if (tdb->map_ptr) {
if (tdb->flags & TDB_INTERNAL)
free(tdb->map_ptr);
else
tdb_munmap(tdb);
}
if (tdb->name)
free(tdb->name);
if (tdb->fd != -1)
close(tdb->fd);
if (tdb->locked)
free(tdb->locked);
errno = save_errno;
return NULL;
}
}
/* close a database */
int tdb_close(TDB_CONTEXT *tdb)
{
TDB_CONTEXT **i;
int ret = 0;
if (tdb->map_ptr) {
if (tdb->flags & TDB_INTERNAL)
free(tdb->map_ptr);
else
tdb_munmap(tdb);
}
if (tdb->name)
free(tdb->name);
if (tdb->fd != -1)
ret = close(tdb->fd);
if (tdb->locked)
free(tdb->locked);
if (tdb->lockedkeys)
free(tdb->lockedkeys);
/* Remove from contexts list */
for (i = &tdbs; *i; i = &(*i)->next) {
if (*i == tdb) {
*i = tdb->next;
break;
}
}
memset(tdb, 0, sizeof(*tdb));
free(tdb);
return ret;
}
/* lock/unlock entire database */
int tdb_lockall(TDB_CONTEXT *tdb)
{
u32 i;
/* There are no locks on read-only dbs */
if (tdb->read_only)
return TDB_ERRCODE(TDB_ERR_LOCK, -1);
if (tdb->lockedkeys)
return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
for (i = 0; i < tdb->header.hash_size; i++)
if (tdb_lock(tdb, i, F_WRLCK))
break;
/* If error, release locks we have... */
if (i < tdb->header.hash_size) {
u32 j;
for ( j = 0; j < i; j++)
tdb_unlock(tdb, j, F_WRLCK);
return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
}
return 0;
}
void tdb_unlockall(TDB_CONTEXT *tdb)
{
u32 i;
for (i=0; i < tdb->header.hash_size; i++)
tdb_unlock(tdb, i, F_WRLCK);
}
int tdb_lockkeys(TDB_CONTEXT *tdb, u32 number, TDB_DATA keys[])
{
u32 i, j, hash;
/* Can't lock more keys if already locked */
if (tdb->lockedkeys)
return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
if (!(tdb->lockedkeys = malloc(sizeof(u32) * (number+1))))
return TDB_ERRCODE(TDB_ERR_OOM, -1);
/* First number in array is # keys */
tdb->lockedkeys[0] = number;
/* Insertion sort by bucket */
for (i = 0; i < number; i++) {
hash = tdb_hash(&keys[i]);
for (j = 0; j < i && BUCKET(tdb->lockedkeys[j+1]) < BUCKET(hash); j++);
memmove(&tdb->lockedkeys[j+2], &tdb->lockedkeys[j+1], sizeof(u32) * (i-j));
tdb->lockedkeys[j+1] = hash;
}
/* Finally, lock in order */
for (i = 0; i < number; i++)
if (tdb_lock(tdb, i, F_WRLCK))
break;
/* If error, release locks we have... */
if (i < number) {
for ( j = 0; j < i; j++)
tdb_unlock(tdb, j, F_WRLCK);
free(tdb->lockedkeys);
tdb->lockedkeys = NULL;
return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
}
return 0;
}
/* Unlock the keys previously locked by tdb_lockkeys() */
void tdb_unlockkeys(TDB_CONTEXT *tdb)
{
u32 i;
for (i = 0; i < tdb->lockedkeys[0]; i++)
tdb_unlock(tdb, tdb->lockedkeys[i+1], F_WRLCK);
free(tdb->lockedkeys);
tdb->lockedkeys = NULL;
}
/* lock/unlock one hash chain. This is meant to be used to reduce
contention - it cannot guarantee how many records will be locked */
int tdb_chainlock(TDB_CONTEXT *tdb, TDB_DATA key)
{
return tdb_lock(tdb, BUCKET(tdb_hash(&key)), F_WRLCK);
}
void tdb_chainunlock(TDB_CONTEXT *tdb, TDB_DATA key)
{
tdb_unlock(tdb, BUCKET(tdb_hash(&key)), F_WRLCK);
}
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-02-25 1:41 Rusty Russell
2002-02-25 1:58 ` your mail Alexander Viro
@ 2002-02-25 13:16 ` Alan Cox
1 sibling, 0 replies; 669+ messages in thread
From: Alan Cox @ 2002-02-25 13:16 UTC (permalink / raw)
To: Rusty Russell
Cc: Linus Torvalds, mingo, Matthew Kirkwood, Benjamin LaHaise,
David Axmark, William Lee Irwin III, linux-kernel
> > fd = sem_initialize();
> > mmap(fd, ...)
> > ..
> > munmap(..)
> >
> > which gives you a handle for the semaphore.
>
> No no no! Implemented exactly that (and posted to l-k IIRC), and it's
> *horrible* to use.
All Linus forgot was to sem_initialize("filename"); With that the rest
comes out for free.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-01-30 18:21 Nickolaos Fotopoulos
2002-01-30 18:57 ` your mail Matti Aarnio
2002-01-31 1:50 ` Drew P. Vogel
0 siblings, 2 replies; 669+ messages in thread
From: Nickolaos Fotopoulos @ 2002-01-30 18:21 UTC (permalink / raw)
To: Linux kernel list (E-mail)
I'm new to this list. Does it get spammed often, like this guy
(grumph@pakistanmail.com) is doing? It is allready becoming quite anouying!
This is by far the busiest list I have ever subscribed to, and there does
not seem to be any sort of spam blocker working here. I thought Majodomo
had stuff like this built in? If not maybe a list moderator could address
this.
Nick Fotopoulos
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-01-30 18:21 Nickolaos Fotopoulos
@ 2002-01-30 18:57 ` Matti Aarnio
2002-01-31 1:50 ` Drew P. Vogel
1 sibling, 0 replies; 669+ messages in thread
From: Matti Aarnio @ 2002-01-30 18:57 UTC (permalink / raw)
To: Nickolaos Fotopoulos; +Cc: Linux kernel list (E-mail)
On Wed, Jan 30, 2002 at 01:21:17PM -0500, Nickolaos Fotopoulos wrote:
> I'm new to this list. Does it get spammed often, like this guy
> (grumph@pakistanmail.com) is doing? It is allready becoming quite anouying!
I already asked about the phenomena, and the guy(?) replied that
he won't use that system anymore as it is doing those repeated
sends all by itself.
> This is by far the busiest list I have ever subscribed to, and there does
> not seem to be any sort of spam blocker working here. I thought Majodomo
> had stuff like this built in? If not maybe a list moderator could address
> this.
http://vger.kernel.org/majordomo-info.html
Trust me, there is HEAVY filtering.
Still some spams do get thru.
> Nick Fotopoulos
/Matti Aarnio
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-01-30 18:21 Nickolaos Fotopoulos
2002-01-30 18:57 ` your mail Matti Aarnio
@ 2002-01-31 1:50 ` Drew P. Vogel
1 sibling, 0 replies; 669+ messages in thread
From: Drew P. Vogel @ 2002-01-31 1:50 UTC (permalink / raw)
To: Nickolaos Fotopoulos; +Cc: Linux kernel list (E-mail)
Personally, when I'm getting a few hundred emails per day, I don't even
notice the 5% spam.
--Drew Vogel
On Wed, 30 Jan 2002, Nickolaos Fotopoulos wrote:
>I'm new to this list. Does it get spammed often, like this guy
>(grumph@pakistanmail.com) is doing? It is allready becoming quite anouying!
>This is by far the busiest list I have ever subscribed to, and there does
>not seem to be any sort of spam blocker working here. I thought Majodomo
>had stuff like this built in? If not maybe a list moderator could address
>this.
> Nick Fotopoulos
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-01-09 17:49 Michael Zhu
2002-01-09 18:17 ` your mail Jens Axboe
0 siblings, 1 reply; 669+ messages in thread
From: Michael Zhu @ 2002-01-09 17:49 UTC (permalink / raw)
To: root; +Cc: linux-kernel
>
> This may be a troll. How would you boot? Who
decrypts during the
> boot?
>
You mean that the loop device couldn't en/decrypt the
whole data on the disk? That mean the loop device
could implement the block level en/decryption.
Michael
______________________________________________________________________
Web-hosting solutions for home and business! http://website.yahoo.ca
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2002-01-09 17:49 Michael Zhu
@ 2002-01-09 18:17 ` Jens Axboe
0 siblings, 0 replies; 669+ messages in thread
From: Jens Axboe @ 2002-01-09 18:17 UTC (permalink / raw)
To: Michael Zhu; +Cc: root, linux-kernel
On Wed, Jan 09 2002, Michael Zhu wrote:
> >
> > This may be a troll. How would you boot? Who
> decrypts during the
> > boot?
> >
>
> You mean that the loop device couldn't en/decrypt the
> whole data on the disk? That mean the loop device
> could implement the block level en/decryption.
Please, read up on the loop crypto stuff off-list. Most of these
questions are very FAQ. You can loop crypto a whole disk or partition of
you want.
--
Jens Axboe
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2002-01-02 14:20 mehul radheshyam choube
2002-01-03 16:40 ` your mail Rik van Riel
0 siblings, 1 reply; 669+ messages in thread
From: mehul radheshyam choube @ 2002-01-02 14:20 UTC (permalink / raw)
To: linux-mm
hi friends,
i would like to do some developement work for linux-mm
please guide me .
mehul.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-12-17 16:07 Sebastian Dröge
2001-12-17 16:22 ` your mail Dave Jones
2001-12-17 16:52 ` Sebastian Dröge
0 siblings, 2 replies; 669+ messages in thread
From: Sebastian Dröge @ 2001-12-17 16:07 UTC (permalink / raw)
To: davej; +Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 697 bytes --]
Hi,
Here's a more or less critical problem with 2.5.1-dj1 :(
This is a Pentium II 350 with 256 MB RAM and Intel BX chipset
It can't find any ISA-PnP cards (I only have an old SB16 ISA-PnP ;) ) in my pc
> Limiting direct PCI/PCI transfers.
> isapnp: Scanning for PnP cards...
> isapnp: No Plug & Play device found
And it has big problems with usb.
Only the root hub is detected but nothing else...
> hub.c: Cannot enable port 1 of hub 1, disabling port.
> hub.c: Maybe the USB cable is bad?
The cable is okay...
2.5.1 works perfectly... but only without dj1 :(
Attached you find my .config, lspci -vvv and dmesg output
I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)
Bye
[-- Attachment #1.2: dmesg.out --]
[-- Type: application/octet-stream, Size: 6472 bytes --]
Linux version 2.5.1-dj1 (root@slomosnail) (gcc version 2.95.3 20010315 (release)) #1 Mon Dez 17 15:56:04 CET 2001
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
CPU: Before vendor init, caps: 0183f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After vendor init, caps: 0183f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: BOOT_IMAGE=linux-devel ro root=341 hdc=scsi hdd=scsi
ide_setup: hdc=scsi
ide_setup: hdd=scsi
Initializing CPU#0
Detected 350.803 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 699.59 BogoMIPS
Memory: 255468k/262144k available (1378k kernel code, 6292k reserved, 346k data, 220k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000040
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 350.7948 MHz.
..... host bus clock speed is 100.2270 MHz.
cpu: 0, clocks: 1002270, slice: 501135
CPU0<T0:1002256,T1:501120,D:1,S:501135,C:1002270>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.15)
Starting kswapd
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec: init pool 0, 1 entries, 12 bytes
biovec: init pool 1, 4 entries, 48 bytes
biovec: init pool 2, 16 entries, 192 bytes
biovec: init pool 3, 64 entries, 768 bytes
biovec: init pool 4, 128 entries, 1536 bytes
biovec: init pool 5, 256 entries, 3072 bytes
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.10e
block: 256 slots per queue, batch=32
Uniform Multi-Platform E-IDE driver Revision: 6.32
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI slot 00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
keyboard: Timeout - AT keyboard not present?(ed)
keyboard: Timeout - AT keyboard not present?(f4)
hda: IBM-DTTA-351010, ATA DISK drive
hdb: WDC WD800BB-00BSA0, ATA DISK drive
hdc: CD-W512EB, ATAPI CD/DVD-ROM drive
hdd: CD-532E-B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c03140c4, I/O limit 4095Mb (mask 0xffffffff)
hda: 19807200 sectors (10141 MB) w/466KiB Cache, CHS=1232/255/63, UDMA(33)
blk: queue c0314224, I/O limit 4095Mb (mask 0xffffffff)
hdb: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(33)
Partition check:
hda: hda1 hda2 hda4
hdb: hdb1 hdb2
dmfe: Davicom DM9xxx net driver, version 1.36.3 (2001-11-06)
PCI: Found IRQ 12 for device 00:10.0
eth0: Davicom DM9102 at pci00:10.0, 00:00:ab:a1:27:8c, irq 12.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 204M
agpgart: Detected Intel 440BX chipset
agpgart: AGP aperture is 64M @ 0xe8000000
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: TEAC Model: CD-W512EB Rev: 2.0E
Type: CD-ROM ANSI SCSI revision: 02
Vendor: TEAC Model: CD-532E-B Rev: 3.0B
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sr1: scsi3-mmc drive: 32x/32x cd/rw xa/form2 cdda tray
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: No ISAPnP cards found, trying standard ones...
sb: I/O, IRQ, and DMA are mandatory
usb.c: registered new driver usbfs
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 10 for device 00:07.2
uhci.c: USB UHCI at I/O 0xe000, IRQ 10
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
reiserfs: checking transaction log (device 03:41) ...
Using r5 hash to sort names
reiserfs: using 3.5.x disk format
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 220k freed
Adding Swap: 273096k swap-space (priority -1)
hub.c: Cannot enable port 1 of hub 1, disabling port.
hub.c: Maybe the USB cable is bad?
reiserfs: checking transaction log (device 03:42) ...
Using r5 hash to sort names
reiserfs: using 3.5.x disk format
ReiserFS version 3.6.25
blk: queue c03140c4, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c0314224, I/O limit 4095Mb (mask 0xffffffff)
[-- Attachment #1.3: lspci.out --]
[-- Type: application/octet-stream, Size: 3864 bytes --]
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 1.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP+ 64bit- FW- Rate=x2
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: ec000000-edffffff
Prefetchable memory behind bridge: e0000000-e7ffffff
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B+
00:07.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at f000 [size=16]
00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin D routed to IRQ 10
Region 4: I/O ports at e000 [size=32]
00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
00:10.0 Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 10)
Subsystem: Davicom Semiconductor, Inc. Ethernet 100/10 MBit
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (5000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 12
Region 0: I/O ports at e400 [size=128]
Region 1: Memory at ef000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at ee000000 [disabled] [size=256K]
Capabilities: [50] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV11 (GeForce2 MX) (rev a1) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at ed000000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=x2
[-- Attachment #1.4: .config --]
[-- Type: application/octet-stream, Size: 21433 bytes --]
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PPRO_FENCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
CONFIG_PCI_GODIRECT=y
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
CONFIG_APM_IGNORE_USER_SUSPEND=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_PDC202XX_FORCE is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_IVB=y
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
#
# SCSI support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_DEBUG is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
CONFIG_DM9102=y
# CONFIG_EEPRO100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Input core support
#
CONFIG_INPUT=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_INPUT_NS558 is not set
# CONFIG_INPUT_LIGHTNING is not set
# CONFIG_INPUT_PCIGAME is not set
# CONFIG_INPUT_CS461X is not set
# CONFIG_INPUT_EMU10K1 is not set
# CONFIG_INPUT_SERIO is not set
# CONFIG_INPUT_SERPORT is not set
#
# Joysticks
#
# CONFIG_INPUT_ANALOG is not set
# CONFIG_INPUT_A3D is not set
# CONFIG_INPUT_ADI is not set
# CONFIG_INPUT_COBRA is not set
# CONFIG_INPUT_GF2K is not set
# CONFIG_INPUT_GRIP is not set
# CONFIG_INPUT_INTERACT is not set
# CONFIG_INPUT_TMDC is not set
# CONFIG_INPUT_SIDEWINDER is not set
# CONFIG_INPUT_IFORCE_USB is not set
# CONFIG_INPUT_IFORCE_232 is not set
# CONFIG_INPUT_WARRIOR is not set
# CONFIG_INPUT_MAGELLAN is not set
# CONFIG_INPUT_SPACEORB is not set
# CONFIG_INPUT_SPACEBALL is not set
# CONFIG_INPUT_STINGER is not set
# CONFIG_INPUT_DB9 is not set
# CONFIG_INPUT_GAMECON is not set
# CONFIG_INPUT_TURBOGRAFX is not set
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_I810 is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_TMPFS is not set
# CONFIG_RAMFS is not set
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
CONFIG_ZISOFS_FS=m
CONFIG_ZLIB_FS_INFLATE=m
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Sound
#
CONFIG_SOUND=y
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_MIDI_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_MIDI_VIA82CXXX is not set
CONFIG_SOUND_OSS=y
# CONFIG_SOUND_TRACEINIT is not set
# CONFIG_SOUND_DMAP is not set
# CONFIG_SOUND_AD1816 is not set
# CONFIG_SOUND_SGALAXY is not set
# CONFIG_SOUND_ADLIB is not set
# CONFIG_SOUND_ACI_MIXER is not set
# CONFIG_SOUND_CS4232 is not set
# CONFIG_SOUND_SSCAPE is not set
# CONFIG_SOUND_GUS is not set
# CONFIG_SOUND_VMIDI is not set
# CONFIG_SOUND_TRIX is not set
# CONFIG_SOUND_MSS is not set
# CONFIG_SOUND_MPU401 is not set
# CONFIG_SOUND_NM256 is not set
# CONFIG_SOUND_MAD16 is not set
# CONFIG_SOUND_PAS is not set
# CONFIG_PAS_JOYSTICK is not set
# CONFIG_SOUND_PSS is not set
CONFIG_SOUND_SB=y
# CONFIG_SOUND_AWE32_SYNTH is not set
# CONFIG_SOUND_WAVEFRONT is not set
# CONFIG_SOUND_MAUI is not set
# CONFIG_SOUND_YM3812 is not set
# CONFIG_SOUND_OPL3SA1 is not set
# CONFIG_SOUND_OPL3SA2 is not set
# CONFIG_SOUND_YMFPCI is not set
# CONFIG_SOUND_YMFPCI_LEGACY is not set
# CONFIG_SOUND_UART6850 is not set
# CONFIG_SOUND_AEDSP16 is not set
# CONFIG_SOUND_TVMIXER is not set
#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set
#
# USB Controllers
#
CONFIG_USB_UHCI_ALT=y
# CONFIG_USB_OHCI is not set
#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_WACOM is not set
#
# USB Imaging devices
#
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set
#
# USB Multimedia devices
#
#
# Video4Linux support is needed for USB Multimedia device support
#
#
# USB Network adaptors
#
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_RIO500 is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-12-17 16:07 Sebastian Dröge
@ 2001-12-17 16:22 ` Dave Jones
2001-12-17 16:52 ` Sebastian Dröge
1 sibling, 0 replies; 669+ messages in thread
From: Dave Jones @ 2001-12-17 16:22 UTC (permalink / raw)
To: Sebastian Dröge; +Cc: Linux Kernel Mailing List
On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> Attached you find my .config, lspci -vvv and dmesg output
> I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)
Thanks. Right now getting 2.4 into a better shape is more
important than fixing 2.5, so if you find any problems repeatable
in 2.4.17rc1, Marcelo really needs to know about it.
The only USB changes in my tree are __devinit_p changes, which
really shouldn't be causing a problem, but there could be some
other unrelated-to-usb patch which is causing this..
2.4 info would be appreciated.
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-17 16:07 Sebastian Dröge
2001-12-17 16:22 ` your mail Dave Jones
@ 2001-12-17 16:52 ` Sebastian Dröge
2001-12-17 16:55 ` Arnaldo Carvalho de Melo
2001-12-17 17:23 ` Sebastian Dröge
1 sibling, 2 replies; 669+ messages in thread
From: Sebastian Dröge @ 2001-12-17 16:52 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel, torvalds
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
Ok...
2.4.16-2.4.17-rc1 works perfectly
2.5.0-2.5.1 works perfectly
Only 2.5.1-dj1 has this 2 errors (ISA-PnP non-detection and USB only root hub detection)
All have the same .config
If you need some more information feel free to ask me ;)
Bye
PS: 2.5.1 (dj1 or not ;) has one problem more on my pc:
INIT can't send the TERM signal to all processes...
Nothing happens... no error message no nothing
SysRQ works
I don't know when it went into 2.5 but I think it wasn't there in -pre10 (don't try -pre11)
PPS: What the hell is APIC (no I don't mean ACPI)? ;) I've enabled it on my UP machine but don't know what it does...
Does anyone have informations about it?
On Mon, 17 Dec 2001 17:22:14 +0100 (CET)
Dave Jones <davej@suse.de> wrote:
> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
>
> > Attached you find my .config, lspci -vvv and dmesg output
> > I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)
>
> Thanks. Right now getting 2.4 into a better shape is more
> important than fixing 2.5, so if you find any problems repeatable
> in 2.4.17rc1, Marcelo really needs to know about it.
>
> The only USB changes in my tree are __devinit_p changes, which
> really shouldn't be causing a problem, but there could be some
> other unrelated-to-usb patch which is causing this..
>
> 2.4 info would be appreciated.
>
> Dave.
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-17 16:52 ` Sebastian Dröge
@ 2001-12-17 16:55 ` Arnaldo Carvalho de Melo
2001-12-17 17:23 ` Sebastian Dröge
1 sibling, 0 replies; 669+ messages in thread
From: Arnaldo Carvalho de Melo @ 2001-12-17 16:55 UTC (permalink / raw)
To: Sebastian, =?iso-8859-1?Q?Dr=F6ge_=3Csebastian=2Edroege=40gmx=2Ede=3E?=
Cc: Dave Jones, linux-kernel, torvalds
Em Mon, Dec 17, 2001 at 05:52:06PM +0100, Sebastian Dröge escreveu:
> PS: 2.5.1 (dj1 or not ;) has one problem more on my pc:
> INIT can't send the TERM signal to all processes...
see the kill(-1,sig) thread...
> Nothing happens... no error message no nothing
> SysRQ works
> I don't know when it went into 2.5 but I think it wasn't there in -pre10 (don't try -pre11)
> PPS: What the hell is APIC (no I don't mean ACPI)? ;) I've enabled it on my UP machine but don't know what it does...
> Does anyone have informations about it?
Advanced Programmable Interrupt Controller, found in SMP machines and in
some UP ones, for UP its shouldn't be enabled in most cases.
- Arnaldo
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-17 16:52 ` Sebastian Dröge
2001-12-17 16:55 ` Arnaldo Carvalho de Melo
@ 2001-12-17 17:23 ` Sebastian Dröge
2001-12-17 17:25 ` Dave Jones
2001-12-17 18:42 ` Sebastian Dröge
1 sibling, 2 replies; 669+ messages in thread
From: Sebastian Dröge @ 2001-12-17 17:23 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
Thanks
This does work
What do you think was exactly the problem?
Bye
On Mon, 17 Dec 2001 17:57:01 +0100 (CET)
Dave Jones <davej@suse.de> wrote:
> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
>
> > 2.4.16-2.4.17-rc1 works perfectly
> > 2.5.0-2.5.1 works perfectly
> > Only 2.5.1-dj1 has this 2 errors (ISA-PnP non-detection and USB only root hub detection)
> > All have the same .config
> > If you need some more information feel free to ask me ;)
>
> Ok, can you try backing out this patch.. (just patch as normal but with -R)
> http://www.codemonkey.org.uk/patches/2.5/small-bits/early-cpuinit-1.diff
>
> regards,
> Dave.
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-17 17:23 ` Sebastian Dröge
@ 2001-12-17 17:25 ` Dave Jones
2001-12-17 18:42 ` Sebastian Dröge
1 sibling, 0 replies; 669+ messages in thread
From: Dave Jones @ 2001-12-17 17:25 UTC (permalink / raw)
To: Sebastian Dröge; +Cc: linux-kernel
On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> Thanks
> This does work
Great, now can you edit the patch to remove the ioapic.c hunk,
reapply, and see if that works..
> What do you think was exactly the problem?
looks like I dorked the apic init...
I'll back that bit out for -dj2, until I've given
it a bit more work.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-17 17:23 ` Sebastian Dröge
2001-12-17 17:25 ` Dave Jones
@ 2001-12-17 18:42 ` Sebastian Dröge
2001-12-17 18:43 ` Dave Jones
1 sibling, 1 reply; 669+ messages in thread
From: Sebastian Dröge @ 2001-12-17 18:42 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Hmm...
I don't see anything about ioapic.c in the patch...
So I removed the apic.c hunk
I think you meant that ;)
Anyway this doesn't solve the problem :(
Bye
On Mon, 17 Dec 2001 18:25:37 +0100 (CET)
Dave Jones <davej@suse.de> wrote:
> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
>
> > Thanks
> > This does work
>
> Great, now can you edit the patch to remove the ioapic.c hunk,
> reapply, and see if that works..
>
> > What do you think was exactly the problem?
>
> looks like I dorked the apic init...
> I'll back that bit out for -dj2, until I've given
> it a bit more work.
>
> regards,
> Dave.
>
> --
> | Dave Jones. http://www.codemonkey.org.uk
> | SuSE Labs
>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <20011214041151.91557.qmail@web14904.mail.yahoo.com>]
* Re: your mail
[not found] <20011214041151.91557.qmail@web14904.mail.yahoo.com>
@ 2001-12-14 16:46 ` Gérard Roudier
2001-12-14 20:09 ` Jens Axboe
2001-12-18 0:34 ` Kirk Alexander
2001-12-14 20:34 ` Jens Axboe
2001-12-15 0:56 ` Stephan von Krawczynski
2 siblings, 2 replies; 669+ messages in thread
From: Gérard Roudier @ 2001-12-14 16:46 UTC (permalink / raw)
To: Kirk Alexander; +Cc: Jens Axboe, linux-kernel
On Fri, 14 Dec 2001, Kirk Alexander wrote:
> [cc'ed to lkml and Gerard Roudier]
>
> Hi Jens,
>
> You asked people to send in reports of which drivers
> were broken by the removal of io_request_lock.
>
> My system is a clunky old Digital Pentium Pro with a
> NCR53c810 rev 2 scsi controller, so it can't use the
> sym driver.
Use sym53c8xx_2 instead. This one uses 2 different firmwares,
- one based on sym53c8xx driver scripts called
'LOAD/STORE based' firmware,
- and another one that only uses generic scripts instructions
and called 'GENERIC' firmware.
The GENERIC firmware has worked for me witn a 810 rev. 2.
I haven't this controller installed at the moment, but I can test the
driver by forcing the driver to use the GENERIC scripts instead for any
symbios chip.
You may let me know if sym53c8xx_2 still works with 810 rev 2.
> I fixed the problem by seeing what the sym
> driver did i.e. the patch below
> This may not be right at all, and I haven't had a
> chance to boot the kernel - but it did build OK.
The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
reliability and performance.
Gérard.
> Cheers,
> Kirk Alexander
>
> P.S.
> Please excuse me if this has already been fixed or
> posted, or if I've broken some lkml etiquette - first
> post I think after lurking off and on for ages. Also
> first time I've compiled a kernel that has only been
> out a few days!
You are welcome and you didn't break any etiquette. The lkml is a very
open mailing list but it gets more than 200 postings a day. Thus the
linux-scsi@vger.kernel.org list should be preferred for topics that
address scsi specifically.
> --- linux/drivers/scsi/sym53c8xx_comm.h Fri Dec 14
> 16:46:45 2001
> +++ linux/drivers/scsi/sym53c8xx_comm.h Fri Dec 14
> 16:49:19 2001
> @@ -438,11 +438,20 @@
> #define NCR_LOCK_NCB(np, flags)
> spin_lock_irqsave(&np->smp_lock, flags)
> #define NCR_UNLOCK_NCB(np, flags)
> spin_unlock_irqrestore(&np->smp_lock, flags)
>
> +#if LINUX_VERSION_CODE >= LinuxVersionCode(2,5,0)
> +
> +#define NCR_LOCK_SCSI_DONE(np, flags) \
> + spin_lock_irqsave((np)->done_list->host, flags)
> +#define NCR_UNLOCK_SCSI_DONE(np, flags) \
> + spin_unlock_irqrestore((np)->done_list->host,
> flags)
> +#else
> +
> #define NCR_LOCK_SCSI_DONE(np, flags) \
> spin_lock_irqsave(&io_request_lock, flags)
> #define NCR_UNLOCK_SCSI_DONE(np, flags) \
> spin_unlock_irqrestore(&io_request_lock, flags)
>
> +#endif
> #else
>
> #define NCR_LOCK_DRIVER(flags) do {
> save_flags(flags); cli(); } while (0)
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-12-14 16:46 ` Gérard Roudier
@ 2001-12-14 20:09 ` Jens Axboe
2001-12-14 18:05 ` Gérard Roudier
2001-12-18 0:34 ` Kirk Alexander
1 sibling, 1 reply; 669+ messages in thread
From: Jens Axboe @ 2001-12-14 20:09 UTC (permalink / raw)
To: Gérard Roudier; +Cc: Kirk Alexander, linux-kernel
On Fri, Dec 14 2001, Gérard Roudier wrote:
> > I fixed the problem by seeing what the sym
> > driver did i.e. the patch below
> > This may not be right at all, and I haven't had a
> > chance to boot the kernel - but it did build OK.
>
> The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
> Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
> quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
> it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
> reliability and performance.
Gerard,
For 2.5, why don't we just yank old sym and ncr out of the kernel? Is
there _any_ reason to keep the two older ones given your new driver
handles it all?
--
Jens Axboe
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-14 20:09 ` Jens Axboe
@ 2001-12-14 18:05 ` Gérard Roudier
2001-12-14 22:26 ` Peter Bornemann
0 siblings, 1 reply; 669+ messages in thread
From: Gérard Roudier @ 2001-12-14 18:05 UTC (permalink / raw)
To: Jens Axboe; +Cc: Kirk Alexander, linux-kernel
On Fri, 14 Dec 2001, Jens Axboe wrote:
> On Fri, Dec 14 2001, Gérard Roudier wrote:
> > > I fixed the problem by seeing what the sym
> > > driver did i.e. the patch below
> > > This may not be right at all, and I haven't had a
> > > chance to boot the kernel - but it did build OK.
> >
> > The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
> > Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
> > quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
> > it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
> > reliability and performance.
>
> Gerard,
>
> For 2.5, why don't we just yank old sym and ncr out of the kernel? Is
> there _any_ reason to keep the two older ones given your new driver
> handles it all?
On my side, there is obviously no reason to keep them in 2.5, as sym-2 is
intended to replace them both. Personnaly I have switched to sym-2 on my
systems since several months.
However, I donnot consider myself as the only owner of these drivers. The
owners are all people that may need symbios chips support under Linux. My
personnal vote, as a user/owner, is to remove them and rely for symbios
chip support on sym-2.
--
Linux stable is a different issue. For this one, I would prefer the old
drivers to remain in place for a longer time. However, I personnaly will
not track bugs on old drivers if either,
- The problem also shows up in sym-2. Then I will try to fix sym-2,
- Or the problem simply doesn't occur in sym-2.
This will apply to problems reported directly by users or by packagers.
By the way, for now, I haven't received any report about sym-2 failing
when sym-1 or ncr succeeds, and my feeling is that this could well be very
unlikely.
But I can make mistakes, me too. :-)
Gérard.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-14 18:05 ` Gérard Roudier
@ 2001-12-14 22:26 ` Peter Bornemann
2001-12-14 20:16 ` Gérard Roudier
0 siblings, 1 reply; 669+ messages in thread
From: Peter Bornemann @ 2001-12-14 22:26 UTC (permalink / raw)
To: Gérard Roudier; +Cc: Jens Axboe, Kirk Alexander, linux-kernel
On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> By the way, for now, I haven't received any report about sym-2 failing
> when sym-1 or ncr succeeds, and my feeling is that this could well be very
> unlikely.
>
Ahemm -- well,
maybe I'm the first one. I have a symbios card, which is recognized by
lspci: SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
(formerly NCR) 53c810 (rev 23).
This card goes into an endless loop during parity-checking. So tried to
disable it for the new sym53cxx in modules.conf:
options sym53c8xx mpar:n spar:n
This did not help in this case, however.
There have been so far three ways to solve this problem:
1. Use the very old ncr53c7,8 or so driver. This is working rather
unreliable for me.
2. Use the ncr53c8xx, which works usually well
3. Use sym53c8xx(old) compiled with parity disabled
Probably there is a way around that, but somebody trying to install Linux
from a SCSI-CDROM with this card for the first time will very likely not
succeed. I have seen this with (for instance) Corel-Linux and FreeBSD
(same driver).
NB Parity checking for me is not really all that important as there is no
hardrive connected to that card. Only CD and scanner.
Peter B
. .
|\_-^^^-_/|
/ (|)_(|) \
( === X === )
\ ._|_. /
^-_ _-^
°°°
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-12-14 22:26 ` Peter Bornemann
@ 2001-12-14 20:16 ` Gérard Roudier
2001-12-15 0:54 ` Peter Bornemann
0 siblings, 1 reply; 669+ messages in thread
From: Gérard Roudier @ 2001-12-14 20:16 UTC (permalink / raw)
To: Peter Bornemann; +Cc: Jens Axboe, Kirk Alexander, linux-kernel
On Fri, 14 Dec 2001, Peter Bornemann wrote:
> On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> > By the way, for now, I haven't received any report about sym-2 failing
> > when sym-1 or ncr succeeds, and my feeling is that this could well be very
> > unlikely.
> >
>
> Ahemm -- well,
> maybe I'm the first one. I have a symbios card, which is recognized by
> lspci: SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> (formerly NCR) 53c810 (rev 23).
>
> This card goes into an endless loop during parity-checking. So tried to
> disable it for the new sym53cxx in modules.conf:
> options sym53c8xx mpar:n spar:n
> This did not help in this case, however.
>
> There have been so far three ways to solve this problem:
> 1. Use the very old ncr53c7,8 or so driver. This is working rather
> unreliable for me.
> 2. Use the ncr53c8xx, which works usually well
> 3. Use sym53c8xx(old) compiled with parity disabled
>
> Probably there is a way around that, but somebody trying to install Linux
> from a SCSI-CDROM with this card for the first time will very likely not
> succeed. I have seen this with (for instance) Corel-Linux and FreeBSD
> (same driver).
> NB Parity checking for me is not really all that important as there is no
> hardrive connected to that card. Only CD and scanner.
About what parity sort are you talking about ?
PCI parity ? SCSI parity ?
PCI parity checking is not an option. If it is this one, then your
hardware is simply broken. For such broken hardwares that returns such
spurious PCI parity error early during HBA probing, sym-2 can detect this
and disable PCI parity checking. This has been reported to work well under
FreeBSD. And sym-2 is also supposed to accept the manual disabling, either
by compiled-in option or using the mpar=n boot-up options.
For SCSI parity, which is different matter, both drivers try to cope and
still sym-2 should accept the spar=n boot-up option.
Could you, please, report me more accurate information.
TIA,
Gérard.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-14 20:16 ` Gérard Roudier
@ 2001-12-15 0:54 ` Peter Bornemann
2001-12-15 6:57 ` Gérard Roudier
0 siblings, 1 reply; 669+ messages in thread
From: Peter Bornemann @ 2001-12-15 0:54 UTC (permalink / raw)
To: Gérard Roudier
Cc: Peter Bornemann, Jens Axboe, Kirk Alexander, linux-kernel
On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
>
>
> On Fri, 14 Dec 2001, Peter Bornemann wrote:
> > Ahemm -- well,
> > maybe I'm the first one. I have a symbios card, which is recognized by
> > lspci: SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> > (formerly NCR) 53c810 (rev 23).
> Could you, please, report me more accurate information.
> TIA,
>
Well, it seems I made my intention not very clear: I do not want You to
fix something in the driver, I just wanted from You to leave the old
ncr-driver in the kernel, just for the situation of a first install. I
think no newbie with little knowledge will be able to install Linux (or,
maybe, FreeBSD), when he happens to own such an controller. First, he
won't be able to read very much on the screen, for the loop runs much too
fast and second, he will not understand when he reads something about a
sym53c8xx. Exactly for this case I think the old driver should be left in.
If You want, You can tell him "Attention! Use of this driver deprecated.
Contact Your support." or whatever seems appropriate. It is just about the
first step to linuxland :-)
Hope I managed to make myself clear tris time
Peter B
. .
|\_-^^^-_/|
/ (|)_(|) \
( === X === )
\ ._|_. /
^-_ _-^
°°°
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-12-15 0:54 ` Peter Bornemann
@ 2001-12-15 6:57 ` Gérard Roudier
0 siblings, 0 replies; 669+ messages in thread
From: Gérard Roudier @ 2001-12-15 6:57 UTC (permalink / raw)
To: Peter Bornemann; +Cc: Jens Axboe, Kirk Alexander, linux-kernel
On Sat, 15 Dec 2001, Peter Bornemann wrote:
> On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
>
> >
> >
> > On Fri, 14 Dec 2001, Peter Bornemann wrote:
> > > Ahemm -- well,
> > > maybe I'm the first one. I have a symbios card, which is recognized by
> > > lspci: SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> > > (formerly NCR) 53c810 (rev 23).
> > Could you, please, report me more accurate information.
> > TIA,
> >
>
> Well, it seems I made my intention not very clear: I do not want You to
> fix something in the driver, I just wanted from You to leave the old
> ncr-driver in the kernel, just for the situation of a first install. I
> think no newbie with little knowledge will be able to install Linux (or,
> maybe, FreeBSD), when he happens to own such an controller. First, he
> won't be able to read very much on the screen, for the loop runs much too
> fast and second, he will not understand when he reads something about a
> sym53c8xx. Exactly for this case I think the old driver should be left in.
> If You want, You can tell him "Attention! Use of this driver deprecated.
> Contact Your support." or whatever seems appropriate. It is just about the
> first step to linuxland :-)
>
> Hope I managed to make myself clear tris time
I have limited time and am very bad in politics. I do prefer to have to
deal with accurate technical issues. My english is also limited to this
field.
You would have been clear if you had reported:
1) Which of the mpar= spar= and/or corresponding compiled-in options made
your broken hardware works (with high risks of silent corruption).
2) If using the corresponding compiled-in option worked with sym-2.
3) Optionnaly, relevant messages printed by sym-2, even taken by hand,
when the problem occurs.
+ any other pertinent information I cannot guess about you thought can
help.
About FreeBSD, the only information I have is that the (sad) work-around I
implemented and that is incorporated in sym-2 _did_ work around the
problem of PCI parity error for people that did report results.
Could you be clear, as expected by technical group of discussions, please.
Gérard.
PS: The ncr53c8xx may just work since it does trust POST software to
enable PCI parity checking bit in PCI config space. But it seems that
most POST shits donnot do so, leaving systems with the risk of silent
data corruption in contradiction with either PCI specifications and user
expectation.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-14 16:46 ` Gérard Roudier
2001-12-14 20:09 ` Jens Axboe
@ 2001-12-18 0:34 ` Kirk Alexander
1 sibling, 0 replies; 669+ messages in thread
From: Kirk Alexander @ 2001-12-18 0:34 UTC (permalink / raw)
To: Gérard_Roudier ; +Cc: Jens Axboe, linux-kernel
--- Gérard_Roudier <groudier@free.fr> wrote: >
>
[snip]
>
> You may let me know if sym53c8xx_2 still works with 810 rev 2.
>
I tried the sym53c8xx_2 driver, put a fair load on the system (lots of sync'ing
and swapping) and didn't seem to have any trouble.
Cheers,
Kirk Alexander
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
[not found] <20011214041151.91557.qmail@web14904.mail.yahoo.com>
2001-12-14 16:46 ` Gérard Roudier
@ 2001-12-14 20:34 ` Jens Axboe
2001-12-15 0:56 ` Stephan von Krawczynski
2 siblings, 0 replies; 669+ messages in thread
From: Jens Axboe @ 2001-12-14 20:34 UTC (permalink / raw)
To: Kirk Alexander; +Cc: groudier, linux-kernel
On Fri, Dec 14 2001, Kirk Alexander wrote:
> [cc'ed to lkml and Gerard Roudier]
>
> Hi Jens,
>
> You asked people to send in reports of which drivers
> were broken by the removal of io_request_lock.
>
> My system is a clunky old Digital Pentium Pro with a
> NCR53c810 rev 2 scsi controller, so it can't use the
> sym driver. I fixed the problem by seeing what the sym
> driver did i.e. the patch below
> This may not be right at all, and I haven't had a
> chance to boot the kernel - but it did build OK.
Missed your original post, it had no subject line. At first view, your
patch looks correct. However, check the ->detect() routing and verify
it's not assuming the lock is held there. That should be the only
pitfall.
Minor nit pick -- since this driver is _in_ the 2.5 tree, there's no way
the #ifdef would not hit. So the way I've been fixing these is to just
always assume latest kernel.
I think this was already fixed though, but at least know you now you did
it right :-)
--
Jens Axboe
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
[not found] <20011214041151.91557.qmail@web14904.mail.yahoo.com>
2001-12-14 16:46 ` Gérard Roudier
2001-12-14 20:34 ` Jens Axboe
@ 2001-12-15 0:56 ` Stephan von Krawczynski
2001-12-15 6:59 ` Gérard Roudier
2 siblings, 1 reply; 669+ messages in thread
From: Stephan von Krawczynski @ 2001-12-15 0:56 UTC (permalink / raw)
To: G?rard Roudier; +Cc: kirkalx, axboe, linux-kernel
On Fri, 14 Dec 2001 17:46:37 +0100 (CET)
Gérard Roudier <groudier@free.fr> wrote:
> > My system is a clunky old Digital Pentium Pro with a
> > NCR53c810 rev 2 scsi controller, so it can't use the
> > sym driver.
>
> Use sym53c8xx_2 instead. This one uses 2 different firmwares,
> [...]
> You may let me know if sym53c8xx_2 still works with 810 rev 2.
On my system it does. I have it as a second controller and am using sym-2
without troubles.
Regards,
Stephan
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-12-15 0:56 ` Stephan von Krawczynski
@ 2001-12-15 6:59 ` Gérard Roudier
0 siblings, 0 replies; 669+ messages in thread
From: Gérard Roudier @ 2001-12-15 6:59 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: kirkalx, axboe, linux-kernel
On Sat, 15 Dec 2001, Stephan von Krawczynski wrote:
> On Fri, 14 Dec 2001 17:46:37 +0100 (CET)
> Gérard Roudier <groudier@free.fr> wrote:
>
> > > My system is a clunky old Digital Pentium Pro with a
> > > NCR53c810 rev 2 scsi controller, so it can't use the
> > > sym driver.
> >
> > Use sym53c8xx_2 instead. This one uses 2 different firmwares,
> > [...]
> > You may let me know if sym53c8xx_2 still works with 810 rev 2.
>
> On my system it does. I have it as a second controller and am using sym-2
> without troubles.
Thanks for your report.
Gérard.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-12-07 4:17 Keith Owens
2001-12-07 5:10 ` your mail Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: Keith Owens @ 2001-12-07 4:17 UTC (permalink / raw)
To: kbuild-devel; +Cc: linux-kernel, torvalds
Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I
want to do this in separate steps to make it easier for architectures
that have not been converted yet.
2.5.1 Semi-stable kernel, after bio is working.
2.5.2-pre1 Add the kbuild 2.5 and CML2 code, still using
Makefile-2.5, supporting both CML1 and CML2.
i386, sparc, sparc64 can use either kbuild 2.4 or 2.5,
2.5 is recommended.
ia64 can only use kbuild 2.5.
Other architectures continue to use kbuild 2.4.
Wait 24 hours for any major problems then -
2.5.2-pre2 Remove kbuild 2.4 code, rename Makefile-2.5 to Makefile.
Still supporting both CML1 and CML2.
i386, ia64, sparc, sparc64 can compile using kbuild 2.5.
Other architectures cannot compile until they convert
to kbuild 2.5. The kbuild group can help with the
conversion but without access to a machine we cannot
test other architectures. Until the other archs have
been converted, they can stay on 2.5.2-pre1.
Wait 24 hours for any major problems then -
2.5.2-pre3 Remove CML1 support.
Doing the change in steps provides a platform where both kbuild 2.4 and
2.5 work and both CML1 and CML2 are available. This allows other
architectures to parallel test the old and new kbuild and CML during
their conversion, I found that ability was very useful during
conversion.
Linus, is this acceptable? When do you want the kbuild 2.5 and CML2
patches?
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-12-07 4:17 Keith Owens
@ 2001-12-07 5:10 ` Linus Torvalds
2001-12-27 18:09 ` Andre Hedrick
0 siblings, 1 reply; 669+ messages in thread
From: Linus Torvalds @ 2001-12-07 5:10 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
On Fri, 7 Dec 2001, Keith Owens wrote:
>
> Linus, the time has come to convert the 2.5 kernel to kbuild 2.5.
We're getting the block IO layer in shape first, the time has not come for
_anything_ else before that.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-07 5:10 ` your mail Linus Torvalds
@ 2001-12-27 18:09 ` Andre Hedrick
2001-12-27 18:55 ` Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: Andre Hedrick @ 2001-12-27 18:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Keith Owens, kbuild-devel, linux-kernel
On Thu, 6 Dec 2001, Linus Torvalds wrote:
>
> On Fri, 7 Dec 2001, Keith Owens wrote:
> >
> > Linus, the time has come to convert the 2.5 kernel to kbuild 2.5.
>
> We're getting the block IO layer in shape first, the time has not come for
> _anything_ else before that.
>
> Linus
Lots of luck ... please pass your crack pipe arounds so the rest of us
idiots can see your vision or lack of ...
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-27 18:09 ` Andre Hedrick
@ 2001-12-27 18:55 ` Linus Torvalds
2001-12-27 19:41 ` Andrew Morton
2001-12-28 22:14 ` Martin Dalecki
0 siblings, 2 replies; 669+ messages in thread
From: Linus Torvalds @ 2001-12-27 18:55 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Keith Owens, kbuild-devel, linux-kernel
On Thu, 27 Dec 2001, Andre Hedrick wrote:
>
> Lots of luck ... please pass your crack pipe arounds so the rest of us
> idiots can see your vision or lack of ...
Heh. I think I must have passed it on to you long ago, and you never gave
it back, you sneaky bastard ;)
The vision, btw, is to get the request layer in good enough shape that we
can dispense with the mid-layer approaches of SCSI/IDE, and block devices
turn into _just_ device drivers.
For example, ide-scsi is heading for that big scrap-yard in the sky: it's
not the SCSI layer that handles special ioctl requests any more, because
the upper layers are going to be flexible enough that you can just pass
the requests down the regular pipe.
(Right now you can see this in block_ioctl.c - while only a few of the
ioctl's have been converted, you get the idea. I'm actually surprised that
nobody seems to have commented on that part).
The final end result of this (I sincerely hope) is that we can get rid of
some of the couplings that we've had in the block layer. ide-scsi is just
the most obvious strange coupling - things like "sg.c" in general are
rather horrible. There's very little _SCSI_ in sg.c - it's really about
sending commands down to the block devices.
The reason I want to get rid of the couplings is that they end up being
big anchors holding down development: you can create a clean driver that
isn't dependent on the SCSI layer overheads (and people do, for things
like DAC etc), but when you do that you lose _all_ of the support
infrastructure, not just the bloat. Which is sad.
(And which is why things like ide-scsi exist - IDE didn't really want to
be a SCSI driver, but people _did_ want to be able to use some of the
generic support routines that the SCSI layer offers. You couldn't just
cherry-pick the parts you wanted).
The other part of the bio rewrite has been to get rid of another coupling:
the coupling between "struct buffer_head" (which is used for a limited
kind of memory management by a number of filesystems) and the act of
actually just doing IO.
I used to think that we could just relegate "struct buffer_head" to _be_
the IO entity, but it turns out to be much easier to just split off the IO
part, which is why you now have a separate "bio" structure for the block
IO part, and the buffer_head stuff uses that to get the work done.
Andre, I know that you're worried about the low-level drivers, but:
- I've long since noticed that we cannot communicate, which is why Jens
is the block level driver person. You'll have to live with it.
- I personally don't think you _can_ make a good driver without having
reasonable interfaces, and we didn't have them.
For example, the network drivers have improved a lot and do not have
_nearly_ the amount of problems block drivers have. That's obviously
partly just because it is a simpler problem, but because it was simpler
it was also possible to change them. The infrastructure changes in the
networking during 2.3.x really did help drivers.
And note that the "Jens" and "communication" part is important. If you
have patches, please talk to Jens, tell him what the issues, are, and I
know I can communicate with him.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-27 18:55 ` Linus Torvalds
@ 2001-12-27 19:41 ` Andrew Morton
2001-12-28 22:14 ` Martin Dalecki
1 sibling, 0 replies; 669+ messages in thread
From: Andrew Morton @ 2001-12-27 19:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andre Hedrick, Keith Owens, kbuild-devel, linux-kernel
Linus Torvalds wrote:
>
> The other part of the bio rewrite has been to get rid of another coupling:
> the coupling between "struct buffer_head" (which is used for a limited
> kind of memory management by a number of filesystems) and the act of
> actually just doing IO.
>
> I used to think that we could just relegate "struct buffer_head" to _be_
> the IO entity, but it turns out to be much easier to just split off the IO
> part, which is why you now have a separate "bio" structure for the block
> IO part, and the buffer_head stuff uses that to get the work done.
>
So... would it be correct to say that there won't be any large
changes to the buffer_head concept in 2.5?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-12-27 18:55 ` Linus Torvalds
2001-12-27 19:41 ` Andrew Morton
@ 2001-12-28 22:14 ` Martin Dalecki
1 sibling, 0 replies; 669+ messages in thread
From: Martin Dalecki @ 2001-12-28 22:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andre Hedrick, Keith Owens, kbuild-devel, linux-kernel
Linus Torvalds wrote:
>(Right now you can see this in block_ioctl.c - while only a few of the
>ioctl's have been converted, you get the idea. I'm actually surprised that
>nobody seems to have commented on that part).
>
That was just too obvious, at least for me... However I don't see why
you just don't start killing of constructs like:
swtch (ioctrl)
BLASH:
BLAHHH:
BLASHH:
BLAASS:
BLAH:
default:
return -ENOVAL;
}
There are ton' s of them out there in the block drivers..
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-10-15 6:25 Dinesh Gandhewar
2001-10-15 6:31 ` your mail Tim Hockin
0 siblings, 1 reply; 669+ messages in thread
From: Dinesh Gandhewar @ 2001-10-15 6:25 UTC (permalink / raw)
To: mlist-linux-kernel
Hello,
What is the effect of following statement at the end of function definition?
*(int *)0 = 0;
Thanking you,
Dinesh
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-10-03 14:28 Marian Kafadarov
2001-10-03 15:52 ` your mail Martin Schulze
0 siblings, 1 reply; 669+ messages in thread
From: Marian Kafadarov @ 2001-10-03 14:28 UTC (permalink / raw)
To: linux-mips
Hello,
We have DEC station 5000 / 240
From were we can download Linux distribution and documentation for it and
what we can do on it.
Best regards: Marian Kafadarov
Technical
university of Plovdiv
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-10-03 14:28 Marian Kafadarov
@ 2001-10-03 15:52 ` Martin Schulze
0 siblings, 0 replies; 669+ messages in thread
From: Martin Schulze @ 2001-10-03 15:52 UTC (permalink / raw)
To: Marian Kafadarov; +Cc: linux-mips
Marian Kafadarov wrote:
> Hello,
> We have DEC station 5000 / 240
> From were we can download Linux distribution and documentation for it and
> what we can do on it.
You could wait until we have finished boot-floppies for this machine
(1-3 weeks) or bootstrap from scratch by using a kernel and a Debian
base system. Both is available, Karsten can also provide a correct
2.4.x kernel.
I'd rather like to ask you to wait a couple of days/weeks until
boot-floppies are available for this machine and you can use the
regular Debian installation process which will be less painful
than the other. If you do so, please come back to us in some
days/weeks to find out if things are ready already.
Regards,
Joey
--
All language designers are arrogant. Goes with the territory...
-- Larry Wall
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-10-02 15:29 Dinesh Gandhewar
2001-10-02 15:30 ` your mail Alan Cox
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Dinesh Gandhewar @ 2001-10-02 15:29 UTC (permalink / raw)
To: mlist-linux-kernel
Hello,
I have written a linux kernel module. The linux version is 2.2.14.
In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module function doesnot cause any problem.
Can you explain this behaviour?
Thnaks,
Dinesh
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-10-02 15:29 Dinesh Gandhewar
@ 2001-10-02 15:30 ` Alan Cox
2001-10-02 15:49 ` Richard B. Johnson
2001-10-02 15:52 ` Michael H. Warfield
2 siblings, 0 replies; 669+ messages in thread
From: Alan Cox @ 2001-10-02 15:30 UTC (permalink / raw)
To: dinesh_gandhewar; +Cc: mlist-linux-kernel
> I have written a linux kernel module. The linux version is 2.2.14.
> In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module function doesnot cause any problem.
> Can you explain this behaviour?
Yes
--
Alan
[Oh wait you want to know why...]
Either
1. You are using it for DMA
2. You are putting it on the stack and causing a stack overflow
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-10-02 15:29 Dinesh Gandhewar
2001-10-02 15:30 ` your mail Alan Cox
@ 2001-10-02 15:49 ` Richard B. Johnson
2001-10-02 15:52 ` Michael H. Warfield
2 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2001-10-02 15:49 UTC (permalink / raw)
To: Dinesh Gandhewar; +Cc: mlist-linux-kernel
On 2 Oct 2001, Dinesh Gandhewar wrote:
>
> Hello,
> I have written a linux kernel module. The linux version is 2.2.14.
> In this module I have declared an array of size 2048. If I use this
> array, the execution of this module function causes kernel to reboot.
> If I kmalloc() this array then execution of this module function
> doesnot cause any problem.
> Can you explain this behaviour?
> Thnaks,
> Dinesh
I would check that you are not accidentally exceeding the bounds of
your array. Actual allocation occurs in page-size chunks. You may
be exceeding your 2048 byte-limit without exceeding the 4096-byte
page-size (of ix86).
However, a global array, or an array on the stack, has very strict
limits. You can blow things up on the stack by exceeding an array
boundary by one byte. And you can overwrite important memory objects
by exceeding the bounds of a global memory object.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-10-02 15:29 Dinesh Gandhewar
2001-10-02 15:30 ` your mail Alan Cox
2001-10-02 15:49 ` Richard B. Johnson
@ 2001-10-02 15:52 ` Michael H. Warfield
2 siblings, 0 replies; 669+ messages in thread
From: Michael H. Warfield @ 2001-10-02 15:52 UTC (permalink / raw)
To: Dinesh Gandhewar; +Cc: mlist-linux-kernel
On Tue, Oct 02, 2001 at 03:29:45PM -0000, Dinesh Gandhewar wrote:
> Hello,
> I have written a linux kernel module. The linux version is 2.2.14.
> In this module I have declared an array of size 2048. If I use this
array, the execution of this module function causes kernel to
reboot. If I kmalloc() this array then execution of this module
function doesnot cause any problem.
> Can you explain this behaviour?
You didn't say how you declared the array or what the element
size was. If the array elements were larger than a char, by saying an
array of size 2048, do you mean in bytes or in array elements?
You also didn't say where you called your module from. Was it
in an interrupt handler or at insmod time or from a system call.
If it was a automatic array on the stack (declared inside the
function and not declared static), you probably overflowed the stack.
> Thnaks,
> Dinesh
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-08-04 11:10 Mahmoud Taghizadeh
2001-08-04 13:18 ` your mail Francois Romieu
0 siblings, 1 reply; 669+ messages in thread
From: Mahmoud Taghizadeh @ 2001-08-04 11:10 UTC (permalink / raw)
To: linux-mm
I am sorry for my stupid question!
is there any linux distribution without memory managment unit?
I mean, the paging is disabled and memory managemnt is done only
by segmentation.
I am thankful in advance.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-07-24 0:38 新 月
2001-07-24 12:47 ` your mail Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: 新 月 @ 2001-07-24 0:38 UTC (permalink / raw)
To: linux-kernel
Hi:
how does the kernel know which filesystem should be
mounted as root filesytem?
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-06-13 1:55 Colonel
2001-06-13 9:32 ` your mail Luigi Genoni
2001-06-18 13:55 ` Jan Hudec
0 siblings, 2 replies; 669+ messages in thread
From: Colonel @ 2001-06-13 1:55 UTC (permalink / raw)
To: linux-kernel
From: Colonel <klink@clouddancer.com>
To: linux-kernel@vger.kernel.org
Subject: ISA Soundblaster problem
Reply-to: klink@clouddancer.com
The Maintainers list does not contain anyone for 2.4 Soundblaster
modules, so perhaps some one on the mailing list is aware of a
solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2
with XMMS. But I have never been successful in a varity of 2.4
kernels, the latest being 2.4.5-ac12. This is what I know:
[DMESG]
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total
}modprobe sb
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
[/etc/modules.conf]
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
[DMESG}
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: No ISAPnP cards found, trying standard ones...
sb: dsp reset failed.
So it seems that PnP finds the card, but the connections (or even the
forced values) to the sb module fail. Back when this was a single
processor machine, but still running 2.4 kernel, a windoze
installation found the SB at the listed interface parameters.
Anyone have a solution?
Same problem without modules.conf settings, valid version of mod
utilities, a web search did not help,...
TIA
please CC: klink@clouddancer.com, not currently on the mailing list.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-06-13 1:55 Colonel
@ 2001-06-13 9:32 ` Luigi Genoni
2001-06-18 13:55 ` Jan Hudec
1 sibling, 0 replies; 669+ messages in thread
From: Luigi Genoni @ 2001-06-13 9:32 UTC (permalink / raw)
To: Colonel; +Cc: linux-kernel
I have the sound blaster 16 card on one of my athlon (on PIII i have
es1731), that has one isa slot on its MB.
It works well, but i do not use isapnp nor any pnp support is enabled
inside of the kernel.
running 2.4.5/2.4.6-pre2
Luigi
On Tue, 12 Jun 2001, Colonel wrote:
> From: Colonel <klink@clouddancer.com>
> To: linux-kernel@vger.kernel.org
> Subject: ISA Soundblaster problem
> Reply-to: klink@clouddancer.com
>
>
> The Maintainers list does not contain anyone for 2.4 Soundblaster
> modules, so perhaps some one on the mailing list is aware of a
> solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2
> with XMMS. But I have never been successful in a varity of 2.4
> kernels, the latest being 2.4.5-ac12. This is what I know:
>
> [DMESG]
> isapnp: Scanning for PnP cards...
> isapnp: Calling quirk for 01:00
> isapnp: SB audio device quirk - increasing port range
> isapnp: Card 'Creative SB16 PnP'
> isapnp: 1 Plug & Play card detected total
>
> }modprobe sb
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
>
>
> [/etc/modules.conf]
> options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
>
>
> [DMESG}
> Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
> sb: No ISAPnP cards found, trying standard ones...
> sb: dsp reset failed.
>
>
> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail. Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
>
>
> Anyone have a solution?
>
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...
>
>
>
> TIA
>
>
> please CC: klink@clouddancer.com, not currently on the mailing list.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-06-13 1:55 Colonel
2001-06-13 9:32 ` your mail Luigi Genoni
@ 2001-06-18 13:55 ` Jan Hudec
1 sibling, 0 replies; 669+ messages in thread
From: Jan Hudec @ 2001-06-18 13:55 UTC (permalink / raw)
To: Colonel; +Cc: linux-kernel
> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail. Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
>
>
> Anyone have a solution?
>
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...
I had a similar problem with different card (Gravi Usltrasound PnP).
The solution turned out to be to avoid dma 1 channel. May be some BIOSes
or ISA chipsets got the 8-bit dma channels handling wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-06-08 1:36 jnn
2001-06-08 13:16 ` your mail Ralf Baechle
0 siblings, 1 reply; 669+ messages in thread
From: jnn @ 2001-06-08 1:36 UTC (permalink / raw)
To: linux-mm
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
hi,all
somebody PLS tell me where can I find some documention about the mechanism of the cach flushing.
[-- Attachment #2: Type: text/html, Size: 462 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-06-08 1:36 jnn
@ 2001-06-08 13:16 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 2001-06-08 13:16 UTC (permalink / raw)
To: jnn; +Cc: linux-mm
On Fri, Jun 08, 2001 at 09:36:48AM +0800, jnn wrote:
> somebody PLS tell me where can I find some documention about the mechanism of the cach flushing.
Right there in your kernel source, in Documentation/cachetlb.txt. It
probably still leaves alot of questions open.
Ralf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-05-31 16:53 Ramil.Santamaria
2001-05-31 20:37 ` your mail Andrzej Krzysztofowicz
0 siblings, 1 reply; 669+ messages in thread
From: Ramil.Santamaria @ 2001-05-31 16:53 UTC (permalink / raw)
To: linux-kernel; +Cc: kErNeL-kRaCkEr
Minor issue with bootsect.s.
The single instance of the lds assembly instruction includes the comment of
! ds:si is source
...
seg fs
lds si,(bx) ! ds:si is source
...
Is this comment not in reverse order (i.e should be lds
dest,src)................
Ramil J.Santamaria
Toshiba America Information Systems
ramil.santamaria@tais.toshiba.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-31 16:53 Ramil.Santamaria
@ 2001-05-31 20:37 ` Andrzej Krzysztofowicz
2001-05-31 23:04 ` H. Peter Anvin
0 siblings, 1 reply; 669+ messages in thread
From: Andrzej Krzysztofowicz @ 2001-05-31 20:37 UTC (permalink / raw)
To: kufel!tais.toshiba.com!Ramil.Santamaria
Cc: kufel!vger.kernel.org!linux-kernel
>
> Minor issue with bootsect.s.
1. bootsect.S is the source file
> The single instance of the lds assembly instruction includes the comment of
> ! ds:si is source
> ...
> seg fs
> lds si,(bx) ! ds:si is source
> ...
> Is this comment not in reverse order (i.e should be lds
> dest,src)................
2. This is not a comment of i386 mnemonics. This comments the role of
specific register in the following instructions.
BTW, linux-kernel readers: anybody is a volunteer for making the kernel size
counter 32-bit here? This would enable using the simple bootloader for
greater kernel loading... (current limit is sligtly below 1MB)
Possibly some 16/32-bit real mode code mixing would be necessary.
Andrzej
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-31 20:37 ` your mail Andrzej Krzysztofowicz
@ 2001-05-31 23:04 ` H. Peter Anvin
0 siblings, 0 replies; 669+ messages in thread
From: H. Peter Anvin @ 2001-05-31 23:04 UTC (permalink / raw)
To: linux-kernel
Followup to: <200105312037.WAA01610@kufel.dom>
By author: Andrzej Krzysztofowicz <kufel!ankry@green.mif.pg.gda.pl>
In newsgroup: linux.dev.kernel
>
> BTW, linux-kernel readers: anybody is a volunteer for making the kernel size
> counter 32-bit here? This would enable using the simple bootloader for
> greater kernel loading... (current limit is sligtly below 1MB)
> Possibly some 16/32-bit real mode code mixing would be necessary.
>
PLEASE don't go there. bootsect.S is fundamentally broken these days
(doesn't work on USB floppies, for example.) It should be killed
DEAD, DEAD, DEAD and not dragged along like a dead albatross.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-05-21 19:43 Thomas Palm
2001-05-21 20:12 ` your mail Lorenzo Marcantonio
0 siblings, 1 reply; 669+ messages in thread
From: Thomas Palm @ 2001-05-21 19:43 UTC (permalink / raw)
To: linux-kernel
-> moved from comp.os.linux.hardware:
Hi,
I still have problems with the VIA Apollo southbridge (Kernel 2.4.2 (Redhat
7.1) and Kernel 2.4.4).
In rare circumstances,
there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
including Sound + Raid). My tests:
- copying 4 GB of CD-ISO-Files from Promise Secondary Master to Promise
Secondary Slave. After that "diff -r srcdir destdir". Test was
succesfull, no differs, even after 15 executions
- (same test with small files)
copying 4GB of small files (50 to 500 KB) from Promise Secondary Master
to Promise Secondary Slave.
1st run of "diff -r srcdir destdir" -> no differs
2nd run of "diff -r srcdir destdir" -> 2 files differ
3rd run of "diff -r srcdir destdir" -> 1 file differs
4th run of "diff -r srcdir destdir" -> 1 file differs
5th run of "diff -r srcdir destdir" -> no differs
- I d did the same tests on the Promise Primary, same results. Also on
the the VIA Secondary but my feeling is that there are even more
corruptions.
I stripped the machine to the bone, PCI-VGA only, same results.
I cannot say for sure, but before I stripped my adaptec SCSI-Card, there
may even been "differs" after copying from SCSI-Disk to SCSI-Disk. Off
course I thought other parts of my Hardware was flacky (e.g. RAM...),
but I swapped everything: RAM from different manufacturers, IDE-Cables,
CPU (Duron 900 -> Duron 850), VGA-Card, I tried the most conservative
Setting in the A7V-Bios, Bios-Update 1003 -> 1004 -> 1004 beta3,
UDMA6->UDMA2 all to no avail.
Any hints?
<TP>
Post a follow-up to this message
Message 2 in thread
Von:Bobby D. Bryant (bdbryant@mail.utexas.edu)
Betrifft:Re: VIA Apollo Southbridge again
Newsgroups:comp.os.linux.hardware
Datum:2001-05-20 09:45:08 PST
Thomas Palm wrote:
> I still have problems with the VIA Apollo southbridge (Kernel 2.4.2
(Redhat 7.1) and Kernel 2.4.4).
There are known to be bugs in the VIA chipsets, but you might want to report
this to
linux-kernel@vger.kernel.org anyway.
Bobby Bryant
Austin, Texas
--
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-21 19:43 Thomas Palm
@ 2001-05-21 20:12 ` Lorenzo Marcantonio
2001-05-22 10:06 ` Thomas Palm
0 siblings, 1 reply; 669+ messages in thread
From: Lorenzo Marcantonio @ 2001-05-21 20:12 UTC (permalink / raw)
To: Thomas Palm; +Cc: linux-kernel
On Mon, 21 May 2001, Thomas Palm wrote:
> there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
> including Sound + Raid). My tests:
> 1st run of "diff -r srcdir destdir" -> no differs
> 2nd run of "diff -r srcdir destdir" -> 2 files differ
> 3rd run of "diff -r srcdir destdir" -> 1 file differs
> 4th run of "diff -r srcdir destdir" -> 1 file differs
> 5th run of "diff -r srcdir destdir" -> no differs
Could you check WHERE the file differ and WHERE the data come from ?
I've got the same mobo AND some nasty DAT tape corruption problems...
(also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's
the DMA troubling us...
-- Lorenzo Marcantonio
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-21 20:12 ` your mail Lorenzo Marcantonio
@ 2001-05-22 10:06 ` Thomas Palm
0 siblings, 0 replies; 669+ messages in thread
From: Thomas Palm @ 2001-05-22 10:06 UTC (permalink / raw)
To: Lorenzo Marcantonio; +Cc: linux-kernel
1. The corrupted files have the same length but differ (I cannot say on what
bit-position)
2. I reproduced the problem while burning CD from SCSI-Disk to
SCSI-CD-Burner!!!
-> It´s definetly not a (single?) IDE-Problem
Burning CD (on slow 4x speed) seems to initialize many small transfers
(instead of a smooth stream)(same as copying many small files) on PCI/DMA wich
generate the same problems!!!
> On Mon, 21 May 2001, Thomas Palm wrote:
>
> > there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
> > including Sound + Raid). My tests:
> > 1st run of "diff -r srcdir destdir" -> no differs
> > 2nd run of "diff -r srcdir destdir" -> 2 files differ
> > 3rd run of "diff -r srcdir destdir" -> 1 file differs
> > 4th run of "diff -r srcdir destdir" -> 1 file differs
> > 5th run of "diff -r srcdir destdir" -> no differs
>
> Could you check WHERE the file differ and WHERE the data come from ?
>
> I've got the same mobo AND some nasty DAT tape corruption problems...
> (also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's
> the DMA troubling us...
>
> -- Lorenzo Marcantonio
>
>
--
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-05-16 15:05 siva prasad
2001-05-17 0:11 ` your mail Erik Mouw
0 siblings, 1 reply; 669+ messages in thread
From: siva prasad @ 2001-05-16 15:05 UTC (permalink / raw)
To: linux-kernel
Sorry for the newbie question..
Is it true that the ipc calls like
msgget(),shmget()...
are not really system calls?
Cos in the file "asm/unistd.h" where the
system calls are listed as __NR_xxx we dont find
the appropriate listing for the ipc calls.
What I guessed was that all the ipc calls are
clubbed under the 'int ipc()' system call and this
is well listed in the "asm/unistd.h"
Could some one explain why the ipc is implemented
this way rather that implementing them as individual
system calls as in UNIX.
Or is it the same way in UNIX
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-16 15:05 siva prasad
@ 2001-05-17 0:11 ` Erik Mouw
0 siblings, 0 replies; 669+ messages in thread
From: Erik Mouw @ 2001-05-17 0:11 UTC (permalink / raw)
To: siva prasad; +Cc: linux-kernel
On Wed, May 16, 2001 at 08:05:38AM -0700, siva prasad wrote:
> Is it true that the ipc calls like
> msgget(),shmget()...
> are not really system calls?
No, they all use a system call, but the system call is the same for all
functions.
> Cos in the file "asm/unistd.h" where the
> system calls are listed as __NR_xxx we dont find
> the appropriate listing for the ipc calls.
> What I guessed was that all the ipc calls are
> clubbed under the 'int ipc()' system call and this
> is well listed in the "asm/unistd.h"
Right, they all use __NR_ipc. See sys_ipc() in
arch/i386/kernel.sys_i386.c, especially the comment right above the
function...
> Could some one explain why the ipc is implemented
> this way rather that implementing them as individual
> system calls as in UNIX.
Probably because the original designer liked it this way and nobody
cared enough to do it otherwise.
> Or is it the same way in UNIX
I don't know, I don't have Unix source available.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-05-08 19:48 Richard B. Johnson
2001-05-08 20:06 ` your mail Jens Axboe
2001-05-08 20:46 ` Alan Cox
0 siblings, 2 replies; 669+ messages in thread
From: Richard B. Johnson @ 2001-05-08 19:48 UTC (permalink / raw)
To: Linux kernel
To driver wizards:
I have a driver which needs to wait for some hardware.
Basically, it needs to have some code added to the run-queue
so it can get some CPU time even though it's not being called.
It needs to get some CPU time which can be "turned on" or
"turned off" as a result of an interrupt or some external
input from an ioctl().
So I thought that the "tasklet" would be ideal. However, the
scheduler "thinks" that a tasklet is an interrupt, so any
attempt to sleep in the tasklet results in a kernel panic,
"ieee scheduling in an interrupt..., BUG sched.c line 688".
Next, I added code to try queue_task(). This has the same problem.
Basically the procedure needs to do:
procedure()
{
if(some_event)
schedule_timeout(n); /* Needs to sleep */
else if(something_else)
do_something();
queue_task(procedure, &tq_immediate); /* Needs to queue itself again */
}
Since I'm running against a time-line, I temporarily gave the module
some CPU time through an ioctl(), i.e., a separate task that does nothing
except repeatably execute ioctl(GIVE_CPU, NULL); This shows that the
driver actually works. It's a GPIB driver so it needs to get the
CPU to find out if it's addressed to listen, etc. These events don't
produce interrupts.
So, what am I supposed to do to add a piece of driver code to the
run queue so it gets scheduled occasionally?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-05-08 19:48 Richard B. Johnson
@ 2001-05-08 20:06 ` Jens Axboe
2001-05-08 20:15 ` Richard B. Johnson
2001-05-08 20:46 ` Alan Cox
1 sibling, 1 reply; 669+ messages in thread
From: Jens Axboe @ 2001-05-08 20:06 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Linux kernel
On Tue, May 08 2001, Richard B. Johnson wrote:
>
> To driver wizards:
>
> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.
>
> It needs to get some CPU time which can be "turned on" or
> "turned off" as a result of an interrupt or some external
> input from an ioctl().
>
> So I thought that the "tasklet" would be ideal. However, the
> scheduler "thinks" that a tasklet is an interrupt, so any
> attempt to sleep in the tasklet results in a kernel panic,
> "ieee scheduling in an interrupt..., BUG sched.c line 688".
Use a kernel thread? If you don't need to access user space, context
switches are very cheap.
> So, what am I supposed to do to add a piece of driver code to the
> run queue so it gets scheduled occasionally?
Several, grep for kernel_thread.
--
Jens Axboe
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-08 20:06 ` your mail Jens Axboe
@ 2001-05-08 20:15 ` Richard B. Johnson
2001-05-08 20:16 ` Jens Axboe
0 siblings, 1 reply; 669+ messages in thread
From: Richard B. Johnson @ 2001-05-08 20:15 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux kernel
On Tue, 8 May 2001, Jens Axboe wrote:
> On Tue, May 08 2001, Richard B. Johnson wrote:
> >
> > To driver wizards:
> >
> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
> >
> > It needs to get some CPU time which can be "turned on" or
> > "turned off" as a result of an interrupt or some external
> > input from an ioctl().
> >
> > So I thought that the "tasklet" would be ideal. However, the
> > scheduler "thinks" that a tasklet is an interrupt, so any
> > attempt to sleep in the tasklet results in a kernel panic,
> > "ieee scheduling in an interrupt..., BUG sched.c line 688".
>
> Use a kernel thread? If you don't need to access user space, context
> switches are very cheap.
>
> > So, what am I supposed to do to add a piece of driver code to the
> > run queue so it gets scheduled occasionally?
>
> Several, grep for kernel_thread.
>
> --
> Jens Axboe
>
Okay. Thanks. I thought I would have to do that too. No problem.
It's a "tomorrow" thing. Ten hours it too long to stare at a
screen.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-08 20:15 ` Richard B. Johnson
@ 2001-05-08 20:16 ` Jens Axboe
2001-05-09 13:59 ` Richard B. Johnson
0 siblings, 1 reply; 669+ messages in thread
From: Jens Axboe @ 2001-05-08 20:16 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Linux kernel
On Tue, May 08 2001, Richard B. Johnson wrote:
> > Use a kernel thread? If you don't need to access user space, context
> > switches are very cheap.
> >
> > > So, what am I supposed to do to add a piece of driver code to the
> > > run queue so it gets scheduled occasionally?
> >
> > Several, grep for kernel_thread.
> >
> > --
> > Jens Axboe
> >
>
> Okay. Thanks. I thought I would have to do that too. No problem.
A small worker thread and a wait queue to sleeep on and you are all set,
10 minutes tops :-)
> It's a "tomorrow" thing. Ten hours it too long to stare at a
> screen.
Sissy!
--
Jens Axboe
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-08 20:16 ` Jens Axboe
@ 2001-05-09 13:59 ` Richard B. Johnson
0 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2001-05-09 13:59 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux kernel
On Tue, 8 May 2001, Jens Axboe wrote:
> On Tue, May 08 2001, Richard B. Johnson wrote:
> > > Use a kernel thread? If you don't need to access user space, context
> > > switches are very cheap.
> > >
> > > > So, what am I supposed to do to add a piece of driver code to the
> > > > run queue so it gets scheduled occasionally?
> > >
> > > Several, grep for kernel_thread.
> > >
> > > --
> > > Jens Axboe
> > >
> >
> > Okay. Thanks. I thought I would have to do that too. No problem.
>
> A small worker thread and a wait queue to sleeep on and you are all set,
> 10 minutes tops :-)
>
> > It's a "tomorrow" thing. Ten hours it too long to stare at a
> > screen.
>
> Sissy!
>
Okay. I am now awake. I will now try the kernel thread. Looks
simple. Got to remember to kill it before/during module removal.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-08 19:48 Richard B. Johnson
2001-05-08 20:06 ` your mail Jens Axboe
@ 2001-05-08 20:46 ` Alan Cox
2001-05-08 21:05 ` Richard B. Johnson
1 sibling, 1 reply; 669+ messages in thread
From: Alan Cox @ 2001-05-08 20:46 UTC (permalink / raw)
To: root; +Cc: Linux kernel
> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.
Wht does it have to wait ? Why cant it just poll and come back next time ?
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-08 20:46 ` Alan Cox
@ 2001-05-08 21:05 ` Richard B. Johnson
0 siblings, 0 replies; 669+ messages in thread
From: Richard B. Johnson @ 2001-05-08 21:05 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux kernel
On Tue, 8 May 2001, Alan Cox wrote:
> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
>
> Wht does it have to wait ? Why cant it just poll and come back next time ?
>
Good question. I wanted to be able to call the exact same routine(s)
that other routines (exected from read() and write()), execute.
These routines are complex and sleep while waiting for events. I
didn't want to duplicate that code with different time-out mechanisms.
GPIB is nasty because you can't do anything unless the 'controller'
tells you to do it. When "addressed to talk", you have to parse
all the stuff sent via interrupt (ATN bit set, control byte, which
address from the control byte, etc.), then let somebody sleeping
in poll() know that they can now "write()". That can all be handled
via interrupt. But, now for the receive <grin>. The user-mode code
needs to be sleeping until some data are available. That data
may never be available. Something in the driver needs to wait
until the hardware is addressed to receive. Since it is not now
receiving, there is no interrupt! It takes time for the controller
to tell you to listen and then tell somebody else to talk to you.
This means that I need some timeout to recover from the fact
that the other guy may never talk.
Once the other guy starts sending data, the interrupts can be
used to handle the data and, once there are valid data, the
device owner can be awakened, presumably sleeping in poll() or
select(). It's the intermediate time where there are no
interrupts that needs the CPU to determine that we've waited
too long for interrupts so the device had better get off the
bus to start the error recovery procedure.
Bright an early tommorrow, I will check out both ways. A kernel
thread might be "neat". However, I may just look to see if
I can just poll while using existing code.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-05-07 11:38 Chandrashekar Nagaraj
2001-05-07 12:09 ` your mail Erik Mouw
0 siblings, 1 reply; 669+ messages in thread
From: Chandrashekar Nagaraj @ 2001-05-07 11:38 UTC (permalink / raw)
To: linux-kernel
hi,
i want to know how to read tab without a terminating character,
ie., if i use getchar() i have to enter '\n' after tab to read tab,
same is the case with read system call and scanf.
bye,
chandra.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-05-07 11:38 Chandrashekar Nagaraj
@ 2001-05-07 12:09 ` Erik Mouw
0 siblings, 0 replies; 669+ messages in thread
From: Erik Mouw @ 2001-05-07 12:09 UTC (permalink / raw)
To: Chandrashekar Nagaraj; +Cc: linux-kernel
On Mon, May 07, 2001 at 05:08:43PM +0530, Chandrashekar Nagaraj wrote:
> i want to know how to read tab without a terminating character,
> ie., if i use getchar() i have to enter '\n' after tab to read tab,
> same is the case with read system call and scanf.
This is off topic for this list, but anyway.
Read man cfmakeraw, and/or get a copy of "Advanced programming in the
UNIX environment" by W. Richard Stevens.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-05-02 22:34 Duc Vianney
2001-05-03 0:10 ` your mail Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: Duc Vianney @ 2001-05-02 22:34 UTC (permalink / raw)
To: torvalds, castortz, Bill Hartner, staelin, Larry McVoy
Cc: lse-tech, linux-kernel, lmbench-users
Has anyone seen performance degradations between 2.2.19 and 2.4.x
when running lmbench? I ran the lmbench benchmark on Linux kernels
2.2.19, 2.4.0, and 2.4.1 and observed performance degradation to be
most noticed in signal handling, pipe latency, file deletion, and
process creation. Are you aware of any kernel changes introduced in
2.4.x that might cause this performance degradation?
The following data are in microseconds, lower is better. Each data point
represents the average of at least four runs.
Tests Linux 2.2.19 Linux 2.4.0 Linux 2.4.1
Signal handler overhead 1.64 3.77 3.82
Pipe latency 4.58 5.28 5.55
File deletion - 10K 11.48 15.30 15.71
Process fork 114.76 140.45 141.98
Process fork+execve 763.57 834.40 840.39
Notes:
1. The benchmark is lmbench-2beta1.
2. The hardware under test is a 700MHz PIII Xeon.
3. The operating system under test is Red Hat 6.2, running Linux kernels 2.2.19,
2.4.0 and 2.4.1, with 4GB memory support.
The following is the summary report generated by the lmbench benchmark.
L M B E N C H 2 . 0 S U M M A R Y
------------------------------------
(Alpha software, do not distribute)
Basic system parameters
----------------------------------------------------
Host OS Description Mhz
--------- ------------- ----------------------- ----
biglinux- Linux 2.2.19 i686-pc-linux-gnu 700
biglinux- Linux 2.2.19 i686-pc-linux-gnu 700
biglinux- Linux 2.2.19 i686-pc-linux-gnu 700
biglinux- Linux 2.2.19 i686-pc-linux-gnu 700
biglinux- Linux 2.4.0 i686-pc-linux-gnu 700
biglinux- Linux 2.4.0 i686-pc-linux-gnu 700
biglinux- Linux 2.4.0 i686-pc-linux-gnu 700
biglinux- Linux 2.4.0 i686-pc-linux-gnu 700
biglinux- Linux 2.4.0 i686-pc-linux-gnu 700
biglinux- Linux 2.4.1 i686-pc-linux-gnu 700
biglinux- Linux 2.4.1 i686-pc-linux-gnu 700
biglinux- Linux 2.4.1 i686-pc-linux-gnu 700
biglinux- Linux 2.4.1 i686-pc-linux-gnu 700
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
biglinux- Linux 2.2.19 700 0.43 0.61 3.89 4.84 20 1.27 1.64 109 761 2988
biglinux- Linux 2.2.19 700 0.43 0.62 3.91 4.89 20 1.27 1.64 108 760 2981
biglinux- Linux 2.2.19 700 0.43 0.62 3.88 4.93 20 1.27 1.64 108 764 2986
biglinux- Linux 2.2.19 700 0.43 0.62 3.79 4.73 22 1.27 1.64 132 767 3011
biglinux- Linux 2.4.0 700 0.40 0.63 3.37 4.45 19 1.21 3.75 139 831 3219
biglinux- Linux 2.4.0 700 0.40 0.60 3.39 4.46 19 1.24 3.75 139 831 3269
biglinux- Linux 2.4.0 700 0.43 0.63 3.39 4.46 21 1.24 3.82 142 841 3255
biglinux- Linux 2.4.0 700 0.43 0.62 3.37 4.49 21 1.24 3.75 140 835 3244
biglinux- Linux 2.4.0 700 0.43 0.62 3.37 4.47 19 1.24 3.75 140 832 3263
biglinux- Linux 2.4.1 700 0.40 0.61 3.37 4.35 19 1.21 3.80 141 836 3262
biglinux- Linux 2.4.1 700 0.40 0.61 3.39 4.42 21 1.21 3.85 142 841 3316
biglinux- Linux 2.4.1 700 0.40 0.59 3.42 4.38 21 1.21 3.81 141 841 3306
biglinux- Linux 2.4.1 700 0.40 0.61 3.39 4.39 20 1.21 3.81 142 841 3225
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
biglinux- Linux 2.2.19 0.850 5.0800 21 6.7500 23 8.98000 97
biglinux- Linux 2.2.19 0.860 7.1700 21 6.9200 22 10 138
biglinux- Linux 2.2.19 0.890 6.5100 21 6.5600 136 14 155
biglinux- Linux 2.2.19 0.960 6.4200 21 6.7000 22 7.16000 88
biglinux- Linux 2.4.0 1.040 6.5300 21 6.5800 29 19 185
biglinux- Linux 2.4.0 1.170 6.6200 21 6.7000 22 6.72000 102
biglinux- Linux 2.4.0 1.050 6.6100 21 6.5900 22 6.68000 101
biglinux- Linux 2.4.0 1.070 6.5700 21 6.7200 22 6.79000 102
biglinux- Linux 2.4.0 1.100 6.5300 21 6.5900 22 13 107
biglinux- Linux 2.4.1 1.050 6.4400 21 7.2000 23 6.88000 102
biglinux- Linux 2.4.1 1.140 6.6900 21 6.7100 22 6.92000 103
biglinux- Linux 2.4.1 1.130 6.7200 22 6.9300 22 6.85000 110
biglinux- Linux 2.4.1 1.180 6.5000 21 7.1000 22 7.11000 109
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
biglinux- Linux 2.2.19 0.850 4.583 8.55 15 25 83
biglinux- Linux 2.2.19 0.860 4.605 8.96 15 25 85
biglinux- Linux 2.2.19 0.890 4.545 8.79 15 25 83
biglinux- Linux 2.2.19 0.960 4.581 8.85 15 25 86
biglinux- Linux 2.4.0 1.040 5.193 8.74 15 22 9.0M
biglinux- Linux 2.4.0 1.170 5.274 8.80 15 22 9.0M
biglinux- Linux 2.4.0 1.050 5.378 9.02 15 23 23M
biglinux- Linux 2.4.0 1.070 5.288 8.99 15 22 3.0M
biglinux- Linux 2.4.0 1.100 5.273 8.81 15 23 29M
biglinux- Linux 2.4.1 1.050 5.291 8.41 15 23 3.0M
biglinux- Linux 2.4.1 1.140 5.419 8.56 15 23 9.0M
biglinux- Linux 2.4.1 1.130 5.574 8.81 15 23 29M
biglinux- Linux 2.4.1 1.180 5.646 9.01 15 24 9.0M
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
biglinux- Linux 2.2.19 8.8928 0.5667 17 1.1416 24.57400 0.887 528
biglinux- Linux 2.2.19 8.8976 0.5710 17 1.1458 23.76700 0.887 518
biglinux- Linux 2.2.19 8.9103 0.5625 17 1.1297 23.83100 0.887 518
biglinux- Linux 2.2.19 8.8881 0.5617 17 1.1739 23.80700 0.888 519
biglinux- Linux 2.4.0 9.4500 0.5682 19 1.5225 1097 0.847 3.00000
biglinux- Linux 2.4.0 9.4589 0.5707 19 1.5247 1129 0.850 3.00000
biglinux- Linux 2.4.0 9.4545 0.5724 19 1.5279 1108 0.887 3.00000
biglinux- Linux 2.4.0 9.4661 0.5762 19 1.5340 1104 0.854 3.00000
biglinux- Linux 2.4.0 9.4563 0.5781 19 1.5398 1140 0.850 3.00000
biglinux- Linux 2.4.1 9.5905 0.5969 17 1.5588 1138 0.837 3.00000
biglinux- Linux 2.4.1 9.6089 0.6082 17 1.5774 1140 0.862 3.00000
biglinux- Linux 2.4.1 9.5914 0.5986 17 1.5677 1156 0.835 3.00000
biglinux- Linux 2.4.1 9.6015 0.6109 17 1.5816 1151 0.861 3.00000
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
biglinux- Linux 2.2.19 684 458 256 219 258 131 129 258 199
biglinux- Linux 2.2.19 684 458 254 191 258 133 130 258 198
biglinux- Linux 2.2.19 685 457 195 219 258 135 129 258 199
biglinux- Linux 2.2.19 694 454 248 219 258 133 129 258 198
biglinux- Linux 2.4.0 651 369 470 146 257 128 129 257 197
biglinux- Linux 2.4.0 641 371 478 209 257 119 129 257 197
biglinux- Linux 2.4.0 647 372 481 209 257 127 128 257 197
biglinux- Linux 2.4.0 634 369 479 209 257 130 129 257 197
biglinux- Linux 2.4.0 641 351 483 210 257 127 129 257 197
biglinux- Linux 2.4.1 650 379 476 209 257 128 129 257 197
biglinux- Linux 2.4.1 622 367 472 209 257 120 128 257 197
biglinux- Linux 2.4.1 615 367 471 209 257 129 129 257 197
biglinux- Linux 2.4.1 624 384 463 209 257 126 129 257 197
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- ---- ----- ------ -------- -------
biglinux- Linux 2.2.19 700 4.286 24 201
biglinux- Linux 2.2.19 700 4.286 12 201
biglinux- Linux 2.2.19 700 4.286 12 201
biglinux- Linux 2.2.19 700 4.286 12 201
biglinux- Linux 2.4.0 700 4.286 12 201
biglinux- Linux 2.4.0 700 4.287 12 201
biglinux- Linux 2.4.0 700 4.286 12 201
biglinux- Linux 2.4.0 700 4.287 12 201
biglinux- Linux 2.4.0 700 4.286 12 201
biglinux- Linux 2.4.1 700 4.286 12 201
biglinux- Linux 2.4.1 700 4.287 12 201
biglinux- Linux 2.4.1 700 4.286 12 201
biglinux- Linux 2.4.1 700 4.287 12 201
Cheers .... Duc.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-05-02 22:34 Duc Vianney
@ 2001-05-03 0:10 ` Linus Torvalds
0 siblings, 0 replies; 669+ messages in thread
From: Linus Torvalds @ 2001-05-03 0:10 UTC (permalink / raw)
To: Duc Vianney
Cc: castortz, Bill Hartner, staelin, Larry McVoy, lse-tech,
linux-kernel, lmbench-users
On Wed, 2 May 2001, Duc Vianney wrote:
>
> Has anyone seen performance degradations between 2.2.19 and 2.4.x
Yes.
The signal handling one is because 2.4.x will save off the full SSE2
state, which means that the signal stack is almost 700 bytes, as compared
to <200 before. This is sadly necessary to be able to take advantage of
the SSE2 instructions - and on special applications the win can be quite
noticeable. This one you won't be able to avoid, although you shouldn't
see it on older hardware that do not have SSE2 (you see it because you
have a PIII).
You don't say how much memory you have, but the file handling ones might
be due to a really unfortunate hash thinko that cause the dentry hash to
be pretty much useless on machines that have 512MB of RAM (it can show up
in other cases, but 512M is the case that makes the hash really become a
non-hash). If so, it should be fixed in 2.4.2.
2.4.4 will give noticeably better numbers for fork and fork+exec. However,
the scheduling optimization that does that actually breaks at least
"bash", and it appears that we will just undo it during the stable series.
Even if the bug is obviously in user land (and a fix is available), stable
kernels shouldn't try to hide the problems.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-04-26 19:37 Alexandru Barloiu Nicolae
2001-04-26 19:51 ` your mail Erik Mouw
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Alexandru Barloiu Nicolae @ 2001-04-26 19:37 UTC (permalink / raw)
To: linux-kernel
is ftp.kernel.org down or is just my connections fault ?
axl
______________________________________________________
support slackware anyway posible paypal@slackware.com anyone ?
http://www.slackware.com/forum/read.php?f=5&i=7887&t=7887
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-04-26 19:37 Alexandru Barloiu Nicolae
@ 2001-04-26 19:51 ` Erik Mouw
2001-04-26 19:54 ` Mohammad A. Haque
2001-04-26 19:59 ` Joel Jaeggli
2 siblings, 0 replies; 669+ messages in thread
From: Erik Mouw @ 2001-04-26 19:51 UTC (permalink / raw)
To: Alexandru Barloiu Nicolae; +Cc: linux-kernel
On Thu, Apr 26, 2001 at 10:37:32PM +0300, Alexandru Barloiu Nicolae wrote:
> is ftp.kernel.org down or is just my connections fault ?
Yes, scheduled downtime. Use your local mirror (ftp.ro.kernel.org).
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-04-26 19:37 Alexandru Barloiu Nicolae
2001-04-26 19:51 ` your mail Erik Mouw
@ 2001-04-26 19:54 ` Mohammad A. Haque
2001-04-26 19:59 ` Joel Jaeggli
2 siblings, 0 replies; 669+ messages in thread
From: Mohammad A. Haque @ 2001-04-26 19:54 UTC (permalink / raw)
To: Alexandru Barloiu Nicolae; +Cc: linux-kernel
Down for maint.
On Thu, 26 Apr 2001, Alexandru Barloiu Nicolae wrote:
> is ftp.kernel.org down or is just my connections fault ?
>
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
mhaque@haque.net
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
batmanppc@themes.org
=====================================================================
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-04-26 19:37 Alexandru Barloiu Nicolae
2001-04-26 19:51 ` your mail Erik Mouw
2001-04-26 19:54 ` Mohammad A. Haque
@ 2001-04-26 19:59 ` Joel Jaeggli
2 siblings, 0 replies; 669+ messages in thread
From: Joel Jaeggli @ 2001-04-26 19:59 UTC (permalink / raw)
To: Alexandru Barloiu Nicolae; +Cc: linux-kernel
yeah two hour upgrade window today...
joelja
On Thu, 26 Apr 2001, Alexandru Barloiu Nicolae wrote:
> is ftp.kernel.org down or is just my connections fault ?
>
> axl
>
>
> ______________________________________________________
> support slackware anyway posible paypal@slackware.com anyone ?
> http://www.slackware.com/forum/read.php?f=5&i=7887&t=7887
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli joelja@darkwing.uoregon.edu
Academic User Services consult@gladstone.uoregon.edu
PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu>]
* Re: your mail
[not found] <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu>
@ 2001-04-04 21:37 ` Matthew Fredrickson
2001-04-05 5:08 ` Ralf Baechle
0 siblings, 1 reply; 669+ messages in thread
From: Matthew Fredrickson @ 2001-04-04 21:37 UTC (permalink / raw)
To: jsc6233, linux-mips
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
On Wed, Apr 04, 2001 at 05:29:54PM -0700, jsc6233@ritvax.isc.rit.edu wrote:
>
> hello,
> Yeah i am trying to compile it while running Irix 6.5. Once i get it all
> working I was going to boot into it. Does that make sense?
> james
<g>No offense, but not really. Actually, you'll probably need to start
off by setting up the x86-mips cross compilers on an x86 linux machine of
yours and booting the kernel via tftp over the network to get started. I
think most of this is covered in the FAQ on the site. Anyway, I don't
think it's _ever_ been supported to compile up the kernel in IRIX anyway,
so your kind of out of luck for that. On a side note, you probably want
to stop by freeware.sgi.com and upgrade your gcc from 2.7 to the latest
(2.95.3 I think). Might even try downloading some pre3.0 stuff and try
that out. Back to topic: Read EVERYTHING you can on the linux-mips sgi
site before asking a question here; if you don't, that's a very good way
to get kindly (and a lot of times unkindly) pointed to the FAQ. Hope this
helps.
--
Matthew Fredrickson AIM MatthewFredricks
ICQ 13923212 matt@NOSPAMfredricknet.net
http://www.fredricknet.net/~matt/
"Everything is relative"
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-04-04 21:37 ` Matthew Fredrickson
@ 2001-04-05 5:08 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 2001-04-05 5:08 UTC (permalink / raw)
To: Matthew Fredrickson; +Cc: jsc6233, linux-mips
On Wed, Apr 04, 2001 at 04:37:47PM -0500, Matthew Fredrickson wrote:
> > hello,
> > Yeah i am trying to compile it while running Irix 6.5. Once i get it all
> > working I was going to boot into it. Does that make sense?
> > james
>
> <g>No offense, but not really. Actually, you'll probably need to start
> off by setting up the x86-mips cross compilers on an x86 linux machine of
> yours and booting the kernel via tftp over the network to get started. I
> think most of this is covered in the FAQ on the site. Anyway, I don't
> think it's _ever_ been supported to compile up the kernel in IRIX anyway,
> so your kind of out of luck for that.
You obvious didn't even check. I assure you that I rarely compile a MIPS
kernel under Linux so if that works, it's coincidental. Crosscompiling
on IRIX works just fine.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-04-02 19:20 Jakob Kemi
2001-04-09 13:23 ` your mail Tim Waugh
0 siblings, 1 reply; 669+ messages in thread
From: Jakob Kemi @ 2001-04-02 19:20 UTC (permalink / raw)
To: linux-kernel
Hi all.
Ok, maybe this isn't the right list for this question. In 2.2.x the
parport_probe module extracted the ieee1284 device id correctly and added to the
proc fs. However this doesn't seem to work for me in 2.4.x
I only have one device to test it on and since I know there have been some
difficulties regarding the device string's length bytes etc I post my device_id string here
the first two bytes says that length is 96 and the following is the string
"MFG:Winbond;MDL:SA5459B;CLS:DIGCAM;DES:Winbond's DIGCAM driver can not be found in the system;"
I have tested to build, parport, parport_pc and ieee1284 both as modules and static into the kernel.
Is there some option I need to enable. As far as I understand the CONFIG_PARPORT_1284 should be enough??
Bye
Jakob
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2001-03-24 18:51 Hubertus Franke
0 siblings, 0 replies; 669+ messages in thread
From: Hubertus Franke @ 2001-03-24 18:51 UTC (permalink / raw)
To: frenzy@frenzy.org; +Cc: SELinux
That's not what the website said. I actually downloaded
(a) the full version
(b) the full 2.4.2 patched kernel
(c) and the patch itself.
All have the same problem. The trick with dobule compile didn't work for
me.
I do run on Redhat 7.0.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
"frenzy@frenzy.org" <mcclellr@OIT.EDU>@tycho.nsa.gov on 03/24/2001 02:26:49
AM
Sent by: owner-selinux@tycho.nsa.gov
To:
cc: SELinux@tycho.nsa.gov
Subject: Re: your mail
It was my understanding that the kernel patch was only made for the
supplied kernel that comes with RH6.1
I could be completely wrong here however. The last one I tried it with was
2.2.17-14smp, which also failed to compile.
Sincerely,
Randy McCleland-Bane
http://www.frenzy.org -- Administrator
MSN: drekbot@hotmail.com ICQ: 32276169
EM: frenzy@frenzy.org,mcclellr@oit.edu
"We must be the change we wish to see
in the world." - Mahatma Gandhi
PGP key: http://www.frenzy.org/frenzy/
frenzy_at_frenzy.org.asc.txt
On Fri, 23 Mar 2001, Hubertus Franke wrote:
just downloaded the SELinux for 2.4.
I did the ./tools/build-kernel and get the following errors.
/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory
/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory
Looks like various files are missing in the distribution.
Any ideas ?
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.
--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2001-03-24 4:55 gawain.lynch
0 siblings, 0 replies; 669+ messages in thread
From: gawain.lynch @ 2001-03-24 4:55 UTC (permalink / raw)
To: Chris Crowther; +Cc: owner-selinux, SELinux
> > /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> > linux/flask/flask.h: No such file or directory
> > /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> > config/flask/audit.h: No such file or directory
> >
> > Looks like various files are missing in the distribution.
> > Any ideas ?
> The header files get auto-created by the build, but
they're not
> there when make dep is run, so you get all the errors, but the Kernel
does
> compile.
I am having the same issue with the current release, I let
tool/build-kernel run twice, but both times it exits with the error below:
In file included from /usr/include/errno.h:36,
from scripts/split-include.c:26:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or
directory
make: *** [scripts/split-include] Error 1
I have also tried patching fresh source here and I get the same issues.
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread* (no subject)
@ 2001-03-24 0:04 dhar
2001-03-24 1:09 ` your mail Tim Wright
0 siblings, 1 reply; 669+ messages in thread
From: dhar @ 2001-03-24 0:04 UTC (permalink / raw)
To: linux-smp; +Cc: linux-kernel
Hi,
I am not a member of either of these lists and would appreciate if you could send your replies to me personally.
Now the problem:
I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 2.2.14 with SMP support. NFS was however compiled as a module.
Now the problem is as follows:
Most of the times the machine just works fine.
But whenever there is heavy disk write activity it just hangs/crashes. Also this is when the SMP kernel is used. If I use the normal kernel then there is no problem.
Could any one tell me what has to be done to prevent this from happening?
Any help in this regard will be very much appreciated.
Once again, kindly reply to me personally as I am not a member of either of these lists.
Regards
Dhar
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-03-24 0:04 dhar
@ 2001-03-24 1:09 ` Tim Wright
0 siblings, 0 replies; 669+ messages in thread
From: Tim Wright @ 2001-03-24 1:09 UTC (permalink / raw)
To: dhar; +Cc: linux-smp, linux-kernel
Hmmm...
you don't really give enough information to make much of a guess.
I'd do the following:
Grab at least 2.2.18, or even better, get Alan's 2.2.19pre (which is almost
2.2.19 now, I believe), and build and install that kernel.
Now, if you run into the same problems, record the crash details, especially
if the kernels oopses, and then send the information (kernel version, output
of ksymoops if there is an oops, kernel .config used etc.) to the mailing list.
Tim
On Sat, Mar 24, 2001 at 05:34:39AM +0530, dhar wrote:
> Hi,
>
> I am not a member of either of these lists and would appreciate if you could send your replies to me personally.
>
> Now the problem:
>
> I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 2.2.14 with SMP support. NFS was however compiled as a module.
>
> Now the problem is as follows:
>
> Most of the times the machine just works fine.
> But whenever there is heavy disk write activity it just hangs/crashes. Also this is when the SMP kernel is used. If I use the normal kernel then there is no problem.
>
> Could any one tell me what has to be done to prevent this from happening?
>
> Any help in this regard will be very much appreciated.
>
> Once again, kindly reply to me personally as I am not a member of either of these lists.
>
> Regards
> Dhar
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-03-23 23:02 Hubertus Franke
2001-03-24 1:53 ` your mail Chris Crowther
` (2 more replies)
0 siblings, 3 replies; 669+ messages in thread
From: Hubertus Franke @ 2001-03-23 23:02 UTC (permalink / raw)
To: SELinux
just downloaded the SELinux for 2.4.
I did the ./tools/build-kernel and get the following errors.
/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory
/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory
Looks like various files are missing in the distribution.
Any ideas ?
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-03-23 23:02 Hubertus Franke
@ 2001-03-24 1:53 ` Chris Crowther
2001-03-24 7:26 ` frenzy@frenzy.org
2001-03-26 13:57 ` Stephen Smalley
2 siblings, 0 replies; 669+ messages in thread
From: Chris Crowther @ 2001-03-24 1:53 UTC (permalink / raw)
To: SELinux
On Fri, 23 Mar 2001, Hubertus Franke wrote:
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
>
> Looks like various files are missing in the distribution.
> Any ideas ?
The header files get auto-created by the build, but they're not
there when make dep is run, so you get all the errors, but the Kernel does
compile.
--
Chris "_Shad0w_" Crowther
shad0w@shad0w.org
http://www.shad0w.org.uk/
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-03-23 23:02 Hubertus Franke
2001-03-24 1:53 ` your mail Chris Crowther
@ 2001-03-24 7:26 ` frenzy@frenzy.org
2001-03-26 14:01 ` Stephen Smalley
2001-03-26 13:57 ` Stephen Smalley
2 siblings, 1 reply; 669+ messages in thread
From: frenzy@frenzy.org @ 2001-03-24 7:26 UTC (permalink / raw)
Cc: SELinux
It was my understanding that the kernel patch was only made for the
supplied kernel that comes with RH6.1
I could be completely wrong here however. The last one I tried it with was
2.2.17-14smp, which also failed to compile.
Sincerely,
Randy McCleland-Bane
http://www.frenzy.org -- Administrator
MSN: drekbot@hotmail.com ICQ: 32276169
EM: frenzy@frenzy.org,mcclellr@oit.edu
"We must be the change we wish to see
in the world." - Mahatma Gandhi
PGP key: http://www.frenzy.org/frenzy/
frenzy_at_frenzy.org.asc.txt
On Fri, 23 Mar 2001, Hubertus Franke wrote:
just downloaded the SELinux for 2.4.
I did the ./tools/build-kernel and get the following errors.
/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory
/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory
Looks like various files are missing in the distribution.
Any ideas ?
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-03-24 7:26 ` frenzy@frenzy.org
@ 2001-03-26 14:01 ` Stephen Smalley
0 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2001-03-26 14:01 UTC (permalink / raw)
To: frenzy@frenzy.org; +Cc: SELinux
The kernel patch is based on the stock kernel sources from
www.kernel.org or its mirrors. The current release provides
patches for kernel versions 2.2.18 and 2.4.2, although the
2.2-based patch is no longer being actively developed.
--
Stephen D. Smalley, NAI Labs
sds@tislabs.com
On Fri, 23 Mar 2001, frenzy@frenzy.org wrote:
> It was my understanding that the kernel patch was only made for the
> supplied kernel that comes with RH6.1
> I could be completely wrong here however. The last one I tried it with was
> 2.2.17-14smp, which also failed to compile.
> Sincerely,
>
> Randy McCleland-Bane
> http://www.frenzy.org -- Administrator
> MSN: drekbot@hotmail.com ICQ: 32276169
> EM: frenzy@frenzy.org,mcclellr@oit.edu
> "We must be the change we wish to see
> in the world." - Mahatma Gandhi
> PGP key: http://www.frenzy.org/frenzy/
> frenzy_at_frenzy.org.asc.txt
>
> On Fri, 23 Mar 2001, Hubertus Franke wrote:
>
> just downloaded the SELinux for 2.4.
>
> I did the ./tools/build-kernel and get the following errors.
>
>
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
>
>
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
>
> Looks like various files are missing in the distribution.
> Any ideas ?
>
>
> Hubertus Franke
> Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh@us.ibm.com
> (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
>
>
>
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-03-23 23:02 Hubertus Franke
2001-03-24 1:53 ` your mail Chris Crowther
2001-03-24 7:26 ` frenzy@frenzy.org
@ 2001-03-26 13:57 ` Stephen Smalley
2 siblings, 0 replies; 669+ messages in thread
From: Stephen Smalley @ 2001-03-26 13:57 UTC (permalink / raw)
To: Hubertus Franke; +Cc: SELinux
These header files should be automatically generated during
the build. I just tried again with a clean copy of the release
on my RedHat 6.1 system, and it built without any problems.
Try expanding a clean copy of the release and building the
kernel by hand rather than using the build-kernel script, i.e.
tar xzf slinux-200103151617-release.tgz
cd slinux
ln -sf kernel-2.4 kernel
cd kernel
make xconfig or make menuconfig or make config
(Configure the kernel appropriately.)
make dep
make
make modules
--
Stephen D. Smalley, NAI Labs
sds@tislabs.com
On Fri, 23 Mar 2001, Hubertus Franke wrote:
> just downloaded the SELinux for 2.4.
>
> I did the ./tools/build-kernel and get the following errors.
>
>
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
>
>
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
>
> Looks like various files are missing in the distribution.
> Any ideas ?
>
>
> Hubertus Franke
> Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh@us.ibm.com
> (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
>
>
>
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-03-11 17:06 Martin Bruchanov
2001-03-12 5:03 ` your mail Greg KH
0 siblings, 1 reply; 669+ messages in thread
From: Martin Bruchanov @ 2001-03-11 17:06 UTC (permalink / raw)
To: linux-kernel
Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
############################################################################
[1.] One line summary of the problem:
USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.
############################################################################
[2.] Full description of the problem/report:
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=18 (error=-110)
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=20 (error=-110)
This message was echoed, when i plug-in SMP device Wacom Graphire or
keyboard to USB plug. I test it with three identicals kernel, only
difference was in "Processor type and features".
There was USB non-functional with Symmetric multi-processing support
was US on fistr kernel.
Second kernel without SMP correctly detect the USB device and without
APIC.
Third kernel with APIC and IO-APIC support on uniprocessors was not
detect USB device.
############################################################################
[3.] Keywords (i.e., modules, networking, kernel):
modules, USB
############################################################################
[4.] Kernel version (from /proc/version):
2.4.2
############################################################################
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
############################################################################
[6.] A small shell script or example program which triggers the
problem (if possible)
############################################################################
[7.] Environment
############################################################################
[7.1.] Software (add the output of the ver_linux script here)
############################################################################
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 859.113
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse
bogomips : 1710.48
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 859.113
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 mmx fxsr sse
bogomips : 1717.04
############################################################################
[7.3.] Module information (from /proc/modules):
evdev 3712 0 (unused)
mousedev 4288 0 (unused)
wacom 3344 0 (unused)
input 3680 0 [evdev mousedev wacom]
usb-uhci 23248 0 (unused)
usbcore 53776 2 [wacom usb-uhci]
############################################################################
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
4000-40ff : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
9000-900f : VIA Technologies, Inc. Bus Master IDE
9400-941f : VIA Technologies, Inc. UHCI USB
9400-941f : usb-uhci
9800-981f : VIA Technologies, Inc. UHCI USB (#2)
9800-981f : usb-uhci
9c00-9cff : VIA Technologies, Inc. AC97 Audio Controller
a000-a003 : VIA Technologies, Inc. AC97 Audio Controller
a400-a403 : VIA Technologies, Inc. AC97 Audio Controller
ac00-ac07 : Promise Technology, Inc. 20265
b000-b003 : Promise Technology, Inc. 20265
b400-b407 : Promise Technology, Inc. 20265
b800-b803 : Promise Technology, Inc. 20265
bc00-bc3f : Promise Technology, Inc. 20265
c000-c0ff : Realtek Semiconductor Co., Ltd. RTL-8139
c000-c0ff : eth0
############################################################################
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at 9000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at 9400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at 9800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 20)
Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio]
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 18
Region 0: I/O ports at 9c00 [size=256]
Region 1: I/O ports at a000 [size=4]
Region 2: I/O ports at a400 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0c.0 RAID bus controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 4d39
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at ac00 [size=8]
Region 1: I/O ports at b000 [size=4]
Region 2: I/O ports at b400 [size=8]
Region 3: I/O ports at b800 [size=4]
Region 4: I/O ports at bc00 [size=64]
Region 5: Memory at df000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [58] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0d.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI])
Subsystem: Texas Instruments: Unknown device 8020
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (750ns min, 1000ns max), cache line size 08
Interrupt: pin A routed to IRQ 19
Region 0: Memory at df024000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at df020000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 1
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at c000 [size=256]
Region 1: Memory at df025000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation GeForce 256 (rev 10) (prog-if 00 [VGA])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
############################################################################
[7.6.] SCSI information (from /proc/scsi/scsi)
############################################################################
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
Kernel with SMP /proc/bus/usb/devices:
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 3 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=9800
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=9400
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
Kernel with ACPI (without SMP):
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 3 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=9800
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=9400
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
Kernel without SMP and ACPI:
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 3 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=9800
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB UHCI Root Hub
S: SerialNumber=9400
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=056a ProdID=0010 Rev= 1.20
S: Manufacturer=WACOM
S: Product=ET-0405-UV1.2-0
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 40mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=wacom
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl= 10ms
############################################################################
[X.] Other notes, patches, fixes, workarounds:
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-03-11 17:06 Martin Bruchanov
@ 2001-03-12 5:03 ` Greg KH
2001-03-14 17:46 ` Robert Read
0 siblings, 1 reply; 669+ messages in thread
From: Greg KH @ 2001-03-12 5:03 UTC (permalink / raw)
To: Martin Bruchanov; +Cc: linux-kernel
On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
>
> Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
>
> ############################################################################
> [1.] One line summary of the problem:
> USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.
What kind of motherboard is this?
And does USB work in SMP mode with "noapic" given on the kernel command
line?
thanks,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-03-12 5:03 ` your mail Greg KH
@ 2001-03-14 17:46 ` Robert Read
0 siblings, 0 replies; 669+ messages in thread
From: Robert Read @ 2001-03-14 17:46 UTC (permalink / raw)
To: Greg KH, Martin Bruchanov, linux-kernel
On Sun, Mar 11, 2001 at 09:03:09PM -0800, Greg KH wrote:
> On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
> >
> > Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
> >
> > ############################################################################
> > [1.] One line summary of the problem:
> > USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.
>
> What kind of motherboard is this?
>
>From the lspci output, looks like I have the same mainboard or at
least one with an identical chipset. I've got an MSI 694D Pro
Mainboard with 694X VIA chipset, with 2 cpus installed, and I had the
same USB problem with 2.4.0, but haven't had time to test it on a
recent kernel.
robert
> And does USB work in SMP mode with "noapic" given on the kernel command
> line?
>
> thanks,
>
> greg k-h
>
> --
> greg@(kroah|wirex).com
> http://immunix.org/~greg
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-03-06 23:55 Ying Chen
2001-03-07 0:40 ` your mail Don Dugger
0 siblings, 1 reply; 669+ messages in thread
From: Ying Chen @ 2001-03-06 23:55 UTC (permalink / raw)
To: linux-kernel
Hi,
I have two questions on Linux pthread related issues. Would anyone be able
to help?
1. Does any one have some suggestions (pointers) on good kernel Linux thread
libraries?
2. We ran multi-threaded application using Linux pthread library on 2-way
SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see
significant increase in context switching when moving from UP to SMP, and
high CPU usage with no performance gain in turns of actual work being done
when moving to SMP, despite the fact the benchmark we are running is
CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks
went to scheduling and signaling overheads. Has anyone seen something like
this before with pthread applications running on SMP platforms? Any
suggestions or pointers on this subject?
Thanks a lot!
Ying
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-03-06 23:55 Ying Chen
@ 2001-03-07 0:40 ` Don Dugger
0 siblings, 0 replies; 669+ messages in thread
From: Don Dugger @ 2001-03-07 0:40 UTC (permalink / raw)
To: Ying Chen; +Cc: linux-kernel
Ying-
I'm a little confused here. It's very hard to compare a UP application
vs. the same app. converted to use threads. Unless the app. is
structured such that multiple threads can run at the same time then
no, you won't see any improvement by going to SMP, in fact a true
single threaded app. will frequently slow down when run on an SMP
kernel.
Have you watched a CPU meter while your benchmark runs? Even something
basic like `top' should give you a feel for whether or not your
using all of the CPU's.
On Tue, Mar 06, 2001 at 03:55:55PM -0800, Ying Chen wrote:
> Hi,
>
> I have two questions on Linux pthread related issues. Would anyone be able
> to help?
>
> ...
>
> 2. We ran multi-threaded application using Linux pthread library on 2-way
> SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see
> significant increase in context switching when moving from UP to SMP, and
> high CPU usage with no performance gain in turns of actual work being done
> when moving to SMP, despite the fact the benchmark we are running is
> CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks
> went to scheduling and signaling overheads. Has anyone seen something like
> this before with pthread applications running on SMP platforms? Any
> suggestions or pointers on this subject?
>
> Thanks a lot!
>
> Ying
>
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-02-15 0:27 Deepa Suresh
2001-02-15 11:03 ` your mail Geert Uytterhoeven
0 siblings, 1 reply; 669+ messages in thread
From: Deepa Suresh @ 2001-02-15 0:27 UTC (permalink / raw)
To: linux-mips; +Cc: deepa.suresh
Hello,
We have a QED based MIPs processor, running Linux 2.4-test6.
We use our own graphics card.
We want to get X/display up on this board. WE have a frame buffer driver
written
for the same card running on x86 Linux version and running X using
XFBDev server.
I want to know if we can reuse the same driver for mips also?
In the case of i386 Linux, fbcon.c and fbmem.c do most of the
processing before giving control to the corresponding graphics card.
In mips port can we use the same fbcon.c and fbmem.c functionality
with our graphics driver. Is this enough for X to come up
without any problems. (i have seen sgi using newport_con , can we use
fb_con itself instead , what are the problems?)
I did see in the mailing list, someone mentioning using ATI graphics
card with the same hardware and running X. How was the frame buffer
driver modified?
Any help on this would be appreciated.
Thanks & Rgds
deepa
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-02-15 0:27 Deepa Suresh
@ 2001-02-15 11:03 ` Geert Uytterhoeven
0 siblings, 0 replies; 669+ messages in thread
From: Geert Uytterhoeven @ 2001-02-15 11:03 UTC (permalink / raw)
To: Deepa Suresh; +Cc: linux-mips
On Wed, 14 Feb 2001, Deepa Suresh wrote:
> We have a QED based MIPs processor, running Linux 2.4-test6.
> We use our own graphics card.
> We want to get X/display up on this board. WE have a frame buffer driver
> written
> for the same card running on x86 Linux version and running X using
> XFBDev server.
Does the frame buffer driver you wrote for x86 Linux relies on the card being
initialised by the video BIOS on the card? If not, it'll work out-of-the-box.
If yes, you'll have to make sure a similar initialization is done on the MIPS
platform.
> I want to know if we can reuse the same driver for mips also?
> In the case of i386 Linux, fbcon.c and fbmem.c do most of the
> processing before giving control to the corresponding graphics card.
>
> In mips port can we use the same fbcon.c and fbmem.c functionality
> with our graphics driver. Is this enough for X to come up
> without any problems. (i have seen sgi using newport_con , can we use
> fb_con itself instead , what are the problems?)
Fbmem and fbcon should work fine. They are not architecture specific.
And if these work, XF{68,86}_FBDev should work as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-01-19 13:37 Robert Kaiser
2001-01-19 14:37 ` your mail Steve Hill
0 siblings, 1 reply; 669+ messages in thread
From: Robert Kaiser @ 2001-01-19 13:37 UTC (permalink / raw)
To: Steve Hill; +Cc: linux-kernel
On Thu Jan 18 16:30:30 2001 steve@navaho.co.uk wrote
> Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> hardware? It doesn't even seem to start (I get nothing on the screen from
>t he kernel, it just sits there and does nothing). :(
What processor does it use ? (386 or 486 perchance?)
----------------------------------------------------------------
Robert Kaiser email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-19 13:37 Robert Kaiser
@ 2001-01-19 14:37 ` Steve Hill
0 siblings, 0 replies; 669+ messages in thread
From: Steve Hill @ 2001-01-19 14:37 UTC (permalink / raw)
To: RobertKaiser; +Cc: linux-kernel
On Fri, 19 Jan 2001, RobertKaiser wrote:
> On Thu Jan 18 16:30:30 2001 steve@navaho.co.uk wrote
> > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> > hardware? It doesn't even seem to start (I get nothing on the screen from
> >t he kernel, it just sits there and does nothing). :(
>
> What processor does it use ? (386 or 486 perchance?)
AMD K6 (so 586) - I was trying the i386 version of the kernel on it
though, if that's going to be a problem, I can try the 586 version...
--
- Steve Hill
System Administrator Email: steve@navaho.co.uk
Navaho Technologies Ltd. Tel: +44-870-7034015
... Alcohol and calculus don't mix - Don't drink and derive! ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-01-10 18:24 Thiago Rondon
2001-01-11 4:08 ` your mail David Hinds
0 siblings, 1 reply; 669+ messages in thread
From: Thiago Rondon @ 2001-01-10 18:24 UTC (permalink / raw)
To: dahinds; +Cc: Linux Kernel, Alan Cox
Check kmalloc().
-Thiago Rondon
--- linux-2.4.0-ac5/drivers/pcmcia/ds.c Sat Sep 2 04:13:49 2000
+++ linux-2.4.0-ac5.maluco/drivers/pcmcia/ds.c Wed Jan 10 16:20:53 2001
@@ -414,6 +414,8 @@
/* Add binding to list for this socket */
driver->use_count++;
b = kmalloc(sizeof(socket_bind_t), GFP_KERNEL);
+ if (!b)
+ return -ENOMEM;
b->driver = driver;
b->function = bind_info->function;
b->instance = NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
2001-01-10 18:24 Thiago Rondon
@ 2001-01-11 4:08 ` David Hinds
0 siblings, 0 replies; 669+ messages in thread
From: David Hinds @ 2001-01-11 4:08 UTC (permalink / raw)
To: Thiago Rondon, dahinds; +Cc: Linux Kernel, Alan Cox
On Wed, Jan 10, 2001 at 04:24:21PM -0200, Thiago Rondon wrote:
>
> Check kmalloc().
>
> -Thiago Rondon
>
> --- linux-2.4.0-ac5/drivers/pcmcia/ds.c Sat Sep 2 04:13:49 2000
> +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/ds.c Wed Jan 10 16:20:53 2001
> @@ -414,6 +414,8 @@
> /* Add binding to list for this socket */
> driver->use_count++;
> b = kmalloc(sizeof(socket_bind_t), GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
> b->driver = driver;
> b->function = bind_info->function;
> b->instance = NULL;
>
As with the other kmalloc patch, this is also broken; things have been
done that need to be un-done, and you can't just exit the function
here. I'll come up with a better fix.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2001-01-04 1:36 John Van Horne
2001-01-04 15:36 ` your mail Ralf Baechle
0 siblings, 1 reply; 669+ messages in thread
From: John Van Horne @ 2001-01-04 1:36 UTC (permalink / raw)
To: 'linux-mips@oss.sgi.com'; +Cc: 'wesolows@foobazco.org'
[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]
Hello,
I downloaded cross-all-001027.tar from
oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev,
built it on my ix86 Linux box, and have tried to use it on our Linux
application and Linux kernel.
I'm getting errors which we didn't see when we were using
binutils-mips-linux-2.8.1 and
egcs-mips-linux-1.0.3a.
First, while the kernel builds just fine, when we use objcopy to convert the
elf image into a binary
image which we can download to our target, objcopy fails with warnings
saying that it is writing
sections to huge (i.e. negative) file offsets. When I use objdump to analyze
the kernel image,
I see that our start address of 0x80102584 has been turned into
0xffffffff80102584. I'm thinking that
I need to tell ld something to stop it from doing this. Any ideas?
Second, the way we build our application, we first create a partially linked
image, with the -r flag. Then
we run ld on this (and an additional object file). When we do this with the
tools from cross-all-001027
we get the following error on the second link step:
mips-linux-ld: BFD internal error, aborting at
/homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c
line 6942 in _bfd_mips_elf_relocate_section
mips-linux-ld: Please report this bug.
Actually, on the application we didn't get this far using
binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a,
so I have nothing to compare it to. I'm not sure if this is a bug or if I
should be passing some flags to gcc or ld.
Any help you can provide would be appreciated.
Thanks,
-John
[-- Attachment #2: Type: text/html, Size: 2640 bytes --]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 1:36 John Van Horne
@ 2001-01-04 15:36 ` Ralf Baechle
2001-01-04 16:22 ` Maciej W. Rozycki
0 siblings, 1 reply; 669+ messages in thread
From: Ralf Baechle @ 2001-01-04 15:36 UTC (permalink / raw)
To: John Van Horne
Cc: 'linux-mips@oss.sgi.com', 'wesolows@foobazco.org'
On Wed, Jan 03, 2001 at 05:36:44PM -0800, John Van Horne wrote:
> First, while the kernel builds just fine, when we use objcopy to convert the
> elf image into a binary
> image which we can download to our target, objcopy fails with warnings
> saying that it is writing
> sections to huge (i.e. negative) file offsets. When I use objdump to analyze
> the kernel image,
> I see that our start address of 0x80102584 has been turned into
> 0xffffffff80102584. I'm thinking that
> I need to tell ld something to stop it from doing this. Any ideas?
That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses.
Older binutils used to zero-extend addresses which was broken. So what
you observe is actually the sympthom of a bug that got fixed.
> Second, the way we build our application, we first create a partially linked
> image, with the -r flag. Then
> we run ld on this (and an additional object file). When we do this with the
> tools from cross-all-001027
> we get the following error on the second link step:
>
> mips-linux-ld: BFD internal error, aborting at
> /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c
> line 6942 in _bfd_mips_elf_relocate_section
>
> mips-linux-ld: Please report this bug.
Not good ... Two possibilities.
- it's fairly easy to make ld die in funny ways by feeding it with nonsense
options, linker scripts or similar.
- it's really a bug.
Assuming it's really a bug, can you extract a small test case that
demonstrate this bug?
> Actually, on the application we didn't get this far using
> binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a,
> so I have nothing to compare it to. I'm not sure if this is a bug or if I
> should be passing some flags to gcc or ld.
It may well be a bug; especially -r is used relativly rarely so the code
isn't getting excercised too well. I'd like to see it get fixed in the
current linker, though.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 15:36 ` your mail Ralf Baechle
@ 2001-01-04 16:22 ` Maciej W. Rozycki
2001-01-04 16:40 ` Joe deBlaquiere
0 siblings, 1 reply; 669+ messages in thread
From: Maciej W. Rozycki @ 2001-01-04 16:22 UTC (permalink / raw)
To: Ralf Baechle
Cc: John Van Horne, 'linux-mips@oss.sgi.com',
'wesolows@foobazco.org'
On Thu, 4 Jan 2001, Ralf Baechle wrote:
> > I see that our start address of 0x80102584 has been turned into
> > 0xffffffff80102584. I'm thinking that
> > I need to tell ld something to stop it from doing this. Any ideas?
>
> That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses.
> Older binutils used to zero-extend addresses which was broken. So what
> you observe is actually the sympthom of a bug that got fixed.
I'm not sure that's the best solution, I'm afraid. For elf32-mips
addresses should be 32-bit and not 64-bit. It would be consistent with
other 32-bit platforms, it would make interoperability easier (ksymoops
cannot make use of System.map to grok kernel oopses which provide 32-bit
addresses) and it would make objdump outputs more readable.
Fixing this problem with BFD is on my to do list (but has a low priority
assigned).
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 16:22 ` Maciej W. Rozycki
@ 2001-01-04 16:40 ` Joe deBlaquiere
2001-01-04 17:13 ` Ralf Baechle
2001-01-04 17:18 ` Maciej W. Rozycki
0 siblings, 2 replies; 669+ messages in thread
From: Joe deBlaquiere @ 2001-01-04 16:40 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Ralf Baechle, John Van Horne, 'linux-mips@oss.sgi.com',
'wesolows@foobazco.org'
If the BFD stuff is built with any support for 64 bit (even as an
optional target) it will maintain all addresses as 64-bit values, even
if the file is 32 bit.
There is a bug in that "some" newer versions of objcopy will not allow
you to translate these sign-extended 32 bit addresses into Intel Hex
format.
If you're really only doing 32-bit mips you might consider removing the
64 bit targets in the config.bfd... I think that will solve the problems.
Maciej W. Rozycki wrote:
> On Thu, 4 Jan 2001, Ralf Baechle wrote:
>
>
>>> I see that our start address of 0x80102584 has been turned into
>>> 0xffffffff80102584. I'm thinking that
>>> I need to tell ld something to stop it from doing this. Any ideas?
>>
>> That's be ok. 32-bit MIPS addresses are sign-extended into 64-bit addresses.
>> Older binutils used to zero-extend addresses which was broken. So what
>> you observe is actually the sympthom of a bug that got fixed.
>
>
> I'm not sure that's the best solution, I'm afraid. For elf32-mips
> addresses should be 32-bit and not 64-bit. It would be consistent with
> other 32-bit platforms, it would make interoperability easier (ksymoops
> cannot make use of System.map to grok kernel oopses which provide 32-bit
> addresses) and it would make objdump outputs more readable.
>
> Fixing this problem with BFD is on my to do list (but has a low priority
> assigned).
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 16:40 ` Joe deBlaquiere
@ 2001-01-04 17:13 ` Ralf Baechle
2001-01-04 17:46 ` Joe deBlaquiere
2001-01-04 17:18 ` Maciej W. Rozycki
1 sibling, 1 reply; 669+ messages in thread
From: Ralf Baechle @ 2001-01-04 17:13 UTC (permalink / raw)
To: Joe deBlaquiere
Cc: Maciej W. Rozycki, John Van Horne,
'linux-mips@oss.sgi.com', 'wesolows@foobazco.org'
On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:
> There is a bug in that "some" newer versions of objcopy will not allow
> you to translate these sign-extended 32 bit addresses into Intel Hex
> format.
I couldn't care less ...
> If you're really only doing 32-bit mips you might consider removing the
> 64 bit targets in the config.bfd... I think that will solve the problems.
Doesn't really solve the problem. For example on an Origin we have a 32-bit
userland but 64-bit kernel addresses which confuses ksymops and procps.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 17:13 ` Ralf Baechle
@ 2001-01-04 17:46 ` Joe deBlaquiere
2001-01-04 18:12 ` Maciej W. Rozycki
0 siblings, 1 reply; 669+ messages in thread
From: Joe deBlaquiere @ 2001-01-04 17:46 UTC (permalink / raw)
To: Ralf Baechle
Cc: Maciej W. Rozycki, John Van Horne,
'linux-mips@oss.sgi.com', 'wesolows@foobazco.org'
Ralf Baechle wrote:
> On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:
>
> If you're really only doing 32-bit mips you might consider removing the
>> 64 bit targets in the config.bfd... I think that will solve the problems.
>
>
> Doesn't really solve the problem. For example on an Origin we have a 32-bit
> userland but 64-bit kernel addresses which confuses ksymops and procps.
>
> Ralf
It was meant as a workaround...
Perhaps we could have an option to objcopy that would allow you to copy
the addresses without sign extension?
Joe
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 17:46 ` Joe deBlaquiere
@ 2001-01-04 18:12 ` Maciej W. Rozycki
0 siblings, 0 replies; 669+ messages in thread
From: Maciej W. Rozycki @ 2001-01-04 18:12 UTC (permalink / raw)
To: Joe deBlaquiere
Cc: Ralf Baechle, John Van Horne, 'linux-mips@oss.sgi.com',
'wesolows@foobazco.org'
On Thu, 4 Jan 2001, Joe deBlaquiere wrote:
> It was meant as a workaround...
>
> Perhaps we could have an option to objcopy that would allow you to copy
> the addresses without sign extension?
Please do either implement a clean solution or wait until someone else
(possibly me) does. We don't want any more hacks -- MIPS/Linux already
has enough of them. This is my view of the situation at present.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2001-01-04 16:40 ` Joe deBlaquiere
2001-01-04 17:13 ` Ralf Baechle
@ 2001-01-04 17:18 ` Maciej W. Rozycki
1 sibling, 0 replies; 669+ messages in thread
From: Maciej W. Rozycki @ 2001-01-04 17:18 UTC (permalink / raw)
To: Joe deBlaquiere
Cc: Ralf Baechle, John Van Horne, 'linux-mips@oss.sgi.com',
'wesolows@foobazco.org'
On Thu, 4 Jan 2001, Joe deBlaquiere wrote:
> If the BFD stuff is built with any support for 64 bit (even as an
> optional target) it will maintain all addresses as 64-bit values, even
> if the file is 32 bit.
I do consider it fine BFD handles all addresses as 64-bit internally. I
just think it should truncate them to 32-bits upon printing (and always
whenever appropriate) when the selected target is 32-bit. It does so (it
has to!) for output anyway, so what's the deal?
> If you're really only doing 32-bit mips you might consider removing the
> 64 bit targets in the config.bfd... I think that will solve the problems.
Nope, I insist 32-bit targets need to work correctly regardless of
whether there are any 64-bit ones supported by a particular BFD binary or
not. Do you think elf32-i386 should switch to printing 64-bit addresses
if elf64-alpha is also supported by a given configuration of BFD? I
don't.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2000-12-11 14:01 Heiko.Carstens
2000-12-11 15:14 ` your mail Alan Cox
0 siblings, 1 reply; 669+ messages in thread
From: Heiko.Carstens @ 2000-12-11 14:01 UTC (permalink / raw)
To: linux-kernel
Recently I had some thoughts on how to realise CPU attachment and
detachment in a running Linux system (based on the 2.4 kernel).
CPU attachment and detachment would make sense on an S/390 when there
are several Linuxes running, each in its own logical partition. This
way a CPU could be taken from one partition and be given to another
partition (e.g. dependent on the current workload) on the fly without
the need to reboot anything.
Now the question is: how can this goal be achieved?
Attachment of a new CPU:
The idea is to synchronize all CPUs and then start the new CPU with a
sigp. To synchronize n CPUs one can create n kernel threads and give
them a high priority to make sure they will be executed soon (e.g. by
setting p->policy to SCHED_RR and p->rt_priority to a very high
value). As soon as all CPUs are in synchronized state (with
interrupts disabled) the new CPU can be started. But before this can
be done there are some other things left to do:
First of all a new cpu_idle task needs to be created for the new CPU.
Unfortunately there are several other parts in the kernel that need
to be updated when a new CPU will be attached to the running system.
For example the slabcache has a per-CPU cache for each of its caches.
This implies that with the arrival of a new CPU for each of these
caches a new per-CPU cache needs to be allocated. This is of course
only one issue in the common part of the kernel that needs to be
addressed.
Considering this maybe it would be a good idea that each part of the
kernel that has per-CPU data structures that need an update should
register a function which will be called before a new CPU will be
attached to the system.
Then the attachment of a new CPU should work the following way:
- synchronize all CPUs via kernel threads
- create a new idle task
- update all parts of the kernel that have per-CPU dependencies with
the prior registered functions
- and finally start the new CPU (out of one of the kernel threads).
Detachment of a CPU:
Detaching a CPU should work nearly the same way:
- synchronize all CPUs via kernel threads
- stop the selected CPU (out of a kernel thread)
- update all parts of the kernel that have per-CPU dependencies with
registered functions
- and finally remove the cpu_idle task of the released CPU (and the
kernel thread which ran on the released CPU until the CPU was
stopped).
Detaching a CPU is a bit more difficult than attaching a CPU because
one has to think for example of pending tasklets on the to be stopped
CPU. But these could simply be moved to another CPU.
The general question is: what do all of you think of the idea of an
interface where the parts of the kernel that have per-CPU
dependencies should register two functions (one for attaching a CPU
and one for detaching)?
Any comments on this would be appreciated..
Best regards,
Heiko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2000-12-11 14:01 Heiko.Carstens
@ 2000-12-11 15:14 ` Alan Cox
0 siblings, 0 replies; 669+ messages in thread
From: Alan Cox @ 2000-12-11 15:14 UTC (permalink / raw)
To: Heiko.Carstens; +Cc: linux-kernel
> sigp. To synchronize n CPUs one can create n kernel threads and give
> them a high priority to make sure they will be executed soon (e.g. by
> setting p->policy to SCHED_RR and p->rt_priority to a very high
> value). As soon as all CPUs are in synchronized state (with
> interrupts disabled) the new CPU can be started. But before this can
> be done there are some other things left to do:
You dont IMHO need to use such a large hammer. We already do similar sequences
for tlb invalidation on X86 for example. You can broadcast an interprocessor
interrupt and have the other processors set a flag each. You spin until they
are all captured, then when you clear the flag they all continue. You just
need to watch two processors doing it at the same time 8)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 2000-09-04 12:01 Sahil
2000-09-04 15:35 ` your mail Rik van Riel
0 siblings, 1 reply; 669+ messages in thread
From: Sahil @ 2000-09-04 12:01 UTC (permalink / raw)
To: linux-mm
dear friends,
I am a newbie to kernel programming.
can anyone suggest some good readings for the same?
Shahil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <Pine.GSO.4.10.10007211305380.4421-100000@ux5.cso.uiuc.edu>]
* Re: your mail
[not found] <Pine.GSO.4.10.10007211305380.4421-100000@ux5.cso.uiuc.edu>
@ 2000-07-22 11:56 ` Matthew Wilcox
0 siblings, 0 replies; 669+ messages in thread
From: Matthew Wilcox @ 2000-07-22 11:56 UTC (permalink / raw)
To: borislav dzodzo; +Cc: willy, parisc-linux
On Fri, Jul 21, 2000 at 01:06:33PM -0500, borislav dzodzo wrote:
> hi i found some of your posts on
> http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/
> and i thought you might know if
> there already exists a linux version of fsck for
> under pa-risc for HFS (not apple but HewlettPackard).
HP's HFS is a BSD Fast Filesystem (FFS) derivative. There are a few
minor differences, but they are very closely related. By studying the
HP-specific magic numbers added to recent 2.3/4 series kernels, you should
have no problem making a fsck.ufs or fsck.ffs work on Linux. If anyone
can find one, let me know, and a mkfs would also be useful to have.
> if not... could you please tell me where are some good specs on
> HFS so that i could write my own.
--
Revolutions do not require corporate support.
^ permalink raw reply [flat|nested] 669+ messages in thread
[parent not found: <001e01bfed04$b27494a0$29e58aa4@crusman>]
* Re: your mail
[not found] <001e01bfed04$b27494a0$29e58aa4@crusman>
@ 2000-07-14 10:00 ` Gabriel Paubert
0 siblings, 0 replies; 669+ messages in thread
From: Gabriel Paubert @ 2000-07-14 10:00 UTC (permalink / raw)
To: Crusman; +Cc: ppc_mailing
On Thu, 13 Jul 2000, Crusman wrote:
> >The configurations I have are for 2600 with a PMC graphics board, remove
> >CONFIG_VT from the setup and it will use a serial console.
> >
> >BTW use PrePboot for these boards (CONFIG_PREPBOOT) since it gives a nicer
> >PCI layout to access the VMEbus...
> >
> >Please use the patches mvme2600.*.bz2...
>
> I have tested the patches but the new kernel don't see the scsi device...so
> I can't try it anyway !
Did you try the nfsroot (or nfsinstall but it's probably broken now) ? The
nfsroot does not have any CONFIG_VT set so it should work. At least it
works on headless 2600 and 2400.
> Yes, I have tested your kernel, but there is a message ( PC keyb error... or
> something like this) wich lock the kernel during the boot ! It's probably
> due to the Virtual Terminal support in the kernel !
> I always use the "console=ttyS0,9600" kernel option.
Then it should not do this, I don't know what happens. AFAIR it works on
MVME2400 whcih don't have the KB controller either.
> In short :
>
> - I can't use your kernel because of the PC_key error !
> - I can't patch & build a new kernel because this new kernel don't see my
> SCSI PMC !
Did you ever see the PMC module with some kernel ? Once booted (an nfsrrot
system is the best for this), see what you have in /proc/bus/pci.
Gabriel.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 2000-03-28 8:19 pnilesh
2000-03-28 13:26 ` Stephen C. Tweedie
0 siblings, 1 reply; 669+ messages in thread
From: pnilesh @ 2000-03-28 8:19 UTC (permalink / raw)
To: Kanoj Sarcar; +Cc: linux-mm
No, if both processes have faulted in the page into their ptes, it will
be 2. The page count is normally the number of references from user
ptes, plus any long/short term holds kernel code establishes on the
page.
I was confused as Maurice Bach increases region reference count when any
region say text is shared among more than one processes, and not the page
reference count.
One more thing if the process ocurrs a page fault on text page it calls
file_no_page()
>From what you said in this case it should increment the page count but in
this function no where I could see the page count getting incremented.
>
> Q When a page of a file is in page hash queue, does this page have
page
> table entry in any process ?
Possibly, if the file is mmaped into some other process.
> Q Can this be discarded right away , if the need arises?
>
At the minimum, you need to write modified contents back to disk, if
the file page has not already been discarded.
The David Rusling book says when reducing page cache and buffer cache the
page table entries are not modified and the pages can be dropped directly.
Kanoj
> Nilesh Patel
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux.eu.org/Linux-MM/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
2000-03-28 8:19 pnilesh
@ 2000-03-28 13:26 ` Stephen C. Tweedie
0 siblings, 0 replies; 669+ messages in thread
From: Stephen C. Tweedie @ 2000-03-28 13:26 UTC (permalink / raw)
To: pnilesh; +Cc: Kanoj Sarcar, linux-mm, Stephen Tweedie
Hi,
On Tue, Mar 28, 2000 at 01:49:04PM +0530, pnilesh@in.ibm.com wrote:
>
> No, if both processes have faulted in the page into their ptes, it will
> be 2.
3. The page cache counts as a reference.
> One more thing if the process ocurrs a page fault on text page it calls
> file_no_page()
> From what you said in this case it should increment the page count but in
> this function no where I could see the page count getting incremented.
It is done implicitly when filemap_nopage() looks for the page in the
page cache: __find_page() increments the reference count of any page
it finds before returning.
> The David Rusling book says when reducing page cache and buffer cache the
> page table entries are not modified and the pages can be dropped directly.
Yes, but it checks the page reference count to make sure it is legal to
do so first.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 1999-07-08 20:04 David Woodhouse
1999-07-08 22:53 ` your mail Jason Gunthorpe
0 siblings, 1 reply; 669+ messages in thread
From: David Woodhouse @ 1999-07-08 20:04 UTC (permalink / raw)
To: D. Jeff Dionne / VE3DJF; +Cc: mtd
Hmmm. Majordomo bounced my mail too - it seems we're not allowed to use the
s-word at all....
jeff@ampr.harc.on.ca said:
> Just joined the mailing list (likely you saw my [word that majordomo
> doesn't like] go by, I copied the address blindly and later noticed I sent
> it to the list and not the majordomo :-( )
No - the subscr^H^H^H^H^H^H request got caught by majordomo and didn't get sent
to the list.
Strangely, your second mail got caught by the same rule, and didn't get sent
to the list either. Try it again and see if it's just sulking at you for
sending the request to the wrong address :)
> Anyway, having come over from the uClinux project, I am very
> interested in anything you may have. I can also lend a hand. We've
> had XIP from FLASH now for about a year, but are stuck using ROMfs
> (which as you know is read only).
> So I'll be the newbe and ask... What's the current status of the project?
We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is
something like this:
Two years ago, I was employed by Nortel to provide a driver for M-Systems'
Disk-On-Chip 1000, and I started a generic system for 'Memory Technology
Devices', based heavily on David Hinds' similar work in the PCMCIA subsystem.
This has lain fallow since then, except when people have asked me about it,
when I've pointed them at the tarball and told them to play with it if they so
desire.
Since then, at least two other people have come up with similar implementations
and added drivers for their own hardware. I'm currently working on
identifying the best features of all of them, and combining them into a single
system to which we can port all the available hardware drivers.
You can find three of these implementations on ftp.linux-mtd.infradead.org in
the /pub/mtd directory:
flash.diff - Kernel patch to support FTL on CFI-compliant flash
mtd-990108.tar.gz - My original tarball - midlevel glue layer,
FTL driver,
Disk-On-Chip 1000 driver,
Uncached system RAM driver.
mtd-19990629-jgg.tar.gz - Modified version of the above, with some extra
sensible features in the midlevel layer,
and a couple more hardware drivers.
That's basically the current status - fairly fragmented. I hope that within a
week or so we can have the whole lot working together, and agree on a feature
set for it. Any input from the uClinux project would be very much appreciated.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
1999-07-08 20:04 David Woodhouse
@ 1999-07-08 22:53 ` Jason Gunthorpe
1999-07-09 7:09 ` D. Jeff Dionne / VE3DJF
0 siblings, 1 reply; 669+ messages in thread
From: Jason Gunthorpe @ 1999-07-08 22:53 UTC (permalink / raw)
To: David Woodhouse; +Cc: D. Jeff Dionne / VE3DJF, mtd
On Thu, 8 Jul 1999, David Woodhouse wrote:
> > Anyway, having come over from the uClinux project, I am very
> > interested in anything you may have. I can also lend a hand. We've
> > had XIP from FLASH now for about a year, but are stuck using ROMfs
> > (which as you know is read only).
Can you fire over your patch to ROMfs to make it do this? The 2.2.10
kernel version doesn't.
> We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is
> something like this:
I have read only ffs2 running, but the hair brained compression scheme is
giving me pain :<
On lwn there was a pointer to a Hard Hat linux which also claimed flash
support with a flash file system, anyone know more about those guys?
Jason
To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1999-07-08 22:53 ` your mail Jason Gunthorpe
@ 1999-07-09 7:09 ` D. Jeff Dionne / VE3DJF
1999-07-09 15:27 ` Jason Gunthorpe
0 siblings, 1 reply; 669+ messages in thread
From: D. Jeff Dionne / VE3DJF @ 1999-07-09 7:09 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: mtd
>
> On Thu, 8 Jul 1999, David Woodhouse wrote:
>
> > > Anyway, having come over from the uClinux project, I am very
> > > interested in anything you may have. I can also lend a hand. We've
> > > had XIP from FLASH now for about a year, but are stuck using ROMfs
> > > (which as you know is read only).
>
> Can you fire over your patch to ROMfs to make it do this? The 2.2.10
> kernel version doesn't.
Unfortunately, in it's current form it will not be of any use to you I suspect.
It's for 2.0.37, and is tied up with another meg of patch. It touches lots
of stuff, and it needs cleaning :-(
We're also very 68k right now, so Linux/Intel would be some work. You'll
need fully position independant code to start with... Does -fpic go far enough
on Intel? You'll need to hack the ELF loader, we run a simple (low overhead)
binary format.
>
> > We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is
> > something like this:
>
> I have read only ffs2 running, but the hair brained compression scheme is
> giving me pain :<
>
> On lwn there was a pointer to a Hard Hat linux which also claimed flash
> support with a flash file system, anyone know more about those guys?
>
> Jason
>
To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1999-07-09 7:09 ` D. Jeff Dionne / VE3DJF
@ 1999-07-09 15:27 ` Jason Gunthorpe
0 siblings, 0 replies; 669+ messages in thread
From: Jason Gunthorpe @ 1999-07-09 15:27 UTC (permalink / raw)
To: D. Jeff Dionne / VE3DJF; +Cc: mtd
On Fri, 9 Jul 1999, D. Jeff Dionne / VE3DJF wrote:
> > Can you fire over your patch to ROMfs to make it do this? The 2.2.10
> > kernel version doesn't.
>
> Unfortunately, in it's current form it will not be of any use to you I suspect.
> It's for 2.0.37, and is tied up with another meg of patch. It touches lots
> of stuff, and it needs cleaning :-(
>
> We're also very 68k right now, so Linux/Intel would be some work. You'll
> need fully position independant code to start with... Does -fpic go far enough
> on Intel? You'll need to hack the ELF loader, we run a simple (low overhead)
> binary format.
Oh this is not at all what I was thinking, on Intel all we'd need to do is
setup the proper page tables so that each 4k page mapped to the correct 4k
chunk of flash, the FFS write unit size and alignment would be set to 4k
for executables. There should be no need to worry about pic and elf will
run fine like that too.
It should be really simple if someone can think up either a modification
to readpage() that adjusts the physical location of the given page
structure or a new mmap that sets up a new page table mapping..
Jason
To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1999-05-01 2:35 Bill Nottingham
0 siblings, 0 replies; 669+ messages in thread
From: Bill Nottingham @ 1999-05-01 2:35 UTC (permalink / raw)
To: linux-sound
jason (rohwedde@uiuc.edu) said:
> Does anyone know how to make a pci card with a ensoniq es1370 chipset on it
> work with linux?? It came out of a gateway.. thanks for any help
You should just be able to use the es1370 driver, either the one
in the standard 2.2 kernel or in the ALSA project.
Bill
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 1999-02-13 17:50 Benjamin Herrenschmidt
1999-02-15 9:58 ` your mail Gabriel Paubert
0 siblings, 1 reply; 669+ messages in thread
From: Benjamin Herrenschmidt @ 1999-02-13 17:50 UTC (permalink / raw)
To: Paul Mackerras, Cort Dougan, linuxppc-dev
Hi !
I would like your point of view about the following:
The kernel entry code starts playing with BATs as soon as it is entered.
Isn't that dangerous ? I mean, you must have enough luck for this BAT not
to be used at this specific time, or not overlapping another BAT setup by
MacOS (overlapping BATs causes undefined behaviour according to the PPC
manual) ?
I have made a test bootx that I'll upload to
ftp.linuxppc.org/developement/users/benh later today (the archive will
probably be called BootX_phys_test.sit). This version of BootX doesn't
jump directly to the kernel but goes to a small piece of PPC asm that
will cause the kernel to be entered with MMU (and interrupts) disabled. I
beleive this should get rid of potential problems with TLB misses during
boot too. Of course, all addresses passed to the kernel are turned into
physical addresses (frame buffer, stack, boot_infos).
This version works on my desktop G3, I didn't have time to test it on
other machines yet.
The bootstrap code is simple (it's entered with the same parameters as
the kernel, but with physical addresses and with the kernel physical
entry in r6) :
/* switch interrupts off */
mfmsr r0;
ori r31,r31,MSR_EE;
andc r0,r0,r31;
sync;
mtmsr r0;
sync;
/* put kernel entry (phys) in ssr0 */
mtspr SSR0, r6;
/* Setup ssr1 (kernel entry MSR) */
ori r31,r31,(MSR_IR|MSR_DR);
andc r0,r0,r31;
mtspr SSR1, r0;
/* Branch to the kernel */
rfi;
Note: I wrote this little piece of asm with CodeWarrior. Since I would
like to make a C boostrap that takes place between this and the kernel, I
still need to figure out how to build code for this with egcs. If I could
find the correct MakeFile options to get an output like prom.c
(PC-relative branches, datas accessed thru a RELOC macro), I think it
would be just fine. A better approach would be to store datas relative to
a register that I can setup before entering the boostrap, but that means
parsing enough of the ELF to extract the offset of the datas. I would
appreciate if someone could give me some tips about what is usually done
in those cases or some pointers to infos/samples.
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
1999-02-13 17:50 Benjamin Herrenschmidt
@ 1999-02-15 9:58 ` Gabriel Paubert
1999-02-15 11:23 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 669+ messages in thread
From: Gabriel Paubert @ 1999-02-15 9:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, Cort Dougan, linuxppc-dev
On Sat, 13 Feb 1999, Benjamin Herrenschmidt wrote:
>
> Hi !
>
> I would like your point of view about the following:
>
> The kernel entry code starts playing with BATs as soon as it is entered.
> Isn't that dangerous ? I mean, you must have enough luck for this BAT not
> to be used at this specific time, or not overlapping another BAT setup by
> MacOS (overlapping BATs causes undefined behaviour according to the PPC
> manual) ?
One of the first steps I do in prepboot is to invalidate all the BATs and
all the TLB entries, to make sur that I start from a known state
(invalidating the BATs is a pain because it's different in 601 and
others). But then I'm quite sure I'm called with address translation
disabled, only that some FW version leave stale values in these registers.
> I have made a test bootx that I'll upload to
> ftp.linuxppc.org/developement/users/benh later today (the archive will
> probably be called BootX_phys_test.sit). This version of BootX doesn't
> jump directly to the kernel but goes to a small piece of PPC asm that
> will cause the kernel to be entered with MMU (and interrupts) disabled. I
> beleive this should get rid of potential problems with TLB misses during
> boot too. Of course, all addresses passed to the kernel are turned into
> physical addresses (frame buffer, stack, boot_infos).
I still had problems with stale TLB entries between prepboot when the
kernel enabled the MMU. You have to flush the TLB before starting the
kernel to be absolutely sure that there the kernel uses only translations
it has defined (I discovered that I had added code accessing I/O
space before the corresponding BATs were set up due to staale TLB
entries).
> This version works on my desktop G3, I didn't have time to test it on
> other machines yet.
> The bootstrap code is simple (it's entered with the same parameters as
> the kernel, but with physical addresses and with the kernel physical
> entry in r6) :
>
> /* switch interrupts off */
> mfmsr r0;
> ori r31,r31,MSR_EE;
> andc r0,r0,r31;
> sync;
> mtmsr r0;
> sync;
Wrong, what is in r31 before ? You may clear unwanted MSR bits:
mfmsr r0
rlwinm r0,r0,0,17,15
mtmsr r0
is enough (And if you don't like using rlwinm like this, which is
guaranteed to work according to the architecture):
mfmsr r0
ori r0,r0,MSR_EE
xori r0,r0,MSR_EE
mtmsr r0
and you never need a sync before or after disabling interrupts. It is
different when enabling them however, because you have to make
sure that accesses to the interrupt controller have made it to the bus.
>
> /* put kernel entry (phys) in ssr0 */
> mtspr SSR0, r6;
>
> /* Setup ssr1 (kernel entry MSR) */
> ori r31,r31,(MSR_IR|MSR_DR);
> andc r0,r0,r31;
> mtspr SSR1, r0;
>
> /* Branch to the kernel */
> rfi;
>
> Note: I wrote this little piece of asm with CodeWarrior. Since I would
> like to make a C boostrap that takes place between this and the kernel, I
> still need to figure out how to build code for this with egcs. If I could
> find the correct MakeFile options to get an output like prom.c
> (PC-relative branches, datas accessed thru a RELOC macro), I think it
> would be just fine. A better approach would be to store datas relative to
> a register that I can setup before entering the boostrap, but that means
> parsing enough of the ELF to extract the offset of the datas. I would
> appreciate if someone could give me some tips about what is usually done
> in those cases or some pointers to infos/samples.
I would recommend that you take a look at the patch files I have for
prep (only have a look at the prepboot directory):
ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.1.gz
it is even probably overkill for what you need. But the Makefile
(with -m rleocatable), the linker script (ppcboot.lds) and the
early boot (head.S) are probably good examples (and I tried to keep them
clean).
Gabriel.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1999-02-15 9:58 ` your mail Gabriel Paubert
@ 1999-02-15 11:23 ` Benjamin Herrenschmidt
1999-02-15 14:18 ` Gabriel Paubert
0 siblings, 1 reply; 669+ messages in thread
From: Benjamin Herrenschmidt @ 1999-02-15 11:23 UTC (permalink / raw)
To: Gabriel Paubert, linuxppc-dev
On Mon, Feb 15, 1999, Gabriel Paubert <paubert@iram.es> wrote:
>One of the first steps I do in prepboot is to invalidate all the BATs and
>all the TLB entries, to make sur that I start from a known state
>(invalidating the BATs is a pain because it's different in 601 and
>others). But then I'm quite sure I'm called with address translation
>disabled, only that some FW version leave stale values in these registers.
My bootstrap is now a two-step bootstrap too, written all in asm to avoid
relocation problems.
>I still had problems with stale TLB entries between prepboot when the
>kernel enabled the MMU. You have to flush the TLB before starting the
>kernel to be absolutely sure that there the kernel uses only translations
>it has defined (I discovered that I had added code accessing I/O
>space before the corresponding BATs were set up due to staale TLB
>entries).
Since the MMU is switched off by the boostrap, I beleive those TLB
entries won't do any harm until the kernel switches the MMU back on,
that's it ? (I just want to make sure I fully understand). So, basically,
I could add to my bootstrap a piece of code that invalidates all BATs and
flush the TLB (I'll look at your preploader code for that).
>Wrong, what is in r31 before ? You may clear unwanted MSR bits:
You are right. I already changed this to rlwinm approx. 5 minutes after
sending the previous mail ;-)
> mfmsr r0
> rlwinm r0,r0,0,17,15
> mtmsr r0
>
>is enough (And if you don't like using rlwinm like this, which is
>guaranteed to work according to the architecture):
>
> mfmsr r0
> ori r0,r0,MSR_EE
> xori r0,r0,MSR_EE
> mtmsr r0
>
>and you never need a sync before or after disabling interrupts. It is
>different when enabling them however, because you have to make
>sure that accesses to the interrupt controller have made it to the bus.
Ok, so I'll finally remove this sync.
>I would recommend that you take a look at the patch files I have for
>prep (only have a look at the prepboot directory):
>
> ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.1.gz
>
>it is even probably overkill for what you need. But the Makefile
>(with -m rleocatable), the linker script (ppcboot.lds) and the
>early boot (head.S) are probably good examples (and I tried to keep them
>clean).
Ok, thanks.
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
1999-02-15 11:23 ` Benjamin Herrenschmidt
@ 1999-02-15 14:18 ` Gabriel Paubert
1999-02-15 17:42 ` David Edelsohn
0 siblings, 1 reply; 669+ messages in thread
From: Gabriel Paubert @ 1999-02-15 14:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Mon, 15 Feb 1999, Benjamin Herrenschmidt wrote:
> My bootstrap is now a two-step bootstrap too, written all in asm to avoid
> relocation problems.
Well, -m relocate is quite powerful IMHO. And I tried to write as little
assembly as possible, as you can easily guess from the 5000 lines of
PPC assembly of the x86 emulator :-)
> Since the MMU is switched off by the boostrap, I beleive those TLB
> entries won't do any harm until the kernel switches the MMU back on,
> that's it ? (I just want to make sure I fully understand). So, basically,
> I could add to my bootstrap a piece of code that invalidates all BATs and
> flush the TLB (I'll look at your preploader code for that).
No, but I need to run the bootloader mostly with MMU on to initialize the
VGA boards by emulating the VGA ROM BIOS for 2 reasons:
- having correct memeory attributes and the caches enabled,
- emulating the 1Mb of Intel Mobo (640k RAM+128k VGA+ ROM BIOS...)
I found that if I did not invalidate the TLB before starting the kernel, I
was allowed to do strange things (specifically accessing I/O space before
it was even mapped by BATs or PTE) due to stale TLB entries. This caused
the introduction of a few bugs in some versions of my PreP initialization
code which were extremely hard to find. I even was unlucky enough to fall
on the borderline case where adding or suppressing a single debug message
in the loader cause the critical TLB entry to be valid or invalid.
Note that my code to invalidate TLB is the hammer to kill flies method: it
is guaranteed to work for all PPC (except embedded) implementations from
the architectural handbook because I don't want to rely on any system info
(too often wrong), so I invalidate 65536 TLB entries. In a bootloader, I
obviously don't care about the couple of milliseconds it takes.
>
> >Wrong, what is in r31 before ? You may clear unwanted MSR bits:
>
> You are right. I already changed this to rlwinm approx. 5 minutes after
> sending the previous mail ;-)
Ok, better like this. Unfortunately for rlwinm and friends, gas allows you
to replace the last 2 parameters by a single value (bit mask), for
example: rlwinm r3,r4,0, 0x00ffff00, but it does not work if you have the
complementary mask (ones, zeros, ones) so you can't type rlwinm
r0,r0,0,~MSR_EE. Note that gcc/egcs would generate the code with the
rlwinm instruction. Anybody wants to tweak binutils to allow this ?
Gabriel.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1999-02-15 14:18 ` Gabriel Paubert
@ 1999-02-15 17:42 ` David Edelsohn
0 siblings, 0 replies; 669+ messages in thread
From: David Edelsohn @ 1999-02-15 17:42 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Benjamin Herrenschmidt, linuxppc-dev
>>>>> Gabriel Paubert writes:
Gabriel> Ok, better like this. Unfortunately for rlwinm and friends, gas allows you
Gabriel> to replace the last 2 parameters by a single value (bit mask), for
Gabriel> example: rlwinm r3,r4,0, 0x00ffff00, but it does not work if you have the
Gabriel> complementary mask (ones, zeros, ones) so you can't type rlwinm
Gabriel> r0,r0,0,~MSR_EE. Note that gcc/egcs would generate the code with the
Gabriel> rlwinm instruction. Anybody wants to tweak binutils to allow this ?
I think that this already was discovered and fixed in the
development sources. From the ChangeLog:
Wed Aug 12 14:00:38 1998 Ian Lance Taylor <ian@cygnus.com>
From Peter Thiemann <thiemann@informatik.uni-tuebingen.de>:
* ppc-opc.c (insert_mbe): Handle wrapping bitmasks.
(extract_mbe): Likewise.
David
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1998-09-25 17:26 rtlynch
0 siblings, 0 replies; 669+ messages in thread
From: rtlynch @ 1998-09-25 17:26 UTC (permalink / raw)
To: linux-sound
You need the isapnp package. This package has tools to inspect isa cards
and also to activate the recomended pnp settings. I belive the home page
is at http://www.roestock.demon.co.uk/isapnptools
-Rusty Lynch
On Thu, 24 Sep 1998, Jonathan Herringer (PHY) wrote:
> I have a PnP Sound blaster card that can't get detected by linux. I have
> soft booted from widows, dos and it still doesnt' get detected.
>
> I got the latest version of the kernel (2.1.122) with plug and play
> support (but couldn't find any thing on how to configure the PnP)
>
> Can any one suggest reading material etc... I have read the Sound HOW-To
>
>
> Thanks,
> Jonathan Herringer
>
>
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 1998-02-25 22:15 Rik van Riel
1998-02-25 22:48 ` your mail Linus Torvalds
0 siblings, 1 reply; 669+ messages in thread
From: Rik van Riel @ 1998-02-25 22:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen C. Tweedie, linux-mm
Hi,
I've just come up with a very simple idea to limit
thrashing, and I'm asking you if you want it implemented
(there's some cost involved :-( ).
We could simply prohibit the VM subsystem from swapping
out pages which have been allocated less than one second
ago, this way the movement of pages becomes 'slower', and
thrashing might get somewhat less.
The cost involved is that we have to add a new entry
to the page_struct :-( and do some (relatively cheap)
bookkeeping on every page. Also, this might limit the
rate of allocation some programs do, giving rise to
all sorts of new and exiting problems.
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1998-02-25 22:15 Rik van Riel
@ 1998-02-25 22:48 ` Linus Torvalds
1998-02-25 23:26 ` Rik van Riel
0 siblings, 1 reply; 669+ messages in thread
From: Linus Torvalds @ 1998-02-25 22:48 UTC (permalink / raw)
To: Rik van Riel; +Cc: Stephen C. Tweedie, linux-mm
On Wed, 25 Feb 1998, Rik van Riel wrote:
>
> I've just come up with a very simple idea to limit
> thrashing, and I'm asking you if you want it implemented
> (there's some cost involved :-( ).
>
> We could simply prohibit the VM subsystem from swapping
> out pages which have been allocated less than one second
> ago, this way the movement of pages becomes 'slower', and
> thrashing might get somewhat less.
I'm _really_ nervous about "rate-based" limiting. Personally I think that
it only makes sense for things like networking, and even there it had
better be done by hardware.
The reason I dislike rate-based things is that it is _so_ hard to give any
kind of guarantees at all on the sanity of the thing. You can tweak the
rates, but they don't have any logic to them, and most importantly they
are very hard to make self-tweaking.
I tend to prefer a "balancing" approach to these problems: the important
part about balancing is that while it may not have some specific
well-defined behaviour that you can point your finger to ("will not page
out the same page that it paged in within 5 seconds"), the basic approach
is to write something that doesn't have any hard rules but that TENDS
towards some certain goal.
That way you get algorithms that you can be fairly confident work well in
the normal cases (because you test those normal cases), and because there
are no hard rules you also don't get strange "edges" when something
unexpected happens: performance may well degrade badly, but it degrades
_softly_ rather than in quantisized jumps.
Linus
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
1998-02-25 22:48 ` your mail Linus Torvalds
@ 1998-02-25 23:26 ` Rik van Riel
0 siblings, 0 replies; 669+ messages in thread
From: Rik van Riel @ 1998-02-25 23:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen C. Tweedie, linux-mm
On Wed, 25 Feb 1998, Linus Torvalds wrote:
> > We could simply prohibit the VM subsystem from swapping
> > out pages which have been allocated less than one second
> > ago, this way the movement of pages becomes 'slower', and
> > thrashing might get somewhat less.
>
> The reason I dislike rate-based things is that it is _so_ hard to give any
> kind of guarantees at all on the sanity of the thing. You can tweak the
> rates, but they don't have any logic to them, and most importantly they
> are very hard to make self-tweaking.
Yup, I don't like 'em either, but I proposed it anyways
in case anyone of you might like it :-)
Personally, I like balancing code too, if possible with
some balancing on the balancing code as well...
OK, we go with balancing code.
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
^ permalink raw reply [flat|nested] 669+ messages in thread
* (no subject)
@ 1997-08-09 17:16 Vincent Renardias
1997-08-09 17:41 ` Ralf Baechle
0 siblings, 1 reply; 669+ messages in thread
From: Vincent Renardias @ 1997-08-09 17:16 UTC (permalink / raw)
To: linux
Hello,
I've just joined this ML, and I'm trying to contribute to the
Linux/SGI development. Since I'm not too good at kernel hacking, I've
tough about working on porting the userland part (I have some experience
with this part since I've been a Debian developper for a while and
initiated the Debian/PowerPC port).
By now I don't have access to any SGI hardware, but i've been able
to build some packages with the crossdev (i486-linux) packages from
ftp.linux.sgi.com.
So here are my questions:
1/ Which are the 'most wanted' packages not yet recompiled/ported to
Linux/SGI? I've looked at the RPMs available RPM list, and some important
packages seem unavailable yet. (sed,tar,perl come to mind).
2/ While using the crossdev gcc, several times I got complains about a
file 'sgidefs.h' missing (from
/usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41).
Commenting the '#include' file made the compile work, but I not sure it's
the right fix.
3/ Can any1 confirm/correct the following values for GNU/autoconf:
ac_cv_c_bigendian=no
ac_cv_c_char_unsigned=no
ac_cv_sizeof_long=4
ac_cv_sizeof_int=4
Cordialement,
--
- ** Linux ** +-------------------+ ** WAW ** -
- vincent@debian.org | RENARDIAS Vincent | vincent@waw.com -
- Debian/GNU Linux +-------------------+ http://www.waw.com/ -
- http://www.debian.org/ | WAW (33) 4 91 81 21 45 -
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1997-08-09 17:41 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 1997-08-09 17:41 UTC (permalink / raw)
To: Vincent Renardias; +Cc: linux
> I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
>
> So here are my questions:
>
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).
sed, tar: confilicting declaration in source and libc. Both work other-
wise. Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails. I think because groff/man are missing. I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...
> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41).
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix.
Not the right thing, but won't hurt. I shows that your libc is
not installed correctly.
> 3/ Can any1 confirm/correct the following values for GNU/autoconf:
> ac_cv_c_bigendian=no
MIPS CPUs can be configured for both byte orders. SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware. As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.
> ac_cv_c_char_unsigned=no
True by default, unless you give -funsigned-char.
> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4
True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64. These options
are incompatible with libc, so I mention them only for completeness.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 1997-08-09 17:41 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 1997-08-09 17:41 UTC (permalink / raw)
To: Vincent Renardias; +Cc: linux
> I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
>
> So here are my questions:
>
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).
sed, tar: confilicting declaration in source and libc. Both work other-
wise. Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails. I think because groff/man are missing. I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...
> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41).
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix.
Not the right thing, but won't hurt. I shows that your libc is
not installed correctly.
> 3/ Can any1 confirm/correct the following values for GNU/autoconf:
> ac_cv_c_bigendian=no
MIPS CPUs can be configured for both byte orders. SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware. As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.
> ac_cv_c_char_unsigned=no
True by default, unless you give -funsigned-char.
> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4
True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64. These options
are incompatible with libc, so I mention them only for completeness.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
1997-08-09 17:41 ` Ralf Baechle
(?)
@ 1997-08-09 19:40 ` Vincent Renardias
1997-08-09 19:42 ` Ralf Baechle
-1 siblings, 1 reply; 669+ messages in thread
From: Vincent Renardias @ 1997-08-09 19:40 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux
On Sat, 9 Aug 1997, Ralf Baechle wrote:
> > 2/ While using the crossdev gcc, several times I got complains about a
> > file 'sgidefs.h' missing (from
> > /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41).
> > Commenting the '#include' file made the compile work, but I not sure it's
> > the right fix.
>
> Not the right thing, but won't hurt. I shows that your libc is
> not installed correctly.
I just installed the binutils/gcc crossdev packages from
ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
(i386).
[Thanx for the explanation on endianess ;]
Cordialement,
--
- ** Linux ** +-------------------+ ** WAW ** -
- vincent@debian.org | RENARDIAS Vincent | vincent@waw.com -
- Debian/GNU Linux +-------------------+ http://www.waw.com/ -
- http://www.debian.org/ | WAW (33) 4 91 81 21 45 -
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1997-08-09 19:42 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 1997-08-09 19:42 UTC (permalink / raw)
To: Vincent Renardias; +Cc: ralf, linux
> > Not the right thing, but won't hurt. I shows that your libc is
> > not installed correctly.
>
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).
Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one. DANGER: When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system. MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)
Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native. The sole problems I currently have is that the kernel
seems to have some memory corruption problem. That is nasty because
it usually hits the bitmaps ... It might as well explain Miguel's
recently reported NFS problem.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1997-08-09 19:42 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 1997-08-09 19:42 UTC (permalink / raw)
To: Vincent Renardias; +Cc: ralf, linux
> > Not the right thing, but won't hurt. I shows that your libc is
> > not installed correctly.
>
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).
Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one. DANGER: When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system. MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)
Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native. The sole problems I currently have is that the kernel
seems to have some memory corruption problem. That is nasty because
it usually hits the bitmaps ... It might as well explain Miguel's
recently reported NFS problem.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1997-08-09 19:42 ` Ralf Baechle
(?)
@ 1997-08-09 21:05 ` Vincent Renardias
1997-08-09 21:11 ` Ralf Baechle
1997-08-09 22:53 ` Mike Shaver
-1 siblings, 2 replies; 669+ messages in thread
From: Vincent Renardias @ 1997-08-09 21:05 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux
On Sat, 9 Aug 1997, Ralf Baechle wrote:
> > I just installed the binutils/gcc crossdev packages from
> > ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> > from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> > (i386).
>
> Well, it doesn't matter except that I built the executables with Linux
> libc and you therefore need that one. DANGER: When you install libs
> for a crosscompiler you will have to move the libs a bit around.
> Just doing tar zxf ... -C / will fry your native system. MIPS stuff
> just has too much octane to be suitable as fuel for your Intel machine ;-)
Debian provides nice tools to handdle this kind of installation:
- alien: allows to convert binary packages between any 2 of the
{.deb,.tgz,.rpm} formats.
- dpkg-cross: tool handdling cross-compilation packages. That is any file
that should go into /*/lib is redirected into /usr/local/$ARCH-linux/lib.
(same for the include files). It also makes it possible to build a given
package for several architectures at the same time.
Those tools should probably work on any Linux flavour (distrib./arch.)
Anyway, I've installed glibc-2.0.4 to get around the missing sgidefs.h
problem, and I run into another problem:
now mips-linux-gcc complains about:
% mips-linux-gcc -o pwgen pwgen.o -lm
/usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
index; run ranlib to add one
running mips-linux-ranlib on the given file does not change anything.
(ie: still getting the same message)
Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
Cordialement,
--
- ** Linux ** +-------------------+ ** WAW ** -
- vincent@debian.org | RENARDIAS Vincent | vincent@waw.com -
- Debian/GNU Linux +-------------------+ http://www.waw.com/ -
- http://www.debian.org/ | WAW (33) 4 91 81 21 45 -
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread* Re: your mail
@ 1997-08-09 21:11 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 1997-08-09 21:11 UTC (permalink / raw)
To: Vincent Renardias; +Cc: ralf, linux
> % mips-linux-gcc -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
>
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
>
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
No. Looks as if your lib still isn't correctly installed. If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1997-08-09 21:11 ` Ralf Baechle
0 siblings, 0 replies; 669+ messages in thread
From: Ralf Baechle @ 1997-08-09 21:11 UTC (permalink / raw)
To: Vincent Renardias; +Cc: ralf, linux
> % mips-linux-gcc -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
>
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
>
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
No. Looks as if your lib still isn't correctly installed. If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.
Ralf
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
1997-08-09 21:11 ` Ralf Baechle
(?)
@ 1997-08-10 2:57 ` Vincent Renardias
-1 siblings, 0 replies; 669+ messages in thread
From: Vincent Renardias @ 1997-08-10 2:57 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux
On Sat, 9 Aug 1997, Ralf Baechle wrote:
> > % mips-linux-gcc -o pwgen pwgen.o -lm
> > /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> > index; run ranlib to add one
> >
> > running mips-linux-ranlib on the given file does not change anything.
> > (ie: still getting the same message)
> >
> > Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
>
> No. Looks as if your lib still isn't correctly installed. If ranlib
> doesn't help, then your libc.a is probably corrupted into a zero lenght
> file.
You're right. (Not an empty file through, but somehow it got truncated to
~50 K). Reinstalling fixed it.
Here's the list of what I compiled so far:
file_3.20.1-6_mips.deb gzip_1.2.4-15_mips.deb
debmake_3.3.11_mips.deb grep_2.0-12_mips.deb
dpkg-dev_1.4.0.8_all.deb makedev_1.6-16_mips.deb
dpkg_1.4.0.8_mips.deb sysklogd_1.3-17_mips.deb
dpkg_1.4.0.8_mips.nondebbin.tar.gz update_1.3-1_mips.deb
cpio_2.4.2-11_mips.deb tar_1.12-1_mips.deb
patch_2.2-1_mips.deb sed_2.05-15_mips.deb
flex_2.5.4a-1_mips.deb findutils_4.1-23_mips.deb
bison_1.25-9_mips.deb shellutils_1.16-4_mips.deb
diff_2.7-13_mips.deb textutils_1.22-2_mips.deb
rpm_2.4.2-2_mips.deb pwgen_1-8_mips.deb
adduser_3.6_all.deb
These packages are available from odin.waw.com/pub/linux (the pgp signed
checksums are in the changes/ subdirectory). I'd be glad if someone could
test a few of them and tell me if everything is okay.
Quick install instructions:
untar the file dpkg_1.4.0.8_mips.nondebbin.tar.gz at the root of your FS,
then install other packages with 'dpkg -i foo.deb'.
Cordialement,
--
- ** Linux ** +-------------------+ ** WAW ** -
- vincent@debian.org | RENARDIAS Vincent | vincent@waw.com -
- Debian/GNU Linux +-------------------+ http://www.waw.com/ -
- http://www.debian.org/ | WAW (33) 4 91 81 21 45 -
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1997-08-09 22:53 ` Mike Shaver
0 siblings, 0 replies; 669+ messages in thread
From: Mike Shaver @ 1997-08-09 22:53 UTC (permalink / raw)
To: Vincent Renardias; +Cc: ralf, linux
Thus spake Vincent Renardias:
> % mips-linux-gcc -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
>
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.
Mike
--
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation
#> Chief System Architect and Herder of Bits
#>
#> "Yoda say, `Just slap a little public key crypto into it' does not
#> a secure system make." -- Marcus J. Ranum (mjr@clark.net)
^ permalink raw reply [flat|nested] 669+ messages in thread
* Re: your mail
@ 1997-08-09 22:53 ` Mike Shaver
0 siblings, 0 replies; 669+ messages in thread
From: Mike Shaver @ 1997-08-09 22:53 UTC (permalink / raw)
To: Vincent Renardias; +Cc: ralf, linux
Thus spake Vincent Renardias:
> % mips-linux-gcc -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
>
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.
Mike
--
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation
#> Chief System Architect and Herder of Bits
#>
#> "Yoda say, `Just slap a little public key crypto into it' does not
#> a secure system make." -- Marcus J. Ranum (mjr@clark.net)
^ permalink raw reply [flat|nested] 669+ messages in thread
end of thread, other threads:[~2024-02-14 14:09 UTC | newest]
Thread overview: 669+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-12 13:28 Philip K.F. Hölzenspies
2003-01-12 17:57 ` Shawn Starr
2003-01-13 16:37 ` your mail Pete Zaitcev
-- strict thread matches above, loose matches on Subject: below --
2024-02-09 12:30 Ulf Hansson
2024-02-14 14:09 ` your mail Konstantin Ryabitsev
2023-10-16 12:31 Gilbert Adikankwu
2023-10-16 12:34 ` your mail Julia Lawall
2023-10-16 12:42 ` Gilbert Adikankwu
2023-10-16 13:23 ` Julia Lawall
2023-05-25 12:01 Murphy Zhou
2023-05-25 12:04 ` your mail Christoph Hellwig
2023-05-25 12:45 ` Murphy Zhou
2023-05-10 19:01 [PATCH] maple_tree: Fix a few documentation issues, Thomas Gleixner
2023-05-15 19:27 ` your mail Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
2023-05-23 13:46 ` Liam R. Howlett
2023-04-26 14:35 Bryan O'Donoghue
2023-04-26 20:54 ` your mail Konstantin Ryabitsev
2023-03-17 16:36 Sumitra Sharma
2023-03-17 16:47 ` your mail Julia Lawall
2023-03-17 18:17 ` Sumitra Sharma
2023-03-19 8:09 ` Sumitra Sharma
2023-03-19 8:35 ` Julia Lawall
2023-03-19 8:56 ` Sumitra Sharma
2023-03-19 9:02 ` Julia Lawall
2023-03-19 9:53 ` Sumitra Sharma
2022-02-03 13:41 Harald Hoyer
2022-02-03 14:18 ` your mail Konstantin Ryabitsev
[not found] <CAP7CzPfLu6mm6f2fon-zez3PW6rDACEH6ihF2aG+1Dc7Zc2WuQ@mail.gmail.com>
2021-09-13 6:06 ` Willy Tarreau
2021-08-21 8:59 Kari Argillander
2021-08-22 13:13 ` your mail CGEL
2021-08-16 2:46 Kari Argillander
2021-08-16 12:27 ` your mail Christoph Hellwig
2021-04-07 1:27 [PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-PC kernel: [ 466.271037] page:980000025fca4170 count:0 mapcount:0 mapping:980000025a0dca60 index:0x0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271039] flags: 0x1e01fff000000() Feb 6 17:13:13 aaa-PC kernel: [ 466.271042] raw: 0001e01fff000000 0000000000000100 0000000000000200 980000025a0dca60 Feb 6 17:13:13 aaa-PC kernel: [ 466.271044] raw: 0000000000000000 0000000000000000 00000000ffffffff Feb 6 17:13:13 aaa-PC kernel: [ 466.271046] page dumped because: non-NULL mapping Feb 6 17:13:13 aaa-PC kernel: [ 466.271047] Modules linked in: bnep fuse bluetooth ecdh_generic sha256_generic cfg80211 rfkill vfat fat serio_raw uio_pdrv_genirq binfmt_misc ip_tables amdgpu chash radeon r8168 loongson gpu_sched Feb 6 17:13:13 aaa-PC kernel: [ 466.271059] CPU: 3 PID: 9554 Comm: blur_image Tainted: G B 4.19.0-loongson-3-desktop #3036 Feb 6 17:13:13 aaa-PC kernel: [ 466.271061] Hardware name: Haier Kunlun-LS3A4000-LS7A-desktop/Kunlun-LS3A4000-LS7A-desktop, BIOS Kunlun-V4.0.12V4.0 LS3A4000 03/19/2020 Feb 6 17:13:13 aaa-PC kernel: [ 466.271063] Stack : 000000000000007b 000000007400cce0 0000000000000000 0000000000000007 Feb 6 17:13:13 aaa-PC kernel: [ 466.271067] 0000000000000000 0000000000000000 0000000000002a82 ffffffff8202c910 Feb 6 17:13:13 aaa-PC kernel: [ 466.271070] 0000000000000000 0000000000002a82 0000000000000000 ffffffff81e20000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271074] 0000000000000000 ffffffff8021301c ffffffff82040000 6e754b20534f4942 Feb 6 17:13:13 aaa-PC kernel: [ 466.271078] ffff000000000000 0000000000000000 000000007400cce0 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271082] 9800000007155d40 ffffffff81cc5470 0000000000000005 6db6db6db6db0000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271086] 0000000000000003 fffffffffffffffb 0000000000006000 98000002559f4000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271090] 980000024a448000 980000024a44b7f0 9800000007155d50 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271094] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271097] 9800000007155d40 ffffffff802310c4 ffffffff81e70000 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271101] ... Feb 6 17:13:13 aaa-PC kernel: [ 466.271103] Call Trace: Feb 6 17:13:13 aaa-PC kernel: [ 466.271107] [<ffffffff802310c4>] show_stack+0x44/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271110] [<ffffffff819f5158>] dump_stack+0x1d8/0x240 Feb 6 17:13:13 aaa-PC kernel: [ 466.271113] [<ffffffff80491c10>] bad_page+0x210/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271116] [<ffffffff804931c8>] free_pcppages_bulk+0x708/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 46 6.271119] [<ffffffff804980cc>] free_unref_page_list+0x1cc/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271122] [<ffffffff804ad2c8>] release_pages+0x648/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271125] [<ffffffff804f3b48>] tlb_flush_mmu_free+0x88/0x100 Feb 6 17:13:13 aaa-PC kernel: [ 466.271128] [<ffffffff804f8a24>] zap_pte_range+0xa24/0x1480 Feb 6 17:13:13 aaa-PC kernel: [ 466.271132] [<ffffffff804f98b0>] unmap_page_range+0x1f0/0x500 Feb 6 17:13:13 aaa-PC kernel: [ 466.271135] [<ffffffff804fa054>] unmap_vmas+0x154/0x200 Feb 6 17:13:13 aaa-PC kernel: [ 466.271138] [<ffffffff8051190c>] exit_mmap+0x20c/0x380 Feb 6 17:13:13 aaa-PC kernel: [ 466.271142] [<ffffffff802bb9c8>] mmput+0x148/0x300 Feb 6 17:13:13 aaa-PC kernel: [ 466.271145] [<ffffffff802c80d8>] do_exit+0x6d8/0x1900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271148] [<ffffffff802cb288>] do_group_exit+0x88/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271151] [<ffffffff802cb3d8>] sys_exit_group+0x18/0x40 Feb 6 17 :13:13 aaa-PC kernel: [ 466.271155] [<ffffffff8023f954>] syscall_common+0x34/0xa4 songqiang
2021-04-07 8:25 ` your mail Huang Rui
2021-04-07 8:25 ` Huang Rui
2021-04-07 9:25 ` Christian König
2021-04-07 9:25 ` Christian König
2021-04-01 21:16 Bhaumik Bhatt
2021-04-07 6:56 ` your mail Manivannan Sadhasivam
[not found] <20210322213644.333112726@goodmis.org>
2021-03-22 21:40 ` Steven Rostedt
[not found] <20210322212156.440428241@goodmis.org>
2021-03-22 21:36 ` Steven Rostedt
2020-12-02 1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi
2020-12-02 9:47 ` Andy Shevchenko
2020-12-02 10:04 ` Rasmus Villemoes
2020-12-02 11:50 ` Yun Levi
[not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
2020-12-02 17:37 ` Andy Shevchenko
2020-12-02 18:27 ` Yun Levi
2020-12-02 18:51 ` your mail Andy Shevchenko
2020-12-02 18:56 ` Andy Shevchenko
2020-09-03 17:36 Barnett, Andy
2020-09-18 7:56 ` your mail Johan Hovold
2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir
2020-08-06 22:31 ` Konrad Dybcio
2020-08-13 7:04 ` your mail Bjorn Andersson
2020-08-17 17:12 ` Amit Pundir
2020-08-30 18:58 ` Bjorn Andersson
2020-08-05 10:57 Jacopo Mondi
2020-08-09 15:53 ` your mail Laurent Pinchart
2020-08-10 7:28 ` Jacopo Mondi
2020-08-19 0:36 ` Laurent Pinchart
[not found] <CAK9MGy3D5UBf06OY16UW=c+Cybm67x+0kH_OWJkX7ywdQD9CNA@mail.gmail.com>
2020-06-28 6:27 ` G.W. Haywood
2020-06-24 0:38 shejan shuza
2020-06-24 1:31 ` your mail brian m. carlson
2020-06-09 11:38 Gaurav Singh
2020-06-09 11:54 ` your mail Greg KH
[not found] <526351589195104@mail.yandex.com>
2020-05-11 11:35 ` Heikki Krogerus
[not found] ` <20200511113506.GB2062175-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org>
2020-05-11 11:44 ` Andy Shevchenko
2020-05-11 11:44 ` Andy Shevchenko
[not found] ` <CAHp75VcwUcbtZFQExEoJg9sFFVa_ueUT71SiMCVWetgaQg6kDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-11 12:29 ` Hans de Goede
2020-05-11 12:29 ` Hans de Goede
[not found] ` <5ee2b9ef-25e3-c049-3f82-d3d51d392824-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2020-05-11 13:40 ` Andy Shevchenko
2020-05-11 13:40 ` Andy Shevchenko
[not found] ` <CAHp75VdUeBt++mJCvWkHm82XQ+ze1U6OpQ9fv8Hb2d1Nfsz3pw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-05-18 13:35 ` Heikki Krogerus
2020-05-18 13:35 ` Heikki Krogerus
2020-05-06 5:52 Jiaxun Yang
2020-05-07 11:00 ` your mail Thomas Bogendoerfer
2019-11-20 3:49 Han-Wen Nienhuys
2019-11-20 5:30 ` your mail Taylor Blau
2019-11-20 8:05 ` Christian Couder
[not found] <20191026192359.27687-1-frank-w@public-files.de>
2019-10-26 19:30 ` Greg Kroah-Hartman
2019-10-26 19:30 ` Greg Kroah-Hartman
2019-10-26 19:30 ` Greg Kroah-Hartman
2019-07-11 20:11 Robert Morgan
2019-07-11 20:18 ` your mail Kevin Daudt
2019-07-11 20:25 ` Robert Morgan
[not found] <20190626145238.19708-1-bigeasy@linutronix.de>
2019-06-27 21:13 ` Tejun Heo
[not found] <92179e5f-d73e-974c-774e-09c2813434c0@gmail.com>
2019-04-18 9:09 ` Karel Zak
[not found] <20190411060536.22409-1-npiggin@gmail.com>
2019-04-11 10:53 ` Peter Zijlstra
2019-04-12 3:23 ` Nicholas Piggin
[not found] <20190323171738.GA26736@titus.pi.local>
2019-03-26 8:42 ` Dan Carpenter
[not found] <20190319022012.11051-1-thirtythreeforty@gmail.com>
2019-03-20 7:26 ` Greg Kroah-Hartman
2019-03-19 14:41 (unknown) Maxim Levitsky
2019-03-19 15:22 ` your mail Keith Busch
2019-03-19 15:22 ` Keith Busch
2019-03-19 15:22 ` Keith Busch
2019-03-19 23:49 ` Chaitanya Kulkarni
2019-03-19 23:49 ` Chaitanya Kulkarni
2019-03-19 23:49 ` Chaitanya Kulkarni
2019-03-20 16:44 ` Maxim Levitsky
2019-03-20 16:44 ` Maxim Levitsky
2019-03-20 16:44 ` Maxim Levitsky
2019-03-20 16:30 ` Maxim Levitsky
2019-03-20 16:30 ` Maxim Levitsky
2019-03-20 16:30 ` Maxim Levitsky
2019-03-20 17:03 ` Keith Busch
2019-03-20 17:03 ` Keith Busch
2019-03-20 17:03 ` Keith Busch
2019-03-20 17:33 ` Maxim Levitsky
2019-03-20 17:33 ` Maxim Levitsky
2019-03-20 17:33 ` Maxim Levitsky
2019-04-08 10:04 ` Maxim Levitsky
2019-04-08 10:04 ` Maxim Levitsky
2019-03-21 16:13 ` Stefan Hajnoczi
2019-03-21 16:13 ` Stefan Hajnoczi
2019-03-21 16:13 ` Stefan Hajnoczi
2019-03-21 17:07 ` Maxim Levitsky
2019-03-21 17:07 ` Maxim Levitsky
2019-03-21 17:07 ` Maxim Levitsky
2019-03-25 16:46 ` Stefan Hajnoczi
2019-03-25 16:46 ` Stefan Hajnoczi
2019-03-25 16:46 ` Stefan Hajnoczi
[not found] <20190225201635.4648-1-hannes@cmpxchg.org>
2019-02-26 23:49 ` Roman Gushchin
[not found] <20190204213303.131064-1-matthewgarrett@google.com>
2019-02-05 9:27 ` Jarkko Sakkinen
2019-01-25 9:47 Furkan DURUL
2019-01-25 11:27 ` your mail Kevin Daudt
2018-12-13 14:09 Sebastian Andrzej Siewior
2018-12-13 14:33 ` your mail Sasha Levin
2018-12-13 14:39 ` Sasha Levin
2018-12-13 15:13 ` Sebastian Andrzej Siewior
2018-12-13 14:53 ` Peter Zijlstra
2018-12-14 7:11 ` Greg KH
2018-08-27 14:50 Christoph Hellwig
2018-08-31 20:23 ` your mail Paul Burton
2018-08-31 20:23 ` Paul Burton
[not found] <20180724222212.8742-1-tsotsos@gmail.com>
2018-07-25 7:39 ` Greg Kroah-Hartman
[not found] <2018071901551081442221@163.com>
2018-07-18 20:04 ` Johan Hovold
[not found] <201807160555.w6G5t9Dc075492@mse.aten.com.tw>
2018-07-16 10:03 ` Johan Hovold
2018-07-11 15:25 [PATCH V4] xdrstdio_create buffers do not output encoded values on ppc Steve Dickson
2018-07-23 18:43 ` Marc Eshel
2018-07-23 20:33 ` your mail Bruce Fields
2018-06-13 17:00 [PATCH v2] staging: rts5208: add check on NULL before dereference Andy Shevchenko
[not found] ` <20180613173128.32384-1-vasilyev@ispras.ru>
2018-06-19 7:42 ` your mail Dan Carpenter
2018-03-09 15:12 [PATCH 00/14] Enable SD/MMC on JZ4780 SoCs Ezequiel Garcia
2018-03-09 15:12 ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780 Ezequiel Garcia
2018-03-09 17:51 ` [PATCH 08/14] mmc: jz4740: Add support for the JZ4780, Paul Cercueil
2018-03-09 22:31 ` your mail James Hogan
2018-03-09 22:31 ` James Hogan
2018-02-18 8:14 Tomasz Kłoczko
2018-02-18 9:28 ` your mail Tomasz Pala
2018-02-18 9:34 ` Tomasz Pala
2017-12-07 21:32 Paul Marques Mota
2017-12-07 23:34 ` your mail Guenter Roeck
2017-12-07 23:38 ` Paul Marques Mota
2017-12-07 9:26 Alexander Kappner
2017-12-07 10:38 ` your mail Greg Kroah-Hartman
2017-08-18 17:42 Rajneesh Bhardwaj
2017-08-18 17:53 ` your mail Rajneesh Bhardwaj
2017-06-26 5:21 (unknown) Leon Romanovsky
[not found] ` <20170626052117.GX1248-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-06-26 5:38 ` your mail Leon Romanovsky
2017-06-22 9:50 Jessie Hernandez
2017-06-22 12:48 ` your mail Simon Ruderich
2017-06-22 13:35 ` AW: " Patrick Lehmann
2017-06-22 13:47 ` Simon Ruderich
2017-06-22 13:55 ` AW: " Patrick Lehmann
2017-06-22 20:46 ` Simon Ruderich
2017-06-22 21:35 ` Junio C Hamano
2017-06-22 21:58 ` Ævar Arnfjörð Bjarmason
2017-06-22 22:14 ` Junio C Hamano
2017-06-22 23:21 ` Jeff King
2017-06-23 5:23 ` Junio C Hamano
2017-06-23 16:53 ` Jeff King
2017-06-23 18:44 ` Junio C Hamano
2017-06-23 6:58 ` demerphq
2017-06-04 11:59 Yury Norov
2017-06-14 20:16 ` your mail Yury Norov
2017-06-14 20:16 ` Yury Norov
2017-04-10 11:03 [PATCH -v2 0/9] mm: make movable onlining suck less Michal Hocko
2017-04-15 12:17 ` Michal Hocko
2017-04-17 5:47 ` your mail Joonsoo Kim
2017-04-17 5:47 ` Joonsoo Kim
2017-04-17 8:15 ` Michal Hocko
2017-04-17 8:15 ` Michal Hocko
2017-04-20 1:27 ` Joonsoo Kim
2017-04-20 1:27 ` Joonsoo Kim
2017-04-20 7:28 ` Michal Hocko
2017-04-20 7:28 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
2017-04-20 11:56 ` Vlastimil Babka
2017-04-20 11:56 ` Vlastimil Babka
2017-04-20 12:13 ` Michal Hocko
2017-04-20 12:13 ` Michal Hocko
2017-04-21 4:38 ` Joonsoo Kim
2017-04-21 4:38 ` Joonsoo Kim
2017-04-21 7:16 ` Michal Hocko
2017-04-21 7:16 ` Michal Hocko
2017-04-24 1:44 ` Joonsoo Kim
2017-04-24 1:44 ` Joonsoo Kim
2017-04-24 7:53 ` Michal Hocko
2017-04-24 7:53 ` Michal Hocko
2017-04-25 2:50 ` Joonsoo Kim
2017-04-25 2:50 ` Joonsoo Kim
2017-04-26 9:19 ` Michal Hocko
2017-04-26 9:19 ` Michal Hocko
2017-04-27 2:08 ` Joonsoo Kim
2017-04-27 2:08 ` Joonsoo Kim
2017-04-27 15:10 ` Michal Hocko
2017-04-27 15:10 ` Michal Hocko
2016-11-15 20:29 Christoph Lameter
2016-11-16 10:40 ` your mail Peter Zijlstra
2016-11-16 14:25 ` Steven Rostedt
2016-11-16 14:28 ` Peter Zijlstra
2016-09-20 22:21 Andrew Banman
2016-09-20 22:23 ` your mail andrew banman
2016-09-01 2:02 Fennec Fox
2016-09-01 7:44 ` your mail M G Berberich
2016-09-01 11:17 ` Austin S. Hemmelgarn
2016-09-01 16:44 ` Kyle Gates
2016-09-01 17:06 ` Austin S. Hemmelgarn
2016-09-02 1:51 ` Jeff Mahoney
2016-09-01 21:15 ` M G Berberich
2016-04-11 19:04 (unknown), miwilliams
2016-04-11 19:13 ` your mail Jeff King
2015-08-03 6:18 Shraddha Barke
2015-08-03 7:12 ` your mail Sudip Mukherjee
2015-08-03 7:24 ` Dan Carpenter
2015-06-13 1:02 Tom Christensen
2015-06-13 22:39 ` your mail Dave Chinner
2015-06-14 23:27 ` Dave Chinner
2015-04-21 10:18 No subject Ard Biesheuvel
2015-04-21 10:46 ` your mail Dave P Martin
2015-04-21 10:50 ` Ard Biesheuvel
2015-04-21 11:10 ` Dave P Martin
2015-04-21 11:15 ` Ard Biesheuvel
2015-04-21 11:24 ` Russell King - ARM Linux
2015-04-21 12:50 ` Russell King - ARM Linux
2015-04-21 13:10 ` Ard Biesheuvel
2015-04-21 13:21 ` Dave P Martin
2015-04-21 13:28 ` Ard Biesheuvel
2015-04-21 15:51 ` Dave Martin
2015-04-21 14:05 ` Russell King - ARM Linux
2015-04-21 13:18 ` Dave P Martin
2015-04-21 13:55 ` Russell King - ARM Linux
2015-04-21 14:06 ` Ard Biesheuvel
2015-04-21 17:03 ` Dave Martin
[not found] <20150121201024.GA4548@obsidianresearch.com>
[not found] ` <alpine.DEB.2.02.1501211520150.13480@linuxheads99>
2015-01-21 23:57 ` Jason Gunthorpe
2015-01-22 20:50 ` One Thousand Gnomes
2015-01-28 22:09 ` atull
2014-10-28 14:13 No subject Mark Rutland
2014-10-28 14:19 ` your mail Mark Rutland
2014-10-15 8:10 Christoph Lameter
2014-10-27 15:07 ` your mail Tejun Heo
2014-09-01 15:47 sunwxg
2014-09-01 17:01 ` your mail Dan Carpenter
[not found] <1409556896-21523-2-git-send-email-xiaoguang_wang5188@qq.com>
2014-09-01 8:04 ` Dan Carpenter
2014-07-09 1:03 James Ban
2014-07-09 7:56 ` your mail Mark Brown
2014-02-25 11:20 (unknown), srikanth TS
2014-02-25 15:01 ` your mail Will Deacon
2014-02-25 15:01 ` Will Deacon
2014-02-24 15:12 (unknown), srikanth TS
2014-02-24 17:28 ` your mail Will Deacon
2014-02-24 17:28 ` Will Deacon
2014-02-25 11:28 ` Varun Sethi
2014-02-25 11:28 ` Varun Sethi
[not found] ` <42a1041ac2df4a73a94dc4516969e35d-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-02-26 8:23 ` srikanth TS
[not found] ` <CAM0G4zv7nBLRdiXcFjiarXAhsbA+5MkdWHPysjpn=ydky72Piw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-26 12:14 ` Varun Sethi
2014-01-23 9:06 Prabhakar Lad
2014-01-23 19:55 ` your mail Mark Brown
[not found] <1388425244-10017-1-git-send-email-jdb@sitrep3.com>
2014-01-09 18:39 ` Greg KH
2014-01-09 18:49 ` Joe Borġ
2014-01-14 16:40 ` Steven Rostedt
2013-10-19 22:21 (unknown), Antonio Quartulli
2013-10-20 0:15 ` (unknown) David Miller
2013-10-20 7:57 ` your mail Antonio Quartulli
2013-09-03 14:02 Igor Filakhtov
2013-05-17 18:02 (unknown), ASHISH VERMA
2013-05-21 13:13 ` your mail Magnus Bäck
2013-01-23 12:37 (unknown), Nitin Kshirsagar
[not found] ` <C4B5704C6FEB5244B2A1BCC8CF83B86B0A6257C7D0-AQg6BlXVjylhNUoibfp7lHKnxlUjViKd@public.gmane.org>
2013-01-24 23:12 ` your mail Kent Overstreet
[not found] <CACaajQtCTW_PKA25q3-4o4XAV6sgZnyD+Skkw6mhUHpRBEgbjQ@mail.gmail.com>
2012-11-26 18:29 ` Greg KH
2012-11-26 18:29 ` Greg KH
2012-10-18 15:47 walter harms
2012-10-10 15:06 Kent Yoder
2012-10-10 15:12 ` your mail Kent Yoder
2012-10-04 16:50 Andrea Arcangeli
2012-10-04 18:17 ` your mail Christoph Lameter
2012-10-04 18:17 ` Christoph Lameter
2012-08-03 17:43 Tejun Heo
2012-08-08 16:39 ` your mail Tejun Heo
2012-07-03 20:18 (unknown) Elie De Brauwer
[not found] ` <4FF3539B.50103-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-07-03 20:19 ` your mail Simon Paillard
2012-06-21 18:26 (unknown) Paul Walmsley
2012-06-22 8:56 ` your mail Tony Lindgren
2012-06-22 8:56 ` Tony Lindgren
2012-05-06 14:17 (unknown), Bruce Zu
2012-05-06 17:04 ` your mail Marcus Karlsson
[not found] <1330599216.71336.YahooMailNeo@web30703.mail.mud.yahoo.com>
2012-03-01 12:41 ` (unknown) bella tk
2012-03-01 12:58 ` your mail David Sterba
2012-03-01 14:26 ` Chris Mason
2012-02-21 15:39 Yang Honggang
2012-02-21 11:34 ` your mail Hans J. Koch
2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
2012-02-12 1:02 ` Al Viro
2012-02-12 12:40 ` Jiri Slaby
2012-02-12 19:06 ` Al Viro
2012-02-13 9:40 ` Jiri Slaby
2012-02-12 19:11 ` Al Viro
2012-02-13 9:15 ` Jiri Slaby
[not found] <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se>
2012-01-25 13:26 ` Henrik Rydberg
2012-01-25 14:09 ` Maurus Cuelenaere
[not found] <20120110061735.9BD676BA98@mailhub.coreip.homeip.net>
2012-01-10 7:45 ` Dmitry Torokhov
2011-12-02 16:01 No subject Will Deacon
2011-12-02 16:11 ` your mail Will Deacon
2011-11-22 23:42 Tony Breeds
2011-11-22 23:47 ` your mail Tony Breeds
2011-10-20 0:17 (no subject) Mikulas Patocka
2011-10-20 0:57 ` your mail Alasdair G Kergon
2011-10-20 9:52 ` Joe Thornber
2011-09-21 21:54 jim.cromie
2011-09-26 23:23 ` your mail Greg KH
2011-09-20 15:24 (unknown) Ken D'Ambrosio
2011-09-20 15:35 ` your mail Hugo Mills
2011-09-20 15:40 ` Hugo Mills
2011-08-28 14:11 (unknown) Jan Engelhardt
2011-08-31 11:56 ` your mail Jozsef Kadlecsik
2011-08-31 12:10 ` Jan Engelhardt
2011-08-31 12:16 ` Jozsef Kadlecsik
2011-08-31 12:44 ` Jan Engelhardt
2011-08-31 12:49 ` Jozsef Kadlecsik
2011-08-31 13:04 ` Jan Engelhardt
2011-08-31 13:24 ` Jozsef Kadlecsik
2011-05-17 23:33 [PATCH] module: Use binary search in lookup_symbol() Tim Bird
2011-05-18 18:55 ` Alessio Igor Bogani
2011-05-18 19:22 ` your mail Greg KH
2011-05-18 20:35 ` Alessio Igor Bogani
2011-05-16 9:34 Keshava Munegowda
2011-05-16 9:44 ` your mail Felipe Balbi
2011-05-16 10:07 ` Munegowda, Keshava
2011-05-13 19:35 No subject Vadim Bendebury
2011-05-14 3:32 ` your mail Jean-Christophe PLAGNIOL-VILLARD
2011-05-03 11:01 [RFC][PATCH] Re: [BUG] ext4: cannot unfreeze a filesystem due to a deadlock Surbhi Palande
2011-05-03 13:08 ` (unknown), Surbhi Palande
2011-05-03 13:46 ` your mail Jan Kara
2011-05-03 13:56 ` Surbhi Palande
2011-05-03 15:26 ` Surbhi Palande
2011-05-03 15:36 ` Jan Kara
2011-05-03 15:43 ` Surbhi Palande
2011-05-04 19:24 ` Jan Kara
2011-02-16 11:54 (unknown), Hema HK
2011-02-16 11:55 ` your mail Felipe Balbi
2011-02-16 12:07 ` Hema Kalliguddi
2011-02-16 11:53 (unknown), Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
2011-02-16 11:55 ` your mail Felipe Balbi
2011-01-14 1:14 Omar Ramirez Luna
2011-01-14 4:36 ` your mail Greg KH
2011-01-03 16:38 castet.matthieu
2011-01-03 17:03 ` your mail Stanislaw Gruszka
2011-01-04 5:17 ` Tejun Heo
2010-09-18 11:49 (no subject) Raj Kumar
2010-09-18 15:36 ` your mail Alan Stern
2010-09-18 15:56 ` Dominik Brodowski
2010-06-16 16:33 (unknown), Jan Kara
2010-06-16 22:15 ` your mail Dave Chinner
2010-06-22 2:59 ` Wu Fengguang
2010-06-22 2:59 ` Wu Fengguang
2010-06-22 13:54 ` Jan Kara
2010-06-22 13:54 ` Jan Kara
2010-06-22 14:12 ` Wu Fengguang
2010-06-13 6:16 Mike Gilks
2010-06-18 23:52 ` your mail Greg KH
2010-06-07 17:58 No subject Dave Hylands
2010-06-07 22:10 ` your mail Jamie Lokier
2010-06-07 22:44 ` Dave Hylands
2010-05-18 10:38 (unknown), Marek Szyprowski
2010-05-19 2:24 ` your mail Ben Dooks
2010-05-19 2:24 ` Ben Dooks
2010-05-14 21:39 (unknown) Jiaying Zhang
2010-05-14 22:07 ` your mail tytso
2010-04-14 12:54 Alan Cox
2010-04-14 23:16 ` your mail Dmitry Torokhov
2010-04-15 23:41 ` Rafi Rubin
2010-04-16 4:21 ` Dmitry Torokhov
2010-02-15 22:58 (unknown), Serge Hallyn
[not found] ` <1266274696-23018-1-git-send-email-serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-02-16 0:35 ` your mail Matt Helsley
[not found] ` <20100216003531.GL3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2010-02-16 19:04 ` Sukadev Bhattiprolu
[not found] <20100113004939.289333186@suse.com>
2010-01-13 14:57 ` scameron
[not found] <1250258343-14203-1-git-send-email-thierry.reding@avionic-design.de>
2009-10-02 14:53 ` Thierry Reding
2010-01-02 12:06 ` Russell King - ARM Linux
2009-08-10 16:47 Your Mail Brown.K
2009-07-23 5:38 (unknown), Haneef Syed
2009-07-23 5:50 ` your mail Gleb Natapov
2009-07-23 6:09 ` Haneef Syed
2009-07-23 6:14 ` Gleb Natapov
2009-06-17 16:08 (unknown), Koffi Nogbe
2009-06-17 16:14 ` your mail Matthew Wilcox
2009-05-06 23:53 [RFC PATCH 3/3a] ptrace: add _ptrace_may_access() Oleg Nesterov
2009-05-07 0:21 ` Roland McGrath
2009-05-07 6:36 ` Oleg Nesterov
2009-05-07 8:20 ` Ingo Molnar
2009-05-07 8:31 ` Oleg Nesterov
2009-05-07 8:38 ` Ingo Molnar
2009-05-07 8:57 ` Chris Wright
2009-05-07 9:04 ` Ingo Molnar
2009-05-07 9:20 ` Chris Wright
2009-05-07 9:54 ` James Morris
2009-05-07 10:20 ` your mail Ingo Molnar
2009-05-08 3:27 ` Casey Schaufler
2009-04-02 4:16 (unknown), Lelsie Rhorer
2009-04-02 6:56 ` your mail Luca Berra
2009-03-27 23:26 Eric Anholt
2009-03-28 0:02 ` your mail Linus Torvalds
[not found] <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>
2009-03-13 16:54 ` Ralf Nyren
2009-03-11 10:47 Vitaly Mayatskikh
2009-03-11 14:59 ` your mail Linus Torvalds
2009-03-11 17:23 ` Vitaly Mayatskikh
2009-02-13 0:45 Youngwhan Kim
2009-02-13 3:40 ` your mail Johannes Weiner
2009-01-20 3:21 Paul Mundt
2009-01-19 2:54 Gao, Yunpeng
2009-01-19 3:07 ` your mail Matthew Wilcox
2009-01-13 6:10 Steven Rostedt
2009-01-13 13:21 ` your mail Steven Rostedt
2009-01-11 3:41 Jose Luis Marchetti
2009-01-11 6:47 ` your mail Jesper Juhl
2008-08-13 14:54 (unknown), aneesh.kumar
2008-08-13 15:16 ` your mail Aneesh Kumar K.V
2008-07-27 1:11 (unknown), David Boulding
2008-07-28 14:14 ` your mail Eric Leblond
2008-07-28 14:42 ` David Boulding
[not found] ` <5226fb870807280721kaa95f6esc6955cc87da42c18@mail.gmail.com>
2008-07-28 14:43 ` Eric Leblond
2008-07-28 15:33 ` David Boulding
2008-07-29 7:11 ` Eric Leblond
2008-07-29 20:09 ` David Boulding
2008-07-01 22:48 Henrique de Moraes Holschuh
2008-07-01 22:53 ` your mail Henrique de Moraes Holschuh
2008-05-24 20:05 Thomas Gleixner
2008-05-24 21:06 ` Daniel Walker
2008-05-20 12:34 Lukas Hejtmanek
2008-05-20 15:20 ` your mail Alan Stern
2008-01-22 0:00 (no subject) Thiemo Seufer
2008-01-28 17:51 ` your mail Ralf Baechle
2007-12-05 19:00 [PATCH 0/6] builtin-remote Johannes Schindelin
2007-12-05 19:00 ` (unknown) Johannes Schindelin
2007-12-05 19:01 ` your mail Johannes Schindelin
2007-10-17 18:28 nicholas.thompson1
2007-10-17 16:30 nicholas.thompson1
2007-10-17 16:36 ` your mail Jan Engelhardt
2007-10-17 17:50 ` Matti Aarnio
2007-10-13 4:01 (unknown), Michael Witten
2007-10-13 4:07 ` your mail Jeff King
2007-10-09 9:56 (unknown), Frédéric Mantegazza
2007-10-09 10:46 ` your mail Justin Piszcz
2007-09-27 18:03 Gangadhar Kodishala
2007-09-27 20:06 ` your mail Ricard Wanderlof
2007-09-24 20:44 Steven Rostedt
2007-09-24 20:50 ` your mail Steven Rostedt
2007-08-15 13:53 [PATCH 0/24] make atomic_read() behave consistently across all architectures Stefan Richter
2007-08-15 14:35 ` Satyam Sharma
2007-08-15 14:52 ` Herbert Xu
2007-08-15 16:09 ` Stefan Richter
2007-08-15 16:27 ` Paul E. McKenney
2007-08-15 18:31 ` Segher Boessenkool
2007-08-15 18:57 ` Paul E. McKenney
2007-08-15 19:54 ` Satyam Sharma
2007-08-15 20:47 ` Segher Boessenkool
2007-08-16 0:36 ` Satyam Sharma
2007-08-16 0:32 ` your mail Herbert Xu
2007-05-16 13:30 Bob Picco
2007-05-16 16:43 ` your mail Linas Vepstas
2007-05-16 16:43 ` Linas Vepstas
2007-05-16 17:11 ` Olof Johansson
2007-05-16 17:11 ` Olof Johansson
2007-05-16 17:24 ` Bob Picco
2007-05-16 17:24 ` Bob Picco
2007-03-29 21:39 Gerard Braad Jr.
2007-03-29 21:42 ` your mail Jan Engelhardt
2007-03-29 21:46 ` David Miller
2007-03-29 21:48 ` Gerard Braad
2007-02-05 15:41 logic
2007-02-05 12:36 ` your mail Joerg Roedel
2007-02-05 12:36 ` Joerg Roedel
2007-02-05 14:01 ` Pekka Enberg
2007-02-06 9:41 ` Joerg Roedel
2006-11-21 22:24 (unknown) Johannes Schindelin
2006-11-22 20:16 ` your mail Davide Libenzi
[not found] <D3E576A1A7C7134694A0DDA7C2CA4B884C3985@hyd-mail2.bbnet.ad>
2006-10-23 9:02 ` Chris Wedgwood
2006-10-20 14:24 (unknown) andyparkins
2006-10-20 14:42 ` your mail Johannes Schindelin
[not found] <C8DBC54F2A9BAD4FA7F445CC7ADD963B0232474F@sslmexchange1.paymentech.us>
2006-09-26 19:56 ` Linus Torvalds
2006-05-21 23:53 (unknown) J. Bruce Fields
2006-05-21 23:55 ` your mail J. Bruce Fields
2006-05-22 0:16 ` Junio C Hamano
2006-05-22 1:33 ` J. Bruce Fields
2006-01-11 14:47 (unknown) bhess
2006-01-11 17:44 ` your mail Ross Vandegrift
2005-11-25 22:06 root
2005-11-26 0:11 ` your mail Hugh Dickins
2005-10-05 6:10 (unknown), Willem Swart
2005-10-06 10:52 ` your mail Elfyn McBratney
[not found] <200508301321.j7UDLV9k002943@toshiba.co.jp>
2005-08-30 14:09 ` Harald Welte
2005-06-16 23:08 trmcneal
2005-06-16 23:32 ` your mail Chris Wedgwood
2005-06-17 1:46 ` Tom McNeal
2005-04-28 19:15 Bryan Althouse
2005-04-29 11:02 ` your mail Ralf Baechle
2005-02-03 0:17 Aleksey Gorelov
2005-02-03 1:12 ` your mail Matthew Dharm
2005-02-03 16:03 ` Alan Stern
2004-11-16 13:48 (no subject) Artem B. Bityuckiy
2004-11-16 13:55 ` David Woodhouse
2004-11-16 14:21 ` your mail Artem B. Bityuckiy
2004-11-16 14:29 ` David Woodhouse
2004-11-16 14:54 ` Artem B. Bityuckiy
2004-11-16 15:03 ` David Woodhouse
2004-11-16 15:09 ` Artem B. Bityuckiy
2004-09-19 12:29 plt
2004-09-19 18:22 ` your mail Jesper Juhl
2004-08-24 6:05 (unknown) Francisco M. Marzoa Alonso
2004-08-24 9:39 ` your mail Jan-Benedict Glaw
2004-08-16 15:42 Jon Smirl
2004-08-16 23:55 ` Dave Airlie
2004-08-15 12:19 Dave Airlie
2004-08-15 12:34 ` your mail Christoph Hellwig
2004-08-15 23:40 ` Dave Airlie
2004-08-16 9:17 ` Christoph Hellwig
2004-08-16 9:30 ` Dave Airlie
2004-08-16 9:50 ` Christoph Hellwig
2004-08-16 10:29 ` Dave Airlie
2004-08-16 10:38 ` Christoph Hellwig
2004-08-16 11:02 ` Dave Airlie
2004-08-16 11:08 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
2004-08-16 11:47 ` Dave Airlie
2004-08-16 11:12 ` Alan Cox
2004-08-16 12:20 ` Christoph Hellwig
2004-08-16 12:24 ` Dave Airlie
2004-08-16 12:37 ` Christoph Hellwig
2004-08-16 23:33 ` Dave Airlie
2004-05-24 23:15 Laughlin, Joseph V
2004-05-24 23:04 Laughlin, Joseph V
2004-05-24 23:13 ` Bernd Petrovitsch
2004-05-24 23:21 ` Chris Wright
2004-05-24 22:20 Laughlin, Joseph V
2004-05-24 22:30 ` your mail Herbert Poetzl
2004-05-24 22:34 ` Marc-Christian Petersen
2004-05-24 22:33 ` Chris Wright
2004-04-29 3:03 whitehorse
2004-04-29 3:21 ` your mail Jon
2004-04-12 13:23 (no subject) Denis Vlasenko
2004-04-13 13:46 ` your mail James Morris
2004-04-09 17:54 Martin Knoblauch
2004-04-09 18:12 ` your mail Joel Jaeggli
2004-03-15 22:49 Kevin Leung
2004-03-15 23:26 ` your mail Richard B. Johnson
2004-02-24 13:58 Jim Deas
2004-02-24 14:44 ` your mail Richard B. Johnson
2004-02-19 13:52 (unknown) Joilnen Leite
2004-02-19 14:12 ` your mail Richard B. Johnson
2004-02-13 19:23 Bloch, Jack
2004-02-13 19:14 Bloch, Jack
2004-02-13 16:45 Bloch, Jack
2004-02-13 18:11 ` your mail Maciej Zenczykowski
2004-02-10 23:36 Bloch, Jack
2004-02-11 1:09 ` your mail Maciej Zenczykowski
2003-12-26 20:20 caszonyi
2003-12-26 22:27 ` your mail Linus Torvalds
2004-01-05 10:59 ` Gerd Knorr
2003-12-23 14:16 dublinux
2003-12-23 14:54 ` your mail Matti Aarnio
2003-12-23 17:36 ` Norberto Bensa
[not found] <20031210120336.GU8039@holomorphy.com>
2003-12-10 13:17 ` Stephan von Krawczynski
2003-12-03 16:19 Bloch, Jack
2003-12-03 15:08 Bloch, Jack
2003-12-03 15:43 ` your mail Richard B. Johnson
2003-12-03 16:03 ` Linus Torvalds
[not found] <13724513568.20031119014829@internetplustravel.ru>
2003-12-03 12:02 ` Harald Welte
2003-09-30 8:17 John Bradford
2003-09-30 13:31 ` your mail Dave Jones
2003-09-30 14:06 ` Jamie Lokier
2003-09-30 14:50 ` Dave Jones
2003-09-30 15:30 ` Jamie Lokier
2003-09-30 16:34 ` Adrian Bunk
2003-09-30 14:10 ` John Bradford
2003-09-30 14:58 ` Jamie Lokier
2003-09-30 15:11 ` Dave Jones
2003-09-18 18:35 (no subject) Robert Olsson
2003-09-18 19:38 ` your mail Jeff Garzik
[not found] <Law11-F24DVK3aXvlcq000025d9@hotmail.com>
2003-09-09 16:26 ` Jörn Engel
2003-08-28 2:25 warudkar
2003-08-27 16:02 ` your mail William Lee Irwin III
2003-08-25 16:45 Marcelo Tosatti
2003-08-25 16:59 ` Herbert Pötzl
2003-08-25 13:53 Marcelo Tosatti
2003-08-25 14:30 ` your mail Herbert Pötzl
2003-08-18 6:21 "Andrey Borzenkov"
2003-08-18 20:42 ` your mail Greg KH
2003-08-14 21:57 kartikey bhatt
2003-08-15 3:31 ` your mail James Morris
[not found] <200308031136.17768.lx@lxhp.in-berlin.de>
2003-08-03 18:30 ` Linus Torvalds
2003-07-04 18:10 (unknown) Darryl Perry
2003-07-04 18:21 ` your mail Ged Haywood
2003-07-05 14:48 ` Jim Hartley
2003-07-05 14:53 ` Ged Haywood
[not found] ` <1057435822.2023.49.camel@tamriel.terranforge.com>
2003-07-06 4:06 ` Jim Hartley
2003-07-06 11:20 ` Jochen Reinwand
2003-07-06 11:56 ` Ged Haywood
2003-07-06 16:26 ` Jochen Reinwand
2003-07-06 19:03 ` Eemeli Kantola
2003-07-06 23:10 ` Jochen Reinwand
2003-05-14 18:41 dirf
2003-05-16 10:00 ` your mail Maciej Soltysiak
[not found] <053C05D4.4D025D2E.0005F166@netscape.net>
2003-05-08 9:06 ` Gerd Knorr
2003-04-30 21:39 Mauricio Oliveira Carneiro
2003-05-01 0:05 ` your mail Greg KH
2003-04-25 17:35 Bloch, Jack
2003-04-25 19:43 ` your mail Francois Romieu
2003-04-18 0:08 Dennis Castleman
2003-04-17 17:53 Dennis Castleman
2003-04-17 18:17 ` your mail Jun Sun
2003-04-17 20:15 ` Greg Lindahl
2003-04-18 0:03 ` Ralf Baechle
2003-04-05 0:38 Ed Vance
2003-04-05 4:51 ` Keith Owens
2003-04-04 22:10 Ed Vance
2003-04-04 23:19 ` William Scott Lockwood III
2003-04-04 23:21 ` Keith Owens
2003-04-03 16:22 Richard B. Johnson
2003-04-03 19:22 ` David S. Miller
2003-04-03 20:02 ` your mail Richard B. Johnson
2003-04-03 19:24 ` Alan Cox
2003-04-03 20:00 ` David S. Miller
2003-04-03 20:21 ` Richard B. Johnson
2003-04-03 20:15 ` David S. Miller
2003-04-04 0:31 ` William Scott Lockwood III
2003-04-04 0:40 ` David S. Miller
2003-04-04 0:47 ` William Scott Lockwood III
2003-04-04 12:57 ` Richard B. Johnson
2003-04-04 15:28 ` William Scott Lockwood III
2003-04-04 16:04 ` Richard B. Johnson
2003-04-04 16:04 ` Christoph Hellwig
2003-04-04 16:10 ` Jens Axboe
2003-04-04 20:37 ` Matti Aarnio
2003-04-03 20:40 ` Trever L. Adams
2003-03-29 6:54 Avinash S.
2003-03-29 7:25 ` your mail Thiemo Seufer
2003-01-31 18:46 saurabh khanna
2003-02-03 12:53 ` your mail Alexander Kellett
2003-01-24 5:54 Anoop J.
2003-01-24 6:28 ` David Lang
2003-01-24 6:28 ` David Lang
2003-01-24 8:51 ` Anoop J.
2003-01-24 8:51 ` Anoop J.
2003-01-24 8:48 ` David Lang
2003-01-24 8:48 ` David Lang
2003-01-24 9:49 ` Anoop J.
2003-01-24 9:49 ` Anoop J.
2003-01-24 19:14 ` David Lang
2003-01-24 19:14 ` David Lang
2003-01-24 19:40 ` Maciej W. Rozycki
2003-01-24 19:40 ` Maciej W. Rozycki
2003-01-24 5:08 Anoop J.
2003-01-24 5:11 ` your mail David Lang
2003-01-24 5:11 ` David Lang
2003-01-24 6:06 ` John Alvord
2003-01-24 6:06 ` John Alvord
2003-01-25 2:29 ` Jason Papadopoulos
2003-01-25 2:29 ` Jason Papadopoulos
2003-01-25 2:26 ` Larry McVoy
2003-01-25 2:26 ` Larry McVoy
2003-01-25 17:47 ` Eric W. Biederman
2003-01-25 17:47 ` Eric W. Biederman
2003-01-25 23:10 ` Larry McVoy
2003-01-25 23:10 ` Larry McVoy
2003-01-26 8:12 ` David S. Miller
2003-01-26 8:12 ` David S. Miller
2003-01-16 23:54 (unknown) devnull
2003-01-17 0:35 ` your mail William Lee Irwin III
2003-01-17 6:08 ` Bruce
2002-11-11 19:22 David Mosberger
2002-11-12 1:39 ` your mail Rik van Riel
2002-10-31 18:13 Bloch, Jack
2002-10-31 15:39 Bloch, Jack
2002-10-31 18:00 ` your mail Tom Bradley
2002-10-30 12:45 Roberto Fichera
2002-10-30 14:04 ` your mail Richard B. Johnson
2002-10-30 1:26 (unknown) Michael Robinton
2002-10-30 9:59 ` your mail Massimiliano Masserelli
2002-10-26 19:48 Zajerko-McKee, Nick
2002-10-26 20:08 ` your mail Daniel Jacobowitz
2002-10-26 20:32 ` Greg Lindahl
2002-10-17 7:41 Rusty Russell
2002-10-17 14:56 ` your mail Kai Germaschewski
2002-10-18 2:47 ` Rusty Russell
2002-10-18 21:50 ` Kai Germaschewski
2002-10-14 6:28 Maros RAJNOCH /HiaeR Silvanna/
2002-10-14 12:28 ` your mail Dave Jones
2002-10-09 16:31 (unknown) Joshua Hudson
2002-10-09 18:04 ` your mail Konstantin Boldyshev
2002-10-02 19:58 Mark Peloquin
2002-10-02 20:19 ` your mail jbradford
2002-10-02 12:41 s.stoklossa
2002-10-02 12:51 ` your mail Sam Ravnborg
2002-09-21 5:32 Greg KH
2002-09-23 18:35 ` your mail Patrick Mochel
2002-09-14 12:39 Paolo Ciarrocchi
2002-09-14 17:05 ` your mail Rik van Riel
[not found] <200208312335.g7VNZmk37659@sullivan.realtime.net>
2002-09-01 9:53 ` Krzysiek Taraszka
2002-08-30 18:43 Bloch, Jack
2002-08-30 18:55 ` your mail Matthew Dharm
2002-08-30 19:22 ` Andreas Dilger
2002-08-31 0:12 ` David Woodhouse
2002-08-27 18:22 Steffen Persvold
2002-08-27 19:27 ` your mail Willy Tarreau
2002-08-27 16:55 Alex Pavloff
2002-08-27 1:48 (unknown) Alex Pavloff
2002-08-27 9:59 ` your mail Gerald Emig
2002-08-23 14:45 Mike Dresser
2002-08-23 15:12 ` your mail Bill Unruh
2002-08-23 15:26 ` Mike Dresser
2002-08-23 16:12 ` Bill Unruh
2002-08-23 20:33 ` Mike Dresser
2002-08-25 2:05 ` Mike Dresser
2002-08-19 21:29 Bloch, Jack
2002-08-20 6:47 ` your mail Philipp Matthias Hahn
2002-08-16 7:51 Misha Alex
2002-08-16 9:52 ` your mail Willy Tarreau
2002-08-08 11:28 Samarth Sharma
2002-08-08 13:01 ` your mail Wayne Salamon
2002-07-24 13:37 Richard Mayo
2002-07-24 14:22 ` your mail Stephen Smalley
2002-07-20 19:20 (no subject) Fernando Pablo Lopez-Lezcano
2002-07-21 8:28 ` your mail Jaroslav Kysela
2002-07-06 15:59 Hacksaw
2002-07-07 19:32 ` your mail Min Li
2002-07-05 8:47 Christian Berger
2002-07-05 13:34 ` your mail Gerhard Mack
[not found] <000d01c22361$62c9d6f0$0100a8c0@digital>
2002-07-04 20:45 ` Stephen Tweedie
2002-06-24 5:49 pah
2002-06-24 7:34 ` your mail Zwane Mwaikambo
2002-05-16 12:40 Sanket Rathi
2002-05-16 13:38 ` your mail Alan Cox
2002-05-16 15:54 ` Sanket Rathi
2002-05-16 18:05 ` Alan Cox
2002-05-20 18:07 ` David Mosberger
2002-05-03 14:19 Keith Owens
2002-05-03 14:37 ` your mail tomas szepe
2002-05-03 15:07 ` tomas szepe
2002-05-03 15:29 ` Keith Owens
2002-05-03 15:45 ` tomas szepe
2002-04-24 18:29 Debian User
2002-04-24 20:19 ` your mail Stephen Smalley
2002-04-24 7:55 Huo Zhigang
2002-04-24 7:51 ` your mail Zwane Mwaikambo
2002-04-24 8:27 ` Alan Cox
2002-04-21 21:16 Ivan G.
2002-04-21 23:02 ` your mail Jeff Garzik
2002-04-21 14:54 raciel
2002-04-21 19:12 ` your mail William Lee Irwin III
2002-04-19 19:32 (unknown), raciel
2002-04-19 23:33 ` your mail James Morris
[not found] <ADEEIKPBIEHIINPOFGAOIECBCBAA.gvanuxem@club-internet.fr>
2002-03-15 15:31 ` Stephen Smalley
2002-03-13 19:21 Romain Liévin
2002-03-13 19:43 ` your mail Alan Cox
2002-03-13 20:28 ` Romain Liévin
2002-03-13 20:49 ` Richard B. Johnson
2002-03-13 22:27 ` Alan Cox
2002-03-13 22:35 ` Alan Cox
2002-03-14 7:08 ` Zwane Mwaikambo
2002-03-10 9:39 Samarth Sharma
2002-03-11 14:07 ` your mail Stephen Smalley
2002-02-28 13:58 shura
2002-03-01 15:30 ` your mail Jan-Marek Glogowski
2002-02-27 19:02 Metrix
2002-02-27 19:33 ` your mail Stephen Smalley
2002-02-27 11:31 Metrix
2002-02-27 13:36 ` your mail Stephen Smalley
2002-02-25 1:41 Rusty Russell
2002-02-25 1:58 ` your mail Alexander Viro
2002-02-25 2:14 ` Rusty Russell
2002-02-25 3:18 ` Davide Libenzi
2002-02-25 4:02 ` Alexander Viro
2002-02-26 5:50 ` Rusty Russell
2002-02-25 13:16 ` Alan Cox
2002-01-30 18:21 Nickolaos Fotopoulos
2002-01-30 18:57 ` your mail Matti Aarnio
2002-01-31 1:50 ` Drew P. Vogel
2002-01-09 17:49 Michael Zhu
2002-01-09 18:17 ` your mail Jens Axboe
2002-01-02 14:20 mehul radheshyam choube
2002-01-03 16:40 ` your mail Rik van Riel
2001-12-17 16:07 Sebastian Dröge
2001-12-17 16:22 ` your mail Dave Jones
2001-12-17 16:52 ` Sebastian Dröge
2001-12-17 16:55 ` Arnaldo Carvalho de Melo
2001-12-17 17:23 ` Sebastian Dröge
2001-12-17 17:25 ` Dave Jones
2001-12-17 18:42 ` Sebastian Dröge
2001-12-17 18:43 ` Dave Jones
[not found] <20011214041151.91557.qmail@web14904.mail.yahoo.com>
2001-12-14 16:46 ` Gérard Roudier
2001-12-14 20:09 ` Jens Axboe
2001-12-14 18:05 ` Gérard Roudier
2001-12-14 22:26 ` Peter Bornemann
2001-12-14 20:16 ` Gérard Roudier
2001-12-15 0:54 ` Peter Bornemann
2001-12-15 6:57 ` Gérard Roudier
2001-12-18 0:34 ` Kirk Alexander
2001-12-14 20:34 ` Jens Axboe
2001-12-15 0:56 ` Stephan von Krawczynski
2001-12-15 6:59 ` Gérard Roudier
2001-12-07 4:17 Keith Owens
2001-12-07 5:10 ` your mail Linus Torvalds
2001-12-27 18:09 ` Andre Hedrick
2001-12-27 18:55 ` Linus Torvalds
2001-12-27 19:41 ` Andrew Morton
2001-12-28 22:14 ` Martin Dalecki
2001-10-15 6:25 Dinesh Gandhewar
2001-10-15 6:31 ` your mail Tim Hockin
2001-10-03 14:28 Marian Kafadarov
2001-10-03 15:52 ` your mail Martin Schulze
2001-10-02 15:29 Dinesh Gandhewar
2001-10-02 15:30 ` your mail Alan Cox
2001-10-02 15:49 ` Richard B. Johnson
2001-10-02 15:52 ` Michael H. Warfield
2001-08-04 11:10 Mahmoud Taghizadeh
2001-08-04 13:18 ` your mail Francois Romieu
2001-07-24 0:38 新 月
2001-07-24 12:47 ` your mail Richard B. Johnson
2001-06-13 1:55 Colonel
2001-06-13 9:32 ` your mail Luigi Genoni
2001-06-18 13:55 ` Jan Hudec
2001-06-08 1:36 jnn
2001-06-08 13:16 ` your mail Ralf Baechle
2001-05-31 16:53 Ramil.Santamaria
2001-05-31 20:37 ` your mail Andrzej Krzysztofowicz
2001-05-31 23:04 ` H. Peter Anvin
2001-05-21 19:43 Thomas Palm
2001-05-21 20:12 ` your mail Lorenzo Marcantonio
2001-05-22 10:06 ` Thomas Palm
2001-05-16 15:05 siva prasad
2001-05-17 0:11 ` your mail Erik Mouw
2001-05-08 19:48 Richard B. Johnson
2001-05-08 20:06 ` your mail Jens Axboe
2001-05-08 20:15 ` Richard B. Johnson
2001-05-08 20:16 ` Jens Axboe
2001-05-09 13:59 ` Richard B. Johnson
2001-05-08 20:46 ` Alan Cox
2001-05-08 21:05 ` Richard B. Johnson
2001-05-07 11:38 Chandrashekar Nagaraj
2001-05-07 12:09 ` your mail Erik Mouw
2001-05-02 22:34 Duc Vianney
2001-05-03 0:10 ` your mail Linus Torvalds
2001-04-26 19:37 Alexandru Barloiu Nicolae
2001-04-26 19:51 ` your mail Erik Mouw
2001-04-26 19:54 ` Mohammad A. Haque
2001-04-26 19:59 ` Joel Jaeggli
[not found] <5.0.0.25.0.20010404172906.00a4bce8@vmspop.isc.rit.edu>
2001-04-04 21:37 ` Matthew Fredrickson
2001-04-05 5:08 ` Ralf Baechle
2001-04-02 19:20 Jakob Kemi
2001-04-09 13:23 ` your mail Tim Waugh
2001-03-24 18:51 Hubertus Franke
2001-03-24 4:55 gawain.lynch
2001-03-24 0:04 dhar
2001-03-24 1:09 ` your mail Tim Wright
2001-03-23 23:02 Hubertus Franke
2001-03-24 1:53 ` your mail Chris Crowther
2001-03-24 7:26 ` frenzy@frenzy.org
2001-03-26 14:01 ` Stephen Smalley
2001-03-26 13:57 ` Stephen Smalley
2001-03-11 17:06 Martin Bruchanov
2001-03-12 5:03 ` your mail Greg KH
2001-03-14 17:46 ` Robert Read
2001-03-06 23:55 Ying Chen
2001-03-07 0:40 ` your mail Don Dugger
2001-02-15 0:27 Deepa Suresh
2001-02-15 11:03 ` your mail Geert Uytterhoeven
2001-01-19 13:37 Robert Kaiser
2001-01-19 14:37 ` your mail Steve Hill
2001-01-10 18:24 Thiago Rondon
2001-01-11 4:08 ` your mail David Hinds
2001-01-04 1:36 John Van Horne
2001-01-04 15:36 ` your mail Ralf Baechle
2001-01-04 16:22 ` Maciej W. Rozycki
2001-01-04 16:40 ` Joe deBlaquiere
2001-01-04 17:13 ` Ralf Baechle
2001-01-04 17:46 ` Joe deBlaquiere
2001-01-04 18:12 ` Maciej W. Rozycki
2001-01-04 17:18 ` Maciej W. Rozycki
2000-12-11 14:01 Heiko.Carstens
2000-12-11 15:14 ` your mail Alan Cox
2000-09-04 12:01 Sahil
2000-09-04 15:35 ` your mail Rik van Riel
[not found] <Pine.GSO.4.10.10007211305380.4421-100000@ux5.cso.uiuc.edu>
2000-07-22 11:56 ` Matthew Wilcox
[not found] <001e01bfed04$b27494a0$29e58aa4@crusman>
2000-07-14 10:00 ` Gabriel Paubert
2000-03-28 8:19 pnilesh
2000-03-28 13:26 ` Stephen C. Tweedie
1999-07-08 20:04 David Woodhouse
1999-07-08 22:53 ` your mail Jason Gunthorpe
1999-07-09 7:09 ` D. Jeff Dionne / VE3DJF
1999-07-09 15:27 ` Jason Gunthorpe
1999-05-01 2:35 Bill Nottingham
1999-02-13 17:50 Benjamin Herrenschmidt
1999-02-15 9:58 ` your mail Gabriel Paubert
1999-02-15 11:23 ` Benjamin Herrenschmidt
1999-02-15 14:18 ` Gabriel Paubert
1999-02-15 17:42 ` David Edelsohn
1998-09-25 17:26 rtlynch
1998-02-25 22:15 Rik van Riel
1998-02-25 22:48 ` your mail Linus Torvalds
1998-02-25 23:26 ` Rik van Riel
1997-08-09 17:16 Vincent Renardias
1997-08-09 17:41 ` your mail Ralf Baechle
1997-08-09 17:41 ` Ralf Baechle
1997-08-09 19:40 ` Vincent Renardias
1997-08-09 19:42 ` Ralf Baechle
1997-08-09 19:42 ` Ralf Baechle
1997-08-09 21:05 ` Vincent Renardias
1997-08-09 21:11 ` Ralf Baechle
1997-08-09 21:11 ` Ralf Baechle
1997-08-10 2:57 ` Vincent Renardias
1997-08-09 22:53 ` Mike Shaver
1997-08-09 22:53 ` Mike Shaver
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.