[09:06] <kraut> moin
[11:44] <doko> lamont, kylem: is there a kernel which has the fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32857 ?
[03:10] <alesan> hi.
[03:11] <alesan> we are developing a kernel driver for our device (www.ncomputing.com) it is based on alsa. we want to support ubuntu as best
[03:12] <alesan> how can we know in advance when you are about to release a kernel update so that we can anticipate and create a binary that is going to work with your package?
[03:13] <IntuitiveNipple> alesan: Is the driver proprietary ?
[03:13] <alesan> GPL
[03:14] <alesan> and yes, we could ask the lkml to include it in the main kernel, but we need some time for that (code clean-up etc etc)
[03:14] <alesan> but before it gets accepted we would need a solution.
[03:15] <IntuitiveNipple> If it is GPL, then submit it to Andrew Morton's -mm so it can be reviewed and tested, Ubuntu and other distributions pick up their 'extra' drivers from there based on user demand
[03:15] <zul> BenC: ping ^^^
[03:15] <alesan> ok but - in the meantime - isn't there any option to anticipate your releases?
[03:16] <BenC> alesan: best bet is to submit the driver to use for inclusion in gutsy
[03:16] <IntuitiveNipple> I think the roadmap illustrates the releases... 6 month cycles
[03:16] <BenC> alesan: gutsy will be released in October, and is based on 2.6.22 kernel
[03:16] <alesan> ok but there are often minor releases
[03:17] <alesan> like 2.6.20-16
[03:17] <BenC> alesan: if it's in our source tree, it's being built every time
[03:17] <alesan> that went in 7.04 few weeks ago'
[03:17] <alesan> ok
[03:17] <alesan> I see
[03:17] <BenC> alesan: we can't anticipate those
[03:17] <BenC> the ABI bump - the -16 in the above example - is caused by changes we don't control, usually security updates
[03:18] <BenC> and we don't usually drop new drivers into a stable release, like 7.04
[03:18] <BenC> but we can include it in the upcoming release of gutsy now, and if it's in our tree, then you need not worry about those minors, since it'll get rebuilt everytime
[03:19] <alesan> BenC, ok. very good
[03:19] <BenC> alesan: I suggest checking http://kernel.ubuntu.com/, get the ubuntu-gutsy-lum git tree, and send us a request to include via kernel-team@lists.ubuntu.com
[03:20] <BenC> alesan: best way is to clone the tree, get it in the build, and send a pull request to the list, otherwise, just send us a nice patch
[03:21] <alesan> ok I'll talk with the driver author what he thinks is best
[03:21] <alesan> ask I mean
[03:21] <alesan> ok thank you very much at this point
[03:24] <alesan> BenC, IntuitiveNipple maybe there is a little problem. the driver needs to upload a firmware to our PCI board that is not going to be opensource. will this constitute a problem?
[03:24] <BenC> alesan: the ubuntu-gutsy-lum package already has other firmware in it, so long as we have redistribution rights, it should be ok
[03:25] <IntuitiveNipple> That's rather like the Intel wifi firmware situ, it should be ok
[03:25] <alesan> IntuitiveNipple, but such a thing won't help our driver to get included in the main kernel, right?
[03:26] <alesan> main kernel I mean -mm first and Linus' kernel after
[03:26] <BenC> alesan: it wont keep it from getting into the main kernel
[03:26] <BenC> there's plenty of drivers already that need firmware
[03:26] <IntuitiveNipple> alesan: see BenC's comment :)
[03:27] <BenC> alesan: just make sure you're using firmware API in kernel, and not doing something silly like building the firmware into the driver via bin2hex header :)
[03:27] <alesan> BenC, ok it is ok for now. thank you. and you too IntuitiveNipple 
[03:28] <IntuitiveNipple> Do we have any ACPI suspend experts? I've found an issue with feisty & gutsy whereby a notebook prematurely suspends and immediately resumes in acpi_enter_cleep_state() when flushing the CPU cache, *before* the SLP_ENABLE bit is written
[03:28] <IntuitiveNipple> s/cleep/sleep/
[03:31] <alesan> BenC, I checked and, actually, we load our firmware with a userspace tool. the kernel module (which is only for audio) must be loaded before and needs no special firmware to be loaded, but it won't "work" until the firmware is loaded
[03:31] <alesan> sorry I've been pretty confusing :)
[03:32] <BenC> alesan: a firmware tool?
[03:32] <BenC> alesan: so the driver doesn't request the firmware from userspace like all the other firmware-using drivers in the kernel? :)
[03:35] <alesan> BenC, you know we are building up our Linux-team and some work has been done already maybe not in the best way
[03:36] <BenC> alesan: ah, ok. Most likely the lkml will suggest you use the request_firmware() and related calls in the driver to handle the loading
[03:36] <BenC> alesan: fits into userspace and distros much better that way
[03:36] <alesan> see it like this, our device implements a kind of X-server. the audio part (for which we need the kernel driver) is "optional" and appeared later during the development process
[03:46] <alesan> sorry my network went down.
[03:47] <alesan> any answer to my latest message :) ?
[03:54] <BenC> alesan: didn't see a last question :)
[03:55] <alesan> :) well it was an attempt to explain why we don't load the firmware via a kernel call
[03:56] <BenC> I'd have to see the driver/product to really understand it better, but I'll take your word for it :)
[03:56] <BenC> if you're interested in getting into gutsy, the clock is ticking
[03:57] <BenC> we have feature/kernel freeze coming soon, like 4 weeks or so
[03:58] <alesan> ok
[03:58] <alesan> thank you for the info
[03:58] <BenC> no problem
[05:30] <bullgard4> In  http://tinyurl.com/2vy5ul FUNCTION: acpi_evaluate_object: What is meant with "find and evaluate the given object"?
[05:33] <IntuitiveNipple> bullgard4: It means that the ACPI namespace is walked to find the 'object' (aka method or device etc) and then the 'object' is executed
[05:35] <bullgard4> IntuitiveNipple: Ok, thank you.
[05:49] <alesan> re
[05:53] <alesan> BenC, or everybody else that can help me: I have this dual-dual xeon (4 cores) machine with 4GB ram. I can only see 3GB, is standard ubuntu kernel able to get full 4GB or should I compile some 64GB kernel?
[05:54] <IntuitiveNipple> alesan: Are you using 64-bit Ubuntu?
[05:54] <alesan> no 32 bit for development reasons :)
[05:55] <IntuitiveNipple> I think the max you'll see is about 3.2GB in that case
[05:55] <alesan> really
[05:55] <alesan> should I compile my own kernel then, ok
[05:55] <IntuitiveNipple> I *believe* there is a way to see all the memory, I read about it some time ago, but I can't remember what it was
[05:55] <alesan> only a problem with upgrades but it's ok
[05:56] <IntuitiveNipple> do some Googling for "linux kernel 4GB limit"
[05:56] <alesan> IntuitiveNipple, there is an optionin the kernel for 64GB support, do you mean that?
[05:56] <IntuitiveNipple> see http://kerneltrap.org/node/2450
[05:56] <alesan> or something that won't require a recomiplation?
[05:57] <IntuitiveNipple> "The lower 3 GB of the process virtual address space is accessible as the user-space virtual addresses and the upper 1 GB space is reserved for the kernel virtual addresses."
[05:57] <alesan> argh my http is broken... this router's crap it blocks http and the only thing I can do is to reset it
[06:00] <mjg59> IntuitiveNipple: That's not the issue
[06:00] <mjg59> That's per-process, not kernel address space
[06:00] <IntuitiveNipple> yeah, the page goes on to talk about HIGHMEM though :)
[06:00] <mjg59> alesan: Install the -server kernel
[06:01] <IntuitiveNipple> mjg59: Hobbsee tells me you're a bit of an ACPI suspend expert - is this correct?
[06:01] <mjg59> Yes
[06:01] <IntuitiveNipple> Can I bend your ear on something?
[06:01] <mjg59> Sure
[06:01] <mjg59> (In here is good)
[06:02] <IntuitiveNipple> Ok... if you want a link there's a clear concise explanation in the Ubuntu forums too
[06:02] <IntuitiveNipple> Feisty and Gutsy with a sony Vaio PGC-SRX51P/B notebook, suspend goes fab but the system resumes immediately
[06:03] <IntuitiveNipple> I've been debugging it and found that the call to ACPI_FLUSH_CPU_CACHE() doesn't return, and then the system is Back to C!"
[06:03] <IntuitiveNipple> So i never reaches the acpi_hw_register_write() for SL_ENABLE
[06:04] <IntuitiveNipple> Any ideas ?
[06:04] <IntuitiveNipple> Details here: http://ubuntuforums.org/showpost.php?p=3066404&postcount=9
[06:04] <mjg59> Ah., I saw this on acpi-devel
[06:05] <IntuitiveNipple> you did :)
[06:05] <IntuitiveNipple> I've tested it without paravirt and get the same result. It seems the ASM WBINVD causes this
[06:06] <IntuitiveNipple> Right now, I'm wondering about moving the call to ACPI_FLUSH_CPU_CACHE() to before the acpi_hw_register_write() alls begin, to see if its tipping something off
[06:06] <IntuitiveNipple> s/alls/calls/
[06:07] <mjg59> Yeah. It's not especially obvious what's going on there.
[06:07] <IntuitiveNipple> It certainly has me stumped to explain it!
[06:08] <IntuitiveNipple> The acutual suspend/resume itself looks beautifully clean and perfect in the log, too
[06:13] <alesan> ok sorry my cionnection was bropken.
[06:13] <alesan> connection
[06:13] <alesan> mjg59, I read your advice, you mean linux-image-server right?
[06:14] <alesan> mjg59, am I going to miss the low-latency features in such kernel? or will I hardly notice the difference?
[09:32] <arthur_kalm> Hi everyone, I'm trying to get a D-Link DWL-G122 wireless USB adapter to work with Feisty. The adapter worked perfectly in Dapper but after the upgrade to Feisty, every time I plug the D-Link into the computer all the USB ports instantly disconnect and I get the following error: http://paste.plone.org/15873. Any help would be much appreciated, thanks in advance.
[09:37] <JanC> arthur_kalm: are you sure it still works with dapper (try a dapper live cd)
[09:39] <arthur_kalm> JanC: well it was working with Dapper right before I did the fresh install
[09:40] <JanC> the error you posted is from the USB controller saying something really bad happened  :)
[09:41] <arthur_kalm> JanC: hehe true, well it only happens when the wireless adapter connected. Otherwise the USB works fine. The adapter works in windows too..
[09:56] <JanC> hm, DWL-G122 sounds most likely uses a Ralink chip...
[10:01] <arthur_kalm> JanC... perhaps
[10:03] <JanC> do you have a multi-core CPU?
[10:04] <arthur_kalm> no it's a P3
[10:04] <arthur_kalm> 5 years old computer
[10:08] <IntuitiveNipple> arthur_kalm: In the process of upgrading did you tinker with the insides of the PC at all? I've seen similar reports when ppl have accidentally 'nudged' something
[10:12] <arthur_kalm> IntuitiveNipple: Hmmm I sure hope not... however, now that you mention it... this isn't my computer, it's actually my boss's and he brought it in from home inside a wheeled suitcase and it was bumping around a lot. Let me check that nothing is loose.
[10:13] <IntuitiveNipple> that sounds like an inspired idea :)
[10:13] <IntuitiveNipple> reseat everything and pull/push all wires
[10:14] <arthur_kalm> hmm just checked and it looks fine.. the thing is that Dapper was working fine when he brought the computer in and we had no problems backing up his personal files
[10:14] <IntuitiveNipple> it does sound strange... have you tried it with the Dapper LiveCD to be sure this is not a general problem?
[10:15] <arthur_kalm> no, but it _was_ working when it came in...
[10:16] <arthur_kalm> I can bring in a live CD tomorrow...
[10:17] <IntuitiveNipple> If you can prove that Dapper is working, then you can investigate what changes would affect it. Have you tried the device in another PC running feisty? 
[10:18] <arthur_kalm> haha, why didn't I think of that :P
[10:18] <arthur_kalm> well it works fine in my computer
[10:19] <IntuitiveNipple> Is it using ndiswrapper or regular Linux driver?
[10:20] <IntuitiveNipple> It might be worth investigating the USB hub on the problem PC
[10:20] <arthur_kalm> both do not have ndiswrapper
[10:20] <IntuitiveNipple> Will another device work in the same USB port that you plug it into?
[10:20] <arthur_kalm> well the USB hub works fine with an external hard drive
[10:20] <arthur_kalm> yes
[10:20] <IntuitiveNipple> narrowing it down nicely :)
[10:21] <arthur_kalm> hehe
[10:21] <arthur_kalm> but yeah lsusb shows up normally on my machine
[10:21] <arthur_kalm> and I just plugged in my USB drive and it works fine
[10:23] <IntuitiveNipple> When you plug in the device, are there any usb messages in kern.log before the failure?
[10:24] <arthur_kalm> well it registers the USB device, and then tries to probe it, that's when it fails
[10:25] <IntuitiveNipple> so the probe is suspect?
[10:26] <arthur_kalm> well prism54 yes
[10:27] <IntuitiveNipple> howabout if you blacklist the module and try plugging it in? that way if it doesn't kill the hub you know you've isolated where the problem is
[10:27] <arthur_kalm> so blacklist prism54?
[10:27] <IntuitiveNipple> yes
[10:28] <arthur_kalm> let me try
[10:28] <arthur_kalm> 1 second
[10:29] <arthur_kalm> err
[10:30] <arthur_kalm> I forgot, where do you blacklist?
[10:30] <IntuitiveNipple> /etc/modprobe.d/blacklist i think
[10:32] <arthur_kalm> ok
[10:32] <arthur_kalm> so I added it to the blacklist and ran "modprobe prism54usb"
[10:32] <arthur_kalm> I don't _have_ to restart right?
[10:33] <IntuitiveNipple> is prism54usb loaded? (lsmod | grep prism)
[10:34] <arthur_kalm> yes
[10:34] <arthur_kalm> so I guess restart...
[10:34] <IntuitiveNipple> I'd probably do a full restart so you can guarantee the system is 'clean'
[10:34] <arthur_kalm> OK
[10:34] <arthur_kalm> btw thank you so much for the help :)
[10:34] <IntuitiveNipple> np... I'm sat here twiddling my thumbs building various kernels :)
[10:35] <JanC> prism54 != Ralink
[10:36] <arthur_kalm> IntuitiveNipple: hehe
[10:36] <IntuitiveNipple> JanC: You saying arthur has the wrong driver?
[10:36] <JanC> but I found DWL-G122 revision 2 & 3 being Ralink, maybe revision 1 (which I didn't found anything about) was prism54...
[10:37] <JanC> stupid hardware manufacturers 
[10:37] <arthur_kalm> JanC: hehe, well I'm using Version A2, 1.02
[10:37] <IntuitiveNipple> ahhh... I see... arthur, you'd best check the details ! you might be working with the wrong driver
[10:38] <IntuitiveNipple> A2/prism according to https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported#head-603c9481d6c6288b6b674cc50132d21f6d539c53
[10:38] <arthur_kalm> ok
[10:39] <arthur_kalm> so it seems to be prism
[10:39] <IntuitiveNipple> arthur_kalm:  *** "Also works with Feisty but you need to blacklist prism54usb driver" *****
[10:39] <arthur_kalm> hahaha
[10:39] <IntuitiveNipple> (from that table)
[10:39] <arthur_kalm> yeah I blacklisted prism54usb and now the USB drives work
[10:39] <JanC> arthur_kalm: yeah, rev. B & C (instead of 2 & 3) are Ralink
[10:40] <IntuitiveNipple> arthur_kalm: Does that mean its fixed?
[10:40] <arthur_kalm> JanC: haha so they work out of the box I guess. I think my girlfriend has rev B or C and they work out of the box
[10:40] <JanC> arthur_kalm: if you don't have a multi-core CPU  :)
[10:40] <arthur_kalm> IntuitiveNipple: to the point that it doesn't take out all the other USB devices
[10:40] <IntuitiveNipple> arthur_kalm: progress indeed :)
[10:41] <IntuitiveNipple> On another subject entirely...
[10:41] <arthur_kalm> ok so the network manager doesn't recognize it...
[10:42] <arthur_kalm> and no multicore :P
[10:42] <IntuitiveNipple> ... does anyone know how I can do a kernel package build and have it only recompile dependencies rather than having to do a clean ?
[10:42] <arthur_kalm> but it _is_ recognized by lsusb
[10:43] <IntuitiveNipple> I did some updates in the ACPI code, but the build with binary-debs only rebuilt what was in the debian/build tree, it didn't recompile the acpi changes
[10:43] <IntuitiveNipple> maybe I can do an out-of-tree build and then create the kernel package in another stage?
[10:44] <arthur_kalm> IntuitiveNipple: I should have looked at the wiki :P thanks so much for your help. Thanks JanC
[10:44] <IntuitiveNipple> arthur_kalm: is it working now?
[10:45] <arthur_kalm> IntuitiveNipple: hmm no it doesn't turn on automatically... but at least we can plug it in now
[10:45] <IntuitiveNipple> ok
[10:45] <arthur_kalm> which is progress already
[10:45] <IntuitiveNipple> yeah
[10:45] <arthur_kalm> and I gotta go home already :(
[10:45] <IntuitiveNipple> "Google is your pal"
[10:45] <arthur_kalm> yeah I'll look up howtos for it
[10:46] <arthur_kalm> why do all the helpful people come on when I'm just about to go home? :P
[10:46] <arthur_kalm> but thank you so much for the help, much appreciated
[10:46] <IntuitiveNipple> your welcome
[10:46] <IntuitiveNipple> ^you're^
[10:46] <arthur_kalm> have a good night everyone!