[02:34] <sharms> is the ipw2200bg card currently supported in feisty?  I just booted, restricted manager said it was using driver ipw3894abg  but I didnt see a device, then when I rebooted the card stopped working, I think it may have flashed it with the wrong firmware?
[02:34] <crimsun> err, what?
[02:35] <crimsun> the ipw2200 certainly is supported via the ipw2200 driver
[02:35] <sharms> right but for some reason feisty identified it as ipw3894abg
[02:35] <crimsun> I'm not sure what you mean by "it may have flashed it with the wrong firmware", though
[02:35] <sharms> if I do an ls pci it shows 2200bg
[02:35] <crimsun> which module is loaded?
[02:35] <sharms> not sure, I didnt know if we flash it with firmware like my old wireless card (prism54)
[02:36] <crimsun> well, if by "flash" you mean "upload", then yes
[02:36] <sharms> the first time it was ipw3945.ko, subsequent reboots (with bios error message) use ipw2200
[02:38] <sharms> Its not a big deal for me hardware wise, but if it was somehow related that could be a big issue
[02:38] <crimsun> that's a very odd issue (rather, I've not seen that happen before. PCI ID mismatch?)
[02:38] <sharms> It may have been a bad card from the git-go, I just got it an hour ago
[02:39] <sharms> I believe the first time it booted it identified itself was ipw3945 on the lspci
[02:39] <sharms> but since reboot it said ipw2200
[02:42] <sharms>  ipw3945: MAC is in deep sleep!
[02:42] <sharms> ipw3945: Unable to int nic
[02:43] <crimsun> I suppose you could use /usr/bin/update-pciids
[02:43] <mjg59> ipw2200 and ipw3945 are very different cards
[02:43] <sharms> well it no longer identifies as ipw3945
[02:43] <sharms> it now identifies as ipw2200
[02:43] <mjg59> Given that one is PCI and one is PCIE
[02:43] <crimsun> yeah, that error really makes no sense to me
[02:43] <sharms> but it is conflicting with other devices it says now 
[02:43] <sharms> from the bios that is
[02:43] <mjg59> lspci -n please
[02:44] <sharms> the card is out right now, back to prism54 let me reboot
[02:44] <mjg59> Nothing the drivers do can alter the card in a non-volatile way
[02:45] <mjg59> If it's going in the same slot as a prism54, it's not an ipw3945
[02:49] <sharms> mjg59: http://paste.ubuntu-nl.org/14502/
[02:55] <mjg59> That's certainly an ipw2200
[02:55] <mjg59> It's mini-pci, right?
[02:56] <sharms> ya
[02:56] <sharms> its in my laptop
[02:56] <mjg59> So it can't possibly be ipw3945
[02:57] <mjg59> That's only available in mini-pcie form
[02:57] <sharms> right thats why I was worried maybe ipw3945 might have done something to it somehow
[02:57] <mjg59> No
[02:57] <sharms> ok so then I will just write this one off on bad hardware, I just wanted to run it by you guys 
[03:21] <sharms> mjg59: doing some addition research (looks like you may have been involved in some of this), could it be that my bios may have a whitelist of cards and that could be causing the issue?
[03:29] <sharms> mjg59: how dangerous would it be to use your whitelist bios modifier?
[03:32] <sharms> ha just went for it will let you know
[03:53] <mjg59> BenC: #96480 probably ought to be critical?
[04:40] <BenC> mjg59: marked and milestone'd
[04:40] <mjg59> Ta
[05:32] <BenC> Interesting, latest vmware w6 seems to use vmx extensions on linux
[05:47] <stgraber> hey BenC, about that, I wondered why I can't activate the paravirtualisation stuff with the latest version of VM W6 and a Core2 Duo with the VT ?
[05:47] <BenC> paravirt only works on 32-bit
[05:47] <BenC> and I'm running it enabled right now, so I know it works
[05:48] <stgraber> strange, I'm using 2.6.20-14 on 32-bit
[05:48] <BenC> You have to go to your virtual machine pref's, Other tab, Advanced, and check the box for paravirt
[05:48] <BenC> it's not enabled in ws6 by default
[05:49] <stgraber> yep, but I simply can't because it's grayed with the latest version of ws6
[05:49] <BenC> what build do you have?
[05:49] <stgraber> 42757
[05:49] <BenC> e.x.p build-42757
[05:50] <BenC> you have to power off the vm first
[05:50] <stgraber> it's powered off
[05:50] <BenC> talk to vmware
[05:51] <BenC> Just checked on mine, and it let's me check/uncheck it as long as the vm is powered off, and I've setup for a 32-bit OS
[05:53] <stgraber> hmm, seems to work with an all new VM and the same settings. I'll maybe have to report this to vmware ...
[07:22] <finalbeta> I'm starting to fear Feisty could air with this bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/98782 , And that would render it unusable for me. Check out the latest attached dmesg. I hope I don't overstep any boundaries here, but the desperate... :p. It's 15 minutes now to boot, and the latest 2 kernels give errors about the CD drive also. Dapper and Feisty ran fine, and 2.6.20.9 and lower ran fine.
[07:30] <mjg59> Does it boot at the normal speed if you disconnect the CD drive?
[07:31] <finalbeta> Will try. 
[07:34] <finalbeta> No, doesn't seem to change anything
[07:34] <mjg59> But you no longer get the ata1.01 errors?
[07:34] <finalbeta> Not yet, I'm waiting, it can take a while...
[07:34] <finalbeta> It's just sitting there. (figuratively)
[07:35] <finalbeta> Yep, no more errors, and after the initial stall, It boots much faster.
[07:35] <finalbeta> Already at the login screen.
[07:36] <mjg59> Ok. So it's pretty clearly linked to the unhappiness with the CD drive.
[07:36] <finalbeta> definitely.
[07:36] <mjg59> You're using an 80-wire cable, right?
[07:37] <finalbeta> Ehm, It's a dell laptop. I have no idea what so ever.
[07:37] <mjg59> Ah, ok. Interesting.
[07:37] <finalbeta> I can't screw that part open also...
[07:37] <mjg59> What model?
[07:37] <finalbeta> Tried before, couldn't do it.
[07:37] <finalbeta> Inspiron 8200
[07:37] <mjg59> Ok.
[07:37] <finalbeta> At least 5 years old.
[07:38] <mjg59> Don't have anything with that chipset here
[07:38] <mjg59> I'll have to leave that with Ben, then
[07:38] <finalbeta> I'll add that removing the cd drive fixes it, and add a dmesg to the report when booting without CD drive.
[07:39] <finalbeta> Thanks for helping me out. 
[07:44] <_ion> benc: bzr branch http://johan.kiviniemi.name/software/bzr/hardware_connected/
[07:45] <_ion> benc: Usage example: if modinfo -F alias nvidia-9755 | hardware_connected; then echo "nvidia-9755 compatible hardware is connected" ...
[07:58] <_ion> benc: Assuming all nvidia drivers are moved to a single nvidia-glx package and alternatives are used instead of diverts, here are simplified preinst scripts that should remove *all* old diverts, without a need to list them manually. http://johan.kiviniemi.name/tmp/nvidia-glx-dev.preinst.in http://johan.kiviniemi.name/tmp/nvidia-glx.preinst.in
[07:58] <_ion> s/diverts/divertions/g
[07:59] <fabbione> _ion: you can't just remove diversions. diverts can be done by sysadmins too. you need to be careful there
[08:00] <_ion> fabbione: It only removes diversions made specifically by nvidia-glx packages.
[08:00] <fabbione> and what happens if you hit a custom one? how would you switch to use alternatives?
[08:01] <fabbione> anyway.. it's S U N D A Y
[08:01] <fabbione> and i should stop reading IRC
[08:01] <fabbione> :)
[08:02] <_ion> I haven't really given a lot of thought to special cases in this regard. I believe that when there are multiple nvidia modules installed and the system's supposed to automatically use the right one based on connected hardware, alternatives is the way to go.
[08:03] <fabbione> ok an init script that sets the right links like /lib/modules../volatile
[08:03] <fabbione> s/ok/or
[08:04] <fabbione> given that you can actually change hw across reboot
[08:04] <fabbione> providing a set of alternatives will make it complicated for normal users to switch between driver versions
[08:04] <_ion> nvidia.ko isn't going to be linked using alternatives, but IMO libGL and nvidia_drv.so should.
[08:05] <fabbione> not my call.. but i don't believe alternatives is the right solution
[08:06] <_ion> benc: Any comments to the discussion above?
[09:03] <zdzichuBG> hi