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