Re: i2c via686a.c: save at least 0.5k of space by long v[256] -> u16 v[256]

[Denis Vlasenko]

On Thursday 01 September 2005 18:59, Greg KH wrote:
> On Thu, Sep 01, 2005 at 09:10:14AM +0300, Denis Vlasenko wrote:
> > Not tested, but it's rather obvious.
> 
> Except you forgot a "Signed-off-by:" line...
> 
> > --- linux-2.6.12.src/drivers/i2c/chips/via686a.c.orig   Sun Jun 19 
> > 16:10:10 2005
> > +++ linux-2.6.12.src/drivers/i2c/chips/via686a.cTue Aug 30 00:21:39 2005
> > @@ -205,7 +205,7 @@ static inline u8 FAN_TO_REG(long rpm, in
> >   but the function is very linear in the useful range (0-80 deg C), so 
> >   we'll just use linear interpolation for 10-bit readings.)  So, tempLUT 
> >   is the temp at via register values 0-255: */
> > -static const long tempLUT[] =
> > +static const int16_t tempLUT[] =
> 
> int16_t is not a proper kernel type.  Do you really mean s16 instead?

Ok. Please be informed that there are lots of intNN_t's in i2c dir tho...

> Care to redo this?

Signed-off-by: Denis Vlasenko <[EMAIL PROTECTED]>
--
vda
--- linux-2.6.12.src/drivers/i2c/chips/via686a.c.orig	Sun Jun 19 16:10:10 2005
+++ linux-2.6.12.src/drivers/i2c/chips/via686a.c	Tue Aug 30 00:21:39 2005
@@ -205,7 +205,7 @@ static inline u8 FAN_TO_REG(long rpm, in
  but the function is very linear in the useful range (0-80 deg C), so 
  we'll just use linear interpolation for 10-bit readings.)  So, tempLUT 
  is the temp at via register values 0-255: */
-static const long tempLUT[] =
+static const s16 tempLUT[] =
 { -709, -688, -667, -646, -627, -607, -589, -570, -553, -536, -519,
 	-503, -487, -471, -456, -442, -428, -414, -400, -387, -375,
 	-362, -350, -339, -327, -316, -305, -295, -285, -275, -265,

Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Noritoshi Demizu]

> > Since the TCP Window Scale options are exchanged,
> > the window size field contains shifted value except SYNs.
>
> Be careful, tcpdump may be tracking the window scale and reporting
> scaled values.  Seems unlikely since with a window scale of 2, and odd
> window size would be impossible.

I am sorry if tcpdump tracks the window scale option.  But I think it
is unlikely, because there are odd window sizes, as you pointed out.

By the way, if tcpdump does not track the window scale option, the right
edge (ack + real win) does not change between the following two ACKs.

> 11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win 
> 15340  (DF)
  (259 ACKs are omitted here)
> 11:34:54.611769 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84454467 win 
> 2355  (DF)

The first line is the 37th ACK and the second line is the 295th ACK.

  ACK#37:  ack=84402527 win=15340 right_edge=84463887 (= ack + win * 4)
  ACK#295: ack=84454467 win=2355  right_edge=84463887 (= ack + win * 4)

And all ACKs later than ACK#295 has win=2355 (2355*4=9420).

This may be a hint.  But, sorry, I do not know the internal of Linux TCP.

Regards,
Noritoshi Demizu
-
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: [RFC/PATCH]reconfigure MSI registers after resume

[Greg KH]

On Thu, Sep 01, 2005 at 01:59:32PM -0700, Nguyen, Tom L wrote:
> On Thursday, September 01, 2005 1:10 PM Andrew Morton wrote:
> >>
> >> On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
> >> > So what is the alternative to Shaohua's fix?  Restore all the msi 
> >> > registers on resume?
> >> 
> >> Yes, the PCIe port bus driver, for example, did that.
> >> 
> 
> > So you're saying that each individual driver which uses MSI is
> responsible
> > for the restore?  
> Yes.
> 
> > Is it not possible to do this in some single centralized place?
> Existing pci_save_state(dev)/pci_restore_state(dev) covers only 64 bytes
> of PCI header. One solution is to extend these APIs to cover up to 256
> bytes. What do you think?

Will that solve this issue?  I need to dig up my PCI spec to see if that
will still work properly on older pci devices...

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: RFC: i386: kill !4KSTACKS

[Chris Wedgwood]

On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:

> 4Kb kernel stacks are the future on i386, and it seems the problems
> it initially caused are now sorted out.

Not entirely.

XFS when mixed with raid/lvm/nfs still blows up.  It's probably not
alone in this respect but worse than ext2/3.
-
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: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Stephen Hemminger]

On Fri, 02 Sep 2005 13:51:38 +0900 (JST)
Noritoshi Demizu <[EMAIL PROTECTED]> wrote:

> Below may not be directly related to the cause of the problem.
> But I think some window sizes in your mail need to be re-evaluated.
> 
> > 11:29:54.961998 10.2.20.246.33060 > 10.2.224.182.8700: S 
> > 1972343059:1972343059(0) win 5840  > 0,nop,wscale 2> (DF)
> > 11:29:54.983334 10.2.224.182.8700 > 10.2.20.246.33060: S 
> > 2770690746:2770690746(0) ack 1972343060 win 33304  > 99687881 225781001,mss 1460,nop,wscale 1,nop,nop,sackOK> (DF)
> 
> Since the TCP Window Scale options are exchanged,
> the window size field contains shifted value except SYNs.

Be careful, tcpdump may be tracking the window scale and reporting
scaled values.  Seems unlikely since with a window scale of 2, and odd
window size would be impossible.  Also, is there by any chance a busted
firewall in the way (like OpenBSD) that corrupts window scaling. 
-
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: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Noritoshi Demizu]

Below may not be directly related to the cause of the problem.
But I think some window sizes in your mail need to be re-evaluated.

> 11:29:54.961998 10.2.20.246.33060 > 10.2.224.182.8700: S 
> 1972343059:1972343059(0) win 5840  0,nop,wscale 2> (DF)
> 11:29:54.983334 10.2.224.182.8700 > 10.2.20.246.33060: S 
> 2770690746:2770690746(0) ack 1972343060 win 33304  225781001,mss 1460,nop,wscale 1,nop,nop,sackOK> (DF)

Since the TCP Window Scale options are exchanged,
the window size field contains shifted value except SYNs.

> 11:29:55.216634 10.2.20.246.33060 > 10.2.224.182.8700: . ack 14307 win 8192 
>  (DF)
>
> The connection is established and the receiver's TCP window quickly ramps
> up to 8192.

I think the real window size here is 8192 << 2 = 32768.

> 11:29:55.707823 10.2.20.246.33060 > 10.2.224.182.8700: . ack 274527 win 16534 
>  (DF)
>
> Shortly thereafter the TCP window increases further to 16534. It remains
> around 16534 for the next 5 minutes or so.

I think the real window size here is 16534 << 2 = 66136.

> 11:31:09.345250 10.2.20.246.33060 > 10.2.224.182.8700: . ack 38676603 win 
> 16534  (DF)
>
> A few minutes later it has finally caught up to present time and it starts 
> receiving smaller packets containing real-time data. The TCP window is 
> still 16534 at this point.

I think the real window size here is 16534 << 2 = 66136.

> 11:34:54.337167 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84402527 win 
> 15340  (DF)
  (sniop)
> 11:34:54.628497 10.2.20.246.33060 > 10.2.224.182.8700: . ack 84458619 win 
> 2355  (DF)
>
> This is where things start going bad. The window starts shrinking from 
> 15340 all the way down to 2355 over the course of 0.3 seconds.

I think the real window sizes are 15340 << 2 = 61360 and 2355 << 2 = 9420.
Hence, the right edges can be calculated as the following:

  84402527 + 15340 << 2 = 84463887
  84458619 +  2355 << 2 = 84468039

So, the window is not shrinked between those two lines.
Sorry, I have not checked other lines.

> 11:40:08.279678 10.2.20.246.33060 > 10.2.224.182.8700: . ack 134973263 win 
> 2355  (DF)
>
> Five minutes later the TCP window is still at 2355, having never recovered.

I think the real window size here is 2355 << 2 = 9420.

> As I mentioned earlier, I've seen it go as low as 181.

I think the real window size is 181 << 2 = 724.

Regards,
Noritoshi Demizu
-
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: reboot vs poweroff

[Eric W. Biederman]

Nigel Cunningham <[EMAIL PROTECTED]> writes:

>
> All I did was start calling pm_ops->prepare, ->enter and ->finish
> regardless of the powerdown method, instead of only for S3 or S4. It
> seems to be working fine. If, however, we should be doing things
> differently, I'm happy to comply. What's the authoritative word?

Not certain.  I am only authoritative on device_suspend() and the
reboot_notifiers, in this context.  Largely I read and think about
the code to see what is going on.

Eric
-
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: reboot vs poweroff

[Eric W. Biederman]

"Brown, Len" <[EMAIL PROTECTED]> writes:

>  
>>Patch tested and works fine here. You should probably make a 
>>note in the bugzilla so we don't get a conflicting merge
>>from the ACPI folks.
>
> One might also consider that it would be a good idea to
> send patches that break ACPI files to the ACPI maintainer
> and [EMAIL PROTECTED] before sending them
> to Linus...

My apologies, for bug fixes that are not complete and simply move
where the bug is.  My apologies also for not cc'ing you, I didn't
intend to omit you but it never occurred to me.  The patch was
also 2 lines and obviously correct.

For this round I knew you were on the CC list and deliberately included
you.

My goal for the reboot/halt/suspend/kexec path is to fix it so the
generic code is correct and consistent.  Something it hasn't been for
years creating the affect that a correct bug fix in one place would
break something else. 

Until the reboot paths are correct and consistent things will continue
to break, in weird and unpredictable ways, that will keep us all
hunting weird strange bugs for a long time.  I think the S4 suspend
case is the last code path that needs to be fixed.  It is certainly
the last one I am aware of.

Eric

-
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: Change in NFS client behavior

[Andrew Morton]

Trond Myklebust <[EMAIL PROTECTED]> wrote:
>

Looks good from a quick scan.

> +static int do_posix_truncate(struct dentry *dentry, loff_t length)
>  +{
>  +int err = 0;
>  +struct iattr newattrs;
>  +
>  +newattrs.ia_size = length;
>  +newattrs.ia_valid = ATTR_SIZE;
>  +
>  +down(>d_inode->i_sem);
>  +/* In SuS/Posix lore, truncate to the current file size is a no-op */
>  +if (length != i_size_read(dentry->d_inode))
>  +err = notify_change(dentry, );
>  +up(>d_inode->i_sem);
>  +return err;
>  +}

I'm not sure that we really need to bother putting the i_size test inside
i_sem.  If somebody is changing the file size in parallel with truncate
then they'll get unpredictable results anyway.  Needs deep thought.
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Hiro Yoshioka]

From: Andrew Morton <[EMAIL PROTECTED]>
> Hiro Yoshioka <[EMAIL PROTECTED]> wrote:
> >
> > --- linux-2.6.12.4.orig/arch/i386/lib/usercopy.c2005-08-05 
> > 16:04:37.0 +0900
> >  +++ linux-2.6.12.4.nt/arch/i386/lib/usercopy.c 2005-09-01 
> > 17:09:41.0 +0900
> 
> Really.  Please redo and retest the patch against a current kernel.

Does it mean 2.6.13? I'll do it. 

Regards,
  Hiro
-
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: reboot vs poweroff

[Eric W. Biederman]

Pavel Machek <[EMAIL PROTECTED]> writes:

> Hi!
>> 
>> Thanks.
>> 
>> This is clearly a code path I missed when I was fixing things.
>> 
>> When I made the final acpi change I checked for any other users
>> of device_suspend and it seems I was blind and missed this one.
>> Looking again...
>> 
>> The patch in the bug report looks correct.  However it is still
>> a little incomplete.  In particular the reboot notifier is not
>> being called, and since not everything has been converted into
>> using shutdown methods that could lead to some other inconsistent
>> behavior.
>> 
>> Does anyone have any problems with the patch below?
>> If not I will send this off to Linus..
>
> Yes. kernel_suspend is *way* too generic name.  kernel_suspend_off?
> kernel_powe_off_suspend?

Darn.  You have a point there.

>> @@ -420,6 +421,15 @@ void kernel_power_off(void)
>>  }
>>  EXPORT_SYMBOL_GPL(kernel_power_off);
>>  
>> +int kernel_suspend(void)
>> +{
>> +notifier_call_chain(_notifier_list, SYS_POWER_OFF, NULL);
>> +system_state = SYSTEM_POWER_OFF;
>> +device_shutdown();
>> +return pm_ops->enter(PM_SUSPEND_DISK);
>> +}
>> +EXPORT_SYMBOL_GPL(kernel_suspend);
>> +
>
> Are you sure pm_ops exists in !CONFIG_PM case?

Hmm.  Good point.  I hadn't considered that.  I am now certain
it only exists when CONFIG_PM is set.

Thinking about it more I probably want to simply have a
kernel_power_off_shutdown(); common factor and call
that instead of device_shutdown().

Ok some sleep and then I will see if I can better version of this
cleanup.

Eric
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Andrew Morton]

Hiro Yoshioka <[EMAIL PROTECTED]> wrote:
>
> --- linux-2.6.12.4.orig/arch/i386/lib/usercopy.c  2005-08-05 
> 16:04:37.0 +0900
>  +++ linux-2.6.12.4.nt/arch/i386/lib/usercopy.c   2005-09-01 
> 17:09:41.0 +0900

Really.  Please redo and retest the patch against a current 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
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] Implement shared page tables

[Chen, Kenneth W]

Dave McCracken wrote on Tuesday, August 30, 2005 3:13 PM
> This patch implements page table sharing for all shared memory regions that
> span an entire page table page.  It supports sharing at multiple page
> levels, depending on the architecture.

In function pt_share_pte():

> + while ((svma = next_shareable_vma(vma, svma, ))) {
> + spgd = pgd_offset(svma->vm_mm, address);
> + if (pgd_none(*spgd))
> + continue;
> +
> + spud = pud_offset(spgd, address);
> + if (pud_none(*spud))
> + continue;
> +
> + spmd = pmd_offset(spud, address);
> + if (pmd_none(*spmd))
> + continue;

> + page = pmd_page(*spmd);
> + pt_increment_share(page);
> + pmd_populate(vma->vm_mm, pmd, page);
> + }


Do you really have to iterate through all the vma?  Can't you just break
out of the while loop on first successful match and populating the pmd?
I would think you will find them to be the same pte page. Or did I miss
some thing?


--- ./mm/ptshare.c.orig 2005-09-01 21:16:35.311915518 -0700
+++ ./mm/ptshare.c  2005-09-01 21:18:24.629296992 -0700
@@ -200,6 +200,7 @@ pt_share_pte(struct vm_area_struct *vma,
page = pmd_page(*spmd);
pt_increment_share(page);
pmd_populate(vma->vm_mm, pmd, page);
+   break;
}
}
pte = pte_alloc_map(vma->vm_mm, pmd, address);

-
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: Change in NFS client behavior

[Trond Myklebust]

fr den 02.09.2005 Klokka 00:15 (-0400) skreiv Trond Myklebust:

> Sure. The other problem is that the test is made before the i_sem is
> grabbed. OK, so how about the appended patch instead?

Doh!

Trond
VFS/NFS: Fix up behaviour w.r.t. truncate() and open(O_TRUNC)

 POSIX and the SUSv3 specify that open(O_TRUNC) should always bump ctime/mtime
 whereas truncate() should only do so if the file size actually changes.

 Fix the behaviour of NFS, which currently is broken w.r.t. open(), and fix
 the VFS truncate() so that it no enforces the POSIX rules.

 Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
 attr.c  |   14 +++---
 nfs/inode.c |5 -
 open.c  |   25 +++--
 3 files changed, 26 insertions(+), 18 deletions(-)

Index: linux-2.6.13/fs/nfs/inode.c
===
--- linux-2.6.13.orig/fs/nfs/inode.c
+++ linux-2.6.13/fs/nfs/inode.c
@@ -833,11 +833,6 @@ nfs_setattr(struct dentry *dentry, struc
struct nfs_fattr fattr;
int error;
 
-   if (attr->ia_valid & ATTR_SIZE) {
-   if (!S_ISREG(inode->i_mode) || attr->ia_size == 
i_size_read(inode))
-   attr->ia_valid &= ~ATTR_SIZE;
-   }
-
/* Optimization: if the end result is no change, don't RPC */
attr->ia_valid &= NFS_VALID_ATTRS;
if (attr->ia_valid == 0)
Index: linux-2.6.13/fs/open.c
===
--- linux-2.6.13.orig/fs/open.c
+++ linux-2.6.13/fs/open.c
@@ -206,11 +206,32 @@ int do_truncate(struct dentry *dentry, l
newattrs.ia_valid = ATTR_SIZE | ATTR_CTIME;
 
down(>d_inode->i_sem);
+   /* This should be used for open(O_TRUNC) and functions that need to
+* set mtime/ctime whether or not the size changes
+*/
+   if (length == i_size_read(dentry->d_inode))
+   newattrs.ia_valid &= ~ATTR_SIZE;
err = notify_change(dentry, );
up(>d_inode->i_sem);
return err;
 }
 
+static int do_posix_truncate(struct dentry *dentry, loff_t length)
+{
+   int err = 0;
+   struct iattr newattrs;
+
+   newattrs.ia_size = length;
+   newattrs.ia_valid = ATTR_SIZE;
+
+   down(>d_inode->i_sem);
+   /* In SuS/Posix lore, truncate to the current file size is a no-op */
+   if (length != i_size_read(dentry->d_inode))
+   err = notify_change(dentry, );
+   up(>d_inode->i_sem);
+   return err;
+}
+
 static inline long do_sys_truncate(const char __user * path, loff_t length)
 {
struct nameidata nd;
@@ -261,7 +282,7 @@ static inline long do_sys_truncate(const
error = locks_verify_truncate(inode, NULL, length);
if (!error) {
DQUOT_INIT(inode);
-   error = do_truncate(nd.dentry, length);
+   error = do_posix_truncate(nd.dentry, length);
}
put_write_access(inode);
 
@@ -313,7 +334,7 @@ static inline long do_sys_ftruncate(unsi
 
error = locks_verify_truncate(inode, file, length);
if (!error)
-   error = do_truncate(dentry, length);
+   error = do_posix_truncate(dentry, length);
 out_putf:
fput(file);
 out:
Index: linux-2.6.13/fs/attr.c
===
--- linux-2.6.13.orig/fs/attr.c
+++ linux-2.6.13/fs/attr.c
@@ -70,17 +70,9 @@ int inode_setattr(struct inode * inode, 
int error = 0;
 
if (ia_valid & ATTR_SIZE) {
-   if (attr->ia_size != i_size_read(inode)) {
-   error = vmtruncate(inode, attr->ia_size);
-   if (error || (ia_valid == ATTR_SIZE))
-   goto out;
-   } else {
-   /*
-* We skipped the truncate but must still update
-* timestamps
-*/
-   ia_valid |= ATTR_MTIME|ATTR_CTIME;
-   }
+   error = vmtruncate(inode, attr->ia_size);
+   if (error || (ia_valid == ATTR_SIZE))
+   goto out;
}
 
if (ia_valid & ATTR_UID)

Re: Change in NFS client behavior

[Trond Myklebust]

to den 01.09.2005 Klokka 21:07 (-0700) skreiv Andrew Morton:

> Of course.  But with your patch, the optimisation in inode_setattr() is
> redundant (except for O_TRUNC, perhaps).

Sure. The other problem is that the test is made before the i_sem is
grabbed. OK, so how about the appended patch instead?

Cheers,
  Trond

VFS/NFS: Fix up behaviour w.r.t. truncate() and open(O_TRUNC)

 POSIX and the SUSv3 specify that open(O_TRUNC) should always bump ctime/mtime
 whereas truncate() should only do so if the file size actually changes.

 Fix the behaviour of NFS, which currently is broken w.r.t. open(), and fix
 the VFS truncate() so that it no enforces the POSIX rules.

 Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
 attr.c  |   14 +++---
 nfs/inode.c |5 -
 open.c  |   25 +++--
 3 files changed, 26 insertions(+), 18 deletions(-)

Index: linux-2.6.13/fs/nfs/inode.c
===
--- linux-2.6.13.orig/fs/nfs/inode.c
+++ linux-2.6.13/fs/nfs/inode.c
@@ -833,11 +833,6 @@ nfs_setattr(struct dentry *dentry, struc
struct nfs_fattr fattr;
int error;
 
-   if (attr->ia_valid & ATTR_SIZE) {
-   if (!S_ISREG(inode->i_mode) || attr->ia_size == 
i_size_read(inode))
-   attr->ia_valid &= ~ATTR_SIZE;
-   }
-
/* Optimization: if the end result is no change, don't RPC */
attr->ia_valid &= NFS_VALID_ATTRS;
if (attr->ia_valid == 0)
Index: linux-2.6.13/fs/open.c
===
--- linux-2.6.13.orig/fs/open.c
+++ linux-2.6.13/fs/open.c
@@ -206,11 +206,32 @@ int do_truncate(struct dentry *dentry, l
newattrs.ia_valid = ATTR_SIZE | ATTR_CTIME;
 
down(>d_inode->i_sem);
+   /* This should be used for open(O_TRUNC) and functions that need to
+* set mtime/ctime whether or not the size changes
+*/
+   if (length == i_size_read(dentry->d_inode))
+   newattrs.ia_valid &= ~ATTR_SIZE;
err = notify_change(dentry, );
up(>d_inode->i_sem);
return err;
 }
 
+static int do_posix_truncate(struct dentry *dentry, loff_t length)
+{
+   int err = 0;
+   struct iattr newattrs;
+
+   newattrs.ia_size = length;
+   newattrs.ia_valid = ATTR_SIZE;
+
+   down(>d_inode->i_sem);
+   /* In SuS/Posix lore, truncate to the current file size is a no-op */
+   if (length != i_size_read(dentry->d_inode))
+   err = do_truncate(dentry, length);
+   up(>d_inode->i_sem);
+   return err;
+}
+
 static inline long do_sys_truncate(const char __user * path, loff_t length)
 {
struct nameidata nd;
@@ -261,7 +282,7 @@ static inline long do_sys_truncate(const
error = locks_verify_truncate(inode, NULL, length);
if (!error) {
DQUOT_INIT(inode);
-   error = do_truncate(nd.dentry, length);
+   error = do_posix_truncate(nd.dentry, length);
}
put_write_access(inode);
 
@@ -313,7 +334,7 @@ static inline long do_sys_ftruncate(unsi
 
error = locks_verify_truncate(inode, file, length);
if (!error)
-   error = do_truncate(dentry, length);
+   error = do_posix_truncate(dentry, length);
 out_putf:
fput(file);
 out:
Index: linux-2.6.13/fs/attr.c
===
--- linux-2.6.13.orig/fs/attr.c
+++ linux-2.6.13/fs/attr.c
@@ -70,17 +70,9 @@ int inode_setattr(struct inode * inode, 
int error = 0;
 
if (ia_valid & ATTR_SIZE) {
-   if (attr->ia_size != i_size_read(inode)) {
-   error = vmtruncate(inode, attr->ia_size);
-   if (error || (ia_valid == ATTR_SIZE))
-   goto out;
-   } else {
-   /*
-* We skipped the truncate but must still update
-* timestamps
-*/
-   ia_valid |= ATTR_MTIME|ATTR_CTIME;
-   }
+   error = vmtruncate(inode, attr->ia_size);
+   if (error || (ia_valid == ATTR_SIZE))
+   goto out;
}
 
if (ia_valid & ATTR_UID)

Re: Change in NFS client behavior

[Andrew Morton]

Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> to den 01.09.2005 Klokka 20:45 (-0700) skreiv Andrew Morton:
> > Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > >
> > >  +static inline int do_posix_truncate(struct dentry *dentry, loff_t 
> > > length)
> > >  +{
> > >  +/* In SuS/Posix lore, truncate to the current file size is a 
> > > no-op */
> > >  +if (length == i_size_read(dentry->d_inode))
> > >  +return 0;
> > >  +return do_truncate(dentry, length);
> > >  +}
> > 
> > We have the same optimisation in inode_setattr()...
> 
> Look again. The two are NOT the same.
> 
> The code in inode_setattr() will cause truncate() to erroneously update
> the ctime/mtime.

Of course.  But with your patch, the optimisation in inode_setattr() is
redundant (except for O_TRUNC, perhaps).
-
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.13 lockup at boot after/at cpu initialization

[Andrew Morton]

Moses Leslie <[EMAIL PROTECTED]> wrote:
>
> On some older hardware I'm trying to use, 2.6.13 (and 2.6.12.3, the only
>  other 2.6 kernel tested on this hardware)  lock up right after boot, there
>  are no indications about what specifically is wrong.  The last few lines
>  before the lockup are:
> 
>  382MB LOWMEM available
>  DMI 2.3 present
>  Allocating PCI resources starting at 
>  Built 1 zonelists
>  Kernel command line: root=/dev/hda1 ro
>  Initialing CPU#0
> 
>  I can get the numbers if needed.
> 
>  2.4.31 works without problems.

Well that sucks.

You may get some more output if you add `earlyprintk=vga' to the kernel
boot command line.

To narrow down where it's hanging we'll need to start sprinkling printk()s.
Something like this: 


diff -puN init/main.c~a init/main.c
--- devel/init/main.c~a 2005-09-01 21:03:50.0 -0700
+++ devel-akpm/init/main.c  2005-09-01 21:05:28.0 -0700
@@ -53,6 +53,8 @@
 #include 
 #include 
 
+#define D() do { printk("%s:%d\n", __FILE__, __LINE__); } while (0)
+
 /*
  * This is one of the first .c files built. Error out early
  * if we have compiler trouble..
@@ -467,13 +469,21 @@ asmlinkage void __init start_kernel(void
   __stop___param - __start___param,
   _bootoption);
sort_main_extable();
+   D();
trap_init();
+   D();
rcu_init();
+   D();
init_IRQ();
+   D();
pidhash_init();
+   D();
init_timers();
+   D();
softirq_init();
+   D();
time_init();
+   D();
 
/*
 * HACK ALERT! This is early. We're enabling the console before
@@ -481,10 +491,14 @@ asmlinkage void __init start_kernel(void
 * this. But we do want output early, in case something goes wrong.
 */
console_init();
+   D();
if (panic_later)
panic(panic_later, panic_param);
+   D();
profile_init();
+   D();
local_irq_enable();
+   D();
 #ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start && !initrd_below_start_ok &&
initrd_start < min_low_pfn << PAGE_SHIFT) {
@@ -493,41 +507,68 @@ asmlinkage void __init start_kernel(void
initrd_start = 0;
}
 #endif
+   D();
vfs_caches_init_early();
+   D();
mem_init();
+   D();
kmem_cache_init();
+   D();
setup_per_cpu_pageset();
+   D();
numa_policy_init();
+   D();
if (late_time_init)
late_time_init();
+   D();
calibrate_delay();
+   D();
pidmap_init();
+   D();
pgtable_cache_init();
+   D();
prio_tree_init();
+   D();
anon_vma_init();
+   D();
 #ifdef CONFIG_X86
if (efi_enabled)
efi_enter_virtual_mode();
 #endif
+   D();
fork_init(num_physpages);
+   D();
proc_caches_init();
+   D();
buffer_init();
+   D();
unnamed_dev_init();
+   D();
key_init();
+   D();
security_init();
+   D();
vfs_caches_init(num_physpages);
+   D();
radix_tree_init();
+   D();
signals_init();
+   D();
/* rootfs populating might need page-writeback */
page_writeback_init();
+   D();
 #ifdef CONFIG_PROC_FS
proc_root_init();
 #endif
+   D();
cpuset_init();
+   D();
 
check_bugs();
+   D();
 
acpi_early_init(); /* before LAPIC and SMP init */
+   D();
 
/* Do the rest non-__init'ed, we're now alive */
rest_init();
_

-
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: Change in NFS client behavior

[Trond Myklebust]

to den 01.09.2005 Klokka 20:45 (-0700) skreiv Andrew Morton:
> Trond Myklebust <[EMAIL PROTECTED]> wrote:
> >
> >  +static inline int do_posix_truncate(struct dentry *dentry, loff_t length)
> >  +{
> >  +  /* In SuS/Posix lore, truncate to the current file size is a no-op */
> >  +  if (length == i_size_read(dentry->d_inode))
> >  +  return 0;
> >  +  return do_truncate(dentry, length);
> >  +}
> 
> We have the same optimisation in inode_setattr()...

Look again. The two are NOT the same.

The code in inode_setattr() will cause truncate() to erroneously update
the ctime/mtime.

Cheers,
  Trond

-
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: Change in NFS client behavior

[Andrew Morton]

Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
>  +static inline int do_posix_truncate(struct dentry *dentry, loff_t length)
>  +{
>  +/* In SuS/Posix lore, truncate to the current file size is a no-op */
>  +if (length == i_size_read(dentry->d_inode))
>  +return 0;
>  +return do_truncate(dentry, length);
>  +}

We have the same optimisation in inode_setattr()...
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Hiro Yoshioka]

Andrew,

From: Andrew Morton <[EMAIL PROTECTED]>
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > On Friday 02 September 2005 04:08, Andrew Morton wrote:
> > 
> > > I suppose I'll queue it up in -mm for a while, although I'm a bit dubious
> > > about the whole idea...  We'll gain some and we'll lose some - how do we
> > > know it's a net gain?
> > 
> > I suspect it'll gain more than it loses. The only case where it might 
> > not gain is immediately someone reading the data from the page cache again
> > after the write.
> 
> That's a pretty common case - temporary files.
> 
> > But I suppose that's far less frequent than writing the data.
> 
> yup.
> 
> Hiro, could you please send through a summary of the performance testing
> results sometime?  Runtimes rather than oprofile output?

iozone results are

original 2.6.12.4 CPU time = 207.768 sec
cache aware   CPU time = 184.783 sec
(three times run)
184.783/207.768=88.94% (11.06% reduction)

original:
pattern9-0-cpu4-0-08191720/iozone.out:  CPU Utilization: Wall time   45.997
CPU time   64.527CPU utilization 140.28 %
pattern9-0-cpu4-0-08191741/iozone.out:  CPU Utilization: Wall time   46.878
CPU time   71.933CPU utilization 153.45 %
pattern9-0-cpu4-0-08191743/iozone.out:  CPU Utilization: Wall time   45.152
CPU time   71.308CPU utilization 157.93 %

cache awre:
pattern9-0-cpu4-0-09011728/iozone.out:  CPU Utilization: Wall time   44.842
CPU time   62.465CPU utilization 139.30 %
pattern9-0-cpu4-0-09011731/iozone.out:  CPU Utilization: Wall time   44.718
CPU time   59.273CPU utilization 132.55 %
pattern9-0-cpu4-0-09011744/iozone.out:  CPU Utilization: Wall time   44.367
CPU time   63.045CPU utilization 142.10 %

Regards,
  Hiro
-
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: Change in NFS client behavior

[Trond Myklebust]

to den 01.09.2005 Klokka 19:38 (-0400) skreiv Trond Myklebust:
> This is a consequence of 2.6 NFS clients optimising away unnecessary
> truncate calls. Whereas this is correct behaviour for truncate(), it
> appears to be incorrect for open(O_TRUNC).
> 
> In fact, local filesystems like xfs and ext3 appear to have the opposite
> problem: they change ctime if you call ftruncate(0) on the zero-length
> file, as the attached test shows.

Rob,

Could you please check if the following patch fixes NFS (and also the
local filesystems) for you?

Cheers,
  Trond

VFS/NFS: Fix up behaviour w.r.t. truncate() and open(O_TRUNC)

 POSIX and the SUSv3 specify that open(O_TRUNC) should always bump ctime/mtime
 whereas truncate() should only do so if the file size actually changes.

 Fix the behaviour of NFS, which currently is broken w.r.t. open(), and fix
 the VFS truncate() so that it no enforces the POSIX rules.

 Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
 nfs/inode.c |5 -
 open.c  |   12 ++--
 2 files changed, 10 insertions(+), 7 deletions(-)

Index: linux-2.6.13/fs/nfs/inode.c
===
--- linux-2.6.13.orig/fs/nfs/inode.c
+++ linux-2.6.13/fs/nfs/inode.c
@@ -833,11 +833,6 @@ nfs_setattr(struct dentry *dentry, struc
struct nfs_fattr fattr;
int error;
 
-   if (attr->ia_valid & ATTR_SIZE) {
-   if (!S_ISREG(inode->i_mode) || attr->ia_size == 
i_size_read(inode))
-   attr->ia_valid &= ~ATTR_SIZE;
-   }
-
/* Optimization: if the end result is no change, don't RPC */
attr->ia_valid &= NFS_VALID_ATTRS;
if (attr->ia_valid == 0)
Index: linux-2.6.13/fs/open.c
===
--- linux-2.6.13.orig/fs/open.c
+++ linux-2.6.13/fs/open.c
@@ -211,6 +211,14 @@ int do_truncate(struct dentry *dentry, l
return err;
 }
 
+static inline int do_posix_truncate(struct dentry *dentry, loff_t length)
+{
+   /* In SuS/Posix lore, truncate to the current file size is a no-op */
+   if (length == i_size_read(dentry->d_inode))
+   return 0;
+   return do_truncate(dentry, length);
+}
+
 static inline long do_sys_truncate(const char __user * path, loff_t length)
 {
struct nameidata nd;
@@ -261,7 +269,7 @@ static inline long do_sys_truncate(const
error = locks_verify_truncate(inode, NULL, length);
if (!error) {
DQUOT_INIT(inode);
-   error = do_truncate(nd.dentry, length);
+   error = do_posix_truncate(nd.dentry, length);
}
put_write_access(inode);
 
@@ -313,7 +321,7 @@ static inline long do_sys_ftruncate(unsi
 
error = locks_verify_truncate(inode, file, length);
if (!error)
-   error = do_truncate(dentry, length);
+   error = do_posix_truncate(dentry, length);
 out_putf:
fput(file);
 out:

Re: [PATCH 2.6.13] Unhandled error condition in aic7xxx

[Randy.Dunlap]

On Thu, 01 Sep 2005 12:38:24 -0700 Daniel Walker wrote:

> 
> This patch should handle the case when scsi_add_host() fails.
> 
> Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.13/drivers/scsi/aic7xxx/aic7xxx_osm.c
> ===
> --- linux-2.6.13.orig/drivers/scsi/aic7xxx/aic7xxx_osm.c  2005-08-28 
> 23:41:01.0 +
> +++ linux-2.6.13/drivers/scsi/aic7xxx/aic7xxx_osm.c   2005-08-31 
> 18:45:20.0 +
> @@ -996,6 +996,7 @@ ahc_linux_register_host(struct ahc_softc
>   struct   Scsi_Host *host;
>   char*new_name;
>   u_long   s;
> + int error = 0;
>  
>   template->name = ahc->description;
>   host = scsi_host_alloc(template, sizeof(struct ahc_softc *));
> @@ -1029,8 +1030,16 @@ ahc_linux_register_host(struct ahc_softc
>  
>   host->transportt = ahc_linux_transport_template;
>  
> - scsi_add_host(host, (ahc->dev_softc ? >dev_softc->dev : NULL)); /* 
> XXX handle failure */
> - scsi_scan_host(host);
> + error = scsi_add_host(host, (ahc->dev_softc ? >dev_softc->dev : 
> NULL));
> + if (error) {
> + /* 
> +  * Discard host variable on error.
> +  */
> + scsi_host_put(host);
> + return (error);

no parens on return, just: return error;

> + } 
> + scsi_scan_host(host);
> + 
>   return (0);
>  }



---
~Randy
-
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.13 git snapshot patches still empty

[Randy.Dunlap]

On Thu, 1 Sep 2005 20:17:37 -0700 Randy.Dunlap wrote:

> On Fri, 02 Sep 2005 02:19:51 +0100 Sid Boyce wrote:
> 
> > For both -git1.gz/.bz2 and -git2.gz/.bz2.
> 
> Yep, I think this is the fourth message about this.
> It would be nice to get it fixed

I suppose as a temporary measure (without daily snapshots, but
one merged linus-patch of all 2.6.13++ patches), we could use
linus.patch from Andrew's -mm broken-out directory


-
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.13 git snapshot patches still empty

[Randy.Dunlap]

On Fri, 02 Sep 2005 02:19:51 +0100 Sid Boyce wrote:

> For both -git1.gz/.bz2 and -git2.gz/.bz2.

Yep, I think this is the fourth message about this.
It would be nice to get it fixed
-
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/

[RFC] Splitting out kernel<=>userspace ABI headers

[Kyle Moffett]

A while ago there was a big discussion about splitting out the
userspace-accessible portions of the kernel headers into a separate
directory, "kabi", "kernel-abi", "linux-abi", or a half-dozen other
suggestions.  Linus sprinkled a bit of holy-penguin-pee on the idea,
but nothing ever really happened after that.  I have some available
time at the moment, and I would be willing to undertake the task,
but I would like a bit of guidance first, both from Linus/akpm/etc,
and from the list in general, about a few initial issues I see from
my initial attempts to sort through the mess:

  1)  There are a couple header files upon which almost everything
else depends, among them {asm,linux}/{posix_,}types.h, which have
some significant duplications.  Many of the archs have weird sizes
for those types to preserve some backwards-compatibility ABI, but
nowhere does it explain if there are any type-size restrictions in
general.  I would propose that those headers be reorganized so that
there are sane defaults for all the types in kabi/types.h, and
archs that require different would #define exceptions in their
kabi/arch-foo/types.h.  This would allow new archs to start with a
sane standard ABI before it becomes set in stone.

  2)  There is a bunch of stuff that would be _really_ useful in
userspace programs as well, even though not kernel ABI, such as
list.h, atomic.h (with a few archs modified due to privilege
restrictions), etc.  If there is interest, I would attempt to split
off those headers into a kcore/kerncore/linuxcore/whatever inline
header collection included in the linux distribution and installed
as part of the kernel headers.

  3)  What names are preferable for the above?  My personal
preferences are "kabi" and "kcore", because those save the most
typing for the sucker trying to do all this (IE: me), although if
someone has good reasons otherwise, I'll listen.

I realize this project is only slightly short of massive, however I
do have a bunch of time and am willing to do the grunt work if
enlightened as to the community desires.  I have a few different
semi-patches almost ready, and I can probably finish up a couple
this weekend if I can figure out which way people want to go.  One
of the major challenges is that kernel files have historically kind
of indiscriminately included asm/foo.h when they really meant
linux/foo.h (See the types.h example), only to have it magically
work because some other header already included linux/types.h
anyways.  If arch/driver/etc maintainers are willing to take patches
to clean that up, I'll start with that and eventually get a decent
set of kabi/* headers.


Cheers,
Kyle Moffett

--
Unix was not designed to stop people from doing stupid things,  
because that

would also stop them from doing clever things.
  -- Doug Gwyn


-
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 0/10] m68k/thread_info merge

[viro]

On Thu, Sep 01, 2005 at 05:17:38PM -0700, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Can I assume that the five m68k patches can be split apart from the five
> > patches which dink with task_struct?  ie: if the task_struct patches go in
> > later, does anything bad happen?
> 
> eh, forget I asked that.  They're interdependent.

... but do not have to 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: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[John Heffner]

On Sep 1, 2005, at 6:53 PM, Ion Badulescu wrote:


A few minutes later it has finally caught up to present time and it 
starts receiving smaller packets containing real-time data. The TCP 
window is still 16534 at this point.


[tcpdump output removed]

This is where things start going bad. The window starts shrinking from 
15340 all the way down to 2355 over the course of 0.3 seconds. Notice 
the many duplicate acks that serve no purpose (there are no lost 
packets and the tcpdump is taken on the receiver so there is no 
packets/acks crossed in flight).


I have an idea why this is going on.  Packets are pre-allocated by the 
driver to be a max packet size, so when you send small packets, it 
wastes a lot of memory.  Currently Linux uses the packets at the 
beginning of a connection to make a guess at how best to advertise its 
window so as not to overflow the socket's memory bounds.  Since you 
start out with big segments then go to small ones, this is defeating 
that mechanism.  It's actually documented in the comments in 
tcp_input.c. :)


 * The scheme does not work when sender sends good segments opening
 * window and then starts to feed us spagetti. But it should work
 * in common situations. Otherwise, we have to rely on queue collapsing.

If you overflow the socket's memory bound, it ends up calling 
tcp_clamp_window().  (I'm not sure this is really the right thing to do 
here before trying to collapse the queue.)  If the receiving 
application doesn't fall too far behind, it might help you to set a 
much larger receiver buffer.


  -John

-
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: State of Linux graphics

[rep stsb]

svgalib is spelled "svgalib"

I have started writing a windowing program which
uses svgalib. The source code is available at,

http://sourceforge.net/projects/svgalib-windows
 
select "browse cvs". SourceForge is rebuilding their
site, so some things don't work.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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: [Q] how to use syslogd to debug kernel ?

[Zhou Yingchao]

On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi, everyone.
> 
>I know kernel oops can be seen by run 'dmesg', but if
> kernel crashed, we can not run it.   so I reconfigure syslogd
> to support remote forward, the debug machine content of
> syslogd.conf is:

When the panic is called, the network system cannt working, no
message will be sent. The panic is only designed to print at least
 oops message on the screen. 
For debug through ethernet, I suggest you to try KGDB, which consist
a patch to debug over ethernet. 

-- 
Yingchao Zhou
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Andrew Morton]

Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Friday 02 September 2005 04:08, Andrew Morton wrote:
> 
> > I suppose I'll queue it up in -mm for a while, although I'm a bit dubious
> > about the whole idea...  We'll gain some and we'll lose some - how do we
> > know it's a net gain?
> 
> I suspect it'll gain more than it loses. The only case where it might 
> not gain is immediately someone reading the data from the page cache again
> after the write.

That's a pretty common case - temporary files.

> But I suppose that's far less frequent than writing the data.

yup.

Hiro, could you please send through a summary of the performance testing
results sometime?  Runtimes rather than oprofile output?
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Andi Kleen]

On Friday 02 September 2005 04:08, Andrew Morton wrote:

> I suppose I'll queue it up in -mm for a while, although I'm a bit dubious
> about the whole idea...  We'll gain some and we'll lose some - how do we
> know it's a net gain?

I suspect it'll gain more than it loses. The only case where it might 
not gain is immediately someone reading the data from the page cache again
after the write. But I suppose that's far less frequent than writing the data.

-Andi
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Andrew Morton]

Hiro Yoshioka <[EMAIL PROTECTED]> wrote:
>
> From: Andi Kleen <[EMAIL PROTECTED]>
> > On Thursday 01 September 2005 11:07, Hiro Yoshioka wrote:
> > 
> > > The following is the almost final version of the
> > > cache pollution aware __copy_from_user_ll() patch.
> > 
> > Looks good to me.
> > 
> > Once the filemap.c hunk is in I'll probably do something
> > similar for x86-64.
> 
> Thank you very much. What else should I do? Shall I just
> be waiting to check in the patch?
> 

I suppose I'll queue it up in -mm for a while, although I'm a bit dubious
about the whole idea...  We'll gain some and we'll lose some - how do we
know it's a net gain?
-
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.13-mm1

[Andrew Morton]

"J.A. Magallon" <[EMAIL PROTECTED]> wrote:
>
> 
> On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > 
> > - Included Alan's big tty layer buffering rewrite.  This breaks the build on
> >   lots of more obscure character device drivers.  Patches welcome (please cc
> >   Alan).
> > 
> 
> I have problems with udev and latest -mm.
> 2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
> System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
> udev, etc), but the fact is that with the same setup, plain .13 boots
> and -mm1 blocks. Udev is 068 version.
> 
> Any idea about what can be the reason ?
> 

There's some suspect locking in the /proc/devices seq_file conversion code.

Could you revert convert-proc-devices-to-use-seq_file-interface-fix.patch
then convert-proc-devices-to-use-seq_file-interface.patch?

-
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.13-mm1

[Andrew Morton]

Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
> Hi,
> 
> On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> > 
> ...
>
> This patch:
> 
> netlink-log-protocol-failures.patch
> 
> is causing lots of messages like this to be logged on my console:
> 
> Sep  2 11:52:41 tornado kernel: DEBUG: Failed to load PF_NETLINK protocol 9
>
> It seems to be caused by audit support not being enabled in as if I rebuild 
> with audit support the message goes away :)

OK, thanks.  I passed that on to David and Patrick.

> 
> 
> I'm also observing some USB messages logged:
> 
> Sep  2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 13
> Sep  2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB 
> Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204
> Sep  2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), 
> re-enabling...
> Sep  2 13:26:23 tornado kernel: usb 5-1: USB disconnect, address 13
> Sep  2 13:26:23 tornado kernel: drivers/usb/class/usblp.c: usblp0: removed
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 14
> Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 15
> Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/all, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 16
> Sep  2 13:26:23 tornado kernel: usb 5-1: can't set config #1, error -71
> Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
> uhci_hcd and address 17
> Sep  2 13:26:24 tornado kernel: usb 5-1: unable to read config index 0 
> descriptor/start
> Sep  2 13:26:24 tornado kernel: usb 5-1: can't read configurations, error -71
> 
> [EMAIL PROTECTED] kernel]# lsusb
> Bus 005 Device 004: ID 050d:0105 Belkin Components
> Bus 005 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
> Bus 005 Device 001: ID :
> Bus 004 Device 001: ID :
> Bus 003 Device 001: ID :
> Bus 002 Device 001: ID :
> Bus 001 Device 001: ID :
> [EMAIL PROTECTED] kernel]#
> 
> Output of lsusb -v up at http://www.reub.net/kernel/lsusb-output
> 

Added the usual Cc's...
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Andi Kleen]

On Friday 02 September 2005 03:43, Hiro Yoshioka wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
>
> > On Thursday 01 September 2005 11:07, Hiro Yoshioka wrote:
> > > The following is the almost final version of the
> > > cache pollution aware __copy_from_user_ll() patch.
> >
> > Looks good to me.
> >
> > Once the filemap.c hunk is in I'll probably do something
> > similar for x86-64.
>
> Thank you very much. What else should I do? Shall I just
> be waiting to check in the patch?

I suppose Andrew will take care of it, unless someone else
objects.

-Andi
-
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] Implement shared page tables

[Chen, Kenneth W]

Dave McCracken wrote on Tuesday, August 30, 2005 3:13 PM
> This patch implements page table sharing for all shared memory regions that
> span an entire page table page.  It supports sharing at multiple page
> levels, depending on the architecture.
> 
> 
> This version of the patch supports i386 and x86_64.  I have additional
> patches to support ppc64, but they are not quite ready for public
> consumption.
> 
>  
> + prio_tree_iter_init(, >i_mmap,
> + vma->vm_start, vma->vm_end);


I think this is a bug.  The radix priority tree for address_space->
i_mmap is keyed on vma->vm_pgoff.  Your patch uses the vma virtual
address to find a shareable range, Which will always fail a match
even though there is one.  The following is a quick hack I did to
make it work.

- Ken

--- linux-2.6.13/mm/ptshare.c.orig  2005-09-01 18:58:12.299321918 -0700
+++ linux-2.6.13/mm/ptshare.c   2005-09-01 18:58:39.846196580 -0700
@@ -26,6 +26,11 @@
 #include 
 #include 
 
+#define RADIX_INDEX(vma)  ((vma)->vm_pgoff)
+#define VMA_SIZE(vma)(((vma)->vm_end - (vma)->vm_start) >> PAGE_SHIFT)
+/* avoid overflow */
+#define HEAP_INDEX(vma)  ((vma)->vm_pgoff + (VMA_SIZE(vma) - 1))
+
 #undef PT_DEBUG
 
 #ifndef __PAGETABLE_PMD_FOLDED
@@ -173,7 +178,7 @@ pt_share_pte(struct vm_area_struct *vma,
   address);
 #endif
prio_tree_iter_init(, >i_mmap,
-   vma->vm_start, vma->vm_end);
+   RADIX_INDEX(vma), HEAP_INDEX(vma));
 
while ((svma = next_shareable_vma(vma, svma, ))) {
spgd = pgd_offset(svma->vm_mm, address);


-
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.13-mm1

[J.A. Magallon]

On 1/09/2005 10:58 a.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/
> 
> - Included Alan's big tty layer buffering rewrite.  This breaks the build on
>   lots of more obscure character device drivers.  Patches welcome (please cc
>   Alan).
> 

I have problems with udev and latest -mm.
2.6.13 boots fine, but 2.6.13-mm1 blocks when starting udev.
System is Mandriva Cooker. As cooker, things are changing fast (initscripts,
udev, etc), but the fact is that with the same setup, plain .13 boots
and -mm1 blocks. Udev is 068 version.

Any idea about what can be the reason ?

TIA

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.13 (gcc 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.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/

[PATCH 2.6.13] libata: fix pio_mask values (take 2)

[Brett Russ]

ata_get_mode_mask() uses bits 3 and 4 in the pio_mask to represent PIO
modes 3 and 4.  The value read from the drive, which reports support
for PIO3 and PIO4 in bits 0 and 1, is shifted left by 3 bits and OR'd
with 0x7 (which then corresponds to PIO 2-0 in libata).  Thus, the
drivers below need adjustments to comply with the way pio_mask is
used.  I changed the masks from the commented values to all support
PIO4-0, since the spec mandates that PIO0-2 are supported and there's
no reason not to support PIO3 IMO.

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>


Index: linux-2.6.13/drivers/scsi/ahci.c
===
--- linux-2.6.13.orig/drivers/scsi/ahci.c
+++ linux-2.6.13/drivers/scsi/ahci.c
@@ -244,7 +244,7 @@ static struct ata_port_info ahci_port_in
.host_flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
  ATA_FLAG_SATA_RESET | ATA_FLAG_MMIO |
  ATA_FLAG_PIO_DMA,
-   .pio_mask   = 0x03, /* pio3-4 */
+   .pio_mask   = 0x1f, /* pio4-0 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
.port_ops   = _ops,
},
Index: linux-2.6.13/drivers/scsi/sata_uli.c
===
--- linux-2.6.13.orig/drivers/scsi/sata_uli.c
+++ linux-2.6.13/drivers/scsi/sata_uli.c
@@ -120,8 +120,8 @@ static struct ata_port_info uli_port_inf
.sht= _sht,
.host_flags = ATA_FLAG_SATA | ATA_FLAG_SATA_RESET |
  ATA_FLAG_NO_LEGACY,
-   .pio_mask   = 0x03, //support pio mode 4 (FIXME)
-   .udma_mask  = 0x7f, //support udma mode 6
+   .pio_mask   = 0x1f, /* pio4-0 */
+   .udma_mask  = 0x7f, /* udma6-0 */
.port_ops   = _ops,
 };
 
-
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: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

[Hiro Yoshioka]

From: Andi Kleen <[EMAIL PROTECTED]>
> On Thursday 01 September 2005 11:07, Hiro Yoshioka wrote:
> 
> > The following is the almost final version of the
> > cache pollution aware __copy_from_user_ll() patch.
> 
> Looks good to me.
> 
> Once the filemap.c hunk is in I'll probably do something
> similar for x86-64.

Thank you very much. What else should I do? Shall I just
be waiting to check in the patch?

Regards,
  Hiro
-
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.13-mm1

[Reuben Farrelly]

Hi,

On 1/09/2005 10:58 a.m., Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm1/

- Included Alan's big tty layer buffering rewrite.  This breaks the build on
  lots of more obscure character device drivers.  Patches welcome (please cc
  Alan).



Changes since 2.6.13-rc6-mm2:


 linus.patch
 git-acpi.patch
 git-arm.patch
 git-cpufreq.patch
 git-cryptodev.patch
 git-ia64.patch
 git-audit.patch
 git-audit-ppc64-fix.patch
 git-input.patch
 git-jfs-fixup.patch
 git-kbuild.patch
 git-libata-all.patch
 git-mtd.patch
 git-netdev-all.patch
 git-nfs.patch
 git-ocfs2.patch
 git-serial.patch
 git-scsi-block.patch
 git-scsi-iscsi.patch
 git-scsi-misc.patch
 git-watchdog.patch


This patch:

netlink-log-protocol-failures.patch

is causing lots of messages like this to be logged on my console:

Sep  2 11:52:41 tornado kernel: DEBUG: Failed to load PF_NETLINK protocol 9

It seems to be caused by audit support not being enabled in as if I rebuild 
with audit support the message goes away :)



I'm also observing some USB messages logged:

Sep  2 13:26:22 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 13
Sep  2 13:26:22 tornado kernel: drivers/usb/class/usblp.c: usblp0: USB 
Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6204
Sep  2 13:26:23 tornado kernel: hub 5-0:1.0: port 1 disabled by hub (EMI?), 
re-enabling...

Sep  2 13:26:23 tornado kernel: usb 5-1: USB disconnect, address 13
Sep  2 13:26:23 tornado kernel: drivers/usb/class/usblp.c: usblp0: removed
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 14

Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/64, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 15

Sep  2 13:26:23 tornado kernel: usb 5-1: device descriptor read/all, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 16

Sep  2 13:26:23 tornado kernel: usb 5-1: can't set config #1, error -71
Sep  2 13:26:23 tornado kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 17
Sep  2 13:26:24 tornado kernel: usb 5-1: unable to read config index 0 
descriptor/start

Sep  2 13:26:24 tornado kernel: usb 5-1: can't read configurations, error -71

[EMAIL PROTECTED] kernel]# lsusb
Bus 005 Device 004: ID 050d:0105 Belkin Components
Bus 005 Device 003: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
Bus 005 Device 001: ID :
Bus 004 Device 001: ID :
Bus 003 Device 001: ID :
Bus 002 Device 001: ID :
Bus 001 Device 001: ID :
[EMAIL PROTECTED] kernel]#

Output of lsusb -v up at http://www.reub.net/kernel/lsusb-output

reuben


-
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.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Brett Russ wrote:

This is my libata compatible low level driver for the Marvell SATA
family.  Currently it successfully runs in PIO mode on a 6081 chip.
EDMA support is in the works and should be done shortly.  Review,
testing (especially on other flavors of Marvell), comments welcome.


Note that this patch depends on the PCI INTx patch I submitted earlier:

http://lkml.org/lkml/2005/8/15/165

Sorry for the delayed notice,
BR
-
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/

[2.6 patch] i386/x86_64: make get_cpu_vendor() static

[Adrian Bunk]

get_cpu_vendor() no longer has any users in other files.


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

---

This patch was already sent on:
- 24 Aug 2005

 arch/i386/kernel/cpu/common.c |2 +-
 arch/x86_64/kernel/setup.c|2 +-
 include/asm-x86_64/proto.h|1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

--- linux-2.6.13-rc6-mm1-full/arch/i386/kernel/cpu/common.c.old 2005-08-23 
01:42:41.0 +0200
+++ linux-2.6.13-rc6-mm1-full/arch/i386/kernel/cpu/common.c 2005-08-23 
01:43:12.0 +0200
@@ -151,7 +151,7 @@
 }
 
 
-void __devinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
+static void __devinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
 {
char *v = c->x86_vendor_id;
int i;
--- linux-2.6.13-rc6-mm1-full/include/asm-x86_64/proto.h.old2005-08-23 
01:43:21.0 +0200
+++ linux-2.6.13-rc6-mm1-full/include/asm-x86_64/proto.h2005-08-23 
01:43:27.0 +0200
@@ -8,7 +8,6 @@
 struct cpuinfo_x86; 
 struct pt_regs;
 
-extern void get_cpu_vendor(struct cpuinfo_x86*);
 extern void start_kernel(void);
 extern void pda_init(int); 
 
--- linux-2.6.13-rc6-mm1-full/arch/x86_64/kernel/setup.c.old2005-08-23 
01:43:35.0 +0200
+++ linux-2.6.13-rc6-mm1-full/arch/x86_64/kernel/setup.c2005-08-23 
01:43:47.0 +0200
@@ -929,7 +929,7 @@
c->x86_num_cores = intel_num_cpu_cores(c);
 }
 
-void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c)
+static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c)
 {
char *v = c->x86_vendor_id;
 

-
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: A couple of OOM killer races

[Zhou Yingchao]

On 9/2/05, Richard Hayden <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> It appears there is no protection in badness() (called by
> out_of_memory() for each process) when it reads p->mm->total_vm. Another
> processor (or a kernel preemption) could presumably run do_exit and then
> exit_mm, freeing the process in question's reference to its mm just
> after the (!p->mm) check but before it reads p->mm->total_vm, making the
> latter reference a null pointer reference.

 In badness, the tasklist_lock has been hold. And when an exit signal
delived to it because other thread call do_group_exit, it need to hold
the tasklist_lock first, so we are protected.
  
-- 
Yingchao Zhou
-
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/

[2.6 patch] drivers/char/drm/: small cleanups

[Adrian Bunk]

This patch contains the following small cleanups:
- make two needlessly global functions static
- drm_sysfs.c: every file should #include the header with the prototypes 
   of the global functions it is offering


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

---

This patch was already sent on:
- 24 Aug 2005

 drivers/char/drm/drm_bufs.c|2 +-
 drivers/char/drm/drm_context.c |2 +-
 drivers/char/drm/drm_sysfs.c   |1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_bufs.c.old   2005-08-24 
16:55:50.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_bufs.c   2005-08-24 
16:56:06.0 +0200
@@ -1041,7 +1041,7 @@
return 0;
 }
 
-int drm_addbufs_fb(drm_device_t *dev, drm_buf_desc_t *request)
+static int drm_addbufs_fb(drm_device_t *dev, drm_buf_desc_t *request)
 {
drm_device_dma_t *dma = dev->dma;
drm_buf_entry_t *entry;
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_context.c.old
2005-08-24 16:56:29.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_context.c2005-08-24 
16:56:42.0 +0200
@@ -308,7 +308,7 @@
  *
  * Attempt to set drm_device::context_flag.
  */
-int drm_context_switch( drm_device_t *dev, int old, int new )
+static int drm_context_switch( drm_device_t *dev, int old, int new )
 {
 if ( test_and_set_bit( 0, >context_flag ) ) {
 DRM_ERROR( "Reentering -- FIXME\n" );
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_sysfs.c.old  2005-08-24 
16:57:02.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_sysfs.c  2005-08-24 
16:57:20.0 +0200
@@ -17,6 +17,7 @@
 #include 
 
 #include "drm_core.h"
+#include "drmP.h"
 
 struct drm_sysfs_class {
struct class_device_attribute attr;

-
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/

[2.6 patch] remove ACPI S4bios support

[Adrian Bunk]

Remove S4BIOS support. It is pretty useless, and only ever worked for
_me_ once. (I do not think anyone else ever tried it). It was in
feature-removal for a long time, and it should have been removed before.

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

---

This patch was already sent on:
- 22 Aug 2005

This patch was sent by Pavel Machek on:
- 12 Aug 2005

I made the following changes to it:
- drivers/acpi/sleep/proc.c chunk did no longer apply due to
  unrelated context changes
- remove the feature-removal-schedule.txt entry

 Documentation/feature-removal-schedule.txt |8 
 arch/i386/kernel/acpi/wakeup.S |6 --
 drivers/acpi/sleep/main.c  |8 
 drivers/acpi/sleep/poweroff.c  |4 +---
 drivers/acpi/sleep/proc.c  |2 --
 5 files changed, 1 insertion(+), 27 deletions(-)

--- linux-2.6.13-rc6-mm1-full/Documentation/feature-removal-schedule.txt.old
2005-08-22 00:32:08.0 +0200
+++ linux-2.6.13-rc6-mm1-full/Documentation/feature-removal-schedule.txt
2005-08-22 00:32:17.0 +0200
@@ -17,14 +17,6 @@
 
 ---
 
-What:  ACPI S4bios support
-When:  May 2005
-Why:   Noone uses it, and it probably does not work, anyway. swsusp is
-   faster, more reliable, and people are actually using it.
-Who:   Pavel Machek <[EMAIL PROTECTED]>
-

-
 What:  io_remap_page_range() (macro or function)
 When:  September 2005
 Why:   Replaced by io_remap_pfn_range() which allows more memory space
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -320,12 +320,6 @@ ret_point:
callrestore_processor_state
ret
 
-ENTRY(do_suspend_lowlevel_s4bios)
-   call save_processor_state
-   call save_registers
-   call acpi_enter_sleep_state_s4bios
-   ret
-
 ALIGN
 # saved registers
 saved_gdt: .long   0,0
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -23,7 +23,6 @@ u8 sleep_states[ACPI_S_STATE_COUNT];
 
 static struct pm_ops acpi_pm_ops;
 
-extern void do_suspend_lowlevel_s4bios(void);
 extern void do_suspend_lowlevel(void);
 
 static u32 acpi_suspend_states[] = {
@@ -98,8 +97,6 @@ static int acpi_pm_enter(suspend_state_t
case PM_SUSPEND_DISK:
if (acpi_pm_ops.pm_disk_mode == PM_DISK_PLATFORM)
status = acpi_enter_sleep_state(acpi_state);
-   else
-   do_suspend_lowlevel_s4bios();
break;
case PM_SUSPEND_MAX:
acpi_power_off();
@@ -206,11 +203,6 @@ static int __init acpi_sleep_init(void)
printk(" S%d", i);
}
if (i == ACPI_STATE_S4) {
-   if (acpi_gbl_FACS->S4bios_f) {
-   sleep_states[i] = 1;
-   printk(" S4bios");
-   acpi_pm_ops.pm_disk_mode = PM_DISK_FIRMWARE;
-   }
if (sleep_states[i])
acpi_pm_ops.pm_disk_mode = PM_DISK_PLATFORM;
}
diff --git a/drivers/acpi/sleep/poweroff.c b/drivers/acpi/sleep/poweroff.c
--- a/drivers/acpi/sleep/poweroff.c
+++ b/drivers/acpi/sleep/poweroff.c
@@ -21,9 +21,7 @@ int acpi_sleep_prepare(u32 acpi_state)
 {
 #ifdef CONFIG_ACPI_SLEEP
/* do we have a wakeup address for S2 and S3? */
-   /* Here, we support only S4BIOS, those we set the wakeup address */
-   /* S4OS is only supported for now via swsusp.. */
-   if (acpi_state == ACPI_STATE_S3 || acpi_state == ACPI_STATE_S4) {
+   if (acpi_state == ACPI_STATE_S3) {
if (!acpi_wakeup_address) {
return -EFAULT;
}
--- linux-2.6.13-rc6-mm1-full/drivers/acpi/sleep/proc.c.old 2005-08-22 
00:33:58.0 +0200
+++ linux-2.6.13-rc6-mm1-full/drivers/acpi/sleep/proc.c 2005-08-22 
00:34:55.0 +0200
@@ -25,8 +25,6 @@
for (i = 0; i <= ACPI_STATE_S5; i++) {
if (sleep_states[i]) {
seq_printf(seq, "S%d ", i);
-   if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f)
-   seq_printf(seq, "S4bios ");
}
}
 

-
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/

[2.6 patch] mm/filemap.c: make two functions static

[Adrian Bunk]

This patch makes two needlessly global functions static.


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

---

This patch was already sent on:
- 20 Aug 2005

--- linux-2.6.13-rc6-mm1/mm/filemap.c.old   2005-08-20 14:37:27.0 
+0200
+++ linux-2.6.13-rc6-mm1/mm/filemap.c   2005-08-20 14:46:24.0 +0200
@@ -2034,7 +2034,7 @@
 }
 EXPORT_SYMBOL(generic_file_buffered_write);
 
-ssize_t
+static ssize_t
 __generic_file_aio_write_nolock(struct kiocb *iocb, const struct iovec *iov,
unsigned long nr_segs, loff_t *ppos)
 {
@@ -2134,7 +2134,7 @@
return ret;
 }
 
-ssize_t
+static ssize_t
 __generic_file_write_nolock(struct file *file, const struct iovec *iov,
unsigned long nr_segs, loff_t *ppos)
 {

-
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/

[2.6 patch] drivers/net/wan/: possible cleanups

[Adrian Bunk]

This patch contains possible cleanups including the following:
- make needlessly global code static
- #if 0 the following unused global function:
  - sdladrv.c: sdla_intde
- remove the following unused global variable:
  - lmc_media.c: lmc_t1_cables
- remove the following unneeded EXPORT_SYMBOL's:
  - cycx_drv.c: cycx_inten
  - sdladrv.c: sdla_inten
  - sdladrv.c: sdla_intde
  - sdladrv.c: sdla_intack
  - sdladrv.c: sdla_intr
  - syncppp.c: sppp_input
  - syncppp.c: sppp_change_mtu

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

---

This patch was already sent on:
- 31 May 2005
- 18 Apr 2005

 drivers/net/wan/cycx_drv.c  |7 +-
 drivers/net/wan/cycx_main.c |2 
 drivers/net/wan/dscc4.c |   14 ++---
 drivers/net/wan/farsync.c   |   24 
 drivers/net/wan/hdlc_fr.c   |2 
 drivers/net/wan/lmc/lmc_debug.c |   10 +--
 drivers/net/wan/lmc/lmc_media.c |8 --
 drivers/net/wan/pc300.h |   16 -
 drivers/net/wan/pc300_drv.c |   87 
 drivers/net/wan/pc300_tty.c |   18 +++---
 drivers/net/wan/sdla.c  |   20 +++
 drivers/net/wan/sdladrv.c   |   16 ++---
 drivers/net/wan/syncppp.c   |   10 +--
 include/linux/cycx_drv.h|1 
 include/linux/sdladrv.h |4 -
 include/net/syncppp.h   |1 
 16 files changed, 101 insertions(+), 139 deletions(-)

--- linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h.old  2005-02-16 
19:14:39.0 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h  2005-02-16 
19:14:46.0 +0100
@@ -60,6 +60,5 @@
 extern int cycx_poke(struct cycx_hw *hw, u32 addr, void *buf, u32 len);
 extern int cycx_exec(void __iomem *addr);
 
-extern void cycx_inten(struct cycx_hw *hw);
 extern void cycx_intr(struct cycx_hw *hw);
 #endif /* _CYCX_DRV_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c.old2005-02-16 
19:14:55.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c2005-02-16 
19:15:35.0 +0100
@@ -110,7 +110,7 @@
  * < 0 error.
  * Context:process */
 
-int __init cycx_drv_init(void)
+static int __init cycx_drv_init(void)
 {
printk(KERN_INFO "%s v%u.%u %s\n", fullname, MOD_VERSION, MOD_RELEASE,
 copyright);
@@ -120,7 +120,7 @@
 
 /* Module 'remove' entry point.
  * o release all remaining system resources */
-void cycx_drv_cleanup(void)
+static void cycx_drv_cleanup(void)
 {
 }
 
@@ -185,8 +185,7 @@
 }
 
 /* Enable interrupt generation.  */
-EXPORT_SYMBOL(cycx_inten);
-void cycx_inten(struct cycx_hw *hw)
+static void cycx_inten(struct cycx_hw *hw)
 {
writeb(0, hw->dpmbase);
 }
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c.old   2005-02-16 
19:46:47.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c   2005-02-16 
19:47:00.0 +0100
@@ -103,7 +103,7 @@
  * < 0 error.
  * Context:process
  */
-int __init cycx_init(void)
+static int __init cycx_init(void)
 {
int cnt, err = -ENOMEM;
 
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c.old 2005-02-16 
23:57:37.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c 2005-02-17 
00:00:26.0 +0100
@@ -74,11 +74,11 @@
 /*
  * Modules parameters and associated varaibles
  */
-int fst_txq_low = FST_LOW_WATER_MARK;
-int fst_txq_high = FST_HIGH_WATER_MARK;
-int fst_max_reads = 7;
-int fst_excluded_cards = 0;
-int fst_excluded_list[FST_MAX_CARDS];
+static int fst_txq_low = FST_LOW_WATER_MARK;
+static int fst_txq_high = FST_HIGH_WATER_MARK;
+static int fst_max_reads = 7;
+static int fst_excluded_cards = 0;
+static int fst_excluded_list[FST_MAX_CARDS];
 
 module_param(fst_txq_low, int, 0);
 module_param(fst_txq_high, int, 0);
@@ -572,13 +572,13 @@
 static void fst_process_tx_work_q(unsigned long work_q);
 static void fst_process_int_work_q(unsigned long work_q);
 
-DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0);
-DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0);
+static DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0);
+static DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0);
 
-struct fst_card_info *fst_card_array[FST_MAX_CARDS];
-spinlock_t fst_work_q_lock;
-u64 fst_work_txq;
-u64 fst_work_intq;
+static struct fst_card_info *fst_card_array[FST_MAX_CARDS];
+static spinlock_t fst_work_q_lock;
+static u64 fst_work_txq;
+static u64 fst_work_intq;
 
 static void
 fst_q_work_item(u64 * queue, int card_index)
@@ -1498,7 +1498,7 @@
  *  The interrupt service routine
  *  Dev_id is our fst_card_info pointer
  */
-irqreturn_t
+static irqreturn_t
 fst_intr(int irq, void *dev_id, struct pt_regs *regs)
 {
struct fst_card_info *card;
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c.old 2005-02-17 
00:00:38.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/hdlc_fr.c 2005-02-17 
00:00:46.0 +0100
@@ -347,7 +347,7 @@
 
 
 
-int 

[2.6 patch] drivers/md/raid1.c: make a function static

[Adrian Bunk]

This patch makes a needlessly global function static.


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

---

This patch was already sent on:
- 22 Aug 2005

--- linux-2.6.13-rc6-mm1-full/drivers/md/raid1.c.old2005-08-22 
02:50:14.0 +0200
+++ linux-2.6.13-rc6-mm1-full/drivers/md/raid1.c2005-08-22 
02:50:31.0 +0200
@@ -1703,7 +1703,7 @@
return 0;
 }
 
-void raid1_quiesce(mddev_t *mddev, int state)
+static void raid1_quiesce(mddev_t *mddev, int state)
 {
conf_t *conf = mddev_to_conf(mddev);
 

-
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/

[2.6 patch] fs/cramfs/uncompress.c should #include (fwd)

[Adrian Bunk]

Every file should #include the header with the prototypes of the global 
functions it is offering.


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

---

This patch was already sent on:
- 24 Aug 2005

--- linux-2.6.13-rc6-mm1-full/fs/cramfs/uncompress.c.old2005-08-23 
01:56:47.0 +0200
+++ linux-2.6.13-rc6-mm1-full/fs/cramfs/uncompress.c2005-08-23 
01:57:09.0 +0200
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static z_stream stream;
 static int initialized;

-
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/

[2.6 patch] fs/super.c: unexport user_get_super

[Adrian Bunk]

There's no modular usage in the kernel and modules shouldn't use this 
symbol.


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

---

This patch was already sent on:
- 22 Aug 2005
- 30 May 2005
- 13 May 2005
- 1 May 2005
- 23 Apr 2005

--- linux-2.6.12-rc2-mm3-full/fs/super.c.old2005-04-23 02:45:59.0 
+0200
+++ linux-2.6.12-rc2-mm3-full/fs/super.c2005-04-23 02:46:07.0 
+0200
@@ -467,8 +467,6 @@
return NULL;
 }
 
-EXPORT_SYMBOL(user_get_super);
-
 asmlinkage long sys_ustat(unsigned dev, struct ustat __user * ubuf)
 {
 struct super_block *s;

-
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: [RFC][PATCH] Use proper casting with signed timespec.tv_nsec values

[George Anzinger]

john stultz wrote:

All,
I recently ran into a bug with an older kernel where xtime's tv_nsec
field had accumulated more then 2 seconds worth of time. The timespec's
tv_nsec is a signed long, however gettimeofday() treats it as an
unsigned long. Thus when the failure occured, very strange and difficult
to debug time problems occurred.

The main cause of the problem I was seeing is already fixed in mainline,
however just to be safe, I figured the following patch would be wise.

I only audited i386 and x86_64, however other arches probably could have
similar signed problems as well.

Please let me know if you have any further comments or feedback.


John,

There is a problem in the way this code handles the conversion to usec. 
 There is a conversion here and also in the get_offset code.  If the 
nanoseconds are carrier until after the addition of the two about 25% of 
the time you will end up with an additional usec in time.  I strongly 
suggest changing to convert to usec after the addition of xtime and 
get_offset time to avoid this.  If the "correct" thing is done in 
clock_gettime() (i.e. get_offset is in nanoseconds) this actually turns 
up as a back step in time WRT gettimeofday and clock_gettime().


George
--


thanks
-john

linux-2.6.13_signed-tv_nsec_A0.patch

diff --git a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c
+++ b/arch/i386/kernel/time.c
@@ -156,7 +156,7 @@ void do_gettimeofday(struct timeval *tv)
usec += lost * (USEC_PER_SEC / HZ);
 
 		sec = xtime.tv_sec;

-   usec += (xtime.tv_nsec / 1000);
+   usec += (unsigned long)xtime.tv_nsec / 1000;
} while (read_seqretry(_lock, seq));
 
 	while (usec >= 100) {

diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -128,7 +128,7 @@ void do_gettimeofday(struct timeval *tv)
seq = read_seqbegin(_lock);
 
 		sec = xtime.tv_sec;

-   usec = xtime.tv_nsec / 1000;
+   usec = (unsigned long)xtime.tv_nsec / 1000;
 
 		/* i386 does some correction here to keep the clock 
 		   monotonous even when ntpd is fixing drift.

diff --git a/kernel/timer.c b/kernel/timer.c
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -824,7 +824,7 @@ static void update_wall_time(unsigned lo
do {
ticks--;
update_wall_time_one_tick();
-   if (xtime.tv_nsec >= 10) {
+   if ((unsigned long)xtime.tv_nsec >= 10) {
xtime.tv_nsec -= 10;
xtime.tv_sec++;
second_overflow();


-
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/



--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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/

2.6.13-mm1 - drivers/serial/jsm/jsm_tty broken too

[Damir Perisa]

i disabled the isdn subsystem temporarely and tried to recompile 
finding out that jsm-tty is affected too:

 CC [M]  drivers/serial/jsm/jsm_tty.o
drivers/serial/jsm/jsm_tty.c: In function 'jsm_input':
drivers/serial/jsm/jsm_tty.c:592: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:619: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:620: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:623: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:624: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:667: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:668: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:669: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:670: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:671: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:672: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:674: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:677: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:680: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:681: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:682: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:691: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:692: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:693: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:694: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:695: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:696: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:698: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:701: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:742: error: 'struct tty_struct' has no member 
named 'flip'
drivers/serial/jsm/jsm_tty.c:742: error: 'struct tty_struct' has no member 
named 'flip'
make[3]: *** [drivers/serial/jsm/jsm_tty.o] Error 1
make[2]: *** [drivers/serial/jsm] Error 2
make[1]: *** [drivers/serial] Error 2
make: *** [drivers] Error 2

hope that this tty breaks will be fixed in mm2

greetings,
Damir

-- 
It would save me a lot of time if you just gave up and went mad now.


pgp60tBiLq0ox.pgp
Description: PGP signature

RE: [RFC/PATCH]reconfigure MSI registers after resume

[Shaohua Li]

On Thu, 2005-09-01 at 23:20 +0800, Nguyen, Tom L wrote:
> On Wednesday, August 31, 2005 2:44 PM Greg KH wrote:
> >>On Thu, Aug 18, 2005 at 01:35:46PM +0800, Shaohua Li wrote:
> >> Hi,
> >> It appears pci_enable_msi doesn't reconfigure msi registers if it
> >> successfully look up a msi for a device. It assumes the data and
> address
> >> registers unchanged after calling pci_disable_msi. But this isn't
> always
> >> true, such as in a suspend/resume circle. In my test system, the
> >> registers unsurprised become zero after a S3 resume. This patch fixes
> my
> >> problem, please look at it. MSIX might have the same issue, but I
> >> haven't taken a close look.
> 
> > Tom, any comments on this?
> 
> In the cases of suspend/resume, a device driver needs to restore its PCI
> configuration space registers, which include the MSI/MSI-X capability
> structures if a device uses MSI/MSI-X. I think reconfiguring MSI
> data/address each time a driver calls pci_enable_msi may not be
> necessary.
Just when you called pci_disable_msi, reconfiguring MSI registers should
be done. Is there any pain of reconfiguring MSI registers?
I don't understand why should we have the assumption. If you disabled
the ability, you must reconfigure it to me. This is the easy logic.

Thanks,
Shaohua

-
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-pm] PowerOP Take 2 1/3: ARM OMAP1 platform support

[David Brownell]

> Date: Wed, 31 Aug 2005 20:05:02 -0700
> From: Todd Poynor <[EMAIL PROTECTED]>
>
> David Brownell wrote:
> > Interesting.  I start to like this shape better; it moves more of the
> > logic to operating point code, where it can make the sysfs interface
> > talk in terms of meaningful abstractions, not cryptic numeric offsets.
> > But it was odd to see the first patch be platform-specific support,
> > rather than be a neutral framework into which platform-aware code plugs
> > different kinds of things...
>
> Since it is at a low layer below a number of possible interfaces, and 
> since there is no generic processing performed at this low layer (it's 
> pretty much set or get an opaque structure), there isn't any 
> higher-layer framework to plug into at the moment.

You're presenting PowerOP as a multi-platform thing in its own right.
I think that's my missing "higher level framework".  Although given the
other two patches in this group, maybe it was the sysfs API?  :)


>   If something like 
> these abstractions of power parameters and operating points are felt to 
> be a good foundation for a runtime power management stack then turning 
> our attentions to the next layer up (perhaps cpufreq or a new 
> embedded-oriented stack) would create that generic structure.

Something like -- certainly.  I suspect what I'm thinking about as the
API-visible structure is what you might want to call a range of operating
points, not just a single one ... example, "any CPU rate, low voltage, with
audio and display off".

In that example, suppose there are five choices for the CPU clock setting.
One way defines a different point for each choice, leading to five times
as many states as the one that just says "doesn't matter".

Come to think of it, I'm not clear how you think device drivers (a common
generic structure!) would interact with changes to power constraints.
Would you see the display driver being responsible for turning its power on
and off?  Or would code that switches operating points handle that too?
Should drivers get "here's the next operating point" calls?


> > One part I don't like is that the platform would be limited to tweaking
> > a predefined set of fields in registers.  That seems insufficient for
> > subsystems that may not be present on all boards.  
>
> Yes, the code currently assumes it would be tweaked for different 
> variants of platforms, partly due to the difficulty of implementing a 
> lean and mean way of integrating the different pieces.

Surely at least drawing a line between the on-chip hardware and
the drivers for external stuff is simple enough, though.  This
current construction would make it hard to draw that line, since
there's no distinction between the SOC logic (potentially very
reusable) and the board specific details (often less so) including
discrete devices and their drivers.


>   It sounds like 
> registering multiple handlers for multiple sets of power parameters may 
> be in order, although a single opaque structure shared between upper 
> layers and the handlers probably won't be sufficient any more.

I'm not sure why you say either of those things.  Surely the point
of the "echo pointname >file" operation is to change several
power constraints at once?  And I don't think you've talked much
about the layers on either side of PowerOP ... except maybe to say
they should exist.  :)


>  > Plus, to borrow some
> > terms from cpufreq, it only facilitates "usermode" governor models, never
> > "ondemand" or any other efficient quick-response adaptive algorithms.
>
> The sysfs interface does not itself handle such schemes, but the PowerOP 
> layer is fine with inserting beneath in-kernel algorithms.  Low-latency, 
> very frequent adjustments to power parameters are very much in mind for 
> what I'm trying to do, assuming embedded hardware will increasingly be 
> able to take advantage of aggressive runtime power management for 
> battery savings.

So you see why I want the "thing" seen by userspace to cover a range
of power states:  otherwise those "very frequent" adjustments would
always involve userspace transition and scheduling delays.


> ...
> > Alternatively, the "thing" could implement some adaptive algorithm
> > using local measurements, predictions, and feedback to adjust any
> > platform power parameters dynamically.  Maybe it'd delegate management
> > of the ARM clock to "cpufreq", and focus on managing power for other
> > board components that might never get really reusable code.  Switching
> > between operating points wouldn't require userspace instruction;
> > call it a "dynamic operating point" selection model.
>
> Interesting, although such close coordination of changing various clocks 
> and voltages is required on some platforms that it would be hard to 
> distribute it much among kernel components.

Much less "usermode" ones.  ;)

There will certainly be globs of functionality on a given platform
that don't factor nicely, and demand more 

RFC: i386: kill !4KSTACKS

[Adrian Bunk]

4Kb kernel stacks are the future on i386, and it seems the problems it
initially caused are now sorted out.

Does anyone knows about any currently unsolved problems?

I'd like to:
- get a patch into on of the next -mm kernels that unconditionally 
  enables 4KSTACKS
- if there won't be new reports of breakages, send a patch to
  completely remove !4KSTACKS for 2.6.15

In -mm, Reiser4 still has a dependency on !4KSTACKS.
I've mentioned this at least twice to the Reiser4 people, and they 
should check why this dependency is still there and if there are still 
stack issues in Reiser4 fix them.

If not people using Reiser4 on i386 will have to decide whether to 
switch the filesystem or the architecture...

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: Inconsistent kallsyms data error near the end of make in the linux kernel-2.6.13

Quoting Sabuj Pattanayek <[EMAIL PROTECTED]>:

> Hi all,

Hi, Sabuj

> I'm posting a bug as directed by REPORTING-BUGS in the kernel sources.
> 
> PROBLEM: Inconsistent kallsyms data error near the end of make in the linux
> kernel-2.6.13 .

This is probably a known problem.

Please check this thread:

http://lkml.org/lkml/2005/8/31/129

and use the patch I posted there.

I hope this helps,

--
Paulo Marques

-
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 0/10] m68k/thread_info merge

[Andrew Morton]

Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Can I assume that the five m68k patches can be split apart from the five
> patches which dink with task_struct?  ie: if the task_struct patches go in
> later, does anything bad happen?

eh, forget I asked that.  They're interdependent.
-
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 0/10] m68k/thread_info merge

[Andrew Morton]

Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> This patch series brings the m68k closer to a working state. It consists 
> of two basic parts, the first five patches do the minimal changes to get 
> m68k compiling in mainline, the last five patches do a cleanup of the 
> kernel API.

Can I assume that the five m68k patches can be split apart from the five
patches which dink with task_struct?  ie: if the task_struct patches go in
later, does anything bad happen?
-
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] via82cxxx IDE: Support multiple controllers

[Daniel Drake]

Bartlomiej Zolnierkiewicz wrote:

Same thing as with VT6420 support:

I'm still concerned about VIA IDE chipset + VT6410 combo
(AFAIR I've also seen VT6410 on PCI add-on card but I can be wrong).

via82cxxx.c needs to be fixed to support multiple controllers first.


Hows this? I don't have any hardware with two VIA controllers, however I have 
tested this on a pc which has a single vt8233a controller.


---

Support multiple controllers in the via82cxxx IDE driver

Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
--- linux/drivers/ide/pci/via82cxxx.c.orig	2005-08-31 01:32:05.0 +0100
+++ linux/drivers/ide/pci/via82cxxx.c	2005-09-02 01:16:59.0 +0100
@@ -101,11 +101,19 @@ static struct via_isa_bridge {
 	{ NULL }
 };
 
-static struct via_isa_bridge *via_config;
-static unsigned int via_80w;
-static unsigned int via_clock;
 static char *via_dma[] = { "MWDMA16", "UDMA33", "UDMA66", "UDMA100", "UDMA133" };
 
+struct via82cxxx_dev
+{
+	struct pci_dev *pci_dev, *isa_dev;
+	struct via_isa_bridge *via_config;
+	unsigned int via_clock;
+	unsigned int via_80w;
+};
+
+#define VIA_MAX_CONTROLLERS 4
+static struct via82cxxx_dev *via_controllers[VIA_MAX_CONTROLLERS];
+
 /*
  * VIA /proc entry.
  */
@@ -116,9 +124,6 @@ static char *via_dma[] = { "MWDMA16", "U
 #include 
 
 static u8 via_proc = 0;
-static unsigned long via_base;
-static struct pci_dev *bmide_dev, *isa_dev;
-
 static char *via_control3[] = { "No limit", "64", "128", "192" };
 
 #define via_print(format, arg...) p += sprintf(p, format "\n" , ## arg)
@@ -127,43 +132,42 @@ static char *via_control3[] = { "No limi
 
 
 /**
- *	via_get_info		-	generate via /proc file 
- *	@buffer: buffer for data
- *	@addr: set to start of data to use
- *	@offset: current file offset
- *	@count: size of read
+ *	via_print_controller_info	-	produce /proc info for one controller
+ *	@p: buffer for data
+ *	@hwif: hwif of controller
  *
  *	Fills in buffer with the debugging/configuration information for
- *	the VIA chipset tuning and attached drives
+ *	the VIA chipset tuning and attached drives on the specified
+ *	controller. Returns the end of the buffer that was reached.
  */
- 
-static int via_get_info(char *buffer, char **addr, off_t offset, int count)
+
+static char* via_print_controller_info(char *p, struct via82cxxx_dev *vdev)
 {
+	struct pci_dev *dev = vdev->pci_dev;
 	int speed[4], cycle[4], setup[4], active[4], recover[4], den[4],
 		 uen[4], udma[4], umul[4], active8b[4], recover8b[4];
-	struct pci_dev *dev = bmide_dev;
 	unsigned int v, u, i;
-	int len;
 	u16 c, w;
 	u8 t, x;
-	char *p = buffer;
+	unsigned long via_base;
 
 	via_print("--VIA BusMastering IDE Configuration"
 		"");
 
 	via_print("Driver Version: 3.38");
 	via_print("South Bridge:   VIA %s",
-		via_config->name);
+		vdev->via_config->name);
 
-	pci_read_config_byte(isa_dev, PCI_REVISION_ID, );
+	pci_read_config_byte(vdev->isa_dev, PCI_REVISION_ID, );
 	pci_read_config_byte(dev, PCI_REVISION_ID, );
 	via_print("Revision:   ISA %#x IDE %#x", t, x);
 	via_print("Highest DMA rate:   %s",
-		via_dma[via_config->flags & VIA_UDMA]);
+		via_dma[vdev->via_config->flags & VIA_UDMA]);
 
+	via_base = pci_resource_start(dev, 4);
 	via_print("BM-DMA base:%#lx", via_base);
 	via_print("PCI clock:  %d.%dMHz",
-		via_clock / 1000, via_clock / 100 % 10);
+		vdev->via_clock / 1000, vdev->via_clock / 100 % 10);
 
 	pci_read_config_byte(dev, VIA_MISC_1, );
 	via_print("Master Read  Cycle IRDY:%dws",
@@ -199,7 +203,7 @@ static int via_get_info(char *buffer, ch
 		(c & 0x80) ? "yes" : "no", (c & 0x8000) ? "yes" : "no");
 
 	via_print("Cable Type:%10s%20s",
-		(via_80w & 1) ? "80w" : "40w", (via_80w & 2) ? "80w" : "40w");
+		(vdev->via_80w & 1) ? "80w" : "40w", (vdev->via_80w & 2) ? "80w" : "40w");
 
 	via_print("---drive0drive1"
 		"drive2drive3-");
@@ -208,7 +212,7 @@ static int via_get_info(char *buffer, ch
 	pci_read_config_dword(dev, VIA_DRIVE_TIMING, );
 	pci_read_config_word(dev, VIA_8BIT_TIMING, );
 
-	if (via_config->flags & VIA_UDMA)
+	if (vdev->via_config->flags & VIA_UDMA)
 		pci_read_config_dword(dev, VIA_UDMA_TIMING, );
 	else u = 0;
 
@@ -224,32 +228,32 @@ static int via_get_info(char *buffer, ch
 		uen[i]   = ((u >> ((3 - i) << 3)) & 0x20);
 		den[i]   = (c & ((i & 1) ? 0x40 : 0x20) << ((i & 2) << 2));
 
-		speed[i] = 2 * via_clock / (active[i] + recover[i]);
-		cycle[i] = 100 * (active[i] + recover[i]) / via_clock;
+		speed[i] = 2 * vdev->via_clock / (active[i] + recover[i]);
+		cycle[i] = 100 * (active[i] + recover[i]) / vdev->via_clock;
 
 		if (!uen[i] || !den[i])
 			continue;
 
-		switch (via_config->flags & VIA_UDMA) {
+		switch (vdev->via_config->flags & VIA_UDMA) {
 
 			case VIA_UDMA_33:
-speed[i] = 2 * via_clock / udma[i];
-cycle[i] = 100 * udma[i] / 

[RFC: 2.6 patch] remove some unused IDE stuff

[Adrian Bunk]

This patch removes some dead IDE-related #define's and
"static inline" functions.

Please double-check it since I've only tested it with grep and didn't 
try compilation.


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

---

 arch/ppc/platforms/hdpu.c   |   40 ---
 include/asm-m68knommu/ide.h |   41 
 include/asm-parisc/ide.h|5 
 3 files changed, 86 deletions(-)

--- linux-2.6.13-mm1-full/arch/ppc/platforms/hdpu.c.old 2005-09-02 
02:02:33.0 +0200
+++ linux-2.6.13-mm1-full/arch/ppc/platforms/hdpu.c 2005-09-02 
02:04:08.0 +0200
@@ -608,46 +608,6 @@
}
 }
 
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-static int hdpu_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-   return check_region(from, extent);
-}
-
-static void
-hdpu_ide_request_region(ide_ioreg_t from, unsigned int extent, const char 
*name)
-{
-   request_region(from, extent, name);
-   return;
-}
-
-static void hdpu_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-   release_region(from, extent);
-   return;
-}
-
-static void __init
-hdpu_ide_pci_init_hwif_ports(hw_regs_t * hw, ide_ioreg_t data_port,
-ide_ioreg_t ctrl_port, int *irq)
-{
-   struct pci_dev *dev;
-
-   pci_for_each_dev(dev) {
-   if (((dev->class >> 8) == PCI_CLASS_STORAGE_IDE) ||
-   ((dev->class >> 8) == PCI_CLASS_STORAGE_RAID)) {
-   hw->irq = dev->irq;
-
-   if (irq != NULL) {
-   *irq = dev->irq;
-   }
-   }
-   }
-
-   return;
-}
-#endif
-
 void hdpu_heartbeat(void)
 {
if (mv64x60_read(, MV64x60_GPP_VALUE) & (1 << 5))
--- linux-2.6.13-mm1-full/include/asm-m68knommu/ide.h.old   2005-09-02 
02:04:17.0 +0200
+++ linux-2.6.13-mm1-full/include/asm-m68knommu/ide.h   2005-09-02 
02:10:11.0 +0200
@@ -141,47 +141,6 @@
 
 #define ide_init_default_irq(base) ide_default_irq(base)
 
-static IDE_INLINE int
-ide_request_irq(
-   unsigned int irq,
-   void (*handler)(int, void *, struct pt_regs *),
-   unsigned long flags,
-   const char *device,
-   void *dev_id)
-{
-#ifdef CONFIG_COLDFIRE
-   mcf_autovector(irq);
-#endif
-   return(request_irq(irq, handler, flags, device, dev_id));
-}
-
-
-static IDE_INLINE void
-ide_free_irq(unsigned int irq, void *dev_id)
-{
-   free_irq(irq, dev_id);
-}
-
-
-static IDE_INLINE int
-ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
-   return 0;
-}
-
-
-static IDE_INLINE void
-ide_request_region(ide_ioreg_t from, unsigned int extent, const char *name)
-{
-}
-
-
-static IDE_INLINE void
-ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-}
-
-
 static IDE_INLINE void
 ide_fix_driveid(struct hd_driveid *id)
 {
--- linux-2.6.13-mm1-full/include/asm-parisc/ide.h.old  2005-09-02 
02:05:19.0 +0200
+++ linux-2.6.13-mm1-full/include/asm-parisc/ide.h  2005-09-02 
02:08:39.0 +0200
@@ -20,11 +20,6 @@
 #define IDE_ARCH_OBSOLETE_INIT
 #define ide_default_io_ctl(base)   ((base) + 0x206) /* obsolete */
 
-#define ide_request_irq(irq,hand,flg,dev,id)   
request_irq((irq),(hand),(flg),(dev),(id))
-#define ide_free_irq(irq,dev_id)   free_irq((irq), (dev_id))
-#define ide_check_region(from,extent)  check_region((from), (extent))
-#define ide_request_region(from,extent,name)   request_region((from), 
(extent), (name))
-#define ide_release_region(from,extent)release_region((from), 
(extent))
 /* Generic I/O and MEMIO string operations.  */
 
 #define __ide_insw insw

-
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/

Inconsistent kallsyms data error near the end of make in the linux kernel-2.6.13

[Sabuj Pattanayek]

Hi all,

I'm posting a bug as directed by REPORTING-BUGS in the kernel sources.

PROBLEM: Inconsistent kallsyms data error near the end of make in the linux
kernel-2.6.13 .

1) Decompress full linux-2.6.13.tar.bz2 sources to /usr/src/linux
2) cp /boot/config-2.6.12.5 to /usr/src/linux/.config
3) make oldconfig
4) make && make modules_install
5) near the end of the make process this error shows up:

  SYSMAP  .tmp_System.map
Inconsistent kallsyms data
Try setting CONFIG_KALLSYMS_EXTRA_PASS
make: *** [vmlinux] Error 1

keywords: inconsistent kallsysms data, CONFIG_KALLSYMS_EXTRA_PASS

2.6.12.5 was the last working kernel version that compiled without any errors.
Setting CONFIG_KALLSYMS_EXTRA_PASS=y obviously fixes the problem, but it was
said in  that it should be reported so here is the report (.config
posted at the end).

src/linux# scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux eglimp 2.6.12.5 #1 SMP Mon Aug 22 15:42:02 CDT 2005 i686 AMD Athlon(tm)
MP 2800+ AuthenticAMD GNU/Linux

Gnu C  3.3.5-20050130
Gnu make   3.80
binutils   2.15.92.0.2
util-linux 2.12i
mount  2.12i
module-init-tools  3.0
e2fsprogs  1.38
reiserfsprogs  3.6.19
reiser4progs   line
xfsprogs   2.6.25
nfs-utils  1.0.6
Linux C Library2.3.5
Dynamic linker (ldd)   2.3.5
Procps 3.2.5
Net-tools  1.60
Kbd1.12
Sh-utils   5.2.1
udev   068
Modules Loaded sbp2 ohci1394 raw1394 ieee1394 e100 nvidia agpgart


src/linux# cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) MP 2800+
stepping: 0
cpu MHz : 2134.416
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips: 4210.68

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) Processor
stepping: 0
cpu MHz : 2134.416
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips: 4259.84


src/linux# cat /proc/modules
sbp2 22600 2 - Live 0xf8a3
ohci1394 32372 0 - Live 0xf8a1e000
raw1394 26860 0 - Live 0xf8a28000
ieee1394 301268 3 sbp2,ohci1394,raw1394, Live 0xf8a79000
e100 34816 0 - Live 0xf89c4000
nvidia 3708488 12 - Live 0xf8dd9000
agpgart 30160 1 nvidia, Live 0xf89ce000


src/linux# cat /proc/ioports
-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
04d0-04d1 : pnp 00:05
0cf8-0cff : PCI conf1
1000-10ff : :00:0a.0
1400-14ff : :00:0a.0
1800-18ff : :00:0a.1
1c00-1cff : :00:0a.1
2000-203f : :00:0b.0
2050-2053 : :00:00.0
3000-3fff : PCI Bus #02
  3000-307f : :02:05.0
  3080-30bf : :02:08.0
3080-30bf : e100
  30c0-30df : :02:04.0
30c0-30df : EMU10K1
  30e0-30e7 : :02:04.1
8000-8003 : PM1a_EVT_BLK
8004-8005 : PM1a_CNT_BLK
8008-800b : PM_TMR
8010-8015 : ACPI CPU throttle
8020-8023 : GPE0_BLK
f000-f00f : :00:07.1
  f000-f007 : ide0
  f008-f00f : ide1


src/linux# cat /proc/iomem
-0009f7ff : System RAM
0009f800-0009 : reserved
000a-000b : Video RAM area
000c-000cebff : Video ROM
000cf000-000d07ff : Adapter ROM
000f-000f : System ROM
0010-e1ee : System RAM
  0010-00587cb8 : Kernel code
  00587cb9-007160bf : Kernel data
e1ef-e1efefff : ACPI Tables
e1eff000-e1ef : ACPI Non-volatile Storage
e1f0-e1f7 : System RAM
e1f8-e1ff : reserved
e800-e8003fff : :00:09.0
e8004000-e8005fff : :00:0a.0
  e8004000-e8004fff : aic79xx
e8006000-e8007fff : :00:0a.1
  e8006000-e8006fff : aic79xx
e8008000-e80087ff : :00:09.0
  e8008000-e80087ff : ohci1394
e802-e803 : :00:0b.0
e900-e9ff : PCI Bus #01
  e900-e9ff : :01:05.0
e900-e9ff : nvidia
ea00-ea0f : PCI Bus #02
  ea00-ea01 : :02:08.0
ea00-ea01 : e100
  ea02-ea020fff : :02:00.0
   

I have Dothan stepping 6, is that C1?

[Sebastian Fabrycki]

Hi
Pentium M / Dothan steppings are: A1, A2, B0, B1, C0, C1. My /proc/cpuinfo 
shows stepping 6. Does this mean i have stepping C1?

If so, then can i compile cpufreq tables into kernel? I have centrino laptop 
without those tables in ACPI.
st3 wrote:
The only issue is that there are four different versions of Dothan CPUs for
A1, A2, B0, B1, C0 steppings. There is only one version for C1 stepping.

So, if i have C1 Dothan then i can compile voltage tables into kernel?

If yes, then can someone send me patch for kernel version 2.6.13 ?

I'm not subscribed to the list, please CC me.
-- 
Regards


--
Jedyny taki czat... >>> http://link.interia.pl/f18b0

-
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/

2.6.13 lockup at boot after/at cpu initialization

[Moses Leslie]

Hi,

On some older hardware I'm trying to use, 2.6.13 (and 2.6.12.3, the only
other 2.6 kernel tested on this hardware)  lock up right after boot, there
are no indications about what specifically is wrong.  The last few lines
before the lockup are:

382MB LOWMEM available
DMI 2.3 present
Allocating PCI resources starting at 
Built 1 zonelists
Kernel command line: root=/dev/hda1 ro
Initialing CPU#0

I can get the numbers if needed.

2.4.31 works without problems.

GCC: gcc version 3.3.5 (Debian 1:3.3.5-13)

I've tried noapic nolapic noacpi with the same results.

lspci -vvv, /proc/cpuinfo, and .config below.  More than happy to provide
any more information or whatever is needed.

Thanks,

Moses

:00:00.0 Host bridge: Intel Corp. 82810 GMCH [Graphics Memory Controller 
Hub] (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- SERR- Reset- FastB2B-

:00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR-  [disabled] [size=256K]

:01:0d.0 Ethernet controller: National Semiconductor Corporation DP83815 
(MacPhyter) Ethernet Controller
Subsystem: Netgear FA311 / FA312 (FA311 with WoL HW)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR-  [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

:01:0e.0 Ethernet controller: 3Com Corporation 3cSOHO100-TX Hurricane (rev 
30)
Subsystem: 3Com Corporation 3cSOHO100-TX Hurricane
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR-  [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 6
model name  : Celeron (Mendocino)
stepping: 5
cpu MHz : 531.725
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr
bogomips: 1061.68

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13
# Mon Aug 29 20:27:44 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y

Re: [PATCH] part 3 - Convert IPMI driver over to use refcounts

[Andrew Morton]

> The IPMI driver uses read/write locks to ensure that things
> exist while they are in use.  This is bad from a number of
> points of view.  This patch removes the rwlocks and uses
> refcounts and a special synced list (the entries can be
> refcounted and removal is blocked while an entry is in
> use).
> 

This:

> +
> +struct synced_list_entry_task_q
>  {
>   struct list_head link;
> + task_t   *process;
> +};
> +

> +#define synced_list_for_each_entry(pos, l, entry, flags) \
> + for ((spin_lock_irqsave(&(l)->lock, flags),   \
> +   pos = container_of((l)->head.next, typeof(*(pos)),entry.link)); \
> +  (prefetch((pos)->entry.link.next),   \
> +   &(pos)->entry.link != (&(l)->head)  \
> + ? (atomic_inc(&(pos)->entry.usecount),\
> +   spin_unlock_irqrestore(&(l)->lock, flags), 1)   \
> + : (spin_unlock_irqrestore(&(l)->lock, flags), 0));\
> +  (spin_lock_irqsave(&(l)->lock, flags),   \
> +   synced_list_wake(&(pos)->entry),\
> +  pos = container_of((pos)->entry.link.next, typeof(*(pos)), 
>  \
> +  entry.link)))

(gad)


And this:

> +static int synced_list_clear(struct synced_list *head,
> +  int (*match)(struct synced_list_entry *,
> +   void *),
> +  void (*free)(struct synced_list_entry *),
> +  void *match_data)
> +{
> + struct synced_list_entry *ent, *ent2;
> + int  rv = -ENODEV;
> + int  mrv = SYNCED_LIST_MATCH_CONTINUE;
> +
> + spin_lock_irq(>lock);
> + restart:
> + list_for_each_entry_safe(ent, ent2, >head, link) {
> + if (match) {
> + mrv = match(ent, match_data);
> + if (mrv == SYNCED_LIST_NO_MATCH)
> + continue;
> + }
> + if (atomic_read(>usecount)) {
> + struct synced_list_entry_task_q e;
> + e.process = current;
> + list_add(, >task_list);
> + __set_current_state(TASK_UNINTERRUPTIBLE);
> + spin_unlock_irq(>lock);
> + schedule();
> + spin_lock_irq(>lock);
> + list_del();
> + goto restart;
> + }
> + list_del(>link);
> + rv = 0;
> + if (free)
> + free(ent);
> + if (mrv == SYNCED_LIST_MATCH_STOP)
> + break;
> + }
> + spin_unlock_irq(>lock);
> + return rv;
> +}

Look awfully similar to wait_queue_head_t.  Are you sure existing
infrastructure cannot be used?

> 1 files changed, 692 insertions(+), 461 deletions(-)

Ow.  Why is it worthwhile?
-
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.13] Warning in the e1000 driver

[Jeff Kirsher]

On 9/1/05, Daniel Walker <[EMAIL PROTECTED]> wrote:
> 
> This should fix a small warning in the e1000 driver. It casts to the
> largest possible type dma field. This was found while compiling for
> X86_64 .
> 
> Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.13/drivers/net/e1000/e1000_main.c
> ===
> --- linux-2.6.13.orig/drivers/net/e1000/e1000_main.c2005-08-30 
> 18:28:41.0 +
> +++ linux-2.6.13/drivers/net/e1000/e1000_main.c 2005-08-30 19:42:45.0 
> +
> @@ -2767,7 +2767,7 @@ e1000_clean_tx_irq(struct e1000_adapter
> "  next_to_use  <%x>\n"
> "  next_to_clean<%x>\n"
> "buffer_info[next_to_clean]\n"
> -   "  dma  <%zx>\n"
> +   "  dma  <%llx>\n"
> "  time_stamp   <%lx>\n"
> "  next_to_watch<%x>\n"
> "  jiffies  <%lx>\n"
> @@ -2776,7 +2776,7 @@ e1000_clean_tx_irq(struct e1000_adapter
> E1000_READ_REG(>hw, TDT),
> tx_ring->next_to_use,
> i,
> -   tx_ring->buffer_info[i].dma,
> +   (unsigned long 
> long)tx_ring->buffer_info[i].dma,
> tx_ring->buffer_info[i].time_stamp,
> eop,
> jiffies,
> 
> 
> -
> 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/
> 

Just remove the following lines
> -   "  dma  <%zx>\n"
and
> -   tx_ring->buffer_info[i].dma,
from the DPRINTK statement.  The information being provided for debug
purposes is not that helpful when debugging anyway.

--
Cheers,
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/

Re: [PATCH 1/1] 8250_kgdb driver reworked

[Tom Rini]

On Thu, Sep 01, 2005 at 03:45:09PM -0700, Tom Rini wrote:

[snip]
> So digging back in CVS it seems this was added to fix a spurious
> interrupt that occured on an (probably) an x86_64 box when NMI support
> didn't work correctly.  I think it's safe enough to just drop this.

Since reposting seems to be getting more and more helpful feedback,
here's things again:

Index: linux-2.6.13/drivers/serial/8250.c
===
--- linux-2.6.13.orig/drivers/serial/8250.c
+++ linux-2.6.13/drivers/serial/8250.c
@@ -2516,6 +2516,27 @@ void serial8250_unregister_port(int line
 }
 EXPORT_SYMBOL(serial8250_unregister_port);
 
+/**
+ * serial8250_unregister_by_port - remove a 16x50 serial port
+ * at runtime.
+ * @port: A  uart_port that describes the port to remove.
+ *
+ * Remove one serial port.  This may not be called from interrupt
+ * context.  We hand the port back to the our control.
+ */
+void serial8250_unregister_by_port(struct uart_port *port)
+{
+   struct uart_8250_port *uart;
+
+   down(_sem);
+   uart = serial8250_find_match_or_unused(port);
+   up(_sem);
+
+   if (uart)
+   serial8250_unregister_port(uart->port.line);
+}
+EXPORT_SYMBOL(serial8250_unregister_by_port);
+
 static int __init serial8250_init(void)
 {
int ret, i;
Index: linux-2.6.13/drivers/serial/8250.h
===
--- linux-2.6.13.orig/drivers/serial/8250.h
+++ linux-2.6.13/drivers/serial/8250.h
@@ -19,6 +19,7 @@
 
 int serial8250_register_port(struct uart_port *);
 void serial8250_unregister_port(int line);
+void serial8250_unregister_by_port(struct uart_port *port);
 void serial8250_suspend_port(int line);
 void serial8250_resume_port(int line);
 
Index: linux-2.6.13/drivers/serial/Kconfig
===
--- linux-2.6.13.orig/drivers/serial/Kconfig
+++ linux-2.6.13/drivers/serial/Kconfig
@@ -87,7 +87,7 @@ config SERIAL_8250_ACPI
 
 config SERIAL_8250_NR_UARTS
int "Maximum number of 8250/16550 serial ports"
-   depends on SERIAL_8250
+   depends on SERIAL_8250 || KGDB_8250
default "4"
help
  Set this to the number of serial ports you want the driver
Index: linux-2.6.13/drivers/serial/Makefile
===
--- linux-2.6.13.orig/drivers/serial/Makefile
+++ linux-2.6.13/drivers/serial/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_SERIAL_JSM) += jsm/
 obj-$(CONFIG_SERIAL_TXX9) += serial_txx9.o
 obj-$(CONFIG_SERIAL_VR41XX) += vr41xx_siu.o
 obj-$(CONFIG_SERIAL_SGI_IOC4) += ioc4_serial.o
+obj-$(CONFIG_KGDB_8250) += 8250_kgdb.o
Index: linux-2.6.13/lib/Kconfig.debug
===
--- linux-2.6.13.orig/lib/Kconfig.debug
+++ linux-2.6.13/lib/Kconfig.debug
@@ -193,7 +193,7 @@ config KGDB_CONSOLE
 choice
prompt "Method for KGDB communication"
depends on KGDB
-   default KGDB_ONLY_MODULES
+   default KGDB_8250_NOMODULE
default KGDB_MPSC if SERIAL_MPSC
help
  There are a number of different ways in which you can communicate
@@ -212,6 +212,14 @@ config KGDB_ONLY_MODULES
  Use only kernel modules to configure KGDB I/O after the
  kernel is booted.
 
+config KGDB_8250_NOMODULE
+   bool "KGDB: On generic serial port (8250)"
+   select KGDB_8250
+   help
+ Uses generic serial port (8250) to communicate with the host
+ GDB.  This is independent of the normal (SERIAL_8250) driver
+ for this chipset.
+
 config KGDB_MPSC
bool "KGDB on MV64x60 MPSC"
depends on SERIAL_MPSC
@@ -219,4 +227,54 @@ config KGDB_MPSC
  Uses a Marvell GT64260B or MV64x60 Multi-Purpose Serial
  Controller (MPSC) channel. Note that the GT64260A is not
  supported.
+
 endchoice
+
+config KGDB_8250
+   tristate "KGDB: On generic serial port (8250)" if !KGDB_8250_NOMODULE
+   depends on m && KGDB_ONLY_MODULES
+   help
+ Uses generic serial port (8250) to communicate with the host
+ GDB.  This is independent of the normal (SERIAL_8250) driver
+ for this chipset.
+
+config KGDB_SIMPLE_SERIAL
+   bool "Simple selection of KGDB serial port"
+   depends on KGDB_8250
+   default y
+   help
+ If you say Y here, you will only have to pick the baud rate
+ and port number that you wish to use for KGDB.  Note that this
+ only works on architectures that register known serial ports
+ early on.  If you say N, you will have to provide, either here
+ or on the command line, the type (I/O or MMIO), IRQ and
+ address to use.  If in doubt, say Y.
+
+config KGDB_BAUDRATE
+   int "Debug serial port baud rate"
+   depends on (KGDB_8250 && KGDB_SIMPLE_SERIAL)
+   default "115200"
+   help
+ gdb and 

Re: Change in NFS client behavior

[Trond Myklebust]

on den 31.08.2005 Klokka 08:55 (-0600) skreiv Rob Sims:
> We have noticed when changing from kernel 2.4.23 to 2.6.8 that
> timestamps of files are not changed if opened for a write and nothing is
> written.  When using 2.4.23 timestamps are changed.  When using a local
> filesystem (reiserfs) with either kernel, timestamps are changed.
> Symptoms vary with the client, not the server.  See the script below.
> 
> When run on a 2.4.23 machine in an NFS mounted directory, output is
> "Good."  When run on a 2.6.8 or 2.6.12-rc4 machine in an NFS directory,
> output is "Error."
> 
> Is this a bug?  How do we revert to the 2.4/local fs behavior?  

This is a consequence of 2.6 NFS clients optimising away unnecessary
truncate calls. Whereas this is correct behaviour for truncate(), it
appears to be incorrect for open(O_TRUNC).

In fact, local filesystems like xfs and ext3 appear to have the opposite
problem: they change ctime if you call ftruncate(0) on the zero-length
file, as the attached test shows.

Cheers,
  Trond


#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
	struct stat buf1, buf2, buf3;
	int fd;

	if (argc != 2) {
		printf("syntax: %s filename\n", argv[0]);
		exit(1);
	}
	fd = open(argv[1], O_CREAT|O_EXCL|O_WRONLY, 0644);
	if (fd == -1) {
		perror("open(%s, O_CREAT|O_EXCL|O_WRONLY) failed\n", argv[1]);
		exit(1);
	}
	if (fstat(fd, ) == -1) {
		perror("fstat() failed\n");
		exit(1);
	}
	printf("File: %s, st_size = %lu, st_ctime = %s\n", argv[1],
			buf1.st_size,
			asctime(localtime(_ctime)));
	close(fd);
	sleep(2);
	fd = open(argv[1], O_TRUNC|O_WRONLY);
	if (fd == -1) {
		perror("open(%s, O_TRUNC|O_WRONLY) failed\n", argv[1]);
		exit(1);
	}
	if (fstat(fd, ) == -1) {
		perror("fstat() failed\n");
		exit(1);
	}
	printf("File: %s, st_size = %lu, st_ctime = %s\n", argv[1],
			buf2.st_size,
			asctime(localtime(_ctime)));
	if (buf1.st_ctime == buf2.st_ctime)
		printf("Bad behaviour in open(%s, O_TRUNC)!\n", argv[1]);
	sleep(2);
	if (ftruncate(fd, 0) == -1) {
		perror("ftruncate(0) failed\n");
		exit(1);
	}
	if (fstat(fd, ) == -1) {
		perror("fstat() failed\n");
		exit(1);
	}
	printf("File: %s, st_size = %lu, st_ctime = %s\n", argv[1],
			buf3.st_size,
			asctime(localtime(_ctime)));
	if (buf2.st_ctime != buf3.st_ctime)
		printf("Bad behaviour in ftruncate(0)!\n");
	close(fd);
	exit(0);
}

Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Jesper Juhl]

On 9/2/05, Ion Badulescu <[EMAIL PROTECTED]> wrote:
> Hi David,
> 
> On Thu, 1 Sep 2005, David S. Miller wrote:
> 
> > Thanks for the empty posting.  Please provide the content you
> > intended to post, and furthermore please post it to the network
> > developer mailing list, netdev@vger.kernel.org
> 
> First of all, thanks for the reply (even to an empty posting :).
> 
> The posting wasn't actually empty, it was probably too long (94K according

Two solutions commonly applied to that problem :

 - put the big file(s) online somewhere and include an URL in the email
 - compress the file(s) and attach the compressed files to the email

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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/

2.6.13-mm1: misc mwave issues

[Adrian Bunk]

On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc6-mm2:
>...
>  git-serial.patch
>...
>  Subsystem trees
>...

This patch contains Alan's patch for fixing the compilation of 
drivers/char/mwave/mwavedd.c, but the driver is still marked as BROKEN 
which should now be undone.

The MWAVE also got a comment
  # PLEASE DO NOT DO THIS - move this driver to drivers/serial

Since it seems this code is mostly unmaintained, can the
  mv drivers/char/mwave drivers/serial/
be done in the git-serial tree?

Additionally, drivers/char/mwave/mwavedd.c now requires an
  #include "8250.h"
for the serial8250_{,un}register_port prototypes.


TIA
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: 2.6.13-mm1: broken drivers/video/sis/Makefile

[Thomas Winischhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adrian Bunk wrote:
> On Thu, Sep 01, 2005 at 03:55:42AM -0700, Andrew Morton wrote:
> 
>>...
>>Changes since 2.6.13-rc6-mm2:
>>...
>>+sisfb-update.patch
>>...
>> fbdev updates
>>...
> 
> 
> This patch accidentally replaces drivers/video/sis/Makefile with a 
> toplevel Makefile.

ARGH. that happens if you work with four trees at the same time...

My appologies. Correct Makefile-patch attached.

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDF43FzydIRAktyUcRAptjAKDPQeYc3v5Ulu+HKnbRINsCNcfwwgCgkWnD
sJnT86TfSyX45JIW2KKRLog=
=TDOr
-END PGP SIGNATURE-
--- linux-2.6.13-orig/drivers/video/sis/Makefile2005-08-29 
01:41:01.0 +0200
+++ linux-2.6.13-sisfb/drivers/video/sis/Makefile   2005-09-02 
01:22:29.247255624 +0200
@@ -4,4 +4,4 @@
 
 obj-$(CONFIG_FB_SIS) += sisfb.o
 
-sisfb-objs := sis_main.o sis_accel.o init.o init301.o
+sisfb-objs := sis_main.o sis_accel.o init.o init301.o initextlfb.o

[2.6 patch] feature-removal-schedule.txt: remove {,un}register_serial entry

[Adrian Bunk]

If the feature is removed, there's no need to keep the entry in 
feature-removal-schedule.txt.


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

--- linux-2.6.13-mm1-full/Documentation/feature-removal-schedule.txt.old
2005-09-02 01:13:12.0 +0200
+++ linux-2.6.13-mm1-full/Documentation/feature-removal-schedule.txt
2005-09-02 01:13:29.0 +0200
@@ -77,16 +77,6 @@
 
 ---
 
-What:  register_serial/unregister_serial
-When:  September 2005
-Why:   This interface does not allow serial ports to be registered against
-   a struct device, and as such does not allow correct power management
-   of such ports.  8250-based ports should use serial8250_register_port
-   and serial8250_unregister_port, or platform devices instead.
-Who:   Russell King <[EMAIL PROTECTED]>
-

-
 What:  i2c sysfs name change: in1_ref, vid deprecated in favour of cpu0_vid
 When:  November 2005
 Files: drivers/i2c/chips/adm1025.c, drivers/i2c/chips/adm1026.c

-
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]kprobes comment patch around kprobes lock functions

[Keshavamurthy Anil S]

On Thu, Sep 01, 2005 at 02:09:38PM -0700, Andrew Morton wrote:
> Now, probably there's deep magic happening here and I'm wrong.  If so then
> please explain the code's magic via a comment patch so the question doesn't
> arise again, thanks.
> 

This is a comment patch around lock_kprobes() and unlock_kprobes() functions.

Signed-off-by: Anil S Keshavamurthy <[EMAIL PROTECTED]>

===
 kernel/kprobes.c |   14 ++
 1 files changed, 14 insertions(+)

Index: linux-2.6.13-mm1/kernel/kprobes.c
===
--- linux-2.6.13-mm1.orig/kernel/kprobes.c
+++ linux-2.6.13-mm1/kernel/kprobes.c
@@ -157,9 +157,16 @@ void __kprobes lock_kprobes(void)
 {
unsigned long flags = 0;
 
+   /* Avoiding local interrupts to happen right after we take the 
kprobe_lock
+* and before we get a chance to update kprobe_cpu, this to prevent
+* deadlock when we have a kprobe on ISR routine and a kprobe on task
+* routine
+*/
local_irq_save(flags);
+
spin_lock(_lock);
kprobe_cpu = smp_processor_id();
+
local_irq_restore(flags);
 }
 
@@ -167,9 +174,16 @@ void __kprobes unlock_kprobes(void)
 {
unsigned long flags = 0;
 
+   /* Avoiding local interrupts to happen right after we update
+* kprobe_cpu and before we get a a chance to release kprobe_lock,
+* this to prevent deadlock when we have a kprobe on ISR routine and
+* a kprobe on task routine
+*/
local_irq_save(flags);
+
kprobe_cpu = NR_CPUS;
spin_unlock(_lock);
+
local_irq_restore(flags);
 }
 
-
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/

[2.6 patch] drivers/serial/crisv10.c: remove {,un}register_serial dummies

[Adrian Bunk]

On Wed, Aug 31, 2005 at 10:33:52AM +0100, Russell King wrote:
>...
> In addition, the following drivers declare functions of the same name.
> The maintainers of these need to look to see why, and eliminate them
> where possible.
> 
> drivers/serial/crisv10.c:register_serial(struct serial_struct *req)
> drivers/serial/crisv10.c:void unregister_serial(int line)


It seems we can simply kill these dummies with this patch.


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

--- linux-2.6.13-mm1-full/drivers/serial/crisv10.c.old  2005-09-02 
01:10:07.0 +0200
+++ linux-2.6.13-mm1-full/drivers/serial/crisv10.c  2005-09-02 
01:10:27.0 +0200
@@ -5038,17 +5038,3 @@
 /* this makes sure that rs_init is called during kernel boot */
 
 module_init(rs_init);
-
-/*
- * register_serial and unregister_serial allows for serial ports to be
- * configured at run-time, to support PCMCIA modems.
- */
-int
-register_serial(struct serial_struct *req)
-{
-   return -1;
-}
-
-void unregister_serial(int line)
-{
-}

-
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] Ext3 online resizing locking issue (Again)

[Glauber de Oliveira Costa]

Hi.

Here is my new trial for the resize lock issue. 
Basically, it goes as follows: 

To ensure that only one resizer is running at a time, I added a global
lock that is acquired in the very beginning of ext3_group_add and
ext3_group_extend. 

lock_super is now only used in ext3_group_add in the moment we alter
s_groups_count, and released after the super block is marked dirty.

In ext3_group_extend, this is done outside the main function, so we can
do it trusting the lock to be already held while in remount, or
acquiring it explicitly while in ioctl. 

The lock in ext3_setup_new_group_blocks was simply wiped out, since this
is always called from one of the functions that already holds the lock
(and thus, in a safe environment)

Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>


-- 
=
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
[EMAIL PROTECTED]
=
Only in linux/fs/ext3/: .tmp_versions
Only in linux/fs/ext3/: fileidx
diff -bup linux-2.6.13-orig/fs/ext3/ioctl.c linux/fs/ext3/ioctl.c
--- linux-2.6.13-orig/fs/ext3/ioctl.c   2005-09-01 12:44:31.0 -0300
+++ linux/fs/ext3/ioctl.c   2005-09-01 11:42:22.0 -0300
@@ -207,6 +207,12 @@ flags_err:
return -EFAULT;
 
err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count);
+   if (!err){
+   lock_super(sb);
+   sb->s_dirt = 1;
+   unlock_super(sb);
+   }
+   
journal_lock_updates(EXT3_SB(sb)->s_journal);
journal_flush(EXT3_SB(sb)->s_journal);
journal_unlock_updates(EXT3_SB(sb)->s_journal);
Only in linux/fs/ext3/: patch
diff -bup linux-2.6.13-orig/fs/ext3/resize.c linux/fs/ext3/resize.c
--- linux-2.6.13-orig/fs/ext3/resize.c  2005-09-01 12:44:31.0 -0300
+++ linux/fs/ext3/resize.c  2005-09-01 19:30:40.0 -0300
@@ -23,6 +23,8 @@
 #define outside(b, first, last)((b) < (first) || (b) >= (last))
 #define inside(b, first, last) ((b) >= (first) && (b) < (last))
 
+DECLARE_MUTEX(resize_lock);
+
 static int verify_group_input(struct super_block *sb,
  struct ext3_new_group_data *input)
 {
@@ -178,7 +180,6 @@ static int setup_new_group_blocks(struct
if (IS_ERR(handle))
return PTR_ERR(handle);
 
-   lock_super(sb);
if (input->group != sbi->s_groups_count) {
err = -EBUSY;
goto exit_journal;
@@ -194,6 +195,7 @@ static int setup_new_group_blocks(struct
ext3_set_bit(0, bh->b_data);
}
 
+   smp_rmb();
/* Copy all of the GDT blocks into the backup in this group */
for (i = 0, bit = 1, block = start + 1;
 i < gdblocks; i++, block++, bit++) {
@@ -271,7 +273,6 @@ exit_bh:
brelse(bh);
 
 exit_journal:
-   unlock_super(sb);
if ((err2 = ext3_journal_stop(handle)) && !err)
err = err2;
 
@@ -706,6 +707,11 @@ int ext3_group_add(struct super_block *s
int gdb_off, gdb_num;
int err, err2;
 
+   if (unlikely(down_trylock(_lock))){
+   ext3_warning(sb,__FUNCTION__,"multiple resizers run on 
filesystem. Aborting\n");
+   return -EBUSY;
+   }
+
gdb_num = input->group / EXT3_DESC_PER_BLOCK(sb);
gdb_off = input->group % EXT3_DESC_PER_BLOCK(sb);
 
@@ -753,12 +759,6 @@ int ext3_group_add(struct super_block *s
goto exit_put;
}
 
-   lock_super(sb);
-   if (input->group != EXT3_SB(sb)->s_groups_count) {
-   ext3_warning(sb, __FUNCTION__,
-"multiple resizers run on filesystem!\n");
-   goto exit_journal;
-   }
 
if ((err = ext3_journal_get_write_access(handle, sbi->s_sbh)))
goto exit_journal;
@@ -847,6 +847,7 @@ int ext3_group_add(struct super_block *s
 */
smp_wmb();
 
+   lock_super(sb);
/* Update the global fs size fields */
EXT3_SB(sb)->s_groups_count++;
 
@@ -865,9 +866,9 @@ int ext3_group_add(struct super_block *s
 
ext3_journal_dirty_metadata(handle, EXT3_SB(sb)->s_sbh);
sb->s_dirt = 1;
+   unlock_super(sb);
 
 exit_journal:
-   unlock_super(sb);
if ((err2 = ext3_journal_stop(handle)) && !err)
err = err2;
if (!err) {
@@ -877,6 +878,7 @@ exit_journal:
   primary->b_size);
}
 exit_put:
+   up(_lock);
iput(inode);
return err;
 } /* ext3_group_add */
@@ -901,6 +903,12 @@ int ext3_group_extend(struct super_block
handle_t *handle;
int err, freed_blocks;
 
+
+   if (unlikely(down_trylock(_lock))){ 
+   ext3_warning(sb,__FUNCTION__,"multiple resizers run on 
filesystem. Aborting\n");
+   return -EBUSY;
+   }
+
/* We 

RE: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

[Protasevich, Natalie]

 

> -Original Message-
> From: Ashok Raj [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 01, 2005 3:27 PM
> To: Protasevich, Natalie
> Cc: Ashok Raj; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: [patch 1/1] Hot plug CPU to support physical add 
> of new processors (i386)
> 
> On Thu, Sep 01, 2005 at 04:09:09PM -0500, Protasevich, Natalie wrote:
> > > 
> > > > Current IA32 CPU hotplug code doesn't allow bringing up
> > > processors that were not present in the boot configuration. 
> > > > To make existing hot plug facility more practical for 
> physical hot 
> > > > plug, possible processors should be encountered during boot for 
> > > > potentual hot add/replace/remove. On ES7000, ACPI marks all the 
> > > > sockets that are empty or not assigned to the partitionas as 
> > > > "disabled". The patch allows arrays/masks with APIC info
> > > for disabled
> > > > processors to be
> > > 
> > > This sounds like a cluge to me. The correct 
> implementation would be 
> > > you would need some sysmgmt deamon or something that 
> works with the 
> > > kernel to notify of new cpus and populate apicid and grow 
> > > cpu_present_map. Making an assumption that disabled 
> APICID are valid 
> > > for ES7000 sake is not a safe assumption.
> > 
> > Yes, this is a kludge, I realize that. The AML code was not 
> there so 
> > far (it will be in the next one). I have a point here 
> though that if 
> > the processor is there, but is unusable (what "disabled" 
> means as the 
> > ACPI spec says), meaning bad maybe, then with physical hot 
> plug it can 
> > certainly be made usable and I think it should be taken into 
> > consideration (and into configuration). It should be counted as 
> > possible at least, with hot plug, because it represent 
> existing socket.
> 
> 
> I think marking it as present, and considering in 
> cpu_possible_map is perfectly ok. But we would need more glue 
> logic, that is if firmware marked it as disabled, then one 
> would expect you then run _STA and find that the CPU is now 
> present and functional as reported by _STA, then the CPU is onlinable.
> 
> So if _STA can work favorably in your case you can use it to 
> override the disabled setting at boot time which would be 
> prefectly fine.
> > 

We have a server control mechanism that sends appropriate messages and
notifications to the OS. The BIOS handles all the hardware level stuff,
including bringing the processor into appropriate state. The user level
driver handles those messages and uses OS facilities to bring up
processors and make them operational.

--Natalie 
> -- 
> Cheers,
> Ashok Raj
> - Open Source Technology Center
> 
-
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 12/12] UML - Fix x86_64 page leak

[Jeff Dike]

We were leaking pmd pages when 3_LEVEL_PGTABLES was enabled.  This fixes that.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/kernel/skas/include/mmu-skas.h
===
--- test.orig/arch/um/kernel/skas/include/mmu-skas.h2005-09-01 
16:54:41.0 -0400
+++ test/arch/um/kernel/skas/include/mmu-skas.h 2005-09-01 16:54:59.0 
-0400
@@ -6,11 +6,15 @@
 #ifndef __SKAS_MMU_H
 #define __SKAS_MMU_H
 
+#include "linux/config.h"
 #include "mm_id.h"
 
 struct mmu_context_skas {
struct mm_id id;
 unsigned long last_page_table;
+#ifdef CONFIG_3_LEVEL_PGTABLES
+unsigned long last_pmd;
+#endif
 };
 
 extern void switch_mm_skas(struct mm_id * mm_idp);
Index: test/arch/um/kernel/skas/mmu.c
===
--- test.orig/arch/um/kernel/skas/mmu.c 2005-09-01 16:51:15.0 -0400
+++ test/arch/um/kernel/skas/mmu.c  2005-09-01 16:57:00.0 -0400
@@ -56,6 +56,9 @@
 */
 
 mm->context.skas.last_page_table = pmd_page_kernel(*pmd);
+#ifdef CONFIG_3_LEVEL_PGTABLES
+mm->context.skas.last_pmd = (unsigned long) __va(pud_val(*pud));
+#endif
 
*pte = mk_pte(virt_to_page(kernel), __pgprot(_PAGE_PRESENT));
*pte = pte_mkexec(*pte);
@@ -144,6 +147,10 @@
 
if(!proc_mm || !ptrace_faultinfo){
free_page(mmu->id.stack);
-   free_page(mmu->last_page_table);
+   pte_free_kernel((pte_t *) mmu->last_page_table);
+dec_page_state(nr_page_table_pages);
+#ifdef CONFIG_3_LEVEL_PGTABLES
+   pmd_free((pmd_t *) mmu->last_pmd);
+#endif
}
 }
Index: test/include/asm-um/pgalloc.h
===
--- test.orig/include/asm-um/pgalloc.h  2005-09-01 16:51:15.0 -0400
+++ test/include/asm-um/pgalloc.h   2005-09-01 16:51:36.0 -0400
@@ -42,11 +42,13 @@
 #define __pte_free_tlb(tlb,pte) tlb_remove_page((tlb),(pte))
 
 #ifdef CONFIG_3_LEVEL_PGTABLES
-/*
- * In the 3-level case we free the pmds as part of the pgd.
- */
-#define pmd_free(x)do { } while (0)
-#define __pmd_free_tlb(tlb,x)  do { } while (0)
+
+extern __inline__ void pmd_free(pmd_t *pmd)
+{
+   free_page((unsigned long)pmd);
+}
+
+#define __pmd_free_tlb(tlb,x)   tlb_remove_page((tlb),virt_to_page(x))
 #endif
 
 #define check_pgt_cache()  do { } while (0)
Index: test/include/asm-um/pgtable-3level.h
===
--- test.orig/include/asm-um/pgtable-3level.h   2005-09-01 16:51:15.0 
-0400
+++ test/include/asm-um/pgtable-3level.h2005-09-01 16:51:36.0 
-0400
@@ -69,14 +69,11 @@
 return pmd;
 }
 
-static inline void pmd_free(pmd_t *pmd){
-   free_page((unsigned long) pmd);
+extern inline void pud_clear (pud_t *pud)
+{
+set_pud(pud, __pud(0));
 }
 
-#define __pmd_free_tlb(tlb,x)   do { } while (0)
-
-static inline void pud_clear (pud_t * pud) { }
-
 #define pud_page(pud) \
((struct page *) __va(pud_val(pud) & PAGE_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: [RFC][CFLART] ipmi procfs bogosity

[Corey Minyard]

Andrew Morton wrote:


Corey Minyard <[EMAIL PROTECTED]> wrote:
 


Indeed, this function is badly written.  In rewriting, I couldn't find a
nice function for reading integers from userspace, and the proc_dointvec
stuff didn't seem terribly suitable.
   



We write numbers into profs files all the time.  Is there something
different about the IPMI requirement which makes the approach used by, say,
dirty_writeback_centisecs_handler() inappropriate?
 

Ok, that's probably better, and this probably belongs in 
/proc/sys/dev/ipmi.  This is new enough that it doesn't matter, I don't 
think any one is using it yet.


Patch is attached.

-Corey


ipmi-poweroff-fix-chassis-ctrl.patch
Description: unknown/unknown

Re: [PATCH 1/2] pci: Block config access during BIST (resend)

[Andrew Morton]

Brian King <[EMAIL PROTECTED]> wrote:
>
> +void pci_block_user_cfg_access(struct pci_dev *dev)
> +{
> + unsigned long flags;
> +
> + pci_save_state(dev);
> + spin_lock_irqsave(_lock, flags);
> + dev->block_ucfg_access = 1;
> + spin_unlock_irqrestore(_lock, flags);

Are you sure the locking in here is meaningful?  All it will really do is
give you a couple of barriers.

-
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 8/12] UML - Increase granularity of host capability checking

[Jeff Dike]

From: Bodo Stroesser <[EMAIL PROTECTED]>

This change enables SKAS0/SKAS3 to work with all combinations
of /proc/mm and PTRACE_FAULTINFO being available or not.

Also it changes the initialization of proc_mm and
ptrace_faultinfo slightly, to ease forcing SKAS0 on a patched
host. Forcing UML to run without /proc/mm or PTRACE_FAULTINFO
by cmdline parameter can be implemented with a setup resetting
the related variable.

Signed-off-by: Bodo Stroesser <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/kernel/skas/include/skas.h
===
--- test.orig/arch/um/kernel/skas/include/skas.h2005-09-01 
16:03:16.0 -0400
+++ test/arch/um/kernel/skas/include/skas.h 2005-09-01 16:21:00.0 
-0400
@@ -33,7 +33,7 @@
 unsigned long len, int r, int w, int x, int done,
 void *data);
 extern void user_signal(int sig, union uml_pt_regs *regs, int pid);
-extern int new_mm(int from);
+extern int new_mm(int from, unsigned long stack);
 extern int start_userspace(unsigned long stub_stack);
 extern int copy_context_skas0(unsigned long stack, int pid);
 extern void get_skas_faultinfo(int pid, struct faultinfo * fi);
Index: test/arch/um/kernel/skas/mmu.c
===
--- test.orig/arch/um/kernel/skas/mmu.c 2005-09-01 16:03:16.0 -0400
+++ test/arch/um/kernel/skas/mmu.c  2005-09-01 16:21:00.0 -0400
@@ -77,23 +77,14 @@
struct mm_struct *cur_mm = current->mm;
struct mm_id *cur_mm_id = _mm->context.skas.id;
struct mm_id *mm_id = >context.skas.id;
-   unsigned long stack;
-   int from, ret;
+   unsigned long stack = 0;
+   int from, ret = -ENOMEM;
 
-   if(proc_mm){
-   if((cur_mm != NULL) && (cur_mm != _mm))
-   from = cur_mm->context.skas.id.u.mm_fd;
-   else from = -1;
-
-   ret = new_mm(from);
-   if(ret < 0){
-   printk("init_new_context_skas - new_mm failed, "
-  "errno = %d\n", ret);
-   return ret;
-   }
-   mm_id->u.mm_fd = ret;
-   }
-   else {
+   if(!proc_mm || !ptrace_faultinfo){
+   stack = get_zeroed_page(GFP_KERNEL);
+   if(stack == 0)
+   goto out;
+  
/* This zeros the entry that pgd_alloc didn't, needed since
 * we are about to reinitialize it, and want mm.nr_ptes to
 * be accurate.
@@ -103,20 +94,30 @@
ret = init_stub_pte(mm, CONFIG_STUB_CODE,
(unsigned long) &__syscall_stub_start);
if(ret)
-   goto out;
-
-   ret = -ENOMEM;
-   stack = get_zeroed_page(GFP_KERNEL);
-   if(stack == 0)
-   goto out;
-   mm_id->stack = stack;
+   goto out_free;
 
ret = init_stub_pte(mm, CONFIG_STUB_DATA, stack);
if(ret)
goto out_free;
 
dec_mm_counter(mm, nr_ptes);
+   }
+   mm_id->stack = stack;
 
+   if(proc_mm){
+   if((cur_mm != NULL) && (cur_mm != _mm))
+   from = cur_mm_id->u.mm_fd;
+   else from = -1;
+
+   ret = new_mm(from, stack);
+   if(ret < 0){
+   printk("init_new_context_skas - new_mm failed, "
+  "errno = %d\n", ret);
+   goto out_free;
+   }
+   mm_id->u.mm_fd = ret;
+   }
+   else {
if((cur_mm != NULL) && (cur_mm != _mm))
mm_id->u.pid = copy_context_skas0(stack,
  cur_mm_id->u.pid);
@@ -126,7 +127,8 @@
return 0;
 
  out_free:
-   free_page(mm_id->stack);
+   if(mm_id->stack != 0)
+   free_page(mm_id->stack);
  out:
return ret;
 }
@@ -137,8 +139,10 @@
 
if(proc_mm)
os_close_file(mmu->id.u.mm_fd);
-   else {
+   else
os_kill_ptraced_process(mmu->id.u.pid, 1);
+
+   if(!proc_mm || !ptrace_faultinfo){
free_page(mmu->id.stack);
free_page(mmu->last_page_table);
}
Index: test/arch/um/kernel/skas/process.c
===
--- test.orig/arch/um/kernel/skas/process.c 2005-09-01 16:02:46.0 
-0400
+++ test/arch/um/kernel/skas/process.c  2005-09-01 16:21:00.0 -0400
@@ -138,6 +138,8 @@
 }
 
 extern int __syscall_stub_start;
+int stub_code_fd = -1;
+__u64 stub_code_offset;
 
 static int userspace_tramp(void *stack)
 {
@@ -152,31 +154,31 @@
/* This has a pte, but it can't be 

[PATCH 2/12] UML - x86_64 build fix

[Jeff Dike]

semaphore.c is no longer available from arch/x86_64, so we just pick up the
generic version instead.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: linux-2.6.13-mm1/arch/um/sys-x86_64/Makefile
===
--- linux-2.6.13-mm1.orig/arch/um/sys-x86_64/Makefile   2005-09-01 
15:52:25.0 -0400
+++ linux-2.6.13-mm1/arch/um/sys-x86_64/Makefile2005-09-01 
15:53:04.0 -0400
@@ -6,7 +6,7 @@
 
 #XXX: why into lib-y?
 lib-y = bitops.o bugs.o csum-partial.o delay.o fault.o mem.o memcpy.o \
-   ptrace.o ptrace_user.o semaphore.o sigcontext.o signal.o stub.o \
+   ptrace.o ptrace_user.o sigcontext.o signal.o stub.o \
stub_segv.o syscalls.o syscall_table.o sysrq.o thunk.o
 
 obj-y := ksyms.o
@@ -15,7 +15,7 @@
 USER_OBJS := ptrace_user.o sigcontext.o
 
 SYMLINKS = bitops.c csum-copy.S csum-partial.c csum-wrappers.c memcpy.S \
-   semaphore.c thunk.S module.c
+   thunk.S module.c
 
 include arch/um/scripts/Makefile.rules
 
@@ -24,7 +24,6 @@
 csum-partial.c-dir = lib
 csum-wrappers.c-dir = lib
 memcpy.S-dir = lib
-semaphore.c-dir = kernel
 thunk.S-dir = lib
 module.c-dir = 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
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/12] UML - Use host AIO support

[Jeff Dike]

This patch makes UML use host AIO support when it (and 
/usr/include/linux/aio_abi.h) are present.  This is only the support, with
no consumers - a consumer is coming in the next patch.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/include/aio.h
===
--- test.orig/arch/um/include/aio.h 2005-09-01 07:45:10.520901648 -0400
+++ test/arch/um/include/aio.h  2005-09-01 17:09:05.0 -0400
@@ -0,0 +1,28 @@
+/* 
+ * Copyright (C) 2004 Jeff Dike ([EMAIL PROTECTED])
+ * Licensed under the GPL
+ */
+
+#ifndef AIO_H__
+#define AIO_H__
+
+enum aio_type { AIO_READ, AIO_WRITE, AIO_MMAP };
+
+struct aio_thread_reply {
+   void *data;
+   int err;
+};
+
+struct aio_context {
+   int reply_fd;
+   struct aio_context *next;
+};
+
+#define INIT_AIO_CONTEXT { .reply_fd   = -1, \
+  .next= NULL }
+
+extern int submit_aio(enum aio_type type, int fd, char *buf, int len, 
+ unsigned long long offset, int reply_fd, 
+  struct aio_context *aio);
+
+#endif
Index: test/arch/um/include/init.h
===
--- test.orig/arch/um/include/init.h2005-06-17 15:48:29.0 -0400
+++ test/arch/um/include/init.h 2005-09-01 16:04:47.0 -0400
@@ -111,7 +111,15 @@
 
 #ifndef __KERNEL__
 
-#define __initcall(fn) static initcall_t __initcall_##fn __init_call = fn
+#define __define_initcall(level,fn) \
+   static initcall_t __initcall_##fn __attribute_used__ \
+   __attribute__((__section__(".initcall" level ".init"))) = fn
+
+/* Userspace initcalls shouldn't depend on anything in the kernel, so we'll
+ * make them run first.
+ */
+#define __initcall(fn) __define_initcall("1", fn)
+
 #define __exitcall(fn) static exitcall_t __exitcall_##fn __exit_call = fn
 
 #define __init_call __attribute__ ((unused,__section__ (".initcall.init")))
Index: test/arch/um/include/irq_kern.h
===
--- test.orig/arch/um/include/irq_kern.h2005-06-17 15:48:29.0 
-0400
+++ test/arch/um/include/irq_kern.h 2005-09-01 16:04:47.0 -0400
@@ -7,12 +7,15 @@
 #define __IRQ_KERN_H__
 
 #include "linux/interrupt.h"
+#include "asm/ptrace.h"
 
 extern int um_request_irq(unsigned int irq, int fd, int type,
  irqreturn_t (*handler)(int, void *,
 struct pt_regs *),
  unsigned long irqflags,  const char * devname,
  void *dev_id);
+extern int init_aio_irq(int irq, char *name, 
+   irqreturn_t (*handler)(int, void *, struct pt_regs *));
 
 #endif
 
Index: test/arch/um/kernel/irq.c
===
--- test.orig/arch/um/kernel/irq.c  2005-09-01 16:02:46.0 -0400
+++ test/arch/um/kernel/irq.c   2005-09-01 17:09:18.0 -0400
@@ -31,7 +31,7 @@
 #include "kern_util.h"
 #include "irq_user.h"
 #include "irq_kern.h"
-
+#include "os.h"
 
 /*
  * Generic, controller-independent functions:
@@ -168,13 +168,32 @@
}
 }
 
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
+int init_aio_irq(int irq, char *name, irqreturn_t (*handler)(int, void *, 
+struct pt_regs *))
+{
+   int fds[2], err;
+
+   err = os_pipe(fds, 1, 1);
+   if(err){
+   printk("init_aio_irq - os_pipe failed, err = %d\n", -err);
+   goto out;
+   }
+
+   err = um_request_irq(irq, fds[0], IRQ_READ, handler,
+SA_INTERRUPT | SA_SAMPLE_RANDOM, name, 
+(void *) (long) fds[0]);
+   if(err){
+   printk("init_aio_irq - : um_request_irq failed, err = %d\n",
+  err);
+   goto out_close;
+   }
+
+   err = fds[1];
+   goto out;
+   
+ out_close:
+   os_close_file(fds[0]);
+   os_close_file(fds[1]);
+ out:
+   return(err);
+}
Index: test/arch/um/os-Linux/Makefile
===
--- test.orig/arch/um/os-Linux/Makefile 2005-06-17 15:48:29.0 -0400
+++ test/arch/um/os-Linux/Makefile  2005-09-01 17:09:05.0 -0400
@@ -3,11 +3,15 @@
 # Licensed under the GPL
 #
 
-obj-y = elf_aux.o file.o process.o signal.o time.o tty.o user_syms.o drivers/ \
-   sys-$(SUBARCH)/
+obj-y = aio.o elf_aux.o file.o process.o signal.o time.o tty.o user_syms.o \
+   drivers/ sys-$(SUBARCH)/
 

[PATCH 3/12] UML - System call path cleanup

[Jeff Dike]

This merges two sets of files which had no business being split apart in the
first place.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: linux-2.6.13/arch/um/include/syscall.h
===
--- linux-2.6.13.orig/arch/um/include/syscall.h 2005-08-31 04:29:26.191951656 
-0400
+++ linux-2.6.13/arch/um/include/syscall.h  2005-08-30 19:36:48.0 
-0400
@@ -0,0 +1,12 @@
+/* 
+ * Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED])
+ * Licensed under the GPL
+ */
+
+#ifndef __SYSCALL_USER_H
+#define __SYSCALL_USER_H
+
+extern int record_syscall_start(int syscall);
+extern void record_syscall_end(int index, long result);
+
+#endif
Index: linux-2.6.13/arch/um/include/syscall_user.h
===
--- linux-2.6.13.orig/arch/um/include/syscall_user.h2005-08-30 
19:35:44.0 -0400
+++ linux-2.6.13/arch/um/include/syscall_user.h 2005-08-31 04:29:26.191951656 
-0400
@@ -1,23 +0,0 @@
-/* 
- * Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED])
- * Licensed under the GPL
- */
-
-#ifndef __SYSCALL_USER_H
-#define __SYSCALL_USER_H
-
-extern int record_syscall_start(int syscall);
-extern void record_syscall_end(int index, long result);
-
-#endif
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
Index: linux-2.6.13/arch/um/include/sysdep-i386/syscalls.h
===
--- linux-2.6.13.orig/arch/um/include/sysdep-i386/syscalls.h2005-08-30 
19:35:44.0 -0400
+++ linux-2.6.13/arch/um/include/sysdep-i386/syscalls.h 2005-08-30 
19:36:27.0 -0400
@@ -16,6 +16,8 @@
 
 extern syscall_handler_t old_mmap_i386;
 
+extern syscall_handler_t *sys_call_table[];
+
 #define EXECUTE_SYSCALL(syscall, regs) \
((long (*)(struct syscall_args)) 
(*sys_call_table[syscall]))(SYSCALL_ARGS(>regs))
 
Index: linux-2.6.13/arch/um/include/sysdep-x86_64/syscalls.h
===
--- linux-2.6.13.orig/arch/um/include/sysdep-x86_64/syscalls.h  2005-08-30 
19:35:44.0 -0400
+++ linux-2.6.13/arch/um/include/sysdep-x86_64/syscalls.h   2005-08-30 
19:36:27.0 -0400
@@ -14,6 +14,8 @@
 
 extern syscall_handler_t *ia32_sys_call_table[];
 
+extern syscall_handler_t *sys_call_table[];
+
 #define EXECUTE_SYSCALL(syscall, regs) \
(((long (*)(long, long, long, long, long, long)) \
  (*sys_call_table[syscall]))(UPT_SYSCALL_ARG1(>regs), \
Index: linux-2.6.13/arch/um/kernel/Makefile
===
--- linux-2.6.13.orig/arch/um/kernel/Makefile   2005-08-30 19:35:44.0 
-0400
+++ linux-2.6.13/arch/um/kernel/Makefile2005-08-30 20:08:47.0 
-0400
@@ -18,7 +18,7 @@
 obj-$(CONFIG_GPROF)+= gprof_syms.o
 obj-$(CONFIG_GCOV) += gmon_syms.o
 obj-$(CONFIG_TTY_LOG)  += tty_log.o
-obj-$(CONFIG_SYSCALL_DEBUG) += syscall_user.o
+obj-$(CONFIG_SYSCALL_DEBUG) += syscall.o
 
 obj-$(CONFIG_MODE_TT) += tt/
 obj-$(CONFIG_MODE_SKAS) += skas/
Index: linux-2.6.13/arch/um/kernel/skas/Makefile
===
--- linux-2.6.13.orig/arch/um/kernel/skas/Makefile  2005-08-30 
19:35:44.0 -0400
+++ linux-2.6.13/arch/um/kernel/skas/Makefile   2005-08-30 20:39:46.0 
-0400
@@ -4,7 +4,7 @@
 #
 
 obj-y := clone.o exec_kern.o mem.o mem_user.o mmu.o process.o process_kern.o \
-   syscall_kern.o syscall_user.o tlb.o trap_user.o uaccess.o \
+   syscall.o tlb.o trap_user.o uaccess.o
 
 subdir- := util
 
Index: linux-2.6.13/arch/um/kernel/skas/syscall.c
===
--- linux-2.6.13.orig/arch/um/kernel/skas/syscall.c 2005-08-31 
04:29:26.191951656 -0400
+++ linux-2.6.13/arch/um/kernel/skas/syscall.c  2005-08-31 15:33:26.0 
-0400
@@ -0,0 +1,50 @@
+/* 
+ * Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED])
+ * Licensed under the GPL
+ */
+
+#include "linux/sys.h"
+#include "linux/ptrace.h"
+#include "asm/errno.h"
+#include "asm/unistd.h"
+#include "asm/ptrace.h"
+#include "asm/current.h"
+#include "sysdep/syscalls.h"
+#include "kern_util.h"
+#include "syscall.h"
+
+void handle_syscall(union uml_pt_regs *r)
+{
+   struct pt_regs *regs = container_of(r, struct pt_regs, regs);
+   long result;
+   int syscall;
+#ifdef UML_CONFIG_SYSCALL_DEBUG
+   int index;
+
+   index = record_syscall_start(UPT_SYSCALL_NR(r));
+#endif
+   syscall_trace(r, 0);
+
+   current->thread.nsyscalls++;
+   nsyscalls++;
+
+   /* This should go in the declaration of syscall, but 

[PATCH 1/12] UML - tty fix

[Jeff Dike]

This fixes a build breakage introduced by Alan's tty cleanups.  This should
be tied to that patch if possible.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: linux-2.6.13-mm1/arch/um/drivers/chan_kern.c
===
--- linux-2.6.13-mm1.orig/arch/um/drivers/chan_kern.c   2005-09-01 
15:52:25.0 -0400
+++ linux-2.6.13-mm1/arch/um/drivers/chan_kern.c2005-09-01 
15:52:31.0 -0400
@@ -161,9 +161,6 @@
}
}
 
-   if((tty->flip.flag_buf_ptr == NULL) || 
-  (tty->flip.char_buf_ptr == NULL))
-   return;
tty_insert_flip_char(tty, ch, TTY_NORMAL);
 }
 
@@ -542,8 +539,8 @@
chan = list_entry(ele, struct chan, list);
if(!chan->input || (chan->ops->read == NULL)) continue;
do {
-   if((tty != NULL) && 
-  (tty->flip.count >= TTY_FLIPBUF_SIZE)){
+   if((tty != NULL) &&
+  !tty_buffer_request_room(tty, 1)){
schedule_work(task);
goto out;
}
@@ -572,14 +569,3 @@
  out:
if(tty) tty_flip_buffer_push(tty);
 }
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
 

-
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: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Ion Badulescu]

Hi David,

On Thu, 1 Sep 2005, David S. Miller wrote:


Thanks for the empty posting.  Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org


First of all, thanks for the reply (even to an empty posting :).

The posting wasn't actually empty, it was probably too long (94K according 
to my sent-mail folder) and majordomo truncated it to zero. It has some 
tcpdump snippets, that's what made it so long... unfortunately, they're 
all necessary to understand the nature of the bug. I wasn't sure about 
netdev, that's why I posted it only to linux-kernel and linux-net.


I can provide the full tcpdump out-of-band to interested people, since I 
don't think I can get it past majordomo.


Here is the text of the message without the tcpdump inserts:

---
Hello,

I've been tracking down this bug for some time, and I'm fairly convinced 
at this point that it's a kernel bug.


Under certain conditions, the TCP stack starts shrinking the TCP window 
down to some ridiculously low values (hundreds of bytes, as low as 181) 
and never recovers. The certain conditions I mentioned are not well 
understood at this point, but they include a long-lived connection with a 
very one-sided, fluctuating traffic flowing through it.


So far I've been able to reproduce it on plain-vanilla 2.4.9, 2.4.11.9, 
and 2.4.12.2, as well as on the RHEL3 kernels 2.4.21-20 and 2.4.21-31. The 
hardware is dual Opteron 250, running both 32- and 64-bit SMP kernels 
(seems to make no difference). I've also seen the bug occur on a single 
Athlon XP running 2.6.11.9 UP.


The bug occurs with all sysctl settings at their default values. I've 
tried enabling and disabling pretty much all the tcp-related sysctl's in 
/proc/sys/net/ipv4, to no visible improvement.


Here are a few tcpdump snippets of a TCP connection exhibiting the bug 
(the complete tcpdump is available upon request, but it's very large). 
10.2.20.246 is the data receiver and is the box exhibiting the bug (I'm 
not sure what 10.2.224.182 is running, I don't have access to it). The 
data being sent through is real-time financial data; the session begins by 
catching up (at line speed) to present time, then continues to receive 
real-time data as it is being generated. For what it's worth, we've never 
been seen the bug occur while the session is still catching up (and 
receiving a few large packets at a time); it always seems to happen while 
receiving real-time data (many small packets, variably interspaced).


[I apologize for the amount of tcpdump data, but it's the only way to show 
the bug in action.]


[tcpdump output removed]

The connection is established and the receiver's TCP window quickly ramps 
up to 8192.


[tcpdump output removed]

Shortly thereafter the TCP window increases further to 16534. It remains 
around 16534 for the next 5 minutes or so.


[tcpdump output removed]

A few minutes later it has finally caught up to present time and it starts 
receiving smaller packets containing real-time data. The TCP window is 
still 16534 at this point.


[tcpdump output removed]

This is where things start going bad. The window starts shrinking from 
15340 all the way down to 2355 over the course of 0.3 seconds. Notice the 
many duplicate acks that serve no purpose (there are no lost packets and 
the tcpdump is taken on the receiver so there is no packets/acks crossed 
in flight).


[tcpdump output removed]

Five minutes later the TCP window is still at 2355, having never 
recovered. The window is so small that the available bandwidth for this 
connection is too small to keep up with the real-time data so it is 
falling behind, hence large packets are again being used. The application 
processing the data (Java-based) is mostly idle at this point, and netstat 
shows its recv queue to be empty. There is no apparent reason why the 
kernel shouldn't enlarge the window.


In fact, if I let it continue, it eventually shrinks the window even 
further (by 18:19:29, the time I'm writing this email, it's gone all the 
way down to 1373). As I mentioned earlier, I've seen it go as low as 181.


We are kind of stumped at this point, and it's proving to be a 
show-stopping bug for our purposes, especially over WAN links that have 
higher latency (for obvious reasons). Any kind of assistance would be 
greatly appreciated.


Thanks,
-Ion
-
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 7/12] UML - Move libc-dependent startup and signal code

[Jeff Dike]

From: Gennady Sharapov <[EMAIL PROTECTED]>

The serial UML OS-abstraction layer patch (um/kernel dir).

This moves all systemcalls from process.c file under os-Linux dir
and join process.c and process_kern.c files.

Signed-off-by: Gennady Sharapov <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/include/os.h
===
--- test.orig/arch/um/include/os.h  2005-06-17 15:48:29.0 -0400
+++ test/arch/um/include/os.h   2005-09-01 16:09:41.0 -0400
@@ -153,6 +153,11 @@
 extern int os_file_mode(char *file, struct openflags *mode_out);
 extern int os_lock_file(int fd, int excl);
 
+/* start_up.c */
+extern void os_early_checks(void);
+extern int can_do_skas(void);
+
+/* process.c */
 extern unsigned long os_process_pc(int pid);
 extern int os_process_parent(int pid);
 extern void os_stop_process(int pid);
@@ -161,6 +166,9 @@
 extern void os_usr1_process(int pid);
 extern int os_getpid(void);
 extern int os_getpgrp(void);
+extern void init_new_thread_stack(void *sig_stack, void (*usr1_handler)(int));
+extern void init_new_thread_signals(int altstack);
+extern int run_kernel_thread(int (*fn)(void *), void *arg, void **jmp_ptr);
 
 extern int os_map_memory(void *virt, int fd, unsigned long long off,
 unsigned long len, int r, int w, int x);
@@ -170,6 +178,13 @@
 extern void os_flush_stdout(void);
 extern unsigned long long os_usecs(void);
 
+/* tt.c 
+ * for tt mode only (will be deleted in future...)
+ */
+extern void forward_pending_sigio(int target);
+extern int start_fork_tramp(void *arg, unsigned long temp_stack, 
+   int clone_flags, int (*tramp)(void *));
+
 #endif
 
 /*
Index: test/arch/um/include/user_util.h
===
--- test.orig/arch/um/include/user_util.h   2005-06-17 15:48:29.0 
-0400
+++ test/arch/um/include/user_util.h2005-09-01 16:09:41.0 -0400
@@ -54,8 +54,6 @@
 extern void task_protections(unsigned long address);
 extern int wait_for_stop(int pid, int sig, int cont_type, void *relay);
 extern void *add_signal_handler(int sig, void (*handler)(int));
-extern int start_fork_tramp(void *arg, unsigned long temp_stack, 
-   int clone_flags, int (*tramp)(void *));
 extern int linux_main(int argc, char **argv);
 extern void set_cmdline(char *cmd);
 extern void input_cb(void (*proc)(void *), void *arg, int arg_len);
@@ -64,8 +62,6 @@
 extern int switcheroo(int fd, int prot, void *from, void *to, int size);
 extern void setup_machinename(char *machine_out);
 extern void setup_hostinfo(void);
-extern void init_new_thread_stack(void *sig_stack, void (*usr1_handler)(int));
-extern void init_new_thread_signals(int altstack);
 extern void do_exec(int old_pid, int new_pid);
 extern void tracer_panic(char *msg, ...);
 extern char *get_umid(int only_if_set);
@@ -74,16 +70,12 @@
 extern int attach(int pid);
 extern void kill_child_dead(int pid);
 extern int cont(int pid);
-extern void check_ptrace(void);
 extern void check_sigio(void);
-extern int run_kernel_thread(int (*fn)(void *), void *arg, void **jmp_ptr);
 extern void write_sigio_workaround(void);
 extern void arch_check_bugs(void);
 extern int cpu_feature(char *what, char *buf, int len);
 extern int arch_handle_signal(int sig, union uml_pt_regs *regs);
 extern int arch_fixup(unsigned long address, void *sc_ptr);
-extern void forward_pending_sigio(int target);
-extern int can_do_skas(void);
 extern void arch_init_thread(void);
 extern int setjmp_wrapper(void (*proc)(void *, void *), ...);
 extern int raw(int fd);
Index: test/arch/um/kernel/Makefile
===
--- test.orig/arch/um/kernel/Makefile   2005-09-01 16:04:19.0 -0400
+++ test/arch/um/kernel/Makefile2005-09-01 16:09:41.0 -0400
@@ -8,11 +8,10 @@
 
 obj-y = config.o exec_kern.o exitcode.o \
helper.o init_task.o irq.o irq_user.o ksyms.o main.o mem.o mem_user.o \
-   physmem.o process.o process_kern.o ptrace.o reboot.o resource.o \
-   sigio_user.o sigio_kern.o signal_kern.o signal_user.o smp.o \
-   syscall_kern.o sysrq.o tempfile.o time.o time_kern.o \
-   tlb.o trap_kern.o trap_user.o uaccess_user.o um_arch.o umid.o \
-   user_util.o
+   physmem.o process_kern.o ptrace.o reboot.o resource.o sigio_user.o \
+   sigio_kern.o signal_kern.o signal_user.o smp.o syscall_kern.o sysrq.o \
+   tempfile.o time.o time_kern.o tlb.o trap_kern.o trap_user.o \
+   uaccess_user.o um_arch.o umid.o user_util.o
 
 obj-$(CONFIG_BLK_DEV_INITRD) += initrd.o
 obj-$(CONFIG_GPROF)+= gprof_syms.o
@@ -25,8 +24,8 @@
 
 user-objs-$(CONFIG_TTY_LOG) += tty_log.o
 
-USER_OBJS := $(user-objs-y) config.o helper.o main.o process.o tempfile.o \
-   time.o tty_log.o umid.o user_util.o
+USER_OBJS := $(user-objs-y) config.o helper.o main.o tempfile.o 

Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[David S. Miller]

From: Jesper Juhl <[EMAIL PROTECTED]>
Date: Fri, 2 Sep 2005 00:49:20 +0200

> Hmm, I see plenty of content in the post. Want me to farward you a
> copy off list ?

Please do, I didn't see anything.

It still needs to be reposted to netdev@vger.kernel.org
anyways :)
-
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 10/12] UML - Allow host capability usage to be disabled

[Jeff Dike]

From: Bodo Stroesser <[EMAIL PROTECTED]>

Add new cmdline setups:
  - noprocmm
  - noptracefaultinfo
In case of testing, they can be used to switch off usage of
/proc/mm and PTRACE_FAULTINFO independently.

Signed-off-by: Bodo Stroesser <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/os-Linux/start_up.c
===
--- test.orig/arch/um/os-Linux/start_up.c   2005-09-01 16:42:42.0 
-0400
+++ test/arch/um/os-Linux/start_up.c2005-09-01 16:51:23.0 -0400
@@ -275,6 +275,30 @@
check_ptrace();
 }
 
+static int __init noprocmm_cmd_param(char *str, int* add)
+{
+   proc_mm = 0;
+   return 0;
+}
+
+__uml_setup("noprocmm", noprocmm_cmd_param,
+"noprocmm\n"
+"Turns off usage of /proc/mm, even if host supports it.\n"
+"To support /proc/mm, the host needs to be patched using\n"
+"the current skas3 patch.\n\n");
+
+static int __init noptracefaultinfo_cmd_param(char *str, int* add)
+{
+   ptrace_faultinfo = 0;
+   return 0;
+}
+
+__uml_setup("noptracefaultinfo", noptracefaultinfo_cmd_param,
+"noptracefaultinfo\n"
+"Turns off usage of PTRACE_FAULTINFO, even if host supports\n"
+"it. To support PTRACE_FAULTINFO, the host needs to be patched\n"
+"using the current skas3 patch.\n\n");
+
 #ifdef UML_CONFIG_MODE_SKAS
 static inline void check_skas3_ptrace_support(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: [PATCH] crypto_free_tfm callers no longer need to check for NULL

[Jesper Juhl]

On 9/2/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> 
> Applied, thanks Jesper.
> 
> Can you avoid those "/./" things from showing up in the file paths of
> the patches you post?  They upset the GIT patch application scripts
> and diff verifiers, so I had to edit them out by hand.
> 
No problem, I actually saw those (an unfortunate biproduct of a script
I used to diff the individual files) and told myself that I should
remember to remove them before sending the final patch, but obviously
I forgot.

> Thanks again.
> 
You are most welcome.

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[Jesper Juhl]

On 9/2/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> 
> Thanks for the empty posting.  Please provide the content you
> intended to post, and furthermore please post it to the network
> developer mailing list, netdev@vger.kernel.org
> 
Hmm, I see plenty of content in the post. Want me to farward you a
copy off list ?

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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: [PATCH 2.6.13] IOCHK interface for I/O error handling/detecting (for ia64)

[Brent Casavant]

On Thu, 1 Sep 2005, Hidetoshi Seto wrote:

> Index: linux-2.6.13/include/asm-ia64/io.h
> ===
> --- linux-2.6.13.orig/include/asm-ia64/io.h
> +++ linux-2.6.13/include/asm-ia64/io.h
> @@ -70,6 +70,26 @@ extern unsigned int num_io_spaces;
>  #include 
>  #include 
>  #include 
> +
> +#ifdef CONFIG_IOMAP_CHECK
> +#include 
> +#include 
> +
> +/* ia64 iocookie */
> +typedef struct {
> + struct list_headlist;
> + struct pci_dev  *dev;   /* target device */
> + struct pci_dev  *host;  /* hosting bridge */
> + unsigned long   error;  /* error flag */
> +} iocookie;
> +
> +extern rwlock_t iochk_lock;  /* see arch/ia64/lib/iomap_check.c */
> +
> +/* Enable ia64 iochk - See arch/ia64/lib/iomap_check.c */
> +#define HAVE_ARCH_IOMAP_CHECK
> +
> +#endif /* CONFIG_IOMAP_CHECK  */
> +
>  #include 
> 
>  /*
> @@ -164,14 +184,23 @@ __ia64_mk_io_addr (unsigned long port)
>   * during optimization, which is why we use "volatile" pointers.
>   */
> 
> +#ifdef CONFIG_IOMAP_CHECK
> +
> +extern void ia64_mca_barrier(unsigned long value);
> +
>  static inline unsigned int
>  ___ia64_inb (unsigned long port)
>  {
>   volatile unsigned char *addr = __ia64_mk_io_addr(port);
>   unsigned char ret;
> + unsigned long flags;
> 
> + read_lock_irqsave(_lock,flags);
>   ret = *addr;
>   __ia64_mf_a();
> + ia64_mca_barrier(ret);
> + read_unlock_irqrestore(_lock,flags);
> +
>   return ret;
>  }
> 
> @@ -180,9 +209,14 @@ ___ia64_inw (unsigned long port)
>  {
>   volatile unsigned short *addr = __ia64_mk_io_addr(port);
>   unsigned short ret;
> + unsigned long flags;
> 
> + read_lock_irqsave(_lock,flags);
>   ret = *addr;
>   __ia64_mf_a();
> + ia64_mca_barrier(ret);
> + read_unlock_irqrestore(_lock,flags);
> +
>   return ret;
>  }
> 
> @@ -191,12 +225,54 @@ ___ia64_inl (unsigned long port)
>  {
>   volatile unsigned int *addr = __ia64_mk_io_addr(port);
>   unsigned int ret;
> + unsigned long flags;
> 
> + read_lock_irqsave(_lock,flags);
>   ret = *addr;
>   __ia64_mf_a();
> + ia64_mca_barrier(ret);
> + read_unlock_irqrestore(_lock,flags);
> +
>   return ret;
>  }

I am extremely concerned about the performance implications of this
implementation.  These changes have several deleterious effects on I/O
performance.

The first is serialization of all I/O reads and writes.  This will
be a severe problem on systems with large numbers of PCI buses, the
very type of system that stands the most to gain in reliability from
these efforts.  At a minimum any locking should be done on a per-bus
basis.

The second is the raw performance penalty from acquiring and dropping
a lock with every read and write.  This will be a substantial amount
of activity for any I/O-intensive system, heck even for moderate I/O
levels.

The third is lock contention for this single lock -- I would fully expect
many dozens of processors to be performing I/O at any given time on
systems of interest, causing this to be a heavily contended lock.
This will be even more severe on NUMA systems, as the lock cacheline
bounces across the memory fabric.  A per-bus lock would again be much
more appropriate.

The final problem is that these performance penalties are paid even
by drivers which are not IOCHK aware, which for the time being is
all of them.  A reasonable solution must pay these penalties only
for drivers which are IOCHK aware.  Reinstating the readX_check()
interface is the obvious solution here.  It's simply too heavy a
performance burden to pay when almost no drivers currently benefit
from it.

Otherwise, I also wonder if you have any plans to handle similar
errors experienced under device-initiated DMA, or asynchronous I/O.
It's not clear that there's sufficient infrastructure in the current
patches to adequately handle those situations.

Thank you,
Brent Casavant

-- 
Brent Casavant  If you had nothing to fear,
[EMAIL PROTECTED]how then could you be brave?
Silicon Graphics, Inc.-- Queen Dama, Source Wars
-
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] 8250_kgdb driver reworked

[Tom Rini]

On Thu, Sep 01, 2005 at 11:44:44PM +0100, Alan Cox wrote:
> On Iau, 2005-09-01 at 14:47 -0700, Tom Rini wrote:
> > > > +* If  there is some other CPU in KGDB then this is a
> > > > +* spurious interrupt. so return without even checking a byte
> > > > +*/
> > > > +   if (atomic_read(_active))
> > > > +   return IRQ_NONE;
> > > > +
> > > 
> > > Shared IRQ -> hung box. 
> > 
> > Can you elaborate a bit more please?  When we're actually in KGDB and
> > working on stuff we're polling so it's really just the
> > GDB-is-interrupting case.
> 
> If the IRQ source is level triggered and the device is the cause then as
> soon as you exit the IRQ handler, you'll be called again and again and
> again until the IRQ is cleared or 10,000 tries or so occur when the IRQ
> is disabled

But in the shared IRQ and other source is the other uart still
registered to the real 8250 driver, we'd luck out.  I know this has been
tested on a shared serial irq box, so it's not immediate and always
death at least...

> Does this only occur if there is a stray IRQ under delivery as kgdb is
> entered ? (ie you do something like

So digging back in CVS it seems this was added to fix a spurious
interrupt that occured on an (probably) an x86_64 box when NMI support
didn't work correctly.  I think it's safe enough to just drop this.

-- 
Tom Rini
http://gate.crashing.org/~trini/
-
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: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels

[David S. Miller]

Thanks for the empty posting.  Please provide the content you
intended to post, and furthermore please post it to the network
developer mailing list, netdev@vger.kernel.org

Thanks.
-
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] crypto_free_tfm callers no longer need to check for NULL

[David S. Miller]

Applied, thanks Jesper.

Can you avoid those "/./" things from showing up in the file paths of
the patches you post?  They upset the GIT patch application scripts
and diff verifiers, so I had to edit them out by hand.

Thanks again.
-
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 11/12] UML - Fix advanced sysemu check

[Jeff Dike]

From: Bodo Stroesser <[EMAIL PROTECTED]>

cleanup and fix the check for advanced sysemu
(PTRACE_SYSEMU_SINGLESTEP option)

Signed-off-by: Bodo Stroesser <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/os-Linux/start_up.c
===
--- test.orig/arch/um/os-Linux/start_up.c   2005-09-01 17:19:47.0 
-0400
+++ test/arch/um/os-Linux/start_up.c2005-09-01 17:21:35.0 -0400
@@ -161,7 +161,7 @@
 static void __init check_sysemu(void)
 {
void *stack;
-   int pid, syscall, n, status, count=0;
+   int pid, n, status, count=0;
 
printk("Checking syscall emulation patch for ptrace...");
sysemu_supported = 0;
@@ -192,6 +192,12 @@
 
printk("Checking advanced syscall emulation patch for ptrace...");
pid = start_ptraced_child();
+
+   if(ptrace(PTRACE_OLDSETOPTIONS, pid, 0, 
+ (void *) PTRACE_O_TRACESYSGOOD) < 0)
+   panic("check_ptrace: PTRACE_OLDSETOPTIONS failed, errno = %d",
+ errno);
+
while(1){
count++;
if(ptrace(PTRACE_SYSEMU_SINGLESTEP, pid, 0, 0) < 0)
@@ -199,15 +205,10 @@
CATCH_EINTR(n = waitpid(pid, , WUNTRACED));
if(n < 0)
panic("check_ptrace : wait failed, errno = %d", errno);
-   if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
-   panic("check_ptrace : expected (SIGTRAP|SYSCALL_TRAP), "
- "got status = %d", status);
-
-   syscall = ptrace(PTRACE_PEEKUSR, pid, PT_SYSCALL_NR_OFFSET,
-0);
-   if(syscall == __NR_getpid){
+   if(WIFSTOPPED(status) && (WSTOPSIG(status) == (SIGTRAP|0x80))){
if (!count)
-   panic("check_ptrace : SYSEMU_SINGLESTEP doesn't 
singlestep");
+   panic("check_ptrace : SYSEMU_SINGLESTEP "
+ "doesn't singlestep");
n = ptrace(PTRACE_POKEUSR, pid, PT_SYSCALL_RET_OFFSET,
   os_getpid());
if(n < 0)
@@ -215,6 +216,11 @@
  "call return, errno = %d", errno);
break;
}
+   else if(WIFSTOPPED(status) && (WSTOPSIG(status) == SIGTRAP))
+   count++;
+   else
+   panic("check_ptrace : expected SIGTRAP or "
+ "(SIGTRAP|0x80), got status = %d", status);
}
if (stop_ptraced_child(pid, stack, 0, 0) < 0)
goto fail_stopped;
@@ -250,8 +256,8 @@
CATCH_EINTR(n = waitpid(pid, , WUNTRACED));
if(n < 0)
panic("check_ptrace : wait failed, errno = %d", errno);
-   if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP + 0x80))
-   panic("check_ptrace : expected SIGTRAP + 0x80, "
+   if(!WIFSTOPPED(status) || (WSTOPSIG(status) != (SIGTRAP|0x80)))
+   panic("check_ptrace : expected (SIGTRAP|0x80), "
  "got status = %d", status);

syscall = ptrace(PTRACE_PEEKUSR, pid, PT_SYSCALL_NR_OFFSET,

-
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 9/12] UML - skas0 stubs now check system call return values

[Jeff Dike]

From: Bodo Stroesser <[EMAIL PROTECTED]>

Change syscall-stub's data to include a "expected retval".
Stub now checks syscalls retval and aborts execution of
syscall list, if retval != expected retval.
run_syscall_stub prints the data of the failed syscall,
using the data pointer and retval written by the stub
to the beginning of the stack.
one_syscall_stub is removed, to simplify code, because
only some instructions are saved by one_syscall_stub, no
host-syscall.
Using the stub with additional data (modify_ldt via stub)
is prepared also.

Signed-off-by: Bodo Stroesser <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/include/tlb.h
===
--- test.orig/arch/um/include/tlb.h 2005-09-01 16:32:51.0 -0400
+++ test/arch/um/include/tlb.h  2005-09-01 16:33:07.0 -0400
@@ -38,9 +38,9 @@
 extern void force_flush_all(void);
 extern void fix_range_common(struct mm_struct *mm, unsigned long start_addr,
  unsigned long end_addr, int force,
-void *(*do_ops)(union mm_context *,
-struct host_vm_op *, int, int,
-void *));
+int (*do_ops)(union mm_context *, 
+  struct host_vm_op *, int, int,
+  void **));
 extern int flush_tlb_kernel_range_common(unsigned long start,
 unsigned long end);
 
Index: test/arch/um/kernel/skas/include/skas.h
===
--- test.orig/arch/um/kernel/skas/include/skas.h2005-09-01 
16:33:07.0 -0400
+++ test/arch/um/kernel/skas/include/skas.h 2005-09-01 16:33:07.0 
-0400
@@ -24,14 +24,14 @@
 extern void remove_sigstack(void);
 extern void new_thread_handler(int sig);
 extern void handle_syscall(union uml_pt_regs *regs);
-extern void *map(struct mm_id * mm_idp, unsigned long virt,
-unsigned long len, int r, int w, int x, int phys_fd,
-unsigned long long offset, int done, void *data);
-extern void *unmap(struct mm_id * mm_idp, void *addr,
-  unsigned long len, int done, void *data);
-extern void *protect(struct mm_id * mm_idp, unsigned long addr,
-unsigned long len, int r, int w, int x, int done,
-void *data);
+extern int map(struct mm_id * mm_idp, unsigned long virt,
+  unsigned long len, int r, int w, int x, int phys_fd, 
+  unsigned long long offset, int done, void **data);
+extern int unmap(struct mm_id * mm_idp, void *addr, unsigned long len,
+int done, void **data);
+extern int protect(struct mm_id * mm_idp, unsigned long addr,
+  unsigned long len, int r, int w, int x, int done, 
+  void **data);
 extern void user_signal(int sig, union uml_pt_regs *regs, int pid);
 extern int new_mm(int from, unsigned long stack);
 extern int start_userspace(unsigned long stub_stack);
@@ -39,16 +39,11 @@
 extern void get_skas_faultinfo(int pid, struct faultinfo * fi);
 extern long execute_syscall_skas(void *r);
 extern unsigned long current_stub_stack(void);
+extern long run_syscall_stub(struct mm_id * mm_idp,
+ int syscall, unsigned long *args, long expected,
+ void **addr, int done);
+extern long syscall_stub_data(struct mm_id * mm_idp,
+  unsigned long *data, int data_count,
+  void **addr, void **stub_addr);
 
 #endif
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: "linux"
- * End:
- */
Index: test/arch/um/kernel/skas/mem_user.c
===
--- test.orig/arch/um/kernel/skas/mem_user.c2005-09-01 16:32:51.0 
-0400
+++ test/arch/um/kernel/skas/mem_user.c 2005-09-01 16:43:18.0 -0400
@@ -5,13 +5,14 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include "mem_user.h"
 #include "mem.h"
-#include "mm_id.h"
+#include "skas.h"
 #include "user.h"
 #include "os.h"
 #include "proc_mm.h"
@@ -23,56 +24,99 @@
 #include "uml-config.h"
 #include "sysdep/ptrace.h"
 #include "sysdep/stub.h"
-#include "skas.h"
 
-extern unsigned long syscall_stub, batch_syscall_stub, __syscall_stub_start;
+extern unsigned long batch_syscall_stub, __syscall_stub_start;
 
 extern void wait_stub_done(int pid, int sig, char * fname);
 
-int single_count = 0;
+static inline unsigned long 

Re: [PATCH] DECnet Tidy

[David S. Miller]

From: Patrick Caulfield <[EMAIL PROTECTED]>
Date: Tue, 30 Aug 2005 09:47:36 +0100

> Patch from Steve which I've vetted and tested:
> 
> "This patch is really intended has a move towards fixing the sendmsg/recvmsg  
>
>  functions in various ways so that we will finally have working nagle. Also   
>
>  reduces code duplication. "
> 
> Signed-off-by: Patrick Caulfield <[EMAIL PROTECTED]>

Applied, thanks.
-
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.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

More (non-functional) style modifications since the version 0.11
driver I sent out earlier today.  Removed most parens around return
value, corrected indentation of labels, improved comment for flush,
removed naked return, and cleanup ata_qc_from_tag() call block.

This is my libata compatible low level driver for the Marvell SATA
family.  Currently it successfully runs in PIO mode on a 6081 chip.
EDMA support is in the works and should be done shortly.  Review,
testing (especially on other flavors of Marvell), comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>


Index: linux-2.6.13/drivers/scsi/sata_mv.c
===
--- /dev/null
+++ linux-2.6.13/drivers/scsi/sata_mv.c
@@ -0,0 +1,827 @@
+/*
+ * sata_mv.c - Marvell SATA support
+ *
+ * Copyright 2005: EMC Corporation, all rights reserved. 
+ *
+ * Please ALWAYS copy linux-ide@vger.kernel.org on emails.
+ *
+ * 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; version 2 of the License.
+ *
+ * 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
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "scsi.h"
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "sata_mv"
+#define DRV_VERSION"0.12"
+
+enum {
+   /* BAR's are enumerated in terms of pci_resource_start() terms */
+   MV_PRIMARY_BAR  = 0,/* offset 0x10: memory space */
+   MV_IO_BAR   = 2,/* offset 0x18: IO space */
+   MV_MISC_BAR = 3,/* offset 0x1c: FLASH, NVRAM, SRAM */
+
+   MV_MAJOR_REG_AREA_SZ= 0x1,  /* 64KB */
+   MV_MINOR_REG_AREA_SZ= 0x2000,   /* 8KB */
+
+   MV_PCI_REG_BASE = 0,
+   MV_IRQ_COAL_REG_BASE= 0x18000,  /* 6xxx part only */
+   MV_SATAHC0_REG_BASE = 0x2,
+
+   MV_PCI_REG_SZ   = MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_REG_SZ= MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_ARBTR_REG_SZ  = MV_MINOR_REG_AREA_SZ, /* arbiter */
+   MV_PORT_REG_SZ  = MV_MINOR_REG_AREA_SZ,
+
+   MV_Q_CT = 32,
+   MV_CRQB_SZ  = 32,
+   MV_CRPB_SZ  = 8,
+
+   MV_DMA_BOUNDARY = 0xU,
+   SATAHC_MASK = (~(MV_SATAHC_REG_SZ - 1)),
+
+   MV_PORTS_PER_HC = 4,
+   /* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
+   MV_PORT_HC_SHIFT= 2,
+   /* == (port % MV_PORTS_PER_HC) to determine port from 0-7 port */
+   MV_PORT_MASK= 3,
+
+   /* Host Flags */
+   MV_FLAG_DUAL_HC = (1 << 30),  /* two SATA Host Controllers */
+   MV_FLAG_IRQ_COALESCE= (1 << 29),  /* IRQ coalescing capability */
+   MV_FLAG_BDMA= (1 << 28),  /* Basic DMA */
+
+   chip_504x   = 0,
+   chip_508x   = 1,
+   chip_604x   = 2,
+   chip_608x   = 3,
+
+   /* PCI interface registers */
+
+   PCI_MAIN_CMD_STS_OFS= 0xd30,
+   STOP_PCI_MASTER = (1 << 2),
+   PCI_MASTER_EMPTY= (1 << 3),
+   GLOB_SFT_RST= (1 << 4),
+
+   PCI_IRQ_CAUSE_OFS   = 0x1d58,
+   PCI_IRQ_MASK_OFS= 0x1d5c,
+   PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+
+   HC_MAIN_IRQ_CAUSE_OFS   = 0x1d60,
+   HC_MAIN_IRQ_MASK_OFS= 0x1d64,
+   PORT0_ERR   = (1 << 0), /* shift by port # */
+   PORT0_DONE  = (1 << 1), /* shift by port # */
+   HC0_IRQ_PEND= 0x1ff,/* bits 0-8 = HC0's ports */
+   HC_SHIFT= 9,/* bits 9-17 = HC1's ports */
+   PCI_ERR = (1 << 18),
+   TRAN_LO_DONE= (1 << 19),/* 6xxx: IRQ coalescing */
+   TRAN_HI_DONE= (1 << 20),/* 6xxx: IRQ coalescing */
+   PORTS_0_7_COAL_DONE = (1 << 21),/* 6xxx: IRQ coalescing */
+   GPIO_INT= (1 << 22),
+   SELF_INT= (1 << 23),
+   TWSI_INT= (1 << 24),
+   HC_MAIN_RSVD= (0x7f << 25), /* bits 31-25 */
+   HC_MAIN_MASKED_IRQS = (TRAN_LO_DONE | TRAN_HI_DONE | 
+  PORTS_0_7_COAL_DONE | GPIO_INT | TWSI_INT |
+  HC_MAIN_RSVD),
+
+   /* SATAHC registers 

[PATCH 6/12] UML - Add host AIO support to block driver

[Jeff Dike]

This adds AIO support to the ubd driver.
The driver breaks a struct request into IO requests to the host,
based on the hardware segments in the request and on any COW blocks
covered by the request.
The ubd IO thread is gone, since there is now an equivalent thread in the
AIO module.
There is provision for multiple outstanding requests now.  Requests aren't
retired until all pieces of it have been completed.  The AIO requests have
a shared count, which is decremented as IO operations come in until
it reaches 0.  This can be possibly moved to the request struct -
haven't looked at this yet.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>

Index: test/arch/um/drivers/Makefile
===
--- test.orig/arch/um/drivers/Makefile  2005-09-01 16:02:46.0 -0400
+++ test/arch/um/drivers/Makefile   2005-09-01 16:05:06.0 -0400
@@ -13,7 +13,7 @@
 net-objs := net_kern.o net_user.o
 mconsole-objs := mconsole_kern.o mconsole_user.o
 hostaudio-objs := hostaudio_kern.o
-ubd-objs := ubd_kern.o ubd_user.o
+ubd-objs := ubd_kern.o
 port-objs := port_kern.o port_user.o
 harddog-objs := harddog_kern.o harddog_user.o
 
Index: test/arch/um/drivers/ubd_kern.c
===
--- test.orig/arch/um/drivers/ubd_kern.c2005-09-01 16:03:16.0 
-0400
+++ test/arch/um/drivers/ubd_kern.c 2005-09-01 16:05:06.0 -0400
@@ -35,6 +35,7 @@
 #include "linux/blkpg.h"
 #include "linux/genhd.h"
 #include "linux/spinlock.h"
+#include "asm/atomic.h"
 #include "asm/segment.h"
 #include "asm/uaccess.h"
 #include "asm/irq.h"
@@ -53,20 +54,21 @@
 #include "mem.h"
 #include "mem_kern.h"
 #include "cow.h"
+#include "aio.h"
 
 enum ubd_req { UBD_READ, UBD_WRITE };
 
 struct io_thread_req {
-   enum ubd_req op;
+   enum aio_type op;
int fds[2];
unsigned long offsets[2];
unsigned long long offset;
unsigned long length;
char *buffer;
int sectorsize;
-   unsigned long sector_mask;
-   unsigned long long cow_offset;
-   unsigned long bitmap_words[2];
+   int bitmap_offset;
+   long bitmap_start;
+   long bitmap_end;
int error;
 };
 
@@ -80,28 +82,31 @@
   unsigned long *bitmap_len_out,
   int *data_offset_out);
 extern int read_cow_bitmap(int fd, void *buf, int offset, int len);
-extern void do_io(struct io_thread_req *req);
+extern void do_io(struct io_thread_req *req, struct request *r, 
+ unsigned long *bitmap);
 
-static inline int ubd_test_bit(__u64 bit, unsigned char *data)
+static inline int ubd_test_bit(__u64 bit, void *data)
 {
+   unsigned char *buffer = data;
__u64 n;
int bits, off;
 
-   bits = sizeof(data[0]) * 8;
+   bits = sizeof(buffer[0]) * 8;
n = bit / bits;
off = bit % bits;
-   return((data[n] & (1 << off)) != 0);
+   return((buffer[n] & (1 << off)) != 0);
 }
 
-static inline void ubd_set_bit(__u64 bit, unsigned char *data)
+static inline void ubd_set_bit(__u64 bit, void *data)
 {
+   unsigned char *buffer = data;
__u64 n;
int bits, off;
 
-   bits = sizeof(data[0]) * 8;
+   bits = sizeof(buffer[0]) * 8;
n = bit / bits;
off = bit % bits;
-   data[n] |= (1 << off);
+   buffer[n] |= (1 << off);
 }
 /*End stuff from ubd_user.h*/
 
@@ -110,8 +115,6 @@
 static DEFINE_SPINLOCK(ubd_io_lock);
 static DEFINE_SPINLOCK(ubd_lock);
 
-static void (*do_ubd)(void);
-
 static int ubd_open(struct inode * inode, struct file * filp);
 static int ubd_release(struct inode * inode, struct file * file);
 static int ubd_ioctl(struct inode * inode, struct file * file,
@@ -158,6 +161,8 @@
 int data_offset;
 };
 
+#define MAX_SG 64
+
 struct ubd {
char *file;
int count;
@@ -168,6 +173,7 @@
int no_cow;
struct cow cow;
struct platform_device pdev;
+struct scatterlist sg[MAX_SG];
 };
 
 #define DEFAULT_COW { \
@@ -460,81 +466,114 @@
 );
 
 static void do_ubd_request(request_queue_t * q);
-
-/* Only changed by ubd_init, which is an initcall. */
-int thread_fd = -1;
+static int in_ubd;
 
 /* Changed by ubd_handler, which is serialized because interrupts only
  * happen on CPU 0.
  */
 int intr_count = 0;
 
-/* call ubd_finish if you need to serialize */
-static void __ubd_finish(struct request *req, int error)
+static void ubd_end_request(struct request *req, int bytes, int uptodate)
 {
-   int nsect;
-
-   if(error){
-   end_request(req, 0);
-   return;
+   if (!end_that_request_first(req, uptodate, bytes >> 9)) {
+   add_disk_randomness(req->rq_disk);
+   end_that_request_last(req);
}
-   nsect = req->current_nr_sectors;
-   req->sector += nsect;
-   req->buffer += nsect << 9;
-   req->errors = 0;
-   req->nr_sectors -= nsect;
-  

[PATCH 4/12] UML - build cleanups

[Jeff Dike]

From: Al Viro <[EMAIL PROTECTED]>

Added missing include list to uml AFLAGS
Killed magic for stubs. [So] - it was needed only because of messed AFLAGS
Switched segv_stubs.c to kernel CFLAGS sans profile, instead of user ones
Killed STUBS_CFLAGS - it's not needed and the only remaining use had been
gratitious - it only polluted CFLAGS

Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>


Index: test/arch/um/Makefile-i386
===
--- test.orig/arch/um/Makefile-i386 2005-09-01 16:03:16.0 -0400
+++ test/arch/um/Makefile-i386  2005-09-01 16:04:30.0 -0400
@@ -27,8 +27,7 @@
 endif
 endif
 
-CFLAGS += -U__$(SUBARCH)__ -U$(SUBARCH) $(STUB_CFLAGS) \
- -Iinclude/asm-i386/mach-default \
+CFLAGS += -U__$(SUBARCH)__ -U$(SUBARCH) -Iinclude/asm-i386/mach-default \
   $(if $(KBUILD_SRC),-Iinclude2/asm-i386/mach-default 
-I$(srctree)/include/asm-i386/mach-default)
 
 ifneq ($(CONFIG_GPROF),y)
Index: test/arch/um/Makefile-x86_64
===
--- test.orig/arch/um/Makefile-x86_64   2005-09-01 16:02:46.0 -0400
+++ test/arch/um/Makefile-x86_642005-09-01 16:04:30.0 -0400
@@ -6,7 +6,7 @@
 
 #We #undef __x86_64__ for kernelspace, not for userspace where
 #it's needed for headers to work!
-CFLAGS += -U__$(SUBARCH)__ -fno-builtin $(STUB_CFLAGS)
+CFLAGS += -U__$(SUBARCH)__ -fno-builtin
 USER_CFLAGS += -fno-builtin
 
 ELF_ARCH := i386:x86-64
Index: test/arch/um/sys-i386/Makefile
===
--- test.orig/arch/um/sys-i386/Makefile 2005-09-01 16:03:16.0 -0400
+++ test/arch/um/sys-i386/Makefile  2005-09-01 16:04:30.0 -0400
@@ -16,11 +16,7 @@
 highmem.c-dir = mm
 module.c-dir = kernel
 
-STUB_CFLAGS = -Wp,-MD,$(depfile) $(call unprofile,$(USER_CFLAGS))
-
-# _cflags works with kernel files, not with userspace ones, but c_flags does,
-# why ask why?
-$(obj)/stub_segv.o : c_flags = $(STUB_CFLAGS)
+$(obj)/stub_segv.o : _c_flags = $(call unprofile,$(CFLAGS))
 
 subdir- := util
 
Index: test/arch/um/sys-i386/stub_segv.c
===
--- test.orig/arch/um/sys-i386/stub_segv.c  2005-09-01 16:02:46.0 
-0400
+++ test/arch/um/sys-i386/stub_segv.c   2005-09-01 16:04:30.0 -0400
@@ -3,8 +3,7 @@
  * Licensed under the GPL
  */
 
-#include 
-#include 
+#include 
 #include 
 #include "uml-config.h"
 #include "sysdep/sigcontext.h"
Index: test/arch/um/sys-x86_64/Makefile
===
--- test.orig/arch/um/sys-x86_64/Makefile   2005-09-01 16:04:05.0 
-0400
+++ test/arch/um/sys-x86_64/Makefile2005-09-01 16:04:30.0 -0400
@@ -27,11 +27,7 @@
 thunk.S-dir = lib
 module.c-dir = kernel
 
-STUB_CFLAGS = -Wp,-MD,$(depfile) $(call unprofile,$(USER_CFLAGS))
-
-# _cflags works with kernel files, not with userspace ones, but c_flags does,
-# why ask why?
-$(obj)/stub_segv.o : c_flags = $(STUB_CFLAGS)
+$(obj)/stub_segv.o: _c_flags = $(call unprofile,$(CFLAGS))
 
 subdir- := util
 
Index: test/arch/um/sys-x86_64/stub_segv.c
===
--- test.orig/arch/um/sys-x86_64/stub_segv.c2005-09-01 16:02:46.0 
-0400
+++ test/arch/um/sys-x86_64/stub_segv.c 2005-09-01 16:04:30.0 -0400
@@ -3,9 +3,10 @@
  * Licensed under the GPL
  */
 
-#include 
+#include 
 #include 
 #include 
+#include 
 #include "uml-config.h"
 #include "sysdep/sigcontext.h"
 #include "sysdep/faultinfo.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/

2.6.13-mm1 compiling error

[Guochun Shi]

Hi, I tried to compile 2.6.13-mm1, got some error:

  CC [M]  drivers/isdn/i4l/isdn_tty.o
drivers/isdn/i4l/isdn_tty.c: In function `isdn_tty_try_read':
drivers/isdn/i4l/isdn_tty.c:71: error: structure has no member named `flip'
drivers/isdn/i4l/isdn_tty.c:86: error: structure has no member named `flip'
drivers/isdn/i4l/isdn_tty.c:86: error: structure has no member named `flip'
drivers/isdn/i4l/isdn_tty.c:88: error: structure has no member named `flip'


-Guochun

-
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/