[00:10] <JanC> adinc: I have a laptop that uses iwl3945 fine, so I wonder what your issue is exactly...
[00:13] <JanC> (what your issue is exactly caused by)
[00:20] <adinc> JanC: it is not only my issue
[00:20] <JanC> yeah, I saw the bug
[00:20] <adinc> the problem is described in the bug 185470
[00:20] <ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
[00:20] <adinc> JanC: so i wonder how this device works for you
[00:20] <JanC> but it works fine for me, so I guess the driver can work properly
[00:20] <adinc> that would be great
[00:21] <JanC> maybe it's just not working fine on some variations or combinatiosn with other hardware?
[00:21] <adinc> but unfortunately it doesn't here, i'm just downlaoding the kernel sources in order to make use of the bugfix from mohamed abbas
[00:22] <adinc> JanC: possible, but how should we figure this out, i'm not very well involved into driver programming for wireless devices. we wouldneed to do a lot of work, theonly ones who could do this actually are the developers
[00:22] <adinc> of this driver
[00:23] <adinc> cool the kernel now supports hsdpa
[00:23] <JanC> I guess the Intel developers, with some help of the Ubuntu kernel developers, would be the best people to investigate  ;)
[00:24] <adinc> yes, you are right, but as i can see there is already work done.
[00:25] <JanC> might be, looking at that comment
[00:25] <adinc> JanC: which kernel version are you running?
[00:25] <adinc> comment 25
[00:26] <JanC> latest hardy kernel available this afternoon (8 hours ago or so)
[00:26] <JanC> maybe 10h
[00:26] <adinc> there hasn't beeen any kernel changes in hardy, was there?
[00:26] <adinc> if you do a uname -a, what do you get?
[00:26] <JanC> I haven't checked in the last 8-12h  ;)
[00:26] <JanC> let's check on my laptop
[00:30] <JanC> kernel build based on linux-meta 2.6.24.12.13, which seems to be the last (according to packages.ubuntu.com)
[00:31] <adinc> i've 2.6.24-12-generic
[00:32] <JanC> yeah, that's what uname says
[00:32] <adinc> so your kernel is 2.6.24-12-generic?
[00:32] <JanC> uhu
[00:33] <adinc> i suppose uhu means yes
[00:33] <JanC> yes ツ
[00:34] <adinc> i don't know the numbering you showed above, there must be a mistake in your kernel versioning scheme
[00:38] <JanC> my laptop seems to have a 3945 "rev 2" wireless with PCI-ID 8086:4222 
[00:39] <JanC> the version number I showed is for the kernel meta package--it shows the internal build number used by the Ubuntu kernel developers I suppose
[00:40] <adinc> http://packages.ubuntu.com/hardy/allpackages
[00:40] <adinc> here are the kernel packages listed
[00:42] <JanC> linux-meta is the source package (it's called "meta" because it builds several different kernals)
[00:42] <JanC> see http://packages.ubuntu.com/hardy/linux-generic and then in the bar at the right
[00:43] <JanC> anyway, it's just an internal Ubuntu kernel version number
[00:43] <adinc> i see
[00:44] <adinc> is there a way to see when the latest kernel was published for ubuntu hardy?
[00:45] <JanC> http://packages.ubuntu.com/source/hardy/linux-meta should be pretty up-to-date
[00:45] <JanC> otherwise, if you update hardy from the main servers, it should be obvious  :-)
[00:47] <adinc> a dist-upgrade i suppose would download the latest kernel build, wouldn't it
[00:47] <JanC> yes, it should
[00:49] <JanC> what device ID does 'lspci -nn' give for your wireless?
[00:49] <JanC> or 'lspci -n' maybe
[00:50] <adinc> 8086:4222
[00:50] <JanC> hm, so it's supposed to be exactly the same hardware
[00:52] <adinc> yes
[00:54] <adinc> JanC: have you got a smp kernel?
[00:54] <adinc> somehow a dual core or more than one cpu?
[00:55] <JanC> the -generic kernel is SMP  ツ
[00:55] <JanC> and I have a Core Duo, so it's actually using SMP too
[00:56] <JanC> fro mthe upstream bug report: """Guess what... I enabled the iwl3945 debugging (and disabled CGROUPS to get system back to usable state), and problem is no longer reproducible easily."""
[00:56] <JanC> sounds like a fun bug to "debug" that way  ;-)
[00:57] <adinc> i'm compiling the kernel now.
[00:57] <adinc> does he mean debugging enabled by adding something like debug=0x44444 for modprobe iwl3945
[00:58] <JanC> something like that
[00:59] <adinc> what about cgroups?
[01:03] <JanC> if I understand things correctly (but I am not a kernel devloper in any way), it seems like the firmware crashes or gives errors when it's under load (sometimes)
[01:03] <adinc> i think that is a different bug
[01:04] <adinc> when the module loads a firmware, which is the case when the device is configured, then the problem appears
[07:28] <Ng> has the behaviour of cpu frequency scaling intentionally changed since <=gutsy?
[07:29] <Ng>  /sys/devices/system/cpu/cpu1/cpufreq is a symlink to cpu0/cpufreq
[07:31] <Ng> (which gets lost on suspend/resume because we save the value of each and then reset it to performance for the actual suspend)
[07:31] <Ng> bug #162652
[07:31] <ubotu> Launchpad bug 162652 in pm-utils "pm-utils changes default cpu policy after resuming from suspend-to-ram" [Undecided,Confirmed] https://launchpad.net/bugs/162652
[08:14] <kraut> moin
[08:39] <adinc> can someone have a look into the kernel config file of hardies kernel if it has a driver compiled in called IWL3945, for config-2.6.24-12-generic
[08:56] <soren> soren@butch:~$ grep IWL /boot/config-2.6.24-12-generic 
[08:56] <soren> # CONFIG_IWLWIFI is not set
[08:56] <soren> soren@butch:~$
[08:56] <soren> adinc: ^^
[08:59] <pwnguin> your server names are strange ;)
[09:01] <adinc> soren: sorry?
[09:01] <adinc> i see
[09:02] <adinc> well but what about this bug 185470 then
[09:02] <ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
[09:02] <adinc> so this module is not even enabled
[09:04] <adinc> soren: could you please have a look for me if this module exists in your /lib/modules/2.6.24-12-generic/ubuntu/wireless/iwlwifi/iwlwifi/compatible/iwl3945.ko
[09:04] <soren> adinc: It's probably in linux-ubuntu-modules.
[09:04] <adinc> soren: but still it would need to be enabled in the kernel
[09:05] <adinc> the .config file should show that this module is enabled or not, valid for the whole kernel
[09:05] <soren> adinc: Erm.. no?
[09:05] <adinc> no?
[09:05] <soren> lum has it's own config.
[09:05] <adinc> lum?
[09:05] <soren> s/it's/its/
[09:05] <adinc> what is lum?
[09:05] <soren> linux-ubuntu-modules
[09:05] <pwnguin> isn't ubuntu kernel packaging fun?
[09:05] <adinc> soren: can you please tell me where this config is?
[09:05] <soren> I'm laughing on the inside.
[09:06] <adinc> i'm new to ubuntu
[09:06] <soren> It's in git.
[09:06] <adinc> pwnguin: looks like...
[09:06] <soren> I don't know if it's installed anywhere.
[09:06] <adinc> soren: ok, how can i get it
[09:06] <adinc> with git
[09:06] <adinc> i mean where from
[09:06] <soren> WEll, you can use look at it through gitweb?
[09:06] <soren> http://kernel.ubuntu.com
[09:07] <adinc> i don't know why this is done this way, but makes look through more complicated
[09:07] <adinc> so we won't be able to compile the same kernel here withouth this config file
[09:08] <soren> The main repo tracks the upstream kernel + a few patches here and there. Extra drivers that we add are in lum.
[09:08] <pwnguin> apt-get source should help you
[09:08] <adinc> what does lum mean
[09:09] <pwnguin> Linux
[09:09] <pwnguin> Ubuntu
[09:09] <pwnguin> Modules
[09:09] <pwnguin> its a package
[09:09] <adinc> ohh
[09:09]  * soren chuckles
[09:09] <soren> 09:05:37 < adinc> what is lum?
[09:09] <soren> 09:05:40 < soren> linux-ubuntu-modules
[09:09] <adinc> yes, but i didn't realize this was the shortened way for linux-ubuntu-modules
[09:10] <adinc> my mistake
[09:10] <adinc> ;)
[09:10] <soren> No worries.
[09:11] <alex_joni> adinc: as an exercise you'll have to figure out lrm by yourself :P
[09:11] <pwnguin> heh
[09:12] <pwnguin> Is there a published guide to rebuilding the ubuntu kernel packages, for sysadmins and beginning hackers?
[09:12] <pwnguin> i used to build my own kernel years ago on debian, but its become so much more complicated
[09:12] <alex_joni> there is a guide around wiki.ubuntu.com
[09:12] <adinc> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[09:12] <alex_joni> pwnguin: actually it's a bit easier once you know the steps to do it :)
[09:12] <alex_joni> I never had a thing for make-kpkg :)
[09:13] <pwnguin> i liked make kpkg
[09:13] <pwnguin> much easier to revert when i screw up things
[09:13] <alex_joni> pwnguin: oh, it still builds debs which you install
[09:13] <alex_joni> and revert easily
[09:14] <alex_joni> but not using make-kpkg, using debian/rules from the ubuntu linux source
[09:14] <pwnguin> the wiki page adinc pointed out uses make-pkg =/
[09:15] <abogani> https://wiki.ubuntu.com/KernelMaintenanceStarter 
[09:15] <abogani> make-pkg isn't support at all
[09:16] <adinc> no, he means make-kpkg
[09:16] <alex_joni> look at https://help.ubuntu.com/community/Kernel/Compile
[09:32] <chaosmaster> Hi
[09:34] <chaosmaster> I've done some pm-utils and suspend testing over the holidays and found an issue with resuming on my Samsung P35 notebook and radeon 9700 (r300) based card.
[09:35] <chaosmaster> In contrast to current ubuntu practice radeonfb is *absolutely* needed for working resume
[09:35] <chaosmaster> anyone interested?
[09:35] <alex_joni> chaosmaster: there was a bug related to this reported at launchpad.net, I'd suggest you search there first
[09:41] <chaosmaster> "[Bug 201591] atyfb regression - screen blank except for blinking cursor after fbcon vtswitch"  is another issue and I already commented it
[09:41] <ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,In progress] https://launchpad.net/bugs/201591
[09:42] <alex_joni> did you try the recent fix?
[09:43] <chaosmaster> "81722 Laptop sometimes fails to resume from ACPI S3 suspend"  is the only one mentioning radeonfb with resume/suspend and mentions another issue
[09:43] <alex_joni> the one from mjg on the 23.03.2008 ?
[09:43] <alex_joni> chaosmaster: then I suggest you file a new bug report for the issue you're having :)
[09:43] <chaosmaster> yes, I patched my kernel - without radeonfb breaks completely
[09:44] <chaosmaster> I wanted to ask about the ubuntu policy in not allowing any framebuffer drivers, as they are blacklisted
[09:45] <chaosmaster> alex_joni: for which component - the kernel?
[09:45] <alex_joni> chaosmaster: sorry, not in a real position to be more precise.. :(
[09:47] <chaosmaster> alex_joni: OK, I'll file a new bug
[09:51] <soren> I have a laptop that since upgrading to hardy doesn't suspend nor hibernate anymore. Both end up with a blank vt with a blinking cursor in the top left corner. AFAICS, all the quirks listed on the pm-{suspend,hibernate,suspend-hybrid} man page deal with the resuming process..
[09:51] <soren> ..so I'm at a bit of a loss. What to do?
[09:52] <chaosmaster> soren: what laptop do you use and what is your graphics card?
[09:53] <soren> I believe it's called a Uniwill something-something. It's got Intel graphics.
[09:54] <soren> Suspend and hibernate have both worked flawlessly since breezy on it, afair.
[09:54] <soren> Hm... I could try booting the gutsy kernel.
[09:54] <chaosmaster> soren: please paste the output of: lspci | grep VGA
[09:55] <soren> That might provide a hint as to whether it's a pm-utils issue or a kernel on.e
[09:55] <chaosmaster> soren: not really :)
[09:55] <soren> Why?
[09:57] <soren> It's an intel 855.
[09:57] <soren> chaosmaster: Why couldn't booting an older kernel provide a hint as to whether it's a pm-utils issue or a kernel one?
[09:58] <chaosmaster> soren: the suspend/resume process is very delicate and complex with a lot of parts beeing integrated. in Hardy a lot of new technologies (kerne, xorg, pm-utils) are updated so it's not that easy to pinpoint it to a single part
[09:58] <soren> Er... Sure it is.
[09:58] <soren> Don't start X, boot an older kernel, and presto! All you've got left is the new pm-utils.
[09:58] <adinc> does someone know how to get the processes below the window with top ? sorry for asking here, but i suppose not many people are using it
[09:59] <alex_joni> assuming it works with the older kernel
[09:59] <soren> alex_joni: 09:54:20 < soren> Suspend and hibernate have both worked flawlessly since breezy on it, afair.
[10:00] <soren> adinc: I don't understand the question?
[10:00] <elmargol> Where can I ask iwlwifi specific questions?
[10:00] <chaosmaster> soren: are you ready to test some quirks?
[10:01] <adinc> soren: if you call top, the process listing application, it shows the processes listed till the bottom of the current window. what do you do in order to see the rest of the processes
[10:01] <adinc> elmargol: have you got a problem with iwl3945?
[10:01] <soren> adinc: Stretch the window? :)
[10:01] <soren> chaosmaster: Which ones, for instance?
[10:01] <adinc> soren: cool, but i can't find a 24 inch monitor for the time beeing
[10:02] <elmargol> adinc, yes  I have bug #176271
[10:02] <ubotu> Launchpad bug 176271 in linux-ubuntu-modules-2.6.24 "major throughput difference (between upload and download) when using iwl3945" [Undecided,Confirmed] https://launchpad.net/bugs/176271
[10:02] <elmargol> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1592
[10:02] <soren> adinc: You can make the window larger than your screen, you know..
[10:02] <ubotu> bughost.org bug 1592 in data transfer "Speed drops when downloading at high speeds" [Normal,Assigned] 
[10:02] <adinc> elmargol: do you use hardy
[10:02] <elmargol> adinc, yes
[10:02] <chaosmaster> soren: I don't have intel GMA specific knowledge, but vbestate-restore works for me on my ATI radeon 9700 M
[10:02] <adinc> soren: heheh, but thats not the solution
[10:02] <adinc> elmargol: so you are one of those lucky guys, you at least get a connection
[10:03] <soren> chaosmaster: This is hibernation and suspension. Not resuming.
[10:03] <elmargol> My connection is fast 2-3MB/s after about 100-200MB traffic I get stuck at 1Mbit/s
[10:04] <chaosmaster> soren: best way is to find the most similar notebook / card and try the quirks listed there
[10:04] <adinc> do you have kernel 2.6.22 or 2.6.24?
[10:04] <elmargol> 2.6.24-12-generic
[10:04] <chaosmaster> soren: suspend is (almost) never the problem - it's always about the resuming
[10:04] <soren> chaosmaster: Look... vbestate-restore is about loading the vbestate on *resume*.
[10:05] <soren> chaosmaster: It doesn't suspend!
[10:05] <chaosmaster> soren: oh, then I misunterstood your problem
[10:05] <elmargol> I'm using Ben Collins git tree
[10:06] <adinc> strange, here i can't get it running at all with a samsung q45, but lets wait i'm compiling a fresh git tree
[10:07] <adinc> see bug 185470
[10:07] <ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
[10:07] <soren> Just tested with 2.6.22. It suspends just fine.
[10:07] <soren> It doesn't resume properly, though, but that's just quirks, so that's easy.
[10:08] <adinc> how is ubuntu managing firmware loading, is it hotplug doing?
[10:09] <soren> adinc: I belive it's udev.
[10:09] <adinc> soren: i see
[10:09] <elmargol> I try iwlwifi HEAD now...
[10:09] <adinc> those changes should bit in kernel git
[10:10] <chaosmaster> soren: do you use only ubuntu kernels?
[10:10] <soren> chaosmaster: Yes.
[10:10] <adinc> elmargol: what device are you using it
[10:10] <elmargol> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
[10:11] <adinc> elmargol: same here, whichnotebook is it?
[10:11] <elmargol> Dell inspiron 9400
[10:12] <adinc> ohh, my new kernel hangs when loading acpi modules with init
[10:13] <elmargol> I'm using v1.2.25
[10:13] <adinc> of what?
[10:13] <elmargol> iwl3945
[10:14] <elmargol> thats from 02-04-08
[10:14] <chaosmaster> soren: if the same system suspends fine just with an older kernel, the you have to try other kernels between 2.6.22-working and 2.6.24-nonworking - the problem is I don't know of any mirror with all older ubuntu versions
[10:17] <soren> chaosmaster: I know how to use git.
[10:18] <soren> chaosmaster: I'm just not unambiguously a fan of bisecting as a debugging tool.
[10:19] <chaosmaster> soren: but then you have to compile them and I tried it yesterday - it was not funny, as I didn't find a way to compile only one flavour. By default debuild compiles -generic -386 -server ....
[10:20] <soren> I also know my way around Ubuntu's kernel build system by now :)
[10:20] <soren> Building just a single flavour is even documented on the wiki.
[10:21] <chaosmaster> soren: so you know more than me :)
[10:23] <elmargol> Is there a way to have the card in g only mode?
[10:25] <alex_joni> chaosmaster: iirc it's something like debian/rules binary-image-i386
[11:17] <BenC> Good morning everyone
[11:18] <chaosmaster> good morning (even if it's past 12 here in DE) :)
[11:48] <elmargol> adinc, switching my accesspoint do mode b seems to fix the issue
[11:49] <elmargol> at least it takes longer to happen
[12:04] <AnAnt> Hello, will bug #201591 be fixed in next kernel upload ? will it use that patch suggested by Garrett ?
[12:04] <ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,In progress] https://launchpad.net/bugs/201591
[12:04] <soren> mjg59: Maybe you could help me out a bit? I have a laptop where 2.6.22 suspends and hibernates just fine, but on 2.6.24, it fails. I get a blank vt (blinking cursor in the top-left corner) and then it just sits there, never actually suspending or hibernating. I'm happy to fiddle around with the kernel to try to fix it, but do you have a few pointers about where to look?
[12:05] <mjg59> soren: Did any of the 2.6.24 kernels work?
[12:05] <soren> mjg59: It's my wife's laptop which I only just upgraded yesterday.
[12:05] <soren> mjg59: So I've only tried the most recent one, I'm afraid.
[12:06] <mjg59> soren: Hm. Can you boot with the kernel argument no_console_suspend and without quiet?
[12:06] <mjg59> Then give it a go
[12:06] <soren> Sure.
[12:09] <soren> mjg59: Just to be sure: I call pm-suspend to suspend. That's the way to do it, right?
[12:09] <mjg59> soren: No.
[12:09] <soren> Ah.
[12:09] <mjg59> soren: What desktop are you running?
[12:10] <soren> I've killed X.
[12:10] <mjg59> Don't do that
[12:10] <soren> To keep that out of the equation.
[12:10] <soren> Hm... Ok. Is it likely to work better with X running? That's surprising.
[12:10] <mjg59> I suspect it's unrelated to the problem you're having, but please try from X
[12:11] <soren> WEll, if it matters, I discovered the problem while trying to hibernate from GNOME. Since then, I've used the terminal to make reduce the number of places it could fail.
[12:11] <soren> ...but ok, I'll try from GNOME.
[12:15] <soren> mjg59: Oh.
[12:15] <soren> mjg59: pm-hibernate oopsed.
[12:15] <soren> i915_suspend
[12:17] <mjg59> soren: Hm. How about suspend?
[12:18] <soren> mjg59: I'll try.
[12:19] <soren> mjg59: ba8bbcf6ff4650712f64c0ef61139c73898e2165 says: "i915: add suspend/resume support". If it didn't have suspend/resume support before, how is it that this laptop used to suspend just fine?
[12:20] <soren> It has an i855 graphics adapter, by the way.
[12:20] <mjg59> We attempted to restore graphics state from userspace
[12:20] <mjg59> Hm. Ok, interesting.
[12:20] <mjg59> If it oopses on suspend, that's something I'll have to look at
[12:20] <soren> The i915 driver *is* supposed to handle i855, I suppose?
[12:21] <mjg59> Yes
[12:21] <adinc> elmargol, i could get it the connect and request a dns with a new kernel but still i get errors
[12:22] <adinc> elmargol: is it running without any problems at all now?
[12:22] <elmargol> no
[12:22] <elmargol> Its the same... this was just random (
[12:22] <adinc> `so same here, i'm sure this is nothing we can solve
[12:23] <adinc> only the developer of this driver can do this
[12:23] <elmargol> And i was thinking intel wireless cards are well supported :(
[12:23] <adinc> or someone who is involved in developing this module
[12:23] <tjaalton> soren: I debugged that issue yesterday (hibernate fails to power down) :)
[12:23] <adinc> elmargol: yes, my intention was the same actually when looking to this device
[12:23] <soren> tjaalton: Any luck?
[12:23] <tjaalton> soren: yes
[12:23] <soren> tjaalton: Do tell.
[12:24] <elmargol> I'm wondering if I can change my wireless card
[12:24] <tjaalton> soren: see bug 197064
[12:24] <ubotu> Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] https://launchpad.net/bugs/197064
[12:24] <tjaalton> it's probably the same
[12:25] <soren> Might be.
[12:25] <soren> mjg59: When suspending, I just get a VC with "[  120.351344] drm_sysfs_suspend" and nothing else.
[12:26] <tjaalton> suspend works here
[12:27] <soren> mjg59: I can't help but wonder if I mistyped the kernel option..
[12:27] <mjg59> soren: That's with no_console_suspend?
[12:27] <soren> mjg59: I think so, but I may have mistyped it. I'll try again.
[12:27] <mjg59> Ok
[12:27] <mjg59> And make sure you don't have quiet on the command line
[12:29] <soren> Sure.
[12:30] <Ng> soren: is this on your x40?
[12:31] <soren> /proc/cmdline only lists "root=UUID=blahblahb ro no_console_suspend", so I'll try again.
[12:31] <soren> Ng: Nope.
[12:31] <soren> Ng: It might do the same, though. I haven't tried.
[12:31] <soren> mjg59: Hm... No, I don't get anything but the drm_sysfs_suspend line. After that, it's quiet.
[12:32] <mjg59> soren: Does alt+sysrq+t print anything at that point?
[12:32] <soren> mjg59: Nope.
[12:32] <soren> sysrq+o does power it off, though.
[12:33] <soren> alt+sysrq+o, that is.
[12:33] <mjg59> Hm.
[12:33] <mjg59> I'll see if I can reproduce
[12:33] <soren> So the kernel's somewhat alive, but I get no VC love.
[12:33] <mjg59> My X40 is still around somewhere
[12:34] <soren> mjg59: This is not an X40, though. I realise it's the same graphics card, I'm just saying.
[12:34] <Ng> soren: purely out of interest, does it work if you call acpi-support's sleep.sh?
[12:34] <soren> Ng: I doubt it will, but I can try.
[12:34] <Ng> I get different suspend/resume behaviour between acpi-support and pm-utils. Reading through their scripts last night they seem to do fairly different things
[12:34] <mjg59> Ng: What sort of different behaviour?
[12:35] <Ng> mjg59: well specifically for me I need to unload e1000 for suspend to work, which acpi-support did because it seems to unload all network modules, where pm-utils doesn't unload any modules by default (if I was reading the scripts properly)
[12:36] <mjg59> Ok. Have you got a bug filed about that?
[12:37] <Ng> mjg59: I filed one originally about suspend not working, which I've kept updated, bug 201037. It may need to be moved to a different package or so
[12:37] <ubotu> Launchpad bug 201037 in pm-utils "suspend fails on Thinkpad X300" [Undecided,New] https://launchpad.net/bugs/201037
[12:37] <Ng> and I guess the description should be more generic
[12:37] <soren> I've never been able to really figure out if more or less generic is preferred in these cases.
[12:38] <soren> I'm leaning towards less.
[12:38] <soren> It's easier to mark a bug a as a dupe than to split it into two.
[12:39] <Ng> I can't answer that, but I would guess this affects more than just the x300 and it's a fairly significant behaviour change that's very undiscoverable. the price of unloading/reloading networking modules can't be very high, but it may make some weird problems go away.
[12:39] <Ng> having said that, it just seems like its masking driver bugs
[12:40] <Ng> anyway, I'll stop hijacking soren's bugtime ;)
[12:41] <soren> FWIW, I think don't-unload-by-default would be a good idea early in the dev cycle and then switch to unload-by-default at around beta time.
[12:42] <Ng> I'd buy that for a dollar
[12:42] <soren> It gives us a chance to spot the issues and perhaps fix them early on, and then switch to the safer approach for the release.
[12:43] <mjg59> Ng: Ok, I've poked pitti about that. I'll try to hack up a patch later on if I get a chance.
[12:43] <soren> My not-up-to-date X40 suspends just fine. I'll try getting it current and see if it changes.
[12:44] <mjg59> soren: Just pull the kernel
[12:44] <Ng> mjg59: nice, thanks
[12:46] <soren> mjg59: Alright.
[12:47] <soren> mjg59: Oh, kernel seems to be up-to-date.
[12:47] <mjg59> soren: -12?
[12:47] <soren> uname -a is identical.
[12:47] <mjg59> Ok
[12:47] <mjg59> Hrmph.
[12:47] <soren> pm-utils is not up-to-date, though.
[12:47] <mjg59> /shouldn't/ matter, but yeah, give it a go
[12:48] <soren> No, the X40 still suspends just fine.
[12:48] <mjg59> Bother
[12:48] <mjg59> Makes it harder for me to try to reproduce, then :)
[12:48] <soren> Quite.
[12:48] <mjg59> soren: On the broken machine, can you try moving i915.ko out of the way so it doesn't get loaded?
[12:48] <soren> mjg59: I could. 
[12:52] <soren> The bug tjaalton linked to suggested that it'd end up in an infinite loop. I've left the machine alone for a while and the fan is rather quiet, so I have a hunch that's not it.
[12:55] <soren> mjg59: Without i915, it suspends just fine.
[12:59] <mjg59> soren: Yeah, the failure we've seen with hibernate shouldn't happen on suspend
[12:59] <soren> mjg59: Oh?
[13:00] <mjg59> It's specific to the suspend call being made twice
[13:00] <mjg59> Which only happens in hibernate
[13:01] <soren> Oh, ok.
[13:01] <soren> (hibernate works just fine now, too)
[13:02] <soren> Why does hibernation cause two calls to the suspend code?
[13:02] <mjg59> Because it's somewhat broken
[13:03] <mjg59> soren: Hm. Ok. Anyway, on the off-chance that it's actually the same problem - any chance you can grab the oops on hibernation?
[13:03] <mjg59> Camera or something would be good
[13:04] <soren> Sure.
[13:05] <soren> Just modprobe i915 and recycling X should do the trick, I guess.
[13:07] <smb> BenC: Morging Ben. One question: I was looking over the milestone bugs and there is one (bug 176090) assigned to Tim which is about iwlwifi. Does it make sense to add LED support (kernel driver would have that but is different version)?
[13:07] <ubotu> Launchpad bug 176090 in linux-ubuntu-modules-2.6.24 "WiFi / WLAN LED not working on notebooks with Intel iwl4965 | iwl3945" [Medium,Confirmed] https://launchpad.net/bugs/176090
[13:07] <BenC> smb: Is it just a matter of enabling the right config option?
[13:08] <soren> mjg59: Hm... Guess not. It looks suspiciously like a font-less vc.
[13:08] <smb> BenC: No, there is more code change involved
[13:08] <BenC> smb: looks to me like enabling MAC80211_LEDS would do the trick...what else is there?
[13:09] <mjg59> soren: Heh. Well, if you can get it again, that would be helpful :)
[13:09] <soren> mjg59: I'm on it, I'm on it. I think my phone takes decent enough pictures to be useful. Do you happen to know of a relevant bug to attach it to, or should I just throw them somewhere for you to see.
[13:10] <soren> ?
[13:10] <smb> BenC: If I am not wrong, it requires *-led.c files in both specific drivers and at least one other file that isn't there right now (something with hbus)
[13:11] <smb> BenC: if you want a quick look. I just moved the patch that enabled leds to zinc (my home)
[13:12] <mjg59> soren: Just file a new one for now
[13:15] <smb> BenC: It might be doable. I just wanted to be sure it is agreed because there there certainly is a reason we use the lum driver and not the kernel version
[13:17] <chaosmaster> Hi again
[13:18] <chaosmaster> as mjg59 is here I'm asking again about my suspend issue
[13:18] <chaosmaster> I've done some pm-utils and suspend testing over the holidays and found an issue with resuming on my Samsung P35 notebook and radeon 9700 (r300) based card. In contrast to current ubuntu practice radeonfb is *absolutely* needed for working resume
[13:19] <chaosmaster> shall I file a bug for the kernel or another component?
[13:19] <mjg59> There's not really anything we can do about that case
[13:20] <chaosmaster> I can't believe I'm the only one with this problem
[13:22] <soren> mjg59: Will do.
[13:27] <soren> mjg59: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/207098
[13:27] <ubotu> Launchpad bug 207098 in linux "i915 drm driver fails to hibernate with certain i855's" [Undecided,New] 
[13:27] <BenC> smb: Hold off a sec and let me test one thing real quick
[13:28] <smb> BenC: sure
[13:33] <BenC> chaosmaster: does it work with fglrx?
[13:34] <BenC> brb
[14:49] <BenC> smb: Just pushed that patch out for iwlwifi
[14:49] <BenC> smb: it was gruesome getting it to apply, but it's there
[14:50] <chaosmaster> BenC: I never used fglrx
[15:02] <smb> BenC: Ah, ok. Great
[15:03] <elmargol> BenC, I'm using your kernel from git. And still have this http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1570 bug. Any chances to get this fixed for hardy?
[15:03] <ubotu> bughost.org bug 1570 in data transfer "iwl3945 speed capped at 100 kB/sec" [Normal,Assigned] 
[15:07] <BenC> elmargol: first off, using the kernel wont help anything...you need to use latest lum in git
[15:08] <BenC> elmargol: second off, I'm using iwl3945, and I don't see any cap...I was just transferring at 1.5M/s
[15:09] <elmargol> BenC, sorry I mean I'm using your lum tree
[15:09] <BenC> elmargol: Ah, and I am using 11g, so that explains that part
[15:09] <elmargol> BenC, works for me too i transfer at 2-3Megabyte/sec after 200M speed drops to 100kb/s
[15:10] <BenC> elmargol: well, I transferred 1.2gigs, so...
[15:10] <elmargol> I'm using 11g
[15:10] <elmargol> BenC, do you use wpa?
[15:11] <BenC> elmargol: yes
[15:11] <elmargol> aes or psk?
[15:12] <elmargol> wpa1 or wpa2
[15:14] <BenC> wpa tkip
[15:14] <soren> BenC: You work on the kernel, which is one of the most widely available pieces of software on the planet, and AIUI the only living creatures within miles of you are cows... and you're using WPA.
[15:16] <BenC> soren: a) I like to test the latest and greatest (for testing sake) and b) I'm paranoid over my bandwidth :)
[15:16] <BenC> never know what those mad cows will do
[15:16] <soren> You must be. :)
[15:16] <mjg59> soren: 2.6.24-12-generic-12.22, right?
[15:16] <soren> mjg59: Yup.
[15:17] <BenC> soren: but mainly I worry about my financial transactions over-the-air
[15:17] <soren> BenC: Yeah, I figured. That spoils the joke, though.
[15:17] <BenC> elmargol: at 400Megs transfer and still holding at 1.4M/sec
[15:19]  * lamont` wonders if vmware 6.0.2 works with the current hardy kernel...
[15:19] <BenC> elmargol: anyway, if latest doesn't fix it, it's not going to get fixed for release
[15:19] <BenC> lamont: you'll want the vmmon.tar I have on chinstrap
[15:20] <lamont> thanks
[15:21] <lamont> hrm... vmmon.tar or vmmon-161/vmmon.tar?
[15:22] <BenC> try one, if you get an error about mismatched API version, try the other
[15:30] <elmargol_> BenC, is there a way to set the card to g only mode?
[15:32] <BenC> elmargol: My AP is set to G-only
[15:32] <BenC> so that has the same affect, I would think
[15:35] <AnAnt> Hello, will bug #201591 be fixed in next kernel upload ? will it use that patch suggested by Garrett ?
[15:35] <ubotu> Launchpad bug 201591 in linux "atyfb regression - screen blank except for blinking cursor after fbcon vtswitch " [Medium,In progress] https://launchpad.net/bugs/201591
[15:35] <elmargol_> [  131.230353] wmaster0: TKIP decrypt failed for RX frame from 00:16:b6:19:5e:0a (res=-3) :/
[15:35] <mjg59> BenC: Do you have an M1330 with Intel graphics?
[15:35] <BenC> mjg59: No, nvidia
[15:36] <mjg59> Ah, ok
[15:36] <BenC> I think rtg's is Intel
[15:36] <BenC> mjg59: might also ask jono, not sure what graphics his has
[15:37]  * BenC is off to lunch
[15:42]  * lamont wonders if he should care that the hardy upgrade is gonna nuke restricted-manager
[15:43] <mjg59> soren: Can you do objdump -d /lib/modules/2.6.24-12-generic/kernel/drivers/char/drm/i915.ko and stick the output somewhere?
[15:43] <soren> mjg59: Sure.
[15:44] <Ng> lamont: I think it's called jockey these days
[15:46] <soren> mjg59: http://people.ubuntu.com/~soren/i915.disassembled.txt
[15:50] <lamont> ah, of course.
[15:53] <mjg59> soren: Did you start X, or was this just from the console?
[15:53] <soren> mjg59: From X as you requested.
[15:53] <mjg59> soren: Ok, tanks
[15:53] <mjg59> Thanks
[15:53] <mjg59> Urgh. h key failure.
[15:58] <soren> mjg59: i915_suspend+0x51d is the I915_READ(I915REG_INT_IDENTITY_R) call isn't it?
[15:58] <mjg59> soren: We think it's the FBC reads
[15:59] <soren> mjg59: Hm.. Ok.
[15:59] <mjg59> soren: Can you try http://www.codon.org.uk/~mjg59/tmp/915.diff ?
[16:00] <soren> IS_MOBILE is true for which devices?
[16:00] <soren> (just curious)
[16:05] <soren> mjg59: I'm on my way out the door right now, I'm afraid. I'll try it when I get back sometime later this evening.
[16:05] <mjg59> Should be any of the mobile varients of the chipsets
[16:05] <mjg59> soren: Cool, thanks
[16:05] <soren> mjg59: Oh, thank *you* for looking into it. Much appreciated.
[16:17] <nowhereman> hi everybody
[16:21] <nowhereman> why are make-kpkg builds so much bigger than their ubuntu own git counterparts?
[16:22] <nowhereman> I've built 2.6.25-rc7 and it's around 233M
[16:32] <nowhereman> nvm, found out
[17:44] <BenC> nowhereman: find /lib/modules/`uname -r` -name \*.ko | sudo xargs strip --strip-debug
[17:50] <nowhereman> BenC: yes thanks found that out already :)
[20:19] <sectech> I have an  AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ and athcool doesn't pick up that I have an Athlon... I am running 2.6.24-12-generic... Is there something special that I have to do?
[21:30] <adinc> is someone her who is involved into bug 185470? i've used a new kernel dig and iwl3945 makes still problems
[21:31] <ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
[21:48] <soho> is the new kernel 2.6.24-4 with all it's new features (intel 945 stuff etc.) going into hardy final?
[21:48] <soho> i mean 2.6.24.4
[21:55] <tjaalton> duh, I don't see any i945 goodness in 24.4
[22:08] <mjg59> soren: Had a chance to test that patch? :)
[22:08] <soren> mjg59: I've gotten as far as setting up an i386 chroot to compile it in. Give me half an hour. :)
[22:08] <mjg59> Ha
[22:08] <mjg59> Col
[22:33] <soren> mjg59: Ok, kernel module built. I just need to get my hands on the laptop and try it.
[22:58] <soren> mjg59: Hm... Different oops.
[22:58] <soren> mjg59: This time at i915_suspend+0x60.
[22:58] <soren> mjg59: Actually..
[22:58] <soren> mjg59: I think that's what it said the first time I saw it, too.
[22:59] <soren> mjg59: I just thought I was on crack, so didn't think much of it when I saw the oops on the photos.
[23:23] <mjg59> soren: Hm. Can you try adding similar blocks around some of the other registers?
[23:23] <soren> mjg59: Any particular ones?
[23:23] <soren> mjg59: Or just a random (sub)set?
[23:23] <mjg59> Whichever ones you think it might be oopsing on access to :)
[23:25] <soren> mjg59: Hm.. In any case, I should be adding similar blocks around the resume code, I suppose.
[23:25] <soren> but let's deal with that, when we've found the offending ones.
[23:27] <soren> mjg59: kees and I are looking at the assembler code. We're having trouble making sense of some of it. Well, *I* am, that's for sure.
[23:27] <mjg59> soren: Heh
[23:27] <soren> mjg59: A bit before i915_suspend+0x60, there's a "call 1b6", which is one byte into the call instruction.
[23:27] <soren> wtf?
[23:28] <mjg59> soren: Hrm. Can you stick the disassembly up somewhere again?
[23:28] <soren> http://people.ubuntu.com/~soren/i915.disassembled.txt
[23:28] <mjg59> soren: That's the current module, not the old one?
[23:28] <soren> keescook: Welcome.
[23:28] <soren> mjg59: Old one, but that bit's the same.
[23:28] <keescook> whee
[23:28] <mjg59> soren: Sure? Ok
[23:28] <soren> mjg59: Yes.
[23:29] <soren> I can toss up the new one instead, just to be sure.
[23:29] <mjg59> soren: Passing it on now
[23:29] <soren> http://people.ubuntu.com/~soren/i915-new.disassembled.txt
[23:30] <keescook> fun.  i386 compiler appears to have calculated the relative offset wrong.
[23:30] <soren> Yeah. Something doesn't smell right.
[23:32] <mjg59> soren: Hm. You're definitely starting X, right?
[23:32] <mjg59> And triggering the hibernate with X still running?
[23:32] <soren> mjg59: Hibernating from X, yes.
[23:32] <mjg59> Ok, cool
[23:32] <mjg59> soren: jbarnes is the guy to speak to about this
[23:33]  * mjg59 goes to play Portal for a bit
[23:33] <jbarnes> soren: lspci -v somewhere?
[23:33] <keescook> the disassembly is showing a busted compiler -- a -3 relative jump target is nonsense.
[23:33] <soren> keescook: But if that was really the problem, I wouldn't be getting invalid page requests, but invalid instructions and shit.
[23:33] <soren> jbarnes: Hang on, I'll reboot it.
[23:34] <jbarnes> soren: no it probably wouldn't generate bad opcodes, rather bad memory requests
[23:34] <jbarnes> and/or might overwrite important stuff
[23:34] <soren> jbarnes: Did mjg59 mention the weird looking disassembly?
[23:34] <jbarnes> no, I haven't seen it
[23:34] <keescook>      192:   e8 fc ff ff ff          call   193 <i915_suspend+0x33>
[23:34] <keescook>      197:   8d 8e e0 00 00 00       lea    0xe0(%esi),%ecx
[23:35] <keescook> it's calling into it's own call instruction.
[23:35] <keescook> amd64 compile of the same code shows a regular self-call thunk (e8 00 00 00 00)
[23:37] <jbarnes> it's a rel32 call
[23:38] <keescook> I was about to say -- I can't possibly be right -- the modules are filled with it.
[23:38] <jbarnes> the loader should fix it up
[23:38] <soren> I'll probably figure out what that means when I grow up.
[23:38] <soren> :)
[23:39] <jbarnes> it's probably calling the palette save routine
[23:39] <keescook> ooohhhh
[23:39] <keescook> it's what the prelink targets look like.
[23:39] <keescook> sorry, I haven't disasm'd .o's before.  I'm used to looking at executables
[23:41] <soren> http://pastebin.ca/958866
[23:41] <soren> the lscpi -v (finally)
[23:41] <jbarnes> ok well not the palette routine (that's befcffff) but something
[23:42] <sleepster> how do I become a kernel hacker like you guys?
[23:42] <sleepster> for Ubuntu I mean
[23:43] <sleepster> would you guys offer any advice on how to learn?  I've read the linux kernel books by O'Reilly
[23:43] <jbarnes> sleepster: that's a good start
[23:43] <soren> sleepster: Then you're way ahead of me :)
[23:43] <jbarnes> kernelnewbies has some good tips too
[23:43] <jbarnes> beyond that, I'd recommend finding bugs and fixing them
[23:44] <jbarnes> and don't get too caught up in the janitorial stuff
[23:44] <soren> jbarnes: I tried  http://www.codon.org.uk/~mjg59/tmp/915.diff, but that seems insufficient.
[23:44] <sleepster> yeah. I tend to do that.  I wrote my own OS from scratch, so I know a lot of concepts.
[23:44] <jbarnes> soren: yeah I don't think that's the real issue here
[23:45] <jbarnes> sleepster: well if you wrote your own OS there's not much I can tell you :)
[23:45] <sleepster> I just see you guys talk about the Ubuntu kernel stuff in here .. and it seems interesting.. I want to hop on the band wagon
[23:45] <soren> jbarnes: The new oops is at i915_suspend+0x60, which makes it just before  I915_READ(PIPEACONF);
[23:45] <jbarnes> is that the pci config space read in your case?
[23:46] <soren> pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
[23:46] <soren> AFAIUI
[23:46] <keescook> ah, readelf -r.
[23:46] <soren> If the oops says it's at i915_suspend+0x60, that's the address immediately *After* whatever failed, right?
[23:46] <sleepster> can you guys recommend maybe.. an easy device driver I could implement to learn?
[23:47] <jbarnes> soren: where are the original oopses again?  do you have a complete dmesg from the machine possibly?
[23:48] <soren> jbarnes: The oops happens as I hibernate, so it's unresponsive after it.
[23:48] <jbarnes> sleepster: you should look for the linux driver project, gregkh is running that, they have all sorts of hw that needs linux drivers
[23:48] <soren> jbarnes: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/207098
[23:48] <ubotu> Launchpad bug 207098 in linux "i915 drm driver fails to hibernate with certain i855's" [High,Triaged] 
[23:48] <jbarnes> soren: you could try echo test > /sys/power/disk
[23:48] <jbarnes> then echo disk > /sys/power/state
[23:48] <jbarnes> but that may not help...
[23:49] <soren> jbarnes: I've seen two different oops'es.
[23:49] <soren> jbarnes: The one in the bug and one at i915_suspend+0x60 (but otherwise identical, AFAICS)
[23:50] <jbarnes> ok, so the actual oops is from the access of dfcef0a4
[23:50] <sleepster> thanks guys for the info
[23:50] <sleepster> it's much appreciated
[23:50] <soren> jbarnes: The what now?
[23:51] <jbarnes> soren: I think the cause is the "unable to handle paging request at ..."
[23:51] <jbarnes> and 0xdfcef0a4 is the addr
[23:52] <soren> jbarnes: How do I translate that into something useful?
[23:52] <keescook> soren: where is the +0x60 coming from?
[23:53] <jbarnes> soren: well, looking at the registers, eax has 0xdfced000
[23:53] <soren> keescook: The monitor on the laptop behing me.
[23:53] <soren> behind me, even.
[23:53] <keescook> ah, the photos from 207098 are 0x51d, then?
[23:53] <jbarnes> and 0xdfcef0a4 - 0xdfced000 = 0x20a4
[23:54] <jbarnes> which corresponds to 72a:	8b 80 a4 20 00 00    	mov    0x20a4(%eax),%eax
[23:54] <soren> keescook: Yes.
[23:54] <jbarnes> which is why I suspected the fbc regs at first, since they're at 0x2xxx
[23:54] <jbarnes> but now I think your whole register window is getting lost somehow
[23:55] <soren> I'll see if I can get the +0x60 oops again and take new photos. Gimme a few minutes.
[23:55] <mjg59> jbarnes: Hm. This is without the diff that ensures suspend only gets usefully called once
[23:55] <mjg59> (for hibernation)
[23:55] <mjg59> You don't unmap anything during suspend, do you?
[23:56] <jbarnes> mjg59: we'll disable the device in the suspend path
[23:56] <mjg59> jbarnes: Ah. Perhaps that's the issue.
[23:56] <jbarnes> but it could also be X somehow unmapping the regs
[23:56] <soren> jbarnes: I did the "echo disk > /sys/power/state ; echo disk > /sys/power/state" thing and then it hanged.
[23:56] <mjg59> soren: test, rater than disk?
[23:56] <soren> mjg59: YEs, sorry.
[23:56] <jbarnes> yeah echo test > /sys/power/disk
[23:56] <jbarnes> then echo disk > /sys/power/state
[23:56] <soren> That's what I did.
[23:56] <jbarnes> but yeah the oops might still cause you to hang
[23:56] <soren> I did it from X. Perhaps that was optimistic.
[23:57] <jbarnes> soren: no, that *should* work fine
[23:57] <jbarnes> but there may be a specific interaction with the versions you have on your system
[23:57] <soren> Ok.
[23:58] <soren> test > /sys/power/disk does what?
[23:58] <jbarnes> it'll make your system hibernate, wait 5 seconds, then resume
[23:58] <soren> Increse debugging or something?
[23:58] <jbarnes> w/o actually powering off
[23:58] <soren> Oh.
[23:58] <jbarnes> so you can debug things a lot faster
[23:58] <soren> Ah... Clever.
[23:59] <jbarnes> but as you discovered, it's only useful in some cases :)
[23:59] <soren> I got the system back up now... What was I about to try?
[23:59] <soren> Oh, right. Getting the +0x60 oops again.