[01:03] All, this isn't a bug, but more of a feature request. I had a fella need more that 4x Serial ports on his base install the other day. The Kenel is set to Max 4x ttyS, and passing a kernel command ixed it: 8250_nr=6 .. where would we make the request for this to be built into the Kernel? [01:24] KE1HA, what kernel version did you do this on? [01:27] Oh, boy, it was a couple days ago, but it was the latest 10.04 base install w/Upgrades. [01:28] Let me look at mine real quick. [01:29] Im not sure to be hones, was 32 to 35 somwhere in there. I need to catch the guy in ubuntu IRC again and ask to be certain. [01:30] KE1HA, I'm not finding that param in the kernel source, also check the spelling [01:31] It was a Debian solution to pass the kernel param, will go find it. [01:31] KE1HA, ok thanks [01:36] pgraner, Here's what led me to the solution, but Im still looking for the Deb document page. [01:36] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440807 [01:37] Debian bug 440807 in linux-2.6 "increase CONFIG_SERIAL_8250_NR_UARTS (number of serial ports)" [Wishlist,Fixed] [01:37] pgraner, basically, addign this to the boot image in grub solved it for him, he needed 6 ports: 8250.nr_uarts=5 [01:42] KE1HA, the best way to do it is via the /etc/modprobe.d system and add an "options" line with that param [01:43] KE1HA, we keep it at a low number due it consuming memory, since most people have 1-2 ports on average [01:45] pgraner, rr. yes, I didn't understand why he needed that many either, but he did, so we came up with a work around for not ahving to re-compile the kernel. I need to read up on the /etc/modprobe.d method. Still can't fid the flippen Debian page, errr [01:46] cut off the first part of the. I dont knwo whay he needed that many, but he did .. .. .. [01:46] pgraner, where can I read about the mode proble method ? [01:47] modprobe* [01:51] KE1HA, here is a decent tutorial that should work [01:51] http://atlanticlinux.ie/blog/?p=134 [01:51] TNX [02:13] pgraner, i just whacked two folks off of the plumbers attendance page [02:13] pgraner, (with their permission) [02:13] bjf[afk], huh? [02:13] bjf[afk], ok, I guess === bjf[afk] is now known as bjf [02:26] So, my cursor disappeared somewhere between 2.6.35-rc6 and 2.6.35 (final). Would it be more helpful to run a git bisect on the mainline kernel or the Ubuntu kernels? [02:30] rebooting [02:32] stenten: If you're using the Ubuntu kernels then bisecting the Ubuntu kernel will likely be more useful - it might some of our sauce. [02:32] I tested with the two mainline kernels from the mainline PPA, and rc6 works but the final doesn't. [02:33] (That's because I just installed A3 for iso-testing, so I only have the -14 (2.6.35 final) kernel installed, and don't know where I could install the older ones from). [02:35] Trying to find a good tutorial for git-bisect right now, since I've never done it before.... [02:36] stenten: it's fairly straighforward: [02:36] git bisect good v2.6.35-rc5, then git bisect bad v2.6.35 [02:36] then it'll put you on a commit to test [02:37] those version numbers would be suitable for testing upstream; you'll need to change them if you're testing the ubuntu kernel [03:01] Am I supposed to 'git clone' one of the git repositories from kernel.org before I git bisect? I'm *really* confused right now "( [03:04] You need a local repository, so if you don’t have one, you need to clone it from somewhere. [03:05] And that contains all the commits that I'm going to bisect, right? [03:05] Yes [03:06] OK, I'm git clone-ing the 2.6.35 git repository right now, I'll be back if I get terribly confused again. Thanks. [05:11] cooloney:are you working on bug #588243 [05:11] Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243 [05:12] if not I may take a look at it === lag is now known as Guest33319 [06:08] Morning [06:12] lag_: its too early for you.. [06:13] Yes, it's fairly early for me (just gone 6) [06:29] cooloney: ping === lag is now known as Guest69465 === mdeslaur-afk is now known as mdeslaur [07:50] Morning smb [07:51] lag_, morning [07:54] cooloney: You there yet? [07:54] smb: What's the flag to forward SSH keys? [07:54] -A I believe [07:57] smb, -A indeed [07:57] though it doesn't forward your keys per-se rather forwards the connection to your authentication agent [07:58] How do you use it? [07:59] ssh -A destination [08:00] lag_: yeah [08:00] then that machine can ssh or indeed ssh -A somewhere else, but can talk to the original local key manager to get permission to login [08:00] -A [08:00] Openfree`: hi [08:00] It doesn't work :( [08:00] cooloney, hi~ [08:00] lag_: -A doesn't work? [08:01] Yeah [08:01] ssh -A build-one [08:02] ssh build-two [08:02] Password: [08:02] :( [08:02] lag_: no idea [08:02] it works for me [08:03] lag: does build-two have your ssh key in authorized_keys ? [08:03] jk-: yeah, that might be the root cause [08:04] jk-: Yep [08:04] I can ssh build-two from dev-one [08:05] Do the *.pub files need to be there? [08:05] Or just authorized_keys? [08:05] just authorized_keys [08:05] That's what I have [08:05] so you can ssh without a password from dev-one? [08:05] ssh build-two from dev-one works [08:05] Yes [08:06] To build-one and build-two [08:06] ----------^ === lag is now known as Guest13436 [08:07] OMG - bip took 1.5hrs to log into FreeNode [08:07] maybe try ssh -vvv build-two, see why it's failing to use public key auth [08:07] kk [08:54] apw: If you issue "/etc/init.d/bip restart" how log does it take to connect to FreeNode? [08:55] lag no idea, don't do it ever to be honest [08:55] not hours though [08:55] :( [08:55] bip -v ? [08:55] and cirtainly not going to try it now in case t does take hours [08:56] invalid option [08:56] Really? [08:56] lag@bip-server:~$ bip -v [08:56] Bip IRC Proxy - 0.7.4 [08:56] Copyright © Arnaud Cornet and Loïc Gomez (2004 - 2008) [08:56] Distributed under the GNU Public License Version 2 [08:57] Current version is 0.8.3 [08:58] Correction 0.8.4 === lag is now known as Guest71543 [09:06] lag_, must be as old as hell :) [09:07] Yeah [09:07] Just issued ... safe-upgrade [09:08] upgrade and safe does not compute [09:09] * amitk looks up safe-upgrade [09:09] is this apt-get ? === lag is now known as Guest27899 [10:32] schroot -q -cmaverick-armel [10:32] E: Failed to execute “/bin/bash”: Exec format error === amitk is now known as amitk-afk [11:09] ogasawara, i don't think the ndiswrapper problems are over. my drivers are set up properly and scan for ssids on any kernel i throw at it, but it won't be able to connect on any kernel newer than 2.6.34-5.14 [11:09] doesn't matter if there is security on the router or not [11:32] apw: are your patches for drm (not to make plymouth believe that drm is ready when it's not) ready? [11:32] tseliot, the patches are applied to the uploaded maverick kernel [11:33] apw: great, I'll pull them from git [11:52] Hi, I just saw that linux-image-2.6.32-24.39 is out, but I can't seem to find it in git. I made a git pull and the last tag seems to be Ubuntu-2.6.32-24.38. How can I update my git in order to work on it? [11:54] sorry, I meant linux-image-2.6.34-24-generic, version 2.6.32-24.39ù [11:57] andreoli, yep, the repo is behind as that was a security release [11:57] i'll hastle the culprit and get it up as soon as possible [11:58] no problem, apw :) I thought it was my fault somehow (git newbie, trying to learn...) [11:58] is it sensible to host several kernel ubuntu packages (with different names) in the same PPA? [11:58] andreoli, no just the rules on exposing security before the binaries are released, prevents us pushing, and its another team which pushes security [12:01] ok, thx for the clarification === yofel_ is now known as yofel === amitk-afk is now known as amitk [12:53] apw, I hear ya. Being on that [12:57] amitk: i tried enable SMP in omap3_defconfig to built a single kernel for omap2/3/4. [12:58] amitk: after fixed some compiling issue, i've built the kernel. [12:58] but it doesn't work on my omap3 beagle board. [12:58] cooloney: I talked to TI engineers and they feel it will take some low-level arch work in arch/arm to get SMP arm kernels to work on UP [12:58] it looks like it's not easy to enable SMP in such single kernel [12:58] amitk: yeah, i think so [12:59] so ARM needs to go through the same pain the x86 and other archs did to get SMP kernels working on UP [12:59] in SMP code, there some instruction can't be built in gcc as armv6 [13:00] * amitk is not surprised === lag is now known as Guest6225 === Guest6225 is now known as lag_ [13:50] tgardner, While working there I just noticed an arm branch in the Karmic repo which you have been committing to long time ago. Would you think we need anything from that anymore? [13:51] smb, if its not in the archive, then I suspect no [13:52] tgardner, Its at least heavily neglected. The last commit was a year ago.... So I guess, no. Well I tag it before removing the branch [13:52] smb, wfm [14:15] tgardner: Build server orange is broken [14:15] schroot -q -cmaverick-armel [14:15] E: Failed to execute “/bin/bash”: Exec format error [14:15] apw, wasn't that an mmap issue? [14:16] apw: Tried to fix, but doesn't have perms [14:16] tgardner, The direct issue is binfmt-misc not loaded / set up [14:16] lag_, tried to fix how? [14:17] Not sure this was because of an mmap thing [14:17] Restarting binfmt-misc [14:17] Apparently it wasn't started by the init scripts [14:17] smb thinks it may be a race [14:18] Or maybe its as simple as needing to add binfmt-misc to /etc/modules... [14:19] lag_, restarted, try again [14:19] Hm no, don't have that on my build box and it gets loaded [14:20] tgardner: That's the badger! [14:21] Any chance of getting KOSAKI Motohiro's low latency synchrounous lumpy reclaim patch set applied to Maverick? http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/02107.html [14:21] Is the discussion really finished? [14:35] from the description its still an RFC [14:36] That was my feeling. Mel was also involved and it did sound incomplete. Though, as it showed up on my stable watchlist, it might come that way when done. [14:40] it would be nice to get some more data somehow though, it is attempting to address a bug that has been plaguing the desktop for years so the sooner it dies the sooner we can drink beer [14:53] Sure it would be nice to fix it. But taking patches under discussion from a mailing list for a essential core functionality is like tuning your car according to some information found somewhere. It is crazy enough to it on yourself but you certainly don't want to resell that. [14:54] or in this case 'regift' ;) [15:17] apw, do you plan to add the DEB_STAGE=stage1 patch to debian commonization? [15:26] moin all [15:26] morning bjf === sconklin-gone is now known as sconklin [15:31] bjf, morning! [15:32] bjf, where do those kernel team iso images appear - are they downloadable from a webby URL? [15:33] cking, http://kernel.ubuntu.com/~kernel-ppa/testing/ [15:36] bjf, you probably can expect what my next question is going to be... [15:36] ..any chance of hooking up my USB stick image generating hacks? [15:36] cking I thought you were going to get back to me on that [15:37] I believe I sent you an email. lemme see if it got stuck somewhere :-( [15:37] cking, nope, I just missed it [15:37] 03 2010, ~17:57:35 [15:38] cking, don't know about checking in a vm to kteam-tools [15:38] it's rather big ;-) [15:39] dang, that's one thing that version control cannot handle well [15:39] /query dendrobetes [15:40] pgraner, dendrobates isn't it? [15:40] tgardner, yea misspelled, thx [15:41] a large green frog IIRC [15:41] tgardner, that I didn't know [15:41] tgardner, i am assuming all things which get accepted into maverick should also get applied to the common debian [15:41] a poisonous dart frog at that [15:42] apw, I'm cnosidering the ripple effect. We still need to get Karmic updated. [15:42] tgardner, its an issue indeed [15:56] tgardner, i don't think i have a good plan if we are not going to commonise en'toto [15:56] ie, all those using the common debian, remain up to date [15:56] apw, we need cjwatson to finish his policy update [15:57] bjf, so is this image generator hack a no-goer, or just we need to make sure we keep that vm image somewhere safe? [15:57] tgardner, yeo [15:59] cking, might be worth asking cjwatson when he is back ... as this is something they must have as an issue too for the isos [16:00] cking, i have no problem adding it to the process, it's just you might have to recreated it if necessary [16:00] apw, what's the issue? [16:01] bjf, I will back it up onto a couple of devices [16:04] cking, the VM is needed to install grub yes? [16:07] yep [16:08] the issue is that grub-install does some over-zealous sanity checks which cannot be spoofed around using loopback or device mapper tricks [16:09] one can modify grub-install, but I cannot be bothered - it's easier to do it in a 15 lines script inside a vm [16:16] apw: are you going to backport your 2 kernel patches for drm and fbcon to Lucid. If not, shall I? [16:16] tseliot, do we have those issues on lucid ? [16:16] i've only ever seen the behaviour on maverick [16:17] apw: I think I've seen the drm problem but I'll test again, just to be sure === robbiew1 is now known as robbiew [16:22] tseliot, ok thanks ... good to know [16:33] pgraner, what was the name of the place where you bought our travel case? [16:57] JFo, I think pgraner buys it in bulk 'cos they go missing so frequently at the airports [16:58] but that would be me since I lost the most this last time :) [16:58] 3 bags [16:58] he only had one lost [16:58] JFo, I hadn't realised that. That's really bad news. [16:59] well, they are back now, but it took 3 days after we landed to get them [16:59] If it's any consolation, I think I found a security cable from UDS that may be yours [16:59] I'm just looking at getting us a bigger box [16:59] could be indeed [16:59] JFo, next time fedex your luggage [16:59] heh [17:06] <-lunch [17:07] Test [17:14] cking, i've added the img creation steps to the dail-iso-builder script and i'm running a test [17:15] apw, Works [17:15] smb, indeed so [17:20] bjf, fantastic. thanks [17:21] much appreciated [17:35] * smb is out [17:48] ogasawara: incoming!....https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/554172 (boom!) [17:48] :P [17:48] Ubuntu bug 554172 in linux (Ubuntu Maverick) (and 2 other projects) "system services not starting at boot (affects: 178) (dups: 15) (heat: 781)" [High,Confirmed] [17:48] robbiew: ack [17:49] 237 comments! [17:49] ogasawara: yeah...you can ignore 236 of them [17:49] just read Scott's [17:49] #237 [17:50] prolly a dumb q ... how long does it take for a kernel to move from pre-proposed to proposed? [17:51] vanhoof, its somewhat arbitrary for a released kernel, but generally every couple of weeks. [17:54] bug #554172 [17:54] Launchpad bug 554172 in linux (Ubuntu Maverick) (and 2 other projects) "system services not starting at boot (affects: 178) (dups: 15) (heat: 781)" [High,Confirmed] https://launchpad.net/bugs/554172 [17:54] tgardner: cool, thanks === lag_ is now known as lag [18:11] /msg NickServ identify nelsons === lag is now known as Guest46722 [18:11] lag, change it NOW [18:11] Done [18:11] :) [18:12] Keybuk, this EIO thingy on open ... which kernel are you testing [18:16] reports are on both Lucid and Maverick [18:16] I read the source of GIT HEAD [18:16] though the code was last touched in 09 [18:17] Keybuk, and indeed the comments at the time say that returning EIO on a 'tty' which has been closed, but not yet completed closing should return EIO [18:17] the implication is that this behaviour is reasonable, and supported by POSIX [18:17] s/reasonable/expected [18:19] I'm not sure POSIX says anything about ttys [18:19] or indeed about the ability to half-close something [18:19] can you point me at the comments? [18:19] do a git log on the file containing tty_reopen [18:20] Keybuk, it is documented as a possible return in the open manual page [18:20] EIO The path argument names a STREAMS file and a hangup or error [18:20] occurred during the open(). [18:20] the implication is that last close being inprogress is a hangup on a tty [18:20] that implication sounds more like an SMP-unaware race condition to me ;-) [18:21] Keybuk, cirtainly the behaviour makes more sense for slow closing things like modems, where there is an external interlock to wait on [18:21] yes, but not /dev/console ;-) [18:22] but it cirtainly seems possible that there is a period during which a closing device is unopenable, for ttys [18:22] and /dev/console is a tty like any other no [18:22] it's not supposed to be [18:22] what makes you say that [18:23] because it's supposed to be a virtual device [18:23] stop trying to kill my pony [18:23] that doesn't stop it being a tty [18:23] it also doesn't stop this being wrong behaviour [18:24] indeed, but it also may well be reasonable behaviour, and if it is then we arn't likely to get a fix past alan [18:24] breaking init doesn't seem reasonable though? :) [18:25] nothing about this is upstart specific, after all [18:25] if init breaks cause it doesn't handle documented return codes, he isn't going to have any sympathy is he [18:25] it's not documented anywhere [18:25] i assume you have to handle EAGAIN and EINTR already [18:25] * Keybuk is reading tty(4) [18:25] EIO The path argument names a STREAMS file and a hangup or error [18:25] occurred during the open(). [18:25] it documented as a valid return from open [18:25] yes, but not any explanation as to why it would occur [18:26] and [18:26] err [18:26] no it isn't [18:26] open(2) does not document EIO [18:26] indeed not, but that a tty is a stream as you can push line diciplines [18:26] (thats for your tty ocmment) [18:26] open 2 is libc right? [18:27] manpages-dev [18:27] 3 is the system call [18:27] (isn't it ?) [18:27] it's not POSIX either FWIW :p [18:28] It was wrong anyway! :) [18:28] its documented in the 3 an page, which calls itself the POSIX one [18:28] Doh === Guest46722 is now known as lag [18:28] assuming you're looking at SUS, STREAMS only refers to the XSI STREAMS extension [18:29] It was wrong anyway :) [18:29] i am reading man 3 open on my linux box [18:29] Which is why it keeps logging me in as guest :) [18:29] I don't have an open(3) [18:29] what package does that come from? [18:29] how do i find out [18:29] it could be the snarf'd copy of SUS [18:29] it says STREAMS in capitals like that, it matches SUS [18:29] which means it's XSI STREAMS, not "tty" [18:30] a tty is a steeams device though, as you can stack streams modules onto it, like line diciplines ? no? [18:30] no, STREAMS is a very specific standard [18:30] you can't randomly apply one standard to something else to suit your purposes ;-) [18:30] STREAMS is something you don't want to know about [18:30] so [18:31] It's the System V networking failure [18:31] this behaviour is not documented [18:31] this *return code* is not documented [18:31] so it's completely reasonable for me to not handle it [18:31] Keybuk, do you handle EINTR ? [18:31] what's more, it only broke in Sep 2009 as a result of a kernel change [18:31] apw: yes. [18:31] manpages-posix-dev: /usr/share/man/man3/open.3posix.gz [18:31] apw: right, that's SUS - so STREAMS refers to XSI STREAMS which is not relevant (and deeply scary) [18:31] well i suggest you handle it now, regardless of whether its reasonable [18:31] no, I suggest you fix the kernel [18:32] since this is a regression [18:32] cause even if we can fix it, its likely to take months to get it accepted [18:32] it's affecting a small number of people [18:33] the reality is if we bodge it in upstart it'll fix everyone esle as it'll stay open forever and avoid the issue for ever [18:33] giving us time to persue a fix [18:33] manpages-posix-dev: /usr/share/man/man3/open.3posix.gz [18:33] it's possible that we'd turn this into an infinite loop, etc. [18:34] I'd rather keep the known bug [18:34] ok works for me [18:34] while you work on fixing the kernel regression [18:34] how often is it occuring ... so i can prioritise it with the other issues we have [18:34] (plus I know full well if I bodge it, the bodge will become *the* fix, and the kernel fix will never appear) [18:34] apw: some people (including support customers) claim most boots [18:34] others say intermittently [18:34] others say they've seen it once [18:35] support have given it P3 [19:18] * tgardner lunches [19:31] * apw finds it .. maybe [19:36] hi, i've got some patches which were accepted in the upstream kernel for 2.6.36, but would like to see them get into Maverick. I think they're candidates for 35 stable, but haven't submitted them yet. I was wondering what the ubuntu kernel release schedule was like and if you are going to sync up with stable before Maverick is released? [19:37] joshhunt, we normally start following the stable branch once the kernel releases at our chosen level [19:37] so we're likely to have time to take the first few stable updates for 2.6.35 for maverick before release [19:38] ok great. so if i can get them into one of the first few releases of 35 stable then that would probably be the best way to get them into maverick, right? [19:40] joshhunt, yep [19:40] apw, thanks for your help. [19:58] ls [19:58] bin cdrom etc initrd.img lib media opt root selinux sys usr vmlinuz [19:58] boot dev home initrd.img.old lost+found mnt proc sbin srv tmp var vmlinuz.old [19:58] :) [19:59] <- smartypants [20:23] * jjohansen lunch [20:30] * ogasawara lunch [20:45] apw: I just realised something [20:45] you the commit that "fixes" the Input/output error [20:45] if you look at the patch, it doesn't cover all tty drivers [20:45] just serial ones [20:59] pgraner, tgardner so we aren't attending this before plumbers? http://events.linuxfoundation.org/events/linux-kernel-summit [20:59] JFo: if your invited, sure [20:59] ah, I just got to the invitation bit :) [21:00] thanks jjohansen [21:49] Keybuk, will take a closer look tommorrow on an awake head. have some theorys to look over [21:50] * tgardner checks out [22:28] * cking calls it a day === cking is now known as cking-afk === sconklin is now known as sconklin-gone === bjf is now known as bjf[afk]