[02:19] <mjg59> BenC: Are we keeping the snd-hda-intel in lum?
[02:19] <mjg59> BenC: Also, TIFM still seems to be enabled
[03:12] <mjg59> rtg: The support for the 1984 codec in the Thinkpads doesn't /seem/ to enable the speakers by default
[07:44] <fabbione> jetsaredim: they will arrive, but there is no rush at all. nobody other than vmware can support the modules
[07:44] <fabbione> so before or after release makes no diff
[09:55] <kraut> moin
[01:40] <dewcrav3r> Can someone point me to the appropriate channel for technical kernel support?
[01:42] <soren> dewcrav3r: Depends.. What's the problem?
[01:43] <dewcrav3r> I'm getting a division by zero error in jiffies.h, and I can't find the solution anywhere
[01:54] <soren> dewcrav3r: In Ubuntu's kernel?
[01:54] <soren> dewcrav3r: ...or something you're working on yourself?
[01:55] <dewcrav3r> The one I made didn't have the file at all.... but yes, I'm referring to the Ubuntu version
[02:09] <soren> dewcrav3r: If you can trigger a division by zero in the Ubuntu kernel, that's a bug.
[02:13] <dewcrav3r> sry, busy in another room.
[02:13] <dewcrav3r> whoa.... that's cool ;)
[02:14] <dewcrav3r> The thing is, I can Google the problem and find other who trigger it in different ways... but no solutions
[02:24] <soren> dewcrav3r: I think you should file a bug and describe the problem.
[02:25] <dewcrav3r> I will do that if I can't find a fix for it.  Thanks for the help!
[03:06] <rtg> > mjg59: yeah, rtg is supposed to enable orinoco_cs with just the id's not found in hostap_cs
[03:07] <rtg> mjg59: Actually, I was just going to remove -MODULE_DEVICE_TABLE from the source.
[03:08] <rtg> That way folks with older prism2 cards aren't forced to use hostap or to have to upgrade their firmware.
[03:10] <mjg59> rtg: That would stop it working with genuine orinoco cards
[03:10] <mjg59> Which would be a regression
[03:11] <mjg59> orinoco drives two types of cards - orinoco and prism2. They're similar, but not identical. hostap only drives prism2 hardware (and prism 2.5, but still)
[03:13] <rtg> mjg59: shit, so what you are telling me is really do have to do the visual filter of PCI IDs.
[03:14] <mjg59> They're not PCI IDs
[03:14] <rtg> mjg59: right, PCMCIA.
[03:14] <mjg59> But yes, IDs that aren't supported by hostap should be in orinoco
[03:14] <mjg59> I've fixed up hostap so that it doesn't leave network-manager completely confused, which should deal with the other issues
[03:14] <rtg> There is some overlap, but not easy to spot. Oh well, I'll find 'em.
[03:14] <BenC> rtg: you need to create a new ID table, with just the IDs that hostap_cs doesn't support, and reference that in MODULE_DEVICE_TABLE()
[03:15] <BenC> leave the full table so that pcmcia reg can still drive the entire list if it gets loaded manually
[03:16] <rtg> BenC: ok
[03:40] <rtg> mjg59: what did Feisty do to avoid prism2 collisions? Both hostap_cs and orinoco_cs are built, both with MODULE_DEVICE_TABLE defined. I see a bunch of IDs that overlap. There are some /etc/modprobe.d options for hostap_cs, but no blacklist for orinoco_cs.
[03:41] <mjg59> It would just load whichever came first in the tables, which is determined by inode order
[03:41] <mjg59> So not something that can be depended on
[03:41] <rtg> I suppose that caused some problems.
[03:42] <mjg59> Well, users always got a driver that supported their hardware
[03:42] <mjg59> Just not necessarily the one they wanted
[03:42] <rtg> Yeah, but no WPA support with orinoco_cs, right?
[03:44] <mjg59> Yeah
[03:54] <kylem> BenC, is internal irc fucked?
[03:54] <BenC> kylem: it was, seems to be fine now
[03:55] <kylem> hmm. i can't connect.
[04:22] <soren> Have any of you had a chance to look into either #127872 or #140761 ?  They seem to be the same problem. The former on actual hardware, the latter in vmware.
[04:22] <soren> Bug #127872 and bug #140761
[04:22] <ubotu> Launchpad bug 127872 in linux-source-2.6.22 "scsi drives not detected " [Medium,New]  https://launchpad.net/bugs/127872
[04:22] <ubotu> Launchpad bug 140761 in linux-source-2.6.22 "Ubuntu 7.10 Alpha Gust OS does not recognize a lun with non zero target id on Vmware ESX Server" [Undecided,Confirmed]  https://launchpad.net/bugs/140761
[05:18] <rtg> mjg59: Can you have a look at kernel.ubuntu.com:/home/rtg/ubuntu-gutsy commit cceb265a3fe948666ab5dcc413957a6f0d9f5576 to see if it solves the orinoco_cs problem? For some reason my git trees don't show up on gitweb.
[05:20] <mjg59> rtg: You seem to have removed entries from hostap_cs?
[05:20] <mjg59> Oh, or are they just reformatted?
[05:20] <rtg> mjg59: shit, I reformatted so they were easier to read.
[05:20] <mjg59> Yeah, makes it slightly harder to check the diff :)
[05:21] <rtg> mjg59: I'll revert that. Other then formatting?
[05:21] <mjg59> I don't understand the:
[05:21] <mjg59> +       status = pcmcia_register_driver(&orinoco_driver);
[05:21] <mjg59> +       if (status >= 0)
[05:21] <mjg59> +               status = pcmcia_register_driver(&orinoco_overlap_driver);
[05:21] <mjg59> hunk
[05:21] <rtg> Don't you have to register both tables?
[05:22] <mjg59> Oh, I see - for binding
[05:22] <mjg59> Ok
[05:22] <mjg59> Yeah, looks ok
[05:22] <rtg> cool. I'll cleanup the formatting and push it.
[05:22] <mjg59> I'm going to assume that you've moved the right chunks :)
[05:22] <rtg> It was tedious. I hope so too.
[05:23] <rtg> I think I have exactly one PCMCIA laptop. Maybe I can come up with a prism card that lives in both drivers.
[05:53] <Kano> hi, why is et131x not in the ubuntu modules package?
[05:55] <Kano> Agere's chips are very common
[05:57] <Kano> http://sourceforge.net/projects/et131x/
[05:59] <rtg> Kano: bug #102291
[05:59] <ubotu> Launchpad bug 102291 in ubuntu "[needs packaging]  et131x driver for Agere ET131x gigabit ethernet cards" [Wishlist,Confirmed]  https://launchpad.net/bugs/102291
[06:00] <zul> BenC: ping
[06:01] <zul> rtg: if you want i could create a patch for that
[06:01] <rtg> zul: that would be great. Kano will thank you.
[06:02] <zul> rtg: ill put it on my to do list for this weekend
[06:03] <bdmurray> BenC: Have you seen bug 144945?
[06:03] <ubotu> Launchpad bug 144945 in linux-ubuntu-modules-2.6.22 "kernel Oops in unionfs with l-u-m version 2.6.22-12.32 using Edubuntu amd64 daily 200709025" [Undecided,New]  https://launchpad.net/bugs/144945
[06:03] <Kano> zul: maybe create one for aufs too :)
[06:04] <zul> Kano: i already updated a fix for aufs last weekend
[06:04] <Kano> zul: really, will take a look
[06:04] <Kano> why dont add it in that package too?
[06:04] <zul> Kano: i did
[06:05] <Kano> in ubuntu modules i see no aufs
[06:05] <zul> no its the package in universe
[06:05] <Kano> thats a very old aufs...
[06:06] <zul> tough
[06:07] <Kano> i see your patches in the diff, will try to use it for a newer version
[06:07] <Kano> you dont like extra patch files
[06:08] <zul> i dont like changing existing sources 
[06:09] <Kano> you dont like dpatch?
[06:09] <zul> there is no dpatch i was cutting down on the churn
[06:09] <zul> anyways lunch
[06:10] <Kano> will see if your patch helps me
[06:10] <mjg59> Kano: Where there's no existing patch system, we don't add one. It makes syncing from Debian more difficult otherwise.
[06:10] <Kano> mjg59: a fully outdated module will not be synced...
[06:11] <mjg59> Kano: We sync from Debian every cycle
[06:11] <Kano> i will try to package it correctly...
[06:11] <mjg59> It helps if the packages are as similar as possible
[06:12] <Kano> the debian one even had missing dependenies on the current kernel
[06:12] <mjg59> It's a source package
[06:12] <mjg59> It's not supposed to depend on the kernel
[06:12] <Kano> not the source of course
[06:12] <mjg59> module-assistant is supposed to handle that
[06:13] <Kano> in the control.modules.in 
[06:13] <Kano> you need something like
[06:13] <Kano> Provides: aufs-modules
[06:13] <Kano> Depends: aufs-tools, linux-image-_KVERS_
[06:13] <Kano> otherwise it is not deleted when you delete the kernel
[06:14] <mjg59> Oh, ok
[06:14] <Kano> i found that in 2 packages lately and mailed the maintainers, they did not change it...
[06:14] <mjg59> Have you filed a bug against Debian?
[06:14] <mjg59> Mailing the maintainers will not usually result in things getting done
[06:15] <Kano> the et131x package has the same problems...
[06:15] <Kano> http://kanotix.com/files/thorhammer/updates/et131x/
[06:16] <Kano> there is the same fix included
[06:20] <Kano> i dont ask to add extra kernel patches.. this is always ignored..
[06:21] <Kano> when will be a kernel which has the latest .8 patch?
[06:23] <mjg59> At a point where we're not frozen for the beta release
[06:24] <Kano> sure as patches that add just PCI/USB ids to correct drivers are critical...
[06:25] <mjg59> ?
[06:26] <Kano> i added 2 out of 3 patches i currently use to your bugtracking system, i still patch em on my own...
[06:27] <Kano> the other one was added in the kernel bugzilla, and is still not in it seems...
[06:27] <Kano> only in gregkh tree
[06:28] <Kano> little patches seem to take ages
[06:28] <zul> Kano: which bug numbers I can see if I can get them in
[06:29] <mjg59> Kano: We won't pull stuff from non-mainline trees unless there's a relevant bug
[06:29] <kylem> Kano, if you have issues with people ignoring bugs, please mail kernel-team@ to bring them to our attention
[06:30] <Kano> for me all users are relevant
[06:30] <Kano> and when 1 of those requires a tiny patch i add it
[06:30] <mjg59> Kano: Without a record of a request for a patch and a full justification for why it's needed, we won't apply anything
[06:30] <mjg59> We've got that from you for some bugs, and they'll be handled before release
[06:32] <Kano> https://bugs.launchpad.net/~master-kanotix/
[06:32] <Kano> the 2 medium ones are kernel patches
[06:33] <Kano> will look for the other
[06:34] <Kano> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb/usb-serial-pl2303-support-for-benq-siemens-mobile-phone-ef81.patch
[06:34] <Kano> This patch adds support for the BenQ Mobile Phone EF81 to pl2303
[06:35] <mjg59> Kano: Please file a bug and attach the patch
[06:35] <Kano> ok
[06:36] <mjg59> Thanks
[06:42] <Kano> do you want it as url?
[06:43] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/145284
[06:43] <ubotu> Launchpad bug 145284 in linux-source-2.6.22 "BenQ Mobile Phone EF81 id missing in pl2303 driver" [Undecided,New]  
[06:46] <zul> thanks
[07:40] <jetsaredim> is there a source package for the vmware kernel modules for gutsy?
[07:41] <BenC> bdmurray: Thanks, I'll take a look at it
[07:42] <bdmurray> BenC: Sure, let me know if you need any more information
[07:44] <jetsaredim> i really need to get vmware up and running on my system
[07:46] <jetsaredim> if the kernel team is the maintainer of the vmware-server-modules packages, why haven't they been released for gutsy yet?
[07:46] <Kano> jetsaredim: isnt it in the lrm package?
[07:47] <jetsaredim> it wasn't
[07:47] <jetsaredim> on feisty it was a separate packge
[07:48] <jetsaredim> in either case, I have lrm-2.6.22-12-generic installed and its not in there
[07:48] <jetsaredim> so i guess that's a no
[07:49] <jetsaredim> it was previously called out as its own separate package, though based on lrm
[07:50] <jetsaredim> which - if that's the case - it should just merely be a case of queuing a builds
[07:53] <jetsaredim> Kano: ?
[07:54] <Kano> dont know,why dont you compile the things manually
[07:54] <Kano> http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update113.tar.gz
[07:55] <jetsaredim> what's that?
[07:56] <jetsaredim> i was building the kernel modules by hand before (or as part of the install)
[07:56] <jetsaredim> but then i installed the vmware-server package from the commercial repo and that uses the pre-packaged/built modules
[08:03] <rtg> zul: I just rejected bug #102291
[08:03] <ubotu> Launchpad bug 102291 in linux-ubuntu-modules-2.6.22 "[needs packaging]  et131x driver for Agere ET131x gigabit ethernet cards" [Undecided,Won't fix]  https://launchpad.net/bugs/102291
[08:03] <zul> rtg: ok why?
[08:04] <rtg> zul: After looking at the source code kylem and I decided it needs license clarification.
[08:04] <zul> rtg: ok
[08:09] <mjg59> rtg: Hm. What was the issue?
[08:10] <zul> driver is bsd isnt it?
[08:10] <mjg59> All the files seem to have 3-clause BSD boilerplate
[08:11] <mjg59> Except the makefile, which looks undistributable
[08:11] <kylem> mjg59, indeed.
[08:12] <mjg59> But, well, makefile
[08:12] <mjg59> That one's not hard to deal with
[08:13] <kylem> heh, ok, so i didn't notice it was on the Makefile.
[08:13] <zul> i never really use the makefile that come with the source though
[08:13] <kylem> my face is slightly red.
[08:13] <mjg59> Haha
[08:13] <mjg59> kylem: It's ok, it's hidden under the beard
[08:13] <kylem> what are you staring at
[08:13] <kylem> STOP LOOKING AT ME
[08:14] <zul> so should i still add it? ;)
[08:22] <mjg59> zul: If that's the only issue, I think it's fine
[08:23] <mjg59> Assuming you wrote the Makefile from scratch (which, really, you should do)
[08:23] <zul> sure
[08:24] <jetsaredim> ok - so it sounds like there is some patch work needed for the vmware modules packages to work on gutsy
[08:24] <jetsaredim> can someone point me in the right direction to see if i can get this sorted?
[08:24] <BenC> jetsaredim: it's basically vmware that needs to provide you patches
[08:25] <jetsaredim> they are in the vmware forums
[08:25] <BenC> jetsaredim: and it's not specific to "gutsy", it's a matter of them not working with newer kernel versions
[08:25] <jetsaredim> sure
[08:25] <jetsaredim> i understand that
[08:25] <jetsaredim> i went through that with feisty before i realized there were pre-build packages with the modules in them
[08:25] <jetsaredim> they had issues with 2.6.20 originally
[08:26] <jetsaredim> the fixes were out there to be had, you just had to look around in the vmware support forums to find them
[08:28] <JanC> jetsaredim: I guess filing a bug on launchpad and including a link to those patches might be useful then
[08:31] <jetsaredim> um ok
[08:31] <jetsaredim> i have to say though that there are a few bug reports out there about these packages being missing on gutsy
[08:34] <JanC> well, add the link to the relevant bug then
[08:35] <JanC> but maybe the Ubuntu developers would rather have a promise from someone to maintain this for the next 18 months...
[08:36] <BenC> we aren't including the vmware packages in gutsy
[08:36] <BenC> the pre-built modules at least
[08:37] <BenC> mainly because they too easily conflict with differing versions of vmware products
[08:47] <JanC> BenC: what about other similar modules (e.g. for virtualbox)?
[08:47] <BenC> JanC: wont happen
[08:48] <BenC> JanC: we've been bitten too many times with vm kernel modules causing too many problems with users
[08:48] <BenC> we had to yank vmware kernel modules and vbox kernel module from feisty, 2 days before release
[08:48] <BenC> at the request of the vendor on both counts
[08:52] <JanC> well, at least virtualbox provides their own packages for feisty
[08:53] <kylem> heh, i forgot we had to do that.
[08:58] <BenC> yeah, that experience kind of ruined it for pre-built vm modules :)
[09:19] <rtg> mjg59: Not being a license expert myself, how can you tell that its a 3 clause BSD license? Granted, what I read in et131x_main.c says the right things, but I really wanted to see GPLv2 or BSD.
[09:22] <mjg59> rtg: Compare it to /usr/share/common-licenses/BSD
[09:22] <mjg59> The actual content is basically identical, except for minor formatting changes
[09:31] <rtg> mjg59: I'm not wild about their EULA preamble regarding implied acceptance, but if you think its OK then I'll just go with it.
[09:34] <mjg59> Yeah, that's just ineptitude
[09:34] <mjg59> The license doesn't require us to keep the EULA junk
[09:39] <jetsaredim> BenC: re vm kernel modules - does that mean that there is going to be a source package?
[09:40] <BenC> jetsaredim: vbox has a -modules source package, and vmware provides source with the product
[09:41] <jetsaredim> i don't think that was included in the vmware-server package for feisty
[09:46] <jetsaredim> so i should just remove the vmware-server package and download it raw from vmware then?
[09:48] <jetsaredim> is this change going to be communicated to the larger user community
[09:48] <jetsaredim> cause the wiki still explains how to install from the packages on feisty
[09:50] <BenC> jetsaredim: what package is from the commercial repo, right?
[09:50] <jetsaredim> yes
[09:51] <jetsaredim> the vmware-server package that is
[09:51] <BenC> then the commercial support folks would provide that
[09:51] <BenC> we wouldn't handle it at all
[09:51] <jetsaredim> ie vmware
[09:51] <BenC> no, canonical support
[09:51] <jetsaredim> i wasn't looking for an updated vmware-server package
[09:52] <jetsaredim> just the kernel modules
[09:52] <jetsaredim> because technically the version that i had installed on feisty will work on my upgraded gutsy system, as long as it has the kernel modules
[10:00] <BenC> canonical support works with vmware to provide those packages, and I know they are also looking into providing the modules
[10:01] <jetsaredim> but prolly not until after gutsy is out
[10:07] <rtg> mjg59: Any thoughts on bug #122025? snd-hda-intel after resume appears to be a fairly common  problem. What do you think about adding remove/restore support for snd-hda-intel in the acpi-support package?
[10:07] <ubotu> Launchpad bug 122025 in dell "Audio fails on resume from Hibernate on Lanai" [High,In progress]  https://launchpad.net/bugs/122025
[10:07] <jetsaredim> funny thing
[10:07] <jetsaredim> i just downloaded the newest version of vmware-server (1.0.4) and it builds perfectly against the current gutsy kernel
[10:08] <mjg59> rtg: No, we can't unload and insert the module
[10:08] <mjg59> Applications may have it open
[10:08] <rtg> like the mixer applet.
[10:09] <mjg59> The mixer applet is guaranteed to, and there's no clean way around that
[10:09] <mjg59> But other userspace applications may do as well
[10:09] <rtg> so what do we do about platforms where there is no other workaround?
[10:10] <rtg> fix the driver I suppose.
[10:10] <mjg59> Yup
[10:10] <mjg59> If reinitialising the hardware works, then it's a driver bug - there's something it should be doing on resume that it isn't
[10:38] <bdmurray> mjg59: Did I get the uvcvideo information you needed yet?
[10:40] <mjg59> Nope
[10:41] <bdmurray> Is http://pastebin.osuosl.org/2510 that what you are looking for?
[10:48] <mjg59> bdmurray: Nope - doesn't look like the uvcvideo tracing is turned on
[10:49] <bdmurray> mjg59: and that was trace=255 correct?
[10:49] <mjg59> I think so, yes
[11:22] <bdmurray> mjg59: I'm having a hard time getting more detailed information about where the suspend process is hanging
[11:24] <mjg59> bdmurray: It seems to be pretty clear where it's hanging, but we could do with more data from uvcvideo to find out why it's behaving this way
[11:26] <bdmurray> Whenever I try to suspend with trace=255 enabled the suspend process is much less informative
[11:28] <bdmurray> kernel: [  129.290079]  ieee80211_crypt: unregistered algorithm 'NULL' - is the last thing I see in my kern.log and I lose video on my system so have to reboot