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 <ku...@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
devel mailing list

Reply via email to