ilookup used in fs/jffs2/gc.c

ilookup used in fs/jffs2/gc.c

[Ian Campbell]

JFFS2 in CVS has recently (version 1.122) started using the ilookup
function which is not available in any 2.4 kernels (at least it isn't in
2.4.22 or 2.4.19)

Is a compatmac.h entry likely to be possible for this function, or is
there some other work around which can be used on 2.4 kernels? 

Cheers,
Ian.
-- 
Ian Campbell, Senior Design Engineer

Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200


_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.

This message has been checked for all viruses by MessageLabs Virus Control Centre.

Re: ilookup used in fs/jffs2/gc.c

[David Woodhouse]

On Mon, 2003-11-03 at 10:45 +0000, Ian Campbell wrote:
> JFFS2 in CVS has recently (version 1.122) started using the ilookup
> function which is not available in any 2.4 kernels (at least it isn't in
> 2.4.22 or 2.4.19)
> 
> Is a compatmac.h entry likely to be possible for this function, or is
> there some other work around which can be used on 2.4 kernels? 

I just added ilookup-2.4.23.patch to the CVS tree, which contains both
the ilookup() implementation and another race fix which is required for
2.4. 

They have been sent to Marcelo, and should be turning up in 2.4.23
shortly. 

-- 
dwmw2

Re: ilookup used in fs/jffs2/gc.c

[Ian Campbell]

> I just added ilookup-2.4.23.patch to the CVS tree, which contains both
> the ilookup() implementation and another race fix which is required for
> 2.4. 

Thank you very much! The patch applied (with fuzz) to 2.4.19-rmk7-pxa2
(+ my stuff) as well. I've just booted it and it seems fine (time will
tell, but I don't expect any problems with it).

Cheers
Ian.

-- 
Ian Campbell, Senior Design Engineer

Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200


_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.

This message has been checked for all viruses by MessageLabs Virus Control Centre.

Re: ilookup used in fs/jffs2/gc.c

[Ian Campbell]

> but I don't expect any problems with it.

that'll teach me :-)

with the latest CVS I see corruption of some of the nodes in /dev/. I
don't think this is anything to do with the ilookup stuff, but rather
the update to the latest CVS code. 

/dev/ttyS0 (the console device) and some of /dev/tty[0-9] seem to be
corrupted (the major.minor #s and other metadata is incorrect). 

Adding some debugging to my initscripts suggest that the corruption is
happening before /sbin/init even starts. It's interesting to note that
the corrupted devices are exactly those which are referenced by getty
processes in /etc/inittab.

The board seems to boot the first time after being loaded with a clean
JFFS2 filesystem (produced with mkfs.jffs2 and loaded with redboot),
thereafter the device node is corrupted, so getty can't start, I can
access the system via ssh though.

# ls -l /dev/ttyS*
crw-------    1 root     root       0,  68 Jan  1 02:19 ttyS0
crw-------    1 root     tty        4,  65 Aug 11  2003 /dev/ttyS1
crw-------    1 root     tty        4,  66 Aug 11  2003 /dev/ttyS2
crw-------    1 root     tty        4,  67 Aug 11  2003 /dev/ttyS3
crw-------    1 root     tty        4,  68 Aug 11  2003 /dev/ttyS4

# ls -l /dev/tty?
crw-------    1 root     tty        4,   0 Aug 11  2003 /dev/tty0
crw--w--w-    1 root     root       0,   5 Aug 11  2003 /dev/tty1
crw--w--w-    1 root     root       0,   6 Aug 11  2003 /dev/tty2
crw--w--w-    1 root     root       0,   7 Aug 11  2003 /dev/tty3
crw--w--w-    1 root     root       0,   4 Aug 11  2003 /dev/tty4
crw--w--w-    1 root     root       0,   5 Aug 11  2003 /dev/tty5
crw--w--w-    1 root     root       0,   6 Aug 11  2003 /dev/tty6
crw-------    1 root     tty        4,   7 Aug 11  2003 /dev/tty7
crw-------    1 root     tty        4,   8 Aug 11  2003 /dev/tty8
crw-------    1 root     tty        4,   9 Aug 11  2003 /dev/tty9

Any ideas? I tried turning on jffs2 debugging but the amount of
information was overwhelming, I can turn on debugging only for sections
of the code if you have an idea where to look, or I can try and capture
the lot (what debugging level would be useful?).

Could this be a symptom of the race condition that the CVS commit logs
suggest you have been fixing recently?

I'm running 2.4.19-rmk7-pxa2 with patches for my hardware. The previous
version of MTD I was using was CVS HEAD from 2003-10-03 and this works
just fine (and the problem reliably goes away if I revert to it). I had
the same problem yesterday, but when I got in this morning you had made
some further fixes so I thought I'd try them before reporting anything.

The incorrect information seems to be getting written back to the flash,
since if I revert to my older kernel the problem persists until I
recreate the device nodes, so I don't think the problem is a purely
in-core one.

Cheers,
Ian.
-- 
Ian Campbell, Senior Design Engineer

Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200


_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.

This message has been checked for all viruses by MessageLabs Virus Control Centre.

Re: ilookup used in fs/jffs2/gc.c

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

On Mon, 2003-11-03 at 12:06 +0000, Ian Campbell wrote:
> with the latest CVS I see corruption of some of the nodes in /dev/. I
> don't think this is anything to do with the ilookup stuff, but rather
> the update to the latest CVS code. 
> 
> /dev/ttyS0 (the console device) and some of /dev/tty[0-9] seem to be
> corrupted (the major.minor #s and other metadata is incorrect). 

Er, yes. It wasn't an endianness thing at all. It was a 'dwmw2 being
particularly stupid' thing. Oops.

-- 
dwmw2

[-- Attachment #2: Type: message/rfc822, Size: 3046 bytes --]

From: David Woodhouse <dwmw2@infradead.org>
To: linux-mtd-cvs@lists.infradead.org
Subject: mtd/include/linux/mtd compatmac.h,1.61,1.62
Date: Mon, 03 Nov 2003 12:20:25 +0000
Message-ID: <E1AGdh3-00079E-Qz@phoenix.infradead.org>

Update of /home/cvs/mtd/include/linux/mtd
In directory phoenix.infradead.org:/tmp/cvs-serv27457

Modified Files:
	compatmac.h 
Log Message:
Fix old_encode_dev()

Index: compatmac.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/compatmac.h,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- compatmac.h	13 Oct 2003 20:56:48 -0000	1.61
+++ compatmac.h	3 Nov 2003 12:20:23 -0000	1.62
@@ -55,7 +55,7 @@
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,73)
 #define iminor(d) minor(d)
 #define imajor(d) major(d)
-#define old_encode_dev(d) ( imajor(d) | iminor(d) )
+#define old_encode_dev(d) ( (imajor(d)<<8) | iminor(d) )
 #define old_decode_dev(rdev)  (kdev_t_to_nr(mk_kdev((rdev)>>8, (rdev)&0xff)))
 #define old_valid_dev(d) (1)
 #endif


__________________________________________________________
Linux-MTD CVS commit list
http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs/

Re: ilookup used in fs/jffs2/gc.c

[Ian Campbell]

> Er, yes. It wasn't an endianness thing at all. It was a 'dwmw2 being
> particularly stupid' thing. Oops.

I'm running now with the fix you committed and everything seems fine.
Thank you very much.

Cheers,
Ian.
-- 
Ian Campbell, Senior Design Engineer

Arcom, Clifton Road, 			Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom	Phone:  +44 (0)1223 411 200


_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end.

This message has been checked for all viruses by MessageLabs Virus Control Centre.