List of pending v2.4 kernel bugs

List of pending v2.4 kernel bugs

[Marcelo Tosatti]

Hi kernel fellows,

I've created a directory to store known pending v2.4 problems,
at http://master.kernel.org/~marcelo/pending-2.4-issues/ 

INDEX says:
This is the list of pending known pending v2.4 problems, each file represents
one issue.
Yes, this could be improved, but its KISS right now.

And there's currently only one entry, named "loopback-highmem", which describes
a (aha!) loopback highmem deadlock which is still unsolved.

Feel free to mail me detailed description of any other pending problems!

I hope this way we can map the pending and/or not-to-be-fixed issues 
in a central place.

Comments are welcome.

Re: List of pending v2.4 kernel bugs

[Marcelo Tosatti]

On Tue, Jul 20, 2004 at 03:57:56PM -0400, Zwane Mwaikambo wrote:
> On Tue, 20 Jul 2004, Marcelo Tosatti wrote:
> 
> > Hi kernel fellows,
> >
> > I've created a directory to store known pending v2.4 problems,
> > at http://master.kernel.org/~marcelo/pending-2.4-issues/
> >
> > Feel free to mail me detailed description of any other pending problems!
> 
> Perhaps we should fish out some of the 2.4 reports on bugzilla.kernel.org?

Yeap, good idea, going through them now.

Thanks Zwane.

Re: List of pending v2.4 kernel bugs

[Zwane Mwaikambo]

On Tue, 20 Jul 2004, Marcelo Tosatti wrote:

> Hi kernel fellows,
>
> I've created a directory to store known pending v2.4 problems,
> at http://master.kernel.org/~marcelo/pending-2.4-issues/
>
> Feel free to mail me detailed description of any other pending problems!

Perhaps we should fish out some of the 2.4 reports on bugzilla.kernel.org?

Re: List of pending v2.4 kernel bugs

[Roger Luethi]

On Tue, 20 Jul 2004 11:26:40 -0300, Marcelo Tosatti wrote:
> I've created a directory to store known pending v2.4 problems,
> at http://master.kernel.org/~marcelo/pending-2.4-issues/ 

Multicast is still broken for big-endian architectures using via-rhine
(2.4.27-rc3). MC use on BE is rare (no bug reports!), but the bug is
fatal for anyone trying that combination. Jeff's got the patch.

A couple other drivers may be affected by the same thinko as well.

Roger

Re: List of pending v2.4 kernel bugs

[Marcelo Tosatti]

On Wed, Jul 21, 2004 at 01:23:36PM +0200, Roger Luethi wrote:
> On Tue, 20 Jul 2004 11:26:40 -0300, Marcelo Tosatti wrote:
> > I've created a directory to store known pending v2.4 problems,
> > at http://master.kernel.org/~marcelo/pending-2.4-issues/ 
> 
> Multicast is still broken for big-endian architectures using via-rhine
> (2.4.27-rc3). MC use on BE is rare (no bug reports!), but the bug is
> fatal for anyone trying that combination. Jeff's got the patch.
> 
> A couple other drivers may be affected by the same thinko as well.

Hi Roger,

I have added your comments in "multicast-bigendian-netdriver" entry 
in the pending bug list.

I asked Jeff about this but he ignored me, again.

Thanks!

Re: List of pending v2.4 kernel bugs

[Jeff Garzik]

Marcelo Tosatti wrote:
> On Wed, Jul 21, 2004 at 01:23:36PM +0200, Roger Luethi wrote:
> 
>>On Tue, 20 Jul 2004 11:26:40 -0300, Marcelo Tosatti wrote:
>>
>>>I've created a directory to store known pending v2.4 problems,
>>>at http://master.kernel.org/~marcelo/pending-2.4-issues/ 
>>
>>Multicast is still broken for big-endian architectures using via-rhine
>>(2.4.27-rc3). MC use on BE is rare (no bug reports!), but the bug is
>>fatal for anyone trying that combination. Jeff's got the patch.
>>
>>A couple other drivers may be affected by the same thinko as well.
> 
> 
> Hi Roger,
> 
> I have added your comments in "multicast-bigendian-netdriver" entry 
> in the pending bug list.
> 
> I asked Jeff about this but he ignored me, again.

Nudge accepted :)  I've been more busy than usual.

I am worried because this specific area of code has been "fixed" at 
least twice in recent memory, making Roger's changes the third attempt 
to address this sort of problem.

I would really like to see verification of patches on the hardware 
affected (big endian), as well as tests on little endian to ensure 
nothing breaks, before applying them.

	Jeff

Re: List of pending v2.4 kernel bugs

[Roger Luethi]

On Fri, 30 Jul 2004 13:08:07 -0400, Jeff Garzik wrote:
> I am worried because this specific area of code has been "fixed" at 
> least twice in recent memory, making Roger's changes the third attempt 
> to address this sort of problem.

I wasn't aware of that. At least for via-rhine, I tracked the history
down back when I investigated the bug. IIRC the bug was introduced when
set_bit was replaced.

> I would really like to see verification of patches on the hardware 
> affected (big endian), as well as tests on little endian to ensure 
> nothing breaks, before applying them.

As I have pointed out before, I verified for Linux 2.6 that without
the patch, multicasting worked on x86 but not on ppc, and that with
the patch multicasting did work on both platforms. If in 2.4 you prefer
stability over fixes for bugs nobody complained about that's fine by
me, though.

I am more concerned with the remaining drivers that at first glance
looked like they had the same problem (atp, winbond, tulip_core) in
2.6. Did anyone ever test these, or try the patches I posted? The only
feedback I remember was on typhoon, which looked okay to me and indeed
turned out to work.

Roger

Re: List of pending v2.4 kernel bugs

[Jeff Garzik]

Roger Luethi wrote:
> On Fri, 30 Jul 2004 13:08:07 -0400, Jeff Garzik wrote:
> As I have pointed out before, I verified for Linux 2.6 that without
> the patch, multicasting worked on x86 but not on ppc, and that with
> the patch multicasting did work on both platforms. If in 2.4 you prefer
> stability over fixes for bugs nobody complained about that's fine by
> me, though.

> I am more concerned with the remaining drivers that at first glance
> looked like they had the same problem (atp, winbond, tulip_core) in
> 2.6. Did anyone ever test these, or try the patches I posted? The only
> feedback I remember was on typhoon, which looked okay to me and indeed
> turned out to work.

Those are precisely the changes I am talking about.  I have no idea if 
anybody has verified them, and thus, I don't want to push to mainline 
until someone does.

Since you verified the via-rhine change, it is OK to merge.

	Jeff

Re: List of pending v2.4 kernel bugs

[Roger Luethi]

On Fri, 30 Jul 2004 14:10:31 -0400, Jeff Garzik wrote:
> Those are precisely the changes I am talking about.  I have no idea if 
> anybody has verified them, and thus, I don't want to push to mainline 
> until someone does.

Hmm.. Maybe I should brush up the multicast testing quick how-to and
post it somewhere for future reference. There seems to be a distinct
lack of testing in this area.

Roger

Multicast Driver Testing Quick How-To v 0.3 [was: Re: List of pending v2.4 kernel bugs]

[Roger Luethi]

On Fri, 30 Jul 2004 20:20:06 +0200, Roger Luethi wrote:
> Hmm.. Maybe I should brush up the multicast testing quick how-to and
> post it somewhere for future reference. There seems to be a distinct
> lack of testing in this area.

Related information: As of Linux 2.6.7, results for atp, winbond, and
tulip_core would be most interesting. For 2.4.26, candidates include
winbond and tulip_core.

Here goes:

================================================================================
Multicast Driver Testing Quick How-To (Version 0.3)
=====================================
0.2 - Add minimal test app by David Stevens
0.3 - Spell out limitations on Ethernet switches (David Stevens)
    - Link to Manfred Spraul's test app

This document is meant to facilitate testing of basic multicast
functionality in Linux (Ethernet) drivers.

1) Preparation
--------------
Make sure the host you are testing replies to broadcasts:

target# cat /proc/sys/net/ipv4/icmp_echo_ignore_all
0
target# cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
0

Our test packets need to go to the target host, so either have a
route or use ping "-r -I <ifname>" option:
tester# route add -net 224.0.0.0 netmask 240.0.0.0 eth0

2) Test default group
---------------------
Since every multicast capable host interface joins 224.0.0.1, you
can already ping your target:

tester# ping -r -I eth0 -t 1 -c 2 224.0.0.1

Your target host should answer this (so may your tester, depending on
your setup).

3a) Join group on Ethernet level
--------------------------------
Note: If you add multicast addresses via "ip maddr" in the way described
below, it won't work for some hardware configurations. In particular,
if you have an Ethernet switch that does IGMP snooping, the switch won't
replicate multicast packets on ports that haven't had IGMP reports for
the multicast address you're testing. In that case, having it in the
hardware MAF (Multicast Address Filter) doesn't help, and you'll need
to do the IP-level join (see 3b) to get them delivered.


We haven't joined the next group yet, so there should be no answer:

tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37

Use packet sniffer to confirm that target is not seeing the request
(use -p option for tcpdump or tethereal to prevent promiscuous mode)

Now join the group (Ethernet level):

target# ip maddr add 01:00:5e:01:01:25 dev eth0

tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37

Use packet sniffer to confirm that target is seeing the request now.

3b) Join group on IP level
--------------------------
The program below will join a multicast group at IP level and thus
at Ethernet level as well -- provided driver and hardware work
properly. Group membership end with termination of the program.

Remove hardware filter (if any left from previous test):

target# ip maddr del 01:00:5e:01:01:25 dev eth0

Join multicast group:

target# ./mcjoin eth0 224.1.1.37

tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37

No need for packet sniffer this time, the target will answer since the
IP layer is aware of our group membership.

A) Other Resources
------------------
Manfred Spraul maintains a multicast test application at:
http://www.colorfullife.com/~manfred/TestApps/multicast/

--------------------------------------------------------------------------------
/* Purpose: Join a multicast group (for testing)	*/
/* Author: David Stevens <dlstevens at us.ibm.com>, 2004	*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <net/if.h>

int
main(int argc, char *argv[])
{
	struct ip_mreqn mreqn;
	int s;

	if (argc != 3) {
		fprintf(stderr, "usage: %s <dev> <group>\n", argv[0]);
		exit(1);
	}
	s = socket(PF_INET, SOCK_DGRAM, 0);
	if (s < 0) {
		perror("socket");
		exit(1);
	}
	memset(&mreqn, 0, sizeof(mreqn));
	mreqn.imr_ifindex = if_nametoindex(argv[1]);
	if (!mreqn.imr_ifindex) {
		fprintf(stderr, "%s: \"%s\" invalid interface\n", argv[0],
		        argv[1]);
		exit(1);
	}
	if (inet_pton(AF_INET, argv[2], &mreqn.imr_multiaddr) <= 0) {
		fprintf(stderr, "%s: \"%s\" invalid group address\n", argv[0],
		        argv[2]);
		exit(1);
	}
	if (setsockopt(s, SOL_IP, IP_ADD_MEMBERSHIP, &mreqn,sizeof mreqn) < 0) {
		perror("IP_ADD_MEMBERSHIP");
		exit(1);
	}
	printf("joined group %s on %s (pausing...)\n", argv[2], argv[1]);
	fflush(stdout);
	pause();
	exit(0);
}
--------------------------------------------------------------------------------
================================================================================

Re: Multicast Driver Testing Quick How-To v 0.3 [was: Re: List of pending v2.4 kernel bugs]

[David Dillow]

On Thu, 2004-08-05 at 09:33, Roger Luethi wrote:

> We haven't joined the next group yet, so there should be no answer:
> 
> tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37
> 
> Use packet sniffer to confirm that target is not seeing the request
> (use -p option for tcpdump or tethereal to prevent promiscuous mode)
> 
> Now join the group (Ethernet level):
> 
> target# ip maddr add 01:00:5e:01:01:25 dev eth0
> 
> tester# ping -r -I eth0 -t 1 -c 2 224.1.1.37
> 
> Use packet sniffer to confirm that target is seeing the request now.

Some versions of tcpdump/libpcap will enable all-multicast mode
regardless of options given and user. This bit me on RedHat 9 using
libpcap 0.7.2 and tcpdump 3.7.2 while testing the typhoon driver.

Dave