[13:30] <rpinto> The Ubuntu server at my place just hangs and stops responding and on the console the following message is seen looping  Sep 25 11:51:57 ubuntu kernel: [ 1298.605672] unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 Sep 25 11:52:07 ubuntu kernel: [ 1302.497456] unregister_netdevice: waiting for ppp0 to become free. Usage count = 1
[13:30] <rpinto> it's the ubuntu 8.04 LTS version
[13:30] <rpinto> guys please help.. this server is hanging atleast 2wice a day
[13:31] <rpinto> here's the message again
[13:31] <rpinto> Sep 25 11:51:57 ubuntu kernel: [ 1298.605672] unregister_netdevice: waiting for ppp0 to become free. Usage count = 1 
[13:31] <rpinto> Sep 25 11:52:07 ubuntu kernel: [ 1302.497456] unregister_netdevice: waiting for ppp0 to become free. Usage count = 1
[13:37] <rpinto> anybody worked with asterisk+voip?
[14:17] <apw> rpinto, which kernel version are you running on there
[14:19] <rpinto> 2.6.24-24-server
[14:20] <apw> smb, seen anything like that?
[14:21] <smb> apw, not that I remember...
[14:29] <apw> rpinto, are you able to login on the console when it does that?
[14:29] <rpinto> no
[14:29] <apw> if so then getting a ps -ef and an lsmod might be informative
[14:29] <rpinto> it just hangs
[14:29] <rpinto> no ssh or vnc
[14:29] <rpinto> nothin orks
[14:30] <apw> when u ssh in are you coming in over the ppp link or elsewhere
[14:30] <apw> and what is the ppp link being used for if at all
[14:31] <rpinto> ssh is local for me
[14:31] <rpinto> not the ppp link
[14:31] <rpinto> there are 2 ppp links
[14:31] <rpinto> 2 modems
[14:31] <rpinto> 256kbps and 2 mbps
[15:00] <rpinto> any idea on my issue?
[15:09] <smb> rpinto, Not really. Thus that much silence. It sound a bit like something on close-reopen being not cleanly handled. But I cannot recall something like this. Is networkmanager dynamically doing setup which might be set to something static for testing?
[15:09] <rpinto> how do i check that?
[15:15] <smb> I would expect it to show up under the connections shown by left-clicking on the nm applet. Unfortunately not really much knowledge there...
[16:30] <lxp> hi
[16:31] <lxp> is it possible that the current karmic kernel is missing cpio as build-dependency?
[16:37] <apw> there is no specific dependancy that i can see no
[16:37] <lxp> i tried building in my launchpad ppa and also on my local machine (with pbuilder) always with the same result /bin/bash: line 5: cpio: command not found
[16:37] <lxp> http://launchpadlibrarian.net/32984274/buildlog_ubuntu-karmic-i386.linux_2.6.31-11.38~phc0_FAILEDTOBUILD.txt.gz
[16:38] <lxp> i must admit that the kernel compiled in the ppa is modified
[16:38] <lxp> but an my local machine i also tried the unmodified one
[16:38] <apw> well the same kernel is built in the main archive
[16:38] <lxp> yes i looked at the build logs
[16:38] <rtg> apw, I think it might be a chroot problem. I had to restart the i386 build once.
[16:39] <lxp> and it seems it uses a different base tarball
[16:39] <apw> so that might imply there is a change in some other package which has tripped through
[16:39] <lxp> yes i found a change in dpkg-dev
[16:39] <lxp> but that is older
[16:40] <lxp> cpio dependency was removed in dpkg version 1.15.0
[16:41] <rtg> lxp, so, do you think it needs to be added to the kernel package as a build dep?
[16:42]  * apw had the feeling we got cpio for free via some other standard build environment deps
[16:43] <rtg> apw, maybe that has changed.
[16:43] <apw> yeah tends to unfortuanatly
[16:58] <lxp> sorry i was away
[16:59] <lxp> it would be good if someone else could verify if cpio should be added as build dep
[17:03] <lxp> but i suppose so as cpio is not founded on my clean pbuilder environment and also on the seaborgium build machine with /home/buildd/filecache-default/0517a8e2e8e875206f54e38411e83733c120b9b1 tarball as chroot
[17:04] <rtg> lxp, I've add cpio as a build dep, so it'll take effect on teh next upload.
[17:04] <lxp> thanks
[18:53] <rtg> apw, what did you and Keybuk come up with for i915/agp module load ordering? Shall we just build one of them in?
[18:54] <apw> the correct fix i think needs new infrastructure ... its possibel we could build in the agp module
[18:54] <rtg> apw, I think thats the simplest solution.
[18:54] <apw> i'll see if that builds and post some test kernels
[18:55] <rtg> apw, I assume it'll build, but will it fix your race problem?
[18:56] <apw> interestingly keybuk suggested a modprobe incantation, but it may 
[18:56] <apw> have been tounge in cheek
[18:56] <apw> rtg the sufferers are able to reproduce pretty easily
 install i915 /sbin/modprobe -qb intel-agp ; /sbin/modprobe --ignore-install i915 $CMDLINE_OPTS
[18:56] <rtg> apw, ok, I'd prefer a kernel solution for this. its the way we've solved other load races.
[18:57] <apw> yeah its clearly an issue kernel side
[18:57] <rtg> hmm, does agp need any module parameters? thats what usually bites us when we build something in
[18:58] <apw> it doesn't have any obvious options
[18:59] <rtg> apw, nope. I was just looking at intel-agp.c and couldn't see any either
[18:59] <apw> always a worry at this stage in the release
[18:59] <apw> static int __init agp_intel_init(void)
[18:59] <apw> {
[18:59] <apw>         if (agp_off)
[18:59] <apw>                 return -EINVAL;
[18:59] <apw> it would be off'able from the command line still i think
[19:01] <rtg> apw, yep  - backend.c:static __init int agp_setup(char *s) ...
[19:02] <apw> ok i'll see if it can be flipped and get the hoover on a kernel
[19:08] <rtg> apw, do you remember offhand the magic incantation to stimulate sreadahead profiling? was it just 'profile' ?
[19:09] <apw> hmmm, i think so, but cannot remember accuralty
[21:54] <Keybuk> apw: I never suggest things tongue-in-cheek :p
[21:54] <Keybuk> I instead simply stay silent
[21:54] <Keybuk> I offered the modprobe hack as a workaround for karmic provided that we agree to come up with a proper fix for lynx
[21:55] <Keybuk> I'm not a fan of building things in to solve ordering problems
[21:55] <Keybuk> I'd even like to get ehci-hcd and ohci-hcd back as modules again
[21:57] <rtg> Keybuk, I'm thinking about some macro magic that'll tie these modules together symbolically, then let modprobe just do the right thing.
[21:57] <Keybuk> as I understand it, the problem is that it's not as simple as i915 depends intel-agp
[21:58] <Keybuk> since some cards that i915 supports don't use agp
[21:58] <Keybuk> is that right?
[21:58] <rtg> Keybuk, even so, it won't hurt to load agp.
[21:58] <Keybuk> well, in that case, just make i915 depend intel-agp
[21:58] <rtg> thats kind of what I'm wiorking on. its a gross hack right now
[22:00] <Keybuk> isn't that just a single macro?
[22:00] <Keybuk> it'd be worth talking upstream
[22:01] <rtg> Keybuk, definitely
[22:01] <Keybuk> about whether we should actually have an agp: subsystem
[22:01] <Keybuk> so intel-agp would expose agp:i915 or something
[22:01] <Keybuk> and then the i915 driver would have agp:i915 as well as pci:blah
[22:01] <Keybuk> that'd mean that the ordering was enforced the _right_ way
[22:01] <Keybuk> but ime they like to pretend that agp is just an aperture to pci, rather than a subsystem in its own right
[22:02] <Keybuk> and that wouldn't solve the ehci/[ou]hci ordering problem anyway
[22:02] <Keybuk> for the latter, it looks like we're getting "soft depends" support for modprobe
[22:02] <Keybuk> where a soft dependency can be either pre or post
[22:02] <Keybuk> modprobe will try to load it
[22:02] <Keybuk> but obey they blacklist
[22:02] <Keybuk> and if it fails, won't fail the module actually being loaded
[22:02] <rtg> Keybuk, won't those soft dependencies (or load orders) have to be managed by modprobe?
[22:03] <apw> we basically want Recommends: for modules
[22:03] <Keybuk> rtg: we'll put them in modinfo like we do for depends already
[22:03] <rtg> if we're gonna do that, then why not find a kernel solution.
[22:04] <Keybuk> indeed
[22:04] <rtg> or are you talking about a soft-depends modalias gizmo?
[22:04] <Keybuk> right, exactly that
[22:04] <Keybuk> I'm muttering about what the right kernel solution might be :p
[22:04] <rtg> ah, likely a bit more elegant
[22:04] <apw> that sounds like the 'right' long term soln. to me
[22:05] <rtg> well, for karmic we're gonna have to use an uglier solution, like symbol dependencies.
[22:08] <Keybuk> really?
[22:08]  * Keybuk thought there was a MODULE_DEPEND macro or something
[22:09] <apw> we do have to ensure i915 still loads if intel-agp does not
[22:09] <rtg> perhaps. looking...
[22:09] <apw> like if you have 0 aperture enabled in the BIOS
[22:09] <apw> ie. is a hard depend going to cut it
[22:11] <Keybuk> hard depend will fail that situation
[22:11] <apw> also we need to consider the amd case, which means a different agp module
[22:12] <apw> beep, not for i915
[22:12] <Keybuk> do amd have i915?
[22:12] <apw> nope, ignore me
[22:12] <mjg59> When will you have i915 without AGP?
[22:13] <mjg59> int i915_driver_device_is_agp(struct drm_device * dev)
[22:13] <mjg59> { return 1;
[22:13] <mjg59> }
[22:13] <apw> handy
[22:13] <mjg59> i915 won't do anything useful unless intel-agp is there
[22:13] <mjg59> Otherwise you'll never get any video memory
[22:14] <Keybuk> in which case, i915 should just depend on it?
[22:14] <mjg59> I don't think there's any direct symbol use
[22:15] <mjg59> i915 just calls into the AGP subsystem
[22:15] <Keybuk> sure, but you can add an explicit depend too
[22:19] <Keybuk> I'd tell you the macro but I had no git tree here, and it's being git (ie. slow)
[22:21] <rtg> Keybuk, I didn't see anything named DEPEND in modules.h, but there might be some other possibilities. I'll mess with it more tomorrow. I'm outta here for now.