=== allee_ is now known as allee [13:54] BenC: #180678 - seriously. Every single release I can remember. This really isn't funny any more. [13:54] bug #180678 [13:54] Launchpad bug 180678 in acpi-support "dmesg: toshiba_acpi: Unknown parameter `hotkeys_over_acpi'" [Medium,In progress] https://launchpad.net/bugs/180678 [13:56] mjg59: every release it is the same reason...acpi core changes so much the patch cannot be applied [13:56] mjg59: pretty sure it was in the list of "patches that got left behind" [13:57] mjg59: we've audited the patches that got removed at hardy kernel rebase, and that's the only one [13:58] BenC: As far as I can tell, that mail never went anywhere public? [13:58] Amit replied with a subset Cc:ed to kernel-team [13:59] mjg59: I mean the list I sent you months ago [14:03] BenC: No, it's not in that list [14:04] Can you check whether any other patches have fallen through the cracks? [14:14] BenC: can you please send me this other list that you sent to mjg59 [14:14] mjg59: I told ya we just did an audit of the patches :) [14:14] amitk: it's the same one you got, minus stuff that already got checked [14:14] BenC: ok [14:15] BenC: As I said, that patch isn't in hardy git. It was in gutsy. It's not in the email you sent me. [14:15] If your audit process doesn't pick that up, then that's a problem with your audit process [14:16] Which is consistent with previous occasions where patches have gone missing from the lists of missing patches [14:18] BenC: 2d35697db5e3c4f240ac288c7c5abeb5a03c805c in gutsy [14:19] interesting...it applies cleanly...wonder why it didn't hit the rebase [14:20] BenC: It would be good to know if anything else falls into the same category [14:20] BenC: be sure to mark it as a SAUCE patch so we don't lose it again. === asac_ is now known as asac [14:59] did someone already encounter bug #197006, and/or knows a workaround? [14:59] Launchpad bug 197006 in linux-meta "NFS over Unionfs prevents updating existing files" [Undecided,New] https://launchpad.net/bugs/197006 [15:16] mjg59: toshiba_acpi patch applied [15:16] BenC: Thanks [15:55] tjaalton: I'm turning the ABI crank today. I'll upload -11 in a few hours in advance of Alpha 6 scheduled for next Thursday. [16:12] hi rtg , did you find my bug report [16:12] rtg: btw. the ivtv-fb driver is not working, maybe compiled against wrong header [16:12] Kano: I didn't notice it. What number is it? [16:12] #196745 [16:13] will check if i can do a fix for ivtv-fb [16:13] Kano: we are still working on the ABI mismatch which is probably what is wrong with ivtv-fb [16:13] yes the most easy way is to overwrite the included .h files with the one from the kernel [16:13] that fixes it [16:14] Kano: can't do that (debian policy). see https://wiki.ubuntu.com/KernelTeam/Sprints/Feb2008/HeadersABI for possible solution [16:15] then remove the included headers [16:15] how about that [16:15] they are not needed anyway [16:15] dunno. we'll get it figure out before Beta. [16:16] the fastest hack is just to replace the ivtv-fb headers - not the kernel ones [16:18] Kano: at the risk of sounding pedantic, file a LP bug so I can track it. [16:18] rtg: will try to fix it and then report a bug [16:18] i have got a pvr 350.. [16:19] just dont use it so often [16:24] rtg: ok, I have nvidia almost ready to go, targeted -11 [16:24] rtg: how about enabling vmware client modules? [16:25] Kano: which ones? seems like there is a pending LP for a sound module. [16:25] well the standard ones needed for vmplayer [16:26] i think those will not change [16:26] Kano: do you think enabling ALSA in the kernel would be sufficient? [16:26] virtual box needs always differnet modules, so i would not integrat it [16:27] i think you have alsa already enabled? [16:27] didnt you [16:27] zul: what about xen & nvidia? [16:28] tjaalton, i havent got a chance to look at it [16:29] zul: ok [16:40] rtg: also did you notice that "ifneq ($(wildcard /CurrentlyBuilding),)" has to be "ifeq ($(wildcard /CurrentlyBuilding),)" in debian/rules.d/0-common-vars.mk ? [16:40] currently it is absolutely stupid that it compiles faster when there is a dir/file named /CurrentlyBuilding [16:41] dont you think so... [16:42] ps aux|grep -e -j [16:42] Kano: looks to me like it just overrides CONCURRENCY_LEVEL when on a buildd. [16:43] yes, but completely in the wrong way [16:43] why would somebody build on a multi core machine with -j1? [16:44] you could even disable that check [16:44] Kano: because there might be other builds going on the same machine. [16:44] rtg: i thought that, but then the logic is completely reversed! [16:45] as you compile with 1 thread when there is NO such file and with twice the number of cores when it is there [16:45] check it out yourself [16:48] you will at least see -j2 even with a single core when the file is there and -j1 when it is not there [16:48] must be clear [16:48] that this is wrong [16:48] Kano: this particular problem is not important. I've a zillion other issues to deal with. buildd passes happen overnight for me, so I just don't care. [16:49] rtg: but i care [16:49] start a bug report then. [16:49] you only have to remove the "n" [17:06] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197040 [17:06] Launchpad bug 197040 in linux "reversed logic for bbuild check leads to -j1 default" [Undecided,New] [17:06] here it is === alleeHol is now known as allee [17:31] sound/usb/usx2y/snd-usb-usx2y.o [17:31] you mean that erro? [17:52] hmm no, the error is in toshiba_acpi.c [17:52] what did you do there [17:54] Kano: I'm just getting to buld testing. looks like the acpi crack broke something. [17:54] yes it does not build === doko_ is now known as doko [17:54] rtg: lrm with new nvidia ready [17:55] tjaalton: I'm still build testing. it'll be a bit yet. [17:55] rtg: np [17:56] tjaalton: if you added .12 then you can be sure it will not be the last update [17:56] Kano: surprise [17:57] latest is still set to 169.112 [17:57] that can show my script with -v latest option... [17:58] DISPLAY= fakeroot install-nvidia-debian.sh -pv latest [17:58] 169.12 [17:58] mjg59: can you have a look at the acpi patch BenC applied? It doesn't build, so I've reverted it. I'm kind of on a deadline for Alpha 6. [17:58] rtg: Not currently, no [17:59] I'm up to my eyes in mobile [18:00] mjg59: ok, its gonna have to wait until after -11 is released. [18:00] Well, as long as it hits before final, I'm unfussed [18:00] mjg59: can do. [18:02] btw. you know that at least 2 ide modules are too much? [18:03] via82cxxx and amd74xx are useless, because you have pata_via and pata_amd [18:03] which work much better [18:04] maybe more, but you can be sure that pata drivers are tested for those [18:05] tjaalton: so what did you package 169.12 or 171.05? [18:09] btw. did you try pxe boot for your live images? [18:10] live-helper can for example use net as target [18:10] and creates a tftpboot dir [18:12] hello all [18:12] I have been skimming the bug list for some time, but can't find a bug similar to what I observe [18:13] my machine has some huge speed problems with 2.6.24 (2.6.22 is fine) [18:13] boucman: lsmod|grep -e ide -e pata [18:13] best check this [18:14] if you have got an legacy ide + pata driver loaded blacklist the old ide and run: update-initramfs -u [18:14] Kano: thx... I'm using 2.6.22 right now, are you interested in what it reports, or should I reboot in 2.6.24 to check ? [18:15] well you would need 2.6.24 [18:15] to get this output [18:15] I do get an output :P [18:16] sure, but i dont think something with pata or? [18:16] Kano: you're right [18:17] I'll reboot in a minute, but since I'm unable to log to irc with that kernel, what should I be looking for precisely ? [18:17] the problem is when you would do that now you could not boot your old kernel ;) [18:17] i would prefer those old modules removed, but.. [18:17] you mean 2.6.22 wouldn't boot anymore after doing that ? [18:18] if you blacklist the module and run update-initramfs -u (updates initramfs for current kernel) [18:19] usually the new kernel runs the devices without dma access [18:19] because 2 drivers want to work with the same device, disabling the old ones fixes that usally [18:20] Kano: ok, can you walk me throught the process (or point me to a web page ) I would be gratefull [18:20] well i dont think that ubuntu ppl did that before, thats what i did for kanotix users ;) [18:22] ok, so [18:22] 1) blacklist the module [18:22] Kano: 169.12 [18:22] 2) reboot with .24 kernel [18:22] 3) run "update_initramfs -u" [18:22] right ? [18:22] no you forget the major step [18:22] oh, [18:22] the blacklisting [18:23] that was step 1, but I'm not sure how to do that [18:23] show me lsmod|grep -e ide -e pata [18:23] after reboot [18:23] Kano: ok, I'll reboot, do that and come back. [18:23] then we'll discuss how to fix [18:23] and thx a million for your help [18:23] brb [18:27] back [18:28] so check lsmod|grep -e ide -e pata [18:28] also [18:28] cat /etc/fstab [18:28] cat /proc/cmdline [18:28] video 23316 0 [18:28] output 5632 1 video [18:28] ide_core 136344 1 amd74xx [18:28] pata_amd 16772 0 [18:28] pata_acpi 9856 0 [18:28] libata 176304 4 pata_amd,sata_nv,ata_generic,pata_acpi [18:28] to be sure that you use uuids [18:28] that's under .24 (i'm back to .22 right now) [18:28] the problem is definitely amd74xx [18:28] ok [18:28] why dod you boot the .22 kernel? [18:29] doesnt it boot at alls? [18:30] it does, but usually it takes approx 5' just to start pidgin [18:30] so not really usable [18:30] cat /proc/cmdline [18:30] show this [18:30] root=UUID=aefdb9c5-c42d-4de4-863d-e8db4afcd1e8 ro quiet splash [18:30] ok, should be no problem to use the fix [18:30] :) [18:30] which 2.6.24 do you want to fix [18:31] main one, I guess [18:31] -10? [18:31] yes, that's the latest one [18:31] ls /boot/vmlinuz-2.6.24-* [18:31] (so far :P ) [18:31] show this [18:31] /boot/vmlinuz-2.6.24-10-generic [18:31] echo blacklist amd74xx > /etc/modprobe.d/custom-blacklist [18:32] update-initramfs -uk 2.6.24-10-generic [18:32] then you should be able to boot new kernel [18:33] running... [18:33] ok, done [18:33] I'll be back in a minute (hopefull with .24) thx again for your time [18:33] i hope you did that after sudo -i [18:34] then it should work [18:34] yeah, I used the "administrator terminal" not the normal one [18:35] rtg: at least it compiles with reverted toshiba [18:36] Hello People [18:37] I loaded the lastest hardy update and my dual amd opteron 840 will not boot anymore [18:38] Mike_Feravolo: i guess because of amd74xx kernel module in initrd ;) [18:38] hmm [18:38] i just what to make sure that someone knows [18:38] boucma1: didit boot [18:39] Kano: yes, but pidgin froze at startup like it used to, I'll start a few app to see if it's better than previously [18:39] i have been running the hardy alpha for a couple of months and this is the first major snarl [18:39] and login was very slow... [18:40] boucma1: but at last the hd should be fast, you could check that [18:40] kano- hangs on the UBUNTU splash screen [18:40] Kano: yes, it seems to work better but still very slow [18:40] boucma1: i only use the kenrel not the rest [18:41] Kano: well, pidgin start time was my measure of perf, but it applies to everything [18:41] it's usable now, at least [18:41] boucma1: fdisk -l [18:41] then you will see only sd? [18:41] you can then check performance with [18:41] hdparm -tT /dev/sd? [18:42] I am not near that system now, but i will try a few things before reloading gusty - Thank You [18:42] Mike_Feravolo: can you boot antoher kernel? [18:42] /dev/sda: [18:42] Timing cached reads: 1604 MB in 2.00 seconds = 801.97 MB/sec [18:42] Timing buffered disk reads: 220 MB in 3.00 seconds = 73.27 MB/sec [18:42] (no idea if that's good [18:43] sure, without dma it would be less than 10 the 2nd one [18:43] ok [18:43] yes the gusty 64 live cd boots, so does dsl, slax and other 32bit distros [18:44] well you only need a live cd to chroot to it [18:44] if your install is 64 bit you need that of course [18:44] kk [18:44] thanks [18:44] ok, thx a lot, I'll use it like that [18:44] bye all [18:45] rtg: i hope you get how bad the amd* module is... [18:45] via is not needed too [18:47] blacklisting is a bit dangerous to older kernels,but easy to verify [18:47] best disable the modules you dont need [18:50] via+amd are the most common ones [19:10] rtg: disable at least [19:10] grep BLK_DEV /boot/config-2.6.24-10-generic |grep -e AMD -e VIA [19:10] CONFIG_BLK_DEV_AMD74XX=m [19:10] CONFIG_BLK_DEV_VIA82CXXX=m [19:10] to avoid huge problems [19:10] amd is critical [19:33] rtg: also you could use -jX for lum too [19:37] rtg: http://paste.debian.net/50205 [19:37] thats the problem with ivtv-fb [19:58] rtg: what you try is to use ivtv-driver.h [19:58] rtg: thats basically , but then you have to fix the driver itself [19:59] Kano: is there a patch for ivtv-fb ? [19:59] well not an easy one [19:59] 1.0.3 is only up to 2.6.23 [19:59] where did you get the driver? [20:00] dunno, probably inherited it from Feisty/Gutsy === clever_ is now known as clever [20:02] will check if the driver can be used from v4l hg [20:03] maybe you need then ivtv + ivtvfb from hg [20:10] hmm that will also need m52790 [20:16] Kano: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/197089 [20:16] Launchpad bug 197089 in linux-ubuntu-modules-2.6.24 "ivtv oops" [Medium,Confirmed] [20:17] well disalbing is not really fun. as you could even use a new xorg driver with it or for pvr350 output plugin [20:18] btw. the -j bug is in lum too [20:18] for debugging -j1 is more easy but in that case you can set CONCURRENCY_LEVEL=1 if needed [20:29] rtg: maybe it is much more easy [20:30] you have that module already [20:30] in the main kenrel [20:30] but you miss the right firmware [20:31] Kano: attaching a patch to the LP report increases the likely hood that it will get fixed . [20:31] rtg: you can remove the code completely from lum [20:31] the module is default and enabled in the kernel [20:31] you only need the correct firmware [20:32] which needs to be updated in lum [20:32] hmm [20:33] when this is already in lum just disable the module -you can completely remove the code [20:33] http://paste.debian.net/50210 [20:33] when i remove lum [20:34] grep -i ivtv /boot/config-$(uname -r) [20:34] CONFIG_VIDEO_FB_IVTV=m [20:34] CONFIG_VIDEO_IVTV=m [20:34] standard kernel [20:34] is the firmware the same version as is already in lum? the file names are the same as the web site. [20:34] didd not try, but look [20:34] isnt that nice [20:35] its certainly an easy fix. [20:43] where can I find a list of .patch files used in the Ubuntu Gutsy kernel? as in each individual patch, like for example just ubuntu's apparmor patches or just ubuntu's dazuko patches [20:45] rtg: yes and it seems to work [20:45] NthDegree: https://wiki.ubuntu.com/KernelGitGuide [20:46] http://paste.debian.net/50212 [20:46] NthDegree: search the log for 'SAUCE:'. Thats most of our special patches. [20:46] hmmm [20:47] so you just have to disable some legacy ide modules [20:47] Kano: I'm still researching that [20:47] rtg: so there's no chance of just grabbing things like a linux-2.6-apparmor.patch or the like that applies to the Ubuntu kernel then? [20:48] rtg: kanotix thorhammer has a kernel completely without config_ide set. only very few pcs could not boot it [20:48] the 2 modules i told you before are definitely verified [20:48] and share the same pciids [20:48] Kano: its likely that I'll blacklist them so that the binaries are still built, just not installed. [20:49] no good idea [20:49] because when somebody executes update-initramfs -uk all [20:49] then older 2.6.22 kernel will never be bootable [20:51] isnt something like that even triggered by module-init-tools? [20:51] you can use that as hotfix [20:51] but no for permanent use [20:52] Kano: start an LP report so we don't lose track, but its gonna have to wait until after Alpha 6 and I'm gone Mar 4-27 so you'll have to deal with the other kernel folks [21:13] hmmm... https://wiki.ubuntu.com/ZenKernel