| === zenbum [n=zenbum@c-69-181-178-99.hsd1.ca.comcast.net] has joined #ubuntu-kernel | ||
| === ahe [n=ahe@mnh9-d933ba96.pool.mediaWays.net] has joined #ubuntu-kernel | ||
| === _human_blip_ [n=mike@mike.nelsonbay.com] has joined #ubuntu-kernel | ||
| === cmvo [n=cmvo@62.225.11.174] has joined #ubuntu-kernel | ||
| === Ju [n=Ju@c-24-126-231-240.hsd1.ca.comcast.net] has left #ubuntu-kernel ["gone"] | ||
| === chmj [n=chmj@196.44.1.98] has joined #ubuntu-kernel | ||
| === doko [n=doko@dslb-088-073-095-096.pools.arcor-ip.net] has joined #ubuntu-kernel | ||
| === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-kernel | ||
| === _human_blip_ [n=mike@mike.nelsonbay.com] has joined #ubuntu-kernel | ||
| === netjoined: irc.freenode.net -> brown.freenode.net | ||
| === Traxer|off [i=traxer@shell6.powershells.de] has joined #ubuntu-kernel | ||
| === JaneW [n=JaneW@dsl-146-143-165.telkomadsl.co.za] has joined #ubuntu-kernel | ||
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel | ||
| === mxpxpod [n=BryanFor@unaffiliated/mxpxpod] has joined #ubuntu-kernel | ||
| doko | how are device files for the parallel interface named? | 04:45 |
|---|---|---|
| Keybuk | do you mean the old-fashioned parallel port? | 04:47 |
| doko | Keybuk: yes, /dev/parportN | 04:47 |
| Keybuk | there isn't a device for those, is there? | 04:48 |
| doko | sure, but there should be one? | 04:48 |
| Keybuk | I doubt it | 04:48 |
| Keybuk | do you see computers with them these days? | 04:49 |
| doko | at least MAKEDEV had support to create these device files | 04:49 |
| Keybuk | really? | 04:49 |
| doko | dude, every thinkpad has a parpart ... | 04:49 |
| Keybuk | I always thought you just talked to parallel ports directly via io, rather than through a device file | 04:49 |
| doko | >>> import parallel | 04:50 |
| doko | >>> p=parallel.Parallel() | 04:50 |
| doko | Traceback (most recent call last): | 04:50 |
| doko | File "<stdin>", line 1, in ? | 04:50 |
| doko | File "/usr/lib/python2.4/site-packages/parallel/parallelppdev.py", line 186, in __init__ | 04:50 |
| doko | self._fd = os.open(self.device, os.O_RDWR) | 04:50 |
| doko | OSError: [Errno 2] No such file or directory: '/dev/parport0' | 04:50 |
| Keybuk | ok | 04:50 |
| Keybuk | loading the parport and parport-pc modules doesn't create that device | 04:50 |
| doko | yes | 04:50 |
| Keybuk | seems nobody's bothered to driver-core them | 04:50 |
| mjg59 | Mm? | 04:59 |
| mjg59 | Don't they appear as /dev/lp0? | 04:59 |
| Keybuk | that's a parallel printer | 04:59 |
| Keybuk | which is the "lp" driver | 04:59 |
| Keybuk | not raw parport access | 04:59 |
| mjg59 | Ah, yes, that does assume a printer | 05:00 |
| Keybuk | mjg59: err @ your bug reassign | 05:27 |
| Keybuk | where does the docs say rmmod is the same as modprobe -r | 05:27 |
| Keybuk | all the docs say you should use modprobe -r as its better | 05:28 |
| infinity | Keybuk: So, when you changes how root mounting works in initramfs-tools, did you break LVM along the way? | 05:38 |
| infinity | Keybuk: There seems to be some murmuring to that effect. | 05:38 |
| Keybuk | I did, yes | 05:38 |
| Keybuk | I fixed it again though | 05:38 |
| Keybuk | the upload to initramfs-tools is the fix, not the cause | 05:38 |
| Keybuk | (worth an explanation) | 05:38 |
| infinity | Indeed.. | 05:39 |
| Keybuk | we worked out, thanks to mjg59's knowledge of strange things called "reserved regions" that once a SATA driver was loaded there was no way ide-generic could steal the devices | 05:39 |
| Keybuk | when I'd investigated I was looking as to when udev got the "ADD /dev/sda" event, which is some time later | 05:39 |
| mjg59 | Keybuk: Yeah, my mistake | 05:39 |
| Keybuk | so we were able to do away with the "if ide do this, if scsi do that" branching code in udev | 05:40 |
| Keybuk | and thus we can mount root filesystems with: | 05:40 |
| Keybuk | - load PCI drivers | 05:40 |
| Keybuk | - load ide-generic | 05:40 |
| Keybuk | - wait for up to three minutes for root to appear | 05:40 |
| Keybuk | PCI IDE drivers it'll appear instantly, so it won't wait | 05:40 |
| Keybuk | ide-generic will be a no-op if a PCI driver was loaded | 05:40 |
| Keybuk | if ide-generic runs the device, it'll appear instantly, so it won't wait | 05:41 |
| infinity | Didn't we have some bizarre race in the past when doing it that way? | 05:41 |
| Keybuk | for SATA drivers the driver will reserve the regions immediately so ide-generic won't break it, but it'll be a few seconds before udev gets the real "device add" events (which we wait for) | 05:41 |
| infinity | I vaguely recall my /dev/sda being /dev/hda on 3 out of 4 boots... | 05:41 |
| Keybuk | for SCSI drivers we get the devices after waiting for a few seconds | 05:42 |
| Keybuk | three minutes is a good upper limit on any device waiting | 05:42 |
| Keybuk | right | 05:42 |
| Keybuk | we had a bug certainly, but that has gone away | 05:42 |
| Keybuk | and that was partially caused by an old kernel patch which I removed | 05:42 |
| infinity | Ahh, well that's nice to know. | 05:42 |
| Keybuk | and the fact we loaded ide-generic *first* | 05:42 |
| Keybuk | we had a strange patch on our kernels that made loading ide-generic mandatory to get any PCI IDE driver to actually probe | 05:42 |
| Keybuk | rather than just probing in the PCI IDE drivers | 05:43 |
| infinity | Special. | 05:43 |
| Keybuk | ok | 05:43 |
| Keybuk | so I modified udev to do the above sequence | 05:43 |
| Keybuk | and all was good | 05:43 |
| Keybuk | except for LVM, EVMS, MD, etc. | 05:43 |
| Keybuk | which suddenly would "hang for three minutes" on boot | 05:43 |
| Keybuk | the fact they didn't before was actually a bug :) | 05:43 |
| Keybuk | and I fixed that bug when I rewrote the udev initramfs script, which made them break | 05:44 |
| Keybuk | they should have been breaking all through dapper | 05:44 |
| Keybuk | the bug is obvious; doing the three minute wait in the udev init-premount means that evms/lvm/etc. haven't been run yet (they're run in local-top) | 05:44 |
| Keybuk | so we're waiting for a root device to appear before running the magic that makes it | 05:45 |
| infinity | Right. | 05:45 |
| Keybuk | I thought about putting the wait in a udev local-top script, but couldn't get PREREQS to play nice (it's not possible to "DEPEND ON EVERYTHING") | 05:45 |
| Keybuk | and if you depend on something that doesn't exist, your script never gets run and initramfs goes into infiniloop territory | 05:45 |
| infinity | You could prereq *, perhaps. | 05:45 |
| makx | yeah that's a bug | 05:45 |
| Keybuk | I couldn't put it in local-premount because that's after mountroot() has already panic'd | 05:45 |
| infinity | Or something equally fucked up. | 05:45 |
| Keybuk | infinity: I tried that :p you can't | 05:46 |
| infinity | But I'm pretty sure it wasn't designed to be used that way. :) | 05:46 |
| Keybuk | then I realised, that that loop code should be in mountroot() anyway | 05:46 |
| infinity | I could rewrite it to work that way, but icky corner case. | 05:46 |
| infinity | And yeah, it's better living in mountroot() | 05:46 |
| infinity | Debian may appreciate that change too. | 05:46 |
| Keybuk | so mountroot() now runs local-top, loops for up to three minutes to wait for the root to appear, then if it still hasn't appearered, loops calling panic to let the user fix it, and then carries on | 05:46 |
| Keybuk | for dapper+1 we can think about changing it to loop forever with a pretty message asking the user to insert the damned root filesystem, or press any key to get a shell, or something | 05:47 |
| Keybuk | tbh | 05:47 |
| Keybuk | for initramfs-tools, I'd rather get rid of PREREQS and just use run-parts and NN-* like everything else <g> | 05:47 |
| infinity | I don't like magic shell for dependencies either. | 05:48 |
| Keybuk | anyway | 05:48 |
| Keybuk | this should fix all occurances of the bug | 05:48 |
| Keybuk | as now we have | 05:48 |
| Keybuk | - probe for PCI devices | 05:48 |
| infinity | Not everything about Jeff's code gives me warm fuzzies, just enough to work on it. :) | 05:48 |
| Keybuk | - load ide-generic | 05:48 |
| Keybuk | - run evms, lvm, md, etc. | 05:48 |
| Keybuk | - wait for root to appear | 05:49 |
| Keybuk | - mount root | 05:49 |
| infinity | Rock. Thanks, dude. | 05:49 |
| infinity | These little bugs have been biting us since dapper opened. | 05:49 |
| Keybuk | it actually makes the boot a bit cuter too, because 9/10 now your scsi card gets its act in gear while initramfs is working up to getting to mounting the root | 05:49 |
| makx | the fixed revsion of initramfs-tools is -25? | 05:50 |
| infinity | makx: Any chance of shoving the udev side of these changes down Md's throat, so you can make the initramfs changes to match ours? | 05:50 |
| infinity | makx: Yes, 24-25 would be the patch Scott did, then obviously, his new udev hooks are important to go with it. | 05:50 |
| makx | haven't looked at the udev changes. | 05:51 |
| makx | infinity: atm i work around Md with udev_helper which prequs udev | 05:51 |
| infinity | (And make sure Debian's kernels don't have that buggy behaviour mentioned above with ide-generic) | 05:51 |
| makx | which is suboptimal | 05:51 |
| Keybuk | ubuntu20->ubuntu21 | 05:51 |
| Keybuk | infinity: Debian's kernels probably still do, because that's where we got the patch | 05:51 |
| Keybuk | it was a Xuism | 05:51 |
| Keybuk | something to do with making the old initrd "load every PCI driver" stuff less icky | 05:52 |
| makx | na it got dropped since 2.6.14 | 05:52 |
| Keybuk | ok | 05:52 |
| Keybuk | actually, you want udev ubuntu19->ubuntu21 | 05:52 |
| infinity | makx: Well, just from reading the description on IRC (haven't looked at the hooks yet), Keybuk's new udev hook is probably a fair bit simpler than before, so maybe Md wouldn't be too unhappy to include it. | 05:52 |
| makx | cool i'll take a look in some hours, will work on that. | 05:53 |
| makx | thanks | 05:53 |
| mjg59 | BenC: Do we have anything other than bcm43xx using softmac yet? | 05:53 |
| BenC | not that I know of | 05:54 |
| infinity | Keybuk: Ahh, yes, init-premount/udev looks MUCH cleaner now. Awesome. | 05:54 |
| mjg59 | Ok, cool | 05:54 |
| infinity | Keybuk: Also, usplash_write calls don't need a || true on them, it exits zero even if your computer's on fire. | 05:56 |
| Keybuk | heh, everything else does || true | 05:56 |
| infinity | Yeah, not sure who to blame for the first || true. :) | 05:56 |
| mjg59 | BenC: You have patches | 05:57 |
| BenC | patches!? we don't need no stinkin' patches! | 05:58 |
| mjg59 | They ought to be enough to get bcm43xx to work nicely without hacky scripts | 05:59 |
| infinity | BenC: when do you want to co-ordinate the ipw3945 junk? | 05:59 |
| BenC | infinity: I think I'll just do the lrm end of it too, I need to add fwcutter aswell | 06:00 |
| infinity | Ahh, cool, all you, then. | 06:00 |
| mjg59 | BenC: No joy with negotiating bcm43xx firmware? | 06:01 |
| infinity | fwcutter can go in LRM-common (which will need to become arch:any, I assume, unless it's a script), but the ipw3945 daemon appears to be versioned with the kernel module, so it should go in lrm-`uname -r` to keep lockstep (and the binary will need to be versioned on the filesystem) | 06:01 |
| infinity | BenC: If you'd prefer I do any of it, just poke me. LRM and I are close personal friends (or enemies) at this point. | 06:03 |
| mjg59 | The sooner we get the 3945 stuff in, the sooner we actually start getting bug reports about how broken it is | 06:07 |
| infinity | makx: What problem, exactly, did you have with moving the module lists to files? I just tried it and it went smashingly... | 06:08 |
| BenC | mjg59: none so far | 06:08 |
| infinity | mjg59: Is that assuming someone has the hardware in their grubby little hands already? | 06:09 |
| mjg59 | infinity: Oh, people /do/ | 06:09 |
| makx | infinity: creation time of initramfs | 06:09 |
| mjg59 | BenC: Yeah, that's because we're not shipping it... | 06:09 |
| makx | was 1/2 longer | 06:09 |
| infinity | makx: I get no slowdowns here... You must have been doing something scary weird... | 06:10 |
| BenC | mjg59: no I meant no luck with bcm43xx firmware | 06:10 |
| mjg59 | BenC: Oh, right | 06:10 |
| makx | infinity: ok cool | 06:10 |
| infinity | makx: Perhaps you've been too heavily influenced by jbailey's shell. ;) | 06:10 |
| mjg59 | BenC: Shame | 06:10 |
| mjg59 | Wonder if I can get it out of the Broadcom UK people (who are all embedded MIPS) | 06:11 |
| infinity | mjg59: ISTR suggesting that once before... | 06:11 |
| infinity | The MIPS folk are very friendly with Debian, at any rate. | 06:11 |
| mjg59 | I'll ask tbm about it | 06:16 |
| mjg59 | He's been in touch with them before | 06:16 |
| infinity | Yes, he has a machine or two from them. | 06:18 |
| infinity | I wouldn't mind one myself. | 06:18 |
| Keybuk | infinity: random thought ... | 06:35 |
| Keybuk | we could split the udev script even further | 06:35 |
| Keybuk | start udevd, and probe for existing buses in init-premount | 06:35 |
| Keybuk | then move the local code to local-premount | 06:35 |
| Keybuk | and the network code to nfs-premount | 06:35 |
| Keybuk | or something | 06:35 |
| infinity | Yeah, when looking at your switch on $BOOT, I was noting you could do that. | 06:36 |
| Keybuk | (actually, probably nfs-top and init-top) | 06:36 |
| infinity | Not that it would make much difference, it would just seem "cleaner" | 06:36 |
| infinity | OTOH, if it's working how it is now, why break it again? :) | 06:36 |
| Keybuk | cleanliness? :p | 06:37 |
| Keybuk | it'd fix the bug where if you change the boot options on the kernel command line, udev ignores it | 06:38 |
| infinity | Next to godliness, I hear. | 06:38 |
| Keybuk | (it gets $BOOT by reading conf/initramfs.conf) | 06:38 |
| infinity | Oh, really? Yeah, that's kinda icky, then. | 06:38 |
| infinity | By all means, muck with your stuff how you want. They're your hooks. ;) | 06:38 |
| === airlied [n=airlied@193.1.99.74] has joined #ubuntu-kernel | ||
| Keybuk | infinity: "while I was in there" ... | 07:07 |
| Keybuk | I moved the lvm and md scripts to lvm-common and mdadm | 07:07 |
| infinity | Gar. | 07:08 |
| Keybuk | Gar? | 07:08 |
| infinity | Our uploads collided. | 07:08 |
| Keybuk | lol | 07:08 |
| Keybuk | what did you upload? | 07:08 |
| infinity | And soyuz happily accepted both. AWESOME. | 07:08 |
| infinity | Go soyuz! | 07:08 |
| === infinity wonders which one will win. | ||
| Keybuk | yeah, it does that | 07:09 |
| infinity | Clearly it has a different concept of "ACCEPT" than katie does... | 07:09 |
| Keybuk | I think whichever one gets mailed second wins | 07:09 |
| infinity | That would be me, then. | 07:09 |
| infinity | I wasn't going to move the lvm and md stuff until Debian did, but I don't mind seeing it go either. :) | 07:10 |
| Keybuk | I long ago gave up "waiting for Debian" :p | 07:10 |
| Keybuk | actually, it was about the time I resigned from Debian | 07:10 |
| Keybuk | lol | 07:10 |
| infinity | I assume lvm-common and mdadm have appropriate Replaces: on them? | 07:10 |
| Keybuk | they do | 07:10 |
| infinity | (Of course, the Replaces will now be wrong..) | 07:10 |
| Keybuk | I found that if we do stuff for them, it gets into Debian quicker | 07:10 |
| Keybuk | lol | 07:10 |
| infinity | (Cause my version still has those scripts) | 07:10 |
| Keybuk | actually, one of them will be right | 07:10 |
| Keybuk | because I mucked up the Replaces | 07:11 |
| Keybuk | LOL | 07:11 |
| === infinity laughs. | ||
| infinity | Right, well you may as well bang up new uploads with fixed Replaces, and then we can yank the scripts AGAIN. | 07:11 |
| Keybuk | who wants to make a 28 with the right things? | 07:12 |
| Keybuk | do you want to, or shall I? | 07:12 |
| infinity | 27, even. | 07:12 |
| Keybuk | 27? | 07:12 |
| Keybuk | you want to upload a THIRD 27? :p | 07:12 |
| infinity | Unless you're skipping one out of deference to the one that got lost in the queue. :) | 07:12 |
| Keybuk | or did we both upload clashing 26s? | 07:12 |
| infinity | We did 26. :) | 07:12 |
| Keybuk | ahh | 07:12 |
| Keybuk | I did a 27 seconds later | 07:12 |
| Keybuk | well, minutes later | 07:12 |
| Keybuk | Accepted: | 07:13 |
| Keybuk | OK: initramfs-tools_0.40ubuntu27.dsc | 07:13 |
| Keybuk | -> Component: main Section: utils | 07:13 |
| Keybuk | OK: initramfs-tools_0.40ubuntu27.tar.gz | 07:13 |
| infinity | Oh, so I need a 28 with my changes? :) | 07:13 |
| infinity | Rock. | 07:13 |
| infinity | I'll do that when yours beats mine, then. :) | 07:13 |
| infinity | FUN GAME. | 07:13 |
| Keybuk | ok | 07:13 |
| Keybuk | http://people.ubuntu.com/~scott/packages | 07:13 |
| Keybuk | that has my 0.40ubuntu27 source | 07:14 |
| Keybuk | grab that, add your patch, then upload a 28 | 07:14 |
| Keybuk | and see if we can get four accepteds for the same daily run <g> | 07:14 |
| === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel | ||
| zul | gday.. | 07:25 |
| zul | BenC: new patch for you i sent in email.. | 07:25 |
| BenC | zul: ok | 07:26 |
| zul | im not dead yet...just resting ;) | 07:26 |
| zul | oops...it bounced | 07:28 |
| Keybuk | infinity: what is the NM patch to madwifi? does that make it support background scanning? | 07:29 |
| infinity | Sadly, no, just WPA extensions. | 07:29 |
| infinity | Background scanning would probably be an unwieldly backport, although the NM keeners are looking into it. | 07:30 |
| infinity | (I've not even tried to find the bits required) | 07:30 |
| infinity | Also, our ubuntu26 uploads got under the wire for the last cron.daily, so we didn't get 4 in one cycle.. *sad* | 07:30 |
| infinity | (That also means that my ubuntu26 is building right now... Or yours.. One of them) | 07:31 |
| infinity | In the end, looks like mine won. :) | 07:32 |
| crimsun | BenC: pong | 07:34 |
| BenC | crimsun: unping, current patches fixed hda problems that people were seeing | 07:34 |
| Keybuk | In Soviet Distro ... Soyuz accepts you! | 07:35 |
| crimsun | BenC: ok. Were these the sigmatel or realtek folks? | 07:35 |
| crimsun | ah, analog | 07:38 |
| BenC | zul: already got the patch in | 07:45 |
| zul | BenC: ok good to know | 07:45 |
| BenC | mjg59: Can you look at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/33704 | 08:36 |
| BenC | mjg59: User claims his amd64 system wont boot unless he removed the ATI IO-APIC block from you (timer pin fixup) | 08:37 |
| mjg59 | BenC: Yes, some newer BIOSes "fix" it in a way that breaks that | 08:37 |
| mjg59 | We should revert my fix and go to the one used in 2.6.16 | 08:37 |
| mjg59 | Hang on, I'll dig it out | 08:37 |
| BenC | ok | 08:37 |
| dilinger | hm | 09:16 |
| dilinger | BenC: so davem claims he's got silo booting from iso9660 on the sunfire 280 i sent him | 09:16 |
| BenC | dilinger: as far as I know silo 1.4.11 contains all the fixes needed | 09:17 |
| dilinger | BenC: cool, ok | 09:17 |
| dilinger | BenC: hm, is there a changelog anywhere or anything? i'm curious what the actual fix involved? | 09:18 |
| BenC | there's a subversion repo | 09:19 |
| BenC | svn.sparc-boot.org | 09:19 |
| dilinger | s-b.o/websvn is a 404 | 09:19 |
| dilinger | what's the full path for the repo? | 09:20 |
| BenC | that's not an http url | 09:21 |
| BenC | it's svn:// url | 09:21 |
| dilinger | yea, i tried that | 09:21 |
| dilinger | svn: PROPFIND of '/': 405 Method Not Allowed (http://svn.sparc-boot.org) | 09:21 |
| BenC | svn co svn://svn.sparc-boot.org/silo/trunk silo | 09:21 |
| dilinger | thanks | 09:21 |
| fabbione | dilinger: yes.. i got the iso to boot here too on the netra | 10:01 |
| mjg59 | BenC: More network drivers for you | 10:15 |
| mjg59 | (You love it really) | 10:16 |
| mjg59 | BenC: And there go the apic fixes | 10:37 |
| === j_ack [n=nico@p508D99D1.dip0.t-ipconnect.de] has joined #ubuntu-kernel | ||
| === _human_blip_ [n=mike@mike.nelsonbay.com] has joined #ubuntu-kernel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!