who is on Gentoo/MIPS_SGI ?

Additional operating system/hardware discussion (Windows, Linux, *BSD and others)
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
nyef
Posts: 73
Joined: Tue Apr 28, 2015 7:54 pm

Re: who is on Gentoo/MIPS_SGI ?

Unread postby nyef » Sun Dec 06, 2015 11:53 am

I'm running Gentoo on an Origin 350 as my main MIPS system (currently based on kernel 4.2.0). There's an FPU bug that affects t5 CPUs (preventing proper FPU operation for n32 and n64 systems, but not affecting o32 systems), and what looks like some sort of TLB bug that needs hunting down, and it's only running one CPU, but things are generally stable.

I have a couple of IP30 systems to install Linux on, I just haven't settled in to trying to get them to work.

nyef
Posts: 73
Joined: Tue Apr 28, 2015 7:54 pm

Re: who is on Gentoo/MIPS_SGI ?

Unread postby nyef » Sun Dec 06, 2015 12:50 pm

Code: Select all

 *    - Greater than 2GB memory causes problems with DMA.  This is a long-standing
 *      problem and patches to fix it by DMA experts would be greatly appreciated!

On my list to hack on once I get a working IP30 setup. IP35 doesn't have a problem with this, and I have some experience with getting DMA working on XBridge and PIC, and BRIDGE is basically XBridge so I don't expect too much trouble on that front.

Code: Select all

 *    - Do not use OHCI-based USB cards in Octane.  They're broke on this machine.
 *      Patches are welcome to fix the issue.

On my O300, I find that enabling the OHCI driver causes the SCSI driver to stop functioning (!).

Code: Select all

 *    - Serial support on the Octane uses a very basic UART driver that drives
 *      the 16550A chip on the IOC3 directly.  It does not use interrupts,
 *      only a polling routine on a timer, which makes it slow and CPU-
 *      intensive.  The baud rate is limited to no more than 38.4kbps on
 *      this driver.  Patches for getting the Altix IOC3 serial driver to
 *      work (which uses DMA and supports faster baud rates) are welcome.

Working on IP35, using the DMA-based driver. Took a bit to sort out endianness issues and DMA and whatnot, but was fairly straightforward overall.

Code: Select all

 *    - UHCI Cards are known to have issues, but should still have some functionality.
 *      This issue primarily manifests itself when using pl2303 USB->Serial adapters.

I have a few pl2303 adapters handy, not sure about the UHCI cards, though.

Unfortunately, the IP35 code conflicts a bit with the IP30 code, so merging things is a bit tricky.

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Sun Dec 06, 2015 7:16 pm

After a ~2 month hiatus, I've got the Octane running and have been building N32 stages for the last week. mips4_r12k_n32 and mips3_n32 are done, but then I discovered a ~2012 uclibc-based stage4, mips3 big-endian, that another Gentoo dev rolled, and have been trying to bit-bang that into updating so I can use it as a seed stage to finally create new MIPS uClibc-based stages for generating new netboot images. Install stages are only good if you can boot something to install them with. Last uclibc stages were done in ~2006 or 2007.

I had tried a musl-based netboot image, but I have been experimenting with PAGE_SIZE=64K on my Octane/Origin kernels lately, which really helps speed up compiling (shaves ~45mins off of a binutils compile). However, musl seems to hardcode the PAGE_SIZE it was built with somewhere, so if you booted a kernel with PAGE_SIZE=4K with this musl netboot....all sorts of problems cropped up. Glibc is just too bloated to make an all-purpose netboot, as IP22-class systems have severe limitations on the size of the kernel image that can be loaded, and IP32 can get fussy as well.

Other successes include gcc-5.3.0 building successfully under uclibc (O32). I'll have to build it again under glibc (N32) later tonight to see if gcc PR66038 is resolved now, as that's prevented me from successfully building any gcc-5.x release under glibc (N32) so far. If that holds true, well, I'll be restarting my stage builds all over again. It's a pity the Onyx2 still locks up at random, else I could run that to speed up my stage builds. I suspect the lock up has something to do with a race condition and page migration, but I haven't had time to chase it down much more.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Sun Dec 06, 2015 7:32 pm

nyef wrote:

Code: Select all

 *    - Greater than 2GB memory causes problems with DMA.  This is a long-standing
 *      problem and patches to fix it by DMA experts would be greatly appreciated!

On my list to hack on once I get a working IP30 setup. IP35 doesn't have a problem with this, and I have some experience with getting DMA working on XBridge and PIC, and BRIDGE is basically XBridge so I don't expect too much trouble on that front.

Hopefully I'll be able to get you a working beta-netboot within the next 1-2 weeks for the Octane, if this uclibc experiment pans out. The DMA thing has been driving me up the wall, because once the 2GB barrier is worked around and I can hunt down some more high-density RAM chips, I can maybe use a ramdisk for some of the compiling to further speed things up.


nyef wrote:

Code: Select all

 *    - Do not use OHCI-based USB cards in Octane.  They're broke on this machine.
 *      Patches are welcome to fix the issue.

On my O300, I find that enabling the OHCI driver causes the SCSI driver to stop functioning (!).

I don't even know why anyone would want to run USB1.x anymore. I should probably get EHCI and xHCI cards and plug them in to do some USB2 and USB3 testing under IP30. As long as nothing I test is a USB hub, might get something workable out. Speed tests especially would be interesting.


nyef wrote:

Code: Select all

 *    - Serial support on the Octane uses a very basic UART driver that drives
 *      the 16550A chip on the IOC3 directly.  It does not use interrupts,
 *      only a polling routine on a timer, which makes it slow and CPU-
 *      intensive.  The baud rate is limited to no more than 38.4kbps on
 *      this driver.  Patches for getting the Altix IOC3 serial driver to
 *      work (which uses DMA and supports faster baud rates) are welcome.

Working on IP35, using the DMA-based driver. Took a bit to sort out endianness issues and DMA and whatnot, but was fairly straightforward overall.

Got a stand-alone patch for that? Fixes for that are probably distinct from the core IOC3 mess. Would be interesting to see if Octane's DMA situation is sane enough to run that. After I fix the "ttyIOCx" names back to a proper "ttySx" naming scheme...


nyef wrote:

Code: Select all

 *    - UHCI Cards are known to have issues, but should still have some functionality.
 *      This issue primarily manifests itself when using pl2303 USB->Serial adapters.

I have a few pl2303 adapters handy, not sure about the UHCI cards, though.

pl2303 converters are junk anyways. I've switched to using the XS880 from U.S. Converters, which is based off of an FTDI FT232RL chipset and ZyWyn ZT213LEEA serial driver. They're not cheap at about ~$44 a pop, but all of the problems I've had with serial consoles has practically vanished since picking several of these up. Have yet to test them in the Octane, though, but I assume any problems will be in the IP30 code and not tied to these devices or the Linux driver for them.


nyef wrote:Unfortunately, the IP35 code conflicts a bit with the IP30 code, so merging things is a bit tricky.

Yeah, we still gotta work on that :) Getting the IOC3 bits hammered out and upstreamed will simplify things a bit. I just got busy the last two months, and may do so again in the new year (but we'll see).
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

nyef
Posts: 73
Joined: Tue Apr 28, 2015 7:54 pm

Re: who is on Gentoo/MIPS_SGI ?

Unread postby nyef » Sun Dec 06, 2015 8:38 pm

Kumba wrote:After a ~2 month hiatus, I've got the Octane running and have been building N32 stages for the last week. mips4_r12k_n32 and mips3_n32 are done, but then I discovered a ~2012 uclibc-based stage4, mips3 big-endian, that another Gentoo dev rolled, and have been trying to bit-bang that into updating so I can use it as a seed stage to finally create new MIPS uClibc-based stages for generating new netboot images. Install stages are only good if you can boot something to install them with. Last uclibc stages were done in ~2006 or 2007.

I have bad news for you: If you check, you'll find that the FPU won't kick over to FR1 mode, which is required for N32 and N64. It's on my shortlist to try and fix, but my project bandwidth has shifted away from MIPS kernel hacking for the past while.

I had tried a musl-based netboot image, but I have been experimenting with PAGE_SIZE=64K on my Octane/Origin kernels lately, which really helps speed up compiling (shaves ~45mins off of a binutils compile). However, musl seems to hardcode the PAGE_SIZE it was built with somewhere, so if you booted a kernel with PAGE_SIZE=4K with this musl netboot....all sorts of problems cropped up. Glibc is just too bloated to make an all-purpose netboot, as IP22-class systems have severe limitations on the size of the kernel image that can be loaded, and IP32 can get fussy as well.

Interesting (probably bad) news: I have a short C test program that causes my O350 to reliably do something weird, and one of the failure modes is a bus error. And it runs perfectly well on my ERLite-3. I think it's a TLB thing, but haven't tracked it down beyond getting a test program, which I did hand off to Ralf so that there'd be more than one set of eyes on the problem. http://paste.lisp.org/display/160204 if you want to take a look.

nyef wrote:

Code: Select all

 *    - Greater than 2GB memory causes problems with DMA.  This is a long-standing
 *      problem and patches to fix it by DMA experts would be greatly appreciated!

On my list to hack on once I get a working IP30 setup. IP35 doesn't have a problem with this, and I have some experience with getting DMA working on XBridge and PIC, and BRIDGE is basically XBridge so I don't expect too much trouble on that front.

Hopefully I'll be able to get you a working beta-netboot within the next 1-2 weeks for the Octane, if this uclibc experiment pans out. The DMA thing has been driving me up the wall, because once the 2GB barrier is worked around and I can hunt down some more high-density RAM chips, I can maybe use a ramdisk for some of the compiling to further speed things up.

I'm still keeping an eye out for high-density Octane SIMMs myself, even if I haven't managed to fix (or work around) the bent (and now stripped) screw that's keeping me from getting at the mainboard with the 2x600 CPU module.

nyef wrote:

Code: Select all

 *    - Serial support on the Octane uses a very basic UART driver that drives
 *      the 16550A chip on the IOC3 directly.  It does not use interrupts,
 *      only a polling routine on a timer, which makes it slow and CPU-
 *      intensive.  The baud rate is limited to no more than 38.4kbps on
 *      this driver.  Patches for getting the Altix IOC3 serial driver to
 *      work (which uses DMA and supports faster baud rates) are welcome.

Working on IP35, using the DMA-based driver. Took a bit to sort out endianness issues and DMA and whatnot, but was fairly straightforward overall.

Got a stand-alone patch for that? Fixes for that are probably distinct from the core IOC3 mess. Would be interesting to see if Octane's DMA situation is sane enough to run that. After I fix the "ttyIOCx" names back to a proper "ttySx" naming scheme...

As part of http://git.linux-mips.org/cgit/nyef/linux-ip35/log/?h=v4.2-ioc-changes, there is commit http://git.linux-mips.org/cgit/nyef/linux-ip35/commit/?h=v4.2-ioc-changes&id=6142674bcb716f1702ec2e364887a4434f75720d, which is the IOC3 serial magic.

I've got a possible further angle so that we don't have to do this constant "blah, blah, and on SGI MIPS we also have to twiddle this bit in the DMA address" thing. And, now that I'm thinking about it, my patches may not work for you due to the differences between the DMA setup between the IP30 bridge driver and the IP35 bridge driver.

nyef wrote:

Code: Select all

 *    - UHCI Cards are known to have issues, but should still have some functionality.
 *      This issue primarily manifests itself when using pl2303 USB->Serial adapters.

I have a few pl2303 adapters handy, not sure about the UHCI cards, though.

pl2303 converters are junk anyways. I've switched to using the XS880 from U.S. Converters, which is based off of an FTDI FT232RL chipset and ZyWyn ZT213LEEA serial driver. They're not cheap at about ~$44 a pop, but all of the problems I've had with serial consoles has practically vanished since picking several of these up. Have yet to test them in the Octane, though, but I assume any problems will be in the IP30 code and not tied to these devices or the Linux driver for them.

Yeah, the pl2303 adapters are junk. Realized only after having accumulated three or four of them that they were less than excellent. Promptly started transitioning to using the network interfaces on system controllers where appropriate (an HP iLO, a Sun ALOM), and I'm planning on making a couple more cables for my EL-16 to cover the rest of what I have hooked up via USB-serial adapters. My primary use-case is remote management of a stack of machines over a VPN, so the USB-serial bit was more of a hack to get things working than a real solution.

nyef wrote:Unfortunately, the IP35 code conflicts a bit with the IP30 code, so merging things is a bit tricky.

Yeah, we still gotta work on that :) Getting the IOC3 bits hammered out and upstreamed will simplify things a bit. I just got busy the last two months, and may do so again in the new year (but we'll see).

I'm wondering if it might not make sense for me to create an IP30 branch from my current IP35 tree and basically try to bring it up like a new port, cribbing liberally from your existing patch set.

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Sun Dec 06, 2015 9:16 pm

nyef wrote:I have bad news for you: If you check, you'll find that the FPU won't kick over to FR1 mode, which is required for N32 and N64. It's on my shortlist to try and fix, but my project bandwidth has shifted away from MIPS kernel hacking for the past while.

Is this affecting IP35-only? I haven't had much of an issue on IP30 running N32. IP27 had a minor buggeroo w/ FP support when Maciej added a patch that didn't account for IP27's setting FCSR to random values on a cold restart. That was quickly detected and fixed, though. That all said, I haven't tried running any programs that fully exploit N32 and FP yet, either.


nyef wrote:Interesting (probably bad) news: I have a short C test program that causes my O350 to reliably do something weird, and one of the failure modes is a bus error. And it runs perfectly well on my ERLite-3. I think it's a TLB thing, but haven't tracked it down beyond getting a test program, which I did hand off to Ralf so that there'd be more than one set of eyes on the problem. http://paste.lisp.org/display/160204 if you want to take a look.

Running this won't crash the kernel, will it? Don't want to interrupt the compile run on the uclibc stuff if it will...



It looks like this is the most relevant bit:

Code: Select all

diff --git a/drivers/tty/serial/ioc3_serial.c b/drivers/tty/serial/ioc3_serial.c
index 27b5fef..d8d3328 100644
--- a/drivers/tty/serial/ioc3_serial.c
+++ b/drivers/tty/serial/ioc3_serial.c
@@ -23,6 +23,10 @@
 #include <linux/ioc3.h>
 #include <linux/slab.h>
 
+#ifdef CONFIG_SGI_IP35
+#include <asm/pci/bridge.h>
+#endif
+
 /*
  * Interesting things about the ioc3
  */
@@ -445,7 +449,11 @@ static int inline port_init(struct ioc3_port *port)
 
       sbbr_l = &idd->vma->sbbr_l;
       sbbr_h = &idd->vma->sbbr_h;
+#ifdef CONFIG_SGI_IP35
+                ring_pci_addr = ((unsigned long __iomem)port->ip_dma_ringbuf) & ~(PCI64_ATTR_SWAP);
+#else
       ring_pci_addr = (unsigned long __iomem)port->ip_dma_ringbuf;
+#endif
       DPRINT_CONFIG(("%s: ring_pci_addr 0x%p\n",
                 __func__, (void *)ring_pci_addr));

I believe I have most of what is in your ioc3.h hunk in the base IOC3 patch. I'll try to apply this one change and see if IP30 comes up on the DMA driver.


nyef wrote:I've got a possible further angle so that we don't have to do this constant "blah, blah, and on SGI MIPS we also have to twiddle this bit in the DMA address" thing. And, now that I'm thinking about it, my patches may not work for you due to the differences between the DMA setup between the IP30 bridge driver and the IP35 bridge driver.

I got a feeling a lot of the [X]BRIDGE setup code between IP27, IP30, and IP35 can be unified a bit more over time. Make the mess a lot easier to read and follow. IP27's big issue is the resource allocation part. I ended up changing that to the XIO window bases, and it works for internal PCI stuff, but that system was not picking up on a USB2.0 card I installed via an XIO shoehorn. Ended up pulling that card before I thought to revert to the original code and test again.

nyef wrote:I'm wondering if it might not make sense for me to create an IP30 branch from my current IP35 tree and basically try to bring it up like a new port, cribbing liberally from your existing patch set.

That should work. I can cherry pick as needed until things are more unified. I track upstream a lot faster, using rolling new patches from my local git repo when a new kernel is released and Ralf pulls from upstream. 4.4 looks to still be a few weeks off, probably 2-3rd week of January, if I had to guess. I need to re-submit patches I had for 4.4 for 4.5 (or 4.6), as Ralf didn't get to them for the 4.4 merge window.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Mon Dec 07, 2015 5:04 am

ivelegacy wrote:
Hopefully I'll be able to get you a working beta-netboot within the next 1-2 weeks for the Octane,

already done for 2.6.17, I can re-use the ramrootfs with kernel 4.* :D

You can, as I sometimes use that old ~2007 netboot for fixing things. But it is *severely* bitrotted. mdadm can't create RAID arrays at all, networking is a touch fickle, etc there's other issues that I can't even remember. I wouldn't trust the filesystem tools one bit, either, in that netboot.


ivelegacy wrote:p.s.
is there a Gigabit/sec PCI card that is known to work with XIO_PCI (ShoeHorn or ShoeBox) ?

Unknown. Just has to support 5V power, so look for PCI-X gigabit cards. Two I ran into earlier tonight are from Sonnet, which caters more to the Mac crowd (but their PCI boards are purple). They have a single-port gigabit card as well as a dual-port. I am told their products are not at all cheap, but are very well built. I have no idea if they'll work in an Octane or Origin/Onyx2:

Sonnet Presto™ Gigabit Pro PCI card:
http://www.sonnettech.com/product/prestogigpro.html

Sonnet Presto™ Gigabit Server:
http://www.sonnettech.com/product/prestogigserver.html
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

nyef
Posts: 73
Joined: Tue Apr 28, 2015 7:54 pm

Re: who is on Gentoo/MIPS_SGI ?

Unread postby nyef » Mon Dec 07, 2015 9:34 am

Kumba wrote:
nyef wrote:I have bad news for you: If you check, you'll find that the FPU won't kick over to FR1 mode, which is required for N32 and N64. It's on my shortlist to try and fix, but my project bandwidth has shifted away from MIPS kernel hacking for the past while.

Is this affecting IP35-only? I haven't had much of an issue on IP30 running N32. IP27 had a minor buggeroo w/ FP support when Maciej added a patch that didn't account for IP27's setting FCSR to random values on a cold restart. That was quickly detected and fixed, though. That all said, I haven't tried running any programs that fully exploit N32 and FP yet, either.

All R1x000 CPUs. The FPU implementation/revision ID register is defined to have the top half wired to zero, but the kernel treats it as a bunch of flags for features present or not present (probably a mips32/mips64 thing, and since mips4 predates them we get bit).

nyef wrote:Interesting (probably bad) news: I have a short C test program that causes my O350 to reliably do something weird, and one of the failure modes is a bus error. And it runs perfectly well on my ERLite-3. I think it's a TLB thing, but haven't tracked it down beyond getting a test program, which I did hand off to Ralf so that there'd be more than one set of eyes on the problem. http://paste.lisp.org/display/160204 if you want to take a look.

Running this won't crash the kernel, will it? Don't want to interrupt the compile run on the uclibc stuff if it will...

I've not noticed it crash the kernel, but you may want to play it safe anyway. It also might only crash on the smaller page size.

nyef wrote:I've got a possible further angle so that we don't have to do this constant "blah, blah, and on SGI MIPS we also have to twiddle this bit in the DMA address" thing. And, now that I'm thinking about it, my patches may not work for you due to the differences between the DMA setup between the IP30 bridge driver and the IP35 bridge driver.

I got a feeling a lot of the [X]BRIDGE setup code between IP27, IP30, and IP35 can be unified a bit more over time. Make the mess a lot easier to read and follow. IP27's big issue is the resource allocation part. I ended up changing that to the XIO window bases, and it works for internal PCI stuff, but that system was not picking up on a USB2.0 card I installed via an XIO shoehorn. Ended up pulling that card before I thought to revert to the original code and test again.

I have near certainty that they can be unified. The main differences are the IRQ mapping, and that 512-meg DMA thing on IP30. And since the DMA thing is for D32 DMA, which neither IP27 nor IP35 are using (and I'll argue that IP30 probably shouldn't use either)...

nyef wrote:I'm wondering if it might not make sense for me to create an IP30 branch from my current IP35 tree and basically try to bring it up like a new port, cribbing liberally from your existing patch set.

That should work. I can cherry pick as needed until things are more unified. I track upstream a lot faster, using rolling new patches from my local git repo when a new kernel is released and Ralf pulls from upstream. 4.4 looks to still be a few weeks off, probably 2-3rd week of January, if I had to guess. I need to re-submit patches I had for 4.4 for 4.5 (or 4.6), as Ralf didn't get to them for the 4.4 merge window.

Okay, so if I start within the next month, rebasing to a 4.4-rc tree is probably in order as a first step.

User avatar
ClassicHasClass
Donor
Donor
Posts: 2109
Joined: Wed Jul 25, 2012 7:12 pm
Location: Sunny So Cal
Contact:

Re: who is on Gentoo/MIPS_SGI ?

Unread postby ClassicHasClass » Mon Dec 07, 2015 1:30 pm

I am told their products are not at all cheap, but are very well built.


That's pretty much Sonnet in a nutshell. The one card of theirs I had that went bad, they no longer sold, but were able to locate a replacement for me out of new old stock at their expense. And that was after the warranty ended, by the way.
smit happens.

:Fuel: bigred, 900MHz R16K, 4GB RAM, V12 DCD, 6.5.30
:Indy: indy, 150MHz R4400SC, 256MB RAM, XL24, 6.5.10
:Indigo2IMP: purplehaze, 175MHz R10000, Solid IMPACT
probably posted from Image bruce, Quad 2.5GHz PowerPC 970MP, 16GB RAM, Mac OS X 10.4.11
plus IBM POWER6 p520 * Apple Network Server 500 * RDI PrecisionBook * BeBox * Solbourne S3000 * Commodore 128 * many more...

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Mon Dec 07, 2015 1:50 pm

nyef wrote:All R1x000 CPUs. The FPU implementation/revision ID register is defined to have the top half wired to zero, but the kernel treats it as a bunch of flags for features present or not present (probably a mips32/mips64 thing, and since mips4 predates them we get bit).

Yeah, I've always noticed that the Kernel seems to read the FPU revision a bit oddly, always reporting it in "uname -a" as "0.0" (Gentoo's version of uname parses the Machine/CPU/FPU type out of /proc/cpuinfo). Sounds like a bug to report to the linux-mips ML; maybe get Ralf or Maciej's attention on it. That said, I haven't seen any ill effects running N32 on the Octane, so I must not have managed to trip it up just yet.


nyef wrote:I've not noticed it crash the kernel, but you may want to play it safe anyway. It also might only crash on the smaller page size.

Or the stars will become right again and dead Cthulhu will live once more.


nyef wrote:I have near certainty that they can be unified. The main differences are the IRQ mapping, and that 512-meg DMA thing on IP30. And since the DMA thing is for D32 DMA, which neither IP27 nor IP35 are using (and I'll argue that IP30 probably shouldn't use either)...

Agreed. I have a test branch in my local repo where I switched the bits over to do DMA64 and use large XIO windows. The machine actually booted and ran for a few minutes, before something in the SCSI subsystem locked it up. So it's definitely doable, but needs further work. Also, the other bits are to properly handle pure-XIO devices with Linux's DMA setup, because it blindly assumes anything doing DMA is a PCI device. That's likely the source of the Impact driver's ills.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Thu Dec 10, 2015 3:24 pm

ivelegacy wrote:gentoo-4.3.0.20151126: the first try … fails

Code: Select all

xtalk:0 xbow widget (rev 2.0) registered as a platform device.
xtalk:8 heart widget (rev F) registered as a platform device.
xtalk:10 bridge widget (rev D) registered as a platform device.
xtalk:11 bridge widget (rev D) registered as a platform device.
xtalk:15 bridge widget (rev D) registered as a platform device.



                         Running power-on diagnostics…


I am switching back to "ip30_defconfig-4.3.0", then I will try to add features and options

I said I stripped that defconfig down a fair bit. Can't rule out I removed something critical. I'll have to remember to do some test boots to work out a generic defconfig and add it to my patch set.

That said, at the above point you indicated, did it simply freeze up or auto-reboot itself?


ivelegacy wrote:

Code: Select all

>> bootp():
Setting $netaddr to 192.168.1.4 (from server )
Obtaining  from server
10547500+256516 entry: 0xa80000002049d240

*** PROM write error on cacheline 0x1fcc1100 at PC=0xa8000000205f8270 RA=0xa8000000205dc24c


the the second try fails funnier :lol:

This is one of those annoying errors that no one has ever figured out. Similar to why CONFIG_DEBUG_LOCK_ALLOC always triggers the "doesn't fit in a FreeMemory area." error on at least IP27 and IP30. I suspect both are probably related to alignment oddies in the final kernel image.


ivelegacy wrote:

Code: Select all

 [5] mips64-unknown-linux-gnu-4.3.5
 [6] mips64-unknown-linux-gnu-4.9.3 *


emerged & switched to sys-devel/kgcc64-v4.9.3!
(64bit kernel compiler)

Yeah, please use a more recent compiler than 4.3.x. That's over 5 years old.

You can also build a cross-compiler on a faster Intel box using Gentoo's crossdev tool (if you have Gentoo on another box). The kernel currently running on my Octane is built with gcc-5.3.0, although right now, you can't compile 5.3.0 on MIPS N32 itself, possibly due to PR66038. Might work on O32, as I can build gcc-5.3.0 in a uclibc chroot, but haven't tried on a glibc chroot yet.

You have dual R14K/600MHz in your Octane, right? What graphics card?
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Thu Dec 10, 2015 6:23 pm

ivelegacy wrote:auto-reboot itself!

That would indeed be odd. Usually, the kernel would just lock up, not trigger the PROM reset vector or HEART's cold reset bit. Gonna have to write this one off to your compiler for now.


ivelegacy wrote:my IP30 is SMP2xR12K@400Mhz, my friend machine is 2XR14K@600Mhz
both machines do not have a GfX installed, mine has a MENET and ShoeHorn
his machine has a empty carrier (just the plastics without anything installed)

the above screenshot is from his machine, mine auto-reboot itself
so we get the same reaction from both of them

I'll upload a config in a bit that has SMP stuff, but lacks graphics entirely. If that fails, then I'll build a kernel for you to try.


ivelegacy wrote:my production kernel, 2.6.17-rc4-hack, gets compiled by kgcc-v4.3.5 and boots fine
I have switched to the last kgcc in the portage

gcc-5.3.0, as far as I see from the portage (last --sync, yesterday) it's currently ~mips
but I can force it, just give me the time, my Atheros9 takes 9 hours to compile gcc

Still need to get you off of 2.6.x entirely. I can only wonder about the security flaws that cumulatively exist in such an old release.

gcc-5.3.0 is ~mips, but as I mentioned previously, none of the 5.x series will compile under N32 (N64 is unknown). It might under O32, but I can only vouch for that on a Uclibc root, as my glibc-based o32 root got brain-damaged when I was trying to migrate to N32 a while back, and I just haven't set up another one yet. That said, I *think* 5.x compiles faster. In uclibc, I timed a full build at ~11 hours, while I know 4.9.x is closer to 13 hours. That was on a dual R14K/600MHz CPU, though. The 5.3 release notes suggest that this release sports faster code generation and link times, so that might explains the differences.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Tue Dec 15, 2015 2:56 am

ivelegacy wrote:

Code: Select all

Instruction bus error, epc == 0000000000443b3c, ra == 0000000000444b88
/usr/bin/myNET-web-machine-info: line 51:   246 Bus error               myNET-networktraffic $netdev >>$page_name2


How old is your initramfs? The problems I ran into on the Octane were Data Bus Errors (DBE), not IBEs, and those were solved once I learned to use the correct handle_*_irq() function. I'm wondering if you've got that initramfs built using really old toolchains/kernel headers and it's just not playing nice.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Tue Dec 15, 2015 3:45 am

ivelegacy wrote:built in 2008

Okay, about as old as the last one I built (2007).


ivelegacy wrote:it works with SMP=disabled

I figured as much. Although I have not had any severe problems with SMP once I fixed the IRQ setup, I can't rule out that all SMP-related problems have been solved, though.


ivelegacy wrote:
Kumba wrote:and those were solved once I learned to use the correct handle_*_irq() function


isn't kernel matter?

Not following what you're asking here?


ivelegacy wrote:

Code: Select all

kika # uname -r
2.6.39-flesh-eating-bats


she has

Code: Select all

kika # gcc-config -l
 [1] mips-unknown-linux-gnu-4.1.2 *
 [2] mips-unknown-linux-gnu-4.5.2
 [3] mips-unknown-linux-gnu-4.6.3

I used gcc- v4.1.2, uclibc profiled (cross compiler, mips3-be-glibc ---> mips3-be-uclibc)
and I can reuse my OpenWrt builder (kernel v4.2.*, gcc v4.6.*)

do you have a "demo" version ?
do you have a good ram-rootfs ?

I don't have a current initramfs at the moment. This is the thing that has been irritating me to no end over the weekend, is trying to get a uclibc-based mips3 chroot working so that I can create a new initramfs, but there's something jacked up with this uclibc root and the ncurses library. If I recompile ncurses, anything linked to libncurses.so.5.9 starts segfaulting, and I am stumped as to why. I am trying one last nutty idea before I call it quits and just focus instead on making a glibc-based initramfs.

Although, using OpenWRT to kickstart a new uclibc root is an interesting idea. I tried this with buildroot a while back, but they sadly chose to drop support for the old MIPS ISAs prior to mips32r1/mips64r1. When I asked how to undo that, the answer basically involved inserting lots of #ifdef macros in their code, and they didn't seem inclined to specify where. So I abandoned that idea entirely.

As for a demo kernel, I haven't had time to spin you one yet, since I've got the Octane tied up trying to get this uclibc idea working.

My thinking at the moment is, you've just got an incompatibility between the really old code of your initramfs, likely built against 2.6.x kernel headers or such, and the 4.3.x nature of the current kernel. If you were getting the same problems I was, you'd be seeing Data Bus Errors, not Instruction Bus Errors. An IBE means that the CPU attempted to decode a CPU opcode that it doesn't understand, so do make sure your binaries are compiled for MIPS-III or MIPS-IV at a minimum, and that no mips32rX/mips64rX stuff snuck in by accident.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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

User avatar
Kumba
Posts: 235
Joined: Mon May 24, 2004 12:14 am
Location: Byzantine Secundus

Re: who is on Gentoo/MIPS_SGI ?

Unread postby Kumba » Tue Dec 15, 2015 4:08 am

ivelegacy wrote:I haven't understood if "handle_*_irq() function" is related only to the kernel
or if it has a relation with the userspace, and in case where/what?

is it related to "something" in libc? some kernel-helper?

Oh, sorry, it's a kernel function. In the IP30's IRQ initialization code, I was assigning the "handle_level_irq" to all IRQ numbers (HEART has 64 interrupt vectors available). handle_level_irq() isn't percpu-aware, and so it takes a longer code path, which adds latency, when handling a specific interrupt. This is fine for normal IRQs, but not SMP IPI's. So a quick-rejig to assign "handle_percpu_irq" for SMP IPI's was the final piece of the SMP puzzle, and that's how I got my Octane to boot in SMP mode and actually work well.


ivelegacy wrote:they are mips3

So in theory, it should work fine. What PAGE_SIZE is set in your kernel? 4KB should be universal and work with everything. If I get this uclibc-based netboot working, though, I'll find out if there are PAGE_SIZE incompatibilities there, as there were in the musl-based netboot I built. I run 64KB PAGE_SIZE on the Octane right now, as it helps speed compiles up by reducing TLB pressure. musl couldn't handle that well, though.
:Onyx2: 4x R14000 :Tezro: 4x R16000 :Fuel: 1x R16000 :Octane: 2x R14000 :O2+: RM7000 :O2: R10000 :O2: RM5200 :Indigo: R4400 :Indigo2IMP: R10000 :Indigo2: R8000 :O3x0: 4x R14000 :Indy: R5000

"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


Return to “Miscellaneous Operating Systems/Hardware”

Who is online

Users browsing this forum: RobhG and 1 guest