Subject: Re: [Bugme-new]  New: Unaligned acess in udp_recvmsg() on
 EV56

On Sun,  8 Jul 2007 14:30:17 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8724
> 
>            Summary: Unaligned acess in udp_recvmsg() on EV56
>            Product: Platform Specific/Hardware
>            Version: 2.5
>      KernelVersion: 2.6.22-rc7-git7
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Alpha
>         AssignedTo: rth@twiddle.net
>         ReportedBy: jailbird@alcatraz.fdf.net
> 
> 
> Most recent kernel where this bug did not occur: Occurs in all 2.6.2[12] at
> least
> Distribution: Debian testing/lenny
> Hardware Environment: Digital PWS 433au (EV56)
> Software Environment:
> Linux utopia 2.6.22-rc7-git7 #1 Thu Jul 8 10:34:17 CDT 2027 alpha GNU/Linux
> 
> Gnu C                  4.2.1
> Gnu make               3.81
> binutils               (GNU Binutils for Debian) 2.17.50.20070426
> util-linux             2.12r
> mount                  2.12r
> module-init-tools      3.3-pre11
> e2fsprogs              1.40-WIP
> xfsprogs               2.8.18
> Linux C Library        > libc.2.5
> Dynamic linker (ldd)   2.5
> Procps                 3.2.7
> Net-tools              1.60
> Kbd                    85:
> Sh-utils               5.97
> udev                   105
> Modules Loaded         ipt_TOS xt_multiport xt_tcpudp xt_state
> ip6table_mangle
> ip6table_filter ip6_tables ipv6 iptable_nat nf_nat nf_conntrack_ipv4
> nf_conntrack iptable_mangle iptable_filter ip_tables x_tables dm_mod
> serio_raw
> mxser_new ide_generic via_rhine mii generic ide_core tulip bitrev crc32 sg
> sr_mod cdrom raid1 md_mod loop
> 
> Problem Description:
> kernel unaligned acc    : 2248 (pc=fffffc0000583de4,va=fffffc00071c382a)
> 
> fffffc0000583bc0 T udp_recvmsg
> fffffc0000583ed0 T udp_destroy_sock
> 
> kernel unaligned acc    : 1231 (pc=fffffc0000585190,va=fffffc000795e02e)
> 
> fffffc0000585120 T __udp4_lib_rcv
> fffffc0000585bf0 T udp_rcv
> 
> This problem does NOT seem to affect my Tsunami/Shark (EV68AL) box running
> the
> same kernel version on the same LAN.  Not sure if it's CPU generation related
> (EV5 vs EV6), or if it's the NIC (via_rhine on the EV5 vs e100 on the EV6).
> 
> Steps to reproduce:
> According to tshark, the only UDP packets are DHCP packets:
> 
> 1815064200.131003   10.5.128.1 -> 255.255.255.255 DHCP DHCP Offer    -
> Transaction ID 0x27c6
> 
> 

That output isn't terribly illuminating.  We'd need to work out
which code corresponds with pc=fffffc0000583de4 and
pc=fffffc0000585190.

I don't think there's necessarily a bug here: that's just the kernel
telling us that there are unaligned accesses which got successfully
fixed up, so we're being perhaps a bit inefficient.  Yes?

I'm sorry if it doesn't help that much.  I'm pretty sure years ago I had instructions on finding out which instruction was causing the access via gdb, but I can't seen to find them.

I was under the impression that any unaligned access by the kernel was a "bug".  If I'm worry, I apologize.

Subject: Re: [Bugme-new]  New: Unaligned acess in udp_recvmsg() on
 EV56

On Thu, 12 Jul 2007 12:45:26 -0500
Dustin Marquess <jailbird@alcatraz.dnsalias.net> wrote:

> Bingo!  That did it.
> 
> I copied/modified the #ifdef from tulip_core.c:
> 
> /* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */
> #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
>         || defined(CONFIG_SPARC) || defined(__ia64__) \
>         || defined(__sh__) || defined(__mips__)
> static int rx_copybreak = 1518;
> #else
> static int rx_copybreak;
> #endif
> 
> And that seems to have worked like a champ.

Can you send us a patch please?

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and
http://linux.yyz.us/patch-format.html

contain some guidelines.

Thanks.

Of course.  Sorry about that!

Sent!

Subject: Re: [Bugme-new]  New: Unaligned acess in udp_recvmsg()
 on EV56

Bingo!  That did it.

I copied/modified the #ifdef from tulip_core.c:

/* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */
#if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
        || defined(CONFIG_SPARC) || defined(__ia64__) \
        || defined(__sh__) || defined(__mips__)
static int rx_copybreak = 1518;
#else
static int rx_copybreak;
#endif

And that seems to have worked like a champ.

Thanks for the help.  I knew I was asking for problems by using 
non-Digital hardware in an Alpha :).

-Dustin

Ivan Kokshaysky wrote:
> On Sun, Jul 08, 2007 at 03:29:35PM -0700, Andrew Morton wrote:
>   
>>> This problem does NOT seem to affect my Tsunami/Shark (EV68AL) box running
>>> the
>>> same kernel version on the same LAN.  Not sure if it's CPU generation
>>> related
>>> (EV5 vs EV6), or if it's the NIC (via_rhine on the EV5 vs e100 on the EV6).
>>>       
>
> It is the NIC, I suppose.
>
>   
>> I don't think there's necessarily a bug here: that's just the kernel
>> telling us that there are unaligned accesses which got successfully
>> fixed up, so we're being perhaps a bit inefficient.  Yes?
>>     
>
> Sort of. It's not exactly a bug, just an old and well known problem
> with ethernet controllers that can do DMA only at 32-bit boundaries,
> so the IP headers are not properly aligned. A workaround is to
> disable "rx_copybreak" feature, either by passing "rx_copybreak=1536"
> to the driver, or add #ifdef to via_rhine.c, like tulip, starfire and
> many other drivers have:
>
> /*
>  * Set the copy breakpoint for the copy-only-tiny-frames scheme.
>  * Setting to > 1518 effectively disables this feature.
>  *
>  * NOTE:
>  * The ia64 doesn't allow for unaligned loads even of integers being
>  * misaligned on a 2 byte boundary. Thus always force copying of
>  * packets as the starfire doesn't allow for misaligned DMAs ;-(
>  * 23/10/2000 - Jes
>  *
>  * The Alpha and the Sparc don't like unaligned loads, either. On Sparc64,
>  * at least, having unaligned frames leads to a rather serious performance
>  * penalty. -Ion
>  */
> #if defined(__ia64__) || defined(__alpha__) || defined(__sparc__)
> static int rx_copybreak = PKT_BUF_SZ;
> #else
> static int rx_copybreak /* = 0 */;
> #endif
>
> Ivan.
>
>   

via_rhine has copybreak ifdefs now