=== doko_ [n=doko@dslb-084-059-076-155.pools.arcor-ip.net] has joined #ubuntu-kernel [12:22] BenC: bcm430x people just announced working transmit/receive [12:40] BenC: With gawk, I get "Error in source file" [01:19] mjg59: you have to delete the bad file [01:19] then one that was attempted by mawk [01:26] BenC: Ah [01:26] BenC: Is there any way of enforcing this in the build? [01:27] would be better if we can fix up the awk script to work more compatibly [01:27] Yeah [01:28] I've managed to get the bcm43xx driver to associate, but not yet to bring up an interface [01:35] will we be able to put some bcm43xx firmware in l-r-m? [01:43] Nf. [01:43] That's awkward. [01:43] Currently, I'd say "no" [02:06] any ideas on the ability to distribute bcm4xxx firmware at all? :) [02:07] I know we have some bcm firmware already in our kernel tree [02:21] The bcm ethernet stuff is fine - they've given us permission [03:08] We can put firmware in LRM if we have the driver in the kernel. [03:08] (if we can distribute the firmmware, that is) [03:09] We do that for acx100 firmware. [03:09] The firmware is ripped out of the Windows driver right now [03:09] yeah, there's a tool to extract it [03:09] Same story with the acx100 firmware. [03:09] infinity: why do we do that for acx100 and no others? [03:09] The tool actually goes and downloads a bunch of random drivers and extracts the firmware. [03:10] we will need that same functionality for bcm43xx [03:10] The Broadcom one extracts stuff from the Windows or MacOS drivers [03:10] BenC : Perhaps because of the extreme sketchiness of how we obtain the firmware? :) [03:10] But we still need permission to distribute it [03:10] (And the fact that it's obviously not Free) [03:10] yeah, wonder if the bcm43xx folks have visited this issue yet [03:11] Some firmware is kindly licesnsed in a way that pretends ot be Free, and we look the other way, I think. [03:11] yeah, like the ones that are in "source code, binhex style" [03:12] "This binhex-to-C-array dump is GPL'd" :) [03:12] I'd be surprised if Broadcom would let us ship the firmware for a device that we've reverse engineered a driver for [03:12] it's not really reverse engineered, is it? [03:12] or is the spec reverse engineered? [03:12] The driver? Well, it's based on reverse engineered specs [03:12] The latter, i think. [03:12] So it's probably legal, but I can't see them being keen [03:13] broadcom isn't keen on too many things [03:13] I used to have access to their docbase [03:14] wonder if that login still works [05:56] ARGH. [05:56] BenC : Still around? [05:56] http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=1e737e269db99fbf01a5436910ae1aef99e9e075;hp=0631074954f75b6351a6c13769e03be5ce87139a;hb=b135c4815051bad6b2472e4ad0152f205918d2c5;f=include/linux/pci_ids.h [05:57] -#define PCI_DEVICE_ID_ATT_L56XMF 0x0440 [05:57] Apparently, I need that for ltmodem to build. [05:57] infinity: You could define it locally [05:58] infinity: Also, see http://www.livejournal.com/users/mjg59/55488.html [05:58] That's the sort of fucking shit I'm dealing with [05:59] mjg59 : Oh, I will define it locally, but it still seems a bit wrong that it got removed. [05:59] infinity: I'm really unconvinced by that title. There's stuff removed there that isn't duplicated by anything else in the file. [06:00] I wish I knew why people keep removing stuff from the kernel [06:00] You'd think they could write a useful patch instead [06:01] Yeah, I did a quick grep and came to the same conclusion as you. [06:01] It may as well have read "Remove PCI IDs for devices I don't like" or something. [06:02] It's probably "Remove PCI IDs that aren't referenced in the kernel" [06:02] Someone should bitch [06:02] Preferably not me, this time [06:03] I did it for the last bit of useful stuff that got ripped out [06:04] Meh. That seems braindead to me, but what do I know? [06:05] I like the ("Open Source" code) bit in your license. [06:05] Just in case we weren't sure. [06:06] I hate Linuxant [06:06] Deep, visceral hate [06:33] so what does vbetool 0.5 do for amd64 over i386? [06:33] er i meant over 0.4 [06:33] i brainoed ;) [06:34] It builds properly [06:34] something that would have made 0.4 not work right on amd64 or just build time issues? [06:34] Basically just build time issues [06:35] ah ok === calc needs to find time to reinstall his laptop with i386 ubuntu to test the acpi stuff === chmj [n=chmj@dsl-146-190-232.telkomadsl.co.za] has joined #ubuntu-kernel [07:40] mjg59 : Any drivers to shove at me for LRM yet?... I'm rolling a new release. [07:45] [07:45] [07:45] === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #ubuntu-kernel === ispiked [n=ispiked@Lee-12-238.rh.ncsu.edu] has joined #ubuntu-kernel [08:56] Can someone buy me an OS that makes sense for Christmas? kthx. [08:57] I rebooted, initramfs claimed that /dev/sda3 (my root device) didn't exist. Sure enough, it had been created as /dev/hda[*] instead. [08:57] Another reboot, and it's back to /dev/sda[*] , and I'm rocking myself to sleep in the foetal position in the corner. [09:02] infinity: is that machine SATA? [09:03] Yes. [09:03] it's a load module order problem [09:03] I blame udev. [09:03] sometime the ide driver (hda*) is loaded before the sata (sda*) [09:03] Note that I didn't touch anything between reboots. [09:05] yeah [09:05] it still can happen [09:06] 2 drivers handling the same device [09:06] BAD BAD BAD [09:06] Yeah. Just wonder why I've never seen it until today. [09:06] Moon phase, I guess. [09:07] possibly [09:55] infinity i had that frequently with udev = 0.74 [09:55] it was solved that time with a nasty timeout. [09:55] that was prior udev with /dev/.udev/udevqueue you can test against [10:04] Well, this is with the shiney new udev here. === makx still envies you for that shiney new udev your debian dir is so much cleaner :-P === makx needs push Md into alioth. [10:26] Our systems and packages may be cleaner, but they only boot every second try, so don't be TOO envious. :) [10:29] infinity you seem to use udevplug, which is not even in our udev package. [10:29] we need to use udevsynthesize. [10:59] BenC: please pull from my archive when you wake up (RedHat cluster kernel modules update) === CataEnry [n=Enrico@host149-23.pool8250.interbusiness.it] has joined #ubuntu-kernel [11:09] hi all [12:52] is stuff like fixing FTBFS becouse of missing headers worth pushing to kernel upstream ? [12:53] chmj: where do you get that? === JaneW [n=JaneW@dsl-165-120-130.telkomadsl.co.za] has joined #ubuntu-kernel [12:56] fabbione: linux-2.6/kernel/irq/handle.o [12:56] include/asm/acpi.h:67: error: boot_cpu_data undeclared (first use in this function) [12:56] from which tree? [12:57] and on what arch are you building? [12:57] i386 [12:57] from which tree? [12:57] upstream tree with some test patches [12:57] probably worth a shot, but check if the patch hasn't been submitted already [12:58] acpi is common enough to trigger an alarm when it doesn't build [12:58] fabbione: hmm, thanks === calc [n=ccheney@ip70-185-4-246.ma.dl.cox.net] has joined #ubuntu-kernel === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel === lx_ [n=lx@p548B269D.dip0.t-ipconnect.de] has joined #ubuntu-kernel [01:54] fabbione: ok [02:04] BenC: thanks dude.. test builded on amd64 and it's fine === siretart [i=siretart@ubuntu/member/siretart] has joined #ubuntu-kernel === lucasvo [n=lucasvo@www.wservices.ch] has joined #ubuntu-kernel === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has joined #ubuntu-kernel [02:13] jbailey, BenC: should we have the meeting now? [02:13] or do you prefer to wait? [02:13] both ways work for me [02:14] fabbione: I'm fine now. I jjust need to remember what it was about. [02:14] something about specs? === jbailey checks his IRC logs. [02:15] I need logrotate for these things. [02:18] ah, here we are. [02:18] KernelServerRoadmap [02:19] The idea being that the spec currently defines servers are pretty exclusively things that high end admins would need (clusters, fibber channel raid arrays, etc). [02:20] What came up was that Ben asked if he thougt anyone would notice if USB network cards weren't compiled for that kernel. === fabbione preemptively fires up metallica [02:20] My comment was that if setup up an office for SME/SoHo, it's very reasonable to do servers with wireless USB. === calc [n=ccheney@ip70-185-4-246.ma.dl.cox.net] has joined #ubuntu-kernel [02:21] jbailey: it really depends what you consider a "server" [02:21] So the discussion is really, (I think), how are we defining server [02:21] Right! =) [02:21] and at the end the result was: hw drivers all [02:21] So it needs to be clear, match what actual end user expectations are. [02:21] we finetune the server for other properties [02:21] like highmem and premptviness [02:21] Well, the definition is less important than what a person will install in their office. [02:21] and stuff along that line [02:21] well it is somehow [02:21] Is it correct for a person in a 5 person office to install the server edition on their fileserver? [02:22] If it's not, then I think it's misnamed. [02:22] we might want to support the kernel server only on certified hw [02:22] And should be "Enterprise computing edition" or something like that, with a note on the side saying what that means. [02:22] There's no serious chance of that for dapper. [02:22] Possibly after that, though. [02:22] i think that what ben and I decided at UBZ was full hw [02:22] but just tune for server/desktop [02:22] for example [02:23] redhat cluster suite doesn't like preempt [02:23] now.. [02:23] ok, here, we can do the meeting now if you like [02:23] you stick redhat cluster suite module on the server kernel [02:23] but not on the workstation one [02:23] given also that desktop prefers preempt generally [02:23] BenC: cool [02:24] it will save me to run this evening [02:25] i *think* the biggest mistake is that we keep trying to code in a spec the kernel [02:25] Eh? If we don't code it into a spec, how are we supposed to do it with enough community feedback? [02:25] jbailey: keeping an eye on bugzilla? ;) [02:27] jbailey: seriously i think that the kernel world is too unpreditable to be specced the same way we do for other stuff, imho [02:27] but does my answer satisfy your curiosity? [02:28] (in regards of the hw support) [02:28] It does, but it doesn't answer the real question yet for me - Is the server kernel going to be suitable for a 5 person office running a fileserver? [02:28] fabbione: one thing we weren't sure of, is this going to be server as in "any machine I decide to run as a server" or server a in "expensive NUMA/Summit type systems"? [02:28] I think it's a yes. [02:29] BenC: iirc we did agree to fine tune the server flavour to suck in as much server coolness as possible [02:29] but our normal 686 kernel can do that [02:30] jbailey: it should yes.. [02:31] and our desktop kernel, currently, isn't full preempt, so it should be suitable for SOHO server situations [02:31] BenC: i think we should rever that for desktop [02:31] so my opinion was that the "server kernel" would be geared toward the higher end stuff [02:31] and disable the RH stuff on it [02:32] BenC: the main problem is that it means shipping even more kernels on -server CD [02:32] and disable NFS server, and other things like that? [02:32] that's confusing for the user [02:32] BenC: no, the rh cluster and premept simply conflicts.. it was an example [02:33] also.. you can't make clustered workstation [02:33] just the line is getting fuzzy [02:33] it just doesn't work :) [02:33] I'm not really sure what the target of our server kernel is, which is making it hard to decide what should and should not be there [02:34] hmmmmm [02:34] i thought we did agree on full hw support [02:34] and just tune highmem and preempt [02:34] to start [02:34] but that's the minor issue [02:34] are we not going to do numa/summit/bigsmp right now? [02:35] do they need to be different flavour? [02:35] or can they exist in the same kernel? [02:35] there's a generic one that covers all three [02:35] but I don't know if it will run on a normal 686, or if you even want to [02:35] we can test the former [02:36] the generic one is what I have now [02:36] maybe I can do a server and a enterprise kernel? [02:36] or server-lowend and server-highend [02:36] server being our 686 tuned for server, and enterprise being the one that supports the big systems? [02:36] i would avoid enterprise word [02:37] ok [02:37] that would make sense yes [02:37] if we stick the word enterprise anywhere we will be classified as RH [02:37] will we need udeb's for those? [02:37] and we do not want that [02:37] only for the -686 [02:37] so we could: [02:37] install the -server CD with the 686-server tuned [02:38] who needs the big mofo can install it from CD [02:38] ok [02:38] how should we call them? [02:38] 686-server and highend-server? [02:39] we will need to keep a very detailed documentation on the differences [02:39] for sure people are going to ask [02:39] "highend" is one of those things people will install for "highend features", invariably installing the wrong thing. [02:39] Is there any short word one can think of that unambiguously means "really big hardware you don't own, dumbass" [02:39] and note that we will need the same counterparts for the other arches [02:40] 686-forbigfathwyoucanteffordunderyourstinckydesk [02:41] (Also, where is the cutoff between server and fatserver?.. With commodoty hardware as it is these days, I assume server will still support a fair number of CPUs (4, 8?) and a mess of RAM (16G, 32G?) out of the box. [02:41] Just not crazy configs like 512 CPUs and NUMA... Right? [02:41] infinity: i think that's more or less what i had in mine and didn't say [02:42] yeah, that's basically it [02:43] 8-way, 32Gig is the limit for our normal server [02:43] Hmm. Dyntick seems to be a bit over-enthusiastic [02:43] As in, I'm only getting ticks if I actually do something that generates interrupts [02:43] BenC : Oh, hate to take your mind off the pressing business of naming your next baby... [02:44] we could call it 686-bigmofo [02:44] And it doesn't actually seem to be saving me any power, either [02:44] BenC : What should we do with "linux-tree" and "linux-patch-ubuntu" from linux-meta? [02:44] i wonder if they will get it? [02:44] infinity: kill them [02:44] linux-patch doesn't exist anymore [02:44] BenC : Are you intending to keep the kernel debian-native from here on in, and we should just drop those? [02:44] and neither -tree- afair [02:45] infinity: I had them deleted, we just need linux-source now [02:45] Well, -tree = source+patch-ubuntu, so if there's no patch, there's no tree. Right. [02:45] Kay. [02:46] brb, rebooting to -7.9 === siretart [i=siretart@ubuntu/member/siretart] has joined #ubuntu-kernel === lucasvo [n=lucasvo@www.wservices.ch] has joined #ubuntu-kernel === Mithrandir [n=tfheen@c5100BC63.inet.catch.no] has joined #ubuntu-kernel === lucasvo [n=lucasvo@www.wservices.ch] has joined #ubuntu-kernel === mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-kernel === jb-home [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has left #ubuntu-kernel ["Leaving"] === cliebow_ [n=cliebow@70-33-153-196.agstme.adelphia.net] has joined #ubuntu-kernel [03:08] could someone elaborate on tagging a vmlinux kernel with initramfs?suggestions were adding initrams.gz to the data section? [03:10] reading the scrollback, what about servers that need high interactivity eg edubuntu or other ltsp servers ? === siretart_ [i=siretart@tauware.de] has joined #ubuntu-kernel [03:10] do they have to have a "desktop" kernel ? === Mithrand1r [n=tfheen@c5100BC63.inet.catch.no] has joined #ubuntu-kernel [03:12] Yagisan: ltsp servers are workstations [03:12] so they get the desktop kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [03:15] yay, my cdrom is working! [03:16] jbailey: I have an interesting tidbit for you, my G4 stopped locking up from the screen-saver after I switched LCD panels [03:17] BenC: It's an Apple Cinema Display. No chance of me swapping it out. =) [03:17] hehe [03:17] BenC: Did you have a chance to ask jgarzik about the ata_piix pata support? [03:18] mjg59: he never came back around [03:18] Ah, ok [03:18] fabbione: Ok, but that would still have the driver support of say "server" versions ? [03:18] Yagisan: please read all the scroll back [03:18] Yagisan: the hw support will be the same in terms of drivers [03:18] and no ltsp does NOT need a server kernel [03:19] fabbione: so on i386 (the only server kernel atm) I will disable all the cluster stuff except in the server kernels, correct? [03:19] should I disable gfs aswell? [03:20] BenC: yes correct. [03:20] gfs/clustering can go away from the desktop [03:20] and you could reenable pre-empt [03:20] but that's up to you [03:22] gfs depends on CMAN iirc [03:22] ok [03:22] do it should autodisable [03:22] fabbione: ok. I just thought I read that nfs was proposed to be disabled in desktop kernels, and that's needed for ltsp/edubuntu [03:22] s/^d/s [03:22] Yagisan: read carefully ;) [03:23] BenC: when do you plan to upload 7.9 ? [03:23] fabbione: I know, I need more coffee (and sleep - my babies won't let me do that). [03:24] hopefully today [03:24] BenC: perfect [03:24] maybe tomorrow since I want to get the server kernel building aswell [03:24] i am waiting for the new rh modules to test the new userland [03:24] too lazy to build it myself on 3 arches [03:25] did you remember to enable the ABI script? === CataEnry [n=cataenry@host149-23.pool8250.interbusiness.it] has joined #ubuntu-kernel [03:26] hi all [03:40] yeah, abi is working again [03:40] cool === calc [n=ccheney@ip70-185-4-246.ma.dl.cox.net] has joined #ubuntu-kernel === paddy- [n=paddy@p549CDD4C.dip.t-dialin.net] has joined #ubuntu-kernel === lamont__ [n=lamont@mib.fc.hp.com] has joined #ubuntu-kernel [04:20] BenC: Hm. The ata_piix driver doesn't provide PCI IDs for a lot of the devices that piix.c will drive [04:20] I'm playing with it a bit now === CataEnry [n=cataenry@host149-23.pool8250.interbusiness.it] has joined #ubuntu-kernel === lx_ [n=lx@p548B269D.dip0.t-ipconnect.de] has left #ubuntu-kernel ["Leaving"] === Yagisan [n=jamie@60-240-201-251.tpgi.com.au] has left #ubuntu-kernel [] [05:16] BenC: either I deleted it, or something else caused your patch email to not reach me... could you send it to lamont.jones@hp.com? [05:16] (elilo/gnuefi) [05:17] I didn't send it [05:17] it's not booting [05:17] the fix is simple enough, just use the linker scripts from gnu-efi 3.0b [05:17] it's like a two line change [05:18] I even tried building with gcc-3.4, and it still doesn't work (as soon as it tries to run elilo, it drops back to the EFI menu, almost instantly) === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel [05:23] BenC: Amusingly enough, I switched back to sparc/2.6.12-9 and started a gdb build earlier. I just checked and it has not crashed yet. [05:23] yeah, that is odd [05:24] I've been doing some fairly frequent builds of the kernel on my e3k (-j20) [05:24] maybe I should try a gdb build :) [05:28] BenC: It's in the testsuite that it's dying. [05:28] So the two thoughts I have are memory pressure, or some syscall exercising. [05:28] I have 6 gigs, so memory pressure is difficult for me [05:28] I need to get my U2 out for testing some of this [05:28] I understand. I have the same problem with my ppc64 box. =) [05:29] poor us :) [05:29] Isn't our life hard? =) [05:52] BenC: so we just need a newer gnu-efi, and then figure out why it doesn't boot, eh? [05:53] and pulling ram is painful, too. [05:54] BenC: does it play a pretty tune first, or just exit? === lamont__ bets exit [05:54] tune? [05:55] I hadn't noticed any tunes coming from my i2k :) [05:55] I see "Loading Ubuntu", then "Starting Ubuntu", and then back to EFI, the "Starting Ubuntu" goes so fast I somtimes don't even see it [05:56] so it's like exiting pretty damn early [05:56] lamont: is there any debugging I can put in elilo? [05:57] I'm almost thinking it is exiting in crt0 or something [06:01] ah, it has verbose and debug options [06:01] I'll try enabling that [07:11] BenC: I get a BUG on 2.6.15-5 triggered by the pcmciautils init script [07:11] is pcmciautils not doing the same checks that pcmcia-cs did, to avoid loading the drivers on systems which don't have pcmcia? [07:11] fixed in -6 [07:11] (this is on my desktop) [07:11] ok, am doing that upgrade now [07:11] you got a softlock, correct? [07:11] correct [07:11] init_i82365 ... _spin_lock_irqsave [07:12] yeah, fixed [07:12] thanks [07:12] patch from breezy causing that [07:12] just removed it [07:15] BenC: any guesses as to my via/irqpoll problem? (#5234) [07:15] that's the real issue with 2.6.15 on my desktop currently [07:15] same problem from breezy, right? [07:15] I left out your patch to see if you'd complain, so I guess I'll still need it :) [07:16] I'll put it in -7.9 [07:16] not exactly; irqpoll no longer works around it now [07:16] maybe irqpoll is broken [07:17] x86 or amd64? [07:18] x86 === CataEnry [n=Enrico@host149-23.pool8250.interbusiness.it] has joined #ubuntu-kernel [07:19] I was going to upload -7.9 today, but it got put off because a driver is failing to build [07:19] since I have to put it off anyway, I can get your via patch in and check irqpoll [07:20] when is flight 2 supposed to be done? [07:20] hi [07:44] BenC: I asked Colin for a not-sooner-than this morning and he said Thursday. [07:44] cool, so tomorrow shoudl be ok for a -7.9 upload [07:44] thanks [07:48] BenC: flight 2 is tentatively later this week [07:48] thurs or fri [08:19] mjg59: are you aware of any problem with the ipw2x00 driver in the latest breezy kernel? [08:19] (or if you heard something about it) [08:26] What sort of problem? [08:27] basically it happens only to cvd [08:27] when there are 3 or 4 APs around [08:27] the card becomes unstable to death [08:27] do you happen to have one of them around to test in a similar situation? [08:28] the problem happens with breezy kernels [08:30] I've seen vaguely similar stuff [08:30] workarounds? [08:30] Nope [08:31] ok thanks :/ [08:35] breezy's kernel keeps crashing on my opteron machine :/ [08:37] Fucking ay === trevilor [n=trevilor@p549CDD4C.dip.t-dialin.net] has joined #ubuntu-kernel [08:37] dilinger: Your opteron and my sparc can go cuddle. [08:38] dilinger: your opteron is crap.. :) [08:38] fabbione: my opteron rocks :p === mjg59 is now happily IRCing from the AMD64 laptop with a Broadcom chipset [08:38] fabbione: i'm not even using SMP, since that crashes on bootup [08:39] hi guys [08:40] it may very well be the 3ware driver [08:40] since it's been doing a lot of i/o when it hangs [08:40] dilinger: what about trying to see if it is something else? [08:40] fabbione: well, the machine's in boston right now, and i'm not [08:40] so trying stuff is kind of hard [08:40] dilinger: sucks to be you [08:41] :P [08:41] not really. it's a 2TB machine :) [08:41] once it's stable, i will be very very happy [08:42] mjg59: just did a sync for bcm43xx and softmac for -7.9, so let me know if it works stock [08:42] the sunfire should be going out to davem today [08:42] assuming that the UPS pickup happens correctly [08:42] dilinger: cool [08:43] BenC: I needed to add a PCI ID [08:43] BenC: dunno if you are reading #u-d but we might not need udeb for -server at all [08:43] But other than that, it seems good [08:43] softmac as in the Airport Extreme support? [08:43] fabbione: ok, I have them enabled, so it's easy to turn off (or ignore them) [08:43] Softmac provides 802.11 management stuff in software [08:43] mjg59: email me the id's [08:43] Which the Broadcom driver needs [08:43] ok [08:44] BenC: ok, if they don't build, just disable them [08:44] bcm43xx as in airport extreme though [08:44] BenC: i totally forgot to ask to Kamion before saying yes [08:44] BenC: 4318 with VENDOR_HP, ID_ANY in the subvendor/device fields [08:44] mjg59: ok, they'll be there [08:45] Rock [08:53] jbailey: what kind of sparc, btw? [08:53] dilinger: U5 [08:54] ah [10:12] BenC: kernel-wedge and kernel-package merges seem to still be pending; if there's something blocking them, please note in the status whiteboard, otherwise please get them merged soonest [11:49] Is it expected that there's no linux-headers-2.6.15-# package yet?