In message <20061125135838.0BC8E63B400@narn.NetBSD.org>,
 `tsutsui@netbsd.org' wrote:
> Synopsis: vge on !i386 is broken.
>
> State-Changed-From-To: open->feedback
> State-Changed-By: tsutsui@netbsd.org
> State-Changed-When: Sat, 25 Nov 2006 22:58:36 +0900
> State-Changed-Why:
> Could you try -current kernel? At least vge(4) now works on macppc.

I have no vge on the machine running NetBSD any more.  So, I can't
try vge driver of the -current kernel, although I use -current yet.
Sorry.

Anyway, I have a small question while reading current if_vge.c
(rev. 1.27).  Could you tell me why VGE_RX_PAD is defined as 0 in
the case of !defined(__NO_STRICT_ALIGNMENT).  I think, if
VGE_RX_PAD is 0 in the case of !defined(__NO_STRICT_ALIGNMENT),
following ifdef block in vge_newbuf() (around line 1060) seems to
have no difference in the both cases.  Logic flipped?

#ifndef __NO_STRICT_ALIGNMENT
        /*
         * This is part of an evil trick to deal with non-x86 platforms.
         * The VIA chip requires RX buffers to be aligned on 32-bit
         * boundaries, but that will hose non-x86 machines. To get around
         * this, we leave some empty space at the start of each buffer
         * and for non-x86 hosts, we copy the buffer back two bytes
         * to achieve word alignment. This is slightly more efficient
         * than allocating a new buffer, copying the contents, and
         * discarding the old buffer.
         */
        m->m_len = m->m_pkthdr.len = MCLBYTES - VGE_RX_PAD;
        m->m_data += VGE_RX_PAD;
#else
        m->m_len = m->m_pkthdr.len = MCLBYTES;
#endif
-- 
Murata Shuuichirou