[02:50] <emgent> morning
=== asac_ is now known as asac
[06:24] <osmosis> from a kernel driver perspective, what is the preferred RAID card vendor?
[06:33] <pwnguin> osmosis: ive heard many people suggest software RAID
[06:34] <pwnguin> but I also don't use raid (I should change that)
[08:01] <amitk> osmosis: 3ware has always had good support for linux
[08:03] <amitk> osmosis: http://linas.org/linux/raid.html for other vendors and specific model details
[08:29] <alex_joni> osmosis: my personal oppinion is that software RAID is sometimes easier to recover
[08:30] <alex_joni> if your card has problems, it's not possible to recover the RAID on another machine, unless it's a compatible one
[08:30] <alex_joni> and software RAID doesn't have that much performance loss to be an issue
[09:18] <tjaalton> should I blame the kernel for not being able to resume from hibernation? Worked fine before enabling -proposed
[09:18] <tjaalton> hangs after the message "Suspending the terminal(s)"
=== mdz_ is now known as mdz
=== pgraner_ is now known as pgraner
[19:38] <newz2000> when running virtualbox 1.6 my computer freezes up and the caps lock key blinks. Is there a way I can get any diagnostic information so I can file a bug report with the vendor?
[20:41] <rtg__> soren: ^^
=== emgent_ is now known as emgent
[21:06] <soren> newz2000: Do you have vmware installed, too?
[21:06] <soren> by any chance?
[21:06] <newz2000> no
[21:06] <soren> Hm... Kvm, then?
[21:06] <newz2000> yes
[21:06] <soren> Ah.
[21:07] <soren> That's likely your problem.
[21:07] <newz2000> :-( I can't use them both? Oh bummer.
[21:07] <soren> Not at the same time.
[21:07] <soren> Try unloading the kvm modules (sudo /etc/init.d/kvm stop) and try again.
[21:08] <newz2000> ok, I have to wait until I have finished my current work because I can't handle a hard lock at the moment
[21:08] <newz2000> this is a new problem with virtualbox 1.6 (1.5 worked fine)
[21:08] <soren> The various modules who use the virtualisation extensions in the CPU's have not agreen on a locking mechanism yet, and things go boom if more than one thing tries to use them at the same time.
[21:08] <soren> newz2000: Well, it's a *possible* cause. It might be something completely different.
[21:09] <newz2000> ok, I'll test after a bit
[21:40] <dupondje> https://bugs.launchpad.net/ubuntu/+bug/235889 plz check :)
[21:45] <ceekay> anyone able to clue me in / point me to docs regarding kernel crash dumps at present and possibly where they were as of 7.04? I see it was accepted for hardy on https://blueprints.launchpad.net/ubuntu/+spec/linux-kernel-crash-dump , but the status does not seem to indicate that it was completed
[21:52] <jepler> ceekay: I'd also love to know more about this
[22:10] <emgent> heya
[22:11] <rtg__> Ng: saw your comment about e1000 EEPROM. Can you reproduce the problem reliably so that if I apply a patch you can tell that I fixed something?
[22:16] <Ng> rtg__: the machine in particular showing the problem is silbs' laptop, so while we do have a reliable testcase, we probably shouldn't interrupt her too much ;)
[22:17] <rtg__> Ng: well, if you'll work with her as she has time, I'll apply the patch in my PPA version.  I'll get it done later this evening since she's already left.
[22:19] <Ng> rtg__: ok, I can probably get on it during lunch or so
[22:21] <rtg__> Ng: ok, I'll add a comment to the bug report when its ready. I'm out for a bit...
[22:23] <ceekay> jepler: from what i've seen BenC 's footprints seem to show up in a few places (that link above as well as the grub changelog mentioning something about "we're no longer using kdump kernels") so i suspect he might have an understanding of what's going on/where things have been
[22:51] <BenC> No, we're still using kdump kernels
[22:51] <BenC> just that we are using a different method of loading them that the old menu.lst grub thing I had originally
[23:18] <ceekay> BenC: any documentation out there that i could use to see where things are/were?