[08:37] <macogw> Would this list be the one where I ask that wpa handling please please please be added?
[08:38] <sn9> hasn't it already been?
[08:39] <macogw> According to my laptop, no
[08:39] <macogw> It'll only take WEP keys
[08:39] <crimsun> which wifi chipset?
[08:41] <macogw> I'm not sure.  Is there something I can type into the terminal to find out?
[08:41] <fatal__> lspci
[08:41] <sn9> assuming it's a pci card
[08:43] <macogw> Intel
[08:43] <macogw> that's showing up a lot....
[08:43] <sn9> is it showing up for the wifi?
[08:43] <sn9> is the wifi built-in, or an add-on?
[08:44] <macogw> Built-in
[08:44] <sn9> then it will be in lspci
[08:44] <sn9> do you have a line that says Intel Pro Wireless?
[08:45] <sn9> if not, it's not intel
[08:45] <nigel_c> wpa_supplicant is probably what macogwis after.
[08:45] <sn9> but that's installed by default
[08:46] <sn9> for all we know, he might have orinoco
[08:46] <macogw> I already tried following that 7-step thing
[08:46] <nigel_c> Yeah.
[08:46] <sn9> sorry
[08:46] <macogw> orinoco is definitely not in the list of what came up
[08:46] <crimsun> macogw: grep -i wireless /var/log/dmesg
[08:46] <nigel_c> What's a girl? :)
[08:46] <macogw> mark of a true geek ^
[08:47] <nigel_c> Or someone just being silly :)
[08:47] <macogw> intel pro wireless 3945
[08:47] <crimsun> macogw: that definitely supports WPA{,-2}
[08:47] <sn9> ah, then it is intel after all
[08:48] <crimsun> and nigel_c's right on the ball; you need to configure network-manager or wpa_supplicant
[08:48] <sn9> wpa worked on that in breezy, and still works (albeit differently) in dapper
[08:48] <crimsun> I'm not a fan of n-m, so I tend to muck with the wpa_supplicant.conf
[08:49] <macogw> well i can tell you that network tools will only take wep codes
[08:49] <macogw> at least the gui
[08:49] <sn9> macogw: is yours ubuntu or kubuntu?
[08:49] <macogw> ubuntu
[08:49] <sn9> 6.06?
[08:49] <macogw> [17179598.124000]  ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[08:49] <macogw> mack@mack-laptop:~$
[08:49] <macogw> yes
[08:49] <crimsun> not much n-m (gui) experience here
[08:49] <macogw> ah wtf did i highlight
[08:49] <nigel_c> And dapper or edgy? The edgy version has some config method changes.
[08:49] <macogw> dapper
[08:49] <crimsun> I can definitely say it's not kernel-related, however, and is probably better addressed in #ubuntu :)
[08:49] <nigel_c> Oops. So much for staying quiet :)
[08:49] <macogw> i dont have the spare box put together yet....that could have edgy on it...
[08:49] <macogw> ok
[08:49] <sn9> macogw: install a pkg called network-manager-gnome
[08:50] <sn9> that will have gui for wpa
[08:51] <sn9> in order for it to work, the wifi must be set to start on boot, and use dhcp
[08:51] <sn9> and NOTHING ELSE
[08:51] <nigel_c> Ah.. I give up on staying quiet... macogw, did you want to use a preshared key?
[08:52] <nigel_c> I don't know what your experience is like sn9, but I found the guis were all useless for psk.
[08:52] <macogw> ok well then something that maybe does have to do with kernel: http://support.dlink.com/products/view.asp?productid=DFE%2D530TX# that pci ethernet card works with fedora and red hat.  according to the posts on the ubuntu forum, it doesnt work on ubuntu, and ive heard that drivers go with kernel so...
[08:53] <sn9> i used the config file myself, but the gui is what is being asked about
[08:53] <sn9> macogw: are you asking about ethernet now? i thought your question was about wifi
[08:54] <macogw> now ethernet, yes...since i was told "hey thats not kernel" and i do happen to be having a problem with "oh crap i cant make this computer be a linux server because that ethernet card doesnt work with ubuntu and im not paying for red hat"
[08:55] <macogw> and that seems like a kernel-ish thing cuz its a driver dealy
[08:55] <sn9> i don't think i've ever seen any kind of ethernet fail to work on ubuntu. fedora and red hat, yes, but not ubuntu
[08:56] <macogw> http://www.ubuntuforums.org/showthread.php?t=240514&highlight=dfe
[08:57] <macogw> http://www.ubuntuforums.org/showthread.php?t=232976&highlight=dfe
[08:57] <macogw> two people seem to be having trouble with d-line ethernet cards
[09:00] <sn9> the 530 uses the via rhine driver
[11:43] <gnomefreak> what is the purpose of wacom?
[11:44] <sn9> the company?
[11:44] <gnomefreak> the driver
[11:44] <sn9> to drive wacom hardware
[11:44] <infinity> (tablets)
[11:45] <infinity> ie: atrists's drawing tablets, some CAD/CAM tablets, and the touch-screens on tablet PCs and some POS systems.
[11:45] <gnomefreak> would that cause a file in restricted-modules to not load
[11:45] <sn9> no
[11:45] <gnomefreak> :(
[11:46] <sn9> are you having nvidia problems?
[11:46] <gnomefreak> lol
[11:46] <gnomefreak> yes
[11:46] <gnomefreak> a .ko file will not load
[11:46] <gnomefreak> adn i can get ouptu with cat
[11:46] <gnomefreak> output even
[11:46] <sn9> there are all sorts of things that can cause nvidia problems
[11:47] <gnomefreak> iirc its the volatile/nvidia.ko file thats not loading. from error it says its not a device
[11:47] <sn9> first of all, are you sure you need the regular nvidia modules and not the legacy ones or the free ones?
[11:47] <infinity> "no such device"?
[11:48] <gnomefreak> sn9: yes its a gforce4 mx4000
[11:48] <infinity> gnomefreak: Which nvidia card do you have?
[11:48] <gnomefreak> infinity: yep
[11:48] <gnomefreak> accourding to the site its still supported with the reg drivers
[11:48] <infinity> Hrm, pretty sure they haven't yet cut support for the GF4MX.
[11:51] <gnomefreak> im going on the assumption that the file it says no such device is in the restricted-modules package not nvidia package
[11:52] <sn9> it's just not seeing the card for some reason
[11:54] <gnomefreak> everything else sees it
[11:54] <gnomefreak> i get the abi warning than that error. alot of wacom errors that end in success
[11:54] <sn9> can you boot into recovery mode and manually probe the module?
[11:55] <sn9> oh, wait. abi warnings?
[11:55] <gnomefreak> will try as soon as im done on dapper
[11:55] <gnomefreak> yes
[11:55] <sn9> is this an upgrade from breezy to dapper?
[11:56] <gnomefreak> the box in question is edgy. but other edgy users got thier accell working
[11:56] <sn9> edgy is a moving target
[11:56] <gnomefreak> i know
[11:56] <sn9> every now and then, things don't work for a while
[12:03] <gnomefreak> is it possible that the mx 4000 is not supported anymore by the glx drivers, maybe the wiki hasnt been updated?
[12:04] <sn9> i doubt that
[12:04] <sn9> more likely, it's temporary edgy breakage
[12:05] <gnomefreak> ok cool ty
[12:18] <BenC> mjg59: ping
[12:18] <BenC> gnomefreak: does Xorg.0.log show that it found the card in the PCI scan?
[12:19] <gnomefreak> BenC: its showing my changes i made to vesa so i can use it
[12:19] <BenC> not sure if that relates to my question :)
[12:19] <mjg59> BenC: Hi
[12:19] <BenC> look in Xorg.0.log for the PCI scanning and see if it even shows that it sees the device
[12:20] <BenC> mjg59: Can you give me some background on that pm_{prepare,restore}_console patch?
[12:20] <mjg59> BenC: VT switching is magic
[12:20] <gnomefreak> ok give me a few minutes im gonna go boot it up and check
[12:20] <mjg59> BenC: Ok. More usefully :)
[12:20] <BenC> and usplash is anti-magic? :)
[12:20] <mjg59> BenC: The kernel does the console changing in order to work around broken video drivers
[12:21] <mjg59> We do it explicitly ourselves, so there's no need for it
[12:21] <mjg59> That's the first argument
[12:21] <mjg59> When the kernel changes vt, any app bound to the current vt gets a signal
[12:21] <BenC> by console switching you mean switching to a VT out of X when we suspend?
[12:21] <mjg59> It needs to respond to that signal in order for the vt switch to be allowed to go ahead
[12:21] <mjg59> Yeah
[12:22] <mjg59> Now that seems to interact really badly with suspend, where userspace tasks are frozen immediately after the vt switch
[12:22] <mjg59> I'm guessing that the signal handling isn't complete before the processes are frozen
[12:22] <mjg59> The kernel then seems to deadlock
[12:22] <BenC> ok, that makes sense
[12:23] <mjg59> We could probably fix this in a complicated way, or we could just strip the unnecessary calls
[12:23] <BenC> so why do we vt switch, if the kernel does it itself?
[12:23] <BenC> because of the same problem?
[12:23] <mjg59> So that we can run vbetool before it switches back to X
[12:23] <mjg59> Otherwise the kernel switches back to X, we run vbetool, X explodes
[12:23] <BenC> ok, I am going to try to summarize this in the commit
[12:27] <BenC> ok, so this went missing in edgy
[12:27] <BenC> dapper still has the patch
[12:30] <gnomefreak> ok looking through log
[12:30] <gnomefreak> (**) |   |-->Device "NVIDIA Corporation NV18 [GeForce4 MX 4000 AGP 8x] "
[12:31] <gnomefreak> im getting that only its a pci not agp :(
[12:35] <BenC> gnomefreak: Look for the line that starts:
[12:35] <BenC> (II) PCI: PCI scan (all values are in hex)
[12:35] <BenC> check in that list to see if it finds the PCI device
[12:35] <gnomefreak> k
[12:37] <gnomefreak> (II) PCI: 00:0f:0: chip 10de,0185 card 0000,0000 rev c1 class 03,00,00 hdr 00   the 00:0f:0 is the hex for the card
[12:38] <gnomefreak> assumming 00:0f:0 is still 00:15:0
[12:40] <gnomefreak> BenC: it also lists the card under PCI-to-ISA bridge:
[12:41] <BenC> gnomefreak: ok, then it sees the card, so that alleviates the issue I was looking at
[12:41] <BenC> gnomefreak: grep EE /var/log/Xorg.0.log
[12:43] <gnomefreak> BenC: sorry i froze what was the grep command again?
 gnomefreak: grep EE /var/log/Xorg.0.log
[12:44] <gnomefreak> i got it
[12:45] <gnomefreak> it doesnt look good :(
[12:46] <gnomefreak> BenC: http://pastebin.com/774708
[12:51] <zul_> BenC: the kernel-package from sid behaves the same way
[02:02] <BenC> gnomefreak: dmesg | grep -i nvidia
[02:02] <gnomefreak> k
[02:02] <BenC> gnomefreak: actually, what kernel do you have installed?
[02:03] <BenC> -386, -686, ...?
[02:03] <gnomefreak> 2.6.17-6-386
[02:03] <gnomefreak> and i dont like the output of that command :(
[02:03] <gnomefreak> http://pastebin.com/774736
[02:05] <BenC> gnomefreak: I'd take this up with nvidia then
[02:05] <gnomefreak> is it the card or the drivers in your best guess?
[02:07] <BenC> hard to tell
[02:07] <infinity> Or the BIOS, or an ACPI bug..
[02:07] <BenC> yeah, I'm thinking BIOS
[02:07] <infinity> If it really is telling the truth, and can't route an IRQ to the card.
[02:08] <BenC> well, there's no error from PCI about not being able to enable the IRQ
[02:08] <BenC> it's mainly that it doesn't see it has one
[02:08] <BenC> I'd check the BIOS settings and make sure the controller has an IRQ for it
[02:08] <infinity> BenC: How do you know?  There's no full dmesg there. :)
[02:08] <BenC> infinity: oh, good point :)
[02:08] <BenC> gnomefreak: put all of dmesg in there please
[02:08] <gnomefreak> that was all of it
[02:08] <BenC> no, it isn't
[02:08] <infinity> gnomefreak: Without the grep.
[02:09] <gnomefreak> oh
[02:09] <BenC> dmesg > dmesg.txt
[02:10] <BenC> lspci -vv >> lspci.txt
[02:10] <BenC> get both of those
[02:11] <gnomefreak> http://pastebin.com/774739
[02:13] <gnomefreak> :(
[02:13] <gnomefreak> heres lspci -vv http://pastebin.com/774741
[02:14] <mjg59> [   61.124183]  PCI: No IRQ known for interrupt pin A of device 0000:00:0f.0. Please try using pci=biosirq.
[02:14] <gnomefreak> other command doesnt output anything and #nvidia just said i need legacy drivers :(
[02:14] <BenC> yeah, that's BIOS/ACPI
[02:14] <infinity> gnomefreak: #nvidia lied.
[02:14] <gnomefreak> k
[02:14] <gnomefreak> good
[02:14] <gnomefreak> i have acpi turned off
[02:14] <mjg59> gnomefreak: Why?
[02:14] <BenC> gnomefreak: Try booting with "pci=biosirq"
[02:15] <gnomefreak> i dont remember
[02:15] <BenC> that's probably the cause there
[02:15] <mjg59> Oh, because it's a 1999 bios
[02:15] <mjg59> gnomefreak: Try booting with acpi=force before pci=biosirq
[02:15] <gnomefreak> add it to /boot/grub/menu.lst?
[02:16] <mjg59> es
[02:16] <BenC> gnomefreak: Or add it to the grub menu by hand, either way
[02:16] <gnomefreak> after the word splash i take it?
[02:17] <BenC> yeah
[02:17] <gnomefreak> ok brb
[02:17] <infinity> gnomefreak: In the "# kopt" section, ideally.
[02:17] <infinity> gnomefreak: So it gets applied to all boot options when update-grub is run.
[02:28] <gnomefreak> ok i played in bios changed irq to auto dmesg nvidia shows this line PCI: Using ACPI for IRQ routing   is that good?
[02:29] <gnomefreak> and anyway to test this before changing xorg?
[02:29] <gnomefreak> thats with the line i put in grub menu
[02:30] <mjg59> gnomefreak: Does it complain about a missing IRQ?
[02:32] <gnomefreak> no it just says if the device doesnt work use lapic
[02:33] <gnomefreak> i think i like this :)  Boot video device is 0000:00:0f.0
[02:33] <gnomefreak> thats teh hex for the pci slot
[02:33] <gnomefreak> that its on
[02:35] <gnomefreak> brb gonna try this
[02:41] <gnomefreak> it works ty guys now i just have an issue i have to work on text isnt being displayed
[02:42] <BenC> that's a known nvidia driver bug
[02:42] <gnomefreak> ok cool
[02:42] <BenC> started occuring in edgy, some kind of xorg/drm interaction
[02:43] <BenC> there's a work around I think, look around for it
[02:43] <gnomefreak> ill try to
[03:09] <BenC> yay for shitty internet access
[03:10] <kylem> that bad, eh?
[03:12] <fabbione> yeah
[03:12] <kylem> eep.
[03:14] <kylem> heh. :/
[04:26] <zul> dentists are so much fun1
[04:26] <zul> ! even
[11:54] <sander_m> Hello. I have a problem with a kernel transplantation. Could someone here help me, or should I go ask on another channel?
[11:56] <sn9> doctor, it's alive!
[11:57] <sander_m> eh?
[11:57] <sn9> kernel transplant
[11:57] <sander_m> hehe :-)
[11:59] <sander_m> I am running Ubuntu i386 on an AMD64. Now I want to replace the kernel (only!) with an amd64-k8 kernel. I got linux-image-amd64-k8 installed, but trying to install linux-restricted-modules-amd64 throws up errors like : ath_hal/ah_osdep.o: file not recognized: File format not recognized
[11:59] <sn9> you can't do it that way
[12:00] <sander_m> Rationale: I want to be able to create an amd64 pbuiler enviroment on mu i386 Ubuntu installation
[12:00] <sn9> if you have a 64-bit kernel, you need 64-bit libs
[12:00] <sander_m> I am running the kernel now :-)
[12:01] <sander_m> It's the modules that give me headaches at the moment.
[12:03] <sn9> doesn't this kind of thing just scream "xen" to you?
[12:04] <sander_m> Probabely, but that would mean a full re-install right? A bit of overkill just to be able to build gnome-hearts for amd64 dapper
[12:05] <sn9> no, the beauty is that you would not need to reinstall a thing, AIUI
[12:06] <mjg59> sander_m: Do you need the restricted modules?
[12:06] <mjg59> They're amd64 objects and they're run through ld, so you'd need a bi-arch binutils
[12:07] <mjg59> Which is probably going to be more pain than you want
[12:07] <sander_m> mjg59 they're not 100% nessecary. I'm running the full system now without them, but I'd like XGL back so I'd need the nviaia kernel modules
[12:07] <mjg59> sander_m: Well, you'll somehow need to deal with binutils in that case, I'm afraid
[12:07] <sander_m> s/nviaia/nvidia
[12:09] <sander_m> and what about regular cross compiling? I can only find info for building i386 beds on amd64 systems, not the other way around
[12:09] <sander_m> s/beds/debs
[12:09] <mjg59> We don't ship the necessary stuff to do that
[12:11] <sander_m> Hmmm... maybe it would be the easiest to simply install a minimal dapper on a spare partition and pbuild my amd64 debs in there