[01:16] <ia> hello. I try to compile custom kernel for jaunty(2.6.28-8.21) with ralink wireless driver as module and i get message ".../linux-2.6.28/scripts/Makefile.build:231: target `ubuntu/../drivers/staging/rt2860' doesn't match the target pattern"; module doesn't compile, but compilation of kernel go on. could you tell me, please, how to fix it?
[01:17] <TheMuso> ia: You should only need the linux headers packages to build a new driver against the kernel.
[01:17] <TheMuso> ia: So linux-headers-2.6.28-generic
[01:21] <ia> TheMuso: eeem, i don't compile driver for existing kernel; i compile the whole kernel with necessary modules. afaik headers necessary only if you develop/compile modules for already existed and compiled kernel.
[01:22] <TheMuso> ia: So do the current jaunty kernels not have the necessary modules? If so, you should contact the kernel team about that
=== Daviey_ is now known as Daviey
[04:30] <pwnguin> does ubuntu-kernel handle linux-firmware?
[04:33] <pwnguin> there's a capitalization bug in the bcm bluetooth firmware =/
[04:34] <pwnguin> bug #156133
[04:34] <ubot3> Malone bug 156133 in linux-firmware "bluez suite lacks bluez-firmware package" [Low,Triaged] https://launchpad.net/bugs/156133
[04:40] <pwnguin> ok, redid the title on that
[04:40] <pwnguin> bug #156133
[04:40] <ubot3> Malone bug 156133 in linux-firmware "bcm203x firmware improperly capitalized" [Low,Triaged] https://launchpad.net/bugs/156133
[05:00] <pgraner> pwnguin: yep it does, what release are you having the prob? Intrepid?
[05:08] <dtchen> pgraner: from last i looked at the bug, both intrepid and jaunty
[05:08] <pgraner> dtchen: ok, I'll flag it for both releases. Thanks.
[06:04] <dtchen> pgraner: / apw: thanks for the vanilla kernel builds, which made it possible to easily fix an upstream ndiswrapper bug (diff sent to tracker).
[06:05] <pgraner> dtchen: cool glad its helping you. Would be great if you could drop a note to kernel-team@lists.ubuntu.com letting the team know
[06:06] <dtchen> pgraner: sure thing. vanilla builds also made it easy to verify existence of another upstream ALSA bug - working on fixing that now.
[06:07] <pgraner> dtchen: awesome!
[07:29] <nataraj>  hi 
[07:29] <nataraj> <nataraj> git branch
[07:29] <nataraj> <nataraj>   master
[07:29] <nataraj> <nataraj>   origin
[07:29] <nataraj> <nataraj> * tmp
[07:30] <nataraj>  tmp is v2.6.18 tag
[07:30] <nataraj> <nataraj> but on compile i get 2.6.29-rc
[07:30] <nataraj> <nataraj> what to do to get 2.6.18 kernel?
[09:29] <Ng> smb_tp: I poked bug #311716 off Fix Released for Intrepid since there seem to be a bunch of people who've had brightness control break as a result
[09:29] <ubot3> Malone bug 311716 in linux "The slider brightness Applet has value inverted after the last update (2.6.27-11)" [Medium,Confirmed] https://launchpad.net/bugs/311716
[09:29] <Ng> (myself included, Thinkpad x300)
[09:29] <smb_tp> Ng, is the result currently no brightness control or the still inverted control?
[09:31] <Ng> smb_tp: no brightness control. The on screen display shows it changing, but it doesn't actually change (via keyboard hotkeys and the panel applet)
[09:31] <smb_tp> Have you tried the acpi_backlight= options?
[09:32] <Ng> smb_tp: the only thing I tried was to quickly rmmod thinkpad_acpi and modprobe it with backlight_control=1 (without rebooting), which didn't seem to do anything, but I'm not sure how useful a test that was
[09:33] <Ng> I certainly can test that option though
[09:34] <smb_tp> Hm, if i do not confuse this the x300 was different as it could/should not work with thinkpad-acpi. Or was that a different model. I think I saw some comments like that somewhere
[09:35] <Ng> there are newer laptops sold as thinkpads which have a totally different internal setup to "normal" thinkpads, but the X300 is a "normal" thinkpad. Interally it's actually quite similar to the X61
[09:35] <Ng> and the various thinkpad kernel modules do definitely work with it
[09:36] <Ng> (and e.g. Nafallo's T61? sees the same thing, and I added a bunch of similar reports as duplicates of 311716 yesterday)
[09:37] <Nafallo> R61
[09:39] <smb_tp> Ok, so all the "real" thinkpads should be happy with "options backlight_enable=1" in the modprobe.d. This should generate a message in dmesg saying that thinkpad_acpi is controlling the backlight, not that it backs of. The problem here is that all those Thinkpads seem to have acpi information that claims to support the generic driver while in fact it does not work. and the thinpad_acpi driver backs off in that case.
[09:41] <Ng> that being the case, the question would be how to get that option on the right machines - it seems a little harsh to regress the brightness control for a popular range of laptops and require people to set a modprobe option themselves (which may cause problems later)
[09:41] <Ng> I'll test that and the acpi_backlight option later
[09:43] <smb_tp> The crazy thing there is that the dsdt does not directly show any _BCL method (which is taken as an indicator that the acpi driver can handle this). It seems like hidden somewhere with indirect pointers which I still do not really grasp. We could make acpi_backlight=1 the default but it is quite hard to say how many models this would regress
[09:46] <Ng> I'd be tempted to suggest contacting Henrique de Moraes Holschuh <hmh@hmh.eng.br> who is the maintainer of thinkpad_acpi and would probably know the models well
[09:46] <Ng> there's an ibm-acpi-devel list that he's quite active on
[09:47] <smb_tp> Ng, for the thinkpads the acpi_backlight option does likely not help. The driver directly queries the capabilities by testing some acpi methods and those will report acpi support even when it is not enabled. Right, this probably is the best approach there
[09:48] <smb_tp> But in that case we should check whether the problems remain in Jaunty or in the generic upstream kernels
[11:10] <mjg59> It'd be far easier to just fix the acpi backlight module than to try to figure out how to hack around it with vendor-specific drivers
[11:22] <philsf> can someone who understands kernel backtraces please take a look at the following dmesg and give me a hint of what's goiing on? http://launchpadlibrarian.net/21975410/dmesg.log it's from Bug #325238, where there are other debugging information and attachments
[11:22] <ubot3> Malone bug 325238 in linux "BUG: unable to handle kernel paging request" [Undecided,New] https://launchpad.net/bugs/325238
[13:33] <Kano> hi rtg , how about merging this today: http://kanotix.com/files/kernel/unused-patches/2.6.28-ubuntu-qc-usb-compile-fix.patch
[13:56] <rtg> Kano: how about following normal procedures and sending patch requests on the mailing list?
[14:31] <smb_tp> mjg59, To figure out that is actually the real goal. The problem that I currently face is that it is quite mysterious to me how those machines involved do their generic support. The vendor driver does the right thing by backing of but that is bad if the generic implementation in the acpi bios seems just to do nothing at all
[15:00] <mjg59> smb_tp: If _BCL returns a set of values where the first two are not included in the rest of the values, the entire list should be treated as the set of probable values. Otherwise the first two values should be ignored. The list should then be sorted.
[15:02] <smb_tp> mjg59, The sorting and dropping came in through stable and I picked that up for future updates. What I am wondering is, that I always believed _BCL should be a method defined in the dsdt. Which isn't the case for those TPs I saw. At least not directly.
[15:13] <mjg59> smb_tp: I was under the impression that _BCL was always there, but that _BQC sometimes provided an index rather than a value
[15:15] <smb_tp> mjg59, That is the absolutely mysterious part. There is no such string as _BCL in the dsdt disassembly. But it must be somewhere. At least acpi finds it somewhere...
[15:18] <mjg59> smb_tp: It's in an SSDT, not the DSDT
[15:20] <smb_tp> mjg59, Hm, I feared I had some misunderstanding there. Strange enough I found a _BCL method in some DSDTs. 
[15:21] <mjg59> smb_tp: It depends on the implementation
[15:22] <mjg59> smb_tp: Generally you'll find it in an SSDT if the system has different graphics options - that way they can ship a single BIOS and load an appropriate SSDT at boot
[15:25] <smb_tp> mjg59, Ah ok. Hm, this might be the stupid question of the month. How can I access and disassemble an SSDT?
[15:26] <mjg59> smb_tp: acpidump will dump them as well
[15:26] <mjg59> You just need to iasl -d the ssdt.dat files
[15:27] <smb_tp> Ok, so the problem is that I asked for /proc/acpi/dsdt which doesn't dump everything
[15:27] <mjg59> Right
[15:29] <smb_tp> mjg59, Oh dear... Well, thanks a lot for that
[17:13] <DnaX> someone can look this bug? https://bugs.edge.launchpad.net/linux/+bug/326621
[17:13] <ubot3> Malone bug 326621 in linux "Ubuntu lacks support for Ralink rt2870 based 802.11n chipsets" [Undecided,New] 
[17:40] <BUGabundo> hi
[17:40] <BUGabundo> anybody else here can help me debug a friends laptop?
[17:40] <BUGabundo> wired card buggy
[17:40] <BUGabundo> prob Linux support
[17:40] <BUGabundo> it's a SYS based laptop
[17:41] <BUGabundo> humm anybody active here with some pointers?
[17:43] <smb_tp> BUGabundo, What release? kernel-version, and maybe what wired card? :)
[17:43] <BUGabundo> ibex
[17:43] <BUGabundo> 2.6.27-11
[17:43] <BUGabundo> sis190
[17:44] <BUGabundo> I had to use the apci off to install
[17:44] <BUGabundo> using wubi
[17:44]  * BUGabundo in the middle I found out that wubi install 64 bits when able too!
[17:45] <smb_tp> Ok, requireing acpi off is probably more than just a network card
[17:45] <BUGabundo> card can get IP and DNS but will not ping anything
[17:46] <BUGabundo> and NM takes about 5 sec just to notice un/pluging the card
[17:46] <smb_tp> Do you see the any associated irq going up when doing pings
[17:46] <BUGabundo> smb_tp: yes... after grub we can see a message warning about using a DUMMY acpi
[17:46] <BUGabundo> smb_tp: irqs where? syslog?
[17:46] <smb_tp> cat /proc/interrupts
[17:47] <BUGabundo> just a sec
[17:47] <smb_tp> Generally wondering why acpi=off was required. What happened otherwise? A hang somewhere or panic?
[17:48] <BUGabundo> hang while installer started
[17:48] <BUGabundo> but I can boot the laptop without it
[17:49] <BUGabundo> smb_tp: what should I be looking for on interrupts?
[17:50] <smb_tp> Since I don't know the card by heart I am not sure it is using interrupts or not. Is there a line which has the sis190 driver to it
[17:51] <BUGabundo> let me get a lspci
[17:52] <BUGabundo> SiS 191 Gigabit Eternet Adapter rev 02
[17:52] <smb_tp> or pipe "ifconfig eth0" here
[17:52] <BUGabundo> interrupt pin A routerd to IRQ 3
[17:52] <BUGabundo> kernel module sis190
[17:53] <BUGabundo> no network on that machine, any thing needed will be either "visual"
[17:53] <BUGabundo> or by usb key
[17:54] <d3xter> hey guys
[17:54] <smb_tp> Right, pipe was rather overstated. Ok, but IRQ 3, so there should be one line in /proc/interrupts with that
[17:55] <BUGabundo> smb_tp: looking at diff cat results it did change
[17:56] <d3xter> I've got a little problem with 2.6.27. Sometimes my fan starts working at max speed and cpu is throttled to half of its speed and nothing happens, if i change it with cpu-freq applet. here is my dmesg: http://pastebin.com/f3fa05d91
[17:56] <smb_tp> In the last column, is there a list of drivers or just one entry
[17:57] <BUGabundo> smb_tp: it just states eth0
[17:57] <BUGabundo> back
[17:57] <BUGabundo> wrong escape key
[17:58] <smb_tp> Ok, that means at least there are interrupts and the have to be from the card and no other driver should be listening
[17:58] <BUGabundo> sure. ifconfig also show tx and rx traffic
[17:58] <BUGabundo> and sometimes you can get network for about  2-3 mins
[17:59] <BUGabundo> but then if falls to 10mb/s and stop working
[17:59] <BUGabundo> even though it as an IP
[17:59] <BUGabundo> I also tried to reboot into recovery, but no deal
[17:59] <BUGabundo> could get IP with dhclient but would not ping
[18:02] <smb_tp> Hm, is tcpdump installed? 
[18:05] <BUGabundo_> back
[18:06] <smb_tp> d3xter, This sounds a bit like the system sees high cpu temperatures.Have you/can you check the cpu temperature at that point?
[18:07] <d3xter> smb_tp well that happends randomly, today it was at 62° C
[18:07] <d3xter> and normally it can handle temps of about 82 or so
[18:08] <d3xter> but the strange this is, that the fan works at max speed until i reboot, not matter how high the temperature is
[18:08] <d3xter> the strange thing is*
[18:08] <smb_tp> at least I would not expect throtteling to happen at that point. What says cat /proc/acpi/thermal_zone/THM0/trip_points ?
[18:09] <d3xter> now the temperature is about 50° C :-/
[18:09] <d3xter> and its still working at max speed
[18:10] <d3xter> critical (S5): 126 C
[18:10] <d3xter> smb_tp what does "CE: hpet increasing min_delta_ns to xx nsec" means?
[18:11] <philsf> can someone who understands kernel backtraces please take a look at the following dmesg and give me a hint of what's going on? http://launchpadlibrarian.net/21975410/dmesg.log it's from Bug #325238, where there are other debugging information and attachments
[18:11] <smb_tp> This happens if you have a fast hpet and the default interval is too small. 
[18:11] <ubot3> Malone bug 325238 in linux "BUG: unable to handle kernel paging request" [Undecided,New] https://launchpad.net/bugs/325238
[18:13] <smb_tp> d3xter, Though yours is running at 15MHz which isn't exceptionally fast. Still the system had problems to set a new minimal delay three times and for that increased this minimum time
[18:13] <BUGabundo_> smb_tp: any more tips?
[18:14] <BUGabundo_> i'm downloading jaunty daily and testing 
[18:15] <d3xter> smb_tp, ah ok, hopefully it will work with jaunty :)
[18:16] <BUGabundo_> but i dont want to place a new user on a devel branch
[18:19] <smb_tp> BUGabundo_, Hard to tell over a distance. the sis190 has a debug option which maybe could reveal more. Not sure you would be able to vary network infrastructure with different cabling or hub... 
[18:20] <BUGabundo1> smb_tp: ha??
[18:22] <smb_tp> BUGabundo1, The difference between Jaunty and Intrepid for the driver itsels is minimal
[18:23] <BUGabundo1> smb_tp: ahh.. I just tried running a kernel with no ACPI restritions and it failed to boot
[18:26] <BUGabundo1> smb_tp: does any log of those failed boot get stored?
[18:29] <smb_tp> Natively that would require the system to be up to a point it has a file system. I don't think wubi has a chance to do something there, but I don't know that environment...
[18:30] <smb_tp> Normally the acpi problems happen before that point
[18:30] <BUGabundo1> I'll check logs once it boots again
[18:36] <smb_tp> Depending on the system hw there is a variation of options to try: hpet=disable, acpi=noirq, pci=routeirq. But generally boot without splash and quiet to get the most output so it is more visible where a hang occurs.
[18:38] <BUGabundo1> yeah i saw ir jamming after CPU cores detections
[19:40] <BUGabundo1> FYI that SIS laptop just booted from Live USB with daily jaunty
[19:41] <BUGabundo1> it jammed at 2.5177 Write protecting the kernel read-only data : 6568k
[19:44] <BUGabundo1> trying hpet=disable it stops on bluetooth rf comm ver 1.10
[19:47] <BUGabundo1> acpi=noirq fails at 0.37 ..timer: vector=0x30 acic1=0 pin1=2 apic2=0 pin2=0
[19:47] <BUGabundo1> humm ok that now moves.... just took 30 sec of no info, but its rolling
[19:57] <BUGabundo1> but that was just to slow, and seeing a bunch of IO errors.
[19:58] <BUGabundo1> I tested my usb pendrive md5sum files just to be sure, and every file was OK
[20:02] <BUGabundo1> pci=routeirq acted like hpet=disable
[20:03] <BUGabundo1> choosing ALL option on the installer seems to at least take the install a bit further
=== ivoks_ is now known as ivoks
[21:45] <domas> is there some secret dance, that would make 'make-kpkg' to produce package for vmlinux too?