| === doko__ is now known as doko | ||
| === akgraner_ is now known as akgraner | ||
| === soren_ is now known as soren | ||
| 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:30 |
| 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:31 |
| rpinto | anybody worked with asterisk+voip? | 13:37 |
| apw | rpinto, which kernel version are you running on there | 14:17 |
| rpinto | 2.6.24-24-server | 14:19 |
| apw | smb, seen anything like that? | 14:20 |
| smb | apw, not that I remember... | 14:21 |
| 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:29 |
| 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:30 |
| 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 | 14:31 |
| rpinto | any idea on my issue? | 15:00 |
| 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:09 |
| 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... | 15:15 |
| lxp | hi | 16:30 |
| lxp | is it possible that the current karmic kernel is missing cpio as build-dependency? | 16:31 |
| 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:37 |
| 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:38 |
| 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:39 |
| lxp | cpio dependency was removed in dpkg version 1.15.0 | 16:40 |
| rtg | lxp, so, do you think it needs to be added to the kernel package as a build dep? | 16:41 |
| * apw had the feeling we got cpio for free via some other standard build environment deps | 16:42 | |
| rtg | apw, maybe that has changed. | 16:43 |
| apw | yeah tends to unfortuanatly | 16:43 |
| lxp | sorry i was away | 16:58 |
| lxp | it would be good if someone else could verify if cpio should be added as build dep | 16:59 |
| 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:03 |
| rtg | lxp, I've add cpio as a build dep, so it'll take effect on teh next upload. | 17:04 |
| lxp | thanks | 17:04 |
| 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:53 |
| 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:54 |
| rtg | apw, I assume it'll build, but will it fix your race problem? | 18:55 |
| 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 | 18:56 |
| apw | <Keybuk> 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:56 |
| 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:57 |
| apw | it doesn't have any obvious options | 18:58 |
| 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 | 18:59 |
| rtg | apw, yep - backend.c:static __init int agp_setup(char *s) ... | 19:01 |
| === Wim_ is now known as wim | ||
| apw | ok i'll see if it can be flipped and get the hoover on a kernel | 19:02 |
| rtg | apw, do you remember offhand the magic incantation to stimulate sreadahead profiling? was it just 'profile' ? | 19:08 |
| apw | hmmm, i think so, but cannot remember accuralty | 19:09 |
| 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:54 |
| 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:55 |
| 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:57 |
| 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 | 21:58 |
| Keybuk | isn't that just a single macro? | 22:00 |
| Keybuk | it'd be worth talking upstream | 22:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| rtg | well, for karmic we're gonna have to use an uglier solution, like symbol dependencies. | 22:05 |
| Keybuk | really? | 22:08 |
| * Keybuk thought there was a MODULE_DEPEND macro or something | 22:08 | |
| 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:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| Keybuk | in which case, i915 should just depend on it? | 22:14 |
| mjg59 | I don't think there's any direct symbol use | 22:14 |
| mjg59 | i915 just calls into the AGP subsystem | 22:15 |
| Keybuk | sure, but you can add an explicit depend too | 22:15 |
| Keybuk | I'd tell you the macro but I had no git tree here, and it's being git (ie. slow) | 22:19 |
| 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. | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!