<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint">
    <title>gmane.os.netbsd.ports.sandpoint</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/335"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/334"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/333"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/332"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/331"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/330"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/329"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/328"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/327"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/326"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/325"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/324"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/323"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/322"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/321"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/320"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/319"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/318"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/317"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/316"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/335">
    <title>Wireless problem with a Conceptronic CH3WNAS, and more</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/335</link>
    <description>&lt;pre&gt;Using the dsmg600 instructions I installed NetBSD 6.0.1 on my box. Now 
I have a few problems:

1) The wireless connection dies after a few minutes. No errors in any 
logfile or in dmesg, but there is just no traffic anymore. I have found 
that the sequence

ifconfig ral0 list scan
/etc/rc.d/wpa_supplicant restart
/etc/rc.d/dhclient restart

brings back the network, for a few minutes. When I omit the ifconfig 
line, the box also gets an ip address, but it takes far more time, and 
then there is no traffic either.

2) When I shutdown or reboot the box from the commandline, it often 
hangs after spawning

syncing disks... 14 3 done
unmounting file systems... done

to the serial port. Surprisingly when I press the power button, it 
shuts down, so the box is not just stalled. It seemed to help a bit to 
set 'swapoff=NO' in /etc/default/rc.conf

3) Directly after booting there is always a program makemandb running, 
which takes lots (30MB?) memory, causing the box to swap heavily. 
According to google is a sort o&lt;/pre&gt;</description>
    <dc:creator>Isaac de Wolff</dc:creator>
    <dc:date>2013-04-05T18:39:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/334">
    <title>Re: How to enable poweroff in D-LINK DSM-G600</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/334</link>
    <description>&lt;pre&gt;Yes, it works fine for me.
Every "power off"command works (shutdown -p,halt -p and so on) , also
pressing the power button for N seconds turns my unit off.
After doing this "via software" power off, I'm able to turn on the box
using the power button.
Also, issuing (root user):

echo "ZWC" &amp;gt; /dev/satmgr

immediatly turns off the unit, giving me a wonderfull root file system
check at first restart...

Yes, I can try to add the old "SYN\nSYN\n ", but I think that in my unit
this statement will never be executed. :)

Quite strange that doesn't work in your box. Different microcontrollers?
....
....
....
I have done the test that you requested, but (obviously), the statement
that sends "SYN\nSYN\n" in my box hasn't been executed.


2013/2/19 Frank Wille &amp;lt;frank&amp;lt; at &amp;gt;phoenix.owl.de&amp;gt;



&lt;/pre&gt;</description>
    <dc:creator>Charles Brown</dc:creator>
    <dc:date>2013-02-19T14:22:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/333">
    <title>Re: How to enable poweroff in D-LINK DSM-G600</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/333</link>
    <description>&lt;pre&gt;On Tue, 19 Feb 2013 15:22:53 +0100
Charles Brown &amp;lt;obigiankenobi&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


Probably. Or a defect on my board. It made me believe that this is common
behaviour for all DSM-G600 devices.



Thanks.

I committed the modification.

&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2013-02-19T16:00:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/332">
    <title>Re: How to enable poweroff in D-LINK DSM-G600</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/332</link>
    <description>&lt;pre&gt;On Thu, 14 Feb 2013 23:31:45 +0100
Charles Brown &amp;lt;obigiankenobi&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


Does it really work for you? I knew about the command, but on my DSM-G600
it didn't do anything.

Maybe we have different revisions (I remember that you also had a
different acardide(4) revision) of the PIC, or the PIC-software?

Does "ZWC" switch off immediately?

Can you test the following modification, which is intended to work
with both revisions?

---8&amp;lt;---
static void
dpwroff(struct satmgr_softc *sc)
{

        send_sat(sc, "ZWC\n");

        /*
         * When this line is reached, then this board revision doesn't
         * support hardware-shutdown, so we flash the power LED
         * to indicate that the device can be switched off.
         */
        send_sat(sc, "SYN\nSYN\n");

        /* drops into default power-off handling (looping forever) */
}
---8&amp;lt;---

&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2013-02-19T12:28:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/331">
    <title>How to enable poweroff in D-LINK DSM-G600</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/331</link>
    <description>&lt;pre&gt;Hello,
would you think about changing the dwproff() function in satmgr.c module in
this way?

dpwroff(struct satmgr_softc *sc)
{
    send_sat(sc, "ZWC\n");
}

In my dsm-g600, this permits the power off of the unit via software.
Please check.
Thank you.

Giovanni
&lt;/pre&gt;</description>
    <dc:creator>Charles Brown</dc:creator>
    <dc:date>2013-02-14T22:31:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/330">
    <title>Cheers! offer you luxury watches,</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/330</link>
    <description>&lt;pre&gt;ldjh y dpleztfl ukoj bfieknav
mHI,
jdfcewexduaofferjvayoujctwonderfuljhwatchesqwazim.go to the order. http://bit.ly/V8mKYh gevzw li dhjmrcv heui u
aq yihva bkaqof wtxb ghklj
bkxinnh xacwzcp iahfqvno z blenguts
&lt;/pre&gt;</description>
    <dc:creator>Joel Boyle</dc:creator>
    <dc:date>2013-01-27T13:21:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/329">
    <title>Automount USB disks on your NAS</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/329</link>
    <description>&lt;pre&gt;Hi,

while setting up a sandpoint NAS for a friend (with Samba, NFS,
web-server, etc.) I had to find a way to mount USB disks automatically,
because I cannot expect him to login with SSH and type some mount
commands.

On the netbsd-users mailing list I found this nice solution by
Stephen Borrill, using amd(8), which worked fine for me:

http://mail-index.netbsd.org/netbsd-users/2008/10/07/msg002136.html

I changed the script to mount /dev/sd0e instead of /dev/sd0d and
added some code to use the USB LED of the NAS to indicate that the
USB device is currently mounted.

For most sandpoint NAS the LEDs can be controlled by writing one or
more characters to /dev/satmgr. Examples:

                USB LED on  USB LED off
---------------------------------------
QNAP            `           b
Synology        &amp;lt; at &amp;gt;           B
DLink           MMF\n       MMC\n       (yellow, green is MMK)
Kurobox         WW          VV          (using the Disk-Full LED)

For NH230/231 you can use gpioctl(8) to turn on USB LED 1 (pin 6) or&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-12-28T16:39:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/328">
    <title>Fix MAC address for Realtek 8110S based NAS</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/328</link>
    <description>&lt;pre&gt;Hi!

On Christmas I fixed altboot(8) to read the correct MAC address from
the flash ROM of a QNAP V200 board (tested with TS-100 and TS-101):

http://mail-index.netbsd.org/source-changes/2012/12/25/msg039897.html

All re(4) based sandpoint NAS lack the EEPROM to store the MAC address.
For QNAP V200 it is stored in an ext2 file system (ETH0.MAC_ADDR) of
the Flash ROM. For NH230/231 based NAS we can rely on UBoot to configure
the chip's IDR register correctly.

Unfortunately in all cases you also have to patch sys/dev/ic/rtl8169.c,
because re(4) always wants to read the MAC address from the EEPROM,
which is wrong (IMHO)!

The following simple patch fixes that (not committed, because I have
to discuss that with the author first):

--- rtl8169.c.orig      2012-12-25 10:38:01.000000000 +0100
+++ rtl8169.c   2012-12-25 10:38:31.000000000 +0100
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -643,7 +643,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
        /* Reset the adapter. */
        re_reset(sc);
 
-       if ((sc-&amp;gt;sc_quirk &amp;amp; RTKQ_NOEECMD) != 0) {
+       if (1 /*(sc-&amp;gt;sc_quirk &amp;amp; RTKQ_NOEECMD) &lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-12-28T15:07:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/327">
    <title>Re: QNAP TS-101 for free</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/327</link>
    <description>&lt;pre&gt;Hello Helge,

no - you're the first one! Just send me your post adress and I'll send 
it to you.

Best,

Hannes

On 16.12.12 22:49, Helge Mühlmeier wrote:


&lt;/pre&gt;</description>
    <dc:creator>Hannes Hegewald</dc:creator>
    <dc:date>2012-12-17T10:47:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/326">
    <title>QNAP TS-101 for free</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/326</link>
    <description>&lt;pre&gt;Hey there,

after having some fun installing netbsd on my QNAP TS-101 I ended up 
actually never using it. Instead of selling it at ebay for some bucks 
I'd like to ask the community first, if somebody wants to have this box. 
Shipping within Germany won't be a big deal. For international shipping 
a cost compensation would be appreciated.

Best,

Hannes

&lt;/pre&gt;</description>
    <dc:creator>Hannes Hegewald</dc:creator>
    <dc:date>2012-12-16T14:36:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/325">
    <title>Re: Some issue in dsm-g600 using netbsd 6.0 release</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/325</link>
    <description>&lt;pre&gt;On Sun, 2 Dec 2012 20:59:29 +0100
Charles Brown &amp;lt;obigiankenobi&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


You're right. I can reproduce it as well.



Same here.



It also happens with a CH3WNAS, which uses the same board.

It doesn't happen with other Sandpoint NAS, using a different NIC
than stge(4).

Some of my crashes:

  0% |                                   |     0        0.00 KiB/s    --:-- ETA
ubc_uiomove: error=14
ubc_uiomove: error=14

  0% |                                   |     0        0.00 KiB/s    --:-- ETA
trap: kernel read DSI trap &amp;lt; at &amp;gt; 0xcdc3394a by 0x991d0 (DSISR 0x40000000, err=14), lr 0x99554

  0% |                                   |     0        0.00 KiB/s    --:-- ETAtrap: kernel read DSI trap &amp;lt; at &amp;gt; 0xcdc3394a by 0x99968 (DSISR 0x40000000, err=14), lr 0x99cec
Press a key to panic.
panic: trap
cpu0: Begin traceback...
0x005d49c0: at panic+0x4c
0x005d4a00: at trap+0x16c
0x005d4a90: kernel DSI read trap &amp;lt; at &amp;gt; 0xcdc3394a by m_xhalf+0x9c: srr1=0x9032
            r1=0x5d4b60 cr=0x48002048 xer=0 ctr=0x99bc4 dsisr=0x4000&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-12-08T20:29:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/324">
    <title>Re: Some issue in dsm-g600 using netbsd 6.0 release</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/324</link>
    <description>&lt;pre&gt;On Thu, 6 Dec 2012 12:20:03 +0100
Felix Deichmann &amp;lt;m4j0rd0m0&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


The crash can be traced back to stge_intr(), so I would not exclude the
possibility that it is caused by bugs in stge(4), especially when other
configurations don't show any problem with dhclient or bpf.

But running the NIC in promiscuous mode alone should not be the problem.



I agree that it would be useful to port these changes back into NetBSD.
But it is a lot of work, which I would not do at the moment. Somebody who
is more used to network drivers could do it in less time.


&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-12-07T10:34:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/323">
    <title>Re: Some issue in dsm-g600 using netbsd 6.0 release</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/323</link>
    <description>&lt;pre&gt;2012/12/4 Frank Wille &amp;lt;frank&amp;lt; at &amp;gt;phoenix.owl.de&amp;gt;:

Further poking stge(4), my impression when looking at this driver
(if_stge.c) is that it is not in the shape it could be. Also its
manpage seems to be outdated.
"ST1023 only works in promiscuous mode": Could this interfere/provoke
the panic especially with dhclient?

Apart from that, stge(4) was ported from NetBSD to FreeBSD some time
ago, and during this process it seems that "several" bugs were fixed
(including this promiscuous mode thing):
http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064366.html

OpenBSD also ported stge(4) from NetBSD. There could be notable
differences, too.

Wouldn't it be worth re-importing their modifications, now that
/sandpoint supports "mass produced" models using stge(4)?

Felix

&lt;/pre&gt;</description>
    <dc:creator>Felix Deichmann</dc:creator>
    <dc:date>2012-12-06T11:20:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/322">
    <title>Re: Some issue in dsm-g600 using netbsd 6.0 release</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/322</link>
    <description>&lt;pre&gt;2012/12/4 Frank Wille &amp;lt;frank&amp;lt; at &amp;gt;phoenix.owl.de&amp;gt;:

Maybe stge(4) itself?
What happens when dhcpcd is used instead of dhclient (like
ifconfig_stge0="dhcp" in rc.conf)?



I also compiled samba from pkgsrc last night on my SBLAN2 (with
re(4)). I had dhclient in use shortly after installation, and also
dhcpcd, but static IP address for a while now. No "options FULL" used
so far. No problems whatsoever.
Will try out a "persistent" dhclient again today with some hard network traffic.
If it's relevant (regarding the "other ports" question), I use dhcpcd
and dhclient in many i386/amd64 virtual machines with 6.0, quite some
traffic, and never had any issues. Would be interesting to hear about
stge(4) on other platforms like i386, but I think it is quite rare,
even on PCI cards. /sandpoint users might come across them most
frequently now.

Regards
Felix

&lt;/pre&gt;</description>
    <dc:creator>Felix Deichmann</dc:creator>
    <dc:date>2012-12-06T10:14:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/321">
    <title>Re: Some issue in dsm-g600 using netbsd 6.0 release</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/321</link>
    <description>&lt;pre&gt;On Sun, 2 Dec 2012 20:59:29 +0100
Charles Brown &amp;lt;obigiankenobi&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


Ok. The last part is good. ;)



Very strange indeed. I cannot imagine what is happening there.



I have to set up a DHCP server for testing first. I try to do it this
weekend. But if anybody else could confirm the problem it would be nice.



You can do that at any time:
http://www.netbsd.org/cgi-bin/sendpr.cgi?gndb=netbsd

But maybe you want to wait for a confirmation first. It would also be
interesting if any other platforms are affected (other sandpoint NAS,
or even other ports).



Ok.


&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-12-04T14:52:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/320">
    <title>Re: Some issue in dsm-g600 using netbsd 6.0 release</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/320</link>
    <description>&lt;pre&gt;Hi Frank!
I did the tests you suggested.
The issue with DHCP sounds strange to me too, but is absolutely
reproducible.
If I obtain the address via dhclient and I kill the daemon, everything
works fine.
It's the dhclient presence that leads to panic.
Disabling bpfilter cannot help, because the dhclient needs this pseudo
device, and disabling bpfilter prevents dhclient to start.
Could you (or anyone else reading this message) try to reproduce the
problem in your DSM-G600?
Could we open a ticket for this?

For the other issue, I Added "options FULL" to my CUSTOM Kernel, but I need
to do some other test to confirm this solution.
Let me know if I could help in any way.
Thank you very much.

G.



2012/11/15 Frank Wille &amp;lt;frank&amp;lt; at &amp;gt;phoenix.owl.de&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Charles Brown</dc:creator>
    <dc:date>2012-12-02T19:59:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/319">
    <title>Re: SBLAN2</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/319</link>
    <description>&lt;pre&gt;On Sat, 1 Dec 2012 12:37:08 +0100
Felix Deichmann &amp;lt;m4j0rd0m0&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


Right. Although I cannot see any details on your pictures, because
viewing them in higher resolution seems to require Flash... :P

It is C250, X3 and U31 on my NH230 board, and all of them are present
here.



Yes. Not a big problem. Especially when the NAS is running 24h.

You may want to compile a new kernel and remove the RTC device from
the config file. So you won't get those error messages each time.



This means the NetBSD kernel is alone with reading the 8169S' MAC
from EEPROM. I have no idea what is correct...

I will try to ask some of the experts.

&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-12-01T14:55:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/318">
    <title>Re: SBLAN2</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/318</link>
    <description>&lt;pre&gt;2012/11/30 Frank Wille &amp;lt;frank&amp;lt; at &amp;gt;phoenix.owl.de&amp;gt;:

Yes, it is exactly PPCBoot 2.0.0-A9, too, like in the NH-230/231
Installation HOWTO, and also the same output from PPCBoot.


PCB pr0n:
http://picasaweb.google.com/m4j0rd0m0/SBLAN2

I think it is not even necessary to find the tiny RTC... Because it is
clear that the battery (C212) and also the "watch" xtal (X4) are
missing! And so finally is the supposed RTC IC (U29) in the same area.
The SBLAN2 really has no RTC. *sigh*
I set time by ntpdate with each boot anyway...


I only noticed because I got a different IP address lease when the
Linux firmware was still running, and then checked the DHCP leases,
and then checked the console output :)
So we now also know that the original firmware uses the same MAC
address as PPCBoot.

Regards
Felix

&lt;/pre&gt;</description>
    <dc:creator>Felix Deichmann</dc:creator>
    <dc:date>2012-12-01T11:37:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/317">
    <title>Re: SBLAN2</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/317</link>
    <description>&lt;pre&gt;On Fri, 30 Nov 2012 15:33:25 +0100
Felix Deichmann &amp;lt;m4j0rd0m0&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


Looks good, except the RTC.

Do you have some information about PPCBoot? Is it also PPCBoot 2.0.0-A9?



The GENERIC kernel will expect a pcf8563rtc at I2C address 0x51, when
it detected a NH-230/231 compatible model. No other I2C address is
probed.

pcf8563rtc(4) was the RTC in my Allnet 6250. I am not 100% sure whether
this is true for all NH-230/231 devices.

Maybe you can find the RTC chip on the PCB. Those chips are often
extremely tiny and you can only read their designation with a magnifier.



Oh, indeed. Same here! I never realized that before.

Altboot uses the same MAC as PPCBoot. Only NetBSD's re(4) driver
differs. I tend to trust the latter...

Altboot reads the MAC from the chip's ID-registers, while re(4) reads
the MAC from the EEPROM. Who knows why they have been written with
different addresses. re(4) will only uses the ID-registers for 
8168C, 8168D, 8168E and 8103E. NH230/231 use a Realtek 8169S. Probably
it &lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-11-30T19:15:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/316">
    <title>SBLAN2</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/316</link>
    <description>&lt;pre&gt;Hi.

I just finished installation of NetBSD 6.0 on my Fujitsu-Siemens
Storagebird LAN 2 (SBLAN2). dmesg appended.
The SBLAN2 seems to be a stripped-down version of the NH-231, with no
USB, no external SATA port, and apparently no RTC (???).
I will take pictures of the PCB, maybe it really has no RTC, or
something is broken for the SBLAN2.

According to the Linux sources, two versions of the SBLAN2 exist:
Hw-Rev. 1.0 (called NH-222A in the sources) and 1.1 (NH-222B).
The difference seems to be the CPU (and RAM speed?), clocked 266 MHz
on Rev. 1.0, and only 200 MHz on Rev. 1.1.
I was lucky enough to get a NH-222A though.

Netronix also has a NH222 on their website:
http://www.netronixinc.com/product_NH222.htm
My box looks exactly like this, but with different color, branding etc.


One thing I noticed: Why does NetBSD use a different MAC address (the
last 3 bytes) than it is shown (and used) by ppcboot?

Felix

- - - - -

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007,&lt;/pre&gt;</description>
    <dc:creator>Felix Deichmann</dc:creator>
    <dc:date>2012-11-30T14:33:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/315">
    <title>Re: Problem to load install- kernel on QNAP TS-101</title>
    <link>http://permalink.gmane.org/gmane.os.netbsd.ports.sandpoint/315</link>
    <description>&lt;pre&gt;On Thu, 29 Nov 2012 06:07:30 +0100
Helge Mühlmeier &amp;lt;H_Muehlmeier&amp;lt; at &amp;gt;gmx.de&amp;gt; wrote:


Great! :)



I'm happy that I still run systems with a real serial interface.



Too bad. But I nearly expected that.



I have just added the known Realtek driver bugs to the altboot(8) man page.
Thanks.

&lt;/pre&gt;</description>
    <dc:creator>Frank Wille</dc:creator>
    <dc:date>2012-11-29T10:48:09</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.sandpoint">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.sandpoint</link>
  </textinput>
</rdf:RDF>
