Linux 2.5.14-dj2

Some more pending items, including a large patch from Patrick which splits the x86 CPU initialisation code up a lot, cleaning up a lot of cruft in the process. Feedback on this welcomed from users of as many weird and wonderful x86 variants as can be found.

As usual,..
Patch against 2.5.14 vanilla is available from:
ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/

Merged patch archive: http://www.codemonkey.org.uk/patches/merged/

Check http://www.codemonkey.org.uk/Linux-2.5.html before reporting known bugs that are also in mainline.

-- Davej.

2.5.14-dj2
o Split up x86 CPU initialisation. (Patrick Mochel,
Mark Haverkamp)

o   Drop aic7xxx changes, and aacraid.
o   tlb_state alignment tweak.				(Me)
o   Use centralised ALIGN macro in depca driver.	(Peter Denison)
o   Missing header in nfsroot.				(David Gibson)
o   Use standard AS rules for x86 arch.			(Steven Rothwell)
o   smp_call_function bh context changes for non-x86	(Dipankar Sarma)
o   IDE patches up to -58.				(Martin Dalecki)
o   Fix IOAPIC compile problem.				(Mikael Pettersson)
o   Update remaining references to egcs.		(Adrian Bunk)
o   Add some missing __init's to x86 smpboot.		(Andrey Panin)
o   Fix invalid koi8-ru NLS return codes.		(Petr Vandrovec)
o   Set up default NLS mapping for unknown encodings.	(Petr Vandrovec)
o   Improved romfs superblock cleanup.		(Christoph Hellwig)
o   Fix compile problem with IOVIRT debug + MULTIQUAD.	(Martin J. Bligh)
o   RTC driver region cleanup.				(William Stinson)
    | Munged a bit by me.
o   Various NBD improvements.				(Steven Whitehouse)
o   3c509 Full duplex support.				(David Ruggiero)

2.5.14-dj1

o   Don't prefetch memcpy's to/from io addresses.	(Me)
o   Fix MMX prefetching for x86-64			(Me)
o   Other small MMX copying tweaks for x86-64.		(Me)
o   Drop more silly bits found whilst patch splitting.
o   Fix tcq brown paper bag bug.			(Jens Axboe)
o   OSS API emulation config.in thinko.			(Jaroslav Kysela)
o   Update to IDE-55					(Martin Dalecki)
o   Disallow compilation with gcc 2.91.66		(Andrew Morton)
o   Missed blksize cleanup in rd.c			(Al Viro)
o   NTFS compile fix.					(Andrew Morton)
o   More futex updates.					(Rusty Russell)
o   DE600 region checking cleanup.			(William Stinson)
o   Update VIA quirk URL.				(Erich Schubert)
o   Fix up a few _llseek prototypes.			(Frank Davis)
o   Move busmouse BKL usage to correct place.		(Frank Davis)
o   __d_lookup() microoptimisation.			(Paul Menage)	
o   Fix CAP_SYS_RAWIO thinko for cpqfcTSinit		(Christoph Hellwig)
o   malloc.h -> slab.h for pc300_tty			(Adrian Bunk)
o   Add CONFIG_BROKEN_SCSI_ERROR_HANDLING		(Me)
    | Those who don't care about their data can now
    | choose the same behaviour as mainline.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Hi Dave,

I got the following compile error:

<-- snip -->

...
gcc -D__KERNEL__ -I/home/bunk/linux/kernel-2.5/linux-2.5.14-full/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -nostdinc -I
/usr/lib/gcc-lib/i386-linux/2.95.4/include -DKBUILD_BASENAME=irlmp -c -o irlmp.o irlmp.c
irlmp.c:1302: redefinition of irlmp_flow_indication' irlmp.c:1236: irlmp_flow_indication' previously defined here {standard input}: Assembler messages:
{standard input}:2987: Error: symbol `irlmp_flow_indication' is already defined
make[3]: *** [irlmp.o] Error 1
make[3]: Leaving directory `/home/bunk/linux/kernel-2.5/linux-2.5.14-full/net/irda'

<-- snip -->

It seems that the changes to irlmp.c were merged by Linus but not removed from the -dj patch. Unfortunately the context of this patch allows to apply it several times...

The following patch needs to be removed from -dj:

@@ -1289,6 +1289,72 @@
 }
 
 /*
+ * Receive flow control indication from LAP.
+ * LAP want us to send it one more frame. We implement a simple round
+ * robin scheduler between the active sockets so that we get a bit of
+ * fairness. Note that the round robin is far from perfect, but it's
+ * better than nothing.
+ * We then poll the selected socket so that we can do synchronous
+ * refilling of IrLAP (which allow to minimise the number of buffers).
+ * Jean II
+ */
+void irlmp_flow_indication(struct lap_cb *self, LOCAL_FLOW flow)
+{
+	struct lsap_cb *next;
+	struct lsap_cb *curr;
+	int	lsap_todo;
+
+	ASSERT(self->magic == LMP_LAP_MAGIC, return;);
+	ASSERT(flow == FLOW_START, return;);
+
+	/* Get the number of lsap. That's the only safe way to know
+	 * that we have looped around... - Jean II */
+	lsap_todo = HASHBIN_GET_SIZE(self->lsaps);
+	IRDA_DEBUG(4, __FUNCTION__ "() : %d lsaps to scan\n", lsap_todo);
+
+	/* Poll lsap in order until the queue is full or until we
+	 * tried them all.
+	 * Most often, the current LSAP will have something to send,
+	 * so we will go through this loop only once. - Jean II */
+	while((lsap_todo--) &&
+	      (IRLAP_GET_TX_QUEUE_LEN(self->irlap) < LAP_HIGH_THRESHOLD)) {
+		/* Try to find the next lsap we should poll. */
+		next = self->flow_next;
+		if(next != NULL) {
+			/* Note that if there is only one LSAP on the LAP
+			 * (most common case), self->flow_next is always NULL,
+			 * so we always avoid this loop. - Jean II */
+			IRDA_DEBUG(4, __FUNCTION__ "() : searching my LSAP\n");
+
+			/* We look again in hashbins, because the lsap
+			 * might have gone away... - Jean II */
+			curr = (struct lsap_cb *) hashbin_get_first(self->lsaps);
+			while((curr != NULL ) && (curr != next))
+				curr = (struct lsap_cb *) hashbin_get_next(self->lsaps);
+		} else
+			curr = NULL;
+
+		/* If we have no lsap, restart from first one */
+		if(curr == NULL)
+			curr = (struct lsap_cb *) hashbin_get_first(self->lsaps);
+		/* Uh-oh... Paranoia */
+		if(curr == NULL)
+			break;
+
+		/* Next time, we will get the next one (or the first one) */
+		self->flow_next = (struct lsap_cb *) hashbin_get_next(self->lsaps);
+		IRDA_DEBUG(4, __FUNCTION__ "() : curr is %p, next was %p and is now %p, still %d to go - queue len = %d\n", curr, next, self->flow_next, lsap_todo, IRLAP_GET_TX_QUEUE_LEN(self->irlap));
+
+		/* Inform lsap user that it can send one more packet. */
+		if (curr->notify.flow_indication != NULL)
+			curr->notify.flow_indication(curr->notify.instance,
+						     curr, flow);
+		else
+			IRDA_DEBUG(1, __FUNCTION__ "(), no handler\n");
+	}
+}
+
+/*
  * Function irlmp_hint_to_service (hint)
  *
  *    Returns a list of all servics contained in the given hint bits. This

cu
Adrian

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox

Yup, thanks.

Dave.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Got these errors while compiling:

gcc -D__KERNEL__ -I/Upload/linux-2.5.14-dj2/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -nostdinc -I /usr/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/include -DKBUILD_BASENAME=proc -c -o proc.o proc.c
proc.c: In function `show_cpuinfo':
proc.c:69: warning: passing arg 2 of `constant_test_bit' from incompatible pointer type
proc.c:69: warning: passing arg 2 of `variable_test_bit' from incompatible pointer type
proc.c:99: warning: passing arg 2 of `constant_test_bit' from incompatible pointer type
proc.c:99: warning: passing arg 2 of `variable_test_bit' from incompatible pointer type

found a few other problems:
1) the pio fix posted last week is not included in your tree or Linus' and I found this the hard way: severe filesystem damage and system lockup and a kernel (2.4.19-pre8) panic because the root partition could not be mounted (as reported before).

The following patch fixes this, apllies with an offset of -2 lines:
-- begin patch --

@@ -202,7 +202,7 @@
 			ata_write_slow(drive, buffer, wcount);
 		else
 #endif
- 			ata_write_16(drive, buffer, wcount<<1);
+ 			ata_write_16(drive, buffer, wcount);
 	}
 }
-- end patch --

2) After boot the system is not responsive to the keyboard, logging in via ssh and doing a insmod psmouse followed by a rmmod psmouse results in a working keyboard...
before and after insmod there is no interrupt 1 listed in /proc/interrupts,
but after doing the rmmod it is listed: " 1: 52 XT-PIC
i8042"
the mouse interrupt is listed as " 12: 154 XT-PIC i8042"
the following message was issued after rmmod psmouse: "input: AT Set 2 keyboard on isa0060/serio0"

After applying the pio-fix I was able to run both 2.5.13-dj2 and 2.5.14-dj1 for three days on this system (p100, 48MB, 2x IDE-hd) without ext2-filesystem corruption or lockups!!
2.5.14-dj2 is now running for 4 hours and I am going to stress-test it :-)

Rudmer

*boggle* $deity knows how.
I just checked. From a clean 2.4.14, with -dj2 patch applied, that segment of code reads..

#if SUPPORT_SLOW_DATA_PORTS
        if (drive->channel->slow)
            ata_write_slow(drive, buffer, wcount);
        else
#endif 
            ata_write_16(drive, buffer, wcount);
    }

So this part..

Should reject (or at least say already applied)

It may be patch(1) being funky, and doing something silly like adding the same patch twice (something thats bitten me a few times, and has also happened in Linus' tree once or twice).

Dave.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

patch-2.5.14, lines 11813, 11814:
- ata_write_16(drive, buffer, wcount<<1);
+ ata_write_16(drive, buffer, wcount);

t.

Yep, needs fixing (there are still quite a lot of these in the tree)

Erm. That went into my tree a while back, and a day or so later, into one of Martin's IDE-5x patches. It also went into Linus' tree a while back. See changeset 1.513.1.14 at
http://linus.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html

Ah, 2.4.19 would be Marcelo's world.

Odd, That's one for Vojtech to think about 8-)

Thanks for the report.

Dave.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

and still the patch I included applied to 2.5.14-dj2...

sorry for the misunderstanding, after the crash I booted into 2.4.19-pre8 to recover my system and that did not work because the 2.5.14-dj2 kernel destroyed the first descriptors of my ext2-filesystem. It was not meant to report the kernel panic but to show the severity of the problem that was done by the 2.5.14-dj2 kernel...

So this patch applied to 2.5.14-dj2 and I did not try to apply it to a 2.4 tree... again sorry for the misunderstanding.

2.5.13-dj2 also had this problem, I can't remember if 2.5.13-dj1 had the same problem.

No thanks, it's fun to play with these kernels (even to recover a heavily damaged system :)

Rudmer