=== jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-ports === shinmen [n=shinmen@nat1.inalambrica.net] has joined #ubuntu-ports [03:08] jbailey: did you try to boot your sparc again or did you declare it dead? [03:08] fabbione: I can boot it fine. It just doesn't live through a gdb build. [03:08] And it hung on the loopback self-test. [03:08] fabbione: It's still sitting here plugged in, though. [03:09] hmmm [03:09] weird [03:09] I had managed to get an oops out of it once, but not when the serial console was plugged into it. [03:09] did you plug a net cable in it? [03:09] Yes. [03:09] Well [03:09] Into one of the three nics. [03:09] did you try to unplug it? [03:10] i wonder if the network card is hunging the test [03:10] No. [03:10] I was thinking of trying to find an old stable release (like woody) and putting it on, and doing builds. [03:10] Just to make sure. [03:10] But I won't have time for that soon. [03:10] I'm still worried that it could be just a gcc-4 issue or something. [03:11] hold on [03:11] I don't know how many other people are actively testing current dapper kernels. =) [03:11] halt [03:11] does it hang the boot or the hw? [03:11] EPARSE [03:11] i understood that the hw was broken [03:11] Which it? [03:11] dunno.. it sounded that way [03:11] The machine boots fine. [03:11] well you can still reinstall breezy and debug stuff :) [03:11] just stay with breezy kernel ;) [03:12] Installing breezy on this was such a pain in the arse. *sigh* === jbailey tries to backrev. [03:12] well dude [03:12] it was a pain true [03:13] now you admit to have a netcable in it [03:13] so you can netinstall it [03:13] and do it clean :) [03:13] I'm not setup for netinstall. [03:13] That's why I was testing CD installs for you. [03:13] I don't have a separate network, and shutting up the dhcp server is too much work. [03:14] That's why I Was thinking Woody. [03:14] you do have a laptop. don't you? [03:14] Yes. [03:14] No crossover cable atm. [03:14] I gave it back to infinity. =) [03:14] ok.. and 3 nics in the sparc? [03:14] ah ok [03:14] hell dude.. you should have told me [03:14] i have tons of crossovers and hubs === fabbione sighs [03:15] ok listen.. deal.. buy a cross over or an extra hub.. i will pay it ;) [03:15] Did Sparc participate in flight-1, btw? [03:15] nope [03:15] too busy building at that time [03:16] i might get flight 2 assuming oo2 builds [03:16] i got all of main builded [03:16] Is 2.6.12-9 a good test, or do I need to go older? [03:17] 2.6.12-9 is the kernel that we used for release [03:17] it's ok, why? [03:17] I'll try just setting that to the default boot. [03:17] ah ok [03:17] sure that should work if udev is not 100% nuts [03:18] udev won't run on that kernel. [03:18] It'll just refuse to start. [03:27] I've just fired up a gdb build on the old kernel, we'll see how she does. [03:28] cool [03:29] remind me.. why did you need gdb 64 bit? [03:30] I think case, to debug sparc64 tls. =) [03:30] s/think/this/ [03:30] s/I/In/ [03:30] no need to === jbailey needs to turn up the heat in here, fingers are stiff. [03:30] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341514 [03:30] I don't need to debug it? [03:30] tls works fine on 64bit assuming you backport all the patches from David Miller [03:30] that Debian did not [03:31] we did the right thing disabling it [03:31] Dude, what do you think I'm doing? [03:31] I'm in the middle of backporting all of them, and I get a segfault. [03:31] *cough* [03:31] ok [03:31] So now I'm debugging it before I upload it as a working version. =) [03:31] david said also that tls makes sense on 32bit [03:31] not on 64 [03:32] it's there almost only for accademic reasons [03:32] Umm, that's not sensical. [03:32] at least that's my understanding of what he said to me a couple of days ago [03:32] NPTL requires TLS support. [03:32] So if the goal is to eliminate the old LinuxThreads library, I need it working. [03:32] fabbione i don't think we will push that for dapper [03:32] davem right, sparc64 libc doesn't need to be TLS [03:32] davem it's nice that 32-bit can be [03:33] ok i can ask him for the patch than [03:33] He won't have it. [03:33] He did the work against current upstream. [03:33] You'll be asking him to do the same work that I've mostly done. [03:33] i didn't connect the 2 things till now [03:34] right.. [03:34] But we need gdb to work for all the arch combos we can run anyway. [03:34] well i am sorry.. i got to it too late [03:34] So I'm getting biarch to work for sparc/sparc64 and ppc/ppc64. [03:34] otherwise i would have asked him :/ [03:36] Well, but we can't expect Dave to carry the sparc port for us entirely. [03:36] no no no [03:36] i understand that [03:36] but given he wrote most of that code [03:37] for him doing a backport is much less expensive than for us [03:37] Not much so, though. [03:37] specially given he does use debian and ubuntu [03:37] he cares about it [03:37] Gettnig all the code was reasonably quick. [03:37] DEbugging it ought to be once I have a debugger. =) [03:37] My biggest limitation is waiting 12 hours for a build iteration. =) [03:38] glibc 2.3 and 2.4 changed how their TLS stuff is done. === fabbione eyes the choccolate cake in the kitchen and plans a pickup mission [03:38] So I ported all of the stuff to 2.3's style. [03:38] ah i see [03:38] I'm guess I've just missed an initialisation somewhere. [03:39] evi [03:39] l [03:39] Right. [03:39] Because it'll be in a chunk of asm. [03:39] can we split glibc? ;) [03:39] That's where he'd be able to go faster than I. [03:39] He can read the asm at full speed. [03:39] in a lot of tiny small readable sources? [03:39] But getting to this point is much harder. [03:39] It *is* small tiny readable sources. =) [03:39] That's half the problem. [03:39] In which frigging source file is the problem? =) [03:39] eh [03:40] exactly [03:40] But gdb will tell me what part of the initialisation is segfaulting. [03:40] right [03:40] Then I'll do the trace against a modern glibc compile and track both backwards. [03:41] you make me hot when you talk to me so dirty! [03:41] *lol* [03:41] ok time for a break [03:42] fabbione: It might be worth asking Znarl if he can handle it - he's been really quick on things. === lamont__ [n=lamont@mib.fc.hp.com] has joined #ubuntu-ports === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-ports [05:50] lamont: did you see what I said wrt elilo? [05:51] BenC: did not. [05:52] scroll back in ubuntu-kernel [05:53] BenC: doh [05:53] thanks [05:53] and awaiting your reply there [05:58] fabbione: I notice that the gdb testsuite includes a number of thread failures on sparc. I wonder how many of these are related to them making assumptions about debugging linuxthreads. [05:58] fabbione: I should check the source to see what its assuming. [06:29] gdb build finished on sparc. [06:30] So that hardware could still be broken, but not exercised by 2.6.12, or 2.6.15 could be broken. [06:30] No opinion offered. =) [06:33] none given either :) [06:33] I have no idea [06:33] it's an odd lockup [06:33] BenC: Maybe when there's less snow, I can give you my patch to gdb and you can try building it? [06:34] I don't know that it hangs the machine if I don't try a biarch gdb build. [06:34] if you can put it somewhere I can download it, I can do a build [06:36] Sure. I was more thinking that you don't want to have to go out there if it crashes. =) [06:37] It's a 3 line patch to debian/rules. Lemme put the .dsc/.diff.gz up somewhere. [06:39] it's ok, I can just flip the breaker for the whole barn from in the house, and reboot all the machines :) [06:39] You have the whole thing on one circuit out there? [06:39] Tell me it's a subpanel circuit. =) [06:39] And not a 15amp. = [06:39] ) [06:45] BenC: http://people.ubuntu.com/~jbailey/sparc/ [06:55] yeah, it's a 100Amp breaker to a subpanel === BenC curses direcway [06:56] might be a bit before I can do that gdb build [06:57] Fair Access Policy just kicked in because I was downloading edubuntu iso [06:57] Fair Access Policy? [06:57] pay $120/month for business grade access, three times the cost of cable, and they didn't tell me about this FAP bullshit [06:58] Hmm. Direcway. Isn't that DirecTv's Internet service? [06:58] yeah, if you consume high b/w over an extended period, they b/w limit you for awhile [06:58] yeah, I can't get normal broadband here [06:58] Just funny. I helped review some of the design specs for it. [06:59] I wonder how different the design from back then was to what they have now. [06:59] It was 1994. =) [06:59] other than FAP and the 400ms latency, it's not too bad [06:59] it's way different [06:59] I have high-power xmit, for .5mbs upload speed [07:00] Ah, yeah. The original design didn't include any up. It was telephone connect for up. [07:00] you can't stand in front of my dish, else you risk eltromagnetic health hazards :) [07:00] first time I had it, they just started the 56kps upload to avoid the phone line [07:00] But it was going to be basically 38,4k up, 100 megs down. =) [07:00] they've been building up business class service for high-power upload [07:01] shit, they don't sell 100mbs down, highest is 2mbs I believe [07:01] I max out at 300kbytes/sec [07:01] generally it's 200kbytes/sec [07:01] under FAP, I get 12kbytes/sec [07:01] Hmm. I wonder how much of that is just a limit on how fast you can ack packets. [07:01] *ouch* [07:02] I think most of it has to do with dish size, the higher d/l rate you get, the larger the dish gets [07:02] Yeah. I just looked in awe at the specs that actually mentioned how the birds and dishes worked. [07:03] Totally no clue on that side. [07:03] the xmit is configurable via the DW7000 modem/router, so they can bump that from the NOC [07:03] I think I'm at 2 watts on xmit [07:04] wish there was a way to bump that power without it telling the NOC :) [07:04] So the day beore thanksgiving they up the power and roast you a turkey in flight? =) [07:04] lol [07:05] I actually thought these new DW7000's were supposed to be linux OS on the inside [07:05] Hughes had a Linux black-box beta test a few years ago [07:05] but they are VxWorks (I can telnet to it) [07:06] It's interesting seeing Linux lose out a bit to VxWorks. [07:06] I don't follow embedded that closely, but it seems to be turning up more and more. [07:07] probably had to do with real-time stuff [07:07] ALso that an embedded more Linux kernel with all the size options turned on is still 700k uncompressed. [07:07] (2.6.14) [07:08] might have been something with the GPL too [07:08] all the press that Linksys got about WRT54G's being hacked up probably scared them === BenC has two linksys wrt's with hacked firmware to bump the xmit power [07:09] Yeah. [07:09] It would be sad to see Linux bumped out of the embedded market. [07:09] So many fun applications waiting for us. =) [07:09] yeah, I love doing embedded work [07:10] so much freedom === jbailey wanders out to buy groceries for lunch. =) [07:10] of course the only embedded system I ever did, I wrote the OS from scratch (multitasking, preemptive OS, with TCP/IP stack, video decode, and gigabit ethernet driver, in 512k RAM) [07:10] linux wouldn't be able to do that [07:11] BenC: Anything you want me to do on this sparc box befor eI wander off? [07:11] 512k, sweet. [07:11] nah, I'll get gdb compiling to see if I can reproduce [07:13] Cool. If you can't, I can try running test kernels or something that just spits out log information more often or something. [07:13] I've got a serial console wired up to it now, so if there's anything that can be got usefully from that, lemme know. [08:09] jbailey: ok [08:12] EUNMATCHED: ok [08:12] fabbione: Was that to the gdb thread failures comment? [08:13] jbailey: yes [08:13] (catching up on the backlog) [08:13] Yeah, it was just far enough back I didn't remember what I'd said to you. =) [08:14] no suriprise :) [09:24] Hmm. [09:24] BenC: Might still be my sparc hardware. [09:24] BenC: It died while sitting idle. [09:24] on 2.6.12-9 [09:25] ah, sadly, I'm happy about that :) === jbailey pouts at BenC =) [10:00] lamont, lamont__ : Any word on libc6-i386 for ia64 yet? === lamont__ wanders over to ask [11:21] lamont__: Thanks. =)