[01:26] <DB42> to whoever fixed the usb quirk for the "microsoft sound system 80" thanks, it works perfectly now
[08:03] <Johninky> hello all
[08:03] <Johninky> Can I ask a quick question please, might take a long answer
[08:04] <Johninky> How can I take .inf file and create a driver for ubuntu 8.04
[08:05] <Johninky> or would it work, I have tried ndisgtk and  ndiswrapper
[08:24] <mjg59> Johninky: You can't
[08:24] <Johninky> I can what
[08:24] <Johninky> cant^^
[08:25] <Johninky> oh never mind I was a little slow on that one
[08:25] <Johninky> sorry
[09:02] <kraut> moin
[16:43] <DB42> i moved from 7.10 to 8.04 in my laptop and now i have no wifi and no ethernet
[16:44] <DB42> can i downgrade to ipw3945 ? 
[16:44] <DB42> ipl is giving me lots of errors and isn't working
[16:46] <DB42> is there a ipw3945 .deb i can d/l for 8.04 ?
[16:53] <DB42> is there an IPW3945 PACKAGE for UBUNTU 8.04 ??
[16:57] <rtg> DB42: install linux-backports-modules in order to get iwlwifi 1.2.25
[17:00] <DB42> ok i've submitted bug report with my problem: https://bugs.launchpad.net/ubuntu/+bug/219268
[17:00] <ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New] 
[17:01] <DB42> rtg: hmm
[17:02] <rtg> DB42: support in 1.2.25 for the 3945 is a little better.
[17:02] <DB42> rtg: which one is for the -generic ?
[17:02] <DB42> rtg: is there a way to revert to ipw /
[17:03] <DB42> for the time being ?
[17:03] <DB42> (without moving to 2.6.22)
[17:03] <rtg> DB42: ipw is gone.
[17:03] <DB42> no .deb package ? :|
[17:03] <DB42> i tried compiling it, no go
[17:03] <DB42> rtg: which backports do i need to install for 2.6.24-16-generic ?
[17:04] <rtg> DB42: try 'sudo apt-get install linux-backports-modules-hardy'
[17:05] <DB42> installing now
[17:05] <DB42> rebooting laptop, let's hope for the best
[17:06] <DB42> i need to do anything after instaling and before rebooting ?
[17:06] <rtg> DB42: nope
[17:08] <DB42> btw this is a backport from what ? 8.10 ?
[17:08] <DB42> :( same error
[17:08] <DB42> problem still there
[17:09] <DB42> it's 1.2.25
[17:10] <DB42> rtg: any other idea ?
[17:10] <rtg> DB42: looking...
[17:12] <DB42> btw, using wicd as network manager if it's of any use
[17:14] <rtg> DB42: what kind of AP connection are you trying to make? WPA Enterprise? Add that to the LP report as well as any noise from /var/log/syslog. Attach it to the LP report, not pastebin. I'll make sure Intel sees the bug report.
[17:14] <DB42> WPA yes
[17:15] <DB42> hmm.. i'll try an unsecure one, and see if it works
[17:15] <rtg> DB42: personal or enterprise?
[17:15] <DB42> personal
[17:18] <mdz> BenC: is it possible to do sysrq-like actions programmatically, e.g. through sysfs or proc?
[17:18] <DB42> rtg: another problem
[17:18] <DB42> my ethernet card isn't working in 2.6.24-16-generic as well ...
[17:18] <mdz> there's /proc/sysrq-trigger...
[17:18] <DB42> hwlist -C networ tells me it's disabled
[17:19] <BenC> mdz: probably, but if the hang is "system", then I'm not sure that would help
[17:19] <mdz> BenC: yeah
[17:20] <rtg> DB42: the rt8139 is well supported. Is this an HP laptop?
[17:20] <mdz> is it possible to serially debug our kernel without modifications?
[17:20] <BenC> I'm getting a base install so I can run the erase command from command line
[17:20] <DB42> rtg: check the bug report, lenovo 3000 n100
[17:20] <DB42> it's an 8139too driver
[17:21] <DB42> i connect a ethernet cable and i don't get in dmesg "link up or down" but the module for 8139too is loaded
[17:21] <rtg> DB42: i see it now. Is the cable plugged in (since you've been using wireless) ?
[17:21] <DB42> yeah
[17:22] <rtg> DB42: never mind
[17:22] <DB42> it's plugged in, but doesn't apear in ifconfig
[17:22] <DB42> and nothing in dmesg
[17:22] <BenC> cjwatson, soren: does blockdev-wipe run on the physical drive, or on the encrypted lvm?
[17:22] <mdz> BenC: the former
[17:23] <rtg> DB42: 'ifconfig -a' ?
[17:23] <BenC> So the fact that this happens for encrypted is just that blockdev-wipe gets run when it normally doesn't
[17:23] <mdz> BenC: well, it runs on the device underlying the encrypted one, AIUI
[17:23] <DB42> rtG: i see eth0 and eth1
[17:23] <mdz> not the physical drive but an unencrypted block device
[17:23] <BenC> mdz: so the wipe isn't being encrypted, right?
[17:23] <rtg> DB42: eth0 is likely the realtek controller.
[17:23] <DB42> yeap
[17:23] <BenC> ok
[17:23] <DB42> check my dmesg on the bug report
[17:24] <mdz> BenC: I think not, but I don't have it in front of me
[17:24] <DB42> it has the RealTek anme there
[17:24] <mdz> alt+f2 during the erase and ps
[17:24] <rtg> DB42: what happens if you 'sudo ifconfig eth0 up'
[17:24] <DB42> rtg: i need to go to a place with ethernet connection and check :)
[17:24] <DB42> sec
[17:25] <mdz> BenC: lib/crypto-base.sh:crypto_wipe_device in partman-crypto
[17:26] <mdz> BenC: seems to say it is in fact writing through dm-crypt when it does the wipe
[17:26] <DB42> rtg: thanks, eth works now
[17:27] <rtg> DB42: so, pluggin it in to a switch fixed it?
[17:27] <DB42> no
[17:27] <DB42> ifconfig eth0 up did
[17:27] <rtg> DB42: hmm. Are you running NetworkManager?
[17:27] <DB42> no, as i said i'm using wicd
[17:27] <rtg> DB42: wicd only works on wireless, right?
[17:27] <DB42> NM didn't work well with my wireless card in 7.10
[17:28] <DB42> nop, wired as well
[17:28] <rtg> DB42: you ought to try NM again. maybe it'll work better with the i3945.
[17:29] <DB42> rtg: i'm trying to conect unencrtyped now and see if it's ok
[17:29] <DB42> how so ? the problem is in the microcode..
[17:29] <DB42> and when i boot to 2.4.22 for wifi now (on 8.04) i still need the wicd
[17:29] <DB42> and i can't have them both
[17:29] <rtg> DB42: indeed, but it could be a function of the kind of packets being transmitted. who knows.
[17:29] <BenC> mdz: so does d-i call blockdev-wipe for this progress?
[17:30] <mdz> BenC: yes
[17:30] <rtg> DB42: you could boot with the lice-cd and try it. that way you don't have to re-install.
[17:30] <rtg> s/lice-cd/live-cd/
[17:30] <DB42> rtg: i rather d/l it when the final is out :|
[17:31] <mdz>         /bin/blockdev-wipe -s 65536 $dev > $fifo &
[17:31] <DB42> also don't have media to burn it on
[17:31] <mdz> [...]        while read x <&9; do
[17:31] <mdz>                 db_progress STEP 1
[17:31] <rtg> DB42: the RC was announced an hour ago.
[17:32] <DB42> btw, i reported a bug in my sound card and did a system update 2 days after, and the bug disappered :)
[17:32] <DB42> that was pretty cool
[17:32] <rtg> DB42: probably a function of updated ALSA in LUM.
[17:33] <BenC> mdz: I can't get blockdev-wipe to reproduce from command line
[17:33] <DB42> the model i had needed to be added to usbquirks.h or so
[17:33] <DB42> (it worked ok in 7.10, but not in 8.04)
[17:34] <mdz> BenC: soren was trying that as well
[17:35] <BenC> The fact that blockdev-wipe output is useless after 24 lines doesn't help either
[17:35] <BenC> wonder if I can easily wrap it in some shell script to put the asterisks on a single line instead of separate
[17:36] <CYREX> I see that the release candidate includes the 2.6.24-16.30 of Ubuntu but will the final version include Kernel 2.6.25 since it came out yesterday
[17:36] <mdz> BenC: | grep -n --line-buffered ''
[17:36] <DB42> CYREX: how so ?
[17:36] <rtg> CYREX: no
[17:36] <DB42> CYREX: 8.04 is freezed already
[17:37] <CYREX> is frozen mean no kernel changing
[17:37] <DB42> mean no change at all besides bug fixes
[17:37] <DB42> mean no change at all besides bug fixes
[17:37] <CYREX> oki thank you
[17:38] <BenC> mdz: not particularly supported by busybox grep
[17:38] <BenC> :)
[17:38] <mdz> oh, you're in d-i
[17:38] <BenC> figure that's the best way to repro it
[17:38] <mdz> BenC: |while read x; do date; done ?
[17:39] <mdz> or similar
[17:40] <DB42> rtg: i'm trying a manual connection, how do i list SSIDs ?
[17:43] <rtg> DB42: sudo iwlist wlan0 scanning
[17:44] <DB42> i get "Failed to read scan data: Resource temporarily unavilable"
[17:45] <rtg> DB42: probably because the firmware has crashed.
[17:46] <DB42> tried removing / reloading the iwl, didn't help ..
[17:47] <DB42> i'll try restarting with no wifi, seing if it helps
[17:47] <DB42> how do i blacklist auto-loading of iwl3945 @ boot ?
[17:47] <DB42> (in kernel boot lie)
[17:51] <BenC> mdz: | while read x; do echo -n "$x"; done
[17:51] <rtg> DB42: add it to /etc/modprobe.d/blacklist
[17:51] <BenC> that worked
[17:52] <DB42> rtg: yeah i wanted it in boot though (since i already reboot)
[17:52] <DB42> but nm, i did a check
[17:52] <DB42> it happens as soon as i type in CLI "iwlist eth1 scan" without even using a network manager
[17:52] <DB42> i updated my bug report to reflect it
[17:53] <DB42> https://bugs.launchpad.net/ubuntu/+bug/219268
[17:53] <ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New] 
[17:54] <DB42> welp for now i guess i'll go back to 2.4.24
[17:54] <DB42> i mean 2.6.22 ... :)
[17:54] <DB42> rtg: no .deb package no backport no nothing for ipw ? :|
[17:55] <rtg> DB42: nope. the regulatory daemon is gone.
[17:57] <DB42> what is "LBM" and "LUM" ?
[17:57] <rtg> linux-backports-modules, linux-ubuntu-modules
[17:58] <DB42> k
[17:58] <DB42> now for the big test, checking if hibernation is fixed in 8.04 for my laptop :)
[18:06] <DB42> yippy
[18:06] <DB42> cool, the cpu fan seems to work after hibernation
[18:06] <DB42> it didn't in 7.10
[18:08] <DB42> so rtg need anything else for my report ?
[18:08] <DB42> will the intel people respond on the bug report itself ?
[18:09] <rtg> DB42: they might, but I think they are losing interest in 3945 in favor or more recent adapters (4965)
[18:10] <DB42> ouch :(
[18:11] <DB42> well if this isn't a specific case of mine, there are still lots of people with 3945 out there (the lenovo 3000 n100 is popular i belive)
[18:11] <DB42> i also think it might be tramuatic for some users that load ubuntu and won't have wifi
[18:11] <rtg> DB42: it doesn't fail for everyone, but I have seen the microcode issue before.
[18:12] <DB42> is there any documentation of the chipset that can tell me what is that specific error ?
[18:12] <rtg> DB42: not that I'm aware of
[18:13] <BenC> mdz: I'm starting to wonder if this is a blockdev-wipe issue...from one run to the next, it goes at different speeds
[18:13] <BenC> like now I'm at 47%, and it would have been done by now on the run before this
[18:14] <mdz> BenC: what are you using for the source? urandom?
[18:16] <mdz> BenC: there's some debugging available if you recompile it, but it's pretty dead simple
[18:17] <BenC> mdz: the stock d-i one, so it's /dev/zero
[18:17] <BenC> mdz: does d-i use default /dev/zero, or does it -f=/dev/urandom?
[18:17] <mdz> BenC: urandom, I believe
[18:17] <BenC> where is the d-i log kept nowadays?
[18:18] <mdz> BenC: oh, nm
[18:18] <mdz> it's using /dev/zero, but writing through a random cryptoloop
[18:18] <BenC> ok
[18:18] <mdz> so blockdev-wipe writes zeros, but what gets written to the device should be random
[18:18] <BenC> ok
[18:18] <mdz> maybe the intervening cryptoloop is what's getting hung up
[18:19] <mdz> are you setting that up in your test environment?
[18:19] <BenC> well, what gets written isn't really random, just encrypted 0's
[18:20]  * BenC chuckles at encrypted 0's
[18:21] <rtg> BenC: maybe it would go faster with unencrypted zeroes :)
[18:22] <BenC> -f=/dev/unencrypted-zeroes
[18:22] <BenC> ENODEV
[18:27] <BenC> mdz: I'm using the devices setup by d-i
[18:27] <BenC> switching to console
[18:28] <BenC> ...after partman runs
[18:30] <mdz> BenC: well, it's encrypting with a random key from /dev/urandom, so it should be pretty random
[18:30] <mdz> I wonder why it does it this way rather than just writing random data to the device
[18:30] <BenC> Ok, I just got a completely different hang
[18:30] <mdz> straight from /dev/urandom to whatever without going through device-mapper
[18:30] <BenC> during dhcp...keyboard started it up again...
[18:31] <BenC> wonder if that's a red herring, or for real hang like we are seeing otherwise
[18:32] <BenC> whoope, nope, same hang repeated
[18:32] <BenC> mdz: Ok, this isn't blockdev-wipe related then
[18:33] <BenC> I got network dhcp screen to hang twice in a row
[18:33] <BenC> stayed at 100% until I hit shift key
[18:33]  * BenC starts to blame kvm
[18:34] <BenC> and note that even though nothing in d-i uses the mouse, the kernel and kvm both pay attention to it, so that would explain the kickstart from it as well
[18:34] <mdz> BenC: others (including jdstrand) have reported hangs in other parts of the installer
[18:34] <BenC> 3 times dhcp hung...
[18:34] <mdz> even before partitioning
[18:35] <BenC> shift key reliably starts it back up
[18:35] <mdz> there is, as far as I know, only one unconfirmed report of this happening outside of KVM
[18:35] <BenC> right, so I'm thinking these are two separate bugs
[18:36] <BenC> One in kvm (dunno if it's userspace or kernel), and one on that specific bit of hardware
[18:36] <BenC> I'm going to try this -server install on some hardware to try and reproduce
[18:37] <mdz> BenC: dendrobates said that mathiaz experienced some mysterious unreproducible hangs on real hardware when doing server enablement, but I have no information
[18:37] <BenC> Bringing dendrobates here, hopefully hash this out a bit more
[18:37]  * BenC summons the frog
[18:38] <mdz> I pasted him a log excerpt
[18:41] <dendrobates-> BenC: here
[18:41] <mdz> dendrobates-: I can always tell when you're here because my xchat-gnome window resizes to accomodate your nick
[18:45] <mdz> kirkland: are you able to reproduce this easily?
[18:45] <kirkland> mdz: I have not reproduced this at all
[18:45] <kirkland> mdz: I've only tried on real hardware
[18:45] <mdz> ah, I see
[18:45] <BenC> dendrobates: I reproduced the hang...but, I was able to reproduce it during dhcp as well as during crypt erase
[18:46] <kirkland> mdz: and with a 300G drive, the device zero'ing takes FOREVER
[18:46] <mdz> Ben and I are starting to think that the primary bug here is kvm-specific
[18:46] <mdz> and there may be a separate issue or two which are hardware-specific
[18:46] <mdz> kirkland: you can manually adjust the size of the device to mitigate that; I did it yesterday
[18:46] <BenC> dendrobates: so this isn't specific to blockdev-wipe usage...which leads to believe even more than what we are seeing in kvm is not likely the same bug as what was reported on real hw
[18:47] <kirkland> BenC: have you given any thought to the empty entropy suggestion one commenter gave?
[18:47] <dendrobates> even in kvm it is not limited to blockdev-wipe.
[18:47] <BenC> kirkland: blockdev-wipe uses /dev/zero, and a key, so there's no entropy involved
[18:48] <BenC> kirkland: plus, it's not just during that operation
[18:48] <kirkland> BenC: right, my question is probably more d-i specific...  anywhere else in the installer that might rely on /dev/random?
[18:48] <mdz> kirkland: not on a recurring basis
[18:48] <dendrobates> both jdstrand and I are seeing it appear at various places during the install, but it always occurs during blockdev-wipe.
[18:48] <kirkland> particularly something that might have been introduced in hardy, since this is looking like a regression since gutsy
[18:49] <mdz> I think the encryption aspect is a red herring
[18:49] <dendrobates> mdz: I do as well.
[18:49] <mdz> the installer just spends a lot of time (and makes a lot of system calls) there
[18:50] <dendrobates> All I know for sure is that it is easy to reproduce with lvm+crypt.
[18:53] <BenC> I'm going to try and reproduce under kvm on gutsy
[18:53] <BenC> that should give us a reliable answer
[18:54] <dendrobates> we have already tried to reproduce it installing Gutsy on a Hardy kvm, with no success.  That seems to point to someting in Hardy.
[18:55] <BenC> dendrobates: Ok, I'll try the other way (install hardy on gutsy)
[18:55] <BenC> dendrobates: but yeah, that's an interesting point too
[18:56] <dendrobates> I am going to try a pre-beta hardy image.
[18:57] <dendrobates> I have a daily build from dec-5
[18:58] <BenC> All I have are 32-bit 7.10 CD's
[18:58] <BenC> Where are the gutsy live cd's?
[18:59] <mdz> BenC: http://releases.ubuntu.com/7.10/
[18:59] <dendrobates> BenC: can't you reproduce it in 32bit?
[18:59] <BenC> thanks
[18:59] <BenC> dendrobates: I'm sticking with what soren told me...haven't tried 32-bit yet :)
[19:00] <BenC> well, I did on my laptop, but it wouldn't repro there
[19:00] <dendrobates> BenC: OK, it does not seem to matter though.
[19:04] <BenC> That's an interesting regression
[19:04] <BenC> hardy nv driver only does 800x600 on my plasma screen, while gutsy starts up at 1280x1024
[19:07] <BenC> Ok, I happen to have 32-bit handy, so I'll try that
[19:12] <dendrobates> I was not able to reproduce it with an older hardy iso, but,  the hardy daily from Dec does not do the erase on lvm+crypt, which is the most reliable way I have found to reproduce it.
[19:13] <dendrobates> mdz: do we have an archive of the daily builds somewhere?
[19:14] <dendrobates> or the alpha releases?
[19:15] <mdz> dendrobates: slangasek would know
[19:15] <mdz> I'm sure we do, but I don't know where
[19:15] <mdz> (of milestones at least)
[19:54] <BenC> hmm
[19:54] <BenC> This might not be possible to test
[19:55] <BenC> Gutsy kvm doesn't support the gfx boot it seems
[19:56] <JanC> BenC: there is a sed line to "fix" the gfxboot issue
[19:56] <JanC> (if that's useful)
[19:56] <BenC> Sure
[19:57] <dendrobates> B$ sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < ubuntu-7.10-server-amd64.iso > ubuntu-7.10-server-amd64-nogfxboot.iso
[19:57] <BenC> dendrobates: thanks
[19:57] <dendrobates> a little brutish, but it works.
[19:57] <BenC> can I hexedit it instead? :)
[19:58] <JanC> it's documented on https://wiki.ubuntu.com/KvmVirtManagerEtc#head-80f0e334a1de270252f62ac69183da2ed58edf3f 
[19:58] <JanC> (the sed line)
[19:58] <JanC> BTW: does anybody know when vmware server & which version will be available for hardy?  (question from someone I know who uses it professionally)
[20:02] <BenC> yep, hexedit is much faster, it solved it, thanks
[20:07] <arcticpenguin380> what processor is ubuntus kernel optimized for?
[20:08] <JanC> arcticpenguin380: depends on which kernel you mean  ;)
[20:08] <arcticpenguin380> hardys.
[20:09] <JanC> hardy has several kernels included
[20:09] <JanC> but -generic kernel is optimized for 686 IIRC
[20:09] <arcticpenguin380> are all hardys kernels 2.6.24?
[20:09] <JanC> yes
[20:11] <arcticpenguin380> oh and is ext4dev compiled?
[20:14] <JanC> I don't think so
[20:15] <JanC> well, /proc/filesystems doesn't list it
[20:43] <BenC> soren: is there supposed to be a way to make kvm emulate 64-bit when running under a 32-bit kernel?
[20:44] <BenC> otherwise, I gotta download a 32-bit -server CD :/
[21:13] <soren> BenC: No can do.
[21:35] <BenC> Ok, I'm off, and will return in a few hours to continue tracking this down (and over the weekend)
[21:47] <DB42> rtg: here ?
[21:48] <DB42> rtg: http://ubuntuforums.org/showthread.php?p=4612681 fixes the problem
[22:26] <sn9> is anybody actively working on Bug #88746? if so, i'm willing to provide needed info
[22:26] <ubotu> Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [Undecided,Invalid] https://launchpad.net/bugs/88746
[22:27] <sn9> having usb2 broken in feisty, gutsy, _and_ hardy is a bit much
[22:31] <sn9> for perspective, i've had the very same issue on a different machine with a different chipset, a different usb device, and a different distro
[22:31] <sn9> the common element appears to be multifunction usb devices
[22:32] <crimsun> do any of the workarounds ... work for you?
[22:33] <sn9> modprobe -r ehci-hcd
[22:33] <crimsun> so in the absence of a fix that works for everyone, you at least have a viable workaround
[22:34] <sn9> the rest are a bit hard to keep track of
[22:34] <sn9> and that workaround is NOT viable, just like the bug comments say
[22:35] <sn9> after all, apparently that workaround _does_ work for _everybody_
[22:36] <crimsun> that's precisely what I mean.
[22:36] <crimsun> /you/ have a viable workaround.
[22:36] <sn9> huh?
[22:36] <crimsun> I asked if any of the workarounds work for /you/, and you responded with "modprobe -r ehci-hcd"
[22:37] <crimsun> (obviously it's not preferable)
[22:37] <sn9> but you said "in the absence of a fix that works for everyone" -- either there's no such absence or there's no such fix
[22:39] <sn9> there's a reason ehci-hcd isn't just blacklisted by default
[22:39] <crimsun> as we're both well aware, and I have no interest in arguing
[22:40] <sn9> so far, i have not encountered any machine with an amd cpu where ehci-hcd works with a multifunction usb device
[22:40] <sn9> strangely, it seems ok on p4's
[22:45] <sn9> what i'm interested in is contributing to whatever efforts to fix this issue once and for all
[22:45] <tjaalton> crimsun: any fix on the horizon for snd_hda_intel suspend/hibernate issue (needs to be removed after resume, otherwise no sound)?
[22:47] <crimsun> tjaalton: I don't head up sound anymore (and haven't for a year).  What's the issue?
[22:47] <crimsun> tjaalton: meaning, I need to know what HDA codec/model is affected
[22:47] <tjaalton> crimsun: oh sorry.. let's see..
[22:48] <tjaalton> crimsun: 8086:293e I guess
[22:48] <crimsun> need the line afterward.
[22:48] <crimsun> (`lspci -nv|grep -A1 0403')
[22:49] <tjaalton> Subsystem: 1043:829f
[22:50] <crimsun> I can guess that's a Realtek, but can you confirm by looking in /proc/asound/card0/codec#0?
[22:51] <tjaalton> yeah.. Realtek ALC883
[22:51] <tjaalton> shame on intel..
[22:52] <crimsun> tjaalton: ok, please pastebin that codec spew.
[22:53] <tjaalton> crimsun: http://pastebin.ubuntu.com/7440/
[22:53] <crimsun> thanks, looking
[22:53] <tjaalton> does it need some hal/suspend quirk?
[22:54] <sn9> hmm, i just tried a suspend, and no more sound...
[22:54] <sn9> ALC885
[22:58] <crimsun> interesting, there's no unmute for autoconfig
[22:58] <crimsun> tjaalton: I presume you're not passing a model= in /etc/modprobe.d/* ?
[22:59] <tjaalton> crimsun: nope
[22:59] <sn9> i know i'm not -- it gets config from the bios
[23:04] <crimsun> tjaalton: ok, I'll ping you.  Looking closer.
[23:05] <tjaalton> crimsun: excellent, thanks