=== amu [~amu@amu.developer.debian]  has joined #ubuntu-kernel
=== Seveas [~seveas@seveas.demon.nl]  has joined #ubuntu-kernel
=== svenl [~luther@AStrasbourg-251-1-75-78.w82-126.abo.wanadoo.fr]  has joined #ubuntu-kernel
=== _rick [~rick@adsl-ull-96-182.42-151.net24.it]  has joined #ubuntu-kernel
[01:20] <_rick> hoi
=== Micksa pokes mjg59
[01:35] <mjg59> Hello
[01:36] <Micksa> hi
[01:36] <Micksa> okay, so the story so far with STR on my laptop is
[01:37] <Micksa> stuff seems to mostly work okay, except the graphics card :)
[01:37] <Micksa> on resume the PCI config is trashed
[01:37] <Micksa> and "vbetool post" doesn't do a thing
[01:37] <Micksa> so
[01:37] <Micksa> could that be a BIOS related thing at all?
[01:37] <Micksa> could it be related to the fact that it's on a PCIe port?
[01:37] <mjg59> PCI config won't be restored because there's no PCI driver bound to it
[01:38] <mjg59> If it's PCIe, then the issue is probably that the kernel doesn't currently resume PCIe bridges properly
[01:38] <mjg59> There's a patch on acpi-devel - hang on a moment...
[01:38] <Micksa> oooh
[01:41] <mjg59> http://www.codon.org.uk/~mjg59/tmp/pcie.diff
[01:42] <Micksa> oh, but! Mark Lord has an inspiron 9300, which *seems* to be almost identical to a 6000, and his patches, which get STR working for him, don't fix this problem for me
[01:42] <Micksa> um, I'll get back to you :)
[01:42] <_rick> i have problem to compile the kernel with dpkg-buildpackage
[01:43] <Micksa> hmm, that patch applied.
[01:44] <Micksa> on top of his patches I mean.
=== doko [~doko___@dsl-082-082-196-074.arcor-ip.net]  has joined #ubuntu-kernel
[01:44] <mjg59> His patches are just for SATA, aren't they?
[01:45] <Micksa> nono, not just the patch you told me about
[01:45] <Micksa> sorry, forgot they were the same person :)
[01:46] <mjg59> So you get working resume but no working video at the moment, right?
[01:46] <mjg59> That's a touch more miserable to fix
[01:47] <Micksa> yeah
[01:47] <Micksa> but at least I can poke the machine via the network after resume. that sure helps.
[01:47] <Micksa> ml has a page at http://rtr.ca/dell_i9300/ which goes into great detail about how to get the i9300 to work with linux
[01:48] <Micksa> and it links to a patch which covers...
[01:48] <Micksa> well, sata and the touch pad :)
[01:50] <Micksa> I'm not actually sure if we have exactly the same PCIe bridge
[01:52] <Micksa> how do you get lspci to accept output from "lspci -vvx" as input?
[01:53] <mjg59> You can't
[01:53] <mjg59> You need to use setpci
[01:53] <mjg59> But the easiest thing to do is to use /sys/bus/pci/devices/foo/config
[01:53] <mjg59> You can cat that out before suspend and back after resume
[02:00] <Micksa> nono, I thought you could pass the output of "lspci -vvx" to the input of a "lspci -F"
[02:00] <Micksa> to get numeric PCI ids, for example
[02:00] <Micksa> (not that ml gave me the right format anyway :) )
[02:05] <mjg59> Oh, right
[02:05] <mjg59> No idea, I'm afraid :)
[02:06] <Micksa> bah
[02:06] <Micksa> what kind of support channel is this
[03:32] <Mithrandir> it's not a support channel.
[03:33] <Mithrandir> it's a development channel
[03:33] <Mithrandir> (says so in the topic)
=== swarm [~swarm@host162-150.pool80181.interbusiness.it]  has joined #ubuntu-kernel
[05:07] <jbailey> lamont: Hey, how much do you know about crazy ia64 things? =)
[05:07] <swarm> I have found that kernel for amd64-k8 coming with Ubuntu Hoary 5.04 isn't compiled for preemption. That could be the reason for input devices loss of interactivity during heavy /dev/hda I/O activities?
[05:07] <jbailey> swarm: Sure.  Or your dma could be disabled on the harddrive.
[05:07] <swarm> jbailey: it's set to udma5
[05:08] <jbailey> Compiling a kernel with preemtion is still not considered the Right Thing for distro kernels.
[05:08] <lamont> jbailey: very little, truth be told.
[05:08] <jbailey> lamont: Ah, 'kay.
[05:08] <lamont> jbailey: but it's on my list to be come a guru of such things, I fear
[05:09] <jbailey> lamont: I came up with the idea that Xen on ia64 might be able to run an i386 kernel.
[05:09] <swarm> jbayley: is it available any kernel running on amd athlon 64 with preemption enabled provided by Ubuntu team?
[05:09] <jbailey> swarm: No
=== lamont snaps his head around to stare at jbailey in horror
[05:09] <jbailey> lamont: I haven't told you the truly horrific part yet. =)
[05:09] <jbailey> I want to part the Hurd to Xen. =)
[05:09] <lamont> jbailey: the horror is that there's a chance it could work
[05:10] <lamont> that's part the Hurd _with_ Xen. :-)
[05:10] <jbailey> Right, same thing really. =)
[05:11] <swarm> perhaps it's the wrong place but I ask here... do you know if sun jre/jdk >= 1.4.2 amd64 release run on Ubuntu Hoary amd64?
[05:11] <jbailey> Right, it's the wrong place. =)  Please try in #ubuntu.
[05:13] <swarm> I tried yesterday and before.. On #debian-amd64 said that it's normal having that Sun things run on debian amd64. Thanks for the info about kernel
[05:14] <lamont> jbailey: does that mean yopu
[05:14] <jbailey> lamont: I've been looking for little kernel and compiler projects that will allow me to learn stuff in my spare time without having someone else run me over on it.  I suspect this might be an amusing one that noone else would be actively trying to make work right now. =)
[05:14] <lamont> you're going to make Xen work with NPTL?
[05:14] <lamont> jbailey: well, _THAT's_ for certain. :0)
[05:15] <lamont>  /topic jbailey's interest in the Hurd finally explained
[05:15] <jbailey> lamont: It looks like it might now.  I was reading a mailing list and talking with some folks on #xen, and it looks like they can emulate what they need now at a huge penalty, or you can do a custom glibc that uses a few line patch to do TLS accesses differently.
[05:15] <lamont> is there anyway to make that patch part of the standard glibc, I wonder?
[05:16] <jbailey> lamont: What might be interesting is to see if it's possible to get Xen'ness exposed as an HWCAP and then just build an extra pass onto glibc with that patch.
[05:17] <lamont> sounds reasonable
[05:17] <jbailey> Unlikely.  I don't know all of what happens with the patch, but it looks like it doesn't use %gs:# to access the thread stuff anymore, but calculates it.
[05:17] <lamont> ah, blech
[05:19] <jbailey> lamont: If I do take this on, would you mind the occasional ia64 question?  You know, like "Is it true the last twinky^Witarnium rolled off the assembly line in 1970 and they're just selling the stock now?"
[05:19] <lamont> eep.  must take daughter to girlscouts
[05:19] <lamont> bbl
[05:19] <jbailey> c'ya
[05:20] <lamont> jbailey: you can ask whatever you like (literally).  I reserve the right to not answer. :-)
[05:20] <lamont> and yes, I have stopped beating my wife.
[05:20] <jbailey> Err.
[05:20] <jbailey> Why?
[05:21] <jbailey> (That's question #1)
[05:21] <lamont> I let her win now.
[05:21] <jbailey> =)
=== lamont runs to get ready
[05:26] <swarm> Using headers of current kernel image got with Ubuntu Hoary, config from /proc/config.gz, I should be able to modify kernel config only for preemption with easy, right?
[05:26] <jbailey> I guess so, dunno.
[05:26] <jbailey> I don't build my own kernels.
=== swarm [~swarm@host162-150.pool80181.interbusiness.it]  has joined #ubuntu-kernel
=== doko [~doko___@dsl-082-082-196-074.arcor-ip.net]  has joined #ubuntu-kernel
=== svenl [~luther@AStrasbourg-251-1-75-78.w82-126.abo.wanadoo.fr]  has joined #ubuntu-kernel
=== infinity [~adconrad@loki.0c3.net]  has joined #ubuntu-kernel
=== TheMuso [~luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-kernel
=== mjg59 [mjg59@cavan.codon.org.uk]  has joined #ubuntu-kernel
=== calc [~ccheney@ip70-185-4-246.ma.dl.cox.net]  has joined #ubuntu-kernel
=== smurfix [~smurf@smurfix.developer.debian]  has joined #ubuntu-kernel
=== Mithrandir [~tfheen@vawad.err.no]  has joined #ubuntu-kernel
=== jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== dilinger [dilinger@mouth.voxel.net]  has joined #ubuntu-kernel
=== Seveas` [~seveas@seveas.demon.nl]  has joined #ubuntu-kernel
=== swarm [~swarm@host162-150.pool80181.interbusiness.it]  has joined #ubuntu-kernel
=== doko [~doko___@dsl-082-082-196-074.arcor-ip.net]  has joined #ubuntu-kernel
=== svenl [~luther@AStrasbourg-251-1-75-78.w82-126.abo.wanadoo.fr]  has joined #ubuntu-kernel
=== infinity [~adconrad@loki.0c3.net]  has joined #ubuntu-kernel
=== TheMuso [~luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
=== lamont [~lamont@mix.mmjgroup.com]  has joined #ubuntu-kernel
=== mjg59 [mjg59@cavan.codon.org.uk]  has joined #ubuntu-kernel
=== calc [~ccheney@ip70-185-4-246.ma.dl.cox.net]  has joined #ubuntu-kernel
=== smurfix [~smurf@smurfix.developer.debian]  has joined #ubuntu-kernel
=== Mithrandir [~tfheen@vawad.err.no]  has joined #ubuntu-kernel
=== jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== dilinger [dilinger@mouth.voxel.net]  has joined #ubuntu-kernel
=== swarm [~swarm@host162-150.pool80181.interbusiness.it]  has joined #ubuntu-kernel
=== JaneW [~JaneW@212.33.141.9]  has joined #ubuntu-kernel
[06:48] <jbailey> lamont: w-b question for you.  Does it respect the Architecture field, or does it hand everything to everyone?
=== JaneW [~JaneW@212.33.141.9]  has left #ubuntu-kernel ["Leaving"] 
[06:50] <lamont> w-b respects Packages-arch-specific.  It cares not one wit about Architecture:
[06:50] <lamont> dpkg/debhelper will fail the build based on Architecture: though
=== swarm [~swarm@host162-150.pool80181.interbusiness.it]  has joined #ubuntu-kernel
[07:41] <swarm> jbailey: solved input devices latency problem related to kernel preemption disabled.
[07:46] <swarm> I'm using kernel 2.6.11 amd64-k8 smp from Ubuntu. CONFIG_PREEMPT is not set while, of course, CONFIG_SMP=y. My pc has 1 CPU. Now there is no latency and it's very usable. Why?
=== Seveaz [~seveas@seveas.demon.nl]  has joined #ubuntu-kernel
=== swarm [~swarm@host150-125.pool80181.interbusiness.it]  has joined #ubuntu-kernel