| === mcasadevall is now known as NCommander | ||
| === RemoteVi1wer is now known as RemoteViewer | ||
| === tjaalton_ is now known as tjaalton | ||
| nikolam | Could someone comment on this bug? Seems that 2.6.24-21 on amd64 has a problem | 10:55 |
|---|---|---|
| nikolam | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/287416 | 10:55 |
| === asac__ is now known as asac | ||
| amitk | rtg: I already suggested splitting lbm into smaller parts but it is too late now. But IMO, we should do it for Jaunty | 13:22 |
| rtg | amitk: LBM isn't subject to SRU policies, so it may not be too late. There might be some package naming policies that get abused, but thats more a matter of getting exceptions granted. | 13:25 |
| amitk | rtg: cjwatson's words, not mine. Let me get him | 13:26 |
| rtg | amitk: there is no hurry. its not something I'm gonna do today. | 13:27 |
| amitk | rtg: lbm is in main and I was assured that that made things complicated | 13:28 |
| rtg | it probably does. | 13:28 |
| rtg | however, kernel packages are already special since they get new package names with every ABI. | 13:29 |
| cjwatson | amitk: so what's this about splitting up lbm? | 13:30 |
| rtg | cjwatson: I suggested splitting out compat-wireless as a way to mitigate regressions from other drivers. | 13:31 |
| cjwatson | I'm really concerned about messing around with packaging at this point | 13:32 |
| amitk | rtg: I was suggesting even finer grained, separate out ath5k from the rest | 13:32 |
| cjwatson | I'd rather not | 13:32 |
| rtg | nor would I | 13:32 |
| rtg | besides, right now compat-wireless is the only thing in LBM | 13:32 |
| cjwatson | right, and people will probably only have one of those chipsets | 13:33 |
| amitk | cjwatson: given that ath5k users are going to _depend_ on lbm, how else do we ensure that we don't regress lbm during the next 18 months. | 13:33 |
| rtg | well, LBM has been going through the -proposed cycle, just like other kernel packages. | 13:34 |
| cjwatson | it's going to suck somewhat for atheros users no matter what we do. A week ago I would have agreed with you, but now? I can't say I'm so sure | 13:35 |
| amitk | rtg: it is a question of QAing all of compat-wireless vs. just ath5k in -proposed | 13:37 |
| rtg | amitk: but ath5k doesn't exist in a vacuum. its intimately intertwined with the rest of the wireless stack. | 13:38 |
| amitk | rest of the stack, yes. Rest of the drivers, no. | 13:39 |
| rtg | amitk: as cjwatson pointed out, you don't have to worry about the rest of the drivers 'cause they won't get loaded anyway.. | 13:39 |
| amitk | rtg: so just remove in-kernel ath5k and do a best-effort on LBM? | 13:41 |
| rtg | amitk: thats pretty much my plan. | 13:41 |
| rtg | we are somewhat subject to upstream progress. | 13:42 |
| cjwatson | if you guys really think that splitting out a compat-wireless package from lbm is the only sane answer, then I'm willing to defer; you'll need to be really careful about the package structure, though, and it'll need a linux-meta update | 13:42 |
| amitk | rtg: do you forsee alsa or something else coming back into lbm? | 13:43 |
| rtg | cjwatson: I'm open to suggestions. Also, I don't think we need to do this before release. The current LBM is as good as it gets for awhile. | 13:43 |
| rtg | I don't see the need for ALSA at this point | 13:43 |
| cjwatson | rtg: we're going to have to document what people need to do at release time, and at the moment that's going to involve them installing LBM | 13:43 |
| cjwatson | rtg: so this is hard to change later - people will have LBM installed already and will upgrade it all at once | 13:44 |
| cjwatson | I mean, obviously in general I'm in favour of fewer things having to be changed before release now :) | 13:44 |
| amitk | rtg: besides users for whom in-kernel ath5k works now will complain much louder later | 13:45 |
| cjwatson | certainly if we're going to disable in-kernel ath5k then I think that needs to be done pre-release; it'll be almost impossible to QA after release | 13:46 |
| rtg | one of the drivering forces for LBM in the past has been because there was no other mechanism to get new HW support. now we have an alternative (ubuntu-next), so those folks that just gotta have support can always use that. Ubuntu-next kind of relieves to need to add a bunch of stuff to LBM. | 13:46 |
| rtg | I plan to upload a kernel today without ath5k support, if everyone is agreed. | 13:47 |
| cjwatson | ack | 13:47 |
| pgraner | rtg: the only that that should be in that kernel is the lack of 5k support | 13:47 |
| === shenki_ is now known as shenki | ||
| rtg | pgraner: can't parse your sentence. the only change? | 13:48 |
| pgraner | rtg: no other changes are allowed at this point, we have approval for just the disabling of ath5k... | 13:49 |
| rtg | pgraner: right. what'ya think I am? some profligate coder? | 13:49 |
| pgraner | rtg: just checking in the past we have had other things "slip" in due to them being committed in the tree. | 13:50 |
| rtg | amitk: so the mid-team plan is to go with LBM, so my job is to try not to break it with future updates, nor to add any devices that moight hose you up. correct? | 13:51 |
| rtg | pgraner: I'll make sure that doesn't happen this time. | 13:51 |
| * cjwatson appreciates it :) | 13:51 | |
| pgraner | rtg: thanks! love ya... mean it! | 13:52 |
| rtg | eew! | 13:52 |
| cjwatson | NURSE! BRAIN FLOSS | 13:52 |
| amitk | rtg: yes. But rest of the distro will also depend on lbm now. They might get to you before I do if you break lbm :-p | 13:52 |
| rtg | amitk: I'll just point them at ubuntu-next. its my bandaid for all HW enablement. | 13:53 |
| cjwatson | so bug 267295 and bug 283316 -> intrepid-updates? | 13:56 |
| cjwatson | if so, please adjust their milestones | 13:56 |
| amitk | rtg: please refer to bug 284354 when disabling in-kernel ath5k | 13:58 |
| amitk | rtg: madwifi + ath5k racing won't disappear with disabling in-kernel and installing lbm though | 13:59 |
| cjwatson | uh. I thought you said in #ubuntu-release that it would | 13:59 |
| amitk | cjwatson: on boot ath5k (lbm) will always win. But I am worried about suspend/resume case. | 14:01 |
| amitk | still thinking about it... | 14:01 |
| rtg | amitk: but its not a race. | 14:01 |
| * amitk goes off to do a few tests | 14:02 | |
| amitk | rtg: what is not a race? suspend/resume? | 14:02 |
| rtg | amitk: the loading sequence. ath5k only gets loaded after madwifi fails. | 14:03 |
| amitk | rtg: so madwifi fails gracefully is what you're saying? | 14:04 |
| rtg | amitk: I guess you could say that. It can't support the RF chip, so it bails out with an error. | 14:05 |
| rtg | amitk: I have ogra checking to make sure madwifi isn't loading when LBM is installed. | 14:14 |
| rtg | I remembered a bug that smb found in modprobe when 2 modules of different names claim the same PCI ID. | 14:14 |
| * amitk nods | 14:15 | |
| asac | rtg: ath9k issue with eventual patch: #278190 | 14:16 |
| smb_tp | rtg, As long as the driver bails out with an error this might be ok (if the hw isn't left in a strange state) | 14:16 |
| smb_tp | rtg, But err, yeah they claim the same id | 14:17 |
| smb_tp | rtg, So it is as long as depmod is not changed. Have you heard something from John Masters? | 14:18 |
| rtg | asac: this is a patch against the LBM stuff, right? | 14:19 |
| amitk | rtg: in-kernel module has precedence over lrm? | 14:19 |
| smb_tp | amitk, not ncessarily | 14:19 |
| rtg | amitk: no. its LBM, LRM, then kernel. | 14:19 |
| smb_tp | amitk, with same drivers (names) its defined in the search order of depmod.conf but for different names its random by dir creation order | 14:20 |
| * amitk swears at a ath5k oops | 14:23 | |
| asac | rtg: not sure. i have no big picture about which version are where. a user just pointed me to that patch ... and since i saw that its Linville i thought it might be good crack ;) | 14:28 |
| rtg | asac: its definitely good crack. I'll pick it up the next time I update LBM with a new compat-wireless tree. | 14:29 |
| rtg | I think I'll wait until after release before I go rocking the boat. amitk will have me by the throat if I break his samsung device :) | 14:30 |
| asac | rtg: isnt Q1 5k and this is about 9k? | 14:30 |
| rtg | asac: it sure is :) I'm in an ath5k rut. | 14:31 |
| asac | rtg: yeah. so, taking one step back from 5k, do you think that patch would be applicable for our 9k mainline driver? | 14:32 |
| asac | :) | 14:32 |
| amitk | rtg: just got an oops from ath5k on q1. Trying to get it out to a bug | 14:32 |
| asac | or lbm there too? | 14:32 |
| rtg | asac: probably, but its gonna be an SRU. | 14:33 |
| asac | rtg: sure. didnt ment to have that in final ;) | 14:33 |
| asac | rtg: its assigned to you ... do youwant me to do anything else? e.g. like adding intrepid? | 14:34 |
| rtg | asac: yep - add the Intrepid so it doesn;t get lost. | 14:34 |
| asac | (sorry to ask now, but otherwise it will just drop from my radar and i wont be able to help remind you :)) | 14:34 |
| asac | ok done ;) | 14:34 |
| asac | have fun with 5k then | 14:34 |
| Kano | hi, did you see the security update 2.6.27.3? | 14:42 |
| rtg | ugh, say it ain't so. | 14:44 |
| lool | Hey folks | 14:47 |
| NCommander | o_o; | 14:47 |
| NCommander | oh | 14:47 |
| NCommander | *ow | 14:47 |
| lool | amitk, rtg: I'd love to fix status/description of the ath5k / Q1U / madwifi / mobile bugs | 14:47 |
| lool | First, wifi currently works with madwifi on the Q1U, even if you don't change anything | 14:48 |
| lool | At least with WPA | 14:48 |
| amitk | lool: doesn't for me with WPA2 | 14:48 |
| lool | amitk reported that it doesn't work with WPA2, but it's better than using lbm (which is not possible to sustain) | 14:48 |
| lool | We will document ath5k in lbm as an alternative which is easy to install, but we can't install it by default | 14:49 |
| ogra | lool, WEP as well | 14:49 |
| lool | So WPA2 is broken with madwifi on Q1U; do we need to file / track this? I'm happy to have a bug for it, but we wont do anything about it in intrepid, we will use a newer ath5k which works in all cases in jaunty | 14:49 |
| lool | ogra: WEP broken? | 14:49 |
| ogra | working | 14:50 |
| lool | Ok | 14:50 |
| lool | Another thing which is broken with madwifi is suspend resumle | 14:50 |
| ogra | only if ath5k is present | 14:50 |
| amitk | lool: madwifi future is a don't care. So no point in tracking WPA2 with a bug | 14:50 |
| lool | There is no race with ath5k whatsoever; the module just plain don't like suspend/resume, even when ath5k isn't around | 14:50 |
| ogra | works fine if you blacklist | 14:50 |
| lool | amitk: Exactly, I think the same | 14:50 |
| lool | ogra: suspend/resume works for you? Not for me | 14:50 |
| ogra | hmm, let me test again | 14:51 |
| lool | I remove ath5k from module path | 14:51 |
| * ogra blacklists ath5k | 14:51 | |
| lool | rebooted after update-initramfs -u, and wifi would break over suspend/resume | 14:51 |
| lool | removing and reinserting the ath_* madwifi modules, and it would work again | 14:51 |
| lool | So on this second madwifi issue, is it worth filing a bug? Yes I think so | 14:51 |
| lool | We can help suspend/resume with madwifi for intrepid; it's old style remove the module before suspend, but will work | 14:52 |
| lool | Do we care for jaunty? No | 14:52 |
| lool | Is this critical? No | 14:52 |
| lool | Concerning the two ath5k and madwifi getting loaded; I understand why it happens, I think it's not good that we have to do this, but I don't have any magic wand to help it; it will effectively be fixed when a single driver supports all PCI ids and all their hardware | 14:53 |
| lool | I don't expect this will be fixed in intrepid, and intend to close the corresponding bug with "wontfix in intrepid and we don't care in jaunty" | 14:54 |
| lool | Finally, ath5k status in linux/linux-lpia: I didn't see ath5k working, rtg had issues with it and recommended removing it from linux/linux-lpia: I second that; it's high priority for intrepid, not critical I'd say but best to avoid half working wifi IMO; no idea how many affected people with working ath5k or half working | 14:55 |
| lool | We should recommend lbm or let these people try madwifi IMO | 14:55 |
| lool | Do I miss any issue? | 14:55 |
| lool | Oh yes, the madwifi wpasupplicant backend | 14:55 |
| ogra | lool, confirming, madwifi now asks for the passphrase after resume ... that used to work earlier | 14:55 |
| rtg | lool: I'm in the process if disabling ath5k in the kernel. | 14:56 |
| lool | That's completely irrelevant, this backend had issues and wasn't needed with some cards/madwifi versions; it's orthogonal, we can't do anything about it and don't care for either intrepid or jaunty | 14:56 |
| lool | rtg: Thanks; do you have a bug report for that? | 14:56 |
| lool | rtg: If not, copy pasting your test results which you mailed to devel would be fine as a reference point | 14:56 |
| rtg | lool: 284354 | 14:56 |
| lool | rtg: or just link the thread in the kernel changelog | 14:56 |
| lool | rtg: 284354 is about two drivers for same PCI id getting loaded | 14:57 |
| lool | It kind of became "Wifi debate on Q1U/mobile/ath5k/madwifi" though :-/ | 14:57 |
| rtg | lool: the issues are kind of related, but I'll make it clear in the changelog. | 14:57 |
| lool | rtg: Do you mind not using 284354? I can open you another bug if you like | 14:58 |
| lool | rtg: Or are you done already with the commits? | 14:58 |
| rtg | lool: still in progress. just lemme know when you've a new LP number. | 14:59 |
| lool | (rtg: I intend to wontfix the "two drivers for same PCI id" bug with rationale of my above monologue) | 14:59 |
| lool | rtg: Will open a new bug for you now | 14:59 |
| lool | rtg: 288148 assigned to you for the linux task | 15:03 |
| lool | amitk: Will you do the linux-lpia rebase dance for this bug? | 15:03 |
| amitk | lool: yes, I will rebase it. We should have it tomorrow. | 15:06 |
| amitk | I'll wait for rtg to get done with his changes | 15:07 |
| rtg | amitk: I think I'll test build before uploading. I'd hate to get reamed by Steve. | 15:08 |
| amitk | rtg: wise course of action | 15:10 |
| lool | amitk: assigning you to the linux-lpia task then | 15:10 |
| rtg | amitk: I've pushed everything except the final changelog commit. | 15:11 |
| lool | rtg: When I said 'this is completely irrelevant' earlier, I was speaking of the wpasupplicant madwifi backend BTW, not of what you said | 15:13 |
| rtg | lool: I assumed that :) | 15:14 |
| lool | rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/275423 sounds like what you reported in terms of wifi speed of ath5k | 15:15 |
| lool | Too issues in the same bug unfortunately | 15:15 |
| lool | https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/275692 is the suspend/resume bug I mentionned earlier | 15:16 |
| lool | ogra: " | 15:16 |
| lool | ogra: "I added a line 'SUSPEND_MODULES="ath_pci"' to /etc/pm/config.d/01-modules and now resuming works. | 15:16 |
| rtg | lool: almost all ath5k issues are related to ANI failures, suspend/resume notwithstanding. | 15:16 |
| lool | rtg: This one mentions poor network performance which reminded me of your own testing | 15:17 |
| ogra | lool, right | 15:17 |
| ogra | lool, though we wouldnt use /etc/pm/config.d from a package | 15:17 |
| lool | ogra: I'm sure you're bored with all the sleep you've got; care to prepare an intrepid fix? | 15:17 |
| lool | Yeah of course | 15:17 |
| ogra | wher should that sit in ? | 15:18 |
| ogra | which package ? | 15:18 |
| lool | ogra: Good question | 15:18 |
| ogra | effectively it shuld be in lrm :P | 15:18 |
| lool | I wonder whether it makes sense in lrm | 15:18 |
| lool | amitk, rtg: opinion? | 15:19 |
| ogra | but thats something i dont really like to touch as non kernel guy | 15:19 |
| ogra | i can put it in pm-utils as well, but it would be moot for 90% of users | 15:19 |
| lool | ogra: Could you test it? In terms of where to install what file with which contents | 15:20 |
| lool | No, please not in pm-utils | 15:20 |
| lool | We're going to forget it in there, and it will make suspend/resume slower for everybody | 15:20 |
| rtg | lool: I can't figure out what you want an opinion on? adding madwifi to pm-utils for suspend/resume? | 15:21 |
| lool | rtg: Yeah | 15:21 |
| lool | rtg: Adding a hint to modprobe -r ath_pci on suspend/resume in lrm | 15:21 |
| ogra | /usr/lib/pm-utils/defaults would be one place to put it | 15:21 |
| lool | ogra: I'd have thought /usr/lib/pm-utils/sleep.d/nnmadwifi | 15:23 |
| lool | SUSPEND_MODULES="$SUSPEND_MODULES ath_pci" | 15:23 |
| lool | nn < 50 I'd guess | 15:24 |
| ogra | yeah | 15:24 |
| rtg | lool: thats the way I've done it in the past. | 15:24 |
| ogra | i'D suggest 10 | 15:24 |
| lool | rtg: Someone preparing a lrm upload in the kernel team currently could include this fix? | 15:24 |
| amitk | lool: wouldn't that start a precendent of different packages hacking into pm-utils configs | 15:25 |
| lool | amitk: I think it's the intention of this dir of modules to be extensible in this way | 15:25 |
| ogra | amitk, thats what the xxxx.d dirs are for | 15:25 |
| rtg | lool: that makes LRM dependent on pm-utils | 15:26 |
| Kano | rtg: why dont you blacklist ath_pci for testing? | 15:26 |
| Kano | my card can connect with both drivers | 15:26 |
| lool | rtg: Why? | 15:26 |
| lool | rtg: lrm just provides a pm-utils extension which is picked up if installed | 15:26 |
| Kano | and the standard madwifi branch is even worse than ath_pci,because only the madwifi-hal branch or ath5k can use ar2007 | 15:27 |
| lool | rtg: Or are you suggesting you can fix this in the kernel module directly? | 15:27 |
| amitk | lool: ogra: are you guys getting stable wireless connections on the Q1? I am oopsing in 5 minutes today | 15:27 |
| ogra | i do | 15:27 |
| lool | amitk: I do, but then I didn't really try high traffic | 15:27 |
| rtg | lool: no, I was just considering whether LRM needed to be install time dependent on pm-utils. | 15:27 |
| lool | I did do some ubuntu updates thopugh | 15:27 |
| lool | rtg: I don't think this is needed, no | 15:28 |
| rtg | lool: ok | 15:28 |
| * amitk downloads a new mobile image | 15:28 | |
| Kano | rtg: ar2007 is for example on eee pc | 15:28 |
| lool | rtg: Ideally, we would fix the relevant layer (kernel module) and have this quirk apply for all possible suspend/resume scenarii, but I'm not competent enough to suggest something lower level than pm-utils | 15:28 |
| rtg | Kano: I had no luck with sustained transfers using ath5k. I also talked to Luis and he agreed that 2.6.27 ath5k isn't ready for prime time. | 15:28 |
| lool | pm-utils is what is used on desktops and mobile flavours, it's good enough for us though | 15:29 |
| Kano | rtg: but standard madwifi is useless for lots of mobile devices | 15:29 |
| lool | I guess it wont work with echo mem >/sys/power/state though :-/ | 15:29 |
| rtg | Kano: you're right, which is why we're suggesting LBM with the compat-wireless stack. | 15:29 |
| lool | ogra: If you have your Q1U booted, can you try the proposed SUSPEND_MODULES and confirm file pathname and contents? | 15:30 |
| lool | ogra: i'm not 100% sure the files are sourced, they might be exec'ed | 15:31 |
| lool | ogra: In which case, you need to implement it differently | 15:31 |
| lool | Or in a different place | 15:31 |
| ogra | doing now | 15:32 |
| lool | ogra: You might want to test what happens when SUSPEND_MODULES is set in the main config | 15:34 |
| ogra | lool, i'm pretty sure they need to be executable | 15:35 |
| ogra | so #!/bin/sh | 15:35 |
| lool | ogra: Then what I proposed isn't enough | 15:36 |
| lool | ogra: I'm not sure how do you keep state on whether ath_pci needs to be reloaded or not | 15:36 |
| ogra | needs an export | 15:36 |
| ogra | SUSPEND_MODULES is ok, thats the way to do it | 15:36 |
| jdong | anyone here familiar with how to kick the macbooks into AHCI mode the 'right way'? | 15:38 |
| jdong | they seem to boot in piix compatibility mode, but if you forcibly talk to it in AHCI it responds | 15:39 |
| jdong | I'm wondering if there's a more correct way to kick it into AHCI mode, as AFAIK no other Intel AHCI controller behaves in this way | 15:39 |
| ogra | hmm, the script seems not to work :/ | 15:40 |
| lool | ogra: Make sure your 10something isn't parsed after the system's config where one might have set SUSPEND_MODULES="foo" (overwriting your addition of ath_pci) | 15:41 |
| mjg59 | jdong: There is no right way | 15:41 |
| mjg59 | And several others will behave in the same way | 15:41 |
| jdong | mjg59: hmm is there any way that we can get macbook users AHCI mode out of the box then? | 15:41 |
| mjg59 | Currently? No. | 15:41 |
| jdong | mjg59: it seems like SATA link power management shaves off almost a watt on idle | 15:41 |
| mjg59 | Bug Apple | 15:42 |
| ogra | lool, it gets reloaded if put in the default file but doesnt attempt a connect | 15:42 |
| mjg59 | THeir firmware sets it up to be in piix mode | 15:42 |
| jdong | understood. | 15:42 |
| jdong | so there's no way to kick it back to AHCI mode from our side | 15:42 |
| ogra | lool, oh, sorry, my fault, there was a popunder from a former try | 15:42 |
| ogra | it was waiting on passphrase confirmation | 15:42 |
| jdong | mjg59: thanks for your insight :) I guess I'll just continue rolling my own hacked kernels then | 15:44 |
| ogra | lool, i by looking at pm-functions fear we have to resort to /etc unless we want it in the pm-utils package | 15:45 |
| Kano | rtg: btw. at least 2/5 pci ids from ath9k are enabled in ath_pci | 15:46 |
| rtg | Kano: thats right, I seem to remember a couple of AR5007 chips supported by ath9k. | 15:53 |
| lool | ogra: Uh? | 15:53 |
| ogra | lool, pm-functions only respects /etc/pm/config.d/ or /usr/lib/pm-utils/defaults for setting global vars | 15:55 |
| lool | amitk: laptop-mode-tools is an example of extending /usr/lib/pm-utils/sleep.d BTW | 15:56 |
| ogra | you can use /usr/lib/pm-utils/sleep.d/XXblah but it will be a rather complex script | 15:56 |
| lool | ogra: My problem is mostly with saving the state of whether ath_pci was already loaded or not | 15:56 |
| ogra | doesnt matter | 15:56 |
| lool | ogra: I don't think it needs to be large | 15:57 |
| lool | ogra: Doesn't matter? | 15:57 |
| ogra | the new ath5k from lbm will override it anyway | 15:57 |
| lool | ogra: I don't want ath_pci to be modprobed if people are using ath5k or nothing | 15:57 |
| ogra | no matter if its loaded or not | 15:57 |
| lool | ??? | 15:57 |
| ogra | i just tested that before with rtg | 15:57 |
| ogra | ath5k will claim the device and manage it, no matter if ath_pci is loaded | 15:58 |
| ogra | with the lbm one | 15:58 |
| ogra | with the in-kernel one its exactly the other way round | 15:58 |
| lool | I'm not sure you're looking at the same bug that I am | 15:59 |
| lool | I'm speaking of people having lrm installed, using madwifi | 15:59 |
| lool | These wont get wifi on resume | 15:59 |
| ogra | right | 15:59 |
| ogra | right | 15:59 |
| lool | I'm looking at providing a pm-utils file to have the module modprobe -red and modprobed on suspend/resume | 15:59 |
| ogra | adding ath_pci to SUSPEND_MODULES solves this | 15:59 |
| ogra | we have two options for that, putting a one liner in /etc/pm/config.d/ or a complex script that executes functions on suspend resume into /usr/lib/pm-utils/sleep.d/XXblah | 16:00 |
| lool | ogra: Will the module be loaded on resume if it wasn't loaded? | 16:00 |
| ogra | yes | 16:01 |
| lool | That's not good | 16:01 |
| ogra | oh, wait, you mean if it was never loaded ? | 16:01 |
| ogra | why should it be loaded on resume if the kernel didnt load it on boot | 16:01 |
| lool | ogra: Actually, it wont be reloaded if you use SUSPEND_RESUME | 16:01 |
| ogra | SUSPEND_MODULES you mean | 16:02 |
| lool | _rmmod() touches a file saying whether it was modprobe -red successfully or not | 16:02 |
| lool | Err SUSPEND_MODULES right | 16:02 |
| ogra | it gets reloaded here | 16:02 |
| lool | ogra: Could you offer a /etc/pm/config.d/ file in the bug for the kernel team to add to lrm? | 16:02 |
| ogra | but why shouldnt it have been loaded by the kernel before, i dont understand | 16:02 |
| lool | ogra: it gets reloaded when it wasn't loaded? | 16:03 |
| ogra | do you have an example when exactly " it wasn't loaded" could happen ? | 16:03 |
| lool | ogra: People with lrm installed but not having madwifi hardware | 16:03 |
| lool | atheros hw | 16:03 |
| lool | Or people using lbm's ath5k | 16:04 |
| ogra | ah, well, modbprobe would surely do the same as on boot | 16:04 |
| lool | (I know the correct module will be used, but we shouldn't load ath_pci nevertheless) | 16:04 |
| lool | ogra: It wont | 16:04 |
| ogra | looking for the pci id and load or not load it depending on the finding | 16:04 |
| lool | But pm-utils doesn't look at PCI ids... | 16:04 |
| ogra | pm-utils is dumb | 16:05 |
| ogra | it calls modprobe | 16:05 |
| lool | Yes, not on PCI ids | 16:05 |
| ogra | no, it just calls modprobe | 16:05 |
| lool | Not only | 16:05 |
| ogra | if there is no atheros HW modprobe will silently die | 16:05 |
| lool | It also saves whether a modprobe -r failed or not | 16:05 |
| lool | if it succeeded, it will reload the module | 16:06 |
| ogra | right | 16:06 |
| ogra | still, if there is no atheros HW it wont do any harm | 16:06 |
| ogra | if lbm is there, ath5k will in any case override madwifi | 16:06 |
| * lool pfff | 16:06 | |
| ogra | we shipped lrm for years | 16:07 |
| ogra | madwifi was always included | 16:07 |
| ogra | why shoulld it suddenly behave harmful if there is no atheros HW | 16:07 |
| ogra | there are only two intresting scenarios imho | 16:08 |
| ogra | ath_pci being blacklisted ... lbm being installed | 16:08 |
| ogra | for the first i added a fix recently to pm-utils to not probe blacklisted modules | 16:08 |
| ogra | for the second it was confirmed today with rtg that lbm overrides madwifi in any case | 16:09 |
| ogra | so i dont see any issue here | 16:09 |
| lool | I should have tested myself, would have been quicker: echo "SUSPEND_MODULES=loop" > /etc/pm/config.d/loop | 16:12 |
| lool | Suspend+resume, loop isn't loaded | 16:12 |
| lool | I'll verify it works fine with ath_pci when I'm done reverting to non-lbm | 16:12 |
| * ogra still doesnt get the issue, modprobe would care | 16:14 | |
| ogra | lool, info added to the bug | 16:21 |
| ogra | erm ... did i add to the right bug ? | 16:22 |
| ogra | you closed all tasks | 16:22 |
| lool | Ok, verified the proposed fix | 16:26 |
| lool | ogra: https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/275692 I think I mentionned this earlier | 16:27 |
| ogra | ah | 16:28 |
| * ogra copy pastes | 16:28 | |
| lool | rtg: So I confirmed the fix; is it you who's preparing the last lrm upload before release? Could you add a /etc/pm/config.d file as described in this bug and close it? | 16:28 |
| rtg | lool: ok, on conf call. will deal afterwards | 16:29 |
| lool | rtg: Thanks | 16:32 |
| lool | rtg: After discussion with cjwatson, we will defer #275692 to a SRU as there's too much work to do before final already | 16:46 |
| lool | rtg: Will repoke you about merging it after final :-) | 16:46 |
| rtg | lool: agreed | 16:48 |
| === amitk is now known as amitk-afk | ||
| === ogra_ is now known as ogra | ||
| === thegodfather is now known as fabbione | ||
| elmo | what's responsible for telling iwl3945 that I'm in the UK and want the full spectrum of wireless channels? | 22:48 |
| elmo | or more relevantly; is it the kernel's problem? | 22:49 |
| elmo | (it's regressed for me in intrepid) | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!