Re: [BUG] 2.6.20 Oopses in xfrm_audit_log
ail to let you know that i got the oops again this morning with a 2.6.20 patched with the above fix. I'm going to rebuild a vanilla kernel patched with the patched sent by David Miller in follow up to your previous conversation. Here's the dump: BUG: unable to handle kernel NULL pointer dereference at virtual address 0188 printing eip: c02fb85c *pde = Oops: [#1] PREEMPT Modules linked in: stir4200 irda crc_ccitt ppdev vmnet(P) vmmon(P) loop usblp nls_iso8859_1 nls_cp437 vfat fat xfrm4_mode_tunnel deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher xcbc sha256 sha1 crypto_null xfrm4_tunnel tunnel4 ipcomp esp4 ah4 af_key autofs4 asb100 hwmon_vid hidp rfcomm l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_LOG xt_limit xt_mark xt_state xt_tcpudp iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_MARK iptable_mangle ip_tables x_tables binfmt_misc ipv6 sd_mod sg hfsplus video button ac lp parport_pc parport floppy nvram usb_storage scsi_mod libusual usbhid hid ehci_hcd snd_via82xx snd_ac97_codec uhci_hcd ac97_bus ohci1394 snd_seq_dummy ieee1394 snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd shpchp i2c_viapro b44 soundcore pcspkr i2c_core eepro100 mii via_agp agpgart usbcore dm_mod CPU:0 EIP:0060:[]Tainted: P M VLI EFLAGS: 00010246 (2.6.20 #1) EIP is at xfrm_audit_log+0x4cc/0x580 eax: c4f3a86b ebx: c039d160 ecx: edx: 0023 esi: edi: 0031 ebp: esp: deb71a18 ds: 007b es: 007b ss: 0068 Process pluto (pid: 3847, ti=deb7 task=e1b82050 task.ti=deb7) Stack: c17d2e60 c0354bf1 ecce48e0 0003 c03ac59c e18b2400 0001 0003 f8ce1450 0001 0286 deb71a6c c011506b 0286 efdde780 0246 c17d2e60 efdde780 f8cdac67 Call Trace: [] __wake_up+0x4b/0x80 [] pfkey_broadcast+0x137/0x1b0 [af_key] [] pfkey_send_policy_notify+0xef/0x1a0 [af_key] [] local_bh_enable+0x2e/0xa0 [] xfrm_get_policy+0x2b7/0x2f0 [] xfrm_get_policy+0x0/0x2f0 [] xfrm_user_rcv_msg+0x102/0x1b0 [] xfrm_user_rcv_msg+0x0/0x1b0 [] netlink_run_queue+0x82/0x120 [] xfrm_netlink_rcv+0x28/0x40 [] netlink_data_ready+0x12/0x50 [] netlink_sendskb+0x21/0x40 [] netlink_sendmsg+0x230/0x310 [] sock_aio_write+0x11d/0x130 [] avc_has_perm+0x5a/0x70 [] do_sync_write+0xd5/0x120 [] autoremove_wake_function+0x0/0x50 [] vfs_write+0x177/0x180 [] sys_write+0x41/0x70 [] syscall_call+0x7/0xb === Code: 8b 44 24 70 c1 e2 08 c1 e8 08 09 c2 0f b7 c2 89 44 24 08 8b 44 24 48 89 04 24 e8 10 eb e3 ff e9 bc fc ff ff 8b 8c 24 c0 00 00 00 <8b> 91 88 01 00 00 0f b7 99 82 00 00 00 85 d2 0f 85 64 fc ff ff EIP: [] xfrm_audit_log+0x4cc/0x580 SS:ESP 0068:deb71a18 -- Charles-Edouard Ruault GPG key Id E4D2B80C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.20 Oopses in xfrm_audit_log
to let you know that since i've applied you patch, everything is running smoothly for me. Thanks again. -- Charles-Edouard Ruault GPG key Id E4D2B80C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.20 Oopses in xfrm_audit_log
e);
> security_xfrm_policy_free(&tmp);
> }
> - if (delete)
> - xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
> -AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL);
> -
> if (xp == NULL)
> return -ENOENT;
>
> @@ -1289,6 +1285,10 @@ static int xfrm_get_policy(struct sk_buf
> } else {
> if ((err = security_xfrm_policy_delete(xp)) != 0)
> goto out;
> +
> + xfrm_audit_log(NETLINK_CB(skb).loginuid, NETLINK_CB(skb).sid,
> +AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL);
> +
> c.data.byid = p->index;
> c.event = nlh->nlmsg_type;
> c.seq = nlh->nlmsg_seq;
>
Thanks for the quick reply & for the patch.
I'm recompiling as i write this email. I'll let you know if i experience
the problem again !
Regards.
--
Charles-Edouard Ruault
PGP Key ID E4D2B80C
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.20 Oopses in xfrm_audit_log
Hi All, i upgraded to vanilla kernel 2.6.20 and while i was using strongswan 2.8.2 to setup an IPSEC VPN i got the following kernel Ooops. I had successfully established the same tunnel a few times, but key renegotiation caused a problem ( both ends did not renegotiate at the same time so the tunnel was frozen ), i decided to kill the tunnel and start a new one ( using ipsec auto --down tunnel & ipsec auto --up tunnel ), while i was doing so, i got the oops. BUG: unable to handle kernel NULL pointer dereference at virtual address 0188 printing eip: c02fb85c *pde = Oops: [#1] PREEMPT Modules linked in: xfrm4_mode_tunnel usblp deflate zlib_deflate twofish twofish_common serpent blowfish des cbc ecb blkcipher xcbc sha256 sha1 crypto_null xfrm4_tunnel tunnel4 ipcomp esp4 ah4 af_key autofs4 asb100 hwmon_vid hidp rfcomm l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_LOG xt_limit xt_mark xt_state xt_tcpudp iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_MARK iptable_mangle ip_tables x_tables binfmt_misc sd_mod ipv6 sg hfsplus video button ac lp parport_pc parport floppy nvram usb_storage scsi_mod libusual usbhid hid ehci_hcd snd_via82xx snd_ac97_codec ac97_bus ohci1394 snd_seq_dummy uhci_hcd ieee1394 snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_agp agpgart i2c_viapro soundcore eepro100 i2c_core b44 pcspkr mii shpchp usbcore dm_mod CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.20 #1) EIP is at xfrm_audit_log+0x4cc/0x580 eax: ecb71061 ebx: c039d160 ecx: edx: 0021 esi: 01f4 edi: 0255 ebp: esp: e8cd5a18 ds: 007b es: 007b ss: 0068 Process pluto (pid: 27486, ti=e8cd4000 task=d3557070 task.ti=e8cd4000) Stack: c17d2ea0 c0354bf1 e183f9c0 0003 c03ac59c e1399800 0001 0003 f8d0a450 0001 0286 e8cd5a6c c011506b 0286 f73cb8c0 0246 c17d2ea0 f73cb8c0 f8d03c67 Call Trace: [] __wake_up+0x4b/0x80 [] pfkey_broadcast+0x137/0x1b0 [af_key] [] pfkey_send_policy_notify+0xef/0x1a0 [af_key] [] local_bh_enable+0x2e/0xa0 [] xfrm_get_policy+0x2b7/0x2f0 [] xfrm_get_policy+0x0/0x2f0 [] xfrm_user_rcv_msg+0x102/0x1b0 [] xfrm_user_rcv_msg+0x0/0x1b0 [] netlink_run_queue+0x82/0x120 [] xfrm_netlink_rcv+0x28/0x40 [] netlink_data_ready+0x12/0x50 [] netlink_sendskb+0x21/0x40 [] netlink_sendmsg+0x230/0x310 [] sock_aio_write+0x11d/0x130 [] avc_has_perm+0x5a/0x70 [] do_sync_write+0xd5/0x120 [] autoremove_wake_function+0x0/0x50 [] vfs_write+0x177/0x180 [] sys_write+0x41/0x70 [] syscall_call+0x7/0xb === Code: 8b 44 24 70 c1 e2 08 c1 e8 08 09 c2 0f b7 c2 89 44 24 08 8b 44 24 48 89 04 24 e8 10 eb e3 ff e9 bc fc ff ff 8b 8c 24 c0 00 00 00 <8b> 91 88 01 00 00 0f b7 99 82 00 00 00 85 d2 0f 85 64 fc ff ff EIP: [] xfrm_audit_log+0x4cc/0x580 SS:ESP 0068:e8cd5a18 I'm running a vanilla 2.6.20 kernel on a Fedora Core 5 box on an athlon processor: cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2400+ stepping: 1 cpu MHz : 2000.256 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 ts bogomips: 4003.78 clflush size: 32 uname -a Linux machine 2.6.20 #1 PREEMPT Sat Feb 10 13:48:56 CET 2007 i686 athlon i386 GNU/Linux Please CC me in follow ups since i do not subscribe to the list. Thanks -- Charles-Edouard Ruault GPG key Id E4D2B80C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Reserve only needed regions for PC timers on i386 and x86_64
Alan Cox wrote:
On Llu, 2005-02-07 at 09:29, Charles-Edouard Ruault wrote:
- Why is the generic timer using this address ? isn't it reserving a too
wide portion of IO ports ? Should it be modified for this board ?
It just reserved the entire chip space since way back when.
- If there's a good reason for the timer to request this address, is
there a clean way to share it with the timer ?
Submit a small patch to Linus/Andrew to make the generic code only
reserve the ports it should. It's just a historical oversight
Linus, Andrew,
As suggested by Alan, here's a small patch against kernel 2.4.29 to
split the IO addresses reserved for the PC timer into two regions
instead of a large one.
It mimics what has been done in kernel 2.6.
Instead of reserving 0x40 through 0x5f it reserves only what the two
timers need, i.e 0x40-0x43 and 0x50-0x53.
It patches both i386 and x86_64 architecture.
Please CC me in replies since i did not subscribe to the list.
--
Charles-Edouard Ruault
Idtect SA
115 rue Reaumur - 75002, Paris, France
Tel: +33-1-55-34-76-65
Fax: +33-1-55-34-76-75
Web: http://www.idtect.com
--- linux/arch/i386/kernel/setup.c.orig Fri Feb 18 18:46:55 2005
+++ linux/arch/i386/kernel/setup.c Mon Feb 21 11:19:45 2005
@@ -354,7 +354,8 @@
struct resource standard_io_resources[] = {
{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
- { "timer", 0x40, 0x5f, IORESOURCE_BUSY },
+ { "timer0", 0x40, 0x43, IORESOURCE_BUSY },
+ { "timer1", 0x50, 0x53, IORESOURCE_BUSY },
{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
--- linux/arch/x86_64/kernel/setup.c.orig Mon Feb 21 11:56:11 2005
+++ linux/arch/x86_64/kernel/setup.cMon Feb 21 11:54:41 2005
@@ -93,7 +93,8 @@
struct resource standard_io_resources[] = {
{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
- { "timer", 0x40, 0x5f, IORESOURCE_BUSY },
+ { "timer0", 0x40, 0x43, IORESOURCE_BUSY },
+ { "timer1", 0x50, 0x53, IORESOURCE_BUSY },
{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?
linux-os wrote:
On Mon, 7 Feb 2005, Randy.Dunlap wrote:
Charles-Edouard Ruault wrote:
Hi All,
i wrote a driver for the watchdog timer provided by a small form
factor board from IEI ( the PCISA-C800EV :
http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ).
This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset.
The watchdog uses two registers at addresses 0x43 and 0x443,
therefore my driver tries to get bot addresses for its own use calling
request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1,
"watchdog").
The first call to request 0x43 fails because the address has already
been allocated to the timer ( /proc/ioports shows 0040-005f : timer ).
So my questions are :
- Why is the generic timer using this address ? isn't it reserving a
too wide portion of IO ports ? Should it be modified for this board ?
- If there's a good reason for the timer to request this address,
is there a clean way to share it with the timer ?
Missing kernel version must be "not the current/latest",
so early 2.6 or more likely 2.4 (just guessing)?
/proc/ioports timer assignments have now been split up like this:
0040-0043 : timer0
0050-0053 : timer1
However, port 0x43 is still assigned to timer0, so your request_region
call will still fail. What system board timer resource assignments
should be used for that VIA chipset? If the chipset timer only needs
0x40-0x42, e.g., leaving 0x43 available, then it would be possible
to do some kind of workaround (maybe not real clean, but possible).
--
~Randy
The driver can still R/W registers that it hasn't allocated.
There is no hardware trap preventing this. I suggest that,
as a temporary work-around, just don't allocate the low
port, but attempt to use it. I think the watchdog probably
just looks for read at that address.
Hi Dick,
thanks for the reply. Right now i'm doing exactly what you suggest and
it works fine ... but i'm not really happy about this "workaround" since
it's not clean.
The driver reads only at 0x43 to disable the watchdog , i have not seen
any side effect so far but ... one never knows !
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
--
Charles-Edouard Ruault
Idtect SA
115 rue Reaumur - 75002, Paris, France
Tel: +33-1-55-34-76-65
Fax: +33-1-55-34-76-75
Web: http://www.idtect.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?
Randy.Dunlap wrote: Charles-Edouard Ruault wrote: Hi All, i wrote a driver for the watchdog timer provided by a small form factor board from IEI ( the PCISA-C800EV : http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ). This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset. The watchdog uses two registers at addresses 0x43 and 0x443, therefore my driver tries to get bot addresses for its own use calling request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, "watchdog"). The first call to request 0x43 fails because the address has already been allocated to the timer ( /proc/ioports shows 0040-005f : timer ). So my questions are : - Why is the generic timer using this address ? isn't it reserving a too wide portion of IO ports ? Should it be modified for this board ? - If there's a good reason for the timer to request this address, is there a clean way to share it with the timer ? Missing kernel version must be "not the current/latest", so early 2.6 or more likely 2.4 (just guessing)? /proc/ioports timer assignments have now been split up like this: 0040-0043 : timer0 0050-0053 : timer1 However, port 0x43 is still assigned to timer0, so your request_region call will still fail. What system board timer resource assignments should be used for that VIA chipset? If the chipset timer only needs 0x40-0x42, e.g., leaving 0x43 available, then it would be possible to do some kind of workaround (maybe not real clean, but possible). Hi Randy, thanks for the reply. My apologies for not including the kernel version ( that's what you get when you try to go too fast ;) You were right, i'm running 2.4.29 ! I don't know about the resources assignments needed by this timer. I tried to get the spec sheets for the chipset from the via site but i was not able to find it ( i did not spend hours looking tough ). I was wondering if someone had the info out there ! Right now i'm just not taking into account the failure of the request_region and everything works fine. But i wanted to make it clean so ... i'll have to dig deeper into this i guess ! -- Charles-Edouard Ruault Idtect SA 115 rue Reaumur - 75002, Paris, France Tel: +33-1-55-34-76-65 Fax: +33-1-55-34-76-75 Web: http://www.idtect.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IO port conflict between timer & watchdog on PCISA-C800EV board ?
Hi All, i wrote a driver for the watchdog timer provided by a small form factor board from IEI ( the PCISA-C800EV : http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ). This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset. The watchdog uses two registers at addresses 0x43 and 0x443, therefore my driver tries to get bot addresses for its own use calling request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, "watchdog"). The first call to request 0x43 fails because the address has already been allocated to the timer ( /proc/ioports shows 0040-005f : timer ). So my questions are : - Why is the generic timer using this address ? isn't it reserving a too wide portion of IO ports ? Should it be modified for this board ? - If there's a good reason for the timer to request this address, is there a clean way to share it with the timer ? Thanks for your answers. Regards. PS: Please CC me to your replies, i'm not on the list. -- Charles-Edouard Ruault Idtect SA 115 rue Reaumur - 75002, Paris, France Tel: +33-1-55-34-76-65 Fax: +33-1-55-34-76-75 Web: http://www.idtect.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext2 corruption in 2.4.0 (again)
I've seen on Kernel Traffic that some people have reported an ext2 corruption with kernel 2.4.0. It happened to me yesterday with a different configuration than the one reported on the original posting so i just want to report the problem again : I was doing some standard work on my system and after issuing a ls in / i saw some weird info displayed ( very huge files, strange permissions etc ... ), after a while i had a kernel panic with the following message : ext2-fs panic ( device ide0(3,1)) : load_block_bitmap : block_group >= groups_count - block_group =302292 group_count=226 and the system died. I tried to reboot, i did not work ( unable to mount root partition ) I booted in redhat-rescue mode and tried to run fsck on my root filesystem, it did not recognized the superblock so i used another superblock and it was reporting almost all the inodes corrupted. I tried to repair what could be repaired without success. I ended up reformatting my HD and reinstalling the system ( first time it happens to me in 6 years of Linux ). Here's some info on my system : Hardware : Pentium III 550Mhz 384 MB RAM IDE hard drive : FUJITSU MPC3064AT ( /dev/hda ) here's the content of /proc/pci : PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel 440BX - 82443BX Host (rev 3). Medium devsel. Master Capable. Latency=64. Prefetchable 32 bit memory at 0xf800 [0xf808]. Bus 0, device 1, function 0: PCI bridge: Intel 440BX - 82443BX AGP (rev 3). Medium devsel. Master Capable. Latency=128. Min Gnt=140. Bus 0, device 7, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 2). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. I/O at 0x1060 [0x1061]. Bus 0, device 7, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=64. I/O at 0x1040 [0x1041]. Bus 0, device 7, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 2). Medium devsel. Fast back-to-back capable. Bus 0, device 12, function 0: Multimedia audio controller: Unknown vendor Unknown device (rev 3). Vendor id=1073. Device id=c. Medium devsel. IRQ 10. Master Capable. Latency=64. Min Gnt=5.Max Lat=25. Non-prefetchable 32 bit memory at 0xf400 [0xf400]. Bus 0, device 15, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=66. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xf4008000 [0xf4008000]. I/O at 0x1000 [0x1001]. Non-prefetchable 32 bit memory at 0xf410 [0xf410]. Bus 1, device 0, function 0: VGA compatible controller: Intel Unknown device (rev 33). Vendor id=8086. Device id=7800. Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. No bursts. Prefetchable 32 bit memory at 0xf500 [0xf508]. Non-prefetchable 32 bit memory at 0xf420 [0xf420]. Software: kernel 2.4.0 on a redhat 7.0 (compiled with kgcc). I upgraded the following packages ( following the /usr/src/linux/Documentation/Changes document ) : e2fsprogs-1.19-0.2.i386.rpm iptables-1.1.1-2.i386.rpm util-linux-2.10p-2.i386.rpm e2fsprogs-devel-1.19-0.2.i386.rpm modutils-2.4.0-1.i386.rpm that's about it I hope this helps ! keep on the great work ! regards Charles-Edouard Ruault - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
