| === Tim-away is now known as TimStarling | ||
| jbuncher | apw: I won't be able to test those kernels today, but I should get a chance to tomorrow. | 00:30 |
|---|---|---|
| apw | they'll take some hours yet anyhow ... will reply on the bug | 00:43 |
| jbuncher | sounds good | 00:44 |
| === dreamnid_ is now known as dreamnid | ||
| === mib_4tf3sums is now known as pARAd0X85 | ||
| pARAd0X85 | where is the best place to discover the Linux Input Architecture ? | 08:57 |
| smb_tp | Ok, so maybe we look at the same stuff with https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/286672 as for | 14:07 |
| ubot3 | Malone bug 286672 in linux "WARNING: at /build/buildd/linux-2.6.27/kernel/power/main.c:176 suspend_test_finish+0x74/0x80()" [Medium,In progress] | 14:07 |
| smb_tp | bug 318978 | 14:08 |
| ubot3 | Malone bug 318978 in dell "Hard drive in Studio XPS 13 and 16 cause a 17-18s resume time" [High,Fix released] https://launchpad.net/bugs/318978 | 14:08 |
| rtg | smb_tp: the driver was violating the spec in that it was not waiting the minimum amount of time for the link to reestablish | 14:08 |
| smb_tp | Ok, what happened when it did not wait long enough? It went into a reset? | 14:08 |
| rtg | smb_tp: it would eventually resover, but not until after the resume time had been exceeded | 14:09 |
| rtg | recover, even | 14:09 |
| smb_tp | Hm, from the logs in the other bug report it looks like the link has been reset (could be the recovers) and it requires quite some time until the disk is ready | 14:10 |
| rtg | smb_tp: exactly, thats why its disk specific | 14:11 |
| smb_tp | Then the best thing to check is whether that patch has been backported to intrepid, but I too don't think so. | 14:12 |
| rtg | smb_tp: its a real simple change | 14:12 |
| apw | IntuitiveNipple, on bug #286673 you suggest that there is a relationship with firmware loading, i don't see any firmware loading in the kernel logs there | 14:13 |
| ubot3 | Malone bug 286673 in flashplugin-nonfree "flash plugin 10 is extremely slow !" [Undecided,Confirmed] https://launchpad.net/bugs/286673 | 14:13 |
| smb_tp | The other thing is, should kerneloops react on a WARN like it does? It seems to act as if a kernel crash had occured. | 14:13 |
| apw | all i see is a machine loading slowly, cause its disk took a little while to come back | 14:13 |
| IntuitiveNipple | apw: Relationship *could* have been related to the firmware issue. My investigation showed it isn't on that bug | 14:13 |
| apw | rtg, smb, one thing i would note here, is that its ok for sata to take up to 5 seconds, and yet the overall resume warning time is 5 seconds | 14:14 |
| IntuitiveNipple | apw: It was in the context of my sweeping through the suspend/resume bugs trying to identify which might be caused by the firmware load issue | 14:14 |
| apw | i think in tandem we should up the rather arbitrary resume timeout by the delta there | 14:14 |
| apw | IntuitiveNipple, makes sense then | 14:14 |
| rtg | apw: correct, but in general most disks re-synv in something less then 2 seconds, whereas the original timeout was only 1 second. | 14:15 |
| apw | smb_tp, most WARN_ON's are something that needs reporting, that one really isn't | 14:15 |
| apw | rtg, yes, but the one in the bug smb quotes first the disk take of the order of 2s to recover | 14:15 |
| apw | and in that machine that pushes recovery to 8s total, there is nothing major there, other than the disk at 2s to my eyey | 14:16 |
| smb_tp | I guess it is only the "your kernel crashed" string that apparently is somewhere in the popup window when it asks for submitting a report that makes users jump | 14:16 |
| apw | if its going to be that close to a pretty idea time, its too agressive as a WARN_ON if you have kerneloops installed | 14:17 |
| apw | my feeling is that that is a bit low with the state of the art, its an ideal not a hard deadline | 14:17 |
| apw | i wonder if perhaps there should be a 'look_i_am_slow_at_resuming=yes' kernel command line to shut it up | 14:18 |
| apw | else people will report an oops for every resume | 14:18 |
| smb_tp | The reports would require something like a 5s delay (that is when the atalib prints be patient) | 14:18 |
| smb_tp | But that probably is not needed if the other timeout is larger | 14:19 |
| smb_tp | IntuitiveNipple, I think we should try the patch from 318978 with some Intrepid test kernels. If that prevents the recovery this should help there as well. | 14:22 |
| IntuitiveNipple | smb_tp: Have I got confused? I *thought* one of the reporters was using 2.6.28-6 or -7 ? | 14:22 |
| * smb_tp looks again | 14:23 | |
| IntuitiveNipple | smb_tp: You're correct! I've looked at som many kern.log's recently I don't know where I am :) | 14:24 |
| IntuitiveNipple | s/som/so/ | 14:24 |
| smb_tp | No, there seems to be one, thoug hard to say which extactlly kernel level | 14:25 |
| IntuitiveNipple | in which case I agree, if Tim's patch will help it'll calm some nerves | 14:25 |
| smb_tp | https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/286672/comments/16 | 14:25 |
| ubot3 | Malone bug 286672 in linux "WARNING: at /build/buildd/linux-2.6.27/kernel/power/main.c:176 suspend_test_finish+0x74/0x80()" [Medium,In progress] | 14:25 |
| IntuitiveNipple | oh, well spotted! | 14:25 |
| smb_tp | Hm , must be 2.6.28-8-24 | 14:25 |
| smb_tp | Lets check when the other patch got in | 14:25 |
| IntuitiveNipple | It shows 2.6.28-8-generic #24-Ubuntu | 14:26 |
| smb_tp | rtg, patch went in 2.6.28-5.12, so it should be in there | 14:27 |
| rtg | smb_tp: in Jaunty for sure. I thought you were talking about Intrepid? | 14:27 |
| smb_tp | Most of the others yes. One single WARN for 28 but funnily when he supplied the whole dmesg it was 2.6.27 again... | 14:28 |
| rtg | hmm, some crack involved? | 14:28 |
| IntuitiveNipple | Someone testing kernels to fix it maybe? | 14:30 |
| IntuitiveNipple | I'll ask him to clarify | 14:30 |
| smb_tp | Sounds a bit like it. Well the WARN jsut says takes to long on resume, we don't know why for 2.6.28, so I would really go with that patch and see | 14:30 |
| smb_tp | IntuitiveNipple, I could provide a test kernel to try and link it to the bug report | 14:31 |
| IntuitiveNipple | That'd be useful :) I'm just adding a comment now | 14:33 |
| * smb_tp goes to cook a kernel | 14:33 | |
| IntuitiveNipple | smb_tp: Can you throw in a printk() so we know which code-path ata_wait_ready() takes when -ENODEV applies? I don't think we can figure it out any other way. It would help determine if the ATA_TMOUT_FF_WAIT is used to cause ready to be reset artificially | 14:37 |
| smb_tp | IntuitiveNipple, should be possible. hopefully after the other patch the wait won't occur | 14:39 |
| IntuitiveNipple | And if it does, we get to know which code-path to poke | 14:40 |
| IntuitiveNipple | smb_tp: Looking at it, it might be best to use a count of how many times 'ready' is reset in both paths and print the summary at function-exit else printing to log every~ 50ms might add a delay of its own :) | 14:44 |
| smb_tp | Heh, yeah :) | 14:45 |
| === TimStarling is now known as Tim-away | ||
| philsf | ogasawara: ping? | 16:29 |
| ogasawara | philsf: what's up | 16:29 |
| Martyn | Had anyone had experience configuring and using gfs or OCFS2 on ubuntu-server? | 16:30 |
| philsf | ogasawara: I was told to contact you about a bug, could you take a look at a kernel backtrace for me please? | 16:30 |
| ogasawara | philsf: sure, which bug # | 16:30 |
| philsf | http://launchpadlibrarian.net/21975410/dmesg.log from bug #325238 | 16:31 |
| ubot3 | Malone bug 325238 in linux "BUG: unable to handle kernel paging request" [Undecided,New] https://launchpad.net/bugs/325238 | 16:31 |
| philsf | I think I inputted everything the wiki asks for | 16:32 |
| Martyn | philsf : Considering I'm also currently working in the kernel paging subsystem .. I'll take a quick gander too | 16:37 |
| philsf | Martyn: cool, thanks! | 16:37 |
| philsf | it looks like it should be a nvidia blob thing, but since it also happens with the LiveCD, it also should not be. kind of a paradox for the lay me | 16:38 |
| ogasawara | philsf: you mention you're able to reproduce with a LiveCD, have you tried the latest Jaunty Alpha? has a 2.6.28 based kernel. | 16:39 |
| ogasawara | philsf: I'd just be curious if it still oopses | 16:39 |
| philsf | ogasawara: I haven't. I only tried hardy CD and DVD | 16:39 |
| philsf | the strange thing is that it worked perfectly for almost a year | 16:39 |
| ogasawara | philsf: http://cdimage.ubuntu.com/releases/jaunty/ | 16:40 |
| ogasawara | philsf: if you wouldn't mind testing that would be great - also Alpha 5 should drop today | 16:40 |
| philsf | ok, I'l try it in a couple of hours | 16:42 |
| ogasawara | philsf: thanks. I'll subscribe to the bug report, so if you can post a comment with your test results there I'll see it | 16:42 |
| Martyn | ogasawara : The OOPS recorded in the log is odd. | 16:43 |
| Martyn | ogasawara : It was in the middle of trying an execve | 16:45 |
| Martyn | Which would be what you'd expect if it .. say .. couldn't read the file from the page_cache after it expected to load it from disk. | 16:45 |
| Martyn | However, the whole chain of Oops'es seems to start early on, during the initialization of the intel 915... | 16:46 |
| Martyn | [ 51.475653] EIP: [<f990f9ee>] intel_i915_configure+0xce/0x100 [intel_agp] SS:ESP 0068:f741bde4 | 16:46 |
| Martyn | (agp bus) | 16:46 |
| Martyn | philsf : When you remove the nVidia card, everything boots correctly, right? | 16:48 |
| kristian_ | oooo. is this the kernel? | 17:26 |
| maco | kristian_: yes, would you like some popcorn? | 17:30 |
| kristian_ | thanks, but no thanks! | 17:33 |
| kristian_ | i fount the kernel! :-D | 17:34 |
| kristian_ | found* | 17:34 |
| philsf | Martyn: yes, when I remove the nvidia card, everything boots ok, afaict | 18:44 |
| Martyn | You have a conflict, in hardware then. | 18:52 |
| Martyn | i know you say it's been working before, which leads me to think there might be a hardware change somewhere. Specifically, I'm wondering if the internal intel 915 based video is trying to map the same resources as the nVidia card now. Not something that would _usually_ be a bios setting. | 18:53 |
| Martyn | More a jumper. | 18:53 |
| Martyn | but sometimes it can be something the manufacturer lets you set in the BIOS of the machine (disable internal video card) etc... | 18:53 |
| IntuitiveNipple | It could be an MTRR issue... I was suspicious of the VESA framebuffer | 18:53 |
| Martyn | Why? | 18:54 |
| Martyn | "intuitive nipple?" I have to know the origin | 18:54 |
| IntuitiveNipple | depending on the CPU, there may be insufficient MTRRs | 18:54 |
| IntuitiveNipple | philsf: Did the system work ok previously with the nvidia adapter ? | 18:55 |
| Martyn | True, but phil said that there were no major changes, and it was working in the past... | 18:55 |
| Martyn | so mtrr exhaustion seems unlikely | 18:55 |
| IntuitiveNipple | Unexpected BIOS reset might influence that. I've seen many systems cause unexpected issues because of that. | 18:56 |
| Martyn | Ah, good point. | 18:56 |
| jbuncher | apw: I'm posting in the bug right now, but I was able to test all 3 of those kernels, and they all worked. The 24-23 kernel still won't connect though. Do you know of any other changes would there be between .24-22 and .24-23 that would have caused this? | 18:57 |
| IntuitiveNipple | If you look at the vm addresses of the oops they are very close to pkmap. I wondered if something was invading pkmap | 18:57 |
| Martyn | Although would linux early initialization really pay attention to what the BIOS settings are vis-a-vie MTRR's? | 18:57 |
| IntuitiveNipple | The MTRRs are being configured to take account of holes and so forth by things like agpgart and so on. Also, the vesa fb driver can also allocate them. | 18:58 |
| philsf | IntuitiveNipple: yes, it worked for almost a year, since I bought it | 18:58 |
| IntuitiveNipple | philsf: OK, I noticed you said that it started 'shortly after' after adding the additional hard disk | 18:59 |
| IntuitiveNipple | philsf: how 'short' is short? | 18:59 |
| philsf | IntuitiveNipple: about a week | 18:59 |
| IntuitiveNipple | philsf: And the nvidia adapter was in the system at that time, yes? | 19:00 |
| philsf | IntuitiveNipple: yes | 19:00 |
| IntuitiveNipple | philsf: but when things started going wrong, you discovered that removing it solved the problems? | 19:00 |
| philsf | correct | 19:00 |
| IntuitiveNipple | OK. Did you see my suggestions I added to the bug report? | 19:00 |
| philsf | I just read them. I'll try them in order now | 19:01 |
| philsf | can I skip some steps, since I know the HDs work without the nvidia? | 19:01 |
| philsf | and do you need all dmesg.logs for each step? | 19:02 |
| IntuitiveNipple | philsf: I would place a mild bet on the BIOS step right now. Not just resetting it, but looking for alternate configuration options that affect the internal/external video chipsets and memory mapping | 19:02 |
| philsf | so, should reset to factory defaults suffice? | 19:03 |
| IntuitiveNipple | No, don't need logs. The idea is to try and find some point at which the system is stable. | 19:03 |
| IntuitiveNipple | You've confirmed two things: 1) removing the nvidia adapter solves the issue and 2) it used to work with it in | 19:04 |
| apw | jbuncher, thnkas for the test, will think on it | 19:04 |
| IntuitiveNipple | philsf: So I'd be looking in BIOS for any and all options that affect the video chipsets and memory-mapping (AGP window, for example) | 19:04 |
| jbuncher | apw: no problem, glad to help. | 19:05 |
| philsf | IntuitiveNipple: ok, I just booted the ahrdy liveDVD sucessfully, with everyting except for the nvidia adapter. Since I have no idea what a proper setting would be for AGP window, nor anything related to that, I never changed it (willingly, that is) | 19:13 |
| philsf | *hardy | 19:13 |
| IntuitiveNipple | philsf: OK. In BIOS did you see any options anywhere that allow the enabling/disabling of the internal graphics chipset ? | 19:15 |
| IntuitiveNipple | philsf: Also, what motherboard make/model is it? | 19:15 |
| philsf | IntuitiveNipple: it's an intel d945gpt mobo | 19:15 |
| philsf | IntuitiveNipple: I honestly didn't even look for such an option, will do now | 19:16 |
| IntuitiveNipple | philsf: there usually is something buried away. First thing I do with any system is go through every BIOS menu and option so I will remember in future when something like this comes up | 19:17 |
| * IntuitiveNipple has to leave now. Dinner. | 19:18 | |
| philsf | IntuitiveNipple: me too, with the exception of the arcane PCI settings | 19:18 |
| philsf | IntuitiveNipple: thanks for the tips, I'll update the bug with any news from the tests | 19:18 |
| IntuitiveNipple | philsf: Those are the important ones... sometimes something important is buried 3 menus deep | 19:18 |
| IntuitiveNipple | philsf: I'll keep an eye on the bug report | 19:18 |
| Martyn | Okay, is there some arcade voodo I have to do in order to get gfs working in Intrepid? | 19:33 |
| Martyn | Because right now, the gfs kernel module is -not- cooperating | 19:34 |
| wmat | Martyn: not cooperating how? | 19:47 |
| maco | would "iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks" be the first thing sent to dmesg after modprobing iwlagn? | 19:50 |
| rtg | maco: looks like the module banner to me | 19:50 |
| maco | total kernel newbie here..does that make it the first thing that happens when i modprobe it? | 19:51 |
| wmat | maco: try removing it, then tailing dmesg while adding it | 19:51 |
| rtg | maco: its close enough to the first thing that happens | 19:51 |
| maco | ok | 19:51 |
| maco | er...oh...should i be looking at dmesg, syslog, or kern.log to find what the iwlagn module was doing during ifup? | 19:52 |
| maco | i think it's the modules fault ifup kept failing. unload/reload fixed it | 19:53 |
| rtg | maco: dmesg collects all driver log output | 19:53 |
| maco | thanks | 19:54 |
| rtg | maco: actually, dmesg collects all printk() output. | 19:54 |
| philsf | Martyn: doI understand correctly IntuitiveNipple's suggestion was somehow the BIOS got corrupted? | 19:57 |
| Martyn | philsf : I also think it's possible your BIOS settings _may_ be involved here. It might be worth it to go into the BIOS, choose some default settings, and then try again. | 19:58 |
| Martyn | wmat : It's not loading. | 19:59 |
| Martyn | wmat : It seems to load, and the kernel reports the symbols as being available, but the gfs tools refuse to work. | 19:59 |
| wmat | Martyn: GFS2 tools? I recall something about everything GFS related moving to GFS2, but I could be wrong. | 20:04 |
| philsf | resetting BIOS config to factory defaults apparently solved it for good. I'd like to know why :) | 20:06 |
| Martyn | Hmmm .... does tmpfs (or any of the RAMfs drivers) pin the pages into memory to prevent them getting swapped out? | 22:04 |
| Martyn | Aka.. is it safe to use a tmpfs volume for swapping? | 22:04 |
| Majost | Is there some documentation I can look at to figure out how to create an additional patch set for ubuntu-hardy-lum? | 22:50 |
| laga | Majost: what do you want to do? | 22:50 |
| Majost | I want to add a couple HDA patches and update the existing hda_codec.patch | 22:51 |
| laga | have you found the kernel team wiki yet? | 22:52 |
| Majost | Yes, but I haven't found anything specific to the hardy-lum package just yet. | 22:53 |
| laga | you get a git checkout, apply your patches, update changelog, rebuild? | 22:53 |
| Majost | so for the .patch files, is there a series file or anything which is used to apply a patch order? | 22:55 |
| laga | i believe it's all kept in git. not sure about that anymore | 22:55 |
| Majost | okay, I will look there | 22:55 |
| Majost | So is there any preferred specific method of patching to be able to push fixes upstream? | 23:10 |
| laga | Majost: git commits seem to be the preferred way.. | 23:16 |
| laga | who is "upstream"? hardy-lum probably is pretty old | 23:16 |
| Majost | Well, hopefully Ubuntu. | 23:26 |
| laga | ah, that patch flow is documented in the wiki | 23:27 |
| === Tim-away is now known as TimStarling | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!