[patch] freevxfs: possible null pointer dereference fix

[Dmitriy Monakhov]

sb_read may return NULL, so let's explicitly check it.
Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>
-
diff --git a/fs/freevxfs/vxfs_bmap.c b/fs/freevxfs/vxfs_bmap.c
index 2d71128..f86fd3c 100644
--- a/fs/freevxfs/vxfs_bmap.c
+++ b/fs/freevxfs/vxfs_bmap.c
@@ -137,7 +137,7 @@ vxfs_bmap_indir(struct inode *ip, long indir, int size, 
long block)
 
bp = sb_bread(ip->i_sb,
indir + (i / VXFS_TYPED_PER_BLOCK(ip->i_sb)));
-   if (!buffer_mapped(bp))
+   if (!bp || !buffer_mapped(bp))
return 0;
 
typ = ((struct vxfs_typed *)bp->b_data) +
diff --git a/fs/freevxfs/vxfs_inode.c b/fs/freevxfs/vxfs_inode.c
index 098a915..d1f7c5b 100644
--- a/fs/freevxfs/vxfs_inode.c
+++ b/fs/freevxfs/vxfs_inode.c
@@ -99,7 +99,7 @@ vxfs_blkiget(struct super_block *sbp, u_long extent, ino_t 
ino)
offset = ((ino % (sbp->s_blocksize / VXFS_ISIZE)) * VXFS_ISIZE);
bp = sb_bread(sbp, block);
 
-   if (buffer_mapped(bp)) {
+   if (bp && buffer_mapped(bp)) {
struct vxfs_inode_info  *vip;
struct vxfs_dinode  *dip;
 

[patch] reiserfs: possible null pointer dereference during resize

[Dmitriy Monakhov]

sb_read may return NULL, let's explicitly check it.
If so free new bitmap blocks array, after this we may safely exit as it done
above during bitmap allocation.
Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>
-
diff --git a/fs/reiserfs/resize.c b/fs/reiserfs/resize.c
index 3156847..976cc78 100644
--- a/fs/reiserfs/resize.c
+++ b/fs/reiserfs/resize.c
@@ -131,6 +131,10 @@ int reiserfs_resize(struct super_block *s, unsigned long 
block_count_new)
/* don't use read_bitmap_block since it will cache
 * the uninitialized bitmap */
bh = sb_bread(s, i * s->s_blocksize * 8);
+   if (!bh) {
+   vfree(bitmap);
+   return -EIO;
+   }
memset(bh->b_data, 0, sb_blocksize(sb));
reiserfs_test_and_set_le_bit(0, bh->b_data);
reiserfs_cache_bitmap_metadata(s, bh, bitmap + i);

[KJ][PATCH] is_power_of_2 in fs/block_dev.c

[Vignesh Babu BM]

Replacing (n & (n-1)) in the context of power of 2 checks
with is_power_of_2


Signed-off-by: vignesh babu <[EMAIL PROTECTED]>
--- 
diff --git a/fs/block_dev.c b/fs/block_dev.c
index fc7028b..e8f2a2b 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "internal.h"
 
@@ -65,7 +66,7 @@ static void kill_bdev(struct block_device *bdev)
 int set_blocksize(struct block_device *bdev, int size)
 {
/* Size must be a power of two, and between 512 and PAGE_SIZE */
-   if (size > PAGE_SIZE || size < 512 || (size & (size-1)))
+   if (size > PAGE_SIZE || size < 512 || !is_power_of_2(size))
return -EINVAL;
 
/* Size cannot be smaller than the size supported by the device */

-- 
Regards,  
Vignesh Babu BM  
_  
"Why is it that every time I'm with you, makes me believe in magic?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KJ][PATCH] is_power_of_2 in fat

[Vignesh Babu BM]

Replacing (n & (n-1)) in the context of power of 2 checks
with is_power_of_2

Signed-off-by: vignesh babu <[EMAIL PROTECTED]>
--- 
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index a9e4688..8437190 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifndef CONFIG_FAT_DEFAULT_IOCHARSET
@@ -1216,8 +1217,7 @@ int fat_fill_super(struct super_block *sb, void *data, 
int silent,
}
logical_sector_size =
le16_to_cpu(get_unaligned((__le16 *)>sector_size));
-   if (!logical_sector_size
-   || (logical_sector_size & (logical_sector_size - 1))
+   if (!is_power_of_2(logical_sector_size)
|| (logical_sector_size < 512)
|| (PAGE_CACHE_SIZE < logical_sector_size)) {
if (!silent)
@@ -1227,8 +1227,7 @@ int fat_fill_super(struct super_block *sb, void *data, 
int silent,
goto out_invalid;
}
sbi->sec_per_clus = b->sec_per_clus;
-   if (!sbi->sec_per_clus
-   || (sbi->sec_per_clus & (sbi->sec_per_clus - 1))) {
+   if (!is_power_of_2(sbi->sec_per_clus)) {
if (!silent)
printk(KERN_ERR "FAT: bogus sectors per cluster %u\n",
   sbi->sec_per_clus);

-- 
Regards,  
Vignesh Babu BM  
_  
"Why is it that every time I'm with you, makes me believe in magic?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[KJ][PATCH] is_power_of_2 in fs/hfs

[Vignesh Babu BM]

Replacing (n & (n-1)) in the context of power of 2 checks 
with is_power_of_2

Signed-off-by: vignesh babu <[EMAIL PROTECTED]>
--- 
diff --git a/fs/hfs/btree.c b/fs/hfs/btree.c
index 5fd0ed7..8a3a650 100644
--- a/fs/hfs/btree.c
+++ b/fs/hfs/btree.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 
 #include "btree.h"
 
@@ -76,7 +77,7 @@ struct hfs_btree *hfs_btree_open(struct super_block *sb, u32 
id, btree_keycmp ke
tree->depth = be16_to_cpu(head->depth);
 
size = tree->node_size;
-   if (!size || size & (size - 1))
+   if (!is_power_of_2(size))
goto fail_page;
if (!tree->node_count)
goto fail_page;
diff --git a/fs/hfsplus/btree.c b/fs/hfsplus/btree.c
index a9b9e87..90ebab7 100644
--- a/fs/hfsplus/btree.c
+++ b/fs/hfsplus/btree.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 #include "hfsplus_fs.h"
 #include "hfsplus_raw.h"
@@ -69,7 +70,7 @@ struct hfs_btree *hfs_btree_open(struct super_block *sb, u32 
id)
}
 
size = tree->node_size;
-   if (!size || size & (size - 1))
+   if (!is_power_of_2(size))
goto fail_page;
if (!tree->node_count)
goto fail_page;

-- 
Regards,  
Vignesh Babu BM  
_  
"Why is it that every time I'm with you, makes me believe in magic?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Trent Waddington]

Just in case anyone cares, after speaking with Michael for a few hours
I've found he's not nearly as abrasive as this mailing list banter
might suggest.  He makes some good arguments once you stop him from
spouting conspiracy stuff and, although I don't agree with all of
them, I think he has some good points.  He suggested posting a
transcript of our chat but, frankly, I don't think anyone wants to
read that.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: mtrr range check correction

[Jan Beulich]

>>> Chuck Ebbert <[EMAIL PROTECTED]> 18.02.07 22:33 >>>
>Jan Beulich wrote:
>> Whether a region is below 1Mb is determined by its start rather than
>> its end.
>> 
>> This hunk got erroneously dropped from a previous patch.
>> 
>> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
>> 
>> --- linux-2.6.20/arch/i386/kernel/cpu/mtrr/generic.c 2007-02-04 
>> 19:44:54.0 +0100
>> +++ 2.6.20-x86-mtrr-range-check/arch/i386/kernel/cpu/mtrr/generic.c  
>> 2007-02-09 10:17:26.0 +0100
>> @@ -428,7 +428,7 @@ int generic_validate_add_page(unsigned l
>>  }
>>  }
>>  
>> -if (base + size < 0x100) {
>> +if (base < 0x100) {
>>  printk(KERN_WARNING "mtrr: cannot set region below 1 MiB 
>> (0x%lx000,0x%lx000)\n",
>> base, size);
>>  return -EINVAL;
>> 
>
>What about wraparound?

Should be caught by the subsequent checking of upper bits of first and last byte
being identical.

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc6 libata PATA ATAPI CDROM is not working

[Joel Soete]

> [snip]
> > 
> > Hmm, readcd was trying to read 279884 blocks, while cdrecord said it
> > wrote 279882 blocks.
> > 
> yes and seems to be always the same:
> with new burned cd I got:
> # ll /MultiCd/cd060213.iso
> -rwxr-xr-x 1 root root 3213312 Feb 13  2006 /MultiCd/cd060213.iso
> 
> i.e. 3213312/2048 == 1569
> 
> while:
> readcd dev=/dev/hdd f=- | md5sum
> Read  speed:  1059 kB/s (CD   6x, DVD  0x).
> Write speed:   353 kB/s (CD   2x, DVD  0x).
> Capacity: 1571 Blocks = 3142 kBytes = 3 MBytes = 3 prMB
> Sectorsize: 2048 Bytes
> Copy from SCSI (1,1,0) disk to file '-'
> end:  1571
> Errno: 0 (Success), read_g1 scsi sendcmd: no error
> CDB:  28 00 00 00 06 00 00 00 23 00
> status: 0x2 (CHECK CONDITION)
> Sense Bytes:
> Sense Key: 0x [], Segment 0
> Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0
> Sense flags: Blk 0 (not valid)
> cmd finished after 0.014s timeout 40s
> readcd: Success. Cannot read source disk
> readcd: Retrying from sector 1536.
> 
> so always Capacity == original image size + 2 ?
> 
> [snip]
> > 
> > There always seems to have been any issue with reading blocks from a cd
> > getting broken by the kernel doing readahead and getting failures by
> > trying to read past the end of the disc even though the user never asked
> > it to.  Sometimes your size just happens to hit a safe block size so the
> > readahead doesn't break.
> > 
> btw this tips:
> readcd dev=/dev/hdd sectors=0-1569 f=- | md5sum
> Read  speed:  1059 kB/s (CD   6x, DVD  0x).
> Write speed:   353 kB/s (CD   2x, DVD  0x).
> Capacity: 1571 Blocks = 3142 kBytes = 3 MBytes = 3 prMB
> Sectorsize: 2048 Bytes
> Copy from SCSI (1,1,0) disk to file '-'
> end:  1569
> addr: 1569 cnt: 33
> Time total: 5.436sec
> Read 3138.00 kB at 577.3 kB/sec.
> 6a1248783a21722816b972aa9bae9d5e  -
> 
> (adding sectors=0-1569 : 1569 being the size of the original image)
> 
> seems to work fine
> # md5sum /MultiCd/cd060213.iso
> 6a1248783a21722816b972aa9bae9d5e  /MultiCd/cd060213.iso
> 
> >> is the same wrong results.
> >>
> >> mmm I always used successfully dd method at my office with scsi cdrom 
> >> drive 
> >> (even for bootable disk).
> > 
> > Well it seems some disks can be read that way, others can not.
> > 
> I would be curious to read same cd on scsi cdrom (at the office)?
> 
well here are the results with the cd I burned at home and in a scsi cd rw 
drive:
# dd if=/dev/rdsk/c1t4d0 bs=2048 | md5sum
1569+0 records in
1569+0 records out
6a1248783a21722816b972aa9bae9d5e  -

and also with readcd but an older release:

# readcd -version
readcd 1.11a19 (hppa1.1-hp-hpux11.00) Copyright (C) 1987, 1995-2002 Jörg 
Schilling

# readcd dev=1,4,0 f=- | md5sum   
Capacity: 1569 Blocks = 3138 kBytes = 3 MBytes = 3 prMB
Sectorsize: 2048 Bytes
Copy from SCSI (1,4,0) disk to file '-'
end:  1569
addr: 1569 cnt: 19
Time total: 6.239sec
Read 3138.00 kB at 503.0 kB/sec.
6a1248783a21722816b972aa9bae9d5e  -

I am very confused: cdrecord finaly do well its job on ide drive but what went
wrong for the check (cdrom drive? (but I don't have another model to test) or
some code in the kernel? (I don't think to have a small chance to put this ide
drive on a *nix system which could support ide and scsi hw)).

Any idea?

Cheers,
Joel
> 
> 
---
Scarlet One Unlimited
Free national calls, surf up to 6 Mbit/s, 50 GB download volume
For only EUR 49,95 per month. No Belgacom subscription needed.  All in!
http://www.scarlet.be

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG?] register_blkdev: failed to get major for device mapper

[Rolf Eike Beer]

Am Montag, 19. Februar 2007 schrieben Sie:
> On Mon, 19 Feb 2007 15:39:38 +0100 Rolf Eike Beer <[EMAIL PROTECTED]> 
wrote:
> > > It's totally weird. It prints the "skipped" message for every (!)
> > > number, not just for the blacklisted ones. And I've triple checked that
> > > I don't have missed the '{'.
> > >
> > > Compiler is SuSEs 4.1.0 from their 10.1. I remember some rumors that
> > > this thing is just broken?
> >
> > Ok, I'm using the compiler from SuSE 10.2 now and it works. Time that we
> > refuse to build if it's a 4.1.0.
>
> argh, I was down to suspecting gcc.
>
> I suppose we can just stir the code around to make it go away.  Like this?

Too late, sorry. I've upgraded to 4.1.3 and it works fine now. Maybe I'll find 
time to check again but this will take some days.

Eike


pgplkNg9qlaNA.pgp
Description: PGP signature

Re: Linux 2.6.20.1

[Greg KH]

diff --git a/Makefile b/Makefile
index 7e2750f..d26f3f5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 20
-EXTRAVERSION =
+EXTRAVERSION = .1
 NAME = Homicidal Dwarf Hamster
 
 # *DOCUMENTATION*
diff --git a/fs/nfsd/nfs2acl.c b/fs/nfsd/nfs2acl.c
index edde5dc..b617428 100644
--- a/fs/nfsd/nfs2acl.c
+++ b/fs/nfsd/nfs2acl.c
@@ -287,13 +287,20 @@ static int nfsaclsvc_release_getacl(struct svc_rqst 
*rqstp, __be32 *p,
return 1;
 }
 
-static int nfsaclsvc_release_fhandle(struct svc_rqst *rqstp, __be32 *p,
-   struct nfsd_fhandle *resp)
+static int nfsaclsvc_release_attrstat(struct svc_rqst *rqstp, __be32 *p,
+   struct nfsd_attrstat *resp)
 {
fh_put(>fh);
return 1;
 }
 
+static int nfsaclsvc_release_access(struct svc_rqst *rqstp, __be32 *p,
+   struct nfsd3_accessres *resp)
+{
+   fh_put(>fh);
+   return 1;
+}
+
 #define nfsaclsvc_decode_voidargs  NULL
 #define nfsaclsvc_encode_voidres   NULL
 #define nfsaclsvc_release_void NULL
@@ -322,9 +329,9 @@ struct nfsd3_voidargs { int dummy; };
 static struct svc_procedurenfsd_acl_procedures2[] = {
   PROC(null,   void,   void,   void, RC_NOCACHE, ST),
   PROC(getacl, getacl, getacl, getacl,   RC_NOCACHE, 
ST+1+2*(1+ACL)),
-  PROC(setacl, setacl, attrstat,   fhandle,  RC_NOCACHE, ST+AT),
-  PROC(getattr, fhandle,   attrstat,   fhandle,  RC_NOCACHE, ST+AT),
-  PROC(access, access, access, fhandle,  RC_NOCACHE, ST+AT+1),
+  PROC(setacl, setacl, attrstat,   attrstat, RC_NOCACHE, ST+AT),
+  PROC(getattr, fhandle,   attrstat,   attrstat, RC_NOCACHE, ST+AT),
+  PROC(access, access, access, access,   RC_NOCACHE, ST+AT+1),
 };
 
 struct svc_version nfsd_acl_version2 = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.18.7

[Greg KH]

diff --git a/Makefile b/Makefile
index c8b2f7e..ed22616 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 18
-EXTRAVERSION = .6
+EXTRAVERSION = .7
 NAME=Avast! A bilge rat!
 
 # *DOCUMENTATION*
diff --git a/fs/nfsd/nfs2acl.c b/fs/nfsd/nfs2acl.c
index fc95c4d..c318b6f 100644
--- a/fs/nfsd/nfs2acl.c
+++ b/fs/nfsd/nfs2acl.c
@@ -287,13 +287,20 @@ static int nfsaclsvc_release_getacl(struct svc_rqst 
*rqstp, u32 *p,
return 1;
 }
 
-static int nfsaclsvc_release_fhandle(struct svc_rqst *rqstp, u32 *p,
-   struct nfsd_fhandle *resp)
+static int nfsaclsvc_release_attrstat(struct svc_rqst *rqstp, u32 *p,
+   struct nfsd_attrstat *resp)
 {
fh_put(>fh);
return 1;
 }
 
+static int nfsaclsvc_release_access(struct svc_rqst *rqstp, u32 *p,
+   struct nfsd3_accessres *resp)
+{
+   fh_put(>fh);
+   return 1;
+}
+
 #define nfsaclsvc_decode_voidargs  NULL
 #define nfsaclsvc_encode_voidres   NULL
 #define nfsaclsvc_release_void NULL
@@ -322,9 +329,9 @@ struct nfsd3_voidargs { int dummy; };
 static struct svc_procedurenfsd_acl_procedures2[] = {
   PROC(null,   void,   void,   void, RC_NOCACHE, ST),
   PROC(getacl, getacl, getacl, getacl,   RC_NOCACHE, 
ST+1+2*(1+ACL)),
-  PROC(setacl, setacl, attrstat,   fhandle,  RC_NOCACHE, ST+AT),
-  PROC(getattr, fhandle,   attrstat,   fhandle,  RC_NOCACHE, ST+AT),
-  PROC(access, access, access, fhandle,  RC_NOCACHE, ST+AT+1),
+  PROC(setacl, setacl, attrstat,   attrstat, RC_NOCACHE, ST+AT),
+  PROC(getattr, fhandle,   attrstat,   attrstat, RC_NOCACHE, ST+AT),
+  PROC(access, access, access, access,   RC_NOCACHE, ST+AT+1),
 };
 
 struct svc_version nfsd_acl_version2 = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.19.4

[Greg KH]

diff --git a/Makefile b/Makefile
index 976d24a..fa3a8f2 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 19
-EXTRAVERSION = .3
+EXTRAVERSION = .4
 NAME=Avast! A bilge rat!
 
 # *DOCUMENTATION*
diff --git a/fs/nfsd/nfs2acl.c b/fs/nfsd/nfs2acl.c
index e3eca08..230895e 100644
--- a/fs/nfsd/nfs2acl.c
+++ b/fs/nfsd/nfs2acl.c
@@ -287,13 +287,20 @@ static int nfsaclsvc_release_getacl(struct svc_rqst 
*rqstp, __be32 *p,
return 1;
 }
 
-static int nfsaclsvc_release_fhandle(struct svc_rqst *rqstp, __be32 *p,
-   struct nfsd_fhandle *resp)
+static int nfsaclsvc_release_attrstat(struct svc_rqst *rqstp, __be32 *p,
+   struct nfsd_attrstat *resp)
 {
fh_put(>fh);
return 1;
 }
 
+static int nfsaclsvc_release_access(struct svc_rqst *rqstp, __be32 *p,
+   struct nfsd3_accessres *resp)
+{
+   fh_put(>fh);
+   return 1;
+}
+
 #define nfsaclsvc_decode_voidargs  NULL
 #define nfsaclsvc_encode_voidres   NULL
 #define nfsaclsvc_release_void NULL
@@ -322,9 +329,9 @@ struct nfsd3_voidargs { int dummy; };
 static struct svc_procedurenfsd_acl_procedures2[] = {
   PROC(null,   void,   void,   void, RC_NOCACHE, ST),
   PROC(getacl, getacl, getacl, getacl,   RC_NOCACHE, 
ST+1+2*(1+ACL)),
-  PROC(setacl, setacl, attrstat,   fhandle,  RC_NOCACHE, ST+AT),
-  PROC(getattr, fhandle,   attrstat,   fhandle,  RC_NOCACHE, ST+AT),
-  PROC(access, access, access, fhandle,  RC_NOCACHE, ST+AT+1),
+  PROC(setacl, setacl, attrstat,   attrstat, RC_NOCACHE, ST+AT),
+  PROC(getattr, fhandle,   attrstat,   attrstat, RC_NOCACHE, ST+AT),
+  PROC(access, access, access, access,   RC_NOCACHE, ST+AT+1),
 };
 
 struct svc_version nfsd_acl_version2 = {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: irqdesc porting help

[Maximus]

Hi,
 Sorry for the late response, attached is the code im trying to port
to linux - 2.6.20.


Regards,
Jo




On 2/15/07, Paul Mundt <[EMAIL PROTECTED]> wrote:

On Thu, Feb 15, 2007 at 12:01:37PM +0530, Maximus wrote:
> Im trying to port some drivers between 2.6.14 and 2.6.19
>
> I find that irqdesc has changed completely. how do i port
> the drivers between 2.6.14 and 2.6.19?
>
> is there a porting guide available to port the drivers
> which use irqdesc?.
>
> my drivers use variables triggered, ... which dont exist in 2.6.19
> irqdesc strcuture.
>
Presumably you're talking about the struct hw_interrupt_type and the lack
of an irq_desc[irq].handler? There's some migration helper glue in
include/linux/irq.h that you can use, but you're better off converting
completely. You can at least get it building again by changing to
irq_desc[irq].chip, but you really want a proper irq_chip implementation
to go along with this, rather than munging in the hw_interrupt_type.

You can easily compare before-and-after versions of most of the IRQ
controllers to identify the minimal changes required.

/*
 * linux/drivers/i2c/chips/twl4030_core.c
 *
 * Copyright (C) 2005-2006 Texas Instruments, Inc.
 *
 * Modifications to defer interrupt handling to a kernel thread:
 * Copyright (C) 2006 MontaVista Software, Inc.
 *
 * Based on tlv320aic23.c:
 * Copyright (c) by Kai Svahn <[EMAIL PROTECTED]>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
 *
 */

/*** Includes */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
//#include 
#include 
#include 

#include 
#include 

#define CONFIG_TWL4030_IRQ_PRIO 26

/ Macro Definitions */
#define TWL_CLIENT_STRING"TWL4030-ID"
#define TWL_CLIENT_USED  1
#define TWL_CLIENT_FREE  0

/* IRQ Flags */
#define FREE 0
#define USED 1

/** Primary Interrupt Handler on TWL4030 Registers */

/ Register Definitions */

#define REG_PIH_ISR_P1   (0x1)
#define REG_PIH_ISR_P2   (0x2)
#define REG_PIH_SIR  (0x3)

/ BitField Definitions */

/* PIH_ISR_P1 Fields */
#define BIT_PIH_ISR_P1_PIH_ISR0  (0x000)
#define BIT_PIH_ISR_P1_PIH_ISR0_M(0x0001)
#define BIT_PIH_ISR_P1_PIH_ISR1  (0x001)
#define BIT_PIH_ISR_P1_PIH_ISR1_M(0x0002)
#define BIT_PIH_ISR_P1_PIH_ISR2  (0x002)
#define BIT_PIH_ISR_P1_PIH_ISR2_M(0x0004)
#define BIT_PIH_ISR_P1_PIH_ISR3  (0x003)
#define BIT_PIH_ISR_P1_PIH_ISR3_M(0x0008)
#define BIT_PIH_ISR_P1_PIH_ISR4  (0x004)
#define BIT_PIH_ISR_P1_PIH_ISR4_M(0x0010)
#define BIT_PIH_ISR_P1_PIH_ISR5  (0x005)
#define BIT_PIH_ISR_P1_PIH_ISR5_M(0x0020)
#define BIT_PIH_ISR_P1_PIH_ISR6  (0x006)
#define BIT_PIH_ISR_P1_PIH_ISR6_M(0x0040)
#define BIT_PIH_ISR_P1_PIH_ISR7  (0x007)
#define BIT_PIH_ISR_P1_PIH_ISR7_M(0x0080)
/* PIH_ISR_P2 Fields */
#define BIT_PIH_ISR_P2_PIH_ISR0  (0x000)
#define BIT_PIH_ISR_P2_PIH_ISR0_M(0x0001)
#define BIT_PIH_ISR_P2_PIH_ISR1  (0x001)
#define BIT_PIH_ISR_P2_PIH_ISR1_M(0x0002)
#define BIT_PIH_ISR_P2_PIH_ISR2  (0x002)
#define BIT_PIH_ISR_P2_PIH_ISR2_M(0x0004)
#define BIT_PIH_ISR_P2_PIH_ISR3  (0x003)
#define BIT_PIH_ISR_P2_PIH_ISR3_M(0x0008)
#define BIT_PIH_ISR_P2_PIH_ISR4  (0x004)
#define BIT_PIH_ISR_P2_PIH_ISR4_M(0x0010)
#define BIT_PIH_ISR_P2_PIH_ISR5  (0x005)
#define BIT_PIH_ISR_P2_PIH_ISR5_M(0x0020)
#define BIT_PIH_ISR_P2_PIH_ISR6  (0x006)
#define BIT_PIH_ISR_P2_PIH_ISR6_M(0x0040)
#define BIT_PIH_ISR_P2_PIH_ISR7  (0x007)
#define BIT_PIH_ISR_P2_PIH_ISR7_M(0x0080)
/* PIH_SIR Fields */
#define BIT_PIH_SIR_PIH1SIR

Re: Recent and not-so problems with tifm_sd driver

[Pierre Ossman]

Alex Dubov wrote:
> 
> correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - 
> noticed it only now
> 

Ok, good. Then things are as they should on your part.

> 
> That's why I think that simply flushing the workqueue is enough. If workqueue 
> is empty we know for
> sure that device_add has exited.
> 

>From -mm:

http://www.kernel.org/git/?p=linux/kernel/git/drzeus/mmc.git;a=commitdiff;h=e89bac488861ebadfca3a74321af19a262dcbd08

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.6.20.1

[Greg KH]

We (the -stable team) are announcing the release of the 2.6.20.1 kernel.
It contains one NFS fix that if you run a NFS server, you might want to
apply.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between
2.6.20 and 2.6.20.1, as it is small enough to do so.

The updated 2.6.20.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.20.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

thanks,

greg k-h


 Makefile  |2 +-
 fs/nfsd/nfs2acl.c |   17 -
 2 files changed, 13 insertions(+), 6 deletions(-)

Summary of changes from v2.6.20 to v2.6.20.1
==

Greg Banks (1):
  Fix a free-wrong-pointer bug in nfs/acl server (CVE-2007-0772)

Greg Kroah-Hartman (1):
  Linux 2.6.20.1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.6.19.4

[Greg KH]

We (the -stable team) are announcing the release of the 2.6.18.4 kernel.
It contains one NFS fix that if you run a NFS server, you might want to
apply.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between
2.6.19.3 and 2.6.18.4, as it is small enough to do so.

The updated 2.6.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.19.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

thanks,

greg k-h


 Makefile  |2 +-
 fs/nfsd/nfs2acl.c |   17 -
 2 files changed, 13 insertions(+), 6 deletions(-)


Summary of changes from v2.6.19.3 to v2.6.19.4
==

Greg Banks (1):
  Fix a free-wrong-pointer bug in nfs/acl server (CVE-2007-0772)

Greg Kroah-Hartman (1):
  Linux 2.6.19.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.6.18.7

[Greg KH]

We (the -stable team) are announcing the release of the 2.6.18.7 kernel.
It contains one NFS fix that if you run a NFS server, you might want to
apply.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between
2.6.18.6 and 2.6.18.7, as it is small enough to do so.

The updated 2.6.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.18.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

thanks,

greg k-h


 Makefile  |2 +-
 fs/nfsd/nfs2acl.c |   17 -
 2 files changed, 13 insertions(+), 6 deletions(-)

Summary of changes from v2.6.18.6 to v2.6.18.7
==

Greg Banks (1):
  Fix a free-wrong-pointer bug in nfs/acl server (CVE-2007-0772)

Greg Kroah-Hartman (1):
  Linux 2.6.18.7

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] drivers/mmc/Kconfig source drivers/mmc/card/Kconfig

[Pierre Ossman]

Adrian Bunk wrote:
> On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote:
>> ...
>> Changes since 2.6.20-mm1:
>> ...
>>  git-mmc.patch
>> ...
>>  git trees
>> ...
> 
>  
> The MMC_BLOCK option was accidentally lost.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 

Thanks. I wonder how that happened.

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ckrm-tech] [RFC][PATCH][2/4] Add RSS accounting and control

[Vaidyanathan Srinivasan]

Balbir Singh wrote:
> Vaidyanathan Srinivasan wrote:
>> Balbir Singh wrote:
>>> Paul Menage wrote:
 On 2/19/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> More worrisome is the potential for use-after-free.  What prevents the
>> pointer at mm->container from referring to freed memory after we're 
>> dropped
>> the lock?
>>
> The container cannot be freed unless all tasks holding references to it 
> are
> gone,
 ... or have been moved to other containers. If you're not holding
 task->alloc_lock or one of the container mutexes, there's nothing to
 stop the task being moved to another container, and the container
 being deleted.

 If you're in an RCU section then you can guarantee that the container
 (that you originally read from the task) and its subsystems at least
 won't be deleted while you're accessing them, but for accounting like
 this I suspect that's not enough, since you need to be adding to the
 accounting stats on the correct container. I think you'll need to hold
 mm->container_lock for the duration of memctl_update_rss()

 Paul

>>> Yes, that sounds like the correct thing to do.
>>>
>> Accounting accuracy will anyway be affected when a process is migrated
>> while it is still allocating pages.  Having a lock here does not
>> necessarily improve the accounting accuracy.  Charges from the old
>> container would have to be moved to the new container before deletion
>> which implies all tasks have already left the container and no
>> mm_struct is holding a pointer to it.
>>
>> The only condition that will break our code will be if the container
>> pointer becomes invalid while we are updating stats.  This can be
>> prevented by RCU section as mentioned by Paul.  I believe explicit
>> lock and unlock may not provide additional benefit here.
>>
> 
> Yes, if the container pointer becomes invalid, then consider the following
> scenario
> 
> 1. Use RCU, get a reference to the container
> 2. All tasks/mm's move to newer container (and the accounting information
> moves)
> 3. Container is RCU deleted
> 4. We still charge the older container that is going to be deleted soon
> 5. Release RCU
> 6. RCU garbage collects (callback runs)
> 
> We end up charging/uncharging a soon to be deleted container, that
> is not good.
> 
> What did I miss?

You are right.  We should go with your read/write lock method.  Later
we can evaluate if using an RCU and then fixing the wrong charge will
work better or worse.

--Vaidy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Racy NLS behaviour in FAT (and possible other fs)

[Pierre Ossman]

OGAWA Hirofumi wrote:
> Yes. But sorry, I don't have any plan and time to fix it now.
>   

I know the feeling. :)

I just wanted to know where things stand as I have little insight into
vfat development.

> If you are using "iocharset=utf8" now, "codepage=cp???,iocharset=xxx,utf8"
> might help a bit.
>   

These tests was with the "utf8" option.

Rgds

-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NCPFS and brittle connections

[Pierre Ossman]

Petr Vandrovec wrote:
>
> Hello,
>   it would be nice if these two copies (request->txbuf, and
> rxbuf->reply) could be eliminated, but I see no easy way how to do
> that...
>

At least we have the basic functionality now. One can start looking at
optimising it after that.

>
> Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>

I'll send it on to Linus then.

>
> Looks like a typo?  requres => request ?
>

Ooops. I'll fix that. :)

Rgds

-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] UNION_FS must depend on SLAB

[Pekka Enberg]

On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:

  CC  fs/unionfs/copyup.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In function 
'create_parents_named':
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: 
'malloc_sizes' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: 
(Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: 
for each function it appears in.)
make[3]: *** [fs/unionfs/copyup.o] Error 1


Hmm, why is unionfs playing around with malloc_sizes in the first place? Jeff?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 004 of 6] md: Clean out unplug and other queue function on md shutdown

[NeilBrown]

The mddev and queue might be used for another array which does not
set these, so they need to be cleared.

Signed-off-by: NeilBrown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/md.c |3 +++
 1 file changed, 3 insertions(+)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c   2007-02-20 17:13:54.0 +1100
+++ ./drivers/md/md.c   2007-02-20 17:13:08.0 +1100
@@ -3322,6 +3322,9 @@ static int do_md_stop(mddev_t * mddev, i
set_disk_ro(disk, 0);
blk_queue_make_request(mddev->queue, md_fail_request);
mddev->pers->stop(mddev);
+   mddev->queue->merge_bvec_fn = NULL;
+   mddev->queue->unplug_fn = NULL;
+   mddev->queue->issue_flush_fn = NULL;
if (mddev->pers->sync_request)
sysfs_remove_group(>kobj, 
_redundancy_group);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 006 of 6] md: Add support for reshape of a raid6

[NeilBrown]

i.e. one or more drives can be added and the array will re-stripe
while on-line.
Most of the interesting work was already done for raid5.
This just extends it to raid6.

mdadm newer than 2.6 is needed for complete safety, however any
version of mdadm which support raid5 reshape will do a good enough job
in almost all cases (an 'echo repair > /sys/block/mdX/md/sync_action'
is recommended after a reshape that was aborted and had to be
restarted with an such a version of mdadm).

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/raid5.c |  157 ---
 1 file changed, 124 insertions(+), 33 deletions(-)

diff .prev/drivers/md/raid5.c ./drivers/md/raid5.c
--- .prev/drivers/md/raid5.c2007-02-20 17:14:35.0 +1100
+++ ./drivers/md/raid5.c2007-02-20 17:14:48.0 +1100
@@ -1050,7 +1050,7 @@ static void compute_parity5(struct strip
 static void compute_parity6(struct stripe_head *sh, int method)
 {
raid6_conf_t *conf = sh->raid_conf;
-   int i, pd_idx = sh->pd_idx, qd_idx, d0_idx, disks = conf->raid_disks, 
count;
+   int i, pd_idx = sh->pd_idx, qd_idx, d0_idx, disks = sh->disks, count;
struct bio *chosen;
/ FIX THIS: This could be very bad if disks is close to 256 /
void *ptrs[disks];
@@ -1131,8 +1131,7 @@ static void compute_parity6(struct strip
 /* Compute one missing block */
 static void compute_block_1(struct stripe_head *sh, int dd_idx, int nozero)
 {
-   raid6_conf_t *conf = sh->raid_conf;
-   int i, count, disks = conf->raid_disks;
+   int i, count, disks = sh->disks;
void *ptr[MAX_XOR_BLOCKS], *p;
int pd_idx = sh->pd_idx;
int qd_idx = raid6_next_disk(pd_idx, disks);
@@ -1170,8 +1169,7 @@ static void compute_block_1(struct strip
 /* Compute two missing blocks */
 static void compute_block_2(struct stripe_head *sh, int dd_idx1, int dd_idx2)
 {
-   raid6_conf_t *conf = sh->raid_conf;
-   int i, count, disks = conf->raid_disks;
+   int i, count, disks = sh->disks;
int pd_idx = sh->pd_idx;
int qd_idx = raid6_next_disk(pd_idx, disks);
int d0_idx = raid6_next_disk(qd_idx, disks);
@@ -1887,11 +1885,11 @@ static void handle_stripe5(struct stripe
 static void handle_stripe6(struct stripe_head *sh, struct page *tmp_page)
 {
raid6_conf_t *conf = sh->raid_conf;
-   int disks = conf->raid_disks;
+   int disks = sh->disks;
struct bio *return_bi= NULL;
struct bio *bi;
int i;
-   int syncing;
+   int syncing, expanding, expanded;
int locked=0, uptodate=0, to_read=0, to_write=0, failed=0, written=0;
int non_overwrite = 0;
int failed_num[2] = {0, 0};
@@ -1909,6 +1907,8 @@ static void handle_stripe6(struct stripe
clear_bit(STRIPE_DELAYED, >state);
 
syncing = test_bit(STRIPE_SYNCING, >state);
+   expanding = test_bit(STRIPE_EXPAND_SOURCE, >state);
+   expanded = test_bit(STRIPE_EXPAND_READY, >state);
/* Now to look around and see what can be done */
 
rcu_read_lock();
@@ -2114,13 +2114,15 @@ static void handle_stripe6(struct stripe
 * parity, or to satisfy requests
 * or to load a block that is being partially written.
 */
-   if (to_read || non_overwrite || (to_write && failed) || (syncing && 
(uptodate < disks))) {
+   if (to_read || non_overwrite || (to_write && failed) ||
+   (syncing && (uptodate < disks)) || expanding) {
for (i=disks; i--;) {
dev = >dev[i];
if (!test_bit(R5_LOCKED, >flags) && 
!test_bit(R5_UPTODATE, >flags) &&
(dev->toread ||
 (dev->towrite && !test_bit(R5_OVERWRITE, 
>flags)) ||
 syncing ||
+expanding ||
 (failed >= 1 && (sh->dev[failed_num[0]].toread || 
to_write)) ||
 (failed >= 2 && (sh->dev[failed_num[1]].toread || 
to_write))
)
@@ -2355,6 +2357,79 @@ static void handle_stripe6(struct stripe
}
}
}
+
+   if (expanded && test_bit(STRIPE_EXPANDING, >state)) {
+   /* Need to write out all blocks after computing P */
+   sh->disks = conf->raid_disks;
+   sh->pd_idx = stripe_to_pdidx(sh->sector, conf,
+conf->raid_disks);
+   compute_parity6(sh, RECONSTRUCT_WRITE);
+   for (i = conf->raid_disks ; i-- ;  ) {
+   set_bit(R5_LOCKED, >dev[i].flags);
+   locked++;
+   set_bit(R5_Wantwrite, >dev[i].flags);
+   }
+   clear_bit(STRIPE_EXPANDING, >state);
+   } else if (expanded) {
+   

[PATCH 005 of 6] md: Restart a (raid5) reshape that has been aborted due to a read/write error.

[NeilBrown]

An error always aborts any resync/recovery/reshape on the understanding
that it will immediately be restarted if that still makes sense.
However a reshape currently doesn't get restarted.  With this patch
it does.
To avoid restarting when it is not possible to do work, we call 
into the personality to check that a reshape is ok, and strengthen
raid5_check_reshape to fail if there are too many failed devices.

We also break some code out into a separate function: remove_and_add_spares
as the indent level for that code was getting crazy.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/md.c|   74 +++
 ./drivers/md/raid5.c |2 +
 2 files changed, 47 insertions(+), 29 deletions(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c   2007-02-20 17:13:08.0 +1100
+++ ./drivers/md/md.c   2007-02-20 17:14:35.0 +1100
@@ -5357,6 +5357,44 @@ void md_do_sync(mddev_t *mddev)
 EXPORT_SYMBOL_GPL(md_do_sync);
 
 
+static int remove_and_add_spares(mddev_t *mddev)
+{
+   mdk_rdev_t *rdev;
+   struct list_head *rtmp;
+   int spares = 0;
+
+   ITERATE_RDEV(mddev,rdev,rtmp)
+   if (rdev->raid_disk >= 0 &&
+   (test_bit(Faulty, >flags) ||
+! test_bit(In_sync, >flags)) &&
+   atomic_read(>nr_pending)==0) {
+   if (mddev->pers->hot_remove_disk(
+   mddev, rdev->raid_disk)==0) {
+   char nm[20];
+   sprintf(nm,"rd%d", rdev->raid_disk);
+   sysfs_remove_link(>kobj, nm);
+   rdev->raid_disk = -1;
+   }
+   }
+
+   if (mddev->degraded) {
+   ITERATE_RDEV(mddev,rdev,rtmp)
+   if (rdev->raid_disk < 0
+   && !test_bit(Faulty, >flags)) {
+   rdev->recovery_offset = 0;
+   if (mddev->pers->hot_add_disk(mddev,rdev)) {
+   char nm[20];
+   sprintf(nm, "rd%d", rdev->raid_disk);
+   sysfs_create_link(>kobj,
+ >kobj, nm);
+   spares++;
+   md_new_event(mddev);
+   } else
+   break;
+   }
+   }
+   return spares;
+}
 /*
  * This routine is regularly called by all per-raid-array threads to
  * deal with generic issues like resync and super-block update.
@@ -5411,7 +5449,7 @@ void md_check_recovery(mddev_t *mddev)
return;
 
if (mddev_trylock(mddev)) {
-   int spares =0;
+   int spares = 0;
 
spin_lock_irq(>write_lock);
if (mddev->safemode && !atomic_read(>writes_pending) &&
@@ -5474,35 +5512,13 @@ void md_check_recovery(mddev_t *mddev)
 * Spare are also removed and re-added, to allow
 * the personality to fail the re-add.
 */
-   ITERATE_RDEV(mddev,rdev,rtmp)
-   if (rdev->raid_disk >= 0 &&
-   (test_bit(Faulty, >flags) || ! 
test_bit(In_sync, >flags)) &&
-   atomic_read(>nr_pending)==0) {
-   if (mddev->pers->hot_remove_disk(mddev, 
rdev->raid_disk)==0) {
-   char nm[20];
-   sprintf(nm,"rd%d", rdev->raid_disk);
-   sysfs_remove_link(>kobj, nm);
-   rdev->raid_disk = -1;
-   }
-   }
-
-   if (mddev->degraded) {
-   ITERATE_RDEV(mddev,rdev,rtmp)
-   if (rdev->raid_disk < 0
-   && !test_bit(Faulty, >flags)) {
-   rdev->recovery_offset = 0;
-   if 
(mddev->pers->hot_add_disk(mddev,rdev)) {
-   char nm[20];
-   sprintf(nm, "rd%d", 
rdev->raid_disk);
-   sysfs_create_link(>kobj, 
>kobj, nm);
-   spares++;
-   md_new_event(mddev);
-   } else
-   break;
-   }
-   }
 
-   if (spares) {
+   if (mddev->reshape_position != MaxSector) {
+   if 

[PATCH 002 of 6] md: RAID6: clean up CPUID and FPU enter/exit code

[NeilBrown]

From: "H. Peter Anvin" <[EMAIL PROTECTED]>

- Use kernel_fpu_begin() and kernel_fpu_end()
- Use boot_cpu_has() for feature testing even in userspace

Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/raid6mmx.c  |   16 ---
 ./drivers/md/raid6sse1.c |   17 ---
 ./drivers/md/raid6sse2.c |   22 +---
 ./drivers/md/raid6x86.h  |  218 +++
 4 files changed, 32 insertions(+), 241 deletions(-)

diff .prev/drivers/md/raid6mmx.c ./drivers/md/raid6mmx.c
--- .prev/drivers/md/raid6mmx.c 2007-02-20 17:11:51.0 +1100
+++ ./drivers/md/raid6mmx.c 2007-02-20 17:11:51.0 +1100
@@ -30,14 +30,8 @@ const struct raid6_mmx_constants {
 
 static int raid6_have_mmx(void)
 {
-#ifdef __KERNEL__
/* Not really "boot_cpu" but "all_cpus" */
return boot_cpu_has(X86_FEATURE_MMX);
-#else
-   /* User space test code */
-   u32 features = cpuid_features();
-   return ( (features & (1<<23)) == (1<<23) );
-#endif
 }
 
 /*
@@ -48,13 +42,12 @@ static void raid6_mmx1_gen_syndrome(int 
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
-   raid6_mmx_save_t sa;
 
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
 
-   raid6_before_mmx();
+   kernel_fpu_begin();
 
asm volatile("movq %0,%%mm0" : : "m" (raid6_mmx_constants.x1d));
asm volatile("pxor %mm5,%mm5"); /* Zero temp */
@@ -78,7 +71,7 @@ static void raid6_mmx1_gen_syndrome(int 
asm volatile("pxor %mm4,%mm4");
}
 
-   raid6_after_mmx();
+   kernel_fpu_end();
 }
 
 const struct raid6_calls raid6_mmxx1 = {
@@ -96,13 +89,12 @@ static void raid6_mmx2_gen_syndrome(int 
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
-   raid6_mmx_save_t sa;
 
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
 
-   raid6_before_mmx();
+   kernel_fpu_begin();
 
asm volatile("movq %0,%%mm0" : : "m" (raid6_mmx_constants.x1d));
asm volatile("pxor %mm5,%mm5"); /* Zero temp */
@@ -137,7 +129,7 @@ static void raid6_mmx2_gen_syndrome(int 
asm volatile("movq %%mm6,%0" : "=m" (q[d+8]));
}
 
-   raid6_after_mmx();
+   kernel_fpu_end();
 }
 
 const struct raid6_calls raid6_mmxx2 = {

diff .prev/drivers/md/raid6sse1.c ./drivers/md/raid6sse1.c
--- .prev/drivers/md/raid6sse1.c2007-02-20 17:11:51.0 +1100
+++ ./drivers/md/raid6sse1.c2007-02-20 17:11:51.0 +1100
@@ -33,16 +33,10 @@ extern const struct raid6_mmx_constants 
 
 static int raid6_have_sse1_or_mmxext(void)
 {
-#ifdef __KERNEL__
/* Not really boot_cpu but "all_cpus" */
return boot_cpu_has(X86_FEATURE_MMX) &&
(boot_cpu_has(X86_FEATURE_XMM) ||
 boot_cpu_has(X86_FEATURE_MMXEXT));
-#else
-   /* User space test code - this incorrectly breaks on some Athlons */
-   u32 features = cpuid_features();
-   return ( (features & (5<<23)) == (5<<23) );
-#endif
 }
 
 /*
@@ -53,14 +47,12 @@ static void raid6_sse11_gen_syndrome(int
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
-   raid6_mmx_save_t sa;
 
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
 
-   /* This is really MMX code, not SSE */
-   raid6_before_mmx();
+   kernel_fpu_begin();
 
asm volatile("movq %0,%%mm0" : : "m" (raid6_mmx_constants.x1d));
asm volatile("pxor %mm5,%mm5"); /* Zero temp */
@@ -94,8 +86,8 @@ static void raid6_sse11_gen_syndrome(int
asm volatile("movntq %%mm4,%0" : "=m" (q[d]));
}
 
-   raid6_after_mmx();
asm volatile("sfence" : : : "memory");
+   kernel_fpu_end();
 }
 
 const struct raid6_calls raid6_sse1x1 = {
@@ -113,13 +105,12 @@ static void raid6_sse12_gen_syndrome(int
u8 **dptr = (u8 **)ptrs;
u8 *p, *q;
int d, z, z0;
-   raid6_mmx_save_t sa;
 
z0 = disks - 3; /* Highest data disk */
p = dptr[z0+1]; /* XOR parity */
q = dptr[z0+2]; /* RS syndrome */
 
-   raid6_before_mmx();
+   kernel_fpu_begin();
 
asm volatile("movq %0,%%mm0" : : "m" (raid6_mmx_constants.x1d));
asm volatile("pxor %mm5,%mm5"); /* Zero temp */
@@ -157,8 +148,8 @@ static void raid6_sse12_gen_syndrome(int
asm volatile("movntq %%mm6,%0" : "=m" (q[d+8]));
}
 
-   raid6_after_mmx();
asm volatile("sfence" : :: "memory");
+   kernel_fpu_end();
 }
 
 const struct raid6_calls raid6_sse1x2 = {

diff .prev/drivers/md/raid6sse2.c ./drivers/md/raid6sse2.c
--- .prev/drivers/md/raid6sse2.c  

[PATCH 003 of 6] md: Move warning about creating a raid array on partitions of the one device.

[NeilBrown]

md tries to warn the user if they e.g. create a raid1 using two partitions
of the same device, as this does not provide true redundancy.

However it also warns if a raid0 is created like this, and there is
nothing wrong with that.

At the place where the warning is currently printer, we don't necessarily
know what level the array will be, so move the warning from the point
where the device is added to the point where the array is started.


Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/md.c |   63 +++---
 1 file changed, 37 insertions(+), 26 deletions(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c   2007-02-20 17:10:06.0 +1100
+++ ./drivers/md/md.c   2007-02-20 17:12:16.0 +1100
@@ -1296,27 +1296,17 @@ static struct super_type super_types[] =
.sync_super = super_1_sync,
},
 };
-   
-static mdk_rdev_t * match_dev_unit(mddev_t *mddev, mdk_rdev_t *dev)
-{
-   struct list_head *tmp;
-   mdk_rdev_t *rdev;
-
-   ITERATE_RDEV(mddev,rdev,tmp)
-   if (rdev->bdev->bd_contains == dev->bdev->bd_contains)
-   return rdev;
-
-   return NULL;
-}
 
 static int match_mddev_units(mddev_t *mddev1, mddev_t *mddev2)
 {
-   struct list_head *tmp;
-   mdk_rdev_t *rdev;
+   struct list_head *tmp, *tmp2;
+   mdk_rdev_t *rdev, *rdev2;
 
ITERATE_RDEV(mddev1,rdev,tmp)
-   if (match_dev_unit(mddev2, rdev))
-   return 1;
+   ITERATE_RDEV(mddev2, rdev2, tmp2)
+   if (rdev->bdev->bd_contains ==
+   rdev2->bdev->bd_contains)
+   return 1;
 
return 0;
 }
@@ -1325,8 +1315,7 @@ static LIST_HEAD(pending_raid_disks);
 
 static int bind_rdev_to_array(mdk_rdev_t * rdev, mddev_t * mddev)
 {
-   mdk_rdev_t *same_pdev;
-   char b[BDEVNAME_SIZE], b2[BDEVNAME_SIZE];
+   char b[BDEVNAME_SIZE];
struct kobject *ko;
char *s;
 
@@ -1342,14 +1331,6 @@ static int bind_rdev_to_array(mdk_rdev_t
else
mddev->size = rdev->size;
}
-   same_pdev = match_dev_unit(mddev, rdev);
-   if (same_pdev)
-   printk(KERN_WARNING
-   "%s: WARNING: %s appears to be on the same physical"
-   " disk as %s. True\n protection against single-disk"
-   " failure might be compromised.\n",
-   mdname(mddev), bdevname(rdev->bdev,b),
-   bdevname(same_pdev->bdev,b2));
 
/* Verify rdev->desc_nr is unique.
 * If it is -1, assign a free number, else
@@ -3109,6 +3090,36 @@ static int do_md_run(mddev_t * mddev)
return -EINVAL;
}
 
+   if (pers->sync_request) {
+   /* Warn if this is a potentially silly
+* configuration.
+*/
+   char b[BDEVNAME_SIZE], b2[BDEVNAME_SIZE];
+   mdk_rdev_t *rdev2;
+   struct list_head *tmp2;
+   int warned = 0;
+   ITERATE_RDEV(mddev, rdev, tmp) {
+   ITERATE_RDEV(mddev, rdev2, tmp2) {
+   if (rdev < rdev2 &&
+   rdev->bdev->bd_contains ==
+   rdev2->bdev->bd_contains) {
+   printk(KERN_WARNING
+  "%s: WARNING: %s appears to be"
+  " on the same physical disk as"
+  " %s.\n",
+  mdname(mddev),
+  bdevname(rdev->bdev,b),
+  bdevname(rdev2->bdev,b2));
+   warned = 1;
+   }
+   }
+   }
+   if (warned)
+   printk(KERN_WARNING
+  "True protection against single-disk"
+  " failure might be compromised.\n");
+   }
+
mddev->recovery = 0;
mddev->resync_max_sectors = mddev->size << 1; /* may be over-ridden by 
personality */
mddev->barriers_work = 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 001 of 6] md: Fix raid10 recovery problem.

[NeilBrown]

There are two errors that can lead to recovery problems with raid10
when used in 'far' more (not the default).

Due to a '>' instead of '>=' the wrong block is located which would
result in garbage being written to some random location, quite
possible outside the range of the device, causing the newly
reconstructed device to fail.

The device size calculation had some rounding errors (it didn't round
when it should) and so recovery would go a few blocks too far which
would again cause a write to a random block address and probably
a device error.

The code for working with device sizes was fairly confused and spread
out, so this has been tided up a bit.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./drivers/md/raid10.c |   38 --
 1 file changed, 20 insertions(+), 18 deletions(-)

diff .prev/drivers/md/raid10.c ./drivers/md/raid10.c
--- .prev/drivers/md/raid10.c   2007-02-20 17:10:15.0 +1100
+++ ./drivers/md/raid10.c   2007-02-20 17:11:41.0 +1100
@@ -429,7 +429,7 @@ static sector_t raid10_find_virt(conf_t 
if (dev < 0)
dev += conf->raid_disks;
} else {
-   while (sector > conf->stride) {
+   while (sector >= conf->stride) {
sector -= conf->stride;
if (dev < conf->near_copies)
dev += conf->raid_disks - conf->near_copies;
@@ -1801,6 +1801,7 @@ static sector_t sync_request(mddev_t *md
for (k=0; kcopies; k++)
if 
(r10_bio->devs[k].devnum == i)
break;
+   BUG_ON(k == conf->copies);
bio = r10_bio->devs[1].bio;
bio->bi_next = biolist;
biolist = bio;
@@ -2021,19 +2022,30 @@ static int run(mddev_t *mddev)
if (!conf->tmppage)
goto out_free_conf;
 
+   conf->mddev = mddev;
+   conf->raid_disks = mddev->raid_disks;
conf->near_copies = nc;
conf->far_copies = fc;
conf->copies = nc*fc;
conf->far_offset = fo;
conf->chunk_mask = (sector_t)(mddev->chunk_size>>9)-1;
conf->chunk_shift = ffz(~mddev->chunk_size) - 9;
+   size = mddev->size >> (conf->chunk_shift-1);
+   sector_div(size, fc);
+   size = size * conf->raid_disks;
+   sector_div(size, nc);
+   /* 'size' is now the number of chunks in the array */
+   /* calculate "used chunks per device" in 'stride' */
+   stride = size * conf->copies;
+   sector_div(stride, conf->raid_disks);
+   mddev->size = stride  << (conf->chunk_shift-1);
+
if (fo)
-   conf->stride = 1 << conf->chunk_shift;
-   else {
-   stride = mddev->size >> (conf->chunk_shift-1);
+   stride = 1;
+   else
sector_div(stride, fc);
-   conf->stride = stride << conf->chunk_shift;
-   }
+   conf->stride = stride << conf->chunk_shift;
+
conf->r10bio_pool = mempool_create(NR_RAID10_BIOS, r10bio_pool_alloc,
r10bio_pool_free, conf);
if (!conf->r10bio_pool) {
@@ -2063,8 +2075,6 @@ static int run(mddev_t *mddev)
 
disk->head_position = 0;
}
-   conf->raid_disks = mddev->raid_disks;
-   conf->mddev = mddev;
spin_lock_init(>device_lock);
INIT_LIST_HEAD(>retry_list);
 
@@ -2106,16 +2116,8 @@ static int run(mddev_t *mddev)
/*
 * Ok, everything is just fine now
 */
-   if (conf->far_offset) {
-   size = mddev->size >> (conf->chunk_shift-1);
-   size *= conf->raid_disks;
-   size <<= conf->chunk_shift;
-   sector_div(size, conf->far_copies);
-   } else
-   size = conf->stride * conf->raid_disks;
-   sector_div(size, conf->near_copies);
-   mddev->array_size = size/2;
-   mddev->resync_max_sectors = size;
+   mddev->array_size = size << (conf->chunk_shift-1);
+   mddev->resync_max_sectors = size << conf->chunk_shift;
 
mddev->queue->unplug_fn = raid10_unplug;
mddev->queue->issue_flush_fn = raid10_issue_flush;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 000 of 6] md: Assorted fixes and features for md for 2.6.21

[NeilBrown]

Following 6 patches are against 2.6.20 and are suitable for 2.6.21.
They are not against -mm because the new plugging makes raid5 not work
and so not testable, and there are a few fairly minor intersections between
these patches and those patches.
There is also a very minor conflict with the hardware-xor patches - one line
of context is different.

Patch 1 should probably go in -stable - the bug could cause data
corruption in a fairly uncommon raid10 configuration, so that one and
this intro are Cc:ed to [EMAIL PROTECTED]

Thanks,
NeilBrown


 [PATCH 001 of 6] md: Fix raid10 recovery problem.
 [PATCH 002 of 6] md: RAID6: clean up CPUID and FPU enter/exit code
 [PATCH 003 of 6] md: Move warning about creating a raid array on partitions of 
the one device.
 [PATCH 004 of 6] md: Clean out unplug and other queue function on md shutdown
 [PATCH 005 of 6] md: Restart a (raid5) reshape that has been aborted due to a 
read/write error.
 [PATCH 006 of 6] md: Add support for reshape of a raid6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-mm2

[Andrew Morton]

On Tue, 20 Feb 2007 02:20:21 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
wrote:

> On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> > On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
> > wrote:
> > 
> > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > > > 
> > > > Temporarily at
> > > > 
> > > >   http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > > > 
> > > > Will appear later at
> > > > 
> > > >  
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> > > 
> > > Two problems:
> > > 
> > > 1) A showstopper with the root partition on RAID1:
> > > 
> > > md: raid1 personality registered for level 1
> > > [--snip--]
> > > md: multipath personality registered for level -4
> > > register_blkdev: failed to get major for mdp
> > > [--snip--]
> > > VFS: Cannot open root device "md1" or unknown-block(0,0)
> > 
> > Someone else reported that against mainline.  Can you please debug it a bit?
> 
> For now I can only say 2.6.20 + origin.patch breaks.
> 
> However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason.
> I'll check that tomorrow.

Yes, Rolf says this goes away when you stop using gcc-4.1.0.

I'm hoping that churning the code around like below makes things work
right.



From: Andrew Morton <[EMAIL PROTECTED]>

Several people have reported failures in dynamic major device number handling
due to the recent changes in there to avoid handing out the local/experimental
majors.

Rolf reports that this is due to a gcc-4.1.0 bug.

The patch refactors that code a lot in an attempt to provoke the compiler into
behaving.

Cc: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 block/genhd.c  |9 ++---
 drivers/base/core.c|   14 ++
 fs/char_dev.c  |8 ++--
 include/linux/kdev_t.h |1 +
 4 files changed, 19 insertions(+), 13 deletions(-)

diff -puN block/genhd.c~rework-reserved-major-handling block/genhd.c
--- a/block/genhd.c~rework-reserved-major-handling
+++ a/block/genhd.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,13 +62,7 @@ int register_blkdev(unsigned int major, 
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
-   /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
-   if ((60 <= index && index <= 63) ||
-   (120 <= index && index <= 127) ||
-   (240 <= index && index <= 254))
+   if (is_lanana_major(index))
continue;
if (major_names[index] == NULL)
break;
diff -puN fs/char_dev.c~rework-reserved-major-handling fs/char_dev.c
--- a/fs/char_dev.c~rework-reserved-major-handling
+++ a/fs/char_dev.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -108,12 +109,7 @@ __register_chrdev_region(unsigned int ma
/* temporary */
if (major == 0) {
for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
-   /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
-   if ((60 <= i && i <= 63) || (120 <= i && i <= 127) ||
-   (240 <= i && i <= 254))
+   if (is_lanana_major(i))
continue;
if (chrdevs[i] == NULL)
break;
diff -puN drivers/base/core.c~rework-reserved-major-handling drivers/base/core.c
--- a/drivers/base/core.c~rework-reserved-major-handling
+++ a/drivers/base/core.c
@@ -28,6 +28,20 @@ int (*platform_notify)(struct device * d
 int (*platform_notify_remove)(struct device * dev) = NULL;
 
 /*
+ * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
+ */
+bool is_lanana_major(unsigned int major)
+{
+   if (major >= 60 && major <= 63)
+   return 1;
+   if (major >= 120 && major <= 127)
+   return 1;
+   if (major >= 240 && major <= 254)
+   return 1;
+   return 0;
+}
+
+/*
  * sysfs bindings for devices.
  */
 
diff -puN include/linux/kdev_t.h~rework-reserved-major-handling 
include/linux/kdev_t.h
--- a/include/linux/kdev_t.h~rework-reserved-major-handling
+++ a/include/linux/kdev_t.h
@@ -87,6 +87,7 @@ static inline unsigned sysv_minor(u32 de
return dev & 0x3;
 }
 
+bool is_lanana_major(unsigned int major);
 
 #else /* __KERNEL__ */
 
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

[Jaya Kumar]

On 2/19/07, Paul Mundt <[EMAIL PROTECTED]> wrote:

On Mon, Feb 19, 2007 at 11:13:04PM -0500, Jaya Kumar wrote:
>
> Ok. Here's what I'm thinking for abstracting this:
>
> fbdev drivers would setup fb_mmap with their own_mmap as usual. In
> own_mmap, they would do what they normally do and setup a vm_ops. They
> are free to have their own nopage handler but would set the
> page_mkwrite handler to be fbdev_deferred_io_mkwrite().

The vast majority of drivers do not implement ->fb_mmap(), and with
proper abstraction, this should be something that's possible as a direct
alternative to drivers/video/fbmem.c:fb_mmap() for the people that want
it. Of course it's just as easy to do something like the sbuslib.c route
and then have drivers set their ->fb_mmap() from that too.



I was thinking about having that fb_mmap replacement too. But then I
got worried because that generic implementation of nopage/etc would
need to handle whether the driver's fb memory was vmalloced, kmalloced
or a mixture if some do that. So I figured let's aim low and just pull
in the core part that does the setup and page tracking stuff. I hope
that's okay.


That works for me, though I'd prefer for struct page_list to be done with
a scatterlist, then it's trivial to setup from the workqueue context
without having to shuffle things around.



Ok. Will check out when implementing.

Thanks,
jaya
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20 kernel hang with USB drive and vfat doing ftruncate

[Robert Hancock]

Kumar Gala wrote:
[  497.499249] usb-storage   D  0   671  5   
773   670 (L-TLB)

[  497.506930] Call Trace:
[  497.509372] [C3F35A60] [C00083AC] __switch_to+0x28/0x40
[  497.514608] [C3F35A80] [C01F4B78] schedule+0x324/0x6bc
[  497.519756] [C3F35AC0] [C01F5D6C] schedule_timeout+0x6c/0xd0
[  497.525426] [C3F35B00] [C01F5C9C] io_schedule_timeout+0x30/0x54
[  497.531356] [C3F35B20] [C0050DE4] congestion_wait+0x64/0x8c
[  497.536941] [C3F35B70] [C004A9F0] throttle_vm_writeout+0x1c/0x84
[  497.542958] [C3F35B90] [C004F33C] shrink_zone+0xbb0/0xfe4
[  497.548367] [C3F35D40] [C004F8F4] try_to_free_pages+0x184/0x2cc
[  497.554298] [C3F35DB0] [C0049AA8] __alloc_pages+0x110/0x2c0
[  497.559878] [C3F35E00] [C0060F84] cache_alloc_refill+0x394/0x694
[  497.565900] [C3F35E30] [C00614A0] __kmalloc+0xc4/0xcc
[  497.570961] [C3F35E40] [C01544D0] usb_alloc_urb+0x1c/0x5c
[  497.576371] [C3F35E50] [C015520C] usb_sg_init+0x1a0/0x2f8
[  497.581779] [C3F35EA0] [C0167318] usb_stor_bulk_transfer_sg+0x8c/0x138
[  497.588317] [C3F35ED0] [C0167960] usb_stor_Bulk_transport+0x140/0x310
[  497.594767] [C3F35F00] [C0167DCC] usb_stor_invoke_transport+0x2c/0x344
[  497.601303] [C3F35F50] [C0166B2C] 
usb_stor_transparent_scsi_command+0x10/0x20

[  497.608449] [C3F35F60] [C0168498] usb_stor_control_thread+0x1f8/0x290
[  497.614900] [C3F35FC0] [C0033E48] kthread+0xf4/0x130
[  497.619876] [C3F35FF0] [C001093C] kernel_thread+0x44/0x60


This seems like a problem, the usb-storage thread is trying to allocate 
some memory which is ending up waiting for VM writeout, which obviously 
won't proceed since this thread is the one that needs to do this.. It 
looks like the allocation in usb_stor_bulk_transfer_sglist is done with 
GFP_NOIO, so I wonder why we're getting into this state?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[v j]

You are trying to cram this in a simple yes or no box, and it just doesn't
fit. There are questions nobody knows the answers to (such as what rights
you need to distribute a derivative work or whether compiling code makes a
translation).


Thanks, all for the discussion. I certainly learnt a lot. I definitely
expected to be flamed and roasted for posting my original message, and
was not disappointed :)

I do not possess all the knowledge ("legal" and technical) that people
who have contributed to this discussion possess. However I will still
comment from a user's perspective, which was my original point.

Many companies in the embedded field still mistakenly feel (or felt
until a while ago) that Linux was not right for them. That they would
have to open source their code, that they would not get adequate
support, and that Linux was too big and heavy to perform well in an
embedded platform. People like me who were Linux Desktop junkies were
actually trying to convince companies of the opposite.

Now the popularity of Linux is exploding in the embedded space. Nobody
talks of VxWorks and OSE anymore. It is all Linux. Perhaps it would be
a worthwhile experiment to study this surge in popularity. I am not an
expert, but perhaps the reason is "it works so goddamn well and has a
wealth of third party FREE software". Sure its a bit of work to make
it work on our platform and we don't have to Enea or Windriver to
write our gripes to. But it definitely is worth it.

Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL
does to this popularity. I don't know. I am just giving you my
opinion. The moment companies learn of something like this, alarm
bells start to go off. This is not rational. I personally have nothing
against open-sourcing all software. *But*, this is not how companies
think.

Let's think about why Linux became so popular and strive towards
keeping it that way instead of resorting to innovative ways of just
confusing a lot of people.

Having said this, I am committed to contribute back to the Linux
community in any way I can, not withstanding my present employer. Keep
up the good work guys!


DS


vj.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial related oops

[Robert Hancock]

Michael K. Edwards wrote:

Of course not.  But dealing with a stuck IRQ line by locking up isn't
very practical either.  IRQ sharing is stupid yet universal, and it


And we don't, that's why we have that "nobody cared" logic that disables 
the interrupt line if no driver services the interrupt. That doesn't 
provide a clean recovery, of course, it's meant to notify the user of 
what happened so that the problem can be fixed.



happens all the time that a device that has been sitting there minding
its own business since power-up, with no driver to drive it, decides
to assert its IRQ.  Maybe it just got hot-plugged, maybe it just got
its first dribble of input, whatever.  Other devices on the shared IRQ
are screwed (or at least semi-screwed; you could periodically
re-enable the IRQ long enough to make a run through the ISR chain
servicing the other devices).  But if you run "lspci" (or whatever)
and load a driver for the newly awake device, everything goes back to
normal.

For devices compiled into the kernel, you shouldn't have to play these
games.  If, that is, there were three stages of driver initialization,
called in successive passes:


Exactly, for devices compiled into the kernel. In most setups this is 
only a fraction of all devices, so solving this problem only for drivers 
built into the kernel is no solution.




1) installing an ISR with a fallback STFU path (device-specific but
not dependent on any particular pre-existing chip state), quiescing it
if you know how and registering for the IRQ if you know which it is;

2) going through the chip's soft-reset-wake-up-shut-up cycle and
populating driver data structures, possibly correcting the IRQ
registration along the way;

3) ready-as-we'll-ever-be, bring on the interrupts.

You probably can't help enabling the IRQ briefly during 2) so that you
can do tests like Russell's loopback.  But it's a needless gamble to
do that without doing 1) for all compiled-in drivers and platform
devices first, in a previous discovery pass.  And it's stupid to do 3)
in the same pass as 2), because you'll just open race condition
windows that will only bite when an all-the-way-live device raises its
IRQ at a moment when the writer of the wake-up-shut-up code wasn't
expecting it.  All code has bugs and they're only a problem when they
bite in the field.

If a system has a device that generates interrupts before they're 
enabled,

and the firmware doesn't fix it, then some platform-specific quirk has to
handle it and shut off the interrupt before it allows any interrupts
to be enabled. (We have such a quirk for certain network controllers 
where

the boot ROM can leave the chip generating interrupts on bootup.)


You don't need quirks if your driver initialization is bomb-proof to
begin with.  Devices that are quiet on power-up are purely
coincidental and should not be construed.


It's not coincidental, it is the only sane way to design hardware. You 
just can't go firing off interrupts without a driver having 
intentionally enabled them. There are a few devices that have had such 
issues, but they have been few and far between, certainly not enough to 
warrant the complexity of the scheme you propose.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] [PATCH] MAINTAINERS: mark framebuffer as Orphan

[Antonino A. Daplas]

On Fri, 2007-02-16 at 13:24 +0100, Adrian Bunk wrote:
> On Thu, Feb 15, 2007 at 03:05:26PM -0800, Randy Dunlap wrote:
> > On Thu, 15 Feb 2007 22:26:10 + (GMT) James Simmons wrote:
> > 
> > > 
> > > I wouldn't say it orphan. I just can't spend 8 hours a day on it. 
> > > Alot of patches have been flowing into the layer.

No need.

My apologies for the long absence. I volunteered to serve in a remote,
underserved area (no internet connection, no cellular site, with only a
computer running Windows 95). I thought it would last only a few weeks
but due to unforeseen circumstances, lasted half a year.

Give me several days to read my inbox and update my tree and I should be
back on track.

Tony


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] slab: ensure cache_alloc_refill terminates

[Christoph Lameter]

On Mon, 19 Feb 2007, Pekka J Enberg wrote:

> If slab->inuse is corrupted, cache_alloc_refill can enter an infinite
> loop as detailed by Michael Richardson in the following post:
> .

We have seen that corruption too.

>   check_spinlock_acquired(cachep);
> +
> + /*
> +  * The slab was either on partial or free list so
> +  * there must be at least one object available for
> +  * allocation.
> +  */
> + BUG_ON(slabp->inuse >= cachep->num);

slabp->inuse is an integer and we have seen it become -1. The proposed 
test will not catch those cases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial related oops

[Michael K. Edwards]

On 2/19/07, Robert Hancock <[EMAIL PROTECTED]> wrote:

How do you propose to do this? Drivers can get loaded and unloaded at any
time. If you have a device generating spurious interrupts on a shared IRQ
line, there's no way you can use any device on that line until that interrupt
is shut off. Requiring all drivers to be loaded before any of them can use
interrupts is simply not practical.


Of course not.  But dealing with a stuck IRQ line by locking up isn't
very practical either.  IRQ sharing is stupid yet universal, and it
happens all the time that a device that has been sitting there minding
its own business since power-up, with no driver to drive it, decides
to assert its IRQ.  Maybe it just got hot-plugged, maybe it just got
its first dribble of input, whatever.  Other devices on the shared IRQ
are screwed (or at least semi-screwed; you could periodically
re-enable the IRQ long enough to make a run through the ISR chain
servicing the other devices).  But if you run "lspci" (or whatever)
and load a driver for the newly awake device, everything goes back to
normal.

For devices compiled into the kernel, you shouldn't have to play these
games.  If, that is, there were three stages of driver initialization,
called in successive passes:

1) installing an ISR with a fallback STFU path (device-specific but
not dependent on any particular pre-existing chip state), quiescing it
if you know how and registering for the IRQ if you know which it is;

2) going through the chip's soft-reset-wake-up-shut-up cycle and
populating driver data structures, possibly correcting the IRQ
registration along the way;

3) ready-as-we'll-ever-be, bring on the interrupts.

You probably can't help enabling the IRQ briefly during 2) so that you
can do tests like Russell's loopback.  But it's a needless gamble to
do that without doing 1) for all compiled-in drivers and platform
devices first, in a previous discovery pass.  And it's stupid to do 3)
in the same pass as 2), because you'll just open race condition
windows that will only bite when an all-the-way-live device raises its
IRQ at a moment when the writer of the wake-up-shut-up code wasn't
expecting it.  All code has bugs and they're only a problem when they
bite in the field.


If a system has a device that generates interrupts before they're enabled,
and the firmware doesn't fix it, then some platform-specific quirk has to
handle it and shut off the interrupt before it allows any interrupts
to be enabled. (We have such a quirk for certain network controllers where
the boot ROM can leave the chip generating interrupts on bootup.)


You don't need quirks if your driver initialization is bomb-proof to
begin with.  Devices that are quiet on power-up are purely
coincidental and should not be construed.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] free swap space when (re)activating page

[Christoph Lameter]

On Fri, 16 Feb 2007, Rik van Riel wrote:

> What do you think?

Looks good apart from one passage (which just vanished when I tried to 
reply, please post patches as inline text).

It was the portion that modifies shrink_active_list. Why operate
on the pagevec there? The pagevec only contains the leftovers to be 
released from scanning over the temporary inactive list.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Block layer: separate out queue-oriented ioctls

[Douglas Gilbert]

Alan Stern wrote:
> On Mon, 19 Feb 2007, Douglas Gilbert wrote:
> 
>> Alan,
>> The SG_GET_RESERVED_SIZE ioctl is also defined in
>> the block layer, see block/scsi_ioctl.c .
> 
> Ah, I didn't know that.  (Or more likely, I used to know and have since 
> forgotten.)  Thanks for pointing it out.
> 
>> I suspect it is just a kludge to fool cdrecord that it
>> is talking to a sg device. [One of many kludges in the
>> block SG_IO ioctl implementation to that end.]
>> So perhaps the block layer versions of SG_SET_RESERVED_SIZE
>> and SG_GET_RESERVED_SIZE need to be similarly capped.
> 
> Yes.  In fact one of them already is, but the other should be too.
> 
>> Actually I think that I would default SG_GET_RESERVED_SIZE to
>> request_queue->max_sectors * 512 in the block layer
>> implementation (as there is no "reserve buffer" associated
>> with a block device).
> 
> Okay.
> 
> Come to think of it, the reserved_size value used when a new sg device is
> created should also be capped at max_sectors * 512.  Agreed?  I can't see
> any reason for ever having a larger buffer -- it would be impossible to
> make use of the extra space.

Alan,
That depends whether or not max_sectors can be changed
(via sysfs) subsequent to a sg device being created.
And I think it can.

# ls -l /sys/block/sdc/queue/
total 0
drwxr-xr-x 2 root root0 Feb 19 18:29 iosched
-r--r--r-- 1 root root 4096 Feb 19 23:41 max_hw_sectors_kb
-rw-r--r-- 1 root root 4096 Feb 19 23:41 max_sectors_kb
-rw-r--r-- 1 root root 4096 Feb 19 23:41 nr_requests
-rw-r--r-- 1 root root 4096 Feb 19 23:41 read_ahead_kb
-rw-r--r-- 1 root root 4096 Feb 19 23:41 scheduler


# cat max_hw_sectors_kb > max_sectors_kb

... is the real maximum if the LLD that set max_hw_sectors_kb
is to be believed (actually it is often a finger in
the wind).

Doug Gilbert


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

[Paul Mundt]

On Mon, Feb 19, 2007 at 11:13:04PM -0500, Jaya Kumar wrote:
> On 2/18/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
> >Given that, this would have to be something that's dealt with at the
> >subsystem level rather than in individual drivers, hence the desire to
> >see something like this more generically visible.
> >
> 
> Hi Peter, Paul, fbdev folk,
> 
> Ok. Here's what I'm thinking for abstracting this:
> 
> fbdev drivers would setup fb_mmap with their own_mmap as usual. In
> own_mmap, they would do what they normally do and setup a vm_ops. They
> are free to have their own nopage handler but would set the
> page_mkwrite handler to be fbdev_deferred_io_mkwrite().

The vast majority of drivers do not implement ->fb_mmap(), and with
proper abstraction, this should be something that's possible as a direct
alternative to drivers/video/fbmem.c:fb_mmap() for the people that want
it. Of course it's just as easy to do something like the sbuslib.c route
and then have drivers set their ->fb_mmap() from that too.

> fbdev_deferred_io_mkwrite would build up the list of touched pages and
> pass it to a delayed workqueue which would then mkclean on each page
> and then pass a copy of that page list down to a driver's callback
> function. The fbdev driver's callback function can then do the actual
> IO to the framebuffer or coalesce DMA based on the provided page list.
> 
That works for me, though I'd prefer for struct page_list to be done with
a scatterlist, then it's trivial to setup from the workqueue context
without having to shuffle things around.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ata command timeout

[Marc Marais]

On Tue, 20 Feb 2007 13:07:50 +0900, Tejun Heo wrote
> [EMAIL PROTECTED] wrote:
> > Hello,
> > 
> > I have been running 2.6.18 for two months and the last couple of days these 
> > error messages have appeared in my logs 
> > (sata_promise kernel module, sda:SATA sdb:PATA disks):
> > 
> >ata1: command timeout
> > Feb 17 22:23:14 linux kernel: ata1: no sense translation for status: 0x40
> > Feb 17 22:23:14 linux kernel: ata1: translated ATA stat/err 0x40/00 to SCSI 
> > SK/ASC/ASCQ 0xb/00/00
> > Feb 17 22:23:14 linux kernel: ata1: status=0x40 { DriveReady }
> > Feb 17 22:23:14 linux kernel: sd 0:0:0:0: SCSI error: return code = 
> > 0x0802
> > Feb 17 22:23:14 linux kernel: sda: Current: sense key: Aborted Command
> > Feb 17 22:23:14 linux kernel: Additional sense: No additional sense 
> > information
> > Feb 17 22:23:14 linux kernel: end_request: I/O error, dev sda, sector 
> > 145179585
> > Feb 17 22:23:14 linux kernel: Buffer I/O error on device sda2, logical 
> > block 
> > 2787300
> > Feb 17 22:23:14 linux kernel: lost page write due to I/O error on sda2
> > 
> > and 
> > 
> >ata1: command timeout
> > Feb 19 20:39:31 linux kernel: ata1: no sense translation for status: 0x40
> > Feb 19 20:39:31 linux kernel: ata1: translated ATA stat/err 0x40/00 to SCSI 
> > SK/ASC/ASCQ 0xb/00/00
> > Feb 19 20:39:31 linux kernel: ata1: status=0x40 { DriveReady }
> > Feb 19 20:39:31 linux kernel: sd 0:0:0:0: SCSI error: return code = 
> > 0x0802
> > Feb 19 20:39:31 linux kernel: sda: Current: sense key: Aborted Command
> > Feb 19 20:39:31 linux kernel: Additional sense: No additional sense 
> > information
> > Feb 19 20:39:31 linux kernel: end_request: I/O error, dev sda, sector 
> > 89553479
> > 
> > without any other ill-effects that I know of(I did smart tests on the 
> > drive; 
> > all passed successfully).
> > I have read that hddtemp may be the cause of this (I am running version 
> > 0.3) 
> > so is there any reason
> > to worry and prepare for a HDD replacement?
> 
> Not really.  If the problem occurs very infrequently, you don't need 
> to worry about it too much.  Command timeouts do occur on otherwise healthy
> systems from time to time.
> 
> -- 
> tejun
> -

I'm experiencing the exact same problem with my setup also with sata_promise.
I have posted to the linux-ide list but it wasn't really acknowledged as a
problem in the driver. Are these command timeouts? The log entry doesn't seem
to say that - just an error with 'DriveReady' and command aborted. I would
think some kind of retry should be performed (and if it is then logged too).

The errors may be benign but the problem is when using software raid (md
driver) that this error may cause a degraded array and worse a damaged array
should a read error like this occur when an array is already degraded.

The question is what happens after the error is reported, is the operation
retried? In my situation the md layer receives the error and recovers by
taking the data from another drive in the array. 

The fact that you are also experiencing this means it might be an issue that
needs further investigation in my opinion.



Regards,
Marc

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PCI riser cards and PCI irq routing, etc

[Udo van den Heuvel]

Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> 
>> At the bottom I added a dmesg output of the kernel after boot.
>> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
>> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for
>> i2c although the card does work perfectly for DVB-T reception (picture,
>> low CPU load, etc) with only reception as the bottleneck.
> 
> BTW: Can you check which device # and IRQ does the card get if plugged
> directly into the PCI slot on board (without the riser)?

BTW: 2.6.18-1.2798.fc6 (Fedora kernel) gave me in dmesg:

Linux video capture interface: v2.00
saa7146: register extension 'budget_av'.
saa7146: found saa7146 @ mem f896a000 (revision 1, irq 145) (0x153b,0x1157).
saa7146 (0): dma buffer size 192512
DVB: registering new adapter (Terratec Cinergy 1200 DVB-T).
adapter failed MAC signature check
encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
input: PC Speaker as /class/input/input2
KNC1-0: MAC addr = 00:0a:ac:01:d6:87
DVB: registering frontend 0 (Philips TDA10046H DVB-T)...
budget-av: ci interface initialised.
saa7146: found saa7146 @ mem f89e6000 (revision 1, irq 153) (0x153b,0x1155).
saa7146 (1): dma buffer size 192512
DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S).
adapter failed MAC signature check
encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
KNC1-1: MAC addr = 00:0a:ac:12:93:8d
DVB: registering frontend 1 (ST STV0299 DVB-S)...
budget-av: ci interface initialised.

(irq 145 and 153!?)

I think I can do some testing this afternoon.

Kind regards,
Udo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PCI riser cards and PCI irq routing, etc

[Udo van den Heuvel]

Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> 
>> At the bottom I added a dmesg output of the kernel after boot.
>> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
>> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for
>> i2c although the card does work perfectly for DVB-T reception (picture,
>> low CPU load, etc) with only reception as the bottleneck.
> 
> BTW: Can you check which device # and IRQ does the card get if plugged
> directly into the PCI slot on board (without the riser)?

DN is 20 I believe (from the tranquilPC doc).
irq I'd have to check.

> Is it a VIA ITX board? I think I have VIA's riser card somewhere,
> could check what it does.

Yes, VIA Epia EN12000.
Interesting to check the riser card.

Udo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

[Jaya Kumar]

On 2/18/07, Paul Mundt <[EMAIL PROTECTED]> wrote:

Given that, this would have to be something that's dealt with at the
subsystem level rather than in individual drivers, hence the desire to
see something like this more generically visible.



Hi Peter, Paul, fbdev folk,

Ok. Here's what I'm thinking for abstracting this:

fbdev drivers would setup fb_mmap with their own_mmap as usual. In
own_mmap, they would do what they normally do and setup a vm_ops. They
are free to have their own nopage handler but would set the
page_mkwrite handler to be fbdev_deferred_io_mkwrite().
fbdev_deferred_io_mkwrite would build up the list of touched pages and
pass it to a delayed workqueue which would then mkclean on each page
and then pass a copy of that page list down to a driver's callback
function. The fbdev driver's callback function can then do the actual
IO to the framebuffer or coalesce DMA based on the provided page list.

I would like to add something like the following to struct fb_info:

#ifdef CONFIG_FB_DEFERRED_IO
struct fb_deferred_io *defio;
#endif

to store the mutex (to protect the page list), the touched page list,
and the driver's callback function.

I hope this sounds sufficiently generic to meet everyone's (the two of
us? :) needs.

Thanks,
jaya

ps: I've added James and Geert to the CC list. I would appreciate any
advice on whether this is a suitable approach.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ata command timeout

[Tejun Heo]

[EMAIL PROTECTED] wrote:
> Hello,
> 
> I have been running 2.6.18 for two months and the last couple of days these 
> error messages have appeared in my logs 
> (sata_promise kernel module, sda:SATA sdb:PATA disks):
> 
>ata1: command timeout
> Feb 17 22:23:14 linux kernel: ata1: no sense translation for status: 0x40
> Feb 17 22:23:14 linux kernel: ata1: translated ATA stat/err 0x40/00 to SCSI 
> SK/ASC/ASCQ 0xb/00/00
> Feb 17 22:23:14 linux kernel: ata1: status=0x40 { DriveReady }
> Feb 17 22:23:14 linux kernel: sd 0:0:0:0: SCSI error: return code = 0x0802
> Feb 17 22:23:14 linux kernel: sda: Current: sense key: Aborted Command
> Feb 17 22:23:14 linux kernel: Additional sense: No additional sense 
> information
> Feb 17 22:23:14 linux kernel: end_request: I/O error, dev sda, sector 
> 145179585
> Feb 17 22:23:14 linux kernel: Buffer I/O error on device sda2, logical block 
> 2787300
> Feb 17 22:23:14 linux kernel: lost page write due to I/O error on sda2
> 
> and 
> 
>ata1: command timeout
> Feb 19 20:39:31 linux kernel: ata1: no sense translation for status: 0x40
> Feb 19 20:39:31 linux kernel: ata1: translated ATA stat/err 0x40/00 to SCSI 
> SK/ASC/ASCQ 0xb/00/00
> Feb 19 20:39:31 linux kernel: ata1: status=0x40 { DriveReady }
> Feb 19 20:39:31 linux kernel: sd 0:0:0:0: SCSI error: return code = 0x0802
> Feb 19 20:39:31 linux kernel: sda: Current: sense key: Aborted Command
> Feb 19 20:39:31 linux kernel: Additional sense: No additional sense 
> information
> Feb 19 20:39:31 linux kernel: end_request: I/O error, dev sda, sector 89553479
> 
> without any other ill-effects that I know of(I did smart tests on the drive; 
> all passed successfully).
> I have read that hddtemp may be the cause of this (I am running version 0.3) 
> so is there any reason
> to worry and prepare for a HDD replacement?

Not really.  If the problem occurs very infrequently, you don't need to
worry about it too much.  Command timeouts do occur on otherwise healthy
systems from time to time.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.21-rc1] ibmebus: make root device not of_device-based

[Hoang-Nam Nguyen]

The fake root device doesn't have an associated device tree node,
so it should not be an of_device. This patch makes it a normal,
bus-less device and thus saves a lot of checks later on.


Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---


 ibmebus.c |   33 ++---
 1 files changed, 14 insertions(+), 19 deletions(-)


diff -urp a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
--- a/arch/powerpc/kernel/ibmebus.c 2007-02-20 01:35:54.0 +0100
+++ b/arch/powerpc/kernel/ibmebus.c 2007-02-20 01:39:24.0 +0100
@@ -44,9 +44,8 @@
 #include 
 #include 
 
-static struct ibmebus_dev ibmebus_bus_device = { /* fake "parent" device */
-   .ofdev.dev.bus_id = "ibmebus",
-   .ofdev.dev.bus= _bus_type,
+static struct device ibmebus_bus_device = { /* fake "parent" device */
+   .bus_id = "ibmebus",
 };
 
 static void *ibmebus_alloc_coherent(struct device *dev,
@@ -173,7 +172,7 @@ static struct ibmebus_dev* __devinit ibm
 {
int err = 0;
 
-   dev->ofdev.dev.parent  = _bus_device.ofdev.dev;
+   dev->ofdev.dev.parent  = _bus_device;
dev->ofdev.dev.bus = _bus_type;
dev->ofdev.dev.release = ibmebus_dev_release;
 
@@ -268,14 +267,12 @@ static int ibmebus_match_helper_name(str
const struct ibmebus_dev *ebus_dev = to_ibmebus_dev(dev);
char *name;
 
-   /* parent device has no of_device node, so skip it */
-   if (ebus_dev != _bus_device) {
-   name = (char*)get_property(
-   ebus_dev->ofdev.node, "name", NULL);
+   name = (char*)get_property(
+   ebus_dev->ofdev.node, "name", NULL);
+
+   if (name && (strcmp((char*)data, name) == 0))
+   return 1;
 
-   if (name && (strcmp((char*)data, name) == 0))
-   return 1;
-   }
return 0;
 }
 
@@ -384,14 +381,12 @@ static int ibmebus_match_helper_loc_code
const struct ibmebus_dev *ebus_dev = to_ibmebus_dev(dev);
char *loc_code;
 
-   /* parent device has no of_device node, so skip it */
-   if (ebus_dev != _bus_device) {
-   loc_code = (char*)get_property(
-   ebus_dev->ofdev.node, "ibm,loc-code", NULL);
+   loc_code = (char*)get_property(
+   ebus_dev->ofdev.node, "ibm,loc-code", NULL);
+
+   if (loc_code && (strcmp((char*)data, loc_code) == 0))
+   return 1;
 
-   if (loc_code && (strcmp((char*)data, loc_code) == 0))
-   return 1;
-   }
return 0;
 }
 
@@ -449,7 +444,7 @@ static int __init ibmebus_bus_init(void)
return err;
}
 
-   err = device_register(_bus_device.ofdev.dev);
+   err = device_register(_bus_device);
if (err) {
printk(KERN_WARNING "%s: device_register returned %i\n",
   __FUNCTION__, err);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20: fails to turn laptop power off (ACPI?)

[Len Brown]

On Monday 19 February 2007 19:12, Jonathan Woithe wrote:
> As of 2.6.20 the kernel has not been able to turn the power off on my laptop
> during shutdown.  Up to and including 2.6.19, pressing the power button
> triggered a shutdown via the ACPI system.  Under 2.6.20 (with the same
> kernel features enabled as far as I am aware) the system shutdown still
> occurs, but when the time comes for power to be cut all that happens is that
> the screen backlight turns off and the machine appears to hang indefinitely.

Any better with CONFIG_USB_SUSPEND=n ?
http://bugzilla.kernel.org/show_bug.cgi?id=7828

-Len


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Block layer: separate out queue-oriented ioctls

[Alan Stern]

On Mon, 19 Feb 2007, Douglas Gilbert wrote:

> Alan,
> The SG_GET_RESERVED_SIZE ioctl is also defined in
> the block layer, see block/scsi_ioctl.c .

Ah, I didn't know that.  (Or more likely, I used to know and have since 
forgotten.)  Thanks for pointing it out.

> I suspect it is just a kludge to fool cdrecord that it
> is talking to a sg device. [One of many kludges in the
> block SG_IO ioctl implementation to that end.]
> So perhaps the block layer versions of SG_SET_RESERVED_SIZE
> and SG_GET_RESERVED_SIZE need to be similarly capped.

Yes.  In fact one of them already is, but the other should be too.

> Actually I think that I would default SG_GET_RESERVED_SIZE to
> request_queue->max_sectors * 512 in the block layer
> implementation (as there is no "reserve buffer" associated
> with a block device).

Okay.

Come to think of it, the reserved_size value used when a new sg device is
created should also be capped at max_sectors * 512.  Agreed?  I can't see
any reason for ever having a larger buffer -- it would be impossible to
make use of the extra space.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-git10 (and -git13): BUG at drivers/pci/pci.c:817 during resume from disk

[Tejun Heo]

Rafael J. Wysocki wrote:
> Update:
> 
> I get the same BUG with 2.6.20-git13 100% of the time during the resume.
> The system seems to be fully functional nonetheless.

Known bug, will be fixed soon.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot

[Timothy Shimmin]

Thanks for the report, Linda.
This and other lockdep reports are on our todo/bug list
and I've added this one.
(Nathan looked at some of these lock related changes I believe and we still have
a pending patch of his to go thru)

--Tim

--On 18 February 2007 1:38:45 PM -0800 Linda Walsh <[EMAIL PROTECTED]> wrote:


Turned on lock testing/proving/deadlock detection.  Not chasing any particular
problem, but looking for things "oddities".

Turned on options (under kernel hacking):
   Locking API boot-time self-tests
   RT Mutex debugging, deadlock detection
   Lock debugging: prove locking correctness

Multiple reboots show it to be a constant.
I had tried the new "Asynchronous SCSI scanning" -- thought that might have been
related, but turning it off makes no difference.

I'm guessing this "error" has been present before this, but the lock
proving algorithms are bringing it to light?  So I don't know how serious
this is (if it is anything), but at the least, it doesn't look too clean...


Maybe that

SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
sd 0:0:0:0: Attached scsi disk sda
UDF-fs: No VRS found
XFS mounting filesystem sda3
Ending clean XFS mount for filesystem: sda3
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 316k freed

=
[ INFO: possible recursive locking detected ]
2.6.20 #3
-
rm/682 is trying to acquire lock:
 (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0

but task is already holding lock:
 (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0

other info that might help us debug this:
3 locks held by rm/682:
 #0:  (>i_mutex/1){--..}, at: [] do_unlinkat+0x96/0x170
 #1:  (>i_mutex){--..}, at: [] vfs_unlink+0x5a/0xd0
 #2:  (&(>i_lock)->mr_lock){}, at: [] xfs_ilock+0x7d/0xb0

stack backtrace:
 [] __lock_acquire+0xaf1/0xdf0
 [] lock_acquire+0x57/0x70
 [] xfs_ilock+0x7d/0xb0
 [] down_write+0x2f/0x50
 [] xfs_ilock+0x7d/0xb0
 [] xfs_ilock+0x7d/0xb0
 [] xfs_lock_dir_and_entry+0xfd/0x100
 [] xfs_remove+0x198/0x4e0
 [] xfs_access+0x26/0x50
 [] xfs_access+0x26/0x50
 [] vfs_unlink+0x5a/0xd0
 [] xfs_vn_unlink+0x23/0x60
 [] __mutex_lock_slowpath+0x152/0x2a0
 [] mark_held_locks+0x6b/0x90
 [] __mutex_lock_slowpath+0x152/0x2a0
 [] __mutex_lock_slowpath+0x152/0x2a0
 [] trace_hardirqs_on+0xc7/0x170
 [] __mutex_lock_slowpath+0x145/0x2a0
 [] vfs_unlink+0x5a/0xd0
 [] permission+0x137/0x140
 [] vfs_unlink+0x90/0xd0
 [] do_unlinkat+0xd3/0x170
 [] do_page_fault+0x327/0x630
 [] sysenter_past_esp+0x5f/0x99
 ===
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] Use resource_size_t for serial port IO addresses

[David Gibson]

At present, various parts of the serial code use unsigned long to
define resource addresses.  This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.

This patch changes the type of mapbase in both struct uart_port and
struct plat_serial8250_port to resource_size_t, which can be
configured to be 64 bits on such platforms.  The mapbase in
serial_struct can't safely be changed, because that structure is user
visible.

Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---

 drivers/serial/8250.c|5 +++--
 drivers/serial/8250_early.c  |   16 +---
 drivers/serial/serial_core.c |9 +
 include/linux/serial_8250.h  |2 +-
 include/linux/serial_core.h  |2 +-
 5 files changed, 19 insertions(+), 15 deletions(-)

Index: working-2.6/include/linux/serial_core.h
===
--- working-2.6.orig/include/linux/serial_core.h2007-02-19 
11:07:42.0 +1100
+++ working-2.6/include/linux/serial_core.h 2007-02-19 11:07:43.0 
+1100
@@ -273,7 +273,7 @@ struct uart_port {
const struct uart_ops   *ops;
unsigned intcustom_divisor;
unsigned intline;   /* port index */
-   unsigned long   mapbase;/* for ioremap */
+   resource_size_t mapbase;/* for ioremap */
struct device   *dev;   /* parent device */
unsigned char   hub6;   /* this should be in 
the 8250 driver */
unsigned char   unused[3];
Index: working-2.6/drivers/serial/serial_core.c
===
--- working-2.6.orig/drivers/serial/serial_core.c   2007-02-19 
11:07:42.0 +1100
+++ working-2.6/drivers/serial/serial_core.c2007-02-19 11:07:43.0 
+1100
@@ -633,7 +633,7 @@ static int uart_get_info(struct uart_sta
tmp.hub6= port->hub6;
tmp.io_type = port->iotype;
tmp.iomem_reg_shift = port->regshift;
-   tmp.iomem_base  = (void *)port->mapbase;
+   tmp.iomem_base  = (void *)(unsigned long)port->mapbase;
 
if (copy_to_user(retinfo, , sizeof(*retinfo)))
return -EFAULT;
@@ -1673,10 +1673,11 @@ static int uart_line_info(char *buf, str
return 0;
 
mmio = port->iotype >= UPIO_MEM;
-   ret = sprintf(buf, "%d: uart:%s %s%08lX irq:%d",
+   ret = sprintf(buf, "%d: uart:%s %s%08llX irq:%d",
port->line, uart_type(port),
mmio ? "mmio:0x" : "port:",
-   mmio ? port->mapbase : (unsigned long) port->iobase,
+   mmio ? (unsigned long long)port->mapbase
+: (unsigned long long) port->iobase,
port->irq);
 
if (port->type == PORT_UNKNOWN) {
@@ -2069,7 +2070,7 @@ uart_report_port(struct uart_driver *drv
case UPIO_AU:
case UPIO_TSI:
snprintf(address, sizeof(address),
-"MMIO 0x%lx", port->mapbase);
+"MMIO 0x%llx", (unsigned long long)port->mapbase);
break;
default:
strlcpy(address, "*unknown*", sizeof(address));
Index: working-2.6/drivers/serial/8250_early.c
===
--- working-2.6.orig/drivers/serial/8250_early.c2007-02-19 
11:07:40.0 +1100
+++ working-2.6/drivers/serial/8250_early.c 2007-02-19 11:07:43.0 
+1100
@@ -145,8 +145,9 @@ static int __init parse_options(struct e
port->mapbase = simple_strtoul(options + 5, , 0);
port->membase = ioremap(port->mapbase, mapsize);
if (!port->membase) {
-   printk(KERN_ERR "%s: Couldn't ioremap 0x%lx\n",
-   __FUNCTION__, port->mapbase);
+   printk(KERN_ERR "%s: Couldn't ioremap 0x%llx\n",
+   __FUNCTION__,
+  (unsigned long long)port->mapbase);
return -ENOMEM;
}
mmio = 1;
@@ -168,9 +169,10 @@ static int __init parse_options(struct e
device->baud);
}
 
-   printk(KERN_INFO "Early serial console at %s 0x%lx (options '%s')\n",
+   printk(KERN_INFO "Early serial console at %s 0x%llx (options '%s')\n",
mmio ? "MMIO" : "I/O port",
-   mmio ? port->mapbase : (unsigned long) port->iobase,
+   mmio ? (unsigned long long) port->mapbase
+: (unsigned long long) port->iobase,
device->options);
return 0;
 }
@@ -236,10 +238,10 @@ static int __init early_uart_console_swi
mmio = 

[PATCH 1/2] Define FIXED_PORT flag for serial_core

[David Gibson]

At present, the serial core always allows setserial in userspace to
change the port address, irq and base clock of any serial port.  That
makes sense for legacy ISA ports, but not for (say) embedded ns16550
compatible serial ports at peculiar addresses.  In these cases, the
kernel code configuring the ports must know exactly where they are,
and their clocking arrangements (which can be unusual on embedded
boards).  It doesn't make sense for userspace to change these
settings.

Therefore, this patch defines a UPF_FIXED_PORT flag for the uart_port
structure.  If this flag is set when the serial port is configured,
any attempts to alter the port's type, io address, irq or base clock
with setserial are ignored.

In addition this patch uses the new flag for on-chip serial ports
probed in arch/powerpc/kernel/legacy_serial.c, and for other
hard-wired serial ports probed by drivers/serial/of_serial.c.

Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---

 arch/powerpc/kernel/legacy_serial.c |3 ++-
 drivers/serial/of_serial.c  |3 ++-
 drivers/serial/serial_core.c|   22 +-
 include/linux/serial_core.h |1 +
 4 files changed, 18 insertions(+), 11 deletions(-)

Index: working-2.6/drivers/serial/serial_core.c
===
--- working-2.6.orig/drivers/serial/serial_core.c   2007-02-19 
11:05:32.0 +1100
+++ working-2.6/drivers/serial/serial_core.c2007-02-20 11:38:08.0 
+1100
@@ -672,19 +672,21 @@ static int uart_set_info(struct uart_sta
 */
mutex_lock(>mutex);
 
-   change_irq  = new_serial.irq != port->irq;
+   change_irq  = !(port->flags & UPF_FIXED_PORT)
+   && new_serial.irq != port->irq;
 
/*
 * Since changing the 'type' of the port changes its resource
 * allocations, we should treat type changes the same as
 * IO port changes.
 */
-   change_port = new_port != port->iobase ||
- (unsigned long)new_serial.iomem_base != port->mapbase ||
- new_serial.hub6 != port->hub6 ||
- new_serial.io_type != port->iotype ||
- new_serial.iomem_reg_shift != port->regshift ||
- new_serial.type != port->type;
+   change_port = !(port->flags & UPF_FIXED_PORT)
+   && (new_port != port->iobase ||
+   (unsigned long)new_serial.iomem_base != port->mapbase ||
+   new_serial.hub6 != port->hub6 ||
+   new_serial.io_type != port->iotype ||
+   new_serial.iomem_reg_shift != port->regshift ||
+   new_serial.type != port->type);
 
old_flags = port->flags;
new_flags = new_serial.flags;
@@ -796,8 +798,10 @@ static int uart_set_info(struct uart_sta
}
}
 
-   port->irq  = new_serial.irq;
-   port->uartclk  = new_serial.baud_base * 16;
+   if (change_irq)
+   port->irq  = new_serial.irq;
+   if (! (port->flags & UPF_FIXED_PORT))
+   port->uartclk  = new_serial.baud_base * 16;
port->flags= (port->flags & ~UPF_CHANGE_MASK) |
 (new_flags & UPF_CHANGE_MASK);
port->custom_divisor   = new_serial.custom_divisor;
Index: working-2.6/include/linux/serial_core.h
===
--- working-2.6.orig/include/linux/serial_core.h2007-02-19 
11:05:32.0 +1100
+++ working-2.6/include/linux/serial_core.h 2007-02-20 11:38:08.0 
+1100
@@ -260,6 +260,7 @@ struct uart_port {
 #define UPF_CONS_FLOW  ((__force upf_t) (1 << 23))
 #define UPF_SHARE_IRQ  ((__force upf_t) (1 << 24))
 #define UPF_BOOT_AUTOCONF  ((__force upf_t) (1 << 28))
+#define UPF_FIXED_PORT ((__force upf_t) (1 << 29))
 #define UPF_DEAD   ((__force upf_t) (1 << 30))
 #define UPF_IOREMAP((__force upf_t) (1 << 31))
 
Index: working-2.6/arch/powerpc/kernel/legacy_serial.c
===
--- working-2.6.orig/arch/powerpc/kernel/legacy_serial.c2007-02-15 
10:05:18.0 +1100
+++ working-2.6/arch/powerpc/kernel/legacy_serial.c 2007-02-20 
10:50:16.0 +1100
@@ -115,7 +115,8 @@ static int __init add_legacy_soc_port(st
 {
u64 addr;
const u32 *addrp;
-   upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
+   upf_t flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ
+   | UPF_FIXED_PORT;
struct device_node *tsi = of_get_parent(np);
 
/* We only support ports that have a clock frequency properly
Index: working-2.6/drivers/serial/of_serial.c
===
--- working-2.6.orig/drivers/serial/of_serial.c 2007-02-20 

Use resource_size_t for serial MMIO addresses

[David Gibson]

Andrew, please apply to -mm.  I think these should be good to merge
for 2.6.22.

At present, MMIO addresses for serial port (the ->mapbase field in
uart_port and other structures) are unsigned longs.  This causes
problems on some 32-bit platforms which have a >32-bit physical
address bus, for example the embedded PowerPC 440GP chip, which has a
36-bit physical address bus, and on-chip serial ports located at an
MMIO address above 4GB.

The second patch in this series changes mapbase to a resource_size_t
(which can be 64-bit on the problematic platforms) in struct uart_port
and struct plat_serial8250_port.  It does *not* change the type in
serial_struct, because that structure is exposed to userspace.  It is
therefore unsafe to use setserial to change the address parameters on
a port using a mapbase above 4GB.

The first patch in the series contains the damage of the setserial
problem.  It allows serial ports to be marked with a new
UPF_FIXED_PORT flag, which causes any attempts to change the port's
type (PIO/MMIO etc.), address or irq with setserial to be ignored.
While using setserial to alter the port address is useful for legacy
ISA ports, it is generally a bad idea for ports such as on-chip or
other hardwired ports where the arch code has good information (from
firmware or hardware probing) on the port's type and address.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NCPFS and brittle connections

[Petr Vandrovec]

Pierre Ossman wrote:

Sorry this took so long but I got occupied with other things and this
had to move down the pile a bit.

New patch which uses dedicated buffers for the currently active packet.
Also adds a new state RQ_ABANDONED which basically means "the caller no
longer cares about this request so the pointers are no longer valid". It
is used to determine if the global receive buffer should be copied to
the provided one upon completion.


Hello,
  it would be nice if these two copies (request->txbuf, and 
rxbuf->reply) could be eliminated, but I see no easy way how to do that...



commit 166fb223f9507431fb97820549e3e41980987445
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date:   Mon Feb 19 11:34:43 2007 +0100

ncpfs: make sure server connection survives a kill

Use internal buffers instead of the ones supplied by the caller

so that a caller can be interrupted without having to abort the
entire ncp connection.

Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>


Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
(modulo one thing below)


diff --git a/include/linux/ncp_fs_sb.h b/include/linux/ncp_fs_sb.h
index a503052..d5e7ffc 100644
--- a/include/linux/ncp_fs_sb.h
+++ b/include/linux/ncp_fs_sb.h
@@ -50,6 +50,8 @@ struct ncp_server {
int packet_size;
unsigned char *packet;  /* Here we prepare requests and
   receive replies */
+   unsigned char *txbuf;   /* Storage for current requres */


Looks like a typo?  requres => request ?


+   unsigned char *rxbuf;   /* Storage for reply to current request */
 
 	int lock;		/* To prevent mismatch in protocols. */

struct mutex mutex;


Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux

[H. Peter Anvin]

Rodolfo Giometti wrote:


Please read the following consideratios before sending to /dev/null!
:)

RFC considerations
--

While implementing a PPS API as RFC 2783 defines and using an embedded
CPU GPIO-Pin as physical link to the signal, I encountered a deeper
problem:

   At startup it needs a file descriptor as argument for the function
   time_pps_create().

This implies that the source has a /dev/... entry. This assumption is
ok for the serial and parallel port, where you can do something
usefull beside(!) the gathering of timestamps as it is the central
task for a PPS-API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
precondition for the use of a PPS-API.



It's not a precondition for a file descriptor, either.  There are plenty 
of ioctl-only device drivers in existence.


Furthermore, a file descriptor doesn't imply a device entry.  Consider 
pipe(2), for example.


As far as the kernel is concerned, a file handle is a nice, uniform 
system for providing communication between the kernel and user space. 
It doesn't matter if one can read() or write() on it; it's perfectly 
normal to support only a subset of the normal operations.


-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial related oops

[Robert Hancock]

Michael K. Edwards wrote:

Still open, though it's a pity you're more interested in my flawed
understanding that in the possibility that the kernel could be
systematically made more robust against hardware bugs and coding
errors by the simple expedient of putting all the ISRs in before
turning on any IRQ that might be shared.  Or are you telling me that's
already been done?  (Yes, I am aware that this interacts
entertainingly with hot-plug PCI.  Yes, I am aware that there is a
limit to how much software can fix stupid hardware.  But surely there
is room for an emergency IRQ suppressor to let chip initialization
code kick in and force the hardware to a known state.)


How do you propose to do this? Drivers can get loaded and unloaded at any
time. If you have a device generating spurious interrupts on a shared IRQ
line, there's no way you can use any device on that line until that interrupt
is shut off. Requiring all drivers to be loaded before any of them can use
interrupts is simply not practical.

If a system has a device that generates interrupts before they're enabled,
and the firmware doesn't fix it, then some platform-specific quirk has to
handle it and shut off the interrupt before it allows any interrupts
to be enabled. (We have such a quirk for certain network controllers where
the boot ROM can leave the chip generating interrupts on bootup.)

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial related oops

[Michael K. Edwards]

On 2/19/07, Russell King <[EMAIL PROTECTED]> wrote:

This can't happen because when __do_irq unmasks the interrupt source,
the CPU mask is set, thereby preventing any further interrupt exceptions
being taken.  This is done precisely to prevent this situation happening.

If you are seeing recursion for the same interrupt (two or more stack
frames containing asm_do_IRQ for that very same IRQ) then your interrupt
handling is buggy, plain and simple.


Imaginable.  I'll look at the mask/unmask code.  Thanks.


I don't doubt that it is on the same IRQ line - I have such setups here
and it works perfectly - multiple 8250 UARTs connected to a single
level-triggered interrupt input which also happens to be shared with
a SCSI host chip as well.  Absolutely no problems.


Can you do me a favor?  In the sys_open("/dev/console") path, turn on
the right bits in that second uart's IER, then insert a sleep in
request_irq or something (wherever seems best based on that
backtrace), and feed enough characters into the second UART during
that sleep to generate an IRQ.  Do you not get the same soft lockup?


I still say that your understanding is completely flawed.  Moreover,
you haven't read what I've said about the ordering of initialisation,
the stress on when we disable interrupts for the ports, etc.


Well, all I can say is that that's a real backtrace and it shouldn't
be hard to reproduce if it's anything other than a broken interrupt
controller or broken code called by the __do_irq postamble.  I don't
see any platform-provided unmask routines in that backtrace, but maybe
it got inlined; I'll go back and check.


You're actually *not* helping.  You're causing utter confusion through
misunderstanding, but it seems you're not open to the possibility that
your understanding is flawed.


Still open, though it's a pity you're more interested in my flawed
understanding that in the possibility that the kernel could be
systematically made more robust against hardware bugs and coding
errors by the simple expedient of putting all the ISRs in before
turning on any IRQ that might be shared.  Or are you telling me that's
already been done?  (Yes, I am aware that this interacts
entertainingly with hot-plug PCI.  Yes, I am aware that there is a
limit to how much software can fix stupid hardware.  But surely there
is room for an emergency IRQ suppressor to let chip initialization
code kick in and force the hardware to a known state.)


I'm offering to look through your code and point you at the source of
your issue for free.  Please don't throw that offer away without first
considering that maybe I have a clue about what's going on here.


I appreciate that offer, and I hope to take advantage of it as soon as
I have the source code at my fingertips (not just the chat log where I
recorded the backtrace).


... which showed the port being opened well after system initialisation
of devices, including all serial ports - including disabling of their
interrupt source at the IER, has been completed.


Now that you mention it, the backtrace I sent is the
serial8250_startup one, not the serial8250_init one.  Sorry, this
one's probably an artifact of brain damage specific to this UART.  I
need to dig through a different account to find the init-path example;
but in either case, we're getting a new interrupt during the __do_irq
postamble.  If you're telling me that that shouldn't happen, what
should the backtrace for a soft lockup due to a stuck level-triggered
IRQ look like on ARM?


Yes, and it's the same for any serial console with functioning break
support.  You'll find it in Documentation/sysrq.txt, though it does
misleadingly say "PC style standard serial ports only" whereas the
reality is "where possible".


Thank you very much; this will help me get to the bottom of some other
chip-support nastiness on this device.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] make ipc/shm.c:shm_nopage() static

[Eric W. Biederman]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
>>...
>> Changes since 2.6.20-rc6-mm3:
>>...
>> +shm-make-sysv-ipc-shared-memory-use-stacked-files.patch
>>...
>>  Misc
>>...
>
>
> shm_nopage() can become static.

Acked-by: Eric W. Biederman <[EMAIL PROTECTED]>


>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.20-mm2/ipc/shm.c.old2007-02-18 22:58:03.0 +0100
> +++ linux-2.6.20-mm2/ipc/shm.c2007-02-18 22:58:18.0 +0100
> @@ -226,8 +226,8 @@
>   mutex_unlock(_ids(ns).mutex);
>  }
>  
> -struct page *shm_nopage(struct vm_area_struct *vma, unsigned long address,
> - int *type)
> +static struct page *shm_nopage(struct vm_area_struct *vma,
> +unsigned long address, int *type)
>  {
>   struct file *file = vma->vm_file;
>   struct shm_file_data *sfd = shm_file_data(file);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793

[Veronique & Vincent]

Hi again Marcel and Jiri,

I've set up the hid-core.c to DEBUG mode... and it literally got pretty 
verbose...

At line 2114 we finally get the BUG message (I've attached the full dmesg 
also...) :
2104 drivers/usb/input/hid-core.c: report (size 8) (unnumbered)
2105 drivers/usb/input/hid-core.c: report 0 (size 8) =  00 00 00 00 00 00 00 00
2106 hid-debug: input Keyboard.00e0 = 0
2107 hid-debug: input Keyboard.00e1 = 0
2108 hid-debug: input Keyboard.00e2 = 0
2109 hid-debug: input Keyboard.00e3 = 0
2110 hid-debug: input Keyboard.00e4 = 0
2111 hid-debug: input Keyboard.00e5 = 0
2112 hid-debug: input Keyboard.00e6 = 0
2113 hid-debug: input Keyboard.00e7 = 0
2114 BUG: warning at drivers/usb/input/hid-core.c:797/implement()
2115  [] dump_trace+0x69/0x1b6
2116  [] show_trace_log_lvl+0x18/0x2c
2117  [] show_trace+0xf/0x11
2118  [] dump_stack+0x15/0x17
2119  [] hid_output_report+0x1f8/0x2a3
2120  [] hid_submit_ctrl+0x55/0x214
2121  [] hid_submit_report+0x134/0x15f
2122  [] hiddev_ioctl+0x327/0x88a
2123  [] do_ioctl+0x4c/0x62
2124  [] vfs_ioctl+0x24a/0x25c
2125  [] sys_ioctl+0x4c/0x66
2126  [] sysenter_past_esp+0x56/0x79
2127  [] 0xb7f8c410
2128  ===
2129 BUG: warning at drivers/usb/input/hid-core.c:797/implement()
2130  [] dump_trace+0x69/0x1b6
2131  [] show_trace_log_lvl+0x18/0x2c
...
2157  [] 0xb7f8c410
2158  ===
2159 drivers/usb/input/hid-core.c: submitting ctrl urb: Set_Report 
wValue=0x0210 wIndex=0x wLength=7
2160 BUG: warning at drivers/usb/input/hid-core.c:797/implement()
2161  [] dump_trace+0x69/0x1b6
...
2184  [] do_ioctl+0x4c/0x62
2185  [] vfs_ioctl+0x24a/0x25c
2186  [] sys_ioctl+0x4c/0x66
2187  [] sysenter_past_esp+0x56/0x79
2188  [] 0xb7f8c410
2189  ===
2190 drivers/usb/input/hid-core.c: submitting ctrl urb: Set_Report 
wValue=0x0210 wIndex=0x wLength=7
2191 drivers/usb/input/hid-core.c: report (size 8) (unnumbered)
2192 drivers/usb/input/hid-core.c: report 0 (size 8) =  00 00 00 00 00 00 00 00
2193 hid-debug: input Keyboard.00e0 = 0
2194 hid-debug: input Keyboard.00e1 = 0
2195 hid-debug: input Keyboard.00e2 = 0
2196 hid-debug: input Keyboard.00e3 = 0
2197 hid-debug: input Keyboard.00e4 = 0
2198 hid-debug: input Keyboard.00e5 = 0
2199 hid-debug: input Keyboard.00e6 = 0
2200 hid-debug: input Keyboard.00e7 = 0
2201 drivers/usb/input/hid-core.c: report (size 7) (numbered)
2202 drivers/usb/input/hid-core.c: report 16 (size 6) =  ff 80 80 01 00 00
2203 hid-debug: input Undefined.0001 = 1
2204 hid-debug: input c06a.8f60 = 1
2205 hid-debug: input c06a.8f60 = 1
2206 hid-debug: input ff00.0001 = 1
2207 BUG: warning at drivers/usb/input/hid-core.c:797/implement()
2208  [] dump_trace+0x69/0x1b6
2209  [] show_trace_log_lvl+0x18/0x2c
2210  [] show_trace+0xf/0x11
2211  [] dump_stack+0x15/0x17
2212  [] hid_output_report+0x1f8/0x2a3
2213  [] hid_submit_ctrl+0x55/0x214
2214  [] hid_submit_report+0x134/0x15f
2215  [] hiddev_ioctl+0x327/0x88a
2216  [] do_ioctl+0x4c/0x62
2217  [] vfs_ioctl+0x24a/0x25c
2218  [] sys_ioctl+0x4c/0x66
2219  [] sysenter_past_esp+0x56/0x79
2220  [] 0xb7f8c410
2221  ===
 BUG: warning at drivers/usb/input/hid-core.c:797/implement()
...
2249  [] sysenter_past_esp+0x56/0x79
2250  [] 0xb7f8c410
2251  ===
2252 drivers/usb/input/hid-core.c: submitting ctrl urb: Set_Report 
wValue=0x0210 wIndex=0x wLength=7
2253 drivers/usb/input/hid-core.c: report (size 7) (numbered)
2254 drivers/usb/input/hid-core.c: report 16 (size 6) =  ff 80 00 00 30 00
2255 hid-debug: input ff00.0001 = 0
2256 hid-debug: input Button.0001 = 1
2257 drivers/usb/input/hid-core.c: report (size 7) (numbered)
2258 drivers/usb/input/hid-core.c: report 16 (size 6) =  ff 81 80 01 00 00
2259 hid-debug: input ff00.0001 = 1
2260 hid-debug: input Button.0001 = 0
2261 Bluetooth: Core ver 2.11
2262 NET: Registered protocol family 31
2263 Bluetooth: HCI device and connection manager initialized
2264 Bluetooth: HCI socket layer initialized
2265 Bluetooth: L2CAP ver 2.8
2266 Bluetooth: L2CAP socket layer initialized
2267 Bluetooth: RFCOMM socket layer initialized
2268 Bluetooth: RFCOMM TTY layer initialized
2269 Bluetooth: RFCOMM ver 1.8
2270 usb 2-2.1: new full speed USB device using uhci_hcd and address 5
2271 drivers/usb/input/hid-core.c: report (size 8) (unnumbered)
2272 drivers/usb/input/hid-core.c: report 0 (size 8) =  00 00 00 00 00 00 00 00
2273 hid-debug: input Keyboard.00e0 = 0
2274 hid-debug: input Keyboard.00e1 = 0
2275 hid-debug: input Keyboard.00e2 = 0
2276 hid-debug: input Keyboard.00e3 = 0
2277 hid-debug: input Keyboard.00e4 = 0
2278 hid-debug: input Keyboard.00e5 = 0
2279 hid-debug: input Keyboard.00e6 = 0
2280 hid-debug: input Keyboard.00e7 = 0
2281 usb 2-2.1: configuration #1 chosen from 1 choice
2282 Bluetooth: HCI USB driver ver 2.9
2283 usbcore: registered new interface driver hci_usb
2284 drivers/usb/input/hid-core.c: report (size 7) (numbered)
2285 drivers/usb/input/hid-core.c: report 2 (size 6) =  00 00 00 00 

Re: [xfs-masters] [2.6 patch] make xfs_buftarg_list static again

[Timothy Shimmin]

Hi Adrian,

--On 20 February 2007 1:07:47 AM +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote:


xfs_buftarg_list became global for no good reason.



That's true. I'll make the change for git if Dave has no objections.

It happened because in the SGI tree we want it global for use in kdb by 
xfsidbg.o,
and that used to happen in the CONFIG_XFS_DEBUG case where STATIC would define
to nothing - looks like it is global always in our tree now since Dave's patch.
i.e. it was actually becoming global previously via STATIC on CONFIG_XFS_DEBUG
but one wouldn't have noticed that :) AFAICT.
Hmmm, I'll talk to Dave about this.

--Tim


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.20-mm2/fs/xfs/linux-2.6/xfs_buf.c.old 2007-02-18 
22:55:40.0 +0100
+++ linux-2.6.20-mm2/fs/xfs/linux-2.6/xfs_buf.c 2007-02-18 22:56:08.0 
+0100
@@ -1424,7 +1424,7 @@
 /*
  * buftarg list for delwrite queue processing
  */
-LIST_HEAD(xfs_buftarg_list);
+static LIST_HEAD(xfs_buftarg_list);
 static DEFINE_SPINLOCK(xfs_buftarg_lock);

 STATIC void







-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL vs non-GPL device drivers

[David Schwartz]

Combined responses

> On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> > There is no legal meaning to "combining" two works of authorship under
> > the Berne Convention or any national implementation thereof.  If you
> > "compile" or "collect" them, you're in one area of law, and if you
> > create a work that "adapts" or "recasts" (or more generally "derives
> > from") them, you're in another area of law.

> As I said, you're having a purely semantic argument.

When someone uses a term that can mean more than one possible thing and then
uses the fact that it's true for one meaning to argue that it must be true
for the other, what else can you do other than point out that the term they
are using has multiple meanings?

> Regardless of what you *call* it, shoving two works together does not
> excuse you from the conditions of the license on one of those works,
> *when you make a copy*.

Nobody is arguing otherwise. Nobody is saying "you don't have to comply with
the GPL". We're saying that the GPL doesn't mean what people think it means.
In some cases it's because of the GPL's wording, but in other cases it's
because the GPL cannot set its own scope.

> And that's the GPL in a nutshell, if you want
> to copy the work, you need a license, if you want a license, you must
> abide the conditions, and one of the conditions is that you may not
> combine it with a work that is under an incompatible license unless it
> is mere aggregation.

Right. And all the cases we are talking about are mere aggregation (that is,
they do not create derivative works).

> Of course, now you're going to argue that there's no such thing as an
> "incompatible license" or "mere aggregation" and that these are just
> words that were made up for the GPL, so they can be ignored.. another
> pointless semantic argument because it doesn't change the very simple
> fact that you don't have any rights to copy the work unless you have a
> license and you don't have a license if you fail to abide the
> conditions of the license.

The issue is about what the license *means* and what its scope is. For
example, if the license said "if you ever use a work that is subject to this
license, you must place every work you create after that under the license",
that would obviously not be enforceable. The question of the *scope* of the
license is critical, and you can't read the license to understand its scope.

> Hang on, you're actually debating that you have to abide by conditions
> of a license before you can copy a copyright work?

Well, there are certainly cases where you can. Necessary step, first sale,
and fair use all provide possible situations where you can copy a
copyrighted work without complying with the license. But more generally, the
argument is over the scope of the license.

The GPL doesn't restrict the distribution of mere aggregations not because
the authors felt this was a wise decision, but because it *can't*. That is
outside the GPL's power. So the question of what's a "mere aggregation" is a
legal question about the scope of the GPL, and you have to look at law and
case law to understand it, not the text of the GPL.

The GPL grants you the permission to modify and distribute the original work
if you distribute the source of the original work. The GPL also puts certain
requirements on the distribution of derivative works. This is, as far as I
can tell, the maximum of the scope it can have.

You are trying to cram this in a simple yes or no box, and it just doesn't
fit. There are questions nobody knows the answers to (such as what rights
you need to distribute a derivative work or whether compiling code makes a
translation).

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent and not-so problems with tifm_sd driver

[Alex Dubov]

> > 
> > mmc_rescan
> >   mmc_register_card
> > device_add
> >   mmc_block_probe
> > mmc_block_alloc
> >   -> queue thread starts running
> > add_disk
> >   -> issues a lot of requests; card fails, my drivers calls 
> > mmc_remove_host, which in 

correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - 
noticed it only now

> >  turn calls device_del, though we are still in device_add
> > 
> 

That's why I think that simply flushing the workqueue is enough. If workqueue 
is empty we know for
sure that device_add has exited.



 

Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial related oops

[Russell King]

On Mon, Feb 19, 2007 at 04:04:26PM -0800, Michael K. Edwards wrote:
> On 2/19/07, Russell King <[EMAIL PROTECTED]> wrote:
> >The second interrupt comes in, and when you go to disable that
> >source, you inadvertently re-enable the UART interrupt, despite it
> >still being serviced.
> 
> Incorrect.  An attempt has been made to service the interrupt using
> the only ISR currently in the chain for that IRQ -- the ISR for the
> first UART.  That attempt was not successful, and when __do_irq
> unmasks the interrupt source preparatory to exiting interrupt context,
> __irq_svc is dispatched anew.

This can't happen because when __do_irq unmasks the interrupt source,
the CPU mask is set, thereby preventing any further interrupt exceptions
being taken.  This is done precisely to prevent this situation happening.

If you are seeing recursion for the same interrupt (two or more stack
frames containing asm_do_IRQ for that very same IRQ) then your interrupt
handling is buggy, plain and simple.

> >Please show your interrupt controller (mask, unmask, mask_ack)
> >handling functions corresponding with the interrupt which your
> >UART is connected to.
> 
> Don't have 'em handy; I'll be happy to post them when I do, perhaps
> later today.  I would hope they're pretty generic, though; it's a
> Feroceon core pretending to be an ARM926EJ-S, hooked to the usual
> half-assed Marvell imitation of an ARM licensed functional block.
> Trust me for the moment, it's the same IRQ line.

I don't doubt that it is on the same IRQ line - I have such setups here
and it works perfectly - multiple 8250 UARTs connected to a single
level-triggered interrupt input which also happens to be shared with
a SCSI host chip as well.  Absolutely no problems.

> If you don't enjoy this sort of forensics (which I
> for one do not, especially not when there is a project deadline
> looming and a Heisenbug starts firing 9 times out of 10), you might
> consider systematically installing ISRs that know how to shut
> everything up before turning on any interrupt sources at all.

I still say that your understanding is completely flawed.  Moreover,
you haven't read what I've said about the ordering of initialisation,
the stress on when we disable interrupts for the ports, etc.

> I'm not asking for anyone's help except in the
> let's-all-help-one-another spirit.

You're actually *not* helping.  You're causing utter confusion through
misunderstanding, but it seems you're not open to the possibility that
your understanding is flawed.

I'm offering to look through your code and point you at the source of
your issue for free.  Please don't throw that offer away without first
considering that maybe I have a clue about what's going on here.

> Now please take a second look at the backtrace before toasting me
> lightly again.

... which showed the port being opened well after system initialisation
of devices, including all serial ports - including disabling of their
interrupt source at the IER, has been completed.

> Mmm'kay?  Oh, and by the way -- is there an Alt-SysRq
> equivalent on an ARM serial console?

Yes, and it's the same for any serial console with functioning break
support.  You'll find it in Documentation/sysrq.txt, though it does
misleadingly say "PC style standard serial ports only" whereas the
reality is "where possible".

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] libata: FUA updates

[Robert Hancock]

This updates libata FUA support to be more more in line with reality.
FUA support remains off by default.

Add a setting for the fua command-line parameter on libata which enables
FUA only on NCQ-supporting disks.

Update the ata_dev_supports_fua function to remove the blacklisting of
Maxtor BANC1G10 firmware, as there is no conclusive evidence it was ever
needed.

Centralize all of the FUA on/off decisions in this function.

Bypass the checks for FUA command support bit for NCQ disks, since that
bit only applies to non-NCQ FUA, and FUA is part of the spec for NCQ
commands.

When queue depth is set by the user resulting in enabling/disabling
NCQ, trigger a revalidate so that the FUA state will be rechecked,
since disabling/enabling NCQ may also affect FUA support on some disks.

Add a controller flag to indicate it doesn't support FUA commands, and
set this flag for Silicon Image 311x (since that one is known to have
problems) as well as for ITE821x when in smart mode.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

---

Any comments on this version? It's essentially what I posted previously
in "libata FUA revisited", except that the default for FUA support remains
off, so this shouldn't break anything for anyone that doesn't explicitly
enable it.

diff -urp linux-2.6.20-git6/drivers/ata/libata-core.c 
linux-2.6.20-git6edit/drivers/ata/libata-core.c
--- linux-2.6.20-git6/drivers/ata/libata-core.c 2007-02-11 17:31:19.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/libata-core.c 2007-02-19 
16:55:49.0 -0600
@@ -87,7 +87,7 @@ MODULE_PARM_DESC(atapi_dmadir, "Enable A

int libata_fua = 0;
module_param_named(fua, libata_fua, int, 0444);
-MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on)");
+MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on for NCQ drives only, 2=on)");

static int ata_probe_timeout = ATA_TMOUT_INTERNAL / HZ;
module_param(ata_probe_timeout, int, 0444);
diff -urp linux-2.6.20-git6/drivers/ata/libata-scsi.c 
linux-2.6.20-git6edit/drivers/ata/libata-scsi.c
--- linux-2.6.20-git6/drivers/ata/libata-scsi.c 2007-02-11 17:31:19.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/libata-scsi.c 2007-02-19 
16:47:46.0 -0600
@@ -986,7 +986,7 @@ int ata_scsi_change_queue_depth(struct s
struct ata_port *ap = ata_shost_to_port(sdev->host);
struct ata_device *dev;
unsigned long flags;
-   int max_depth;
+   int max_depth, revalidate;

if (queue_depth < 1)
return sdev->queue_depth;
@@ -1003,10 +1003,22 @@ int ata_scsi_change_queue_depth(struct s
scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);

spin_lock_irqsave(ap->lock, flags);
-   if (queue_depth > 1)
+   if (queue_depth > 1 && (dev->flags & ATA_DFLAG_NCQ_OFF)) {
dev->flags &= ~ATA_DFLAG_NCQ_OFF;
-   else
+   revalidate = 1;
+   } else if(!(dev->flags & ATA_DFLAG_NCQ_OFF)) {
dev->flags |= ATA_DFLAG_NCQ_OFF;
+   revalidate = 1;
+   }
+   /* Note: NCQ is switched off if queue depth is set to 1.
+  Thus changing the depth may also enable/disable FUA,
+  which the SCSI layer needs to know about, so we trigger
+  a revalidate. */
+   if(revalidate) {
+   ap->eh_info.action |= ATA_EH_REVALIDATE;
+   ata_port_schedule_eh(ap);
+   }
+
spin_unlock_irqrestore(ap->lock, flags);

return queue_depth;
@@ -1990,27 +2002,46 @@ static unsigned int ata_msense_rw_recove
}

/*
- * We can turn this into a real blacklist if it's needed, for now just
- * blacklist any Maxtor BANC1G10 revision firmware
+ * ata_dev_supports_fua - Determine if this device supports FUA.
+ * @dev: Device to check
+ *
+ * Determine if this device supports FUA based on drive and
+ * controller capabilities.
+ *
+ * LOCKING:
+ * None.
 */
-static int ata_dev_supports_fua(u16 *id)
+static int ata_dev_supports_fua(struct ata_device* dev)
{
-   unsigned char model[ATA_ID_PROD_LEN + 1], fw[ATA_ID_FW_REV_LEN + 1];
-
+   /* Is FUA completely disabled? */
if (!libata_fua)
return 0;
-   if (!ata_id_has_fua(id))
+   
+   /* Does the drive support FUA?
+  NCQ-enabled drives always support FUA, otherwise
+  check if the drive indicates support for FUA commands. */
+   if((dev->flags & (ATA_DFLAG_PIO | ATA_DFLAG_NCQ_OFF |
+ ATA_DFLAG_NCQ)) != ATA_DFLAG_NCQ) {
+   if(libata_fua == 1)
+   /* FUA enabled only for NCQ */
+   return 0;
+   
+   /* Does the drive support FUA commands? */
+   if (!(dev->flags & ATA_DFLAG_LBA48) ||
+   !ata_id_has_fua(dev->id))
+   return 0;
+   
+   /* Can't use FUA if we can only use PIO and can't use
+  WRITE MULTIPLE FUA EXT */
+   

Re: 2.6.20-mm2

[Rafael J. Wysocki]

On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
> wrote:
> 
> > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > > 
> > > Temporarily at
> > > 
> > >   http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > > 
> > > Will appear later at
> > > 
> > >  
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> > 
> > Two problems:
> > 
> > 1) A showstopper with the root partition on RAID1:
> > 
> > md: raid1 personality registered for level 1
> > [--snip--]
> > md: multipath personality registered for level -4
> > register_blkdev: failed to get major for mdp
> > [--snip--]
> > VFS: Cannot open root device "md1" or unknown-block(0,0)
> 
> Someone else reported that against mainline.  Can you please debug it a bit?

For now I can only say 2.6.20 + origin.patch breaks.

However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason.
I'll check that tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] sata_nv: Use notifier for completion checks

[Robert Hancock]

The hardware provides us a notifier register that indicates what command
tags have completed. Use this to determine which CPBs to check, rather
than blindly checking all active CPBs. This should provide a minor
performance win, since if the controller has touched some of these
incomplete CPBs, accessing them will likely result in a cache miss.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c.delayandfixes   2007-02-19 
17:00:14.0 -0600
@@ -853,22 +854,14 @@ static irqreturn_t nv_adma_interrupt(int

if (status & (NV_ADMA_STAT_DONE |
  NV_ADMA_STAT_CPBERR)) {
+   u32 check_commands = notifier | notifier_error;
+   int pos, error = 0;
/** Check CPBs for completed commands */
-
-   if (ata_tag_valid(ap->active_tag)) {
-   /* Non-NCQ command */
-   nv_adma_check_cpb(ap, ap->active_tag,
-   notifier_error & (1 << 
ap->active_tag));
-   } else {
-   int pos, error = 0;
-   u32 active = ap->sactive;
-
-   while ((pos = ffs(active)) && !error) {
-   pos--;
-   error = nv_adma_check_cpb(ap, 
pos,
-   notifier_error & (1 << 
pos) );
-   active &= ~(1 << pos );
-   }
+   while ((pos = ffs(check_commands)) && !error) {
+   pos--;
+   error = nv_adma_check_cpb(ap, pos,
+   notifier_error & (1 << pos) );
+   check_commands &= ~(1 << pos );
}
}
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] sata_nv: Cleanup taskfile setup

[Robert Hancock]

This edits the taskfile setup to more closely match the way that libata
sends the taskfile for other controllers. This avoids putting taskfile writes
into the CPB buffer that are not needed according to the taskfile flags.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c.delayandfixes   2007-02-19 
17:00:14.0 -0600
@@ -662,29 +662,30 @@ static unsigned int nv_adma_tf_to_cpb(st
{
unsigned int idx = 0;

-   cpb[idx++] = cpu_to_le16((ATA_REG_DEVICE << 8) | tf->device | WNB);
-
-   if ((tf->flags & ATA_TFLAG_LBA48) == 0) {
-   cpb[idx++] = cpu_to_le16(IGN);
-   cpb[idx++] = cpu_to_le16(IGN);
-   cpb[idx++] = cpu_to_le16(IGN);
-   cpb[idx++] = cpu_to_le16(IGN);
-   cpb[idx++] = cpu_to_le16(IGN);
-   }
-   else {
-   cpb[idx++] = cpu_to_le16((ATA_REG_ERR   << 8) | 
tf->hob_feature);
-   cpb[idx++] = cpu_to_le16((ATA_REG_NSECT << 8) | tf->hob_nsect);
-   cpb[idx++] = cpu_to_le16((ATA_REG_LBAL  << 8) | tf->hob_lbal);
-   cpb[idx++] = cpu_to_le16((ATA_REG_LBAM  << 8) | tf->hob_lbam);
-   cpb[idx++] = cpu_to_le16((ATA_REG_LBAH  << 8) | tf->hob_lbah);
-   }
-   cpb[idx++] = cpu_to_le16((ATA_REG_ERR<< 8) | tf->feature);
-   cpb[idx++] = cpu_to_le16((ATA_REG_NSECT  << 8) | tf->nsect);
-   cpb[idx++] = cpu_to_le16((ATA_REG_LBAL   << 8) | tf->lbal);
-   cpb[idx++] = cpu_to_le16((ATA_REG_LBAM   << 8) | tf->lbam);
-   cpb[idx++] = cpu_to_le16((ATA_REG_LBAH   << 8) | tf->lbah);
+   if(tf->flags & ATA_TFLAG_ISADDR) {
+   if (tf->flags & ATA_TFLAG_LBA48) {
+   cpb[idx++] = cpu_to_le16((ATA_REG_ERR   << 8) | 
tf->hob_feature | WNB);
+   cpb[idx++] = cpu_to_le16((ATA_REG_NSECT << 8) | 
tf->hob_nsect);
+   cpb[idx++] = cpu_to_le16((ATA_REG_LBAL  << 8) | 
tf->hob_lbal);
+   cpb[idx++] = cpu_to_le16((ATA_REG_LBAM  << 8) | 
tf->hob_lbam);
+   cpb[idx++] = cpu_to_le16((ATA_REG_LBAH  << 8) | 
tf->hob_lbah);
+   cpb[idx++] = cpu_to_le16((ATA_REG_ERR<< 8) | 
tf->feature);
+   } else
+   cpb[idx++] = cpu_to_le16((ATA_REG_ERR<< 8) | 
tf->feature | WNB);
+   
+   cpb[idx++] = cpu_to_le16((ATA_REG_NSECT  << 8) | tf->nsect);
+   cpb[idx++] = cpu_to_le16((ATA_REG_LBAL   << 8) | tf->lbal);
+   cpb[idx++] = cpu_to_le16((ATA_REG_LBAM   << 8) | tf->lbam);
+   cpb[idx++] = cpu_to_le16((ATA_REG_LBAH   << 8) | tf->lbah);
+   }
+   
+   if(tf->flags & ATA_TFLAG_DEVICE)
+   cpb[idx++] = cpu_to_le16((ATA_REG_DEVICE << 8) | tf->device);

cpb[idx++] = cpu_to_le16((ATA_REG_CMD<< 8) | tf->command | CMDEND);
+   
+   while(idx < 12)
+   cpb[idx++] = cpu_to_le16(IGN);

return idx;
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] sata_nv: Add CPB register info to error_handler output

[Robert Hancock]

When error handling occurs with pending commands, output the contents
of the next CPB count and next CPB index registers as well as the others,
since these may be useful for debugging.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c.delayandfixes   2007-02-19 
17:00:14.0 -0600
@@ -1462,10 +1461,14 @@ static void nv_adma_error_handler(struct
u32 notifier_error = readl(mmio + 
NV_ADMA_NOTIFIER_ERROR);
u32 gen_ctl = readl(pp->gen_block + NV_ADMA_GEN_CTL);
u32 status = readw(mmio + NV_ADMA_STAT);
+   u8 cpb_count = readb(mmio + NV_ADMA_CPB_COUNT);
+   u8 next_cpb_idx = readb(mmio + NV_ADMA_NEXT_CPB_IDX);

ata_port_printk(ap, KERN_ERR, "EH in ADMA mode, notifier 
0x%X "
-   "notifier_error 0x%X gen_ctl 0x%X status 
0x%X\n",
-   notifier, notifier_error, gen_ctl, status);
+   "notifier_error 0x%X gen_ctl 0x%X status 0x%X "
+   "next cpb count 0x%X next cpb idx 0x%x\n",
+   notifier, notifier_error, gen_ctl, status,
+   cpb_count, next_cpb_idx);

for( i=0;icpb[i];

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] sata_nv: enable hotplug interrupt and fix some readl/readw mismatches

[Robert Hancock]

We already have code that handles hotplug interrupt indications in ADMA
mode, this turns on the control flag that actually enables these interrupts.
Also fixes some cases in the same functions where a 16-bit register was read
using a readl instead of a readw.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c.delayandfixes   2007-02-19 
17:00:14.0 -0600
@@ -1041,14 +1034,15 @@ static int nv_adma_port_start(struct ata

/* clear GO for register mode, enable interrupt */
tmp = readw(mmio + NV_ADMA_CTL);
-   writew( (tmp & ~NV_ADMA_CTL_GO) | NV_ADMA_CTL_AIEN, mmio + NV_ADMA_CTL);
+   writew( (tmp & ~NV_ADMA_CTL_GO) | NV_ADMA_CTL_AIEN |
+NV_ADMA_CTL_HOTPLUG_IEN, mmio + NV_ADMA_CTL);

tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp | NV_ADMA_CTL_CHANNEL_RESET, mmio + NV_ADMA_CTL);
-   readl( mmio + NV_ADMA_CTL );/* flush posted write */
+   readw( mmio + NV_ADMA_CTL );/* flush posted write */
udelay(1);
writew(tmp & ~NV_ADMA_CTL_CHANNEL_RESET, mmio + NV_ADMA_CTL);
-   readl( mmio + NV_ADMA_CTL );/* flush posted write */
+   readw( mmio + NV_ADMA_CTL );/* flush posted write */

return 0;
}
@@ -1100,14 +1094,15 @@ static int nv_adma_port_resume(struct at

/* clear GO for register mode, enable interrupt */
tmp = readw(mmio + NV_ADMA_CTL);
-   writew((tmp & ~NV_ADMA_CTL_GO) | NV_ADMA_CTL_AIEN, mmio + NV_ADMA_CTL);
+   writew( (tmp & ~NV_ADMA_CTL_GO) | NV_ADMA_CTL_AIEN |
+NV_ADMA_CTL_HOTPLUG_IEN, mmio + NV_ADMA_CTL);

tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp | NV_ADMA_CTL_CHANNEL_RESET, mmio + NV_ADMA_CTL);
-   readl( mmio + NV_ADMA_CTL );/* flush posted write */
+   readw( mmio + NV_ADMA_CTL );/* flush posted write */
udelay(1);
writew(tmp & ~NV_ADMA_CTL_CHANNEL_RESET, mmio + NV_ADMA_CTL);
-   readl( mmio + NV_ADMA_CTL );/* flush posted write */
+   readw( mmio + NV_ADMA_CTL );/* flush posted write */

return 0;
}
@@ -1490,10 +1493,10 @@ static void nv_adma_error_handler(struct
/* Reset channel */
tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp | NV_ADMA_CTL_CHANNEL_RESET, mmio + NV_ADMA_CTL);
-   readl( mmio + NV_ADMA_CTL );/* flush posted write */
+   readw( mmio + NV_ADMA_CTL );/* flush posted write */
udelay(1);
writew(tmp & ~NV_ADMA_CTL_CHANNEL_RESET, mmio + NV_ADMA_CTL);
-   readl( mmio + NV_ADMA_CTL );/* flush posted write */
+   readw( mmio + NV_ADMA_CTL );/* flush posted write */
}

ata_bmdma_drive_eh(ap, ata_std_prereset, ata_std_softreset,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] sata_nv: various cleanups and fixes

[Robert Hancock]

This patch series contains several fixes for issues I noticed while
debugging some command timeout problems. None of these proved to be
related to that issue, but they fall into the category of things
we should be doing anyway.

Split into separate patches to ease bisecting in case of issues.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] sata_nv: cleanup CPB and APRD initialization

[Robert Hancock]

Clean up the initialization of the CPB and APRD structures so that we
strictly follow the rules for ordering of writes to the CPB flags and
response flags, and prevent duplicate initialization.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c.delayandfixes   2007-02-19 
17:00:14.0 -0600
@@ -1164,11 +1159,7 @@ static void nv_adma_fill_aprd(struct ata
  int idx,
  struct nv_adma_prd *aprd)
{
-   u8 flags;
-
-   memset(aprd, 0, sizeof(struct nv_adma_prd));
-
-   flags = 0;
+   u8 flags = 0;
if (qc->tf.flags & ATA_TFLAG_WRITE)
flags |= NV_APRD_WRITE;
if (idx == qc->n_elem - 1)
@@ -1179,6 +1170,7 @@ static void nv_adma_fill_aprd(struct ata
aprd->addr  = cpu_to_le64(((u64)sg_dma_address(sg)));
aprd->len   = cpu_to_le32(((u32)sg_dma_len(sg))); /* len in bytes */
aprd->flags = flags;
+   aprd->packet_len = 0;
}

static void nv_adma_fill_sg(struct ata_queued_cmd *qc, struct nv_adma_cpb *cpb)
@@ -1199,6 +1191,8 @@ static void nv_adma_fill_sg(struct ata_q
}
if (idx > 5)
cpb->next_aprd = cpu_to_le64(((u64)(pp->aprd_dma + 
NV_ADMA_SGTBL_SZ * qc->tag)));
+   else
+   cpb->next_aprd = cpu_to_le64(0);
}

static int nv_adma_use_reg_mode(struct ata_queued_cmd *qc)
@@ -1231,7 +1225,10 @@ static void nv_adma_qc_prep(struct ata_q
return;
}

-   memset(cpb, 0, sizeof(struct nv_adma_cpb));
+   cpb->resp_flags = NV_CPB_RESP_DONE;
+   wmb();
+   cpb->ctl_flags = 0;
+   wmb();

cpb->len = 3;
cpb->tag = qc->tag;
@@ -1255,6 +1252,8 @@ static void nv_adma_qc_prep(struct ata_q
   finished filling in all of the contents */
wmb();
cpb->ctl_flags = ctl_flags;
+   wmb();
+   cpb->resp_flags = 0;
}

static unsigned int nv_adma_qc_issue(struct ata_queued_cmd *qc)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] libata: warn if speed limited due to 40-wire cable (v2)

[Robert Hancock]

Here's a revised version of my previous patch to warn the user if a
drive's transfer rate is limited because of a 40-wire cable detection.
This one hopefully addresses Alan's previous comments - we now do this
at the very end of the function, and the ugly if condition has been
cleaned up somewhat. Also, it's been inadvertently tested (it seems that
pata_amd Nvidia cable detection is broken in current -git..)

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6/drivers/ata/libata-core.c 2007-02-11 17:31:19.0 
-0600
+++ linux-2.6.20-git6edit/drivers/ata/libata-core.c 2007-02-13 
19:15:58.0 -0600
@@ -3305,19 +3305,7 @@ static void ata_dev_xfermask(struct ata_
xfer_mask = ata_pack_xfermask(ap->pio_mask,
  ap->mwdma_mask, ap->udma_mask);

-   /* Apply cable rule here.  Don't apply it early because when
-* we handle hot plug the cable type can itself change.
-*/
-   if (ap->cbl == ATA_CBL_PATA40)
-   xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
-   /* Apply drive side cable rule. Unknown or 80 pin cables reported
-* host side are checked drive side as well. Cases where we know a
-* 40wire cable is used safely for 80 are not checked here.
-*/
-if (ata_drive_40wire(dev->id) && (ap->cbl == ATA_CBL_PATA_UNK || 
ap->cbl == ATA_CBL_PATA80))
-   xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
-
-
+   /* drive modes available */
xfer_mask &= ata_pack_xfermask(dev->pio_mask,
   dev->mwdma_mask, dev->udma_mask);
xfer_mask &= ata_id_xfermask(dev->id);
@@ -3348,6 +3336,25 @@ static void ata_dev_xfermask(struct ata_
if (ap->ops->mode_filter)
xfer_mask = ap->ops->mode_filter(ap, dev, xfer_mask);

+   /* Apply cable rule here.  Don't apply it early because when
+* we handle hot plug the cable type can itself change.
+* Check this last so that we know if the transfer rate was
+* solely limited by the cable.
+* Unknown or 80 wire cables reported host side are checked
+* drive side as well. Cases where we know a 40wire cable
+* is used safely for 80 are not checked here.
+*/
+   if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA))
+   /* UDMA/44 or higher would be available */
+   if((ap->cbl == ATA_CBL_PATA40) ||
+   (ata_drive_40wire(dev->id) &&
+(ap->cbl == ATA_CBL_PATA_UNK ||
+ ap->cbl == ATA_CBL_PATA80))) {
+   ata_dev_printk(dev, KERN_WARNING,
+"limited to UDMA/33 due to 40-wire cable\n");
+   xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
+   }
+
ata_unpack_xfermask(xfer_mask, >pio_mask,
>mwdma_mask, >udma_mask);
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make xfs_buftarg_list static again

[David Chinner]

On Tue, Feb 20, 2007 at 01:07:47AM +0100, Adrian Bunk wrote:
> xfs_buftarg_list became global for no good reason.

Fallout from a much larger patch. Looks like there were a couple
of STATIC -> static conversions stuffed up. Thanks for catching
this, Adrian.

Tim - another one for you ;)

> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> --- linux-2.6.20-mm2/fs/xfs/linux-2.6/xfs_buf.c.old   2007-02-18 
> 22:55:40.0 +0100
> +++ linux-2.6.20-mm2/fs/xfs/linux-2.6/xfs_buf.c   2007-02-18 
> 22:56:08.0 +0100
> @@ -1424,7 +1424,7 @@
>  /*
>   *   buftarg list for delwrite queue processing
>   */
> -LIST_HEAD(xfs_buftarg_list);
> +static LIST_HEAD(xfs_buftarg_list);
>  static DEFINE_SPINLOCK(xfs_buftarg_lock);
>  
>  STATIC void

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sata_nv: delay on switching between NCQ and non-NCQ commands

[Robert Hancock]

This patch appears to solve some problems with commands timing out in
cases where an NCQ command is immediately followed by a non-NCQ command
(or possibly vice versa). This is a rather ugly solution, but until we
know more about why this is needed, this is about all we can do.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

--- linux-2.6.20-git6edit/drivers/ata/sata_nv.c.before_hacking  2007-02-15 
18:19:13.0 -0600
+++ linux-2.6.20-git6edit/drivers/ata/sata_nv.c 2007-02-15 22:36:02.0 
-0600
@@ -219,6 +219,7 @@
void __iomem *  gen_block;
void __iomem *  notifier_clear_block;
u8  flags;
+   int last_issue_ncq;
};

struct nv_host_priv {
@@ -1260,6 +1261,7 @@
{
struct nv_adma_port_priv *pp = qc->ap->private_data;
void __iomem *mmio = pp->ctl_block;
+   int curr_ncq = (qc->tf.protocol == ATA_PROT_NCQ);

VPRINTK("ENTER\n");

@@ -1274,6 +1276,14 @@
/* write append register, command tag in lower 8 bits
   and (number of cpbs to append -1) in top 8 bits */
wmb();
+
+   if(curr_ncq != pp->last_issue_ncq) {
+   /* Seems to need some delay before switching between NCQ and 
non-NCQ
+  commands, else we get command timeouts and such. */
+   udelay(20);
+   pp->last_issue_ncq = curr_ncq;
+   }
+
writew(qc->tag, mmio + NV_ADMA_APPEND);

DPRINTK("Issued tag %u\n",qc->tag);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

And for those reading along at home, _surely_ you understand the
meanings of "ambiguities in an offer of contract must be construed
against the offeror", "'derivative work' and 'license' are terms of
art in copyright law", and "not a valid limitation of scope".  If not,
I highly recommend to you that master of exposition who goes by "Op.
Cit.".


You're really not helping yourself in making a convincing argument here.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

And for those reading along at home, _surely_ you understand the
meanings of "ambiguities in an offer of contract must be construed
against the offeror", "'derivative work' and 'license' are terms of
art in copyright law", and "not a valid limitation of scope".  If not,
I highly recommend to you that master of exposition who goes by "Op.
Cit.".

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

No, dear, I'm just not interested in convincing you if you can't be
bothered to look back in the thread and Google a bit.  Think of it as
a penny ante, which is pretty cheap in a card game with billion-dollar
table stakes.


Well, with that attitude I can't imagine why people would think you're
a crackpot.. Maybe if you cut back on what you believe the motive is
for Eben Moglen wanting to misconstrue the law and focus on what you
actually claim the law is then people wouldn't mind trawling through
your insane ramblings to find the references that you claim back up
your extraordinary claims.

Now if you care to repeat your references here, without rambling on,
I'm happy to go read them and temporarily suspend my belief that
you're a crackpot.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] fs/9p/vfs_addr.c: make 2 functions static

[Eric Van Hensbergen]

On 2/19/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:

On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-mm1:
>...
>  git-v9fs.patch
>...
>  git trees
>...

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>


Acked-by: Eric Van Hensbergen <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: freezer problems

[Oleg Nesterov]

On 02/20, Rafael J. Wysocki wrote:
>
> BTW, what do you think of the updated patch I sent two messages ago?

Ah, sorry, I just forgot... I think it is nice.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

that's what I figured yes, as you're obviously not interested in
convincing anyone of your opinions, otherwise you wouldn't mind
repeating yourself when someone asks you a simple question.


No, dear, I'm just not interested in convincing you if you can't be
bothered to look back in the thread and Google a bit.  Think of it as
a penny ante, which is pretty cheap in a card game with billion-dollar
table stakes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-mm2

[Rafael J. Wysocki]

On Monday, 19 February 2007 01:00, Andrew Morton wrote:
> On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
> wrote:
> 
> > > netconsole is good.
> > 
> > I know. :-)
> > 
> > In the meantime, I've got something worse on another x86_64 box:
> > 
> > Asus Laptop ACPI Extras version 0.30
> >   L5D model detected, supported
> > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295
> > general protection fault:  [2] PREEMPT
> > last sysfs file: /class/net/eth2/carrier
> > CPU 0
> > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq 
> > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr
> > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1
> > RIP: 0010:[]  [] 
> > __make_request+0x134/0x370
> > RSP: :81005ed659a0  EFLAGS: 00010297
> > RAX:  RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a
> > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0
> > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0
> > R10:  R11:  R12: 810037b4dbb0
> > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0
> > FS:  2ad4a29e6d00() GS:805db000() knlGS:
> > CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0
> > Process pdflush (pid: 178, threadinfo 81005ed64000, task 
> > 810037b060c0)
> > Stack:  810002852540 0001 810037b4dbb0 8026be21
> >  81005ed65a40 0008 810037b4dbb0 0800
> >  0008 8100021d94e0 81005ed65a40 80348e7c
> > Call Trace:
> >  [] mempool_alloc_slab+0x11/0x20
> >  [] generic_make_request+0x1ec/0x230
> 
> yeah. everyone except me is hitting that.

An interesting variant:

[ cut here ]
kernel BUG at block/ll_rw_blk.c:2782!
invalid opcode:  [1] PREEMPT
last sysfs file: /class/net/eth2/carrier
CPU 0
Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq 
snd_seq_device asus_acpi backlight button battery ac dm_mod usbhid pcmcir
Pid: 5060, comm: preload Not tainted 2.6.20-mm2 #4
RIP: 0010:[]  [] 
bio_attempt_back_merge+0x2a/0xa0
RSP: 0018:810045819a58  EFLAGS: 00010202
RAX: 00010080 RBX: 810046946eb0 RCX: 02b26b42
RDX: 0001 RSI: 810046946eb0 RDI: 810037d74a90
RBP: 810045819a68 R08: 810046946eb0 R09: 0400
R10:  R11:  R12: 810046fcc330
R13: 81004a218770 R14: 810037d74a90 R15: 81004a218750
FS:  2acb9c6076f0() GS:805db000() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 2aaac000 CR3: 45855000 CR4: 06e0
Process preload (pid: 5060, threadinfo 810045818000, task 81004a12e140)
Stack:  810046946eb0 810046fcc330 810045819ac8 8034b730
   810046fcc330 0002
 810046946eb0 0008 810046fcc330 0800
Call Trace:
 [] __make_request+0x100/0x370
 [] generic_make_request+0x1ec/0x230
 [] bio_alloc_bioset+0xeb/0x120
 [] submit_bio+0xf6/0x110
 [] bio_alloc+0x10/0x20
 [] mpage_bio_submit+0x22/0x30
 [] do_mpage_readpage+0x505/0x590
 [] _write_unlock_irq+0x36/0x60
 [] add_to_page_cache+0xbb/0xf0
 [] get_page_from_freelist+0x120/0x430
 [] mpage_readpages+0xbe/0x160
 [] ext3_get_block+0x0/0x110
 [] ext3_get_block+0x0/0x110
 [] _spin_unlock+0x30/0x50
 [] get_page_from_freelist+0x220/0x430
 [] ext3_readpages+0x1a/0x20
 [] __do_page_cache_readahead+0x20f/0x330
 [] cp_new_stat+0xf8/0x120
 [] force_page_cache_readahead+0x6d/0xb0
 [] sys_fadvise64_64+0x143/0x1e0
 [] sys_fadvise64+0x9/0x10
 [] system_call+0x7e/0x83


Code: 0f 0b 0f 1f 40 00 eb fe 4c 89 e2 e8 f6 df ff ff 31 d2 85 c0
RIP  [] bio_attempt_back_merge+0x2a/0xa0
 RSP 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forcedeth problems on 2.6.20-rc6-mm3

[Ayaz Abdulla]

Robert Hancock wrote:

Ayaz Abdulla wrote:



For all those who are having issues, please try out the attached patch.

Ayaz


--- 

This email message is for the sole use of the intended recipient(s) 
and may contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact 
the sender by

reply email and destroy all copies of the original message.
--- 






--- orig/drivers/net/forcedeth.c2007-02-08 21:41:59.0 -0500
+++ new/drivers/net/forcedeth.c2007-02-08 21:44:53.0 -0500
@@ -3104,13 +3104,17 @@
 struct fe_priv *np = netdev_priv(dev);
 u8 __iomem *base = get_hwbase(dev);
 unsigned long flags;
+u32 retcode;
 
-if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)

+if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
 pkts = nv_rx_process(dev, limit);
-else
+retcode = nv_alloc_rx(dev);
+} else {
 pkts = nv_rx_process_optimized(dev, limit);
+retcode = nv_alloc_rx_optimized(dev);
+}
 
-if (nv_alloc_rx(dev)) {

+if (retcode) {
 spin_lock_irqsave(>lock, flags);
 if (!np->in_shutdown)
 mod_timer(>oom_kick, jiffies + OOM_REFILL);



Did anyone push this patch into mainline? forcedeth on 2.6.20-git14 is 
still completely broken without this patch.




I have submitted the patch to netdev mailing list.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.16.41

[Greg KH]

On Tue, Feb 20, 2007 at 01:01:10AM +0100, Adrian Bunk wrote:
> On Mon, Feb 19, 2007 at 03:48:46PM -0800, Greg KH wrote:
> > On Sun, Feb 18, 2007 at 02:14:07AM +0100, Adrian Bunk wrote:
> > > Herbert Xu (1):
> > >   [NETFILTER]: Clear GSO bits for TCP reset packet
> > 
> > This patch causes the file it patched to not build at all.  Are you sure
> > it was correct to add this?
> 
> It compiled for me in my test builds.
> 
> Please send the .config and the error message.

Ugh, this was my fault.  It was a distro kernel error as they had
modified their tree in ways I wasn't expecting.

Nevermind, the mainline kernel builds just fine, sorry for the
disturbance.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/char/hvc_console.c: cleanups

[Stephen Rothwell]

On Tue, 20 Feb 2007 01:02:07 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> This patch contains the following cleanups:
> - make needlessly global code static
> - remove the unused EXPORT_SYMBOL's
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>

--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp4DZs9ZHMi1.pgp
Description: PGP signature

RHEL3 2.4.21-37a6smp 10GBps Intel 10GBps NIC: ixgb_clean_tx_irq: Detected Tx Unit Hang - Machine locks up.

[Justin Piszcz]

Quick question,

I am using the latest ixgb driver (1.0.126) as stated both on Intel's 
website and here: http://sourceforge.net/forum/forum.php?forum_id=645203


After a number of hours, sometimes days, I will get this error on the 
console and the box locks up:


ixgb: eth2: ixgb_clean_tx_irq: Detected Tx Unit Hang

Intel told us that the 126 version of this driver was supposed to fix this 
problem.  Is there anyone from Intel on this list or someone who has dealt 
with this issue and has a potential fix?


The Intel Board is 10GBe PCI-X card in a HP DL385.

Can anyone offer some assistance with this issue?

Please CC as I am not on lkml or taroon mailing lists, thanks.

Justin.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86_64: up to 255 or 256 CPUs?

[William Lee Irwin III]

On Tue, Feb 20, 2007 at 01:06:47AM +0100, Adrian Bunk wrote:
> Quoting arch/x86_64/Kconfig:
> <--  snip  -->
> ...
> config NR_CPUS
> int "Maximum number of CPUs (2-256)"
> range 2 255
> ...
> <--  snip  -->
> cu
> Adrian

The broadcast APIC ID clashes with the 256th cpu.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] proper prototype for hugetlb_get_unmapped_area()

[William Lee Irwin III]

On Tue, Feb 20, 2007 at 01:06:34AM +0100, Adrian Bunk wrote:
> This patch adds a proper prototype for hugetlb_get_unmapped_area() in 
> include/linux/hugetlb.h.
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> This patch was already sent on:
> - 25 Nov 2006
>  fs/hugetlbfs/inode.c|5 +
>  include/linux/hugetlb.h |7 +++
>  2 files changed, 8 insertions(+), 4 deletions(-)

I don't see why not.

Acked-by: William Irwin <[EMAIL PROTECTED]>


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forcedeth problems on 2.6.20-rc6-mm3

[Robert Hancock]

Ayaz Abdulla wrote:


For all those who are having issues, please try out the attached patch.

Ayaz


--- 

This email message is for the sole use of the intended recipient(s) and 
may contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact 
the sender by

reply email and destroy all copies of the original message.
--- 






--- orig/drivers/net/forcedeth.c2007-02-08 21:41:59.0 -0500
+++ new/drivers/net/forcedeth.c 2007-02-08 21:44:53.0 -0500
@@ -3104,13 +3104,17 @@
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;
+   u32 retcode;
 
-	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)

+   if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
pkts = nv_rx_process(dev, limit);
-   else
+   retcode = nv_alloc_rx(dev);
+   } else {
pkts = nv_rx_process_optimized(dev, limit);
+   retcode = nv_alloc_rx_optimized(dev);
+   }
 
-	if (nv_alloc_rx(dev)) {

+   if (retcode) {
spin_lock_irqsave(>lock, flags);
if (!np->in_shutdown)
mod_timer(>oom_kick, jiffies + OOM_REFILL);


Did anyone push this patch into mainline? forcedeth on 2.6.20-git14 is 
still completely broken without this patch.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Trent Waddington]

On 2/20/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

Can we put the gamesmanship on "low" here for a moment?  Ask yourself
which is more likely: am I a crank who spends years researching the
legal background of the GPL solely for the purpose of ranting
incoherently on debian-legal and LKML,


that's what I figured yes, as you're obviously not interested in
convincing anyone of your opinions, otherwise you wouldn't mind
repeating yourself when someone asks you a simple question.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: freezer problems

[Rafael J. Wysocki]

On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
> On 02/20, Rafael J. Wysocki wrote:
> >
> > On Monday, 19 February 2007 23:41, Oleg Nesterov wrote:
> > > On 02/19, Rafael J. Wysocki wrote:
> > > >
> > > > On Monday, 19 February 2007 21:23, Oleg Nesterov wrote:
> > > > 
> > > > > > @@ -199,6 +189,10 @@ static void thaw_tasks(int thaw_user_spa
> > > > > >
> > > > > > do_each_thread(g, p) {
> > > > > > +   if (freezer_should_skip(p))
> > > > > > +   cancel_freezing(p);
> > > > > > +   } while_each_thread(g, p);
> > > > > > +   do_each_thread(g, p) {
> > > > > > if (!freezeable(p))
> > > > > > continue;
> > > > > 
> > > > > Any reason for 2 separate do_each_thread() loops ?
> > > > 
> > > > Yes.  If there is a "freeze" request pending for the vfork parent 
> > > > (TIF_FREEZE
> > > > set), we have to cancel it before the child is unfrozen, since 
> > > > otherwise the
> > > > parent may go freezing after we try to reset PF_FROZEN for it.
> > > 
> > > I see, thanks... thaw_process() doesn't take TIF_FREEZE into account.
> > > 
> > > But doesn't this mean we have a race?
> > > 
> > > Suppose that try_to_freeze_tasks() failed. It does cancel_freezing() for 
> > > each
> > > process before return, but what if some thread already checked TIF_FREEZE 
> > > and
> > > (for simplicity) it is preempted before frozen_process() in 
> > > refrigerator().
> > > 
> > > thaw_tasks() runs, ignores this task (P), returns. P gets CPU, and becomes
> > > frozen, but nobody will thaw it.
> > > 
> > > No?
> > 
> > Well, I think this is highly theoretical.  Namely, try_to_freeze_tasks() 
> > only
> > fails after the timeout that's currently set to 20 sec., and it yields the 
> > CPU
> > in each iteration of the main loop.  The task in question would have to 
> > refuse
> > being frozen for 20 sec. and then suddenly decide to freeze itself right 
> > before
> > try_to_freeze_tasks() checks the timeout for the very last time.  Then, it
> > would have to get preempted at this very moment and stay unfrozen at least
> > until thaw_tasks() starts running and in fact even longer.
> 
> Yes, yes, it is pure theroretical,
> 
> > I think we may avoid this by making try_to_freeze_tasks() sleep for some 
> > time
> > after it has reset TIF_FREEZE for all tasks in the error path, if anyone is
> > ever able to trigger it.
> 
> This makes this race  (pure theroretical) ** 2  :)
> 
> Still. May be it make sense to introduce cancel_freezing_and_thaw() function
> (not right now) which stops the task from sleeping in refrigirator reliably.

Hm.  In the case discussed above we have a task that's right before calling
frozen_process(), so we can't thaw it, because it's not frozen.  It will be
frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have no
way to check this.

I think to close this race the refrigerator should check TIF_FREEZE and set
PF_FROZEN _and_ reset TIF_FREEZE under a lock that would also have to be
taken by try_to_freeze_tasks() in the beginning of the error path.  This will
ensure that all tasks either freeze themselves before the error path in
try_to_freeze_tasks() is executed, or remain unfrozen.

I'll try to prepare a patch to illustrate this, but right now I'm too tired to
do it. :-)

> I didn't think much about this, but it looks like we can fix coredump/exec
> problems. Of course, this is not so important, we can ignore them at least
> for now (->vfork_done is different, should be imho solved, because any user
> can block freezer forever).
> 
> The fix:
> 
>   refrigerator:
> 
>   +   // we are going to call do_exit() really soon,
>   +   // we have a pending SIGKILL
>   +   if (current->signal->flags & SIGNAL_GROUP_EXIT)
>   +   return;
> 
>   frozen_process(current);
>   ...
> 
> 
>   zap_other_threads:
> 
>   for_each_subthread() {
>   ...
> 
>   +   //  SIGNAL_GROUP_EXIT is set --
>   +   // we can check sig->group_exit_task to detect 
> de_thread,
>   +   // but perhaps it doesn't hurt if the caller is 
> do_group_exit
>   +   cancel_freezing_and_thaw(p);
>   sigaddset(>pending.signal, SIGKILL);
>   signal_wake_up(t, 1);
>   }
> 
> This way execer reliably kills all sub-threads and proceeds without blocking
> try_to_freeze_tasks(). The same change could be done for zap_process() to fix
> coredump.

Yes, at first sight it looks good.

BTW, what do you think of the updated patch I sent two messages ago?

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Jörn Engel]

On Tue, 20 February 2007 00:57:50 +0100, Juan Piernas Canovas wrote:
> 
> I understand the problem that you describe with respect to the GC, but 
> let me explain why I think that it has a small impact on DualFS.
> 
> Actually, the GC may become a problem when the number of free segments is 
> 50% or less. If your LFS always guarantees, at least, 50% of free 
> "segments" (note that I am talking about segments, not free space), the 
> deadlock problem disappears, right? This is a quite naive solution, but it 
> works.

I don't see how you can guarantee 50% free segments.  Can you explain
that bit?

> In a traditional LFS, with data and meta-data blocks, 50% of free segments 
> represents a huge amount of wasted disk space. But, in DualFS, 50% of free 
> segments in the meta-data device is not too much. In a typical Ext2, 
> or Ext3 file system, there are 20 data blocks for every meta-data block 
> (that is, meta-data blocks are 5% of the disk blocks used by files). 
> Since files are implemented in DualFS in the same way, we can suppose the 
> same ratio for DualFS (1).

This will work fairly well for most people.  It is possible to construct
metadata-heavy workloads, however.  Many large directories containing
symlinks or special files (char/block devices, sockets, fifos,
whiteouts) come to mind.  Most likely noone of your user will ever want
that, but a malicious attacker might.

That, btw, brings me to a completely unrelated topic.  Having a fixed
ratio a metadata to data is simple to implement, but allowing this ratio
to dynamically change would be nicer for administration.  You can add
that to the Christmas wishlist for the nice boys, if you like.

> Remember, I am supposing a naive implementation of the cleaner. With a 
> cleverer one, the meta-data device can be smaller, and the amount of
> disk space finally wasted can be smaller too. The following paper proposes 
> some improvements:
> 
> - Jeanna Neefe Matthews, Drew Roselli, Adam Costello, Randy Wang, and
>   Thomas Anderson.  "Improving the Performance of Log-structured File
>   Systems with Adaptive Methods".  Proc. Sixteenth ACM Symposium on
>   Operating Systems Principles (SOSP), October 1997, pages 238 - 251.
> 
> BTW, I think that what they propose is very similar to the two-strategies 
> GC that you propose in a separate e-mail.

Will have to read it up after I get some sleep.  It is late.

> The point of all the above is that you must improve the common case, and 
> manage the worst case correctly. And that is the idea behind DualFS :)

A fine principle to work with.  Surprisingly, what is the worst case for
you is the common case for LogFS, so maybe I'm more interested in it
than most people.  Or maybe I'm just more paranoid.

Anyway, keep up the work.  It is an interesting idea to pursue.

Jörn

-- 
He who knows that enough is enough will always have enough.
-- Lao Tsu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] aio: propogate post-EIOCBQUEUED errors to completion event

[Chris Mason]

On Mon, Feb 19, 2007 at 07:21:09PM -0500, Benjamin LaHaise wrote:
> On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> > aio is not responsible for this particular synchronization.  Those fixes
> > (if we make them) should come from other places.  The patch is important
> > to get aio error handling right.
> > 
> > I would argue that one common cause of the EIO is userland
> > error (mmap concurrent with O_DIRECT), and EIO is the correct answer.
> 
> I disagree.  That means that using the pagecache to synchronize things like 
> the proposed online defragmentation will occasionally make O_DIRECT users 
> fail.  O_DIRECT doesn't prevent the sysadmin from copying files or other 
> page cache uses, which implies that generating an error in these cases is 
> horrifically broken.  If only root could do it, I wouldn't complain, but 
> this would seem to imply that user vs root holes still exist.

I'm working on this part in the placeholder patches.  It's just a separate
problem from the aio code.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] {rd,wr}msr_on_cpu SMP=n optimization

[Dave Jones]

On Tue, Feb 20, 2007 at 01:21:45AM +0100, Adrian Bunk wrote:
 > On Mon, Feb 19, 2007 at 07:14:34PM -0500, Dave Jones wrote:
 > > On Tue, Feb 20, 2007 at 01:07:13AM +0100, Adrian Bunk wrote:
 > >...
 > >  > +#ifdef CONFIG_SMP
 > >  >  void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
 > >  >  void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
 > >  > +#else  /*  CONFIG_SMP  */
 > >  > +static inline void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, 
 > > u32 *h)
 > >  > +{
 > >  > +   rdmsr(msr_no, *l, *h);
 > >  > +}
 > >  > +static inline void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, 
 > > u32 h)
 > >  > +{
 > >  > +   wrmsr(msr_no, l, h);
 > >  > +}
 > >  > +#endif  /*  CONFIG_SMP  */
 > > 
 > > BUG_ON(cpu!=smp_processor_id()) maybe?
 > 
 > This is the CONFIG_SMP=n case.

Yes. If someone is asking for the MSR on a specific CPU in UP mode,
it's a bug.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL vs non-GPL device drivers

[Michael K. Edwards]

On 2/19/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

Hang on, you're actually debating that you have to abide by conditions
of a license before you can copy a copyright work?

Please, tell us the names of these appellate court decisions so that
we can read them and weep.


Can we put the gamesmanship on "low" here for a moment?  Ask yourself
which is more likely: am I a crank who spends years researching the
legal background of the GPL solely for the purpose of ranting
incoherently on debian-legal and LKML, or am I a mid-career embedded
software developer with an obsessive streak who has come to a
realization how dangerous this whole EXPORT_SYMBOL_GPL business is to
his niche in the industry?  Do I have an irrational hatred for people
named Eben, or am I sick to the heart of seeing decent young kids'
beliefs about the law perverted by a racketeer in attorney's clothing
with (at an informed guess) somewhere between $300K and $2M a year in
easy money from his web of "non-profit" shell companies?  I may be
_wrong_ -- but I'm not _witless_.

Now, if you want to play games, get yourself a copy of this
new-fangled invention called a "web browser", and Google for each set
of capitalized words with a "v." in between that has appeared in my
posts to LKML in the last few days.  For extra credit, follow links to
older posts, cleverly signposted with "http://;.  Repeat ad nauseam.
When you have an argument to offer that isn't already a blenderized
equine, preferably associated with a citation to one of those shiny
URL thingies with an "edu" or a "findlaw" in it, or even one of those
phrases with the magic "v.", I'm all ears.  Good morning -- and if I
don't see ya, good afternoon, good evening, and good night.

- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] aio: propogate post-EIOCBQUEUED errors to completion event

[Zach Brown]

I would argue that one common cause of the EIO is userland
error (mmap concurrent with O_DIRECT), and EIO is the correct answer.


I disagree.  That means that using the pagecache to synchronize  
things like
the proposed online defragmentation will occasionally make O_DIRECT  
users

fail.


Well, only if the pages couldn't be invalidated.  Arguably ext3  
should be trying a lot harder to invalidate before giving up and  
returning failure from invalidate_page().


Hopefully this all goes away in the long term with Chris'  
"placeholder" work that stops insertions into the radix tree while  
dio ops are in flight.


- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] drivers/net/vioc/: possible cleanups

[Adrian Bunk]

On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc6-mm3:
>...
> +Fabric7-VIOC-driver.patch
>...
>  netdev stuff
>...


This patch contains the following possible cleanups:
- remove dead #ifdef EXPORT_SYMTAB code
- no "inline" functions in C files - gcc knows best whether or not to
  inline static functions
- move the vioc_ethtool_ops prototype to a header file
- make needlessly global code static
- #if 0 unused code
- vioc_irq.c: remove the unused vioc_driver_lock

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/vioc/f7/sppapi.h  |2 -
 drivers/net/vioc/khash.h  |   10 -
 drivers/net/vioc/spp.c|   60 +++---
 drivers/net/vioc/vioc_api.c   |5 ++
 drivers/net/vioc/vioc_api.h   |3 +
 drivers/net/vioc/vioc_driver.c|3 -
 drivers/net/vioc/vioc_ethtool.c   |2 -
 drivers/net/vioc/vioc_irq.c   |9 +---
 drivers/net/vioc/vioc_provision.c |   16 +---
 drivers/net/vioc/vioc_receive.c   |2 -
 drivers/net/vioc/vioc_spp.c   |6 +--
 drivers/net/vioc/vioc_transmit.c  |   40 +++-
 12 files changed, 85 insertions(+), 73 deletions(-)

--- linux-2.6.20-mm1/drivers/net/vioc/vioc_driver.c.old 2007-02-18 
01:14:31.0 +0100
+++ linux-2.6.20-mm1/drivers/net/vioc/vioc_driver.c 2007-02-18 
01:14:35.0 +0100
@@ -868,6 +868,3 @@
 module_init(vioc_module_init);
 module_exit(vioc_module_exit);
 
-#ifdef EXPORT_SYMTAB
-EXPORT_SYMBOL(vioc_viocdev);
-#endif /* EXPORT_SYMTAB */
--- linux-2.6.20-mm1/drivers/net/vioc/khash.h.old   2007-02-18 
01:16:28.0 +0100
+++ linux-2.6.20-mm1/drivers/net/vioc/khash.h   2007-02-18 01:25:29.0 
+0100
@@ -52,14 +52,4 @@
 };
 
 
-struct shash_t  *hashT_create(u32, size_t, size_t, u32(*)(unsigned char *, 
unsigned long), int(*)(void *, void *), unsigned int);
-int hashT_delete(struct shash_t * , void *);
-struct hash_elem_t *hashT_lookup(struct shash_t * , void *);
-struct hash_elem_t *hashT_add(struct shash_t *, void *);
-void hashT_destroy(struct shash_t *);
-/* Accesors */
-void **hashT_getkeys(struct shash_t *);
-size_t hashT_tablesize(struct shash_t *);
-size_t hashT_size(struct shash_t *);
-
 #endif
--- linux-2.6.20-mm1/drivers/net/vioc/f7/sppapi.h.old   2007-02-18 
01:26:44.0 +0100
+++ linux-2.6.20-mm1/drivers/net/vioc/f7/sppapi.h   2007-02-18 
01:26:57.0 +0100
@@ -234,7 +234,5 @@
 
 extern void spp_msg_unregister(u32 key_facility);
 
-extern int read_spp_regbank32(int vioc, int bank, char *buffer);
-
 #endif /* _SPPAPI_H_ */
 
--- linux-2.6.20-mm1/drivers/net/vioc/spp.c.old 2007-02-18 01:19:34.0 
+0100
+++ linux-2.6.20-mm1/drivers/net/vioc/spp.c 2007-02-18 01:27:13.0 
+0100
@@ -50,6 +50,15 @@
   c -= a; c -= b; c ^= (b >> 15); \
 }
 
+static struct hash_elem_t *hashT_add(struct shash_t *htable, void *key);
+static struct shash_t *hashT_create(u32 sizehint, size_t keybuf_size,
+size_t databuf_size,
+u32(*hfunc) (unsigned char *,
+unsigned long),
+int (*cfunc) (void *, void *),
+unsigned int flags);
+static void hashT_destroy(struct shash_t *htable);
+static struct hash_elem_t *hashT_lookup(struct shash_t *htable, void *key);
 
 struct shash_t {
/* Common fields for all hash tables types */
@@ -65,7 +74,9 @@
 };
 
 struct hash_ops {
+#if 0
int (*delete) (struct shash_t *, void *);
+#endif  /*  0  */
struct hash_elem_t *(*lookup) (struct shash_t *, void *);
void (*destroy) (struct shash_t *);
struct hash_elem_t *(*add) (struct shash_t *, void *);
@@ -143,6 +154,7 @@
return ((htable->hash_fn(key, len)) & (htable->tsize - 1));
 }
 
+#if 0
 /* Data associated to this key MUST be freed by the caller */
 static int ch_delete(struct shash_t *htable, void *key)
 {
@@ -181,6 +193,7 @@
 
return -1;
 }
+#endif  /*  0  */
 
 static void ch_destroy(struct shash_t *htable)
 {
@@ -232,16 +245,21 @@
 }
 
 /* Accesors **/
-inline size_t hashT_tablesize(struct shash_t * htable)
+
+#if 0
+
+size_t hashT_tablesize(struct shash_t * htable)
 {
return htable->tsize;
 }
 
-inline size_t hashT_size(struct shash_t * htable)
+size_t hashT_size(struct shash_t * htable)
 {
return htable->nelems;
 }
 
+#endif  /*  0  */
+
 static struct hash_elem_t *ch_lookup(struct shash_t *htable, void *key)
 {
u32 idx;
@@ -330,15 +348,17 @@
return 1;
 }
 
-struct hash_ops ch_ops = {
+static struct hash_ops ch_ops = {
+#if 0
.delete = ch_delete,
+#endif  /*  0  */
.lookup = ch_lookup,
.destroy = ch_destroy,
.getkeys = ch_getkeys,
.add = ch_add
 };
 
-struct facility 

[2.6 patch] kill net/rxrpc/rxrpc_syms.c

[Adrian Bunk]

This patch moves the EXPORT_SYMBOL's from net/rxrpc/rxrpc_syms.c to the 
files with the actual functions.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 26 Nov 2006

 net/rxrpc/Makefile |1 -
 net/rxrpc/call.c   |5 +
 net/rxrpc/connection.c |2 ++
 net/rxrpc/rxrpc_syms.c |   34 --
 net/rxrpc/transport.c  |4 
 5 files changed, 11 insertions(+), 35 deletions(-)

--- linux-2.6.19-rc6-mm1/net/rxrpc/Makefile.old 2006-11-26 04:49:25.0 
+0100
+++ linux-2.6.19-rc6-mm1/net/rxrpc/Makefile 2006-11-26 04:50:08.0 
+0100
@@ -12,7 +12,6 @@
krxtimod.o \
main.o \
peer.o \
-   rxrpc_syms.o \
transport.o
 
 ifeq ($(CONFIG_PROC_FS),y)
--- linux-2.6.19-rc6-mm1/net/rxrpc/call.c.old   2006-11-26 04:50:51.0 
+0100
+++ linux-2.6.19-rc6-mm1/net/rxrpc/call.c   2006-11-26 04:51:58.0 
+0100
@@ -314,6 +314,7 @@
_leave(" = %d", ret);
return ret;
 } /* end rxrpc_create_call() */
+EXPORT_SYMBOL(rxrpc_create_call);
 
 /*/
 /*
@@ -465,6 +466,7 @@
 
_leave(" [destroyed]");
 } /* end rxrpc_put_call() */
+EXPORT_SYMBOL(rxrpc_put_call);
 
 /*/
 /*
@@ -923,6 +925,7 @@
return __rxrpc_call_abort(call, error);
 
 } /* end rxrpc_call_abort() */
+EXPORT_SYMBOL(rxrpc_call_abort);
 
 /*/
 /*
@@ -1910,6 +1913,7 @@
}
 
 } /* end rxrpc_call_read_data() */
+EXPORT_SYMBOL(rxrpc_call_read_data);
 
 /*/
 /*
@@ -2076,6 +2080,7 @@
return ret;
 
 } /* end rxrpc_call_write_data() */
+EXPORT_SYMBOL(rxrpc_call_write_data);
 
 /*/
 /*
--- linux-2.6.19-rc6-mm1/net/rxrpc/connection.c.old 2006-11-26 
04:52:08.0 +0100
+++ linux-2.6.19-rc6-mm1/net/rxrpc/connection.c 2006-11-26 04:52:32.0 
+0100
@@ -207,6 +207,7 @@
spin_unlock(>conn_gylock);
goto make_active;
 } /* end rxrpc_create_connection() */
+EXPORT_SYMBOL(rxrpc_create_connection);
 
 /*/
 /*
@@ -411,6 +412,7 @@
 
_leave(" [killed]");
 } /* end rxrpc_put_connection() */
+EXPORT_SYMBOL(rxrpc_put_connection);
 
 /*/
 /*
--- linux-2.6.19-rc6-mm1/net/rxrpc/transport.c.old  2006-11-26 
04:52:43.0 +0100
+++ linux-2.6.19-rc6-mm1/net/rxrpc/transport.c  2006-11-26 04:53:36.0 
+0100
@@ -146,6 +146,7 @@
_leave(" = %d", ret);
return ret;
 } /* end rxrpc_create_transport() */
+EXPORT_SYMBOL(rxrpc_create_transport);
 
 /*/
 /*
@@ -196,6 +197,7 @@
 
_leave("");
 } /* end rxrpc_put_transport() */
+EXPORT_SYMBOL(rxrpc_put_transport);
 
 /*/
 /*
@@ -231,6 +233,7 @@
_leave("= %d", ret);
return ret;
 } /* end rxrpc_add_service() */
+EXPORT_SYMBOL(rxrpc_add_service);
 
 /*/
 /*
@@ -248,6 +251,7 @@
 
_leave("");
 } /* end rxrpc_del_service() */
+EXPORT_SYMBOL(rxrpc_del_service);
 
 /*/
 /*
--- linux-2.6.19-rc6-mm1/net/rxrpc/rxrpc_syms.c 2006-09-20 05:42:06.0 
+0200
+++ /dev/null   2006-09-19 00:45:31.0 +0200
@@ -1,34 +0,0 @@
-/* rxrpc_syms.c: exported Rx RPC layer interface symbols
- *
- * Copyright (C) 2002 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells ([EMAIL PROTECTED])
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-/* call.c */
-EXPORT_SYMBOL(rxrpc_create_call);
-EXPORT_SYMBOL(rxrpc_put_call);
-EXPORT_SYMBOL(rxrpc_call_abort);
-EXPORT_SYMBOL(rxrpc_call_read_data);
-EXPORT_SYMBOL(rxrpc_call_write_data);
-
-/* connection.c */
-EXPORT_SYMBOL(rxrpc_create_connection);
-EXPORT_SYMBOL(rxrpc_put_connection);
-
-/* transport.c */
-EXPORT_SYMBOL(rxrpc_create_transport);
-EXPORT_SYMBOL(rxrpc_put_transport);
-EXPORT_SYMBOL(rxrpc_add_service);
-EXPORT_SYMBOL(rxrpc_del_service);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ 

[2.6 patch] arch/i386/kernel/alternative.c should #include

[Adrian Bunk]

Every file should include the headers containing the prototypes for
it's global functions.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 18 Jan 2007
- 4 Jan 2007

--- linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c.old 2007-01-03 
23:13:18.0 +0100
+++ linux-2.6.20-rc2-mm1/arch/i386/kernel/alternative.c 2007-01-03 
23:13:32.0 +0100
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int no_replacement= 0;
 static int smp_alt_once  = 0;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] {rd,wr}msr_on_cpu SMP=n optimization

[Adrian Bunk]

On Mon, Feb 19, 2007 at 07:14:34PM -0500, Dave Jones wrote:
> On Tue, Feb 20, 2007 at 01:07:13AM +0100, Adrian Bunk wrote:
>...
>  > +#ifdef CONFIG_SMP
>  >  void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);
>  >  void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);
>  > +#else  /*  CONFIG_SMP  */
>  > +static inline void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 
> *h)
>  > +{
>  > +  rdmsr(msr_no, *l, *h);
>  > +}
>  > +static inline void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 
> h)
>  > +{
>  > +  wrmsr(msr_no, l, h);
>  > +}
>  > +#endif  /*  CONFIG_SMP  */
> 
> BUG_ON(cpu!=smp_processor_id()) maybe?

This is the CONFIG_SMP=n case.

>   Dave

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] aio: propogate post-EIOCBQUEUED errors to completion event

[Benjamin LaHaise]

On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> aio is not responsible for this particular synchronization.  Those fixes
> (if we make them) should come from other places.  The patch is important
> to get aio error handling right.
> 
> I would argue that one common cause of the EIO is userland
> error (mmap concurrent with O_DIRECT), and EIO is the correct answer.

I disagree.  That means that using the pagecache to synchronize things like 
the proposed online defragmentation will occasionally make O_DIRECT users 
fail.  O_DIRECT doesn't prevent the sysadmin from copying files or other 
page cache uses, which implies that generating an error in these cases is 
horrifically broken.  If only root could do it, I wouldn't complain, but 
this would seem to imply that user vs root holes still exist.

-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[EMAIL PROTECTED]>.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/