Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-31 Thread Joshua Kinard 
On 10/31/2016 03:13, Waldemar Brodkorb wrote:
> Hi Joshua,
> Joshua Kinard wrote,
> 
>> On 10/23/2016 23:55, Waldemar Brodkorb wrote:
>>> Hi Joshua,
>>> Joshua Kinard wrote,
>>>

[snip]

>>>
>>> After sorting out my last bootup problems (missing N32/O32 binary
>>> support in the kernel), I can confirm that the bug is fixed in
>>> uCLibc-ng 1.0.19:
>>>
>>> root@openadk:/root # ash -c /tmp/c.sh 
>>> ash: /tmp/c.sh: Permission denied
>>> root@openadk:/root # chmod 755 .
>>> root@openadk:/root # chmod 755 /tmp/c.sh 
>>> root@openadk:/root # ash -c /tmp/c.sh 
>>> foo!
>>> root@openadk:/root # ash -c
>>> ash: -c requires an argument
>>> root@openadk:/root # ls /lib
>>>
>>> Please update to 1.0.19, thanks
>>>  Waldemar
>>
>> Sorry for the delay, got tied up with things.
>>
>> I'd already switched the busybox build to a shared library from a static
>> one, which worked around the issue for me, but I am building 1.0.19 now.
>> I'll let you know if any additional issues crop up.
>>
>> And for the record, on your last e-mail, an RM52XX O2 needs -march=rm5200 to
>> gcc.  Stock -mips4 or -march=r5000 won't hurt, either.
> 
> Okay.
>  
>> Now to just figure out the libtirpc bit...
> 
> Buildroot or OpenADK is always a good source for cross-compile
> issues. Take a look at the patches.
> 
> Another possibility would be to ty the internal ipv4 only RPC
> implementation in uClibc-ng, but I have'nt used it for a long time.
> 
> Not sure if rpcbind works with it. I think last time I sed it was
> with good old portmap.
> 
> best regards
>  Waldemar

I can get NFS to work with just portmap running, but it throws an odd, yet
non-fatal, error when mounting the remote share (don't have the actual error
text available at the moment).  I was hoping that having rpcbind running as
well as portmap would eliminate that.  However, current rpcbind needs
libtirpc to build, and that fails on uclibc-ng because of a missing header
file "rpcsvc/yp_prot.h".

Buildroot posted a patch to fix this in libtirpc itself, just haven't had
some free time to test it yet:
http://lists.busybox.net/pipermail/buildroot/2015-July/133890.html

Can't use the internal (minimal?) RPC mechanism, either.  I had to enable
the full RPC stack in order for portmap to actually build.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-31 Thread Waldemar Brodkorb 
Hi Joshua,
Joshua Kinard wrote,

> On 10/23/2016 23:55, Waldemar Brodkorb wrote:
> > Hi Joshua,
> > Joshua Kinard wrote,
> > 
> >> 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.  In my netboot, I need to include xfsprogs, but this has a 
> >> dependency
> >> on the 'valloc' function call.  So in uclibc-ng, I enabled
> >> CONFIG_UCLIBC_SUSV2_LEGACY to enable that function, and rebuilt uclibc-ng.
> >> This fixes the xfsprogs build, but it very subtly breaks busybox's ash 
> >> shell.
> >>
> >> After rebuilding uclibc-ng, then rebuilding busybox statically/multicall, 
> >> if
> >> you run /bin/ash with a malformed argument or give it a script to execute 
> >> that
> >> doesn't have the execute bit set, you get a SIGSEGV:
> >>
> >> Fudging up the argument syntax to /bin/ash:
> >> octane / # /bin/ash "-c"
> >> /bin/ash: -c requires an argument
> >> Segmentation fault
> >>
> >> Via a non-executable script "x.sh", we start with this sample:
> >> octane / # cat ./x.sh
> >> #!/bin/ash
> >> echo "foo!"
> >>
> >> If "x.sh" has the executable bit set, we're all good:
> >> octane / # ls -l ./x.sh
> >> -rwxr-xr-x 1 root root 24 Oct 12 01:57 ./x.sh
> >> octane / # /bin/ash -c ./x.sh
> >> foo!
> >>
> >> But if we turn off the executable bit...
> >> octane / # chmod -x ./x.sh
> >> octane / # ls -l ./x.sh
> >> -rw-r--r-- 1 root root 24 Oct 12 01:57 ./x.sh
> >> octane / # /bin/ash -c ./x.sh
> >> /bin/ash: ./x.sh: Permission denied
> >> Segmentation fault
> > 
> > After sorting out my last bootup problems (missing N32/O32 binary
> > support in the kernel), I can confirm that the bug is fixed in
> > uCLibc-ng 1.0.19:
> > 
> > root@openadk:/root # ash -c /tmp/c.sh 
> > ash: /tmp/c.sh: Permission denied
> > root@openadk:/root # chmod 755 .
> > root@openadk:/root # chmod 755 /tmp/c.sh 
> > root@openadk:/root # ash -c /tmp/c.sh 
> > foo!
> > root@openadk:/root # ash -c
> > ash: -c requires an argument
> > root@openadk:/root # ls /lib
> > 
> > Please update to 1.0.19, thanks
> >  Waldemar
> 
> Sorry for the delay, got tied up with things.
> 
> I'd already switched the busybox build to a shared library from a static
> one, which worked around the issue for me, but I am building 1.0.19 now.
> I'll let you know if any additional issues crop up.
> 
> And for the record, on your last e-mail, an RM52XX O2 needs -march=rm5200 to
> gcc.  Stock -mips4 or -march=r5000 won't hurt, either.

Okay.
 
> Now to just figure out the libtirpc bit...

Buildroot or OpenADK is always a good source for cross-compile
issues. Take a look at the patches.

Another possibility would be to ty the internal ipv4 only RPC
implementation in uClibc-ng, but I have'nt used it for a long time.

Not sure if rpcbind works with it. I think last time I sed it was
with good old portmap.

best regards
 Waldemar
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-21 Thread Joshua Kinard 
On 10/19/2016 23:46, Waldemar Brodkorb wrote:
> Hi Joshua,
> Joshua Kinard wrote,
> 
>> Have you tried 64K PAGE_SIZE by chance?  I use that setting on all of my SGI
>> systems except for the IP27, which has a peculiar Oops crop up under 64K, so
>> that machine boots 16K PAGE_SIZE at the moment.  You actually get a nice
>> performance bump on 16K or 64K versus the standard 4K.  The testing netboot
>> image I ran on my IP27 w/ 16K showed no ill effects, but I still need to do 
>> 64K
>> on the O2 and Octane.
> 
> I have not tested 64k, but I hope it will work fine. I will check as
> soon as I get my O2 netbooting.
> 
> It seems I am too stupid to get the machine netbooted.
> I tried dnsmasq (dhcp,tftp included) and dhcpd/atftpd combination.
> No success so far. I have running a small Linux on my Solidrun
> cubox-i as bootserver for my other machines, which normally just
> works fine.
> 
> Could you share your bootserver details and the command you are
> using to boot a system?
> 
> For better experience I just want to boot OpenBSD bsd.rd.IP32 file
> to see that my bootserver works. Afterwards I want to try my
> cross-compiled kernel.
> 
> I have netbooted so many machines, even old classic unix hardware,
> (with mopd, rarpd, bootparamd, ...) feeling stupid right now.
> 
> Any hints?

My netbooting setup is standard dhcpd with old-school netkit-tftpd (too lazy
to set up the more maintained tftp servers).  The bit probably hanging you
up is a simple /proc tuning directive needed for most SGI systems, so try
executing this line on the netboot server:

echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

That's needed for almost all of the SGI systems to netboot properly.  IP22
(Indy/Indigo2) systems need this additional /proc tuning to limit the
ephemeral port range:

echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range


To actually do the netboot, make sure "netaddr" is unset in the ARCS
environment:

unsetenv netaddr

Then try:

bootp(): 


E.g., for my Octane, I typically use:
bootp(): console=tty0 root=/dev/md0 consoleblank=0

And my IP27:
bootp(): console=ttyS0,9600 root=/dev/md0

If you have no kernel args to pass, then just use "bootp():"


Just make sure your dhcpd is set up to do BOOTP requests properly and that
you can tftp get the kernel image from the server using a tftp client, and
it should JustWork().  If you have issues with the kernel itself booting,
let me know and I can roll a kernel for you.  I haven't tested O2's in a
while, so I don't know if there's any surprises waiting in the 4.7 or 4.8 code.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-17 Thread Joshua Kinard 
On 10/17/2016 14:54, Waldemar Brodkorb wrote:
> Hi Joshua,

[snip]

> 
> You don't like cross-compiling, right?
> uClibc-ng seems not only be interesting for embedded devices, but
> also for classic old unix hardware :)
>  

Oh, I cross-compile all the time.  All of my SGI kernels are built with
cross-compilers.  Userland cross-compiling has just generally been trickier
than kernel cross-compiles, so I don't use it as often.  Plus, testing on the
hardware itself can turn up some rather interesting bugs at times, and in other
instances, you sometimes need the hardware to investigate if a particular CPU
quirk will come back to haunt you (the R10K's speculative execution one being
an all-time classic example).

And yeah, classic hardware still has its place!  There's a port of the Linux
kernel to the IP35-class of SGI hardware (Origin 300, Fuel, Tezro), that's been
started, but hasn't had any recent updates.  But it is functional enough to
boot a netboot with, supposedly, so that's on my infinitely-long TODO list to
try out at some point.  These platforms are still quite plentiful on eBay,
oddly enough, although parts for IP27 machines are becoming pretty scarce,
especially the larger Origin 2000/Onyx2 rack setups.

[snip]

>  
>>> What are you running on the Octane? Linux 64 Bit or 32 Bit?
>>> (n32,o32,n64 in case of 64Bit)
>>
>> Octanes can only boot a 64-bit kernel (same as their IP27 cousins), due to
>> their firmware only supporting 64-bit ELF format.  All of my SGI's run
>> N32/glibc-based userlands, though when I format the O2, it'll be back to O32
>> until I figure out how good uclibc's N32 support is.  I've also got a 
>> multilib
>> chroot based on glibc that mixes O32, N32, and N64, but wasn't able to 
>> complete
>> a fresh stage build with it due to some really weird glibc bug that popped up
>> during the stage3 build cycle.  I have to get glibc-2.24 into play and give 
>> it
>> another go at some point.
> 
> I tested n32 support on my Lemote Yeelong, so you should at least be
> able to boot. A longer time ago I had Xorg and Firefox running on
> the book. Firefox only support n32. The Lemote has a page size of
> 16k, so it showed some interesting bugs in uClibc/uClibc-ng in the past.

I haven't tried running X11 stuff in a long time on these systems.  Octane has
an X11 driver for its Impact graphics board, but my last attempt to fix it up
to compile, plus integrate other fixes for it, resulted in a SIGSEGV that I
lacked knowledge on debugging correctly.  I mostly stick to command-line right
now on these platforms.  And the direction that the Linux ecosystem itself is
moving towards, e.g., Wayland, may throw GUI support into doubt in the future
(have never actually tried Wayland yet).  Way too many things with the hardware
that still need fixing before one can take a look at the shiny bits.

Have you tried 64K PAGE_SIZE by chance?  I use that setting on all of my SGI
systems except for the IP27, which has a peculiar Oops crop up under 64K, so
that machine boots 16K PAGE_SIZE at the moment.  You actually get a nice
performance bump on 16K or 64K versus the standard 4K.  The testing netboot
image I ran on my IP27 w/ 16K showed no ill effects, but I still need to do 64K
on the O2 and Octane.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-17 Thread Waldemar Brodkorb 
Hi Joshua,
Joshua Kinard wrote,

> On 10/16/2016 17:45, Waldemar Brodkorb wrote:
> [snip]
> 
> > 
> > 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)
> > 
> 
> This is the one you'll want to use with Linux.  The 300MHz R5000's are 
> actually
> RM5261's by PMC Sierra (who bought them via their QED acquisition many years
> ago).  Linux refers to them as "Nevada" (CONFIG_CPU_NEVADA).  You can add up 
> to
> 1GB RAM, but when configuring the framebuffer (GBEFB) in the kernel, don't set
> its RAM higher than 4MB (else an Oops due to a *really* old bug no one's 
> chased
> down yet).

Thanks for the hints.
 
> I'm actually trying to get this netboot working so that I can re-install my O2
> w/ a uClibc-ng-based rootfs.  It's currently on an n32 glibc rootfs, but with
> gcc's increasingly-larger compile times and glibc's bloat, that machine,
> despite its 350MHz RM7000 CPU, just takes too long to do stuff (gcc is about a
> ~24-hour job).  64-bit PCI-X is also a little off, but 32-bit PCI should work
> fine as long as the driver isn't braindead and assumes little-endian.

You don't like cross-compiling, right?
uClibc-ng seems not only be interesting for embedded devices, but
also for classic old unix hardware :)
 
> > The classic O2:
> >> hinv
> >System: IP32
> > Processor: 175 Mhz R1, 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.
> 
> Yeah, OpenBSD solved the R10K issues, I *think*, by padding the affected
> instructions out with tons of 'cache' instructions, which I think is one of 
> the
> stated solutions for dealing w/ R10K's speculative execution feature on the
> non-coherent platforms (I think at the cost of a significant performance hit).
> I was told once that Linux's memory design and TLB handling is too complicated
> for a similar approach, but I haven't tried looking into the issue at all
> lately.  R12K CPUs have a hardware bit in their config register called "Delay
> Speculative Dirty" (DSD) that's supposed to help mitigate the problem, but you
> apparently still have to add some cache barriers before loads or stores (or
> both?).  I recently picked one of those up, but haven't had a chance to try it
> out yet.

Thanks for your very detailed answer.
 
> > What are you running on the Octane? Linux 64 Bit or 32 Bit?
> > (n32,o32,n64 in case of 64Bit)
> 
> Octanes can only boot a 64-bit kernel (same as their IP27 cousins), due to
> their firmware only supporting 64-bit ELF format.  All of my SGI's run
> N32/glibc-based userlands, though when I format the O2, it'll be back to O32
> until I figure out how good uclibc's N32 support is.  I've also got a multilib
> chroot based on glibc that mixes O32, N32, and N64, but wasn't able to 
> complete
> a fresh stage build with it due to some really weird glibc bug that popped up
> during the stage3 build cycle.  I have to get glibc-2.24 into play and give it
> another go at some point.

I tested n32 support on my Lemote Yeelong, so you should at least be
able to boot. A longer time ago I had Xorg and Firefox running on
the book. Firefox only support n32. The Lemote has a page size of
16k, so it showed some interesting bugs in uClibc/uClibc-ng in the past.

best regards
 Waldemar
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-16 Thread Joshua Kinard 
On 10/16/2016 17:45, Waldemar Brodkorb wrote:
[snip]

> 
> 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)
> 

This is the one you'll want to use with Linux.  The 300MHz R5000's are actually
RM5261's by PMC Sierra (who bought them via their QED acquisition many years
ago).  Linux refers to them as "Nevada" (CONFIG_CPU_NEVADA).  You can add up to
1GB RAM, but when configuring the framebuffer (GBEFB) in the kernel, don't set
its RAM higher than 4MB (else an Oops due to a *really* old bug no one's chased
down yet).

I'm actually trying to get this netboot working so that I can re-install my O2
w/ a uClibc-ng-based rootfs.  It's currently on an n32 glibc rootfs, but with
gcc's increasingly-larger compile times and glibc's bloat, that machine,
despite its 350MHz RM7000 CPU, just takes too long to do stuff (gcc is about a
~24-hour job).  64-bit PCI-X is also a little off, but 32-bit PCI should work
fine as long as the driver isn't braindead and assumes little-endian.


> The classic O2:
>> hinv
>System: IP32
> Processor: 175 Mhz R1, 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.

Yeah, OpenBSD solved the R10K issues, I *think*, by padding the affected
instructions out with tons of 'cache' instructions, which I think is one of the
stated solutions for dealing w/ R10K's speculative execution feature on the
non-coherent platforms (I think at the cost of a significant performance hit).
I was told once that Linux's memory design and TLB handling is too complicated
for a similar approach, but I haven't tried looking into the issue at all
lately.  R12K CPUs have a hardware bit in their config register called "Delay
Speculative Dirty" (DSD) that's supposed to help mitigate the problem, but you
apparently still have to add some cache barriers before loads or stores (or
both?).  I recently picked one of those up, but haven't had a chance to try it
out yet.


> What are you running on the Octane? Linux 64 Bit or 32 Bit?
> (n32,o32,n64 in case of 64Bit)

Octanes can only boot a 64-bit kernel (same as their IP27 cousins), due to
their firmware only supporting 64-bit ELF format.  All of my SGI's run
N32/glibc-based userlands, though when I format the O2, it'll be back to O32
until I figure out how good uclibc's N32 support is.  I've also got a multilib
chroot based on glibc that mixes O32, N32, and N64, but wasn't able to complete
a fresh stage build with it due to some really weird glibc bug that popped up
during the stage3 build cycle.  I have to get glibc-2.24 into play and give it
another go at some point.



> Best regards
>  Waldemar
> ___
> devel mailing list
> devel@uclibc-ng.org
> http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
> 


-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-16 Thread Waldemar Brodkorb 
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 :
> 
> > 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 R1, 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

Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS

2016-10-16 Thread Joshua Kinard 
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 :

> 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.

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.


>> 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.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
___
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel