=== asac_ is now known as asac
[13:19] <tjaalton> hum, something strange going on with multipath on initramfs, since I had to run 'kpartx -a -p -part /dev/mapper/mpath0' manually to create the devices. anyone have an idea why the kpartx udev rules failed to run that? or pointers how to debug the root cause?
[13:19] <tjaalton> this is jaunty of course
[13:27] <tjaalton> ok, "break=bottom" apparently should allow me to see how it fails
[14:11] <Kano> hi rtg , i would suggest do comple agp not static, seems to cause some problems when everything is active
[14:12] <Kano> i see not increased boot speed anyway
[14:12] <rtg> Kano: what problems is agp causing?
[14:13] <Kano> newer ati cards like r600+ on old agp systems fail
[14:13] <Kano> fglrx does not load
[14:13] <rtg> is this a change from 2.6.28-3 to 2.6.28-4 ?
[14:14] <Kano> yes, now are much more things static
[14:15] <Kano> i would not have got anything against if you would compile every PATA/SATA driver static however, that usually does not hurt and you can boot without initrd in many cases
[14:15] <Kano> but you dont need agp to boot
[14:16] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commitdiff;h=6a2b8564b7afe9a4cd44935e6c8a555e27236ada
[14:17] <Kano> i did not get the purpose of that commit
[14:17] <rtg> Kano: Can you build a test kernel with 'CONFIG_AGP_ATI=m' and confirm that it is really the problem?
[14:18] <Kano> i did, currently they use 2.6.27 kernels, but the ones with that problem are not online right now. its not me with that problem
[14:18] <Kano> somebody even needed to go back to 2.6.24...
[14:19] <rtg> hmmm, that doesn't really indicate an issue with AGP being built in.
[14:20] <Kano> i guess i am right, but will tell you when they are back
[14:20] <Kano> sed -i 's/\(CONFIG_AGP.*=\)y/\1m/' debian/config/i386/config
[14:20] <Kano> i used that for testing
[14:23] <rtg> Kano: I want to know why CONFIG_AGP_ATI=y is causing problems. Can you start a bug report and attach dmesg info and other pertinent information?
[14:24] <Kano> i dont think thats ati, because they often use nvidia boards
[14:24] <Kano> like nforce2 + radeon 2600
[14:25] <Kano> but i even know of a ati laptop with onboard vga (vostro 1000) which fails to load fglrx with that -4 kernel
[14:25] <rtg> Kano: so, you think its CONFIG_AGP=y that is the real issue?
[14:25] <Kano> nvidia would run even when agp is not working, so no good test
[14:26] <Kano> rtg: i will verify that as soon as the others are here, but at least those options directy adress the problems they have now
[14:53] <Kano> tseliot: is there a package for nvidia 180.18' vdpau+ header?
[14:56] <tseliot> Kano: only 180.11 ATM
[14:56] <Kano> not good
[14:56] <tseliot> I know
[14:56] <Kano> vdpau changed with 180.16
[14:57] <tseliot> Kano: I know. I'm working on other things but as soon as I'm done with them I'll upload the new driver
[14:57] <Kano> well it would be good to use it as build-dep for xine-vdpau or mplayer
[14:58] <Kano> in theory it should not really matter if vdpau libs are installed with other drivers
[14:59] <Kano> which can not use em
[15:39] <tjaalton> hrm, my jaunty still won't mount NFS mounts
[15:40] <rtg> tjaalton: -4 was supposed to fix that
[15:41] <tjaalton> rtg: yes I noticed. I've got a freshly installed server which hangs on boot likely because of that. I've got a workstation here and I'll try -4 with it
[15:41] <rtg> drat!
[15:43] <tjaalton> works, but I wonder why the server doesn't
[15:43] <tjaalton> it doesn't mount them on boot though, had to do it by hand
[15:45] <rtg> tjaalton: I presume the server would also hang on boot with -3?
[15:46] <tjaalton> rtg: possibly, can't verify it anymore since I got it to boot from a multipathed device tomorrow (with a patched grub), so before today it didn't boot at all :)
[15:46] <tjaalton> it'll timeout after a few hours though, I hope
[15:52] <tjaalton> eh, s/tomorrow/today/
[17:40] <Kano> rtg: something else: please disable: CONFIG_USB_SUSPEND because when this is set, scanners do not work correctly
[17:42] <rtg> Kano: Intrepid has the same issue, right?
[17:43] <Kano> rtg: please dont force me to test that always
[17:44] <rtg> Kano: my point is that I didn't explicitly change CONFIG_USB_SUSPEND, so Intrepid likely has the same behavior.
[17:44] <Kano> no reports about not working xsane?
[17:45] <Kano> do you own a scanner
[17:45] <rtg> nope
[17:45] <Kano> thats not good to test
[17:45] <Kano> maybe get one from the sane list
[17:46] <rtg> Kano: CONFIG_USB_SUSPEND causes scanners to not work _after_ resuming, right?
[17:47] <Kano> nope it must do something else, it has nothing to do with suspend to ram or so
[17:47] <Kano> that some auto suspend
[17:48] <Kano> it disables usb ports somehow
[17:49] <Kano> i guess you can patch sane to enable it before use
[17:49] <rtg> Kano: I'm looking at the kernel source to see what it does.
[17:49] <Kano> but i can not think that you really gain much energy by doing so
[17:49] <Kano> http://www.blackberryforums.com/linux-users-corner/97661-enable-disable-config_usb_suspend-s-autosuspend-mode.html
[17:50] <Kano> only usefull for laptops anyway
[17:51] <mjg59> No
[17:51] <mjg59> Useful for anything with USB
[17:51] <Kano> to save how much energy?
[17:52] <mjg59> Depends on how many USB ports you have
[17:52] <mjg59> In any case, it's now only autoenabled for hubs and a small number of specific devices
[17:52] <Kano> well scanners do not like it
[17:53] <mjg59> Bug number?
[17:53] <Kano> mjg59: seek for sane errors
[17:54] <mjg59> No
[17:55] <mjg59> Ever since 7d2c592609a7da950b458403f1936d382f38ff9c, autosuspend has been disabled by default except for hubs and any device where the kernel driver claims it supports autosuspend
[17:55] <mjg59> Which was August 2007
[17:55] <mjg59> Which means it'll be disabled by default on scanners, regardless of whether it's enabled in the kernel config
[17:56] <rtg> Kano: with Intrepid you can disable autosuspend in /etc/modprobe.d using "options usbcore autosuspend=-1", but Jaunty is likely gonna require a boot parameter 'usbcore.autosuspend=-1'
[17:56] <Kano> rtg: be sure i dont use ubuntu
[17:57] <rtg> Kano: I guess thats always a choice.
[17:57] <mjg59> Kano: It might be an idea for you to make sure you understand what the kernel actually does before making suggestions about default configuration
[17:57] <Kano> mjg59: well those config tunings help my users however
[17:58] <Kano> if yours dont need, ok
[17:58] <mjg59> Kano: Not on any kernel since 2.6.24
[17:58] <mjg59> Kano: Nowadays, my users are anyone who runs the kernel
[17:59] <mjg59> If you want your users to have their systems use more power, then that's your business. I just want to make it clear to you that your reason for doing so is invalid in this case.
[18:00] <Kano> well i tested the default config and i got reports of non working scanners
[18:01] <mjg59> With which kernel?
[18:01] <Kano> 2.6.28-4
[18:01] <mjg59> This seems unlikely. It's of course possible that there's a bug.
[18:02] <mjg59> What USB class do they present as?
[18:03] <rtg> mjg59: on a different topic, what are your thoughts about building in all PATA/SATA drivers as a step towards avoiding the initramfs delay? Are there module load order side effects?
[18:04] <mjg59> rtg: There are order side effects, but the default link order in the kernel should be correct
[18:04] <Kano> rtg: usually the buildin drivers even init in a more deterministic way than as module
[18:04] <Kano> i used that config before, no problem at all
[18:05] <rtg> I assume there a boot time parameters that help those cases where the order is not correct?
[18:05] <mjg59> Don't /think/ so
[18:05] <rtg> how about the SATA controllers? are they mostly well behaved?
[18:05] <mjg59> Device specific will init first. If they don't bind, the generic ACPI driver will attempt to. If that doesn't, the generic pci driver will attempt to. If that doesn't, the legacy driver will attempt to.
[18:06] <mjg59> Yeah, this is for all libata stuff
[18:06] <mjg59> You risk problems if you mix stuff from drivers/ide and drivers/ata
[18:06] <Kano> rtg: you can savely enable all SATA+PATA drivers
[18:06] <Kano> just do never enable legacy ide
[18:07] <Kano> as this is not set, i see no problem
[18:08] <rtg> Kano: right, but enabling all pata/sata drivers requires a bit of work in the debian installer bits too, so its gonna take awhile.
[18:09] <Kano> at least thats more important for booting without initrd than the ones you enabled now
[18:09] <rtg> Kano: its an iterative approach. 
[18:10] <Kano> its highly unlikely that you could boot without initrd even when you compile dm things in the kernel, as it needs user space tools
[18:11] <rtg> some of the stuff we chose to compile in is core protocol code, code that is relatively invariant.
=== pgraner_ is now known as pgraner
[21:05] <plipp> i guys & gals. Could I get some pointers on module-building?  I've downloaded the source through 'sudo apt-get build-dep linux-image-$(uname -r); apt-get source linux-image-$(uname -r). 
[21:05] <plipp> Copied the config from /boot and built with "make modules" However, I get versioning issues when running them "no symbol version for struct_module"
[21:06] <plipp> I mean 'Hi' (I'm not french).
=== Michiel is now known as Guest81991
=== Guest81991 is now known as Eghie_
[21:21] <plipp> That is, rebuilding a module to a generic kernel
[21:32] <rtg> plipp: https://wiki.ubuntu.com/KernelMaintenance, start with 'Getting the source', then 'Performing builds'
[21:49] <Kano> rtg: verified, fglrx works with agp modules -but not static.
[21:49] <Kano> just tested
[21:50] <rtg> Kano: ok