[01:36] that's funny [01:37] that "frenzy" happened about 30 minutes from where I live [01:37] crazy rednecks [01:47] haha === calc [n=ccheney@ip70-185-4-246.ma.dl.cox.net] has joined #ubuntu-kernel [06:22] morning [06:22] :D [06:22] welcome back, dude [06:22] desrt: I HATE YOU ALL! I WANT TO GO BACK IN HOLIDAYS! [06:22] woh [06:22] ;) [06:22] sounds like you could really use another week or two :P [06:23] easily... [06:23] anyway.. i was hacking yaboot on the weekend [06:23] as it is, breezy won't boot on an xserve unless it has a videocard [06:23] hmmm [06:23] i have a fix [06:24] but...... [06:24] but? [06:24] it disables the stage 1 yaboot menu [06:24] ie: it just loads stage 2 directly [06:24] (stage1 is the part that has a problem) [06:24] i don't think that's a solution [06:24] well, it is for me :) [06:24] yeah for you... [06:24] it's only a problem if you have multiple OSes installed (macos dualboot) [06:24] i'm working on generalising the code [06:25] but work has been a bit hectic the past week [06:25] + i don't know forth :) [07:08] BenC: still awake? [07:26] Gar, is there something mind-numblingly obvious I'm missing, or is the kernel bridging interface really such utter shit? [07:26] When I unplug a cable from one of the bridged interfaces, the whole bridge goes down. YAY. [07:26] (Or power cycle the system it's plugged into, or whatever) [07:27] eth brinding? [07:27] that shouldn't happen [07:27] ethernet, yes. When one interface loses linkbeat, the bridge dies. [07:27] are you sure you have no userland tools checking via mii that the iface is connected to a cable? [07:28] (Doesn't actually down the interface, just stops relaying packets, even after the linkbeat comes back) [07:28] Oh, it's possible. THe bridge is on a breezy desktop, so there might be some irritating magic going on. [07:28] becasue i use brindging on 2.4 on a dead iface to talk to xen domains [07:28] Though I can't think of what (no, network-manager isn't installed) [07:28] infinity: try to do it in single user mode to see if it is userland? [07:33] this is completely and totally awesome [07:35] desrt: what? [07:35] excuse the paste [07:35] 0 > boot hd:2,\\yaboot load-size=24830 adler32=ad6b4eba [07:35] Loading ELF [07:35] Config file read, 678 bytes [07:35] Welcome to yaboot version 1.3.13 [07:35] Enter "help" to get some basic usage information [07:35] boot: [07:35] Linux old [07:35] boot: Linux [07:35] Please wait, loading kernel... [07:35] Elf32 kernel loaded... [07:35] Loading ramdisk... [07:35] i can interact with openfirmware (and yaboot) using a whole bunch of methods [07:36] including -telnet- [07:36] yeah i knew that OF has telnetd [07:36] that's awesome! [07:36] like, crikey! === infinity wishes he had a new enough Mac to have an OF that didn't suck. [07:36] infinity: ask svenl for upgrades :) [07:37] You think he'll swing me a dual G5 to replace my G3? :) [07:37] i meant software.. [07:37] and join the queue for g5's ;) [07:38] Software's a no-go. You can't update the firmware on the Beige G3 past version 2.4 (which I have) [07:38] OF didn't start sucking less until 3.0 (NewWorld), though. [07:39] i need to hook me up with a nice toy [07:39] probably i will soon get money for a new machine [07:39] and i don't want it to be i386 [07:39] either ppc or amd64 [07:39] not sure yet [07:39] I like my amd64. [07:39] And my ppc, for that matter. [07:39] or replace my server with a couple of sparcs [07:40] OR [07:41] make my workstation a new server [07:41] and buy a new workstation [07:44] amd64 is teh love. [07:44] yeah i know.. [07:46] and hi and good morning and stuff [07:58] hmmm [07:58] what's a good brand of ATA harddisks by now? [07:59] i have the following options: Maxtor, Seagate, WD [07:59] seagate seems good and iirc has 5 year warranty [08:00] i want my next system to be an amd64 mac mini [08:00] calc: i am looking for 4x300GB harddisk to replace my server [08:00] instead of the 8x120GB that i have now [08:01] maxtor/wd have shorter warranties iirc so seagate is likely the most reliable as well [08:01] Maxtor has 16MB of cache compared to the 8Mb of the others.. [08:01] and the seagate 7200.8 series goes up to 500gb [08:01] WD has 320GB instead of 300 of the others... [08:02] calc: i am looking at what's available around :) [08:02] at least on local hw shops [08:02] oh [08:02] seagate 400gb seems to be generally available so they may have that also [08:03] OH right [08:03] they are 2 lines below [08:03] they are double as expensive as the 300GB [08:03] i see 7200.8 400gb for sale via pricewatch already not sure if regular stores will have that yet [08:04] heh [08:04] yea i see 300gb seagate for $152 and 400gb for $230 on pricewatch which is still a bit expensive [08:05] oh yea the seagate sata drives do ncq as well, not sure about maxtor/wd [08:05] IMPRESSIVE [08:05] they are selling Apple.. they didn't use to === calc bbl, bed [08:08] Mithrandir: what's a good SATA controller? [08:12] given the minimum differnce in price for the hd, it might be worth making the array SATA === JaneW [n=JaneW@wbs-146-185-138.telkomadsl.co.za] has joined #ubuntu-kernel === jane_ [n=JaneW@wbs-146-185-138.telkomadsl.co.za] has joined #ubuntu-kernel [09:30] fabbione: I've actually good experiences with the sii3114 [09:43] fabbione: do you have a kernel for me? [09:46] Mithrandir: Herbert is working on it [09:46] ok, cheers === chmj [n=chmj@196.36.161.235] has joined #ubuntu-kernel [10:00] jbailey: i managed to fix klibc on sparc64.. [10:23] Mithrandir: is the sii from 3ware? [10:23] no, silicon image [10:23] ok [10:24] of course my hw pusher doesn't have it [10:24] it's often onboard. [10:24] ah ok.. [10:24] and it's the chip name [10:24] http://www.hwb.no/artikkel/15307 [10:24] has a test of different controllers. [10:24] i am looking for a PCI card [10:26] the 3ware they have is the same as in that pic :) [10:28] well, read the article. It's fairly decent. [10:28] Kjernen benyttet under testingen var 2.6.8.1-5-amd64-k8-smp. Det ble brukt x86_64-versjonen av Warty. [10:28] you can read norwegian well enough, can't you? [10:28] yeah i think so :) [10:31] well it's a lot of benchmarks [10:31] but tbh i am not too interested into speed... [10:31] more about: "It works in Linux,, it doesn't work" [10:32] all of the controllers there work in Linux, obviously. :-P [10:32] yeah clearly :) [10:34] looking at the graphs, it makes me wish to buy SCSI :) [10:35] there's a SCSI controller in there as well [10:35] yeah.. that's why :) [10:49] fabbione: the 3ware's are fine controllers, but spend the extra money for the 9500 [10:56] doko: yeah.. it also costs a fortune :) [11:00] Adaptec's 2410 isn't so bad. (or 2810 if you need 8 ports) [11:01] I'd push the 3ware stuff if money was no object, but they are very pricey. [11:05] yeah [11:05] but given that it's one time expense.. i guess i can look into 3ware too === chmj [n=chmj@196.36.161.235] has joined #ubuntu-kernel [01:57] fabbione: I have ACPI fixup patches for you. Shall I just email a tarball with justification? [02:00] mjg59: that would do [02:02] fabbione: Ok, cool [02:04] mjg59: from now on, please start to CC BenC [02:05] he will take over the kernel soon.. [02:06] fabbione: Will do [02:06] fabbione: benc@canonical.com? [02:07] mjg59: meh.. hold on.. [02:07] ben.collins@ubuntu.com [02:07] Ok === Seveas [n=seveas@seveas.demon.nl] has joined #ubuntu-kernel [02:39] fabbione: Mailed [02:40] mjg59: ok [02:40] you gotta be kidding... [02:40] 300KB of tar.gz????? [02:41] fabbione: Most of that's a replacement for the existing acpi update patch [02:42] ok [02:43] mjg59: want to take a look at bugzilla and start marking bugs as pending upload? [02:43] fabbione: Sure, will do [02:45] jbailey: ping? [02:45] fabbione: pong [02:45] jbailey: did you like the klibc upload? [02:46] I saw that it had been done, but it's just coming down now. =) [02:46] nothing too fancy.. [02:46] change the B-D for new kernel headers [02:46] added a specific sparc64 patch to fix FTBFS [02:47] that doesn't touch any of the other code [02:47] so pretty safe [02:54] fabbione: The patch in 11813 ought to be applied === fabbione checks [02:56] OH DAMN SHIT [02:57] there is no connectivity with uk toady [02:57] like yesterday [02:57] ok.. it's taking ages... [02:57] mjg59: i need to take my wife to the doc and i will be back in about 2 hours or so [02:57] probably more... [02:57] just create a list and mail it.. [02:58] or whatever you prefer.. [02:58] just don't leave the list here on IRC :) [02:59] fabbione: No problem [02:59] thanks [03:21] fabbione: Looks good, thanks. === doko__ [n=doko___@dsl-084-059-082-215.arcor-ip.net] has joined #ubuntu-kernel [03:42] i think nobody noticed before, because klibc was probably built on sparc32 or so [03:42] that's what come up to mind now.. [03:42] but we don't care to build in 32 bit [03:43] given that: A) we don't support 32bit b) it's all used once at boot and trashed away === doko__ [n=doko___@dsl-084-059-082-215.arcor-ip.net] has joined #ubuntu-kernel [03:43] anyway.. time to go [03:43] bbl === chmj [n=chmj@196.36.161.235] has joined #ubuntu-kernel [06:01] re [06:02] BenC: ping? [06:05] mjg59: i got the patches.. [06:05] fabbione: Rock [06:08] mjg59: are all the patches done to be applied at the end of 00list? [06:08] with the order you gave.. or somewhere else? [06:08] fabbione: Which ones? The first batch or the second batch? [06:09] both... [06:09] The second batch should all go after the first batch, but the order doesn't matter [06:09] The first batch should have the big patch first, followed by acpi-revert-pci-interrupt-resume [06:10] ok [06:10] than all the others in no special order... [06:10] Yeah [06:10] ok [06:11] The others all depend on the first two, but other than that are order independent [06:11] ok [06:13] on which arches did you test them? [06:13] do they build on ia64? [06:13] Tested on x86 [06:13] what about amd64? [06:13] I don't have access to any ia64 [06:14] I'll check amd64 now [06:14] ok.. do you don't know if they build on amd64/ia64... [06:14] try to be around tomorrow than [06:14] if you can [06:14] i will start merging now [06:14] but i will build tomorrow probably... [06:15] Sure, no problem [06:15] fabbione: Oh, one thing I forgot to mention - the acpi-i2c one adds a new config option [06:15] i saw that [06:16] Ok [06:16] i guess M is fine... [06:16] Yup [06:16] perfect [06:17] hmmm agp-pm... [06:17] didn't we include that one already? [06:17] I don't think so [06:18] * Add PCI-E suspend/resume support: [06:18] - Add patch drivers-pci-pcie_resume-pcie.dpatch. [06:18] no [06:18] it was the PCI-E [06:18] Yeah [06:21] mjg59: where all these patches are coming from? === lamont [n=lamont@15.238.5.97] has joined #ubuntu-kernel [06:21] just to annotate them properly... [06:22] fabbione: The acpi ones are all from acpi upstream, except for the ones that we were already carrying [06:22] toshiba-acpi-dev is from John Belmonte's website [06:22] agp-pm is from the suspend2 tarball (which contains no indication of who wrote it) [06:23] acpi-i2c is from Bruno Ducrot's website [06:23] The reboot patch is me [06:24] ok === doko [n=doko___@dsl-084-059-089-049.arcor-ip.net] has joined #ubuntu-kernel [06:56] mjg59: only 4 left to apply :) [06:57] fabbione: Woo! [06:57] fabbione: I've got another couple for you... [06:57] (But then that's it for the day) [06:58] mjg59: At some point when you have t ime, can I get you to look over the DSDT patch that I've got to see why the classic initrd case fails? [06:58] jbailey: I can have a go, yeah [06:58] mjg59: send me... [06:58] mjg59: Either that or do you think I can get rid of that case an only handle having a DSDT.aml file in the initramfs? [06:58] the initramfs case works. [06:58] Breezy is going with initramfs? [06:58] mjg59: we already switched [06:58] mjg59: Yes, it's default already. =) [06:59] Yeah. I'd drop the initrd support, then. [06:59] mjg59: Nice, saves much trouble. =) [06:59] That's the part of the patch I'm having trouble with. [07:02] applying patch external-drivers-acpi-hardware-hwsleep_gpe-specs to ./ ... failed. === fabbione GRRRS [07:03] Oops [07:03] That's odd [07:04] Oh, shit [07:04] Sorry, I accidently diffed it from the wrong directory level [07:04] Looked like drivers-acpi-sleep-main_make-system-ready-to-resume.dpatch has the same problem [07:10] fabbione: Ok, that's it for now [07:11] mjg59: ok.. everything applies perfectly [07:12] mjg59: got the last mail [07:12] Rock [07:15] mjg59, BenC: i am going to commit the all ACPI stuff untested [07:15] i only know it applies clean [07:15] Ok [07:15] it will need a proper changelog entry [07:15] test build [07:15] and overall configs update [07:16] on all arches.. [07:16] The ACPI stuff is all from upstream, and I haven't /seen/ any complaints on other architectures [07:16] mjg59: well.. i would like to see it at least builded everywhere [07:16] Sure [07:17] BenC: you might have to ask elmo to upgrade some of the chroots.. iirc i did bump a B-D recently [07:25] so you have to build it on all architectures first, then update the debian/abi/* and then do the source upload? [07:25] oops [07:35] * committed kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12--patch-18 [07:35] ok this is the commit with all the ACPI crack [07:37] https://bugzilla.ubuntu.com/show_bug.cgi?id=11813 [07:37] we forgot the patch in here [07:37] Oops [07:37] Sorry, meant to send that to you [07:37] mjg59: is that patch still needed? [07:38] Yeah [07:38] oh my mother just bored me enough on the phone to push me to look at bugzilla for fun [07:38] Haha [07:38] i need to go and start to cook dinner [07:38] BenC: do you want to take care of it? [07:38] just add it at the end of the list [07:39] we also need that PATA patch.. and i think we are done for 7.11 [07:39] there is enough crack for the rest of week [07:40] EHHHH??!?!?!?!??? [07:40] ld -o tests/nfs_no_rpc crt0.o tests/nfs_no_rpc.o libc.a /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a [07:40] /usr/lib/gcc/sparc-linux-gnu/4.0.2/libgcc.a(_muldi3.o): In function `__muldi3': [07:40] : undefined reference to `.umul' [07:40] I DID FUCKING TEST BUILDED IT BEFORE UPLOAD ON EXACTLY THE SAME CHROOT [07:41] ah no.. [07:41] different binutils.. [07:41] Grrrrr [07:42] sure [07:43] BenC: cool [07:44] BenC: if you feel lucky today, there is libaio that is not ported to sparc ;) [07:44] it's missing an include file with some asm to generate direct syscalls to the kernel bypassing libc [07:44] ;) [07:46] fabbione: Why? [07:47] async i/O [07:47] it's faster for certain apps like DB [07:47] (that's the answer i got from upstream at least) [07:48] anyway... i need to go now [07:48] i might pass by later [07:51] later [07:51] I'll check into libaio after I do a kernel build [07:51] or better, while the kernel is building [07:51] BenC: that one is off line and just for fun :) [07:51] it's not important for sparc anyway [07:52] ok === michele [n=michele@host101-177.pool8256.interbusiness.it] has joined #ubuntu-kernel [09:22] hello [09:22] I'd like to know if this patch (or something to that effect) is going to make into breezy: http://marc.theaimsgroup.com/?l=linux-kernel&m=111504542402455&w=2 [09:23] no [09:23] that patch is broken [09:23] and breaks SCSI [09:23] + other stuff [09:23] oh nice... [09:24] does something else exists to have power mgmt in SATA systems? [09:24] not yet [09:24] so I guess that patch isn't even recommended to apply by myself right? [09:25] 9/10K [09:25] uh? [09:25] nope [09:26] don't apply it [09:26] ok... sigh [09:38] fabbione: I still don't see any way it can break SCSI [09:38] The only way it touches the SCSI layer is to add hooks for suspend/resume [09:38] On the other hand, it doesn't /work/ for SCSI [09:39] mjg59: ask greg or jeff.. i really don't know and i don't want to experiment it at 2 weeks from preview [09:39] fabbione: I spoke to alan about it last week [09:40] alan C? [09:40] greg and jeff haven't replied to my mails about it [09:40] Yeah [09:40] what did he say? [09:40] He said he couldn't see any problems with it [09:42] The only code that touches the SCSI subsystem is scsi_bus_suspend and resume [09:42] As far as I can tell, the objection is that it doesn't successfully suspend/resume SCSI (but then, that doesn't work /anyway/) [09:43] The rest of it's all safely contained in the sata layer [09:43] i think the issue was not SCSI as drivers, but as transport layer [09:44] It doesn't touch that part of the kernel [09:44] It's all libata stuff except for scsi_bus_suspend and scsi_bus_resume [09:44] i know.. but that's what they were talking about [09:44] fabbione, I can offer to test it in my thinkpad in case you decide to build a package. I have a spare 5GB. [09:44] There's absolutely no way that that code can touch it [09:45] michele: one test is not enough over 2309208 millions different combination of hw [09:45] fabbione, I know... just in case you needed it. Not trying to push you. [09:46] The only thing it will do on a SCSI setup is check whether the driver has a suspend method, and if so call it [09:46] let me ask again... === lamont wonders if we have a newer-and-better acpi patch. And if mjg59 has an ia64 box at home [09:46] lamont: build or try to from baz.. [09:46] fabbione: I'm prepared to believe that it's a patch that won't always work, but I can't see any way that it can make things worse than they currently are [09:47] lamont: Newer acpi crack is in, I have no ia64 [09:47] i committed all the acpi crack 2/3 hours ago [09:48] mjg59: coolness [09:48] lamont: If you want to send me an ia64 laptop... [09:49] mjg59: I don't think they exist, but a zx2000 might be able to land on your doorstep [09:50] it's kinda like a laptop :-) [09:50] in that it'll fill your lap. [09:50] lamont: Hmm. Unconvinced. [09:50] Oh, it's on of /those/ [09:51] Did Microsoft ever ship Windows for Itanium? === lamont _thinks_ so. === lamont checks [09:52] lamont: i am still waiting for my ia64 and hppa :) [09:52] mjg59: HP certainly shipped it. I expect that MS is at least supporting it in some manner.... [09:53] mjg59: Jeff says 2 things about that patch that he wrote [09:53] a) it's experimental and not ready for upstream [09:53] b) it needs a lot of SCSI love to work properly [09:53] fabbione: Right. But it /does/ work on some systems. [09:54] yes.. but it might as well breaks other [09:54] or make them worst than they are [09:54] fabbione: Uh. At the moment, suspend/resume is broken on *all* SATA machines. [09:54] There's no way to make them worse. [09:54] dude.. that's what he said right now [09:55] I entirely understand why it's not ready for upstream. He wants it to work properly. [09:55] But failing to work in some cases is still better than failing to work in all cases. [09:56] mjg59: there's an HP org that supports ia64/windoze [09:56] lamont: Wow [09:56] not sure how much of that is just front-ending M$, though [09:57] actually.... [09:57] mjg59: the patch can be splitted in 2 i think [09:57] mjg59: scsi and sata [09:57] fabbione: Mm? [09:57] they look sort of indipendet one from each other.. [09:57] fabbione: No - the SCSI part is needed to call the SATA suspend/resume methods [09:58] it doesn't look like... [09:58] Check the scsi_bus_suspend routine. It stops the SCSI queue, checks whether the driver has a suspend method and then calls it [09:58] + if (sht->suspend) [09:58] + err = sht->suspend(sdev); [09:59] ah ok.. [09:59] On SATA devices, that'll call ata_scsi_device_suspend [09:59] On SCSI devices, it's a noop [09:59] Until someone writes the support for them === fabbione ponders... [10:00] So the only thing it does on SCSI systems is to call scsi_device_quiesce(sdev) and scsi_device_resume(sdev); [10:00] Which is safe === fabbione ponders again [10:01] BenC: what do you think? [10:23] i am going to sleep on it.. [10:24] BenC: if you think the patch is reasonable.. go ahead and commit it.. [10:25] leave a note in an email on what you will manage to finish, so i don't need to spend time tomorrow digging around... [10:25]