[11:03] <lifeless> kylem: up?
[01:42] <kylem> lifeless, am now.
[01:45] <lifeless> kylem: https://beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88899 is really painful for me.
[01:45] <lifeless> kylem: anything you guys can do would rock, also anything I should do to up the chances of you doing it
[01:46] <lifeless> jamesh thought it might be linux listening to ACPI from the hardware, and if so that would suck :(
[01:48] <mjg59> Unlikely
[01:55] <lifeless> mjg59: apparently salgado's laptop did this in feisty: the IBM ACPI stuff set a throttle when the battery was removed, or something.
[01:55] <lifeless> you'd need to ask him or jamesh for details though.
[01:58] <mjg59> I'm not clear what you mean by IBM ACPI stuff
[01:59] <lifeless> neither am I
[02:00] <salgado> lifeless, ?
[02:01] <lifeless> salgado: jamesh was telling me about your ACPI kernel patching
[02:01] <lifeless> salgado: and I have a possibly similar thing, but nowhere near enough context to point mjg59 in the right direction.
[02:01] <lifeless> so...
[02:01] <lifeless> :)
[02:02] <salgado> hmmm. there's a bug which is still open, but I'm pretty sure it's a bug in my BIOS
[02:02] <salgado> let me find it
[02:02] <jamesh> salgado: the fix you did for your problem with the speed being limited with the battery out
[02:02] <jamesh> salgado: I mentioned to lifeless that his speed limiting problem might be related
[02:02] <jamesh> (i.e. related to bad info from the ACPI code)
[02:03] <salgado> well, the fix was basically to ignore the BIOS when it tells the kernel to do stupid things. :)
[02:03] <salgado> jamesh, lifeless, http://bugzilla.kernel.org/show_bug.cgi?id=7060
[02:05] <jamesh> lifeless: so you probably want to check if /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq is lower than expected
[02:05] <lifeless> jamesh: that was fine
[02:05] <lifeless> jamesh: no it wasn't!
[02:05] <lifeless> its reporting 6000000 there
[02:05] <lifeless> rather than 11000000
[02:06] <lifeless> there are lots of similarly named files :(
[02:07] <salgado> lifeless, it may also be the same issue Ingo describes in http://lkml.org/lkml/2007/1/16/120
[02:07] <salgado> (in case you haven't seen it)
[02:07] <lifeless> I dont track kernel foo - so I haven't
[02:08] <salgado> I don't either, until it slows down my processor to half of its speed. ;)
[02:09] <lifeless> cool
[02:10] <lifeless> night all
[02:16] <kylem> lifeless, ok. that patch was merged, i'll slurp that in for you.
[02:16] <kylem> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4233dec749a3519069d9390561b5636a75c7579
[02:33] <kylem> lifeless, salgado, jamesh: we already have that reversion in ubuntu-2.6.git
[04:15] <zul> BenC_: I got a patch for you to look at for breezy but Ill show you it tonight when I get home
[04:29] <Eruantalon> breezy?
[04:32] <BenC> zul: Ok
[04:33] <mkrufky> did you guys hear that ivtv is being merged into mainline now?
[04:33] <mkrufky> it's been a long time coming :-)
[04:34] <kylem> mkrufky, what's ivtv?
[04:35] <mkrufky> hardware analog video mpeg encoder driver, based on the iTV cx2341x encoder
[04:35] <mkrufky> it's the "preferred mpeg encoder" driver
[04:36] <mkrufky> i believe it is packaged with the ubuntu kernel in the "out-of-tree" driver section
[04:36] <mkrufky> anyway...  you guys wont have to worry about making ivtv packages and / or compat-porting that driver any longer
[04:39] <kylem> spiffyo.
[04:40] <mkrufky> :-)
[05:30] <dholbach> hey guys
[05:30] <kylem> holy holbach!
[05:30] <dholbach> pkl_: do you want me to attach  http://daniel.holba.ch/temp/mmc-KILL.txt  to bug 82680? that's what happened, when I tried to  modprobe mmc_block  and inserted an SD card into my x40
[05:31] <pkl_> dholbach: yes, please do.
[05:31] <dholbach> if you want a separate bug for that, I can do that too
[05:31] <dholbach> (dunno if that's the same cause or not)
[05:32] <pkl_> dholbach: you have a TI mmc card reader?
[05:32] <dholbach> pkl_: how do I check?
[05:33] <dholbach> daniel@lovegood:~$ lspci -v | grep Texas
[05:33] <dholbach> daniel@lovegood:~$ 
[05:33] <dholbach> doesn't look like
[05:33] <dholbach> 02:00.1 Generic system peripheral [0805] : Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSP
[05:33] <dholbach> ro Host Adapter (rev 13)
[05:33] <dholbach>         Subsystem: IBM Thinkpad X40
[05:33] <dholbach>         Flags: bus master, medium devsel, latency 64, IRQ 17
[05:33] <dholbach>         Memory at d0221000 (32-bit, non-prefetchable) [size=256] 
[05:33] <pkl_> what does lsmod say? do "lsmod | grep tifm"
[05:34] <dholbach> empty
[05:35] <pkl_> If you've got a TI mmc card supported by Linux, it should come up with either "tifm_7xx1" or "tifm_sd"
[05:37] <pkl_> Can you attach the output of lscpi, lsmod, and  dmesg somewhere, that way I can see what you do have.  Best if you raise a bug, #82680 is (I think) TI mmc card specfic.  I'll check. 
[05:38] <dholbach> ok, I'll file a new one and let you know.
[05:38] <pkl_> ok, thanks.
[05:38] <dholbach> the SD reader worked in edgy
[05:39] <pkl_> There seems to be a lot of regressions regarding mmc cards.  Still working on finding out why... :-)
[05:43] <pkl_> dholbach:  "Generic system peripheral [0805]  " is supported by the sdhci driver.  It's likely a problem there.  I'll know more when I've looked at the output from the various commands. 
[05:43] <dholbach> ok nice, *attaching info*
[05:46] <dholbach> pkl_: bug 88992
[05:46] <dholbach> if you need any more info let me know
[05:47] <pkl_> dholbach: OK.  WIll do.
[05:47] <dholbach> gracias :-)
[07:21] <gilligan_> hi
[07:23] <gilligan_> I have a question regarding the patch made to super_umount which has been patched from super_umount(struct super_block*) to super_umount(struct vfsmount*, int flags) .. flags seems to be 0 in most cases -  I have some sources that rely on the old prototype. I can easily add the integer argument, but is there a straight forward way to patch the sources to  use the vfsmount isntead of the super_block ?
[07:23] <gilligan_> i.e can I somehow find the vfsmount struct that the super_block belongs to ? then the patching would be easy
[07:58] <lifeless> kylem: its in git, is it in a package ?
[07:59] <kylem> yes.
[07:59] <kylem> it's been in all of them since we merged 2.6.20
[08:11] <lifeless> so, its not that then.
[08:13] <salgado> lifeless, is it a regression?
[08:14] <kylem> sounds like it.
[08:15] <lifeless> salgado: from edgy yes,
[08:17] <salgado> lifeless, that patch could have caused the regression. is it broken on pre-2.6.20 kernels too?
[08:17] <salgado> I mean, post-edgy, pre-2.6.20
[08:17] <lifeless> salgado: I'll install one today
[09:02] <lifeless> ok thats *freaky*
[09:02] <lifeless> I've gone to battery
[09:02] <lifeless> and now $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
[09:02] <lifeless> 1100000
[09:02] <lifeless> excuse while I say WTF
[09:02] <kylem> possibly some userspace policy is inverted?
[09:04] <lifeless> scaling_governor is set to 'conservative' now
[09:05] <lifeless> presumably by gnome-power-manager