| ogasawara | apw: thanks for investigating that kernel-wedge build issue | 09:11 |
|---|---|---|
| ogasawara | apw: I saw all my builds failed but then had to leave for the airport | 09:12 |
| ogasawara | apw: we missed our connection and are stuck in AMS til this evening | 09:12 |
| === yofel_ is now known as yofel | ||
| === lag is now known as Guest77371 | ||
| ralphcor | Hi, CONFIG_MEMTEST isn't defined by default. I know of memtest86+ but memtest.c gives a memtest=N kernel parameter that runs N tests every boot, maps out bad memory, and being __init disappears later. memtest86+ runs until killed, although its tests are better. | 12:45 |
| ralphcor | Would a wishlist bug for CONFIG_MEMTEST be the way to go? | 12:45 |
| ralphcor | memtest.c gives the paranoid the ability to "run a few tests every boot". | 12:46 |
| penguin42 | ralphcor: What does it do when the test fails? | 12:47 |
| ralphcor | penguin42: printk KERN_INFO and reserve_early(). http://lxr.linux.no/#linux+v2.6.34.1/arch/x86/mm/memtest.c#L32 | 12:48 |
| penguin42 | I guess you could also do something that watched for those and told the user if it survived that long, or spotted them in reported oopss | 12:51 |
| manjo | apw, ping | 12:52 |
| ralphcor | penguin42: I suppose so, but just being able to look at dmesg post-boot and see if memtest.c was happy would be useful. I'm finding the in RAM copy of files can have four bytes, spaced 16 apart, differ from the on disc file after a day or two of uptime. But translating the virtual address of that file+offset into physical RAM address can't be easily done, AFAICS. And memtest86+ is happy, as I say. So CONFIG_MEMTEST would be another option. | 12:55 |
| penguin42 | ralphcor: Nasty; you're assuming that's a RAM problem | 12:56 |
| penguin42 | ralphcor: Are they always at the same offset into any 512byte block? | 12:58 |
| ralphcor | penguin42: True, I am, but then a userspace memory tester has also, once, come up with the same symptom after a few minutes, but never again, which seems to rule out the hard drive -> RAM route. So it's probably happening to other pages of RAM too, it's just the output of lsof is a handy list of files to check. | 12:58 |
| ralphcor | penguin42: No. Here's one where the four RAM bytes are corrupted to become 0x00. http://dorset.pastebin.com/KgLM9jtU | 13:00 |
| ralphcor | penguin42: And a second that shows a more complex corruption. http://dorset.pastebin.com/GsGYGAD6 | 13:01 |
| ralphcor | Ignore the commentary in the first, it was before I cottoned on to the RAM copy being duff, and not my copy of the root partition. | 13:02 |
| penguin42 | ralphcor: Wow, those are weird - I've not seen things vertically changed like that - 4 bytes in a row isn't too unusual | 13:02 |
| ralphcor | penguin42: Me neither. Although 16 bytes is 128 bits which may be a cache line length on this 64-bit arch? That the offset within the 16-bytes differs is strange though. | 13:03 |
| ralphcor | Who knows, perhaps if memtest=N was easily available we'd see more detection of RAM problems helping to point the finger for some of these random kernel crashes. | 13:05 |
| penguin42 | yeh | 13:05 |
| penguin42 | ralphcor: I can imagine if one chip in a DIMM wasn't getting write enabled some of the time or a bad connection then I guess you might see something like that - but it's still odd | 13:06 |
| ralphcor | I was also wondering out of interest if memtest86+ uses all available cores. | 13:06 |
| ralphcor | penguin42: Agreed. If I could get physical address for every fault then I could look for such a pattern. But not being able to do that from userspace is a hamper. memtest=N would report physical addresses, I hope. It's walking through e820 areas. | 13:08 |
| penguin42 | yeh | 13:09 |
| lamont | so about these getattr calls that apparmor is denying... what's the change to the profile to make them happy again? | 15:56 |
| pavolzetor | https://bugs.launchpad.net/gnome-power/+bug/257827 | 16:12 |
| ubot2 | Launchpad bug 257827 in linux (Ubuntu Intrepid) (and 3 other projects) "brightness changes twice when using hotkeys (affects: 7) (dups: 1) (heat: 70)" [Medium,Fix released] | 16:12 |
| pavolzetor | can you hep me | 16:12 |
| lamont | so.. maverick kernel (just linux-image-2.6.35-9-generic), lucid userspace: what am I missing that it no longer finds access points? | 22:36 |
| lamont | meh. broadcom wireless nic seems to be getting ignored | 22:39 |
| ripps | whoa... I thought I had a good understanding of packaging, but than I took a look at the l-b-m packaging... | 22:42 |
| lamont | that's one seriously complicated package. | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!