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 <[email protected]>:
> >>>>
> >>>>> 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
_______________________________________________
devel mailing list
[email protected]
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
