[02:47] <mjg59> BenC: Why do we suddenly have the linux-phc insanity?
[02:47] <mjg59> BenC: It provides the ability for people to fry their hardware in exceedingly nasty ways
[02:49] <BenC> mjg59: We don't
[02:49] <mjg59>     UBUNTU: speedstep-centrino: Include linux-phc built-in tables.
[02:49] <mjg59>     Bug: 63789
[02:49] <mjg59> 
[02:49] <BenC> mjg59: All we have is the tables for speedstep-centrino
[02:49] <mjg59> Oh. No, you don't want that either.
[02:49] <BenC> none of the sysfs twiddling is there
[02:49] <mjg59> There's four different sets of tables for dothans
[02:50] <mjg59> And no way of telling which one is correct
[02:50] <mjg59> Using the wrong one risks hardware damage
[02:50] <BenC> I thought each table was matched
[02:50] <BenC> at least that's the way I read it
[02:50] <BenC> we had the tables in dapper/edgy
[02:52] <mjg59> BenC: No, it's matched on cpuid as far as I can tell - that's not sufficient
[02:52] <mjg59> There's a chance it'll either overvolt it (potential hardware damage) or undervolt it (potential instability)
[02:53] <BenC> mjg59: fuck, as it is now we have cpu's that are running hot to the point that user's can't even watch a video on youtube without it shutting down :/
[02:54] <mjg59> Their hardware is broken
[02:54] <mjg59> "fixing" it risks breaking other people's hardware
[02:54] <BenC> but "it works on windows"
[02:54] <mjg59> The Windows vendor knows what CPU they shipped
[02:54] <BenC> and "linux-phc makes this work"
[02:55] <BenC> I hate this
[02:55] <BenC> I have to pick between two groups, but definitely the group that risks hw damage wins
[02:59] <BenC> I wonder if I can disable use of the tables by default
[02:59] <BenC> use a kernel cmdline options to enable it
[02:59] <BenC> sounds like a plan
[02:59] <mjg59> http://lkml.org/lkml/2006/7/3/240
[03:00] <BenC> yeah, I've read the threads
[03:00] <BenC> which is why I yanked the sysfs twiddling
[03:00] <BenC> but I though the tables were safe
[03:00] <mjg59> Check Arjan's message in that thread
[03:04] <BenC> mjg59: Gotcha
[03:35] <zul> hola
[04:00] <reitblatt> where is l-r-m-2.6.20-13?
[04:11] <tritium> Hi BenC 
[06:09] <BenC> doko: I reproduced your gelic_net problem, I'll fix that for next upload
[06:09] <BenC> doko: wow, I'm not sure...I think it might be caused by the last firmware update
[06:10] <BenC> doko: reverting to an older kernel doesn't fix it
[07:00] <reitblatt> BenC: where's l-r-m-2.6.20-13 ?
[07:01] <BenC> reitblatt: last I checked it was on the build systems being processed
[07:01] <tritium> reitblatt: I was able to download it.  (it built correctly)
[07:02] <tritium> But, Atheros support didn't improve.  Still no wireless networking for me with AR5212...
[07:04] <tritium> reitblatt: https://launchpad.net/+builds/+build/313591
[07:10] <reitblatt> BenC, tritium: thanks
[07:28] <mjg59> BenC: That patch I sent you is kind of important - fixes a fairly major regression from edgy
[08:46] <glick> hi
[08:46] <reitblatt> howdy
[08:47] <glick> hey reitblatt 
[08:48] <glick> hey has anyone here read the book linux device drivers third ed. ?
[10:40] <glick> is anyone up?
[02:50] <tepsipakki> BenC: I searched lp but couldn't find a bug open about megaraid (PERC2/DC) not being fired up properly on boot. Installing Feisty beta went fine
[02:51] <tepsipakki> that's a friend of mine reporting
[02:51] <tepsipakki> the hd's weren't found on boot
[02:51] <BenC> tepsipakki: there was some problems with dapper, and pre-release edgy, but feisty should be ok
[02:52] <BenC> dapper requires the -security kernel to work, IIRC
[02:52] <tepsipakki> he said that edgy didn't work either :/
[02:57] <tepsipakki> but I'll ask for more information
[03:01] <AlinuxOS> BenC, well done, everything is perfect. Thank You!
[03:01] <BenC> AlinuxOS: np
[03:01] <BenC> AlinuxOS: I found the bug about 5 minutes after you logged off last week from our debug session :)
[03:01] <BenC> tepsipakki: so it works with feisty?
[03:02] <BenC> AlinuxOS: so you went a long way to helping me find it, thanks
[03:02] <AlinuxOS> BenC, so I've helped in something :)? 
[03:03] <AlinuxOS> BenC, great :) feel free to use my computers sources.. :)
[03:03] <AlinuxOS> always happy to help you all guys.
[03:09] <tepsipakki> BenC: installation works, but on reboot the disks are not found
[03:10] <BenC> tepsipakki: I'm not sure how that can be...
[03:14] <tepsipakki> BenC: yep, doesn't make sense :)
[03:17] <tepsipakki> hum, there is no l-r-m for -13?
[03:18] <reitblatt> tepsipakki: was uploaded several hours ago
[03:18] <reitblatt> try updating
[03:18] <Mithrandir> I NEWed it this morning, iirc.
[03:19] <tepsipakki> ok, thanks
[03:19] <tepsipakki> there were some bugs on nvidia "crashing" :)
[03:19] <reitblatt> yeah, several of them
[03:20] <giri> BenC: ping
[03:20] <BenC> giri: pong
[03:20] <giri> BenC: hi, I am ndiswrapper developer
[03:21] <BenC> giri: hey
[03:21] <giri> I notice that on Summer of Code 2007, ubuntu proposes to improve ndiswrapper installtion
[03:21] <BenC> giri: It wasn't something I was aware of
[03:21] <giri> ah, ok
[03:21] <BenC> I thought it was already pretty easy
[03:21] <giri> I have been trying to find out who to contact about it
[03:22] <giri> actually, I am proposing to improve stability of ndiswrapper
[03:22] <giri> esp with SMP
[03:22] <giri> would you know if I should contact someone else about it?
[03:23] <giri> BenC: right now, ndiswrapper crashes with smp with certain drivers
[03:24] <BenC> giri: For the driver installation, not sure
[03:25] <BenC> giri: For making it more stable under smp, I can help
[03:26] <giri> BenC: actually, what I need is hardware (smp box, various cards to test)
[03:27] <giri> not sure if soc2007 is the way to go about it
[03:27] <giri> or some kind of sponsorship (either through ubuntu or through some other means) would be better?
[03:38] <giri> BenC: sorry to repeat, but could you clarify how you and/or ubuntu can help?
[03:38] <BenC> giri: me, I'm willing to test and channel bugs :)
[03:38] <BenC> giri: Ubuntu, I'd have to talk to some folks
[03:38] <giri> BenC: ok, tia
[03:39] <BenC> giri: Honestly, I think Ubuntu's more willing to sponsor people making opensource drivers, rather than ndiswrapper work, but I can find out
[03:40] <giri> BenC: yes, I am all to aware of ndiswrapper being smudgy
[03:40] <giri> BenC: in fact, that has been one of the major handicaps of this project
[03:40] <BenC> giri: You're probably more than aware of the outside view of ndiswrapper by most of the kernel community :)
[03:41] <giri> BenC: I have spent _way too much time_ on ndiswrapper, with not much help from others (either materially or code contribution)
[03:41] <giri> BenC: talking of kernel community, I have a patch to fix an issue in kernel, but not in the mood for dealing with people ranting about ndiswrapper
[03:42] <giri> BenC: although patch has nothing to do with ndiswrapper
[03:42] <giri> BenC: if you are interested, the patch fixes __vmalloc to allocate memory in GFP_ATOMIC
[03:42] <giri> BenC: right now, if you use __vmalloc with GFP_ATOMIC, it will result in BUG_ON
[03:43] <giri> BenC: __vmalloc is used in couple of places in kernel
[03:43] <giri> BenC: coming back to ndiswrapper, if you could find if/how ubuntu can help, that will be great
[03:44] <giri> BenC: please let me know if anything works out - my address (pgiri@yahoo.com) should be in ndiswrapper project info
[03:44] <tepsipakki> BenC: ok, a bit more info about that megaraid-issue: it's a Dell Poweredge 2400 and he has a mirrored disk pair and installed Feisty on them, LVM in between. Booting it makes drops it to busybox after local-premount, but I could see the megaraid being loaded _after_ that, and it fails
[03:45] <tepsipakki> BenC: clarification; hw-mirrored disks, and LVM on top of that
[03:47] <tepsipakki> err, s/makes //
[03:48] <tepsipakki> he's doing an installation without LVM now
[03:53] <BenC> tepsipakki: sounds more like a sw issue with the initramfs detecting the lvm and such
[03:55] <tepsipakki> that could be it
[03:55] <tepsipakki> there's also an error from modprobe right after local-premount
[03:55] <tepsipakki> but I couldn't trace the source
[03:56] <tepsipakki> it shows the usage of modprobe, so maybe a typo somewhere
[04:11] <tepsipakki> BenC: it worked without LVM
[04:11] <tepsipakki> so not a kernel issue
[04:12] <BenC> giri: Will do, thanks
[04:30] <tritium_> BenC: got the latest l-r-m updates this morning.  I'm using Atheros AR5212 at the airport :)
[04:31] <BenC> tritium_: sweet
[04:31] <tritium_> Many thanks!
[05:03] <tepsipakki> BenC: seems that the root-cause was that the megaraid was in I2O-emulation mode, not in "mass storage" mode :)
[06:44] <pochu> hi all :) I don't know to which package set this bug, any idea? bug 96545
[06:44] <pochu> hi all :) I don't know to which package set this bug, any idea? bug 96545
[06:45] <pochu> is not ubotu here?
[06:45] <Mithrandir> no
[06:49] <ivoks> pochu: you didn't have linux-386 installed before
[06:50] <ivoks> this is a bug that's old as hoary
[06:52] <pochu> LoL
[06:52] <pochu> not my bug though :)
[08:34] <xipietotec> oh...haven't submitted this as a bug yet...been to busy trying to fix my feisty install, but if someone else wants to. The kernel-386 packages for dist-upgrade do not point correctly to the -generic kernels, ergo, no kernel gets installed, but the config files for the kernel does....ergo...no booting. I had to chroot from the live cd into my hd, delete the -386 kernels, and install the -generic kernel
[08:36] <xipietotec> actually I had to download the -generic kernel directly from the packages site, and install it that way...couldn't use the repository method
[08:50] <thotz> BenC: which is the main bug for the update from nvidia-glx (96xx) --> nvidia-glx (97xx) affecting some gforce users? could you tell me this. have we one?
[08:51] <BenC> thotz: Not that I know of
[08:51] <BenC> xipietotec: the -386 should point to -386, not -generic
[08:51] <Mithrandir> thotz: what do you mean?
[08:52] <thotz> BenC: https://launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/96430
[08:53] <xipietotec> BenC: I thought in feisty -386 had been merged with generic?
[08:53] <BenC> xipietotec: No, -686 and -k7 merged together into -generic
[08:53] <BenC> actually, -686, -686-smp, -k7 and -k7-smp have all merged into -generic
[08:54] <xipietotec> ah, okay...bizzare, well anyways, for some reason I had to delete my -386 and install generic...because it did not install the latest -386 kernel when I dist upgraded
[08:54] <anti_pop> 9755 doesnt support cards older than geforce FX series. and it doesnt seem to be possible to use the 9631 from nvidia.com with 2.6.20-13
[08:54] <xipietotec> installed the config for it, but not the kernel
[08:54] <BenC> xipietotec: Were you missing some linux-386 meta packages?
[08:54] <BenC> you should at least have had linux-386 or linux-image-386
[08:54] <thotz> BenC: Do you know now what I mean?
[08:55] <BenC> xipietotec: There's no way to get the config without the image
[08:55] <BenC> thotz: you mean a bug that others can be set as duplicate of, right?
[08:55] <mjg59> anti_pop: Issues with nvidia code generally have to go to nvidia
[08:56] <BenC> yeah, I'm not sure what people are wanting us to do here
[08:56] <BenC> nvidia dropped support, not us
[08:56] <BenC> we can pretty much ship what they provide
[08:56] <xipietotec> BenC: I had configs and kernel images for earlier versions of the -386 kernel, but for the lastest version, ending in .20 or whatever, I had the config file, but no kernel image. Even trying to reinstall the kernel-image to rebuild my initrd wouldn't fix it (it would just hang after checking the root file system) so I had to delete all of them, and then I switched to -generic
[08:56] <Mithrandir> BenC: they want us to ship three sets of nvidia drivers, not just two.
[08:56] <BenC> we vary from that and we start making problems for us and users
[08:56] <thotz> BenC: yes -> http://www.nvnews.net/vbulletin/showthread.php?t=81668
[08:56] <thotz> BenC and http://www.nvnews.net/vbulletin/showthread.php?t=75603
[08:57] <xipietotec> oddly, even if I switched to the older versions of the -386 kernel image, I could not finish booting
[08:57] <thotz> BenC: 2 legacy drivers + 1 new driver = 3 drivers
[08:57] <BenC> No, I know exactly what's going on, I just don't get why this is "Ubuntu better fix it" and not "nvidia better fix it"
[08:57] <mjg59> = more pain and misery
[08:57] <anti_pop> cause its the new feisty kernel that doest work with the 9631 driver ?
[08:57] <BenC> we provide the drivers as a courtesy to users, so they can get the most from their hw
[08:57] <anti_pop> -12 did
[08:58] <BenC> anti_pop: No, that's not it
[08:58] <BenC> 9631 only worked with feisty kernel because I patched it
[08:58] <anti_pop> i see
[08:58] <BenC> you can get 9631 working with feisty if you hand patch it and build it
[08:58] <BenC> google can show you this
[08:58] <anti_pop> well im a user not a developer and have no idea how to do this
[08:59] <mjg59> anti_pop: I recommend contacting nvidia
[08:59] <BenC> but that doesn't lay the responsibility on our laps to make it work
[09:00] <anti_pop> so if you once patched it, why didnt you use that patch for -13 too ?
[09:00] <BenC> we're going above and beyond any other distro already, sticking our necks out to provide the drivers that nvidia makes available. Asking us to go further than that is a little much
[09:00] <mjg59> anti_pop: Because we're not shipping 9631
[09:00] <BenC> anti_pop: the patch isn't for the kernel, it's for the nvidia driver
[09:00] <thotz> BenC: Sure. I still need a master bug for this. I would call it "Master" then. If you don't tell me, I can't help to make launchpad.
[09:00] <BenC> our kernel is perfectly fine
[09:00] <anti_pop> so there is no support for geforce 4,3 on ubuntu ?
[09:00] <BenC> thotz: The one you pointed to is fine
[09:00] <mjg59> anti_pop: There is. Use the 7xxx series driver.
[09:00] <anti_pop> i will not
[09:00] <BenC> anti_pop: There's no support for it in the driver we get from nvidia
[09:01] <BenC> anti_pop: If the driver nvidia ships doesn't work, we can't help it
[09:01] <thotz> thotz: ok, thanks. should i assign it to somebody? 
[09:01] <BenC> thotz: ubuntu-kernel-team, mark it confirmed and medium for now
[09:01] <anti_pop> so concerning that bug, ubuntu will not have 9631 legacy ?
[09:01] <BenC> thotz: thanks
[09:01] <mjg59> anti_pop: Correct
[09:01] <BenC> anti_pop: nvidia is not maintaining drivers that support your card on linux
[09:02] <BenC> anti_pop: hence, we cannot do so either
[09:02] <anti_pop> until yesterday they did
[09:02] <thotz> BenC: I can't set priority. Sorry...
[09:02] <BenC> anti_pop: if we ship the 9631 driver, we cannot ensure that it will remain secure over the lifetime of feisty, which means we open our users up to unsupported and possibly insecure code
[09:03] <BenC> anti_pop: I'd rather not have that hanging on my conscience
[09:03] <BenC> thotz: Ok, I'll get it
[09:05] <anti_pop> hmm, but what would be the difference to the 7xxx legacy driver ?
[09:06] <anti_pop> this is supported, secure code
[09:06] <mjg59> anti_pop: Every extra set of binary-only drivers shipped adds to the support load
[09:07] <mjg59> anti_pop: This results in security updates taking longer, and increases the risk of extra issues being introduced
[09:07] <mjg59> anti_pop: The 7xxx drivers support your hardware. They will be shipped.
[09:08] <thotz> I still not understand why a 7xxx legacy works and a 9xxx legacy shouldn't work. But that's my own oppinion.
[09:09] <mjg59> thotz: Every set of binary-only drivers shipped adds to the suppotr load
[09:09] <BenC> 7xxx driver is maintained by nvidia still
[09:09] <mjg59> thotz: This results in security updates taking longer, and increases the risk of extra issues being introduced
[09:09] <BenC> they've been updating it and fixing issues in it
[09:10] <thotz> BenC: and the 9xxx legacy not?
[09:11] <BenC> thotz: No, nvidia supports 7xxx legacy driver and 9xxx tip driver
[09:12] <BenC> for us to keep supporting new cards, and retain security fixes, we have to follow the latest in both those lines
[09:12] <BenC> we are at nvidia's mercy as to whether or not they drop support for particular chipsets
[09:12] <anti_pop> what does "tip" driver mean ?
[09:12] <BenC> the 7xxx series legacy driver is a direct result of users, like you guys, complaing to nvidia, not Ubuntu, about losing support
[09:12] <BenC> anti_pop: It means the newest version of their driver
[09:13] <anti_pop> http://www.nvnews.net/vbulletin/showthread.php?t=81668
[09:13] <BenC> 7xxx driver is a fork maintained to support older cards that they stopped supporting in the latest driver
[09:13] <anti_pop> they realease a 9631 legacy and dont maintain/support it ?
[09:14] <BenC> anti_pop: Yes, they support it until 9632 comes out, then you have to use that
[09:14] <BenC> each time they release a new version, you have to update to the newer version if you want security and stability fixes
[09:15] <anti_pop> so there is only 1 real legacy driver (7xxx)
[09:15] <BenC> yes
[09:16] <anti_pop> so everyone with a nvidia card <FX who will install feisty fawn is forced to use this old legacy driver
[09:16] <anti_pop> not good imo
[09:17] <BenC> what's not good about it?
[09:17] <BenC> anti_pop: Is there something wrong with the 7xxx driver on those chipsets?
[09:17] <anti_pop> fixed problems in updated drivers ?
[09:17] <mjg59> Which ones?
[09:17] <BenC> the "fixed problems" are problems affecting cards > than the ones dropped
[09:18] <BenC> 7xxx is maintained, let's not forget this
[09:18] <xipietotec> anti_pop: everyone who has a <FX card, who upgrades to any latest version of any distro out there, will have to use the 7xxx driver, because Nvidia dropped support for the chipset in *their* latest driver releases.
[09:18] <BenC> hence using it isn't a problem
[09:18] <anti_pop> ok, thanks for all this useful input
[09:18] <BenC> anti_pop: If you installed a linux distro today that didn't come with nvidia drivers, and went to nvidia's site to download them, you'd get the 7xxx driver
[09:19] <anti_pop> what is the way to setup stuff like twinview with legacy driver ?
[09:19] <BenC> same way as with the regular driver
[09:19] <BenC> it has a control panel and all
[09:19] <anti_pop> nvidia-settings ?
[09:20] <BenC> yes
[09:20] <xipietotec> anti_pop: don't like the state events? support nouveau
[09:20] <anti_pop> definitly!
[09:20] <anti_pop> i think i have to add a comment to that bug
[09:21] <mjg59> Please don't add comments to bugs unless they add new information
[09:21] <anti_pop> i think most people dont know what the 7xxx legacy is
[09:22] <anti_pop> and maybe the packages nvidia-glx and nvidia-glx-legacy should contain for which card they are
[09:22] <anti_pop> on information
[09:22] <anti_pop> sorry for my english
[09:31] <anti_pop> well the legacy driver is not working here
[09:32] <mjg59> anti_pop: Please file a bug about it
[09:32] <anti_pop> i have to make sure i didnt do something wrong first
[09:40] <alucard> my make-kpkg won't do anything, it just stops and says "nothing to be done" can anyone help me
[09:42] <alucard> my make-kpkg won't do anything, it just stops and says "nothing to be done" can anyone help me
[11:00] <ScottK> Is this the best place to discuss network related kernel bugs? I'm specifically interested in [Bug 86742]  D-Link AirPlus DWL-G650 Wireless (rev.C) - Atheros AR5212 (rev 01) does not work in Feisty
[11:02] <Lure> ScottK: from earlier today:
[11:02] <Lure> [Mon Mar 26 2007]  [16:30:47]  <tritium_> BenC: got the latest l-r-m updates this morning. I'm using Atheros AR5212 at the airport :)
[11:03] <BenC> ScottK: Make sure you have latest -13 kernel + lrm
[11:03] <ScottK> I do have the latest (-13 kernel).  
[11:03] <ScottK> l-r-m?
[11:04] <JoseStefan> restricted modules
[11:05] <ScottK> OK.  I'll check that then.  Thanks.
[11:14] <lifeless> BenC: ping
[11:14] <BenC> lifeless: hey
[11:15] <lifeless> am I confused ? :). I thought you had previously been involved closishly with svn (and I know you're not sussman)
[11:15] <BenC> lifeless: yeah, a few years ago I was doing a lot in regards to memory consumptions and stuff in svn
[11:16] <lifeless> right
[11:16] <BenC> but I'm only involved by name anymore
[11:16] <lifeless> thats cool
[11:16] <lifeless> we have this bug (OT here) :) that would be nice to get someone at svn to care about.
[11:16] <lifeless> and I thought you might know who to prod to make that happen.
[11:17] <BenC> sussman is one
[11:17] <lifeless> it breaks the cscvs package's test suite.
[11:17] <BenC> doesn't svn have a channel on freenode?
[11:17] <lifeless> yah
[11:18] <lifeless> it would suck to ship feisty broken though; if we dont get traction through regular channels soon, perhaps you could email sussman an introduction ?
[11:18] <BenC> sure
[11:18] <lifeless> thanks
[11:19] <ScottK> It was lack of lrm that did it.  Installing that solved my problem.  Thank you very much Lure, BenC, and JoseStefan.  I'll update that bug.
[11:20] <JoseStefan> make sure you have the meta package, so you can avoid that, dont remember the name right now
[11:21] <BenC> ScottK: sudo apt-get install linux-generic
[11:21] <BenC> that will keep things up-to-date
[11:21] <BenC> ScottK: Please just set the bug to rejected or fix-released whichever you feel is appropriate
[11:22] <ScottK> BenC: Will do.  I'll also update the wireless wiki support page too.
[11:22] <BenC> ScottK: for reference on that page, note we have madwifi 0.9.3 now
[11:22] <BenC> link to it's support page would probably make things a lot easier to maintain
[11:23] <ScottK> OK.  I'll take a look at that too.
[11:26] <[g2] > crimsun, around ?
[11:34] <ScottK> BenC: Which "that page" - I don't think I was thinking the same page needed updating that you did?
[11:35] <[g2] > BenC, how crazy are things for the release ?