| === inuka_desk_ is now known as inuka_desk | ||
| === jayc__ is now known as jayc_ | ||
| osmosis | i dont understand what this means, http://www.news.com/8301-13580_3-9867657-39.html | 05:05 |
|---|---|---|
| osmosis | zul: ping | 05:17 |
| === jayc__ is now known as jayc_ | ||
| tjaalton | hmh, resume from hibernate failed, ie. it booted normally and not from the file | 05:56 |
| === asac_ is now known as asac | ||
| === macd_ is now known as macd | ||
| === Whoopie_ is now known as Whoopie | ||
| cking | xivulon: Hi, I've been looking at your notes for the Wubi issues | 10:45 |
| xivulon | just added a new one! | 10:46 |
| xivulon | was waiting for you in fact... | 10:46 |
| xivulon | let me know if I need to clarify anything | 10:47 |
| cking | xivulon: I managed to screw up my /home today playing around with this - I was offline for a while sorting my machine out :-( | 10:48 |
| xivulon | sorry to hear that :( | 10:49 |
| cking | xivulon: It's all part of the fun :-) | 10:49 |
| xivulon | You are invited to explain the fun part to my wife... | 10:49 |
| cking | xivulon: I looked at the notes - the problem is umounting / and then /home - can one actually do this in practice? | 10:50 |
| cking | xivulon: I was thinking of using pivot_root but I haven't much experience with this, so I am not sure if this a possible way of doing things | 10:50 |
| xivulon | unmounting is not a problem except that it will be the last thing you can do (without a ramdisk) | 10:50 |
| xivulon | see my last comment on that | 10:51 |
| cking | ..but with a ramdisk, one could umount /? | 10:51 |
| xivulon | I would assume so | 10:51 |
| xivulon | but I have never tried that | 10:51 |
| cking | ..me neither. I think we may need some expertise from someone like Colin Watson. | 10:52 |
| xivulon | eheh... | 10:53 |
| cking | But I think it will lead to a sane shutdown that will ensure / and /home are flushed and umounted properly | 10:53 |
| cking | ..otherwise one will always see this kind of corruption of / | 10:53 |
| cking | if one can do this then the vm dirty hacks are no longer required | 10:54 |
| xivulon | I'd think that if we could remount /host ro (safely) it would be good enough | 10:54 |
| xivulon | see my umountroot attachment for that, unfortunately ntfs-3g complains about remounting... | 10:55 |
| xivulon | cking the vm dirty hacks are still required in case someone hard-reboot | 10:55 |
| cking | xivulon: yep - true about the hard-reboot - I overlooked that detail. | 10:56 |
| xivulon | In fact based on user feedback all the problems of fs corruption were due to hard reboots | 10:56 |
| xivulon | I haven't seen any complaint about fs corruption because of normal reboot | 10:57 |
| xivulon | I'd guess that remounting root ro + the sysctl hacks is enough in most cases (and maybe some fsck help...) | 10:57 |
| cking | xivulon: I managed it :-) I did started removing a huge tree of source and then rebooted - and I got a bit of a mess | 10:57 |
| xivulon | that is with the sysctl hacks? | 10:58 |
| xivulon | cking was disconnected | 10:59 |
| cking | xivulon: what happened there? | 11:00 |
| cjwatson | there was a netsplit, too | 11:00 |
| cking | ..a netsplit? | 11:00 |
| cjwatson | IRC networks consist of many servers, in general, which are connected in a graph; if a pair of servers lose their connection, that's a netsplit | 11:00 |
| cking | ah.. I am enlightened | 11:00 |
| cjwatson | which results in the users on the network being effectively partitioned in terms of their ability to talk to each other | 11:00 |
| xivulon | cking missed replies after my last comment | 11:01 |
| xivulon | didn't miss cjwatson explanation though :) | 11:01 |
| cking | xivulon: yep, I kind of missed the last few lines | 11:01 |
| cjwatson | 10:56 <cjwatson> cking: I think you misunderstand the order of events slightly, though | 11:02 |
| cjwatson | 10:56 <cjwatson> cking: the NTFS filesystem in question is actually /host, not /home | 11:02 |
| cjwatson | 10:56 <cjwatson> cking: and Wubi is a little odd here - the way it works is that / is actually a loop-mounted filesystem *on top of* an NTFS filesystem that is then moved to /host | 11:02 |
| cjwatson | 10:57 <cjwatson> cking: so the filesystems are the other way round from what you'd expect | 11:02 |
| cjwatson | in case that was missed | 11:02 |
| cking | thanks | 11:02 |
| cking | .. I keep on writing /home when I mean /host - it's a constant brain type of mine | 11:03 |
| cking | ^type^typo. I need coffee. | 11:03 |
| xivulon | the crux though is that /host cannot be remounted r/o IMHO | 11:03 |
| cjwatson | I suspect that you cannot actually unmount / and then expect to be able to unmount /host | 11:03 |
| cjwatson | because you won't have a reference to /host any more | 11:03 |
| xivulon | cking did you experience fs corruption when rebooting (rc6.d) and with the sysctl hacks in place? | 11:03 |
| cjwatson | you'd have to move all the mount points around, and frankly, I do not think that is a viable approach at this point | 11:04 |
| xivulon | was /host to be corrupted or / and did corruption involve the journal? | 11:04 |
| cking | xivulon: yep | 11:04 |
| cjwatson | we need something pretty simple and foolproof, and playing Tetris with your mount points isn't that :) | 11:04 |
| cking | cjwatson: I'm not sure if there is a solution that is simple and foolproof. | 11:05 |
| xivulon | not sure if we can try fixing /host (ntfs-3g) remount | 11:05 |
| cking | xivulon: one could do that - but wasn't there a big risk that NTFS could get corrupted? | 11:06 |
| xivulon | that was my understanding from last szaka comment | 11:06 |
| xivulon | did ask him some more info by mail but he didn't reply | 11:07 |
| cjwatson | if the NTFS filesystem is never remounted read-only or unmounted (as is the case at the moment, I understand), why does that affect the kernel's ability to writeback changes to the ext3 /? | 11:07 |
| cjwatson | or rather, what is breaking the kernel's ability to writeback changes? | 11:07 |
| cking | cjwatson: from the way I see it, we can either force disk writebacks using the vm flush hacks - but this does not necessarily guarantee a fulling sync'd fs.. or.. | 11:08 |
| cjwatson | IIRC the kernel always syncs just before reboot | 11:08 |
| cking | .. we can fool around with the umounting. The former may help when systems power down in an uncontrolled way, the latter makes sure the filesystems are coherently umounted at shutdown | 11:09 |
| cking | cjwatson: true. | 11:10 |
| xivulon | ...and yet you ended up with a corrupted fs | 11:10 |
| cking | ..my concern is that the /host is not being properly written back to. | 11:10 |
| cking | I believe /host is not being umounted which worries me. | 11:12 |
| xivulon | it certainly is not | 11:12 |
| xivulon | or you would lose / | 11:12 |
| xivulon | and hence /sbin/reboot | 11:12 |
| cjwatson | remounting it read-only ought to be as good as unmounting from the perspective of avoiding corruption, but that's been problematic due to ntfs-3g bugs | 11:13 |
| xivulon | cking, on a side note, you also suggested using sync mount option on the loopfile, I assume you meant the /host fs | 11:14 |
| cking | xivulon: yes, if it's possible on ntfs. The sync is not required on the loop file since it's mounted ro at the shutdown. However, the sync,dirsync and commit=1 could help on power outages I suppose. | 11:16 |
| xivulon | but isn't host that has to sync automatically? the fact that the loopfile syncs to host does not help if host does not sync to disc, correct? | 11:17 |
| cking | xivulon: true - yep, it's clear I haven't thought that one through. | 11:18 |
| cking | xivulon: I suppose the outstanding questions are: can ntfs-3g be fixed in time to enable a ro remount, and if so, can one avoid NTFS corruption? | 11:20 |
| cking | xivulon: ..also, do the vm dirty tweaks do anything useful in reality? | 11:21 |
| xivulon | yes, that would be the best avenue, I had that bug open for quite some time... | 11:21 |
| xivulon | but did not bother too much because had zero bug reports about fs corruption... so far... | 11:21 |
| cking | xivulon: ..thirdly.. does the ntfs-3g support sync and commit=1 or are these only applicable to ext3? | 11:22 |
| xivulon | cking I know that in wubi 7.04 we did not have them we had more reports about people having fs corruption after hard reboot | 11:22 |
| xivulon | that is based on a completely subjective measure | 11:22 |
| cking | xivulon: ..yes but it's comforting to hear this. | 11:22 |
| xivulon | might be due to better user education also (added a few faqs) | 11:22 |
| xivulon | I would not know how to test that in an objective way | 11:23 |
| xivulon | for ntfs-3g we would need to ask szaka | 11:23 |
| xivulon | I know nothing about its internals | 11:23 |
| xivulon | but if you see #186117 that didn't go too far | 11:25 |
| cking | xivulon: that's the best path to take if he is available. | 11:25 |
| cking | xivulon: Meanwhile I will google around to see if there are any other ways to make sure the filesystem is flushed other than using the vm dirty hacks, | 11:26 |
| cking | ..one never knows if there is something better. | 11:27 |
| xivulon | cjwatson as plan b couldn't we still try to go for /sbin/reboot on ramdisk (but leaving current behaviour whenver that is not strcilt needed)? | 11:30 |
| cjwatson | it's very risky, you need to copy over any libraries it needs as well; it needs /proc and /dev; and who knows what else you might have to play catch-up with | 11:35 |
| cjwatson | I have a suspicion changing ntfs-3g would be safer | 11:35 |
| xivulon | cking still other route might be to ensure that ntfs-3g does actually empy his cache whenever the sync command is issued. I think. | 11:35 |
| xivulon | if / is ro and synced properly, rebooting should not be too drastic even if /host is rw | 11:36 |
| cking | xivulon: an extra sync can only help | 11:36 |
| cking | xivulon: I recall that twiddle with (one of) the vm dirty options may also forces a sync. | 11:37 |
| xivulon | cking you might want to try to reproduce fs corruption with new initramfs + sysctl + umountroot, as per thread | 11:37 |
| xivulon | as per bug attachments... | 11:38 |
| cking | yep. Will do. | 11:38 |
| * cking need to reboot to try this.. rebooting .. | 11:38 | |
| xivulon | FS corruption of the host is probably far more important than the guest corruption. And for the latter I'd focus on journal loss. | 11:38 |
| cking | xivulon: NTFS + ntfs-3g's behaviour is not really well know in this scenario. That's my concern. I'd hate too see Wubi users hacked off because their NTFS is screwed up | 11:41 |
| cking | ..so sync sync sync and then a fixed ntfs-3g mount -o remount may be the best way forward. | 11:42 |
| cking | ..one can never sync enough. | 11:43 |
| cking | :-) | 11:43 |
| xivulon | only confort I can give you is that with almost 1 million downloads all the ntfs corruption claims were due to hard reboots. And I have no evidence that ntfs-3g makes things any worse | 11:43 |
| cking | 1 million(!!) | 11:43 |
| xivulon | since you would still risk fs corruption when hard rebooting | 11:43 |
| xivulon | I discussed that with szaka more than once, and he always asserted that the chances of fs corruption are not made any worse by the use of ntfs-3g | 11:46 |
| xivulon | yep we are close to a million | 11:47 |
| xivulon | but of course now that wubi is official, host corruption would make very bad press... | 11:48 |
| cking | cking: rebooting .. | 11:55 |
| === Lure_ is now known as Lure | ||
| xivulon | lamont: I did do some basic tests yesterday for #206113 and commented on the bug let me know if you need anything else | 12:36 |
| lamont | my most recent dist-upgrade (-15.27 et al) killed sound... | 13:30 |
| amitk | lamont: does it also lead to a long boot time? | 13:35 |
| lamont | dunno | 13:35 |
| lamont | I wasn't watching... | 13:35 |
| lamont | and actually, I think it's related to session management, not to the kernel upgrade... | 13:35 |
| amitk | lamont: hmm.. how so? | 13:36 |
| lamont | I think I saw this before, now I just need to remember how I got told to fix it... | 13:36 |
| lamont | [ 54.214217] iTCO_wdt: Found a ICH5 or ICH5R TCO device (Version=1, TCOBASE=0xf860) | 13:40 |
| lamont | not seeing where I figured it out before, istr it was simply muted hard somewhere | 13:41 |
| * lamont afk for about 15 min | 13:41 | |
| lamont | amitk: so I take back what I said... let's blame the kernel for now... debugging ideas? | 14:12 |
| amitk | lamont: sound-applet reports no mixers? | 14:17 |
| xivulon | lamont, in case you missed it, did the tests you asked, see comment in 206113 | 14:18 |
| lamont | xivulon: yeah - thanks | 14:18 |
| xivulon | let me know if you need anything else | 14:18 |
| lamont | sure | 14:18 |
| lamont | amitk: bringing the system fully current to now and rebooting (new lrm), and then I think I'll need something more basic in the way of instructions... | 14:19 |
| * lamont iz sound neub | 14:19 | |
| lamont | amitk: anything I should tweak before I reboot | 14:28 |
| lamont | ? | 14:28 |
| lamont | Open Volume Control --> No volume control GStreamer plugins and/or devices found | 14:28 |
| amitk | lamont: just note if you reboot takes longer than usual | 14:31 |
| pwnguin | is -16 known to not boot? i cant find a report on it | 14:32 |
| rtg | pwnguin: on what? -16 is still not widely distributed as meta was just uploaded a few minutes ago. | 14:33 |
| pwnguin | ah | 14:33 |
| pwnguin | on my laptop, toshiba tecra m7. -generic | 14:34 |
| rtg | pwnguin: is this a regression? | 14:34 |
| pwnguin | yea | 14:34 |
| pwnguin | on the other hand, i dont have -meta | 14:34 |
| rtg | from -15 to -16? | 14:34 |
| pwnguin | yep | 14:34 |
| pwnguin | im on -15 right now | 14:34 |
| rtg | pwnguin: meta won't affect the boot. | 14:34 |
| pwnguin | rtg: i'd feel better about not missing part of the package with meta though | 14:35 |
| rtg | pwnguin: at what point in the boot process does it stop? | 14:35 |
| pwnguin | after turning off the graphical boot, hardware detection is the last message | 14:35 |
| pwnguin | i booted into recovery mode | 14:36 |
| pwnguin | and | 14:36 |
| pwnguin | the last two modules giving messages were iwl and cs | 14:36 |
| amitk | pwnguin, wait for a few minutes | 14:36 |
| amitk | it should continue booting | 14:36 |
| lamont | unsurprisingly, that didn't fix either of my issues | 14:36 |
| amitk | rtg: I see this too, I was woring on Classmate when I hit this | 14:36 |
| pwnguin | a few minutes? | 14:37 |
| pwnguin | thats a hell of a timeout ;) | 14:37 |
| amitk | pwnguin: I am trying to determine if you are seeing the same problem as me ;) | 14:37 |
| pwnguin | well | 14:37 |
| pwnguin | lemme reboot it i guess | 14:37 |
| rtg | amitk: everything since -15 has been custom binary, except for the mmc timeout. | 14:37 |
| pwnguin | heh | 14:37 |
| pwnguin | the mmc timeout | 14:38 |
| pwnguin | interesting; i upgraded because i wanted to test that | 14:38 |
| amitk | rtg: yeah.. I saw the changelog, and even the mmc timeout was 10ms, not 2 minutes | 14:38 |
| rtg | better go through the git log and make sure. | 14:38 |
| smb_tp | It is if it was 2ms before and not 2min | 14:38 |
| rtg | brb, rebooting after upgrade. | 14:39 |
| smb_tp | It was just a one liner changing mmc_delay from 2 to 10 | 14:39 |
| pwnguin | its supposed to be ms | 14:39 |
| pwnguin | it could be seconds | 14:39 |
| pwnguin | i never found that particular function | 14:39 |
| smb_tp | It is an inline function in one of the headers | 14:40 |
| amitk | core.h:static inline void mmc_delay(unsigned int ms) | 14:40 |
| amitk | pwnguin: can you confirm that the boot contineus after a few minutes? albeit w/o sound | 14:41 |
| pwnguin | on a related note, the sdhci developer's asked me to retry with MMC_DEBUG | 14:41 |
| pwnguin | amitk: not yet | 14:41 |
| pwnguin | give it a minute or so | 14:41 |
| amitk | pwnguin: just wait a few more please, that'll tell me that it is reproducible behaviour | 14:42 |
| amitk | pwnguin: What does Alt+F1 show? | 14:43 |
| pwnguin | doh | 14:43 |
| pwnguin | nothing much | 14:43 |
| amitk | F2? | 14:43 |
| amitk | I forget which one it is | 14:43 |
| pwnguin | kinit: no resume, doing normal boot | 14:43 |
| lamont | 8 | 14:43 |
| pwnguin | loading manual drivers | 14:43 |
| pwnguin | i forgot to set verbose | 14:43 |
| amitk | pwnguin: care to disable "quiet splash" in the kernel cmdline on the next boot? | 14:44 |
| pwnguin | indeed | 14:44 |
| amitk | thanks | 14:44 |
| amitk | hmm. now to see what changed in lum | 14:45 |
| lamont | amitk: my boot seems to proceed at normal-ish pace | 14:45 |
| pwnguin | lets see. theres hda_codec at 30 saying it cant find my audio. iwl at 31 saying there's 11 tunable channels for bg, 13 for a, and several I/O port probes for module cs | 14:46 |
| amitk | rtg: 607ab6f78fa5d51b4dab72d218455a858c499c6f in lum | 14:46 |
| pwnguin | if you want logs, im afraid i dont have a serial port =( | 14:47 |
| amitk | rtg: smb_tp: that commit looks like it will affect every sound driver | 14:47 |
| rtg | amitk: is that the culprit? | 14:47 |
| pwnguin | huzah | 14:48 |
| pwnguin | fail | 14:48 |
| amitk | rtg: I am going to revert and try on the classmate | 14:48 |
| rtg | amitk: just rename snd_core to something, then try. | 14:49 |
| pwnguin | amitk: after 2 minutes of no activity, it wrote some new text | 14:49 |
| pwnguin | it seems to still be stuck though | 14:50 |
| amitk | pwnguin: I'll bet it'll boot eventually :) | 14:50 |
| smb_tp | Hm, might be bad if register all will eventually call register... | 14:52 |
| pwnguin | heh | 14:52 |
| pwnguin | well, it doesn't seem to be spinning | 14:52 |
| amitk | rtg: crap.. just realised soundcore.ko comes from kernel, not ubuntu directory in /lib/modules :) | 14:52 |
| rtg | amitk: I was just looking to see where that file gets compiled. | 14:53 |
| amitk | rtg: that seems to improve things a lot | 14:54 |
| amitk | I'm going to revert the commit if you have no objections | 14:54 |
| rtg | amitk: can tyou rebuild lum with that patch reverted? | 14:55 |
| amitk | rtg: yeah.. doing that now | 14:55 |
| xivulon | cking in your tests did you try mounting /host with sync & co? | 14:55 |
| rtg | amitk: removing soundcore indicates it is the sound sub-system, but isn't proof positive. | 14:55 |
| xivulon | would it help to have 1 sec sleep before rebooting? | 14:56 |
| cking | xivulon: I couldn't see to create any filesystem corruptions whatsoever. | 14:58 |
| rtg | amitk: I started a new release in LUM | 14:58 |
| cking | xivulon: what is interesting is looking at /proc/vmstat | grep dirty | 14:58 |
| amitk | rtg: I've been seeing this since morning, but thought it was due to my usb patch for classmate suspend | 14:59 |
| cking | ..even with the agressive vm dirty tweaks the data is not getting written back that quickly | 14:59 |
| cking | ..one can see the writes by doing a bit of an ugly hack: sudo echo 1 > /proc/sys/vm/block_dump and looking at dmesg | 15:00 |
| amitk | pwnguin: you are running -15? | 15:00 |
| pwnguin | no | 15:00 |
| pwnguin | -16 | 15:01 |
| amitk | you compiled yourself? | 15:01 |
| pwnguin | nope =( | 15:01 |
| cking | xivulon: ..even with the most aggressive vm dirty settings one can observe writes being flushed a few seconds after the initial write... | 15:01 |
| pwnguin | i noticed -16 in the repos | 15:02 |
| amitk | rtg: ^^ | 15:02 |
| cking | xivulon: ..which could explain why some users are seeing corruptions even when we are forcing writebacks to occur as soon as possible. | 15:02 |
| rtg | amitk: I saw that. | 15:02 |
| cking | xivulon: ..because ASAP is not really that ASAP :-( | 15:02 |
| xivulon | hmm | 15:02 |
| rtg | pwnguin: do you also have -16 LUM installed? | 15:02 |
| xivulon | is that an ntfs-3g / fuse implementation issue? | 15:03 |
| amitk | I only see -16 LRM, no LUM or kernel | 15:03 |
| xivulon | cking what is your suggestion based on that? | 15:03 |
| pwnguin | well my mirror wins i guess | 15:03 |
| amitk | ohh and I see -16 linux-libc-dev | 15:03 |
| cking | xivulon: no. I initially thought it was all the layering in the ntfs-3g, fuse, loopback etc.. but one can observe this on a normally mounted filesystem. | 15:03 |
| smb_tp | amitk: Got that installed already | 15:04 |
| xivulon | when you say "couldn't see to create any filesystem corruptions whatsoever" do you mean you couldn't create corruptions or that you were simply not testing that | 15:04 |
| xivulon | so it's a kernel issue... | 15:04 |
| cking | xivulon: so it appears what the kernel documentation says and what is actually happening differ. | 15:04 |
| xivulon | not to pleased to hear that | 15:05 |
| cking | xivulon: as for the corruptions: I hammered the system with loads of creat's and unlinks and forced a reboot and everything was OK... | 15:05 |
| amitk | smb_tp: no sideeffects? | 15:05 |
| cking | xivulon: and also I repeated this several times and pulled the plug and got the normal fsck'ing fixes but I did not get any major failures | 15:06 |
| xivulon | cking that is in line with lack of reports on the matter. was this with the new initramfs / umountroot or in a plain vanilla case? | 15:06 |
| cking | xivulon: it was using the new scripts from the bug report | 15:06 |
| smb_tp | amitk: None I noted, but I guess this only affects programs comiled on that host. and I didn't compile any user-space | 15:07 |
| xivulon | well that is good news | 15:07 |
| xivulon | for once... | 15:07 |
| amitk | rebooting now.... | 15:07 |
| cking | xivulon: I left some notes on the bug report so one can see what I mean about the write backs being a little bit too lazy for my liking | 15:07 |
| xivulon | could it be that the mount options (sync & co) interfere with sysctl? | 15:08 |
| cking | xivulon: no. when I saw the less than perfect performance I tried it on a vanilla configuration to do a sanity check - i.e. no insane sync,dirsync,commit=1 flags. | 15:09 |
| xivulon | cking: would you suggest we keep mount options and/or sysctl settings? | 15:09 |
| cking | ..and I saw the same "problem". We are probably seeing the pdflush pushing out all it can before it gets rescheduled or something. I need to shove a whole load of debug in to see why it is a little less aggressive than expecyed | 15:10 |
| xivulon | so I guess you'll need some more time for the tests then we can reassess | 15:11 |
| xivulon | I would not think though that in the light of what you say the new initrd/umountroot should make much difference | 15:11 |
| cking | xivulon: well, closer inspection shows that the mount options are ignored by ntfs - so we just fall back to the sysctl's. | 15:11 |
| xivulon | since /host is still not remounted ro (at least in my tests) | 15:11 |
| cking | xivulon: agreed | 15:12 |
| cking | xivulon: I basically need to figure out why pdflush is not being totally true to the vm dirty knobs | 15:13 |
| amitk | rtg: revert works and sound is back | 15:13 |
| xivulon | sure, keep in mind that we'll need to do a feature freeze exception for each change, if something is not strictly necesseray (proven to be so) we should skip it | 15:13 |
| amitk | rtg: I've pushed the revert to lum | 15:13 |
| xivulon | that applies to initrd, sysctl and umountroot | 15:13 |
| cking | xivulon: yep. Well I think the real issue is that we want to flush blocks out asap and I need to figure out why the pdflush does not quite match the behaviour as described on the lid | 15:15 |
| cking | ^on the lid^in the docs^ | 15:15 |
| cking | ..and then I'm a little worried about tinkering with the pdflush daemon this late in a code freeze :-( | 15:15 |
| cking | ..but it could be something obvious once I've got my head around it. | 15:16 |
| cking | xivulon: any ideas on anything else we could do? | 15:17 |
| xivulon | not really | 15:17 |
| cking | xivulon: OK I investigate pdflush and the vm dirty knobs | 15:21 |
| cking | s/I/I will/ | 15:22 |
| xivulon | cking, maybe doublecheck whether initramfs/umountroot make any difference | 15:36 |
| cking | xivulon: I think most productive thing is to see if we can get pdflush to really do aggressive writebacks to limit loopbacke'd fs corruption | 15:38 |
| cking | xivulon: I hope it is something obvious | 15:39 |
| xivulon | agree | 15:40 |
| xivulon | by the way, wouldn't something like that be relevant also for vm? | 15:41 |
| xivulon | that too is a nested fs and hence subject to the same vulnerabilities | 15:43 |
| xivulon | I am surprised I am the only one running into this | 15:43 |
| xivulon | at least for the power-loss part (normal reboot is very different of course) | 15:51 |
| rtg | amitk: I verified the cx88 revert. it definitely makes a difference. | 16:20 |
| amitk | rtg: half the patch was mutexes, it had to ;) | 16:21 |
| rtg | amitk: I looked through it when I applied it. everything looked balanced, _and_ it came from upstream. | 16:21 |
| amitk | rtg: I guess it needs another part from upstream | 16:22 |
| rtg | amitk: could be. now I'm f\gonna have to figure out what the real cx88 crash was . | 16:23 |
| === jayc__ is now known as jayc_ | ||
| nxvl | i have just updated to -16 kernel and it hangs | 17:33 |
| rtg | nxvl: LUM is currently percolating with a fix. wait for linux-ubuntu-modules-2.6.24 16.22 | 17:34 |
| nxvl | ok | 17:34 |
| nxvl | so it was a know issue? | 17:34 |
| pwnguin | heh | 17:34 |
| pwnguin | only recently | 17:34 |
| rtg | nxvl: it became a known issue fairly quickly. | 17:35 |
| nxvl | yes of course it has no more than one day uploaded | 17:35 |
| nxvl | but if you already have what you need to fix it | 17:35 |
| nxvl | i'm ok | 17:35 |
| pwnguin | 16.22? | 17:35 |
| rtg | https://launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/2.6.24-16.22 | 17:35 |
| pwnguin | i have linux-headers at 16.30 | 17:36 |
| pwnguin | is that . not kept in sync? | 17:36 |
| rtg | pwnguin: The LUM package version is not related to the headers package version (except for the ABI number) | 17:37 |
| pwnguin | ok | 17:38 |
| nxvl | so, fix is released and we only need to wait until it reach the mirrors? | 17:39 |
| rtg | yep | 17:39 |
| pwnguin | not booting is a fairly high priority bug ;) | 17:39 |
| pwnguin | espcially when someone like amitk and reproduce it | 17:40 |
| nxvl | ok thanks! | 17:41 |
| nxvl | btw | 17:58 |
| nxvl | i forgot to report something else | 17:58 |
| nxvl | i hav a lenovo T61 | 17:58 |
| nxvl | with hotplug DVD-rom | 17:58 |
| nxvl | but when iunplug it the system hangs | 17:59 |
| mario_limonciell | rtg, i was thinking this morning, could you see to it that LBM is shipped as available on the DVD image to install? | 18:40 |
| mario_limonciell | in it's pool directory or similar | 18:40 |
| rtg | mario_limonciell: thats a question for cjwatson | 18:41 |
| mario_limonciell | okay i'll ask him | 18:42 |
| crimsun | rtg: are there are traces from the bootup problems (WRT #212960 in l-u-m -16)? | 18:52 |
| crimsun | amitk: ^ | 18:52 |
| crimsun | are there, sheesh. can't type. | 18:52 |
| rtg | crimsun: there don't seem to be. I'm looking at it now. Frank's original patch works, but the one Leann attached does not (it locks up) | 18:53 |
| rtg | crimsun: I'm trying to decide if it is really the root of the problem. | 18:53 |
| crimsun | rtg: I don't think it is, after closer inspection. | 18:54 |
| rtg | crimsun: can there really be that much list activity going on? Or is the use of mutexes just jostling the thread timing. | 18:54 |
| rtg | crimsun: as far as I can remember, PCI device discovery is single threaded, right? | 18:55 |
| === inuka_desk_ is now known as inuka_desk | ||
| crimsun | rtg: there shouldn't be much activity, and it is single-threaded IIRC. | 19:09 |
| rtg | crimsun: that's what I thought. I'm not sure Frank's analysis is correct (about the lists getting corrupted). | 19:15 |
| pepie34 | I can't catch an AP with my AR5008 madwifi card since the two last -14 and -15 kernel | 19:17 |
| pepie34 | still no problem with the -12 kernel and the same userland as the others new | 19:17 |
| mario_limonciell | hm what is creating the symlink between cpufreq directories on two core systems initially? | 19:22 |
| mario_limonciell | i had thought it'd be powernowd doing it, but I don't see evidence of that | 19:22 |
| pepie34 | any idea ? for the regression on madwifi | 19:23 |
| smb_tp | rtg: Hm, I might be stupid but in the report snd_card_register_all is called and later snd_device_new. If thats both in core, how should that work? | 19:23 |
| pepie34 | I should be more precise as it is a AR5XX8 chipset i had to use the madwifi svn and not the module in the restricted package | 19:24 |
| pepie34 | it works fine on feisty/gutsy and hardy since the 2.6.24-12 kernel | 19:24 |
| rtg | smb_tp: it clearly must work because its not a problem for everyone. I'm still looking at the cx88 driver. However, right now its lunch time. | 19:29 |
| rtg | pepie34: you are on your own 'cause I haven't pulled the madwifi branch that supports the AR5008. I've been waiting until they make it official. | 19:30 |
| smb_tp | rtg: Enjoy. I was just thinking of the same codepath with mutexes | 19:30 |
| pepie34 | rtg i just want to warn then that since the -14 the madwifi-svn does not work and you will get all the mac user really angry | 19:38 |
| lamont | amitk: so will this new kernel make my soundz werk>? | 19:50 |
| * pwnguin does a zomg sd works again dance | 20:24 | |
| pwnguin | rtg: thanks | 20:24 |
| infinity | lamont: You don't need sound. | 20:49 |
| lamont | infinity: do too | 20:49 |
| infinity | lamont: The kernel team disagrees. | 20:50 |
| rtg | lamont: we've gone out of our way to wreck only _your_ audio support. | 20:54 |
| lamont | rtg: I feel so much more productive without the noise-canceling music | 20:55 |
| rtg | lamont: I thought you had audio once upon a time? | 20:56 |
| sistpoty | hi, can someone please look at the FFe in bug #185634 and give a comment? thanks! | 21:23 |
| ubotu | Launchpad bug 185634 in ubuntu-meta "uvcvideo: iSight firmware loading does not work" [Medium,Confirmed] https://launchpad.net/bugs/185634 | 21:23 |
| tjaalton | is there something in -16 which broke nvidia from loading? bug 215778 | 23:56 |
| ubotu | Launchpad bug 215778 in linux-restricted-modules-2.6.24 "2.6.24-16.30 kernel update - nvidia: module license 'NVIDIA' taints kernel" [Undecided,Confirmed] https://launchpad.net/bugs/215778 | 23:56 |
| tjaalton | lrm debdiff looked good, so it shouldn't be due to the dh_strip fix | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!