Hi Joshua, Joshua Kinard wrote,
On 10/13/2016 15:23, Waldemar Brodkorb wrote:
Hi Joshua, Joshua Kinard wrote,
On 10/12/2016 04:27, Waldemar Brodkorb wrote:
hi,
i am visiting elce, be back on monday. can you try 1.0.17 please. 1.0.18 introduced some interesting regressions i habe not covered in my tests. i have solved most of them, but not all is pushed, yet.
looks related to the patch i sent out to lance last week on the list. best regards Waldemar
Von meinem iPhone gesendet
Am 12.10.2016 um 09:59 schrieb Joshua Kinard kumba@gentoo.org:
On 10/12/2016 03:53, Joshua Kinard wrote: Hello,
I think I've run into a rather odd bug on a big-endian MIPS platform while trying to hand-assemble a MIPS-II ISA netboot image built from a uclibc-ng chroot.
[snip]
PS, I forgot to add, this is using uclibc-ng-1.0.18 and busybox-1.24.2.
(Resending to the actual list, sorry Waldemar!)
Unfortunately, my base root for building the netboot is built on 1.0.18 at the moment. It'd take about two days to do a full rebuild.
So you are natively compiling the netboot system? Are you using static linked binaries, otherwise you could may be just change the shared library and ld.so.
I am doing native compiles on an SGI Octane (which I currently maintain the patchset for out-of-tree). I was only using static linking with Busybox, which is why ash was producing the flaw. I tried implementing the fix described in old uClibc Bug #3919, but that had no effect and the SIGSEGV is still reproducible.
For now, I've simply switched Busybox to use shared linking to resolve the problem, which should be fine with the netboot, since all of its utilities are built from the same chroot. Just trying to work up a fix for compiling rpcbind now, since a dependent library, libtirpc requires a non-existant header "rpcsvc/yp_prot.h", but there's a patch on the OpenWRT ML that might fix this.
You might find patches for such issues in Buildroot or OpenADK, too.
Does uclibc-ng have a working Bugzilla yet? Might seem prudent to copy the details of Bug #3919 from old uClibc since it might be the same bug or related.
I want to get rid of Trac soon, but I haven't decided what to do with the bug tracking.
That said, I think I might have an idea. The bit of code cited in Bug #3919 for old uclibc only defines and uses null_not_ptr in __uClibc_main.c, but it looks like the code in jmp-unwind.c does not. So I am going to try moving the null_not_ptr definition to a header somewhere, mark it non-static (maybe inline?), then try using it on the __pthread_cleanup_upto test and see if that might resolve the issue.
Sound sane?
I pushed the other open regression fixes. May be you could try with latest git master. On what hardware I could reproduce the issue? (I have some old SGI mips devices in my lab..)
I am running Gentoo for my builds, so testing master isn't easy for me at the moment, since to be sure of things, I'd have to run a full rebuild and that would take a day or two due to gcc's compile time (~16 hours on a dual 600MHz R14000 CPU).
What kind of SGI gear do you have available and what CPUs are in them? I can vouch that SGI O2 (IP32) with R5K and RM7K CPUs work (not R10K/R12K), SGI Octane (IP30), and marginally, SGI Origin 2000/Onyx2 (IP27) should all at least work with current Linux, although IP27 and IP30 will require an external set of patches I have (and IP27 may lock up at random).
The older SGI Indy and Indog2 series w/ R4K/R5K CPUs should also still work, but I have not tested those recently due to a bad RTC chip in my Indy. Other Indigo2 variants may or may not work depending on CPU.
I have 2xO2 and 2xIndy.
The modern O2:
hinv
System: IP32 Processor: 300 Mhz R5000, with FPU Primary I-cache size: 32 Kbytes Primary D-cache size: 32 Kbytes Secondary cache size: 1024 Kbytes Memory size: 128 Mbytes Graphics: CRM, Rev C Audio: A3 version 1 SCSI Disk: scsi(0)disk(1) SCSI CDROM: scsi(0)cdrom(4)
The classic O2:
hinv
System: IP32 Processor: 175 Mhz R10000, with FPU Primary I-cache size: 32 Kbytes Primary D-cache size: 32 Kbytes Secondary cache size: 1024 Kbytes Memory size: 128 Mbytes Graphics: CRM, Rev C Audio: A3 version 1 SCSI Disk: scsi(0)disk(2) SCSI CDROM: scsi(0)cdrom(4)
So I should bootup a system on the modern O2? OpenBSD is running 64Bit kernel and userland on O2 and I think I remember they fixed the r10k issues somehow.
What are you running on the Octane? Linux 64 Bit or 32 Bit? (n32,o32,n64 in case of 64Bit)
Best regards Waldemar