[03:11] <holycow> hey guys
[03:11] <holycow> i have an issue with dapper installer on intel chipsets
[03:11] <holycow> the terminal gets hosed 3/4's of the way through with no appearent way to continue or fix it
[03:12] <holycow> i suspect its a driver issue but hard to tell, would this be a kernel issue or a d-i issue?
[04:26] <newz2000> Hi, I reported bug #96679 and I want to fill in the additional info needed to diagnose the bug...
[04:27] <newz2000> I can't get online when I boot 2.6.20-13, the bug is related to power management
[04:27] <newz2000> is there anything besides uname, dmesg and lspci that will help?
[04:34] <newz2000> ok, well, I'll get that and get back to you
[09:24] <Mithrandir> BenC: do you think including the kqemu module by default would make sense?
[09:34] <Mithrandir> BenC: also, I'm thinking about removing all kernel modules older than 2.6.20 ones (like multiverse/misc/vmware-player-kernel-modules-2.6.15-23, restricted/misc/linux-restricted-modules-2.6.17-10-386 ); I guess you don't mind if I do that?
[09:55] <jml> suspend and resume works on my macbook now.
[09:55] <jml> I love you guys so much.
[11:28] <AnAnt> Hello, the -12 & -13 kernels won't boot on my laptop
[11:28] <AnAnt> I just done an update now
[11:36] <AnAnt> ping ?
[11:37] <varka> AnAnt: perhaps you have more luck in #ubuntu+1
[11:43] <AnAnt> isn't that a kernel issue that should be reported ?
[01:49] <BenC> Mithrandir: I can look into the qemu thing...removing old modules sounds fine
[01:50] <Mithrandir> BenC: I can't get it to boot in vmware either, so either it's really busted or I am incompetent.  I haven't tried on real hardware yet.
[01:50] <AnAnt> BenC: the -12 & -13 kernels won't boot on my laptop, I just done an upgrade today
[01:52] <shawarma> Should http://launchpad.net/bugs/94637 be fixed in the daily server images from the 26th?
[01:56] <pkl_> AnAnt: can you file a bug in launchpad, giving the usual details (dmesg, lspci, dmidecode etc.).  Thanks
[01:56] <shawarma> Ah... uname -v says "Mar 21", so I guess not.
[01:56] <AnAnt> pkl_: I can't boot, so can I give dmesg,lspci,... output ?!
[01:57] <pkl_> AnAnt: can you boot using an older kernel (i.re. -10 or -11) and use that?
[01:58] <AnAnt> pkl_: ok, is there something else other than dmesg,lspci & dmidecode
[01:59] <pkl_> AnAnt: plus when you're booting the -12 and -13 kernels, removing quiet and splash from the Grub kernel line may allow you to see what happened (does it go to a busybox prompt?)
[01:59] <pkl_> no, dmesg, lspci and dmicode should be everything needed :)
[01:59] <AnAnt> pkl_: nope, I just get a message like waiting for root partition
[02:00] <pkl_> AnAnt:  I think there's a couple of other users experiencing similar problems.
[02:01] <shawarma> AnAnt: https://launchpad.net/bugs/75681  ?
[02:02] <AnAnt> shawarma: no, I don't use LVM
[02:02] <shawarma> AnAnt: Ok.
[02:03] <pkl_> shawarma: no, that's quite an old bug.  This bug look like it's caused by recent libata changes to the -12 and -13 kernels.
[02:04] <pkl_> AnAnt: if you file a bug with the above info, it will be looked at.  If it is a duplicate, we'll deal with it then.
[02:05] <shawarma> pkl_: Alright. I just joined the conversation just now and it sounded familiar.
[02:05] <pkl_> shawarma: no problem, there's a lot of these bugs. all looking the same :)
[02:07] <shawarma> pkl_: There sure is. :-)
[03:04] <ph8> hi guys - has anyone complained about .13 latest shutting down their PCs because they're 'too hot' ?
[03:05] <ph8> -13 sorry
[03:05] <ph8> i've switched back to -12 and it's not happening anymore
[05:23] <gicmo_> whois kylem
[05:23] <gicmo_> args
[05:23] <gicmo_> ;-)
[05:24] <gicmo_> kylem: ok, you are that kyle ;-) Just wanted to let you know that I am also here and alive if you have any questions regarding https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96692
[05:27] <kylem> thanks.
[05:30] <mjg59> gicmo_: I've just added a comment
[05:31] <gicmo_> hey Matthew!
[05:31] <gicmo_> long time no see
[05:32] <gicmo_> former youth-hostel roommate in stuttgardt ;-)
[05:32] <gicmo_> personally I am more bothered of https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96480 though
[05:34] <gicmo_> mjg59: *sigh* ;-)
[05:35] <mjg59> Gralghngh.
[05:35] <mjg59> Maybe that's why my battery status has vanished.
[05:37] <gicmo_> mjg59: so any idea how to solve that nasty IDE slowness bug? .. maybe its claims to be and old IDE because of bootcamp or something
[05:38] <mjg59> Kyle and I have a couple of ideaas
[05:38] <mjg59> But it involves special-casing Apple hardware
[05:38] <gicmo_> mjg59: you get a beer in Birmingham if you make my MacPro fast again. My X60 tablet is faster
[05:39] <gicmo_> of course on the tablet the pen doesnt work when display is rotated, I wanted to file another bug for that, but I forgot
[05:39] <gicmo_> linux & hardware ;-)
[05:43] <gicmo_> also, if you need somebody to test stuff regarding https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96480, I am very willing to do that
[05:44] <sterwill> Me too.  I've love to run the latest kernel.  :)
[05:48] <sterwill> Since Boot Camp's BIOS stuff is magic (there's no user interface as far as I know), would it be possible to write a Linux utility that set the SATA controller to show up as an AHCI device (like a PC BIOS can do)?  Maybe that's impossible or it wouldn't survive a reboot.  I don't know much about these things.
[05:48] <kylem> sterwill, yes.
[05:49] <kylem> man setpci
[05:49] <mjg59> It wouldn't survive a reboot
[05:49] <sterwill> That was my worry.
[05:49] <kylem> mjg59, so do it in the initramfs.
[05:49] <kylem> ;-)
[05:50] <gicmo_> ohh
[05:50] <gicmo_> sounds magic
[05:50] <sterwill> I understand the bind the kernel AHCI maintainers are in.  Apple doesn't follow the rules, and they don't want to hack up the detection code because it may affect other uses of this controller (which were specifically assigned to run in "piix mode" or whatever the term).
[05:51] <sterwill> Am I right in thinking that if the Apple firmware allowed boot-time configuration of the controller like a PC BIOS might, the card would be correctly detected via AHCI?
[05:52] <kylem> yes
[05:52] <mjg59> That would depend on what configuration it allowed
[05:52] <kylem> all the PC BIOS does is poke config space and initialize the controller
[05:52] <sterwill> Assume it has a "[X]  AHCI mode" setting.  I've seen SATA controllers have these options in PC BIOSes.
[05:53] <exoide> Hi, can someone give me some reference about the .symtab section in an ELF file?
[05:53] <mjg59> sterwill: Assuming it had that option, then yes, it would come up as ahci
[05:54] <kylem> exoide, http://flint.cs.yale.edu/cs422/doc/ELF_Format.pdf
[05:55] <sterwill> The initramfs thing intrigues me.  I don't know much about it.  I stopped building all my own Linux kernels back before boot-time RAM filesystems were used.  :)
[05:55] <sterwill> I know what the RAM fs is used for, but I don't know how to build in scripts/utilities.
[05:55] <exoide> kylem, Is that pdf the TIS specification 1.2?
[05:55] <ivoks> kylem: dapper kernel is under your survailance? :)
[05:56] <kylem> ivoks, yeah
[05:56] <gicmo_> hmm but since it was already working correctly with the AHCI driver if I hacked in that thing in the ahic table if we did that setpci magic in initramfs the ahci driver would pick up the device and it would work just fine? ;-)
[05:56] <ivoks> kylem: there are some funny stuff with serial ports
[05:56] <sterwill> gicmo: Hope so.  :)
[05:56] <mjg59> gicmo_: If you did it early enough, yes
[05:56] <ivoks> kylem: i can't get modem to work :/
[05:56] <mjg59> But less than ideal
[05:56] <kylem> ivoks, file a bug? i'll look at it after feisty kernel freeze.
[05:56] <ivoks> kylem: i did...
[05:56] <kylem> ah
[05:56] <kylem> what bug #
[05:57] <ivoks> sec...
[05:57] <gicmo_> mjg59: hmm right, if you find something better i'll be happy
[05:58] <ivoks> bug #77467
[05:58] <ivoks> kylem: 77467
[05:58] <exoide> kylem, I've read that documentation and It's not enough for me
[05:58] <exoide> kylem, I'm doing a code generator for Linux and I need to know a little more about that section
[05:58] <kylem> so look at binutils, this isn't on topic for this channel.
[05:58] <kylem> ivoks, thanks
[05:59] <exoide> kylem, Can you suggest me a channel?
[05:59] <exoide> kylem, I've tried a lot of channel but nobody answer my question :-(
[05:59] <mjg59> gicmo_: If it needs to be done, it should be done in the kernel
[06:00] <gicmo_> mjg59: fair enough
[06:01] <sterwill> mjg59: Adding the ID to the AHCI list is bad for two reasons: it's hacky because Apple should be using the correct AHCI ID class in the first place; the controller can also be piix and maybe the user wants it that way.  Is this right?
[06:01] <sterwill> Just trying to get things straight for my own knowlege.
[06:01] <mjg59> Yes
[06:03] <sterwill> I had similar fun getting the sound card to work right.  They use Intel's HDA audio chipset but changed all the mixer assignments around.
[06:03] <crimsun> oh, but sigmatels are Oh So Fun.
[06:03] <crimsun> (I suppose they're a bit "better" than Realteks, but that's not any consolation.)
[06:04] <sterwill> I poked through the sigmatel and realtek driver code.  There are a ton of configurations out there.
[06:05] <crimsun> And there will be many more. There are at least three for Mac/Pros alone.
[06:05] <gicmo_> crimsun: omg
[06:05] <sterwill> I didn't know there was more than one Mac Pro sound configuration.  MacBook Pro has a few.
[07:11] <yorokobi> Is SELinux built into any of the kernels for Fiesty?
[07:12] <BenC> it is there but must be enabled with a kernel command line option
[07:13] <BenC> selinux=1 I think?
[07:13] <BenC> mjg59: ping
[07:13] <yorokobi> I've tried that with the generic kernel. dmesg says SELinux is initialized but all of the command-line commands say its disabled.
[07:14] <BenC> I think there's some userspace stuff to it too
[07:14] <yorokobi> And there are no audit entries in /var/log/messages
[07:14] <BenC> if the kernel says it's enabled, then userspace has to take care of the rest
[07:14] <yorokobi> Yeah, I have /selinux and all that 
[07:14] <Mithrandir> you need to install a policy
[07:14] <yorokobi> Targeted is installed
[07:14] <BenC> right, there's a lot to it, from what I understand
[07:15] <yorokobi> Yeah, I had it working in 6.06 then decided to format/reinstall ... 
[07:15] <yorokobi> oh well, I'll play around a bit more and try to find out what I missed.
[07:15] <BenC> selinux-basics, selinux-policy-default packages for starters
[07:16] <BenC> yorokobi: probably some info on wiki.ubuntu.com
[07:17] <mjg59> BenC: Hi
[07:17] <BenC> mjg59: after talking with jgarzik, I've synced our kernel to libata-dev#upstream git
[07:18] <BenC> mjg59: Checking through some things, I noticed that prior to that, "int noacpi;" in libata-core.c was not initialized, so I suspect it was always disabling acpi by default
[07:18] <yorokobi> Argh, gotta put out a fire :) Thanks for your help everyone.
[07:18] <kylem> BenC, uh.
[07:18] <BenC> mjg59: In the new code base, libata_noacpi is set to 1 to by default, jeff says there were regressions
[07:18] <kylem> BenC, global variables are initialized to 0.
[07:18] <BenC> kylem: non-static globals are initialized to 0?
[07:18] <mjg59> BenC: The GTM/STM stuff is required
[07:19] <kylem> BenC, yes
[07:19] <kylem> by .bss
[07:19] <kylem> if you put = 0, they end up in .data and take space in the binary. kind of funny.
[07:19] <BenC> I didn't think global vars went into bss
[07:19] <BenC> maybe I need to refamiliarize myself with some compiler basics :)
[07:20] <BenC> mjg59: Ok, so if I use your patch, then I should be able to have libata_noacpi=0 by default?
[07:20] <kylem> maybe i'm on glue. but i don't think so.
[07:21] <mjg59> BenC: The _GTF code still needs cleaning up a little, so may need to be disabled
[07:21] <mjg59> BenC: But I've got a cleaner patch for you
[07:21] <mjg59> Just let me take a look at what's in -upstream
[07:21] <BenC> mjg59: I already applied yours, so can you patch against git?
[07:22] <mjg59> BenC: Ah, hrm. Might be easiest to revert mine. Give me a couple of minute?
[07:22] <BenC> sure
[07:25] <BenC> 0000000c g     O .bss   00000004 noacpi
[07:25] <BenC> kylem: You were right
[07:25] <kylem> BenC, i don't think i am...
[07:25] <kylem> oh. maybe i am.
[07:26] <BenC> I wonder if that's implementation dependent type stuff
[07:29] <mrec> BenC: I wonder if you had a look at the em28xx stuff lately, you can just pull the changes over the v4l-dvb repository which is on linuxtv.org or pull it directly/completly from mcentral.de now
[07:30] <BenC> mjg59: ata_acpi_push_timings() needs to be static inline for the !CONFIG_SATA_ACPI case
[07:30] <BenC> get multiple defs when building otherwise
[07:32] <BenC> it was defined extern void
[07:32] <BenC> *declared
[07:33] <mjg59> BenC: Ok. Can you revert mine, and add http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/broken-out/libata-acpi-add-infrastructure-for-drivers-to-use.patch
[07:34] <mjg59> and http://www.codon.org.uk/~mjg59/tmp/libata-pata-gtm
[07:34] <BenC> mjg59: yep, thanks
[07:34] <mjg59> If you can push those, then I'll tidy up the integration with Jeff's changes
[07:39] <BenC> mjg59: I get a good chunk of rejects on the second patch
[07:40] <BenC> maybe I can munge it, looks related to the noacpi -> libata_noacpi name change
[07:41] <mjg59> Probably, yeah
[07:41] <BenC> there, patch applies with a little fuzz now
[07:42] <mjg59> Let me know when it's pushed and I'll sort stuff out
[07:44] <BenC> mjg59: pushed
[07:44] <BenC> build tested
[07:48] <mjg59> Pulling
[08:11] <mjg59> BenC: http://www.codon.org.uk/~mjg59/tmp/libata-acpi-cleanup
[08:12] <gicmo_> re
[08:16] <BenC> mjg59: So with this patch we'll have acpi for pata, but not for sata (by default), correct?
[08:16] <mjg59> Yes
[08:16] <BenC> ok
[08:16] <mjg59> Though, strictly, it's not sata/pata
[08:16] <mjg59> It's IDE-style interfaces and non-IDE-style interfaces
[08:16] <BenC> gotcha
[08:16] <BenC> so is non-IDE-style unsafe with acpi?
[08:17] <mjg59> Right now, it's not strictly correct
[08:17] <mjg59> The implementation, that is
[08:18] <BenC> but this gives us at least the same level of support as with ide drivers instead of pata, right?
[08:18] <mjg59> Yes
[08:19] <mjg59> Uhm. I'm assuming you mean that we get the same amount of support in libata as we had in drivers/ide
[08:19] <BenC> right
[08:19] <BenC> mjg59: thanks
[09:36] <tepsipakki> BenC: I merged ndiswrapper from debian.. I don't use it myself, but there was a report it should fix some issues
[09:36] <tepsipakki> I know that the kernel has the latest driver already
[09:36] <tepsipakki> but the tools..
[09:37] <tepsipakki> BenC: do you think it's worth UVFe?
[09:38] <tepsipakki> bug 92155
[09:38] <tepsipakki> hm, no ubugtu here
[09:48] <BenC> tepsipakki: definitely
[09:50] <tepsipakki> cool, I'll file one
[11:12] <BenC> mjg59: ping, re: memstick
[11:25] <mjg59> BenC: Ah, yeah, I'll look into that
[11:25] <mjg59> Need to get a fresh install on the machine with the hardware
[11:30] <BenC> mjg59: Do you have the code handy?
[11:30] <BenC> if you can send it, I can test it (I have memstick hw)