=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-kernel
=== dilinger [i=dilinger@mouth.voxel.net]  has joined #ubuntu-kernel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-kernel
=== nigel_1 [n=nigel@nigel.suspend2.net]  has joined #ubuntu-kernel
=== nigel_1 is now known as nigel_c
=== johanbr [n=j@jupiter.physics.ubc.ca]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
[03:48] <zul> BenC: hey how is it going
[03:57] <BenC> not bad
[04:03] <mjg59> BenC: Hi - did you see my question about SMP on the -386 kernel?
[04:07] <infinity> mjg59: I beleive the problem is that we build some sketchy legacy ISA drivers into the 386 kernel (and only the 386 kernel) which refuse to compile and/or work on SMP-enabled kernels.
[04:07] <infinity> mjg59: This was proven true for the ltmodem driver in LRM as well, which is why it's only built for -386.
[04:07] <mjg59> Oh lordy.
[04:08] <infinity> (It compiles against SPM headers fine, but won't run on SMP kernels, even on a UP machine with smpalternatives)
[04:08] <mjg59> It's almost like it was some random binary obtained from Lucent via dubious means
[04:08] <infinity> Almost, yes.  But there are drivers in the upstream kernel with similar issues, or so I've been told.
[04:09] <infinity> If that's no longer the case, and ltmodem is the only holdout, I'm happy to just drop it completely again.
[04:09] <mjg59> Ok. The result seems to be that we're moving to the -686 kernel on the desktop CDs
[04:09] <infinity> Yes, we moved to -686 when edgy opened.
[04:09] <mjg59> Which loses us a small amount of hardware support
[04:09] <infinity> Which makes sense, since you don't want to run the desktop CD or ubiquity on slow machines anyway.
[04:09] <mjg59> I did some playing today
[04:10] <infinity> But keeping -386 as the d-i kernel for the alternate CD still makes sense.
[04:10] <mjg59> We could easily run ubiquty on a 128MB machine
[04:10] <mjg59> Well, assuming parted isn't /too/ pathological
[04:14] <mjg59> Based on the hwdb data, about 0.5% of users are on 586 machines with 128MB or over
[04:16] <infinity> Of course, users already in hwdb are less likely to (re)install from scratch with the desktop CD than, say, someone with a new computer, or an enthusiast with fast hardware who nervously reinstalls every month.
[04:17] <mjg59> Yeah
[04:17] <infinity> So, statstics of past hardware installed on aren't as useful as one might like.
[04:18] <mjg59> In a way it'd be nice to be able to provide an SMP kernel that still ran on 586 machines and default to that
[04:18] <infinity> I'd love to get the desktop CD requirements down, but I also want to see it support SMP and such, so we have to draw a line somewhere.
[04:18] <mjg59> But mdz's argument is that there's barely anyone that hits and they could use the alternate CD instead
[04:18] <mjg59> Which is pretty understandable
[04:18] <infinity> Ben had discussed a unified -x86 kernel that would rewrite ops on the fly for the detected CPU.
[04:18] <infinity> Not sure where we went with that.
[04:18] <mjg59> That would be very cool
[04:20] <infinity> We'd probably still need SMP and UP, because of the sketchy drivers previously-mentioned (unless they are, or will be, fixed), but we could scrap the distinction between -386,686,k7
[04:21] <mjg59> Running the desktop CD without Gnome drops memory usage by about 50MB. Running an Intel graphics system without 3D and in 16 bit drops memory usage by about another 50MB
[04:21] <infinity> Okay, that last data point is somewhat surprising.
[04:22] <infinity> I didn't realise X was that inefficient at higher colour depths.
[04:22] <ajmitch> it's probably more the lack of 3D
[04:22] <mjg59> It's allocating system memory for video RAM
[04:23] <mjg59> When you enable 3D, it needs texture memory plus approximately four times the amount used for the framebuffer
[04:23] <infinity> Oh, feh.  Right.  I don't have any systems without gobs of video RAM.
[04:23] <infinity> I'm spoiled.
[04:23] <ajmitch> some of us still have the cheap onboard graphics
[04:23] <mjg59> The Intel stuff isn't especially cheap
[04:23] <mjg59> But still
[04:24] <mjg59> On some hardware, we can drop memory requirements for the install by 100MB
[04:24] <mjg59> I think that's probably worth doing and providing as an option
[04:24] <infinity> Yeah, a lowmem boot option might be nice.  Not quite as "lowmem" as d-i's similarly-named option, mind you.
[04:25] <ajmitch> just a light wm?
[04:25] <infinity> Don't really need a WM at all, if you're booting straight to X+ubiquity, though it's probably nice to be able to pop up an xterm to see why the world exploded, if it does.
[04:25] <mjg59> No WM at all?
[04:26] <mjg59> Ah, yes
[04:26] <mjg59> I guess so
[04:26] <infinity> Though there's a certain appeal to using ubiquity as a kiosk-type application.
[04:27] <infinity> Which would avoid calling it a "lowmem" option and confusing people, and instead just be a "Boot directly to Installer" option.
[04:27] <infinity> Which, for the clever, would intuitively imply "no extra crap running, so probably less hard on my hardware", and would also indicate "this is what you want if you're doing a bunch of installs in a row and don't need the desktop".
[04:28] <mjg59> And then have ubiquity check free memory and suggest it as an idea if resources are low
[04:29] <mjg59> It would need an option to the X config to allow it to skip writing the 3D section
[04:29] <mjg59> But that's about it
[04:29] <mjg59> Pretty straightforward
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== johanbr [n=j@d154-20-189-105.bchsia.telus.net]  has joined #ubuntu-kernel
=== johanbr [n=j@d154-20-189-105.bchsia.telus.net]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== doko [n=doko@dslb-088-073-074-120.pools.arcor-ip.net]  has joined #ubuntu-kernel
[12:42] <TheMuso> c
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== kernel_panic [n=ramattac@44.Red-80-35-101.staticIP.rima-tde.net]  has joined #ubuntu-kernel
[03:35] <kernel_panic> hi everybody
[03:35] <kernel_panic> anybody there?
=== mjg59 [n=mjg59@cavan.codon.org.uk]  has joined #ubuntu-kernel
[03:57] <kernel_panic> I've got a problem with debian sarge and kernel 2.6.17.8
[03:57] <thom> kernel_panic: unfortunately for you this is #ubuntu-kernel, and not #debian, which would be a more suitable place for help with debian sarge
=== jwest- [n=jwest@83.110.124.125]  has joined #ubuntu-kernel
=== fs [i=fs@213.178.77.98]  has joined #ubuntu-kernel
=== kbyrd [n=Miranda@mailout1.vmware.com]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
[07:27] <BenC> "but it works with Xen's 2.6.16 kernel"
[07:27] <BenC> zul: I hate you
[07:29] <jwest-> if there are bad blocks
[07:29] <jwest-> nothing can be done about it other than having to reinstall?
[07:30] <jwest-> del/create partition doesnt seem to help
[07:45] <BenC> there's something that can be done, but I'm not sure what it is
[07:45] <thom> gar, this mptscsi is turning into a monster
[07:46] <BenC> jwest-: try the badblocks program
[07:53] <mdz> mjg59: "express installation"
=== jwest-- [n=jwest@83.110.124.125]  has joined #ubuntu-kernel
=== jwest-- is now known as jwest-
[08:00] <Keybuk> BenC: damn, I wish people wouldn't hijack other people's bug reports
[08:00] <Keybuk> that "3 minute hang" one of yours has at least four people with four different problems
[08:00] <Keybuk> we should just have a single "something went wrong" bug that everyone can gripe in ... it'd make our BTS look so much cleaner
[08:01] <mjg59> mdz: Nice name
[08:08] <BenC> hehe
[08:08] <BenC> Keybuk: Yeah, I have like 4 bugs for this "3 minute hang" problem
[08:09] <BenC> Keybuk: Problem I closed 2 of them because the reporters claimed it was fixed with the last dapper upload
[08:09] <Keybuk> a 3 minute hang is just udev's way of saying "uhhhhhhhh"
[08:09] <mdz> BenC: er, is there no bug contact set for linux-source-2.6.17?
[08:09] <Keybuk> it does alarm(180) in the child before embarking on any rule processing
[08:09] <Keybuk> so the fact it hangs for 3 minutes just means the child got deadlocked
[08:09] <Keybuk> it can be caused by just about anything
[08:10] <Keybuk> iftabbing two network cards to the same name
[08:10] <Keybuk> hdparm locking up
[08:10] <Keybuk> modprobe hanging
[08:10] <Keybuk> block device errors (if cdrom_id gets run for a duff cd)
[08:11] <Keybuk> if you get them, ask for /var/log/udev and toss it over to udev
[08:11] <Keybuk> I can always debug it
[08:19] <BenC> mdz: Should be
[08:20] <BenC> Keybuk: ok
[08:24] <mdz> BenC: I filed bug #55695 and it didn't get copied anywhere except ubuntu-bugs
[08:24] <mdz> BenC: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/ says "No people or teams are subscribed to bugmail for this package."
[08:24] <mdz> BenC: each time we move to a different source package name for the kernel, you need to carry that over
[08:25] <mdz> via the "bugmail settings" link on the +source page
=== alex_joni [n=juve@dsplabs.cs.upt.ro]  has joined #ubuntu-kernel
[08:25] <alex_joni> hello.. anyone around familiar with customizing a LiveCD for Dapper (mainly replacing the kernel)
[08:26] <mdz> BenC: no wonder you caught up with bug mail; you've probably been missing all of the new bugs ;-)
[08:49] <BenC> hehe
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
[08:51] <alex_joni> BenC: happen to know who's doing the install/live CD for dapper or edgy?
[08:51] <BenC> not spefically, but #ubuntu-devel might be a good place to start
[09:03] <mdz> alex_joni: there are how-tos on the web 
[09:06] <alex_joni> mdz: found some info in the wiki, but nothing about kernel changing
[09:06] <alex_joni> mdz: I did manage to change the one for Breezy, but for Dapper it's quite different
[09:07] <mdz> alex_joni: with the kernel, it's the same as with any other package, except that you copy the kernel and initrd out of the squashfs into the ISO filesystem
[09:07] <mdz> alex_joni: we would greatly appreciate it if you would update the wiki documentation :-)
[09:08] <alex_joni> mdz: for breezy I had to tinker with udebs.. this all gone now?
[09:09] <alex_joni> mdz: here's the info I wrote about breezy http://dsplabs.utt.ro/~juve/blog/index.cgi/01147559232
[09:13] <mdz> alex_joni: correct, no more messing with udebs
[09:13] <mdz> there's no more debian-installer on the CD, just an initrd which is generated by casper
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
[09:15] <mdz> or rather, by the usual initramfs-tools process with casper's participation
[09:19] <alex_joni> mdz: thank you
[09:28] <BenC> infinity: ping
[10:31] <BenC> mdz: isn't 54035 a dupe of 55695 (or vice a versa)?
[10:38] <mdz> bug 54035, bug 55695
[10:38] <mdz> no ubugtu in this channel?
[10:39] <BenC> guess he left us again
[10:39] <BenC> mdz: they both appear to be bug in idecs
[10:40] <mdz> BenC: yes, you're right; I forgot I'd filed it already
[10:40] <mdz> marked 54035 as a dupe since 55695 has a bit more info
[10:40] <mdz> I still had it on my todo list to file for some reason
=== jwest- is now known as jwest--
=== BenC forewarns everyone of a pending edgy kernel upload tonight
[11:14] <crimsun> great, thanks :)
[11:23] <crimsun> BenC: would it be possible to apply the following Kconfig aoa patch for -4-, too?  http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=f72c2a462f761c14c6f8db314afbf1abb4b0a189;style=raw
[11:24] <crimsun> (no git id to cherry-pick else I'd have recommended it)
[11:31] <BenC> crimsun: my sound/aoa/codecs/Kconfig doesn't even have the "select I2C_POWERMAC" line
[11:31] <BenC> err, the "select I2C" line
[11:32] <crimsun> it shouldn't have either I2C or I2C_POWERMAC prior to the commit
=== crimsun checks ubuntu-2.6
[11:36] <crimsun> unless I'm missing something utterly obvious, those are the two lines that need to be added, and that matches both current ubuntu-2.6 and alsa-current git
[11:37] <crimsun> (well, four lines)
=== derekS [n=dereks@unaffiliated/dereks]  has joined #ubuntu-kernel
[11:50] <derekS> what gcc is 2.6.17-5-k7 compiled with?
[11:50] <crimsun> cat /proc/version
[11:50] <derekS> crimsun: ahh :)
[11:51] <derekS> so i guess thats not the problem with my vmware
[11:51] <derekS> thanks
=== derekS [n=dereks@unaffiliated/dereks]  has left #ubuntu-kernel []