Re: [PATCH] x86_64: Fix apicid versus cpu# confusion.

[yhlu]

So boot_cpu_id is apic id of BSP.

Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.

YH

On 8/11/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ok being impatient not wanting this tiny bug to be forgotten for
> 2.6.13.  Linus please apply this micro patch.
> 
> > >  static void __cpuinit tsc_sync_wait(void)
> > >  {
> > > if (notscsync || !cpu_has_tsc)
> > > return;
> > > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> > > -   boot_cpu_id);
> > > -   sync_tsc();
> > > +   sync_tsc(boot_cpu_id);
> >
> > I actually found a bug in this today. This should be sync_tsc(0), not
> > sync_tsc(boot_cpu_id)
> > Can you just fix it in your tree or should I submit a new patch?
> >
> > -Andi
> 
> Oops.  I knew I didn't have the physical versus logical cpu identifiers right
> when I generated that patch.  It's not nearly as bad as I feared at the time
> though.
> 
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
> 
>  arch/x86_64/kernel/smpboot.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 5192895f71c7eff7e1335cd9d6a775dda2bb5d52
> diff --git a/arch/x86_64/kernel/smpboot.c b/arch/x86_64/kernel/smpboot.c
> --- a/arch/x86_64/kernel/smpboot.c
> +++ b/arch/x86_64/kernel/smpboot.c
> @@ -334,7 +334,7 @@ static void __cpuinit tsc_sync_wait(void
>  {
> if (notscsync || !cpu_has_tsc)
> return;
> -   sync_tsc(boot_cpu_id);
> +   sync_tsc(0);
>  }
> 
>  static __init int notscsync_setup(char *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/
>
-
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: SATA status report updated

[Jeff Garzik]

Rob van Nieuwkerk wrote:

On Fri, 12 Aug 2005 01:09:12 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

Hi Jeff,


Things in SATA-land have been moving along recently, so I updated the 
software status report:


http://linux.yyz.us/sata/software-status.html



Is any progress made on SMART support ?
I've been reading "SMART support will be integrated very soon"
for a very long time now .. :-)


True enough :/

It's been feature-complete for a while, but the reports from testers in 
the field have made me too nervous to push it into the upstream kernel.


I might push it upstream, but disable it by default, which would allow 
for a wider test audience.


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: Soft lockup in e100 driver ?

[Jesse Brandeburg]

On 8/11/05, Stephen D. Williams <[EMAIL PROTECTED]> wrote:
> The chipset is an Intel 8x0 something.  Unfortunately, there is a
> heatsink semi-permanently installed over everything.  Is there a /proc
> pseudofile that will give me good identifying chipset info to report here?

you can show the chipset details with lspci
lspci -n will show device IDs and revision ids

interesting failure case on the e100, I haven't a clue whats going on.

netdev @ vger might be a good place to continue the discussion abut e100 issues.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA status report updated

[Rob van Nieuwkerk]

On Fri, 12 Aug 2005 01:09:12 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

Hi Jeff,

> Things in SATA-land have been moving along recently, so I updated the 
> software status report:
> 
>   http://linux.yyz.us/sata/software-status.html

Is any progress made on SMART support ?
I've been reading "SMART support will be integrated very soon"
for a very long time now .. :-)

> Thanks to all the hard-working SATA contributors!

Yup, thanks to you & them.  SATA has been working perfect in my system
since I started using it 10 months ago !

greetings,
Rob van Nieuwkerk
-
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: Need help in understanding x86 syscall

[Coywolf Qi Hunt]

On 8/12/05, Jeff Carr <[EMAIL PROTECTED]> wrote:
> On 08/11/2005 10:18 AM, Steven Rostedt wrote:
> 
> > It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own
> > customizations.  But I never touched the sysentry stuff and with a few
> > printks I see it is being initialized.
> >
> >>Also glibc support.
> >
> > I'm using Debian unstable with a recent (last week) update.
> >
> > -- Steve
> 
> But are you using libc6-i686? That enables NPTL. Perhaps the behavior
> difference is there? I'm surprised int 80 doesn't really cause an
> interrupt; it doesn't jump to the appropriate place in the x86 vector
> table? Interesting.
> 
> Jeff
> 
> 
> [EMAIL PROTECTED]:~# dpkg -s libc6-i686
> ...
>  This set of libraries is optimized for i686 machines, and will only be
>  used if you are running a 2.6 kernel on an i686 class CPU (check the
>  output of `uname -m').  This includes Pentium Pro, Pentium II/III/IV,
>  Celeron CPU's and similar class CPU's (including clones such as AMD
>  Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezla).
>  .
>  This package includes support for NPTL.
>  .

Even with libc6-i686 installed, I can't see sysenter got used.
libc6-i686 has /lib/tls/i686/cmov/libc.so.6, not the one
/lib/libc-2.3.5.so.

mozilla gets: Illegal instruction

I've added ud2 in both entry.S and vsyscall-sysenter.S.

Any ideas?

-- 
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
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/

SATA status report updated

[Jeff Garzik]

Things in SATA-land have been moving along recently, so I updated the 
software status report:


http://linux.yyz.us/sata/software-status.html

Although I have not updated it in several weeks, folks may wish to refer 
to the hardware status report as well:


http://linux.yyz.us/sata/sata-status.html

Thanks to all the hard-working SATA contributors!

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: Need help in understanding x86 syscall

[Jeff Carr]

On 08/11/2005 10:18 AM, Steven Rostedt wrote:

> It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own
> customizations.  But I never touched the sysentry stuff and with a few
> printks I see it is being initialized.
> 
>>Also glibc support.
> 
> I'm using Debian unstable with a recent (last week) update.
> 
> -- Steve

But are you using libc6-i686? That enables NPTL. Perhaps the behavior
difference is there? I'm surprised int 80 doesn't really cause an
interrupt; it doesn't jump to the appropriate place in the x86 vector
table? Interesting.

Jeff


[EMAIL PROTECTED]:~# dpkg -s libc6-i686
...
 This set of libraries is optimized for i686 machines, and will only be
 used if you are running a 2.6 kernel on an i686 class CPU (check the
 output of `uname -m').  This includes Pentium Pro, Pentium II/III/IV,
 Celeron CPU's and similar class CPU's (including clones such as AMD
 Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezla).
 .
 This package includes support for NPTL.
 .
-
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 5/7] radix-tree: lockless readside

[Nick Piggin]

On Thu, 2005-08-11 at 18:37 -0700, Paul E. McKenney wrote:
> On Thu, Aug 11, 2005 at 10:25:47PM +1000, Nick Piggin wrote:
> > 5/7
> > 
> > -- 
> > SUSE Labs, Novell Inc.
> > 
> 
> > Make radix tree lookups safe to be performed without locks.
> > Readers are protected against nodes being deleted by using RCU
> > based freeing. Readers are protected against new node insertion
> > by using memory barriers to ensure the node itself will be
> > properly written before it is visible in the radix tree.
> > 
> > Also introduce a lockfree gang_lookup_slot which will be used
> > by a future patch.
> 
> Interesting approach!  Don't claim to fully understand it, but
> see below (search for empty lines).  In the meantime, some questions:
> 

Basically, the main idea is this:

find_get_page (the current, locked version) will take the tree_lock,
elevate the refcount of the page currently in pagecache, and drop
the tree_lock.

tree_lock is used to a) ensure consistency of the radix tree, and
b) "pin" the page until we are able to take a reference to it.

After find_get_page returns the page with elevated refcount, it
has released the tree_lock, so there is no other atomicity /
serialisation provided other than the above 2 functions.

* Assuming my RCU'ed radix-tree is correct, that takes care of a.

* Now, we look up a 'struct page' that has existed in the pagecache
  at *some* point in time (ie. dereference the pagep pointer).

* Then, take a reference on that struct page, regardless of whether
  or not it is *now* in pagecache. This act of taking a reference
  is also a memory barrier.

* Now we can again check if the page existed in pagecache _after_
  taking that reference. If yes, we have a reference to the page
  we want.

* If it is no longer in pagecache, we assume it is the wrong page.
  Even if there is a new page in that part of the pagecache we can
  return NULL, because the pagecache would have had to be NULL at
  *some* point between the 2 times we load the pagep pointer.

With the above, we can meet the same requirements of the current
find_get_page. Which basically are:

x) If the page was ever[1] in pagecache, it may be returned
y) If the pagecache was ever[2] empty, NULL may be returned

[1], [2] - in accordance with the high level serialisation
schema, of course. The main point is that the tree_lock in
find_get_page can be taken at any arbitrary time and thus
doesn't provide anything past x and y.

Similar arguments for find_lock_page and find_get_pages, etc.


Anyway, that's the high level idea. All the rest of the machinery
is geared to handle the case where we have taken a reference to
the page after it has been removed from pagecache or used for
something else. This is admittedly fairly complex, but don't get
too hung up about it when getting an overview of it is supposed
to work.

-- 
SUSE Labs, Novell Inc.



Send instant messages to your online friends http://au.messenger.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/

[PATCH] x86_64: Fix apicid versus cpu# confusion.

[Eric W. Biederman]

Ok being impatient not wanting this tiny bug to be forgotten for
2.6.13.  Linus please apply this micro patch.

> >  static void __cpuinit tsc_sync_wait(void)
> >  {
> > if (notscsync || !cpu_has_tsc)
> > return;
> > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> > -   boot_cpu_id);
> > -   sync_tsc();
> > +   sync_tsc(boot_cpu_id);
>
> I actually found a bug in this today. This should be sync_tsc(0), not
> sync_tsc(boot_cpu_id)
> Can you just fix it in your tree or should I submit a new patch?
>
> -Andi

Oops.  I knew I didn't have the physical versus logical cpu identifiers right
when I generated that patch.  It's not nearly as bad as I feared at the time
though.

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

 arch/x86_64/kernel/smpboot.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

5192895f71c7eff7e1335cd9d6a775dda2bb5d52
diff --git a/arch/x86_64/kernel/smpboot.c b/arch/x86_64/kernel/smpboot.c
--- a/arch/x86_64/kernel/smpboot.c
+++ b/arch/x86_64/kernel/smpboot.c
@@ -334,7 +334,7 @@ static void __cpuinit tsc_sync_wait(void
 {
if (notscsync || !cpu_has_tsc)
return;
-   sync_tsc(boot_cpu_id);
+   sync_tsc(0);
 }
 
 static __init int notscsync_setup(char *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: Wireless support

[Kyle Moffett]

On Aug 11, 2005, at 23:17:07, Lee Revell wrote:

On Fri, 2005-08-12 at 12:59 +1000, roucaries bastien wrote:


They post on this list 1 year and a half ago no answer.


I guess everyone on LKML has day jobs now, no one has time for fun  
stuff

like reverse engineering drivers anymore... :-(


Much as I would love to help, I'm usually buried under schoolwork.   
In any

case, I really have to admire the people behind the project, translating
tens of thousands of MIPS assembly instructions to C, documenting the C,
then giving the documentation to somebody else to write the driver even
though by that point you could write it backwards in a blindfold,  
that has

_got_ to be hard and frustrating work.

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:


"Why do musicians compose symphonies and poets write poems? They do  
it because
life wouldn't have any meaning for them if they didn't. That's why I  
draw

cartoons. It's my life."
  -- Charles Shultz


-
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-rc6 Oops with Software RAID, LVM, JFS, NFS

[Phil Dier]

On Fri, 12 Aug 2005 12:07:21 +1000
Neil Brown <[EMAIL PROTECTED]> wrote:

> On Thursday August 11, [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > I posted an oops a few days ago from 2.6.12.3 [1].  Here are the results
> > of my tests on 2.6.13-rc6.  The kernel oopses, but it the box isn't 
> > completely
> > hosed; I can still log in and move around.  It appears that the only things 
> > that are
> > locked are the apps that were doing i/o to the test partition.  More 
> > detailed info 
> > about my configuration can be found here:
> > 
> > 
> 
> You don't seem to give details on how lvm is used to combine the md
> arrays, though I'm not sure that would help particularly.
> 

FYI:

vgdisplay -v vg1  
Using volume group(s) on command line
Finding volume group "vg1"
  --- Volume group ---
  VG Name   vg1
  System ID 
  Formatlvm2
  Metadata Areas2
  Metadata Sequence No  8
  VG Access read/write
  VG Status resizable
  MAX LV255
  Cur LV1
  Open LV   0
  Max PV255
  Cur PV2
  Act PV2
  VG Size   410.00 GB
  PE Size   128.00 MB
  Total PE  3280
  Alloc PE / Size   1093 / 136.62 GB
  Free  PE / Size   2187 / 273.38 GB
  VG UUID   XuRomW-O6Uw-oQGq-vdwD-YwMT-Dltj-NExFmV
   
  --- Logical volume ---
  LV Name/dev/vg1/home
  VG Namevg1
  LV UUIDK7Gq9l-Vjte-ksFt-s0vn-ejqT-RGYc-5Aibtx
  LV Write Accessread/write
  LV Status  available
  # open 0
  LV Size136.62 GB
  Current LE 1093
  Segments   1
  Allocation inherit
  Read ahead sectors 0
  Block device   253:3
   
  --- Physical volumes ---
  PV Name   /dev/md4 
  PV UUID   VgHU6k-lZmE-j686-dvfX-OSsM-yh28-Jyfidn
  PV Status allocatable
  Total PE / Free PE1093 / 0
   
  PV Name   /dev/md7 
  PV UUID   n4rVmy-rARO-a5mY-Iiqo-GvOx-2nbG-HluaTa
  PV Status allocatable
  Total PE / Free PE2187 / 2187

md7 is in there to test live migration from smaller disks to larger ones.


> 
>   struct bio_vec *from;
>   int i;
>   bio_for_each_segment(from, bio, i)
>   BUG_ON(page_zone(from->bv_page)==NULL);
> 
> in generic_make_requst in drivers/block/ll_rw_blk.c, just before
> the call to q->make_request_fn.
> This might trigger the bug early enough to see what is happening.


I'll try this and report the results.


-- 

Phil Dier <[EMAIL PROTECTED]>

/* vim:set ts=8 sw=8 nocindent noai: */
-
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 6/7] mm: lockless pagecache

[Nick Piggin]

On Thu, 2005-08-11 at 18:49 -0700, Paul E. McKenney wrote:
> On Thu, Aug 11, 2005 at 10:28:04PM +1000, Nick Piggin wrote:
> > 6/7
> > 
> > -- 
> > SUSE Labs, Novell Inc.
> > 
> 
> > Use the speculative get_page and the lockless radix tree lookups
> > to introduce lockless page cache lookups (ie. no mapping->tree_lock).
> > 
> > The only atomicity changes this should introduce is the use of a
> > non atomic pagevec lookup for truncate, however what atomicity
> > guarantees there were are probably not too useful anyway.
> 
> I don't understand the placement of the rcu_read_lock() and
> rcu_read_unlock() calls.  Again, possibly because I don't understand
> the overall algorithm yet.  And again, search for blank lines.
> 

I hope I gave a satisfactory answer to this in the last email. If
not, let me know what I've missed...

Indeed you are right that we could push all the RCU locking down
into the radix tree lookups in the places you mention _if_ we
didn't rely on lookups returning radix tree *slots*.

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.



Send instant messages to your online friends http://au.messenger.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: [patch 5/7] radix-tree: lockless readside

[Nick Piggin]

On Thu, 2005-08-11 at 18:37 -0700, Paul E. McKenney wrote:
> On Thu, Aug 11, 2005 at 10:25:47PM +1000, Nick Piggin wrote:
> > 5/7
> > 
> > -- 
> > SUSE Labs, Novell Inc.
> > 
> 
> > Make radix tree lookups safe to be performed without locks.
> > Readers are protected against nodes being deleted by using RCU
> > based freeing. Readers are protected against new node insertion
> > by using memory barriers to ensure the node itself will be
> > properly written before it is visible in the radix tree.
> > 
> > Also introduce a lockfree gang_lookup_slot which will be used
> > by a future patch.
> 
> Interesting approach!  Don't claim to fully understand it, but
> see below (search for empty lines).  In the meantime, some questions:
> 

Thanks for comments and review - very helpful.

> o What exactly is RCU protecting?  My first guess is that
>   it protects the pointers and internal nodes of the
>   radix tree, but not the objects in the leaves of the
>   trees (in other words, the things pointed to by the
>   return value from things like radix_tree_lookup_slot()).
> 

Ah OK, this wasn't initially apparent to me either, however I
believe it is needed.

Indeed we are protecting the internal nodes of the radix tree,
however the speculative get operation needs to dereference a
*pointer* to the page. The `struct page` itself doesn't go away,
and thus doesn't need any protection. However the *pointer* can
go away - it is contained within a radix tree node.

>   But if this really is the case, then the rcu_read_lock() &
>   rcu_read_unlock() pairs can be pushed down into
>   radix_tree_lookup_slot() and friends.
> 
> o The current code structure would lead me to believe that
>   page_cache_get_speculative() is protected by RCU, but
>   I don't see the corresponding call_rcu() or synchronize_rcu()
>   that would cause this protection to be required.
> 

I believe this should answer your concern about the RCU protection
placement.

One thing we could do differently is this: instead of receiving
a pointer to the struct page from the radix tree lookup, we could
actually do as you say and push the rcu locking into the radix
tree lookup.

Then we would do a speculative get_page on that struct page,
finally we would lookup the radix tree again to see whether the
same page is still in the pagecache.

I discounted this idea not just for efficiency, but also because
it would require either a 2 phase speculative get (or a speculative
undo), or would require teaching speculative get about the pagecache
radix tree.

> > @@ -208,9 +219,13 @@ static int radix_tree_extend(struct radi
> > tag_set(node, tag, 0);
> > }
> >  
> > +   newheight = root->height+1;
> > +   node->height = newheight;
> > node->count = 1;
> > +   /* Make ->height visible before node visible via ->rnode */
> 
> > +   smp_wmb();
> > root->rnode = node;
> 
> The prior two lines should instead be:
> 
>   rcu_assign_pointer(root->rnode, node);
> 

Great, thanks very much.

-- 
SUSE Labs, Novell Inc.



Send instant messages to your online friends http://au.messenger.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: [RFC][PATCH] Rename PageChecked as PageMiscFS

[Daniel Phillips]

On Thursday 11 August 2005 19:26, David Howells wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > +   SetPageMiscFS(page);
>
> Can you please retain the *PageFsMisc names I've been using in my stuff?
>
> In my opinion putting the "Fs" bit first gives a clearer indication that
> this is a bit exclusively for the use of filesystems in general.

You also achieved some sort of new low point in the abuse of StudlyCaps there. 
Please, let's not get started on mixed case acronyms.

Anyway, it sounds like you want to bless the use of private page flags in 
filesystems.  That is most probably a bad idea.  Take a browse through the 
existing users and feast your eyes on the spectacular lack of elegance.

Regards,

Daniel
-
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: suspect code in drivers/char/agp/generic.c

[Dave Jones]

On Thu, Aug 11, 2005 at 06:06:55PM -0700, Jeremy Fitzhardinge wrote:
 > I was just looking at agp_copy_info(), which contains this code:
 > 
 >318   if (bridge->mode & AGPSTAT_MODE_3_0)
 >319   info->mode = bridge->mode & ~AGP3_RESERVED_MASK;
 >320   else
 >321   info->mode = bridge->mode & ~AGP2_RESERVED_MASK;
 >322   info->mode = bridge->mode;
 > 
 > This looks wrong to me, since line 322 overrides the previous 4 lines'
 > work...
 > 
 > I have no idea whether this is actually causing a problem, but I'd
 > thought I'd call attention to it.
 
Ugh, that crept in when the multiple gart support got added.
Line 322 shouldn't be there. I'll nuke it in agpgart.git

Whilst its clearly wrong, I'd like the corrected version to take a quick
spin in -mm before we add this to 2.6.13, just in case.

Dave

-
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: SiI 3112A + Seagate HDs = still no go?

[Tejun Heo]

Chris Boot wrote:

Hi all,

I just recently took the plunge and bought 4 250 GB Seagate drives  and 
a 2 port Silicon Image 3112A controller card for the 2 drives my  
motherboard doesn't handle. No matter how hard I try, I can't get the  
hard drives to work: they are detected correctly and work reasonably  
well under _very_ light load, but anything like building a RAID array  
is a bit much and the whole controller seems to lock up.


I've tried adding the drive to the blacklist in the sata_sil.c driver  
and I still have the same trouble: as you can see the messages below  
relate to my patched kernel with the blacklist fix. I've seen that  this 
was discussed just yesterday, but that seemed to give nothing:  
http://www.ussg.iu.edu/hypermail/linux/kernel/0508.1/0310.html


Ready and willing to hack my kernel to pieces; this machine is no use  
until I get all the drives working! Needless to say the drives  
connected to the on-board VIA controller work fine, as do the drives  
currently on the SiI controller if I swap them around.


Any ideas?

TIA
Chris



[added linux-ide to cc list]

 Can you please try w/ vanilla kernel (2.6.12 or 2.6.13-rc)?  And w/ 
one drive only?


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

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Lee Revell]

On Thu, 2005-08-11 at 23:07 -0400, Lee Revell wrote:
> Very nice to see this going in (via) the RT patch.
> 

Also, does not compile for me with ACPI PM timer selected:

  CC  arch/i386/kernel/timers/hrtimer_pm.o
In file included from include/asm/hrtime.h:220,
 from include/linux/hrtime.h:58,
 from arch/i386/kernel/timers/hrtimer_pm.c:11:
include/asm/hrtime-Macpi.h: In function 'stake_cpuctr':
include/asm/hrtime-Macpi.h:110: warning: no return statement in function
returning non-void
arch/i386/kernel/timers/hrtimer_pm.c: In function 'high_res_init_pm':
arch/i386/kernel/timers/hrtimer_pm.c:141: warning: format '%lu' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
arch/i386/kernel/timers/hrtimer_pm.c:141: warning: format '%03lu'
expects type 'long unsigned int', but argument 3 has type 'unsigned int'
arch/i386/kernel/timers/hrtimer_pm.c:182: error: invalid lvalue in
assignment
make[2]: *** [arch/i386/kernel/timers/hrtimer_pm.o] Error 1
make[1]: *** [arch/i386/kernel/timers] Error 2
make: *** [arch/i386/kernel] Error 2

Lee

-
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] SH: inotify and ioprio syscalls

[Paul Mundt]

On Wed, Aug 10, 2005 at 04:07:09PM -0400, Robert Love wrote:
> Add inotify and ioprio syscall stubs to SH.
> 
>   Robert Love
> 
> 
> Signed-off-by: Robert Love <[EMAIL PROTECTED]>
> 
>  arch/sh/kernel/entry.S  |5 +
>  include/asm-sh/unistd.h |8 +++-
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 

On Wed, Aug 10, 2005 at 04:13:17PM -0400, Robert Love wrote:
> Add inotify and ioprio syscall stubs to SH64.
> 
>   Robert Love
> 
> 
> Signed-off-by: Robert Love <[EMAIL PROTECTED]>
> 
>  arch/sh64/kernel/syscalls.S |5 +
>  include/asm-sh64/unistd.h   |7 ++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
Both look good, thanks.

Acked-by: Paul Mundt <[EMAIL PROTECTED]>


pgpMPGgrepOy4.pgp
Description: PGP signature

Re: Wireless support

[Lee Revell]

On Fri, 2005-08-12 at 12:59 +1000, roucaries bastien wrote:
> They post on this list 1 year and a half ago no answer.
> 

I guess everyone on LKML has day jobs now, no one has time for fun stuff
like reverse engineering drivers anymore... :-(

Lee

-
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: Soft lockup in e100 driver ?

[Stephen D. Williams]

"noapic" didn't work, nor did "noacpi", etc.
Going to 2.6.13-rc6.2 solved the problem (once I integrated udev, etc.).

The chipset is an Intel 8x0 something.  Unfortunately, there is a 
heatsink semi-permanently installed over everything.  Is there a /proc 
pseudofile that will give me good identifying chipset info to report here?


If there is a FAQ for this, we should post a message about it once in a 
while.

Nothing here indicates chipset:
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html

The CPU is an Intel Celeron CPU 2.00GHz running at 1495.772 MHz, 128MB 
cache.


sdw

Matti Aarnio wrote:


On Wed, Aug 10, 2005 at 08:32:45PM -0400, Stephen D. Williams wrote:
 

I just noticed that the Ubuntu setup says "GSI 20(level,low) -> IRQ 20" 
whereas I remember my built kernels saying "No GSI..  IRQ 11".  I'll 
investigate what that means and how to enable it.  Pointers appreciated.
   



That is most likely unrelated, but I had similar experiences
at times.  It turned out that something done recently in APIC
management code did break things, but lattest version is again
working.   For a while to have network card working I had to boot
with  "noapic"  option in my home SMP box.

In an UP box it is about same to boot as "noapic", but in SMP it
does result in "one CPU does all interrupts" thingie.  (In some
rare cases it could be desirable, even.)

  /Matti Aarnio


 


sdw

Stephen D. Williams wrote:

   

I have been working for days to get a recent kernel to work with these 
small-format UP Celeron 2Ghz (running at 1.33Ghz) motherboards that I 
am planning to use as thin clients.  I'm doing a PXE boot, loading 
kernels, and trying to get networking to come up.


I eventually realized that the problem is that the e100 driver loads 
but does not allow any packet traffic.  The system isn't crashed, but 
I do get transmit timeouts.


I've used kernels: 2.6.10, 2.6.11, and 2.6.12.4, stock with only the 
"squashfs" patch applied and compiled as 586/


The interesting thing is that Ubuntu 5.04, booted "Live" on the box, 
works just fine with the e100 driver with a kernel shown as: 
"2.6.10-5-386".  I'm going to work on pulling this kernel and its 
modules off to use.


Any help urgently appreciated.

sdw
 



 



begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:[EMAIL PROTECTED]
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:[EMAIL PROTECTED]
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Lee Revell]

On Thu, 2005-08-11 at 13:00 +0200, Ingo Molnar wrote:
> i have released the -53-01 Real-Time Preemption patch, which can be 
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> there are two new features in this release, which justified the jump 
> from .52 to .53:
> 
>  - the inclusion of the High Resolution Timers patch, written by
>George Anzinger, and ported/improved/cleaned-up by Thomas Gleixner.
> 

George,

Very nice to see this going in (via) the RT patch.

Can we get a real help text here:

Clock & Timer Selection
> 1. Legacy Timer Support (LEGACY_TIMER) (NEW)
  2. HPET Timer Support (HPET_TIMER)
  3. High Resolution Timer Support (HIGH_RES_TIMERS) (NEW)
choice[1-3?]: ?

You may have either HPET, High Resolution, or Legacy timer support.

This would be a great place to put some of your extensive docs about the
various timer sources and issues on x86.  I have always thought the HRT
docs were the best source on the net for this info, and I refer people
to it whenever someone has a question about timers on the linux audio
lists.

The docs for "High Resolution Timer clock source" are great.

Can we get more docs here:

HRT Softirg dynamic priority adjustment (HIGH_RES_TIMERS_DYN_PRIO) 
^^^ typo
[N/y/?] (NEW) ?

This option enables the dynamic priority adjustment of the
high resolution timer soft interrupt

No point documenting this one if it's expected to go away though.

Lee


-
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][2.6.12.3] IRQ compression/sharing patch

[James Cleverdon]

The attached hack to assign_irq_vector may be marginally less ugly.
However, I haven't rearranged the code like Andi wanted yet.


On Thursday 11 August 2005 02:55 pm, Protasevich, Natalie wrote:
> > After sleeping on it, maybe the original code can be patched 
> > without having to hack assign_irq_vector(), etc.  How about:
> > 
> > --- io_apic.c   2005-08-11 10:14:33.564748923 -0700
> > +++ io_apic.c.new   2005-08-11 10:15:55.412331115 -0700
> > @@ -617,7 +617,7 @@ int gsi_irq_sharing(int gsi)
> >  * than PCI.
> >  */
> > for (i = 0; i < NR_IRQS; i++)
> > -   if (IO_APIC_VECTOR(i) == vector) {
> > +   if (IO_APIC_VECTOR(i) == vector && i != gsi) {
> > if (!platform_legacy_irq(i))
> > break;  /* got one */
> > IO_APIC_VECTOR(gsi) = 0;
> > 
> > 
> Yes that did it, on my small system it looked just right:
> 
> <7>IRQ to pin mappings:
> <7>IRQ0 -> 0:2
> <7>IRQ1 -> 0:1
> <7>IRQ3 -> 0:3
> <7>IRQ4 -> 0:4
> <7>IRQ5 -> 0:5
> <7>IRQ6 -> 0:6
> <7>IRQ7 -> 0:7
> <7>IRQ8 -> 0:8
> <7>IRQ9 -> 0:9
> <7>IRQ10 -> 0:10
> <7>IRQ11 -> 0:11
> <7>IRQ12 -> 0:12
> <7>IRQ14 -> 0:14
> <7>IRQ15 -> 0:15
> <7>IRQ16 -> 0:16
> <7>IRQ17 -> 0:17
> <7>IRQ18 -> 0:18
> <7>IRQ19 -> 0:19
> <7>IRQ20 -> 0:20
> <7>IRQ21 -> 0:23
> <7>IRQ22 -> 1:2
> <7>IRQ23 -> 1:3
> <7>IRQ24 -> 1:4
> <7>IRQ25 -> 1:5
> <7>IRQ26 -> 2:0
> <7>IRQ27 -> 2:1
> <7>IRQ28 -> 2:2
> <7>IRQ29 -> 2:3
> <7>IRQ30 -> 2:4
> <7>IRQ31 -> 2:5
> <7>IRQ32 -> 2:6
> <7>IRQ33 -> 2:7
> <7>IRQ34 -> 2:8
> :!cat /proc/interrupts
>CPU0   CPU1   CPU2   CPU3
>   0:  12621  15007  12781  20921IO-APIC-edge  timer
>   1: 72  0  2175IO-APIC-edge  i8042
>   2:  0  0  0  0  XT-PIC
> cascade
>   8:  0  0  0  1IO-APIC-edge  rtc
>   9:  0  0  0  0IO-APIC-edge  acpi
>  12:  4272  0110IO-APIC-edge  i8042
>  15:  4  0  0 39IO-APIC-edge  ide1
>  16:  0  0  0  0   IO-APIC-level
> uhci_hcd:usb1, uhci_hcd:usb4
>  17:  0  0  0  2   IO-APIC-level
> ohci1394
>  18:730   2407932   2083   IO-APIC-level
> libata, uhci_hcd:usb3
>  19:  0  0  0  0   IO-APIC-level
> uhci_hcd:usb2
>  21:  0  0  0  0   IO-APIC-level
> ehci_hcd:usb5
>  26:416  0  0  4   IO-APIC-level  eth0
> NMI:116 71 73 51
> LOC:  61280  61258  61236  61214
> ERR:  3
> MIS:  0
> 
> Looks good! I will try the patch also on the ES7000 hopefully big enough
> to exercise some vector sharing.
> 
> Regards,
> --Natalie
> 
> 
> 

-- 
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
diff -pru 2.6.12.3/arch/i386/kernel/acpi/boot.c z12.3/arch/i386/kernel/acpi/boot.c
--- 2.6.12.3/arch/i386/kernel/acpi/boot.c	2005-07-15 14:18:57.0 -0700
+++ z12.3/arch/i386/kernel/acpi/boot.c	2005-08-11 19:27:46.0 -0700
@@ -42,6 +42,7 @@
 static inline void  acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
 extern void __init clustered_apic_check(void);
 static inline int ioapic_setup_disabled(void) { return 0; }
+extern int gsi_irq_sharing(int gsi);
 #include 
 
 #else	/* X86 */
@@ -51,6 +52,9 @@ static inline int ioapic_setup_disabled(
 #include 
 #endif	/* CONFIG_X86_LOCAL_APIC */
 
+static inline int gsi_irq_sharing(int gsi) { return gsi; }
+
+
 #endif	/* X86 */
 
 #define BAD_MADT_ENTRY(entry, end) (	\
@@ -453,7 +457,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
  		*irq = IO_APIC_VECTOR(gsi);
 	else
 #endif
-		*irq = gsi;
+		*irq = gsi_irq_sharing(gsi);
 	return 0;
 }
 
diff -pru 2.6.12.3/arch/x86_64/kernel/io_apic.c z12.3/arch/x86_64/kernel/io_apic.c
--- 2.6.12.3/arch/x86_64/kernel/io_apic.c	2005-07-15 14:18:57.0 -0700
+++ z12.3/arch/x86_64/kernel/io_apic.c	2005-08-11 19:32:28.0 -0700
@@ -56,7 +56,7 @@ int nr_ioapic_registers[MAX_IO_APICS];
  * Rough estimation of how many shared IRQs there are, can
  * be changed anytime.
  */
-#define MAX_PLUS_SHARED_IRQS NR_IRQS
+#define MAX_PLUS_SHARED_IRQS NR_IRQ_VECTORS
 #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + NR_IRQS)
 
 /*
@@ -88,6 +88,7 @@ static void add_pin_to_irq(unsigned int 
 	static int first_free_entry = NR_IRQS;
 	struct irq_pin_list *entry = irq_2_pin + irq;
 
+	BUG_ON(irq >= NR_IRQS);
 	while (entry->next)
 		entry = irq_2_pin + entry->next;
 
@@ -95,7 +96,7 @@ static void add_pin_to_irq(unsigned int 
 		entry->next = first_free_entry;
 		entry = irq_2_pin + entry->next;
 		if (++first_free_entry >= PIN_MAP_SIZE)
-			panic("io_apic.c: whoops");
+			panic("io_apic.c: ran out of irq_2_pin 

Re: Wireless support

[roucaries bastien]

On 8/12/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-09 at 09:52 -0400, Kyle Moffett wrote:
> > they are much less likely to participate in any kind of reverse
> > engineering effort, even if it's just testing a new driver.
> 
> I think anyone launching a reverse engineering effort should announce
> the project to LKML!  When I set out to add some multichannel
> functionality to the emu10k1 ALSA drivers based on the kX project
> Windows drivers, I announced the project to alsa-devel and alsa-user,
> and got a number of volunteers who were most helpful in testing these
> new features, and greatly sped up the effort.  As a result we were able
> to fix almost all the major bugs before I even submitted the patch.  Now
> these new features are merged as of ALSA 1.0.9.

Problem:
o They are translating the drivers (about 66% is done, dma and pio are
close to be done) but in order to close claim for broadcom they don't
create divers. This guys will release documentation. See chinese wall
method on wikipedia.
o They post on this list 1 year and a half ago no answer.


> There is a very large group of people who can't write code but have the
> hardware and are dying to get more out of it, or just to get it to work,
> and would gladly help any Linux driver reverse engineering project, if
> they just knew about it.

o They need more programmer for reverse engeenering effort and
different programmer for writing the drivers from the documentation.
Actually 10% take about 3 months. For the courageous people, they
don't reverse directelly from asm but from C. In fact as mips asm is
pretty simple they can translate asm to C.  Nethertheless, it s
spagetty code and variable are referenced by pointer.
Reverse engeenering is therefore:
 - transform goto in for loop or while loop
 - transform *(phy+1054) in : int error or something like this.

o Testing perhaps in the end of year

Moreover this drivers will support all kind of broadcom card as the
drivers look like to be common

> Lee
> 
> -
> 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/
> 
bastien
-
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: Trouble shooting a ten minute boot delay (SiI3112)

[Tejun Heo]

Shaun Jackman wrote:

I added a PCI SATA controller to my computer. Immediately after grub
loads the kernel there is a consistent ten minute delay before the
kernel displays its first message. I tested Linux 2.6.8 and 2.6.11
both from Debian, and 2.6.11 from Knoppix, all of which experience the
same delay.

The SATA controller is connected to two 200 GB Seagate SATA
ST3200826AS drives. I managed to install Debian on the system, though
the install was perilous, and once booted the system runs wonderfully!
Any suggestions on how I can trouble shoot the ten minute boot delay?
I don't reboot frequently, but it is irksome.

What's the appropriate mailing list for SATA questions, perhaps
linux-ide or linux-scsi?

Please cc me in your reply. Thanks!
Shaun




 Hi, Shaun Jackman.

 The list would be linux-ide but it doesn't really seem like a SATA 
problem.


 * What do you mean by the `first' message?  ie. What's the first line 
you read?

 * Is it really ten minutes?

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

Re: [PATCH 0/8] netpoll: various bugfixes

[David S. Miller]

From: Matt Mackall <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 21:18:28 -0500

> This patch series cleans up a few outstanding bugs in netpoll:
> 
> - two bugfixes from Jeff Moyer's netpoll bonding
> - a tweak to e1000's netpoll stub
> - timeout handling for e1000 with carrier loss
> - prefilling SKBs at init
> - a fix-up for a race discovered in initialization
> - an unused variable warning
> 
> This patch set was tested over repeated rebooting with both tg3 and
> e1000 and random cable disconnection, with and without SMP and
> preempt. Please apply.

All applied, thanks a lot for putting this patch set together.

I'll push this to Linus after some smoke testing.
-
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: Wireless support

[Lee Revell]

On Tue, 2005-08-09 at 09:52 -0400, Kyle Moffett wrote:
> they are much less likely to participate in any kind of reverse  
> engineering effort, even if it's just testing a new driver.

I think anyone launching a reverse engineering effort should announce
the project to LKML!  When I set out to add some multichannel
functionality to the emu10k1 ALSA drivers based on the kX project
Windows drivers, I announced the project to alsa-devel and alsa-user,
and got a number of volunteers who were most helpful in testing these
new features, and greatly sped up the effort.  As a result we were able
to fix almost all the major bugs before I even submitted the patch.  Now
these new features are merged as of ALSA 1.0.9.

There is a very large group of people who can't write code but have the
hardware and are dying to get more out of it, or just to get it to work,
and would gladly help any Linux driver reverse engineering project, if
they just knew about it.

Lee

-
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 3/8] [PATCH] x86_64: Fixing smpboot timing problem

[Eric W. Biederman]

Chris Wright <[EMAIL PROTECTED]> writes:

> * Andi Kleen ([EMAIL PROTECTED]) wrote:
>> >  static void __cpuinit tsc_sync_wait(void)
>> >  {
>> >if (notscsync || !cpu_has_tsc)
>> >return;
>> > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
>> > -  boot_cpu_id);
>> > -  sync_tsc();
>> > +  sync_tsc(boot_cpu_id);
>> 
>> I actually found a bug in this today. This should be sync_tsc(0), not
> sync_tsc(boot_cpu_id)
>> Can you just fix it in your tree or should I submit a new patch? 
>
> I'll fix it locally.  Thanks for the heads-up.

Someone needs to send the patch to Linus for 2.6.13 as well.  Is someone
else going to or should I.  I knew I was confused about physical versus
logical apic ids when I generated the patch.

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] Rename PageChecked as PageMiscFS

[Daniel Phillips]

On Thursday 11 August 2005 19:46, David Howells wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > Since this was done only for CacheFS, and Andrew dropped CacheFS from
> > -mm he could drop this patch as well.
>
> I asked him not to. Somewhat at his instigation, I requested that he drop
> the filesystem caching patches for the moment. I'm updating them and
> they'll be back soon. Taking out this and the other remaining patch means
> he'll just be given them back again shortly.
>
> I know you want to ruthlessly trim out anything that isn't used, but please
> be patient:-)

Are you sure CacheFS is even the right way to do client-side caching?  What is 
wrong with handling the backing store directly in your network filesystem?  
You have to hack your filesystem to use CacheFS anyway, so why not write some 
library functions to handle the backing store mapping and turn the hack into 
a few library calls instead?

I just don't see how turning this functionality into a filesystem is the right 
abstraction.  What actual advantage is there?  I noticed somebody out there 
on the web waxing poetic about how the administrator can look into the cache, 
see what is cached, and even delete some of it.  That just makes me cringe.

Regards,

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

[PATCH 1/8] netpoll: rx_flags bugfix

[Matt Mackall]

Initialize npinfo->rx_flags.  The way it stands now, this will have random
garbage, and so will incur a locking penalty even when an rx_hook isn't
registered and we are not active in the netpoll polling code.

Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

--- linux-2.6.12/net/core/netpoll.c.orig2005-07-01 14:02:56.039174635 
-0400
+++ linux-2.6.12/net/core/netpoll.c 2005-07-01 14:03:16.688739508 -0400
@@ -639,6 +639,7 @@ int netpoll_setup(struct netpoll *np)
if (!npinfo)
goto release;
 
+   npinfo->rx_flags = 0;
npinfo->rx_np = NULL;
npinfo->poll_lock = SPIN_LOCK_UNLOCKED;
npinfo->poll_owner = -1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] netpoll: netpoll_send_skb simplify

[Matt Mackall]

Minor netpoll_send_skb restructuring

Restructure to avoid confusing goto and move some bits out of the
retry loop.

Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c   2005-08-07 15:15:48.0 -0500
+++ l/net/core/netpoll.c2005-08-07 16:59:27.0 -0500
@@ -248,14 +248,14 @@ static void netpoll_send_skb(struct netp
int status;
struct netpoll_info *npinfo;
 
-repeat:
-   if(!np || !np->dev || !netif_running(np->dev)) {
+   if (!np || !np->dev || !netif_running(np->dev)) {
__kfree_skb(skb);
return;
}
 
-   /* avoid recursion */
npinfo = np->dev->npinfo;
+
+   /* avoid recursion */
if (npinfo->poll_owner == smp_processor_id() ||
np->dev->xmit_lock_owner == smp_processor_id()) {
if (np->drop)
@@ -265,29 +265,31 @@ repeat:
return;
}
 
-   spin_lock(>dev->xmit_lock);
-   np->dev->xmit_lock_owner = smp_processor_id();
+   while (1) {
+   spin_lock(>dev->xmit_lock);
+   np->dev->xmit_lock_owner = smp_processor_id();
+
+   /*
+* network drivers do not expect to be called if the queue is
+* stopped.
+*/
+   if (netif_queue_stopped(np->dev)) {
+   np->dev->xmit_lock_owner = -1;
+   spin_unlock(>dev->xmit_lock);
+   netpoll_poll(np);
+   continue;
+   }
 
-   /*
-* network drivers do not expect to be called if the queue is
-* stopped.
-*/
-   if (netif_queue_stopped(np->dev)) {
+   status = np->dev->hard_start_xmit(skb, np->dev);
np->dev->xmit_lock_owner = -1;
spin_unlock(>dev->xmit_lock);
 
-   netpoll_poll(np);
-   goto repeat;
-   }
-
-   status = np->dev->hard_start_xmit(skb, np->dev);
-   np->dev->xmit_lock_owner = -1;
-   spin_unlock(>dev->xmit_lock);
+   /* success */
+   if(!status)
+   return;
 
-   /* transmit busy */
-   if(status) {
+   /* transmit busy */
netpoll_poll(np);
-   goto repeat;
}
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] netpoll: e1000 netpoll tweak

[Matt Mackall]

Suggested by Steven Rostedt, matches his patch included in e100.

Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: l/drivers/net/e1000/e1000_main.c
===
--- l.orig/drivers/net/e1000/e1000_main.c   2005-08-06 17:36:32.0 
-0500
+++ l/drivers/net/e1000/e1000_main.c2005-08-06 17:55:01.0 -0500
@@ -3789,6 +3789,7 @@ e1000_netpoll(struct net_device *netdev)
struct e1000_adapter *adapter = netdev_priv(netdev);
disable_irq(adapter->pdev->irq);
e1000_intr(adapter->pdev->irq, netdev, NULL);
+   e1000_clean_tx_irq(adapter);
enable_irq(adapter->pdev->irq);
 }
 #endif
-
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/8] netpoll: deadlock bugfix

[Matt Mackall]

This fixes an obvious deadlock in the netpoll code.  netpoll_rx takes the
npinfo->rx_lock.  netpoll_rx is also the only caller of arp_reply (through
__netpoll_rx).  As such, it is not necessary to take this lock.

Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c   2005-08-06 17:47:48.0 -0500
+++ l/net/core/netpoll.c2005-08-06 17:47:49.0 -0500
@@ -353,11 +353,8 @@ static void arp_reply(struct sk_buff *sk
struct sk_buff *send_skb;
struct netpoll *np = NULL;
 
-   spin_lock_irqsave(>rx_lock, flags);
if (npinfo->rx_np && npinfo->rx_np->dev == skb->dev)
np = npinfo->rx_np;
-   spin_unlock_irqrestore(>rx_lock, flags);
-
if (!np)
return;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/8] netpoll: various bugfixes

[Matt Mackall]

This patch series cleans up a few outstanding bugs in netpoll:

- two bugfixes from Jeff Moyer's netpoll bonding
- a tweak to e1000's netpoll stub
- timeout handling for e1000 with carrier loss
- prefilling SKBs at init
- a fix-up for a race discovered in initialization
- an unused variable warning

This patch set was tested over repeated rebooting with both tg3 and
e1000 and random cable disconnection, with and without SMP and
preempt. Please apply.
-
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/8] netpoll: remove unused variable

[Matt Mackall]

Remove unused variable

Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c   2005-08-11 01:32:01.0 -0500
+++ l/net/core/netpoll.c2005-08-11 01:49:37.0 -0500
@@ -356,7 +356,6 @@ static void arp_reply(struct sk_buff *sk
unsigned char *arp_ptr;
int size, type = ARPOP_REPLY, ptype = ETH_P_ARP;
u32 sip, tip;
-   unsigned long flags;
struct sk_buff *send_skb;
struct netpoll *np = NULL;
 
-
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/8] netpoll: fix initialization/NAPI race

[Matt Mackall]

This fixes a race during initialization with the NAPI softirq
processing by using an RCU approach.

This race was discovered when refill_skbs() was added to
the setup code.

Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c   2005-08-09 00:56:23.0 -0500
+++ l/net/core/netpoll.c2005-08-11 01:50:24.0 -0500
@@ -731,6 +731,9 @@ int netpoll_setup(struct netpoll *np)
/* last thing to do is link it to the net device structure */
ndev->npinfo = npinfo;
 
+   /* avoid racing with NAPI reading npinfo */
+   synchronize_rcu();
+
return 0;
 
  release:
Index: l/include/linux/netpoll.h
===
--- l.orig/include/linux/netpoll.h  2005-08-09 00:56:23.0 -0500
+++ l/include/linux/netpoll.h   2005-08-11 01:33:42.0 -0500
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 struct netpoll;
@@ -61,25 +62,31 @@ static inline int netpoll_rx(struct sk_b
return ret;
 }
 
-static inline void netpoll_poll_lock(struct net_device *dev)
+static inline void *netpoll_poll_lock(struct net_device *dev)
 {
+   rcu_read_lock(); /* deal with race on ->npinfo */
if (dev->npinfo) {
spin_lock(>npinfo->poll_lock);
dev->npinfo->poll_owner = smp_processor_id();
+   return dev->npinfo;
}
+   return NULL;
 }
 
-static inline void netpoll_poll_unlock(struct net_device *dev)
+static inline void netpoll_poll_unlock(void *have)
 {
-   if (dev->npinfo) {
-   dev->npinfo->poll_owner = -1;
-   spin_unlock(>npinfo->poll_lock);
+   struct netpoll_info *npi = have;
+
+   if (npi) {
+   npi->poll_owner = -1;
+   spin_unlock(>poll_lock);
}
+   rcu_read_unlock();
 }
 
 #else
 #define netpoll_rx(a) 0
-#define netpoll_poll_lock(a)
+#define netpoll_poll_lock(a) 0
 #define netpoll_poll_unlock(a)
 #endif
 
Index: l/net/core/dev.c
===
--- l.orig/net/core/dev.c   2005-08-09 00:56:23.0 -0500
+++ l/net/core/dev.c2005-08-11 01:34:08.0 -0500
@@ -1696,7 +1696,8 @@ static void net_rx_action(struct softirq
struct softnet_data *queue = &__get_cpu_var(softnet_data);
unsigned long start_time = jiffies;
int budget = netdev_budget;
-   
+   void *have;
+
local_irq_disable();
 
while (!list_empty(>poll_list)) {
@@ -1709,10 +1710,10 @@ static void net_rx_action(struct softirq
 
dev = list_entry(queue->poll_list.next,
 struct net_device, poll_list);
-   netpoll_poll_lock(dev);
+   have = netpoll_poll_lock(dev);
 
if (dev->quota <= 0 || dev->poll(dev, )) {
-   netpoll_poll_unlock(dev);
+   netpoll_poll_unlock(have);
local_irq_disable();
list_del(>poll_list);
list_add_tail(>poll_list, >poll_list);
@@ -1721,7 +1722,7 @@ static void net_rx_action(struct softirq
else
dev->quota = dev->weight;
} else {
-   netpoll_poll_unlock(dev);
+   netpoll_poll_unlock(have);
dev_put(dev);
local_irq_disable();
}
-
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 6/8] netpoll: pre-fill skb pool

[Matt Mackall]

we could do one thing (see the patch below): i think it would be useful 
to fill up the netlogging skb queue straight at initialization time.  
Especially if netpoll is used for dumping alone, the system might not be 
in a situation to fill up the queue at the point of crash, so better be 
a bit more prepared and keep the pipeline filled.

Ingo

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>

I've modified this to be called earlier - mpm

Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>

Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c   2005-08-08 23:00:48.0 -0500
+++ l/net/core/netpoll.c2005-08-11 01:50:31.0 -0500
@@ -724,6 +724,10 @@ int netpoll_setup(struct netpoll *np)
npinfo->rx_np = np;
spin_unlock_irqrestore(>rx_lock, flags);
}
+
+   /* fill up the skb queue */
+   refill_skbs();
+
/* last thing to do is link it to the net device structure */
ndev->npinfo = npinfo;
 
-
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-rc6 Oops with Software RAID, LVM, JFS, NFS

[Neil Brown]

On Thursday August 11, [EMAIL PROTECTED] wrote:
> Hi,
> 
> I posted an oops a few days ago from 2.6.12.3 [1].  Here are the results
> of my tests on 2.6.13-rc6.  The kernel oopses, but it the box isn't completely
> hosed; I can still log in and move around.  It appears that the only things 
> that are
> locked are the apps that were doing i/o to the test partition.  More detailed 
> info 
> about my configuration can be found here:
> 
> 

You don't seem to give details on how lvm is used to combine the md
arrays, though I'm not sure that would help particularly.


> 
> Here is the oops:
> 
> Oops:  [#1]
> SMP
> Modules linked in:
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010207   (2.6.13-rc6)
> EIP is at kmap+0x10/0x30
> eax: 0003   ebx: d0977440   ecx: c9efb470   edx: 
> esi: c100   edi:    ebp: ce59d570   esp: f7adde18
> ds: 007b   es: 007b   ss: 0068
> Process md4_raid1 (pid: 6442, threadinfo=f7adc000 task=f70eda20)
> Stack: c014e0bd c9efb470 0001   cb129000 0001 e0c65f00
>f7dcbe18 087641ef  f7dcbe18 c014e146 f7dcbe18 f7addeb0 c3146940
>c033f03f f7dcbe18 f7addeb0 0021d906  003f 0040 
> Call Trace:
>  [] __blk_queue_bounce+0x20d/0x260
--snip---
> Code: 00 40 c7 46 0c 90 30 15 c0 c7 46 10 90 31 15 c0 eb b9 90 90 90 90 90 90 
> 90 90 90 8b 4c 24 04 8b 01 c1 e8 1e 8b 14 85 14 f4 63 c0 <8b> 82 0c 04 00 00 
> 05 00 09 00 00 39 c2 74 05 e9 ac 73 03 00 89
> 

The code is Oopsing in a call to kmap in arch/i386/highmem.c
The PageHighMem macro calls is_highmem(page_zone(page)).
page_zone is defined in mm.h
static inline struct zone *page_zone(struct page *page)
{
return zone_table[(page->flags >> ZONETABLE_PGSHIFT) &
ZONETABLE_MASK];
}

Now at the point of the crash, eax is
(page->flags >> ZONETABLE_PGSHIFT),
which is '3'.  So it seems that this page is in zone 3.
However  zone_table[3] is now in edx, and we can see it is '0'.
There are only 3 zones (normal, dma, highmem), so nothing should ever
by in zone 3.  This page is clearly bad.

However that is as far as I can get.  I don't know whether this is a
bad page pointer passed down from jfs or nfsd, a page pointer that was
corrupted by either lvm or md, or a valid page pointer that has
managed to get a bad zone number encoded in it's flags.

You could possibly put something like

struct bio_vec *from;
int i;
bio_for_each_segment(from, bio, i)
BUG_ON(page_zone(from->bv_page)==NULL);

in generic_make_requst in drivers/block/ll_rw_blk.c, just before
the call to q->make_request_fn.
This might trigger the bug early enough to see what is happening.


> 
> Thanks for looking..
> 

Thanks for testing.

NeilBrown
-
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 RCU to protect tasklist for unicast signals

[Lee Revell]

On Thu, 2005-08-11 at 11:56 +0200, Ingo Molnar wrote:
> > For the record, some shortcomings of this patch:
> > 
> > o   Needs lots more testing on more architectures.
> > 
> > o   Needs performance and stress testing.
> > 
> > o   Needs testing in Ingo's PREEMPT_RT environment.
> 
> cool patch! I have integrated it into my PREEMPT_RT tree, and all it 
> needed to boot was the patch below (doesnt affect the upstream kernel).  
> Using the raw IRQ flag isnt an issue in the RCU code, all the affected 
> codepaths are small and deterministic.
> 

Ingo,

Doesn't this fix the longest latency we were seeing with
PREEMPT_DESKTOP, I don't have a trace handy but the upshot was "signal
delivery must remain atomic on !PREEMPT_RT"?

Lee

-
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: System shutdown with during reboot with 2.6.13-pre6

[Jiri Slaby]

Masoud Sharbiani napsal(a):


Hello,
Adding reboot=w causes system to reboot properly.


It doesn't use interrupt now, it only jumps to one far address with one 
number saved in other place in memory,


Is this a known issue with 2.6.latest ACPI or is it that my mainboard 
is broken?


No, I don't know about anybody, who has the same problem (it doesn't 
mean, that it couldn't be).
Did it work before? Could you accurate version of kernel, where it stops 
working?


--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~  [EMAIL PROTECTED]  ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10

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

BUG: 2.6.12-ck5 (2.6.12.4) forcedeth driver

[Gabriel Devenyi]

My x86-64 system has two network cards, a r8169 and a forcedeth, the r8169 
works fine on my network,
but when I attempt to use the forcedeth card, I get the following errors in 
dmesg:

NETDEV WATCHDOG: eth0: transmit timed out
nv_stop_tx: TransmitterStatus remained busy<7>eth0: tx_timeout: dead entries!
--REPEATS--

I thought it might be a pci routing issues, so I tried pci=routeirq, but it 
made no difference. 

lspci reports:

:00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
Subsystem: Micro-Star International Co., Ltd.: Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC,PATCH] Use RCU to protect tasklist for unicast signals

[Paul E. McKenney]

On Thu, Aug 11, 2005 at 04:16:53PM +0400, Oleg Nesterov wrote:
> Paul E. McKenney wrote:
> >
> > --- linux-2.6.13-rc6/kernel/signal.c2005-08-08 19:59:24.0 
> > -0700
> > +++ linux-2.6.13-rc6-tasklistRCU/kernel/signal.c2005-08-10 
> > 08:20:25.0 -0700
> > @@ -1151,9 +1151,13 @@ int group_send_sig_info(int sig, struct 
> >
> > ret = check_kill_permission(sig, info, p);
> > if (!ret && sig && p->sighand) {
> > +   if (!get_task_struct_rcu(p)) {
> > +   return -ESRCH;
> > +   }
> > spin_lock_irqsave(>sighand->siglock, flags);
>   ^^^
> Is it correct?

Most definitely not!  Thank you again for catching this one, would have
taken some serious test-and-debug time to root it out the hard way.

Fix provided as a patch against V0.7.53-01, probably still has some
bugs, as it has not yet been thoroughly tested.  General approach is
to RCU-protect the sighand pointer from task_struct to sighand_struct.

Will be testing more thoroughly, in the meantime, thoughts?

Thanx, Paul

 fs/exec.c |6 +-
 include/linux/sched.h |   10 ++
 kernel/fork.c |   11 +++
 kernel/signal.c   |   16 +---
 4 files changed, 39 insertions(+), 4 deletions(-)

diff -urpNa -X dontdiff linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/fs/exec.c 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/fs/exec.c
--- linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/fs/exec.c  2005-08-11 
11:44:55.0 -0700
+++ linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/fs/exec.c  
2005-08-11 12:26:45.0 -0700
@@ -773,6 +773,8 @@ no_thread_group:
 */
spin_lock_init(>siglock);
atomic_set(>count, 1);
+   newsighand->deleted = 0;
+   newsighand->successor = NULL;
memcpy(newsighand->action, oldsighand->action,
   sizeof(newsighand->action));
 
@@ -785,12 +787,14 @@ no_thread_group:
recalc_sigpending();
 
task_unlock(current);
+   oldsighand->deleted = 1;
+   oldsighand->successor = newsighand;
spin_unlock(>siglock);
spin_unlock(>siglock);
write_unlock_irq(_lock);
 
if (atomic_dec_and_test(>count))
-   kmem_cache_free(sighand_cachep, oldsighand);
+   sighand_free(oldsighand);
}
 
BUG_ON(!thread_group_empty(current));
diff -urpNa -X dontdiff 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/include/linux/sched.h 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/include/linux/sched.h
--- linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/include/linux/sched.h  
2005-08-11 11:44:57.0 -0700
+++ 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/include/linux/sched.h  
2005-08-11 12:17:01.0 -0700
@@ -450,8 +450,18 @@ struct sighand_struct {
atomic_tcount;
struct k_sigaction  action[_NSIG];
spinlock_t  siglock;
+   int deleted;
+   struct sighand_struct   *successor;
+   struct rcu_head rcu;
 };
 
+static inline void sighand_free(struct sighand_struct *sp)
+{
+   extern void sighand_free_cb(struct rcu_head *rhp);
+
+   call_rcu(>rcu, sighand_free_cb);
+}
+
 /*
  * NOTE! "signal_struct" does not have it's own
  * locking, because a shared signal_struct always
diff -urpNa -X dontdiff 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/kernel/fork.c 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/kernel/fork.c
--- linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/kernel/fork.c  2005-08-11 
11:44:57.0 -0700
+++ linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/kernel/fork.c  
2005-08-11 13:05:17.0 -0700
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -769,6 +770,14 @@ int unshare_files(void)
 
 EXPORT_SYMBOL(unshare_files);
 
+void sighand_free_cb(struct rcu_head *rhp)
+{
+   struct sighand_struct *sp =
+   container_of(rhp, struct sighand_struct, rcu);
+
+   kmem_cache_free(sighand_cachep, sp);
+}
+
 static inline int copy_sighand(unsigned long clone_flags, struct task_struct * 
tsk)
 {
struct sighand_struct *sig;
@@ -783,6 +792,8 @@ static inline int copy_sighand(unsigned 
return -ENOMEM;
spin_lock_init(>siglock);
atomic_set(>count, 1);
+   sig->deleted = 0;
+   sig->successor = 0;
memcpy(sig->action, current->sighand->action, sizeof(sig->action));
return 0;
 }
diff -urpNa -X dontdiff 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01/kernel/signal.c 
linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/kernel/signal.c
--- 

Re: [patch 6/7] mm: lockless pagecache

[Paul E. McKenney]

On Thu, Aug 11, 2005 at 10:28:04PM +1000, Nick Piggin wrote:
> 6/7
> 
> -- 
> SUSE Labs, Novell Inc.
> 

> Use the speculative get_page and the lockless radix tree lookups
> to introduce lockless page cache lookups (ie. no mapping->tree_lock).
> 
> The only atomicity changes this should introduce is the use of a
> non atomic pagevec lookup for truncate, however what atomicity
> guarantees there were are probably not too useful anyway.

I don't understand the placement of the rcu_read_lock() and
rcu_read_unlock() calls.  Again, possibly because I don't understand
the overall algorithm yet.  And again, search for blank lines.

> Index: linux-2.6/mm/filemap.c
> ===
> --- linux-2.6.orig/mm/filemap.c
> +++ linux-2.6/mm/filemap.c
> @@ -379,18 +379,25 @@ int add_to_page_cache(struct page *page,
>   int error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
>  
>   if (error == 0) {
> + page_cache_get(page);
> + __SetPageLocked(page);
> + page->mapping = mapping;
> + page->index = offset;
> +
>   write_lock_irq(>tree_lock);
>   error = radix_tree_insert(>page_tree, offset, page);
>   if (!error) {
> - page_cache_get(page);
> - SetPageLocked(page);
> - page->mapping = mapping;
> - page->index = offset;
>   mapping->nrpages++;
>   pagecache_acct(1);
>   }
>   write_unlock_irq(>tree_lock);
>   radix_tree_preload_end();
> +
> + if (error) {
> + page->mapping = NULL;
> + __put_page(page);
> + __ClearPageLocked(page);
> + }
>   }
>   return error;
>  }
> @@ -500,13 +507,15 @@ EXPORT_SYMBOL(__lock_page);
>   */
>  struct page * find_get_page(struct address_space *mapping, unsigned long 
> offset)
>  {
> - struct page *page;
> + struct page **pagep;
> + struct page *page = NULL;
>  
> - read_lock_irq(>tree_lock);
> - page = radix_tree_lookup(>page_tree, offset);
> - if (page)
> - page_cache_get(page);
> - read_unlock_irq(>tree_lock);
> + rcu_read_lock();
> + pagep = (struct page **)radix_tree_lookup_slot(>page_tree,
> + offset);
> + if (pagep)
> + page = page_cache_get_speculative(pagep);

The data structures accessed by page_cache_get_speculative() don't
seem to be freed via RCU.  My guess is that this is because these
data structures (struct page) never really go away.  However, they
do get re-used, and this re-use must be protected against.  It looks
to me that this protection takes the form of atomic instructions
in get_page_testone() and the like.  If this is the case, then it
should be possible to push the rcu_read_lock() and rcu_read_unlock()
down into the radix_tree_lookup_slot().

> + rcu_read_unlock();
>   return page;
>  }
>  
> @@ -519,12 +528,24 @@ struct page *find_trylock_page(struct ad
>  {
>   struct page *page;
>  
> - read_lock_irq(>tree_lock);
> - page = radix_tree_lookup(>page_tree, offset);
> - if (page && TestSetPageLocked(page))
> - page = NULL;
> - read_unlock_irq(>tree_lock);
> - return page;
> + page = find_get_page(mapping, offset);
> + if (page) {
> + if (TestSetPageLocked(page))
> + goto out_failed;
> + /* Has the page been truncated before being locked? */
> + if (page->mapping != mapping || page->index != offset) {
> + unlock_page(page);
> + goto out_failed;
> + }
> +
> + /* Silly interface requires us to drop the refcount */
> + __put_page(page);
> + return page;
> +
> +out_failed:
> + page_cache_release(page);
> + }
> + return NULL;
>  }
>  
>  EXPORT_SYMBOL(find_trylock_page);
> @@ -545,25 +566,17 @@ struct page *find_lock_page(struct addre
>  {
>   struct page *page;
>  
> - read_lock_irq(>tree_lock);
>  repeat:
> - page = radix_tree_lookup(>page_tree, offset);
> + page = find_get_page(mapping, offset);
>   if (page) {
> - page_cache_get(page);
> - if (TestSetPageLocked(page)) {
> - read_unlock_irq(>tree_lock);
> - lock_page(page);
> - read_lock_irq(>tree_lock);
> -
> - /* Has the page been truncated while we slept? */
> - if (page->mapping != mapping || page->index != offset) {
> - unlock_page(page);
> - page_cache_release(page);
> - goto repeat;
> - }
> + lock_page(page);
> + /* 

Re: allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task)

[Siddha, Suresh B]

On Fri, Aug 12, 2005 at 11:24:14AM +1000, Nick Piggin wrote:
> I'm not saying that I would reject any patch that did this or changed
> behaviour in the way that you would propose, however I would like
> to merge the version I sent as a bug fix first.

Please go ahead. Depending on the need, we will revisit this when we add
CMP enhancements.

thanks,
suresh
-
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 5/7] radix-tree: lockless readside

[Paul E. McKenney]

On Thu, Aug 11, 2005 at 10:25:47PM +1000, Nick Piggin wrote:
> 5/7
> 
> -- 
> SUSE Labs, Novell Inc.
> 

> Make radix tree lookups safe to be performed without locks.
> Readers are protected against nodes being deleted by using RCU
> based freeing. Readers are protected against new node insertion
> by using memory barriers to ensure the node itself will be
> properly written before it is visible in the radix tree.
> 
> Also introduce a lockfree gang_lookup_slot which will be used
> by a future patch.

Interesting approach!  Don't claim to fully understand it, but
see below (search for empty lines).  In the meantime, some questions:

o   What exactly is RCU protecting?  My first guess is that
it protects the pointers and internal nodes of the
radix tree, but not the objects in the leaves of the
trees (in other words, the things pointed to by the
return value from things like radix_tree_lookup_slot()).

But if this really is the case, then the rcu_read_lock() &
rcu_read_unlock() pairs can be pushed down into
radix_tree_lookup_slot() and friends.

o   The current code structure would lead me to believe that
page_cache_get_speculative() is protected by RCU, but
I don't see the corresponding call_rcu() or synchronize_rcu()
that would cause this protection to be required.

I will expand on this in a reply to the relevant patch...

Thanx, Paul

> Index: linux-2.6/lib/radix-tree.c
> ===
> --- linux-2.6.orig/lib/radix-tree.c
> +++ linux-2.6/lib/radix-tree.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  
>  #ifdef __KERNEL__
> @@ -45,7 +46,9 @@
>   ((RADIX_TREE_MAP_SIZE + BITS_PER_LONG - 1) / BITS_PER_LONG)
>  
>  struct radix_tree_node {
> + unsigned intheight; /* Height from the bottom */
>   unsigned intcount;
> + struct rcu_head rcu_head;
>   void*slots[RADIX_TREE_MAP_SIZE];
>   unsigned long   tags[RADIX_TREE_TAGS][RADIX_TREE_TAG_LONGS];
>  };
> @@ -97,10 +100,17 @@ radix_tree_node_alloc(struct radix_tree_
>   return ret;
>  }
>  
> +static void radix_tree_node_rcu_free(struct rcu_head *head)
> +{
> + struct radix_tree_node *node =
> + container_of(head, struct radix_tree_node, rcu_head);
> + kmem_cache_free(radix_tree_node_cachep, node);
> +}
> +
>  static inline void
>  radix_tree_node_free(struct radix_tree_node *node)
>  {
> - kmem_cache_free(radix_tree_node_cachep, node);
> + call_rcu(>rcu_head, radix_tree_node_rcu_free);
>  }
>  
>  /*
> @@ -196,6 +206,7 @@ static int radix_tree_extend(struct radi
>   }
>  
>   do {
> + unsigned int newheight;
>   if (!(node = radix_tree_node_alloc(root)))
>   return -ENOMEM;
>  
> @@ -208,9 +219,13 @@ static int radix_tree_extend(struct radi
>   tag_set(node, tag, 0);
>   }
>  
> + newheight = root->height+1;
> + node->height = newheight;
>   node->count = 1;
> + /* Make ->height visible before node visible via ->rnode */

> + smp_wmb();
>   root->rnode = node;

The prior two lines should instead be:

rcu_assign_pointer(root->rnode, node);

> - root->height++;
> + root->height = newheight;
>   } while (height > root->height);
>  out:
>   return 0;
> @@ -250,9 +265,12 @@ int radix_tree_insert(struct radix_tree_
>   /* Have to add a child node.  */
>   if (!(tmp = radix_tree_node_alloc(root)))
>   return -ENOMEM;
> - *slot = tmp;
> + tmp->height = height;
>   if (node)
>   node->count++;
> + /* Make ->height visible before node visible via slot */
> + smp_wmb();
> + *slot = tmp;
>   }
>  
>   /* Go a level down */
> @@ -282,12 +300,14 @@ static inline void **__lookup_slot(struc
>   unsigned int height, shift;
>   struct radix_tree_node **slot;
>  
> - height = root->height;
> + if (root->rnode == NULL)
> + return NULL;
> + slot = >rnode;
> + height = (*slot)->height;
>   if (index > radix_tree_maxindex(height))
>   return NULL;
>  
>   shift = (height-1) * RADIX_TREE_MAP_SHIFT;
> - slot = >rnode;
>  
>   while (height > 0) {
>   if (*slot == NULL)
> @@ -491,21 +511,24 @@ EXPORT_SYMBOL(radix_tree_tag_get);
>  #endif
>  
>  static unsigned int
> -__lookup(struct radix_tree_root *root, void **results, unsigned long index,
> +__lookup(struct radix_tree_root *root, void ***results, unsigned long index,
>   unsigned int 

Re: allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task)

[Nick Piggin]

Siddha, Suresh B wrote:


On Fri, Aug 12, 2005 at 09:49:36AM +1000, Nick Piggin wrote:


Well, it is a departure from our current idea of balancing.



That idea is already changing from the first line of the patch. 
And the change is "allowing the load to grow upto the sched 
group's cpu_power"





But this is the intended behaviour of the scheduler. IMO
it was a bug in the implementation.


I would prefer to use my patch initially to fix the _bug_
you found, then we can think about changing policy for
power savings.



Second part of the patch is just a logical extension of the
first one.



Main things I'm worried about:

Idle time regressions that pop up any time we put
restrictions on balancing.



We are talking about lightly loaded case anyway. We are not changing
the behavior of a heavily loaded system.




But if the system is going idle, it _looks_ like it is lightly
loaded to the CPU scheduler. However, it is imperitive that
any spare tasks get moved to idle CPUs in order to keep things
like IO going.

It seems to be a problem with database workloads.


This can tend to unbalance memory controllers (eg. on POWER5,
CMP Opteron) which can be a performance problem on those
systems.



We will do that already with the first line in the patch. 





But that's because the tasks are already running on that CPU, and
affinity is more important in that case (especially for NUMA systems).

If we want to distribute uniformly among the memory controllers, 
cpu_power of the group should reflect it (shared resources bottle neck).





I don't mean that we want to completely distribute load evenly over
memory controllers, but I think it is better not to introduce this kind
of bias to the scheduler. At least not without some justification.


Lastly, complexity in the calculation.



My first patch is a simple straight fwd one.




It is simpler than the second, but it introduces (yet another) special
case in find_busiest_group.

I'm not saying that I would reject any patch that did this or changed
behaviour in the way that you would propose, however I would like
to merge the version I sent as a bug fix first.

Thanks,
Nick


Send instant messages to your online friends http://au.messenger.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: [PATCH/RFT 5/5] CLOCK-Pro page replacement

[Rik van Riel]

On Thu, 11 Aug 2005, Song Jiang wrote:

> My machine has 2GB memory.
> The size of the file to be scanned is 2.5GB.

> Meanwhile, Clock-Pro is supposed to do a better job, because
> part of the file can be protected in the active list and get
> a decent number of hits.

> Active:  11356 kB
> Inactive:  1994400 kB

There is an error somewhere in my implementation of Clock-Pro.

I have made some tweaks but haven't found a proper fix yet.

The problem is that if I make things too well in favor of the
evicted pages, then pages on the active list may get replaced
by pages that have the _same_ inter-reference distance, which
would result in similarly bad behaviour.

Eyeballs on vmscan.c, nonresident.c and clockpro.c would be
very much appreciated ;)

> Here is from /proc/refaults: 
> 
> Refault distance  Hits
>  0 - 32768   192
> 32768 - 65536   269
> 65536 - 98304   447
> 98304 -131072   603
>131072 -163840  1087
>163840 -196608   909
>196608 -229376   558
>229376 -262144   404
>262144 -294912   287
>294912 -327680   191
>327680 -36044879
>360448 -39321668
>393216 -42598441
>425984 -45875245
>458752 -49152031
> New/Beyond491520  2443
> 
> In the statistic, we do see many hits at the distance of around 
> 150,000 pages. If we consider the inactive list size (1.9GB), 
> this position corresponds to the file size. However, if everything
> happens as expected, all the hits should happen at the
> distance. Unfortunately, there are also many hits listed as
> New/Beyond. Because "Beyond"s should not be there, are they all
> "New"s? Futhermore, I didn't see where the refault_histogram 
> statistics get reset, though they almost stop increasing after
> the first run. Can you show me that? 

Currently the statistics never get reset.

The number of "new/beyond" sounds about right for the
startup of a fully running Linux system.

-- 
All Rights Reversed
-
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 5/8] Check input buffer size in zisofs

[Chris Wright]

* H. Peter Anvin ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> >-stable review patch.  If anyone has any  objections, please let us know.
> 
> Looks good to me.  Feel free to add:
> 
> Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>

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

[PATCH] Fix mmap_kmem (was: [question] What's the difference between /dev/kmem and /dev/mem)

[Steven Rostedt]

On Thu, 2005-08-11 at 17:36 -0400, Steven Rostedt wrote:
> OK, I thought I use to know this. But what is the difference
> between /dev/kmem and /dev/mem.  I thought that with /dev/kmem you could
> use the actual kernel addresses to read from. 
> 
> For example, if I wanted to read the current variable X in the kernel, I
> could look up the address of X in System.map, then mmaping to /dev/kmem
> I could get to that variable using the address that I got from
> System.map.  But this doesn't seem to work.
> 
> I'm getting an IO error on read. And looking at this I see:
> 
> 
> static int mmap_kmem(struct file * file, struct vm_area_struct * vma)
> {
> unsigned long long val;
>   /*
>* RED-PEN: on some architectures there is more mapped memory
>* than available in mem_map which pfn_valid checks
>* for. Perhaps should add a new macro here.
>*
>* RED-PEN: vmalloc is not supported right now.
>*/
>   if (!pfn_valid(vma->vm_pgoff))
>   return -EIO;
>   val = (u64)vma->vm_pgoff << PAGE_SHIFT;
>   vma->vm_pgoff = __pa(val) >> PAGE_SHIFT;
>   return mmap_mem(file, vma);
> }
> 
> I printed out the value in vma->vm_pgoff, and it still has the
> 0xc000 (but shifted >> 12). Isn't this suppose to also remove the
> 0xc?  Or am I just totally off here? 
> 
> Thanks,
> 
> -- Steve
> 


Found the problem.  It is a bug with mmap_kmem.  The order of checks is
wrong, so here's the patch.  Attached is a little program that reads the
System map looking for the variable modprobe_path.  If it finds it, then
it opens /dev/kmem for read only and mmaping it to read the contents of
modprobe_path.

Without this fix I get:

# ./tmap /boot/System.map
found modprobe_path at (0xc03647e0) c03647e0
mmap: Input/output error

On a machine with the patch, I now get:

# ./tmap /boot/System.map
found modprobe_path at (0xc03aa900) c03aa900
/sbin/modprobe

Note that the attached program does not handle the case of the string
crossing over a page.

-- Steve

Here's the simple patch:

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

--- linux-2.6.13-rc6-git1/drivers/char/mem.c.orig   2005-08-11 
20:48:34.0 -0400
+++ linux-2.6.13-rc6-git1/drivers/char/mem.c2005-08-11 20:48:48.0 
-0400
@@ -269,10 +269,10 @@ static int mmap_kmem(struct file * file,
 *
 * RED-PEN: vmalloc is not supported right now.
 */
-   if (!pfn_valid(vma->vm_pgoff))
-   return -EIO;
val = (u64)vma->vm_pgoff << PAGE_SHIFT;
vma->vm_pgoff = __pa(val) >> PAGE_SHIFT;
+   if (!pfn_valid(vma->vm_pgoff))
+   return -EIO;
return mmap_mem(file, vma);
 }
 

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

#include 
#include 
#include 
#include 

int page_size;
#define PAGE_SIZE page_size
#define PAGE_MASK (~(PAGE_SIZE-1))

void get_var (unsigned long addr) {
	off_t ptr = addr & ~(PAGE_MASK);
	off_t offset = addr & PAGE_MASK;
	int i = 0;
	char *map;
	static int kfd = -1;

	kfd = open("/dev/kmem",O_RDONLY);
	if (kfd < 0) {
		perror("open");
		exit(0);
	}

	map = mmap(NULL,PAGE_SIZE,PROT_READ,MAP_SHARED,kfd,offset);
	if (map == MAP_FAILED) {
		perror("mmap");
		exit(-1);
	}
	printf("%s\n",map+ptr);

	return;
}

int main(int argc, char **argv)
{
	FILE *fp;
	char addr_str[11]="0x";
	char var[51];
	unsigned long addr;
	char ch;
	int r;
	
	if (argc != 2) {
		fprintf(stderr,"usage: %s System.map\n",argv[0]);
		exit(-1);
	}

	if ((fp = fopen(argv[1],"r")) == NULL) {
		perror("fopen");
		exit(-1);
	}

	do {
		r = fscanf(fp,"%8s %c %50s\n",_str[2],,var);
		if (strcmp(var,"modprobe_path")==0)
			break;
	} while(r > 0);
	if (r < 0) {
		printf("could not find modprobe_path\n");
		exit(-1);
	}
	page_size = getpagesize();
	addr = strtoul(addr_str,NULL,16);
	printf("found modprobe_path at (%s) %08lx\n",addr_str,addr);
	get_var(addr);
}

Re: [patch 5/8] Check input buffer size in zisofs

[H. Peter Anvin]

Chris Wright wrote:

-stable review patch.  If anyone has any  objections, please let us know.


Looks good to me.  Feel free to add:

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

Re: [lm-sensors] I2C block reads with i2c-viapro: testers wanted

[Mark M. Hoffman]

Hi Jean:

* Jean Delvare <[EMAIL PROTECTED]> [2005-08-09 23:13:28 +0200]:
> I am implementing I2C block reads in the i2c-viapro driver, and am
> looking for testers. I was able to test on my own VT8237R chip, it works
> OK, now I'd need to know how it works on older VIA south bridges, namely
> the VT8235 and the VT82C686B. South bridges before that (VT82C686A,
> VT8233A and older) are supposed not to work according to the datasheets,
> but a confirmation would be welcome, who knows, it might simply not be
> documented.
> 
> My experimental patch follows. I have enabled the I2C block read
> function for all VIA south bridges, so that it can be tested on all
> chips. I'll restrict that after the test phase, of course.

I fired it up on one of the older chipsets...

# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] 
(rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x 
AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 23)
00:07.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev 11)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 30)

# lspci -n
00:00.0 Class 0600: 1106:0691 (rev c4)
00:01.0 Class 0604: 1106:8598
00:07.0 Class 0601: 1106:0596 (rev 23)
00:07.1 Class 0101: 1106:0571 (rev 10)
00:07.2 Class 0c03: 1106:3038 (rev 11)
00:07.3 Class 0600: 1106:3050 (rev 30)

As you suspected, it didn't work.

# i2cdump -y 0 0x50 i
Error: Block read failed, return code 0

> On my system, the dump is down from over 2 seconds without the patch to
> below 0.2 second with the patch, which proves how efficient I2C block
> reads are and explains why I want to implement this function.

I also found something interesting, by accident.  With a stock FC4 kernel,
the i2cdump clocked at 1.02s total.  With 2.6.13-rc6, it took 5.11s!  The
only relevant difference that I can see is that the FC4 kernel uses HZ of
1000 while my 2.6.13-rc6 kernel uses 100.  Because the i2c-viapro is a
polling driver, it becomes slower as HZ decreases.

I.e. the improvement you are seeing with byte vs. block xfers is quite
exaggerated because we poll the device relatively infrequently.  *All*
the xfers are slower than they could be w/ a non-polling driver.

Regards,

-- 
Mark M. Hoffman
[EMAIL PROTECTED]

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

Re: [RFC][2.6.12.3] IRQ compression/sharing patch

[James Cleverdon]

On Thursday 11 August 2005 02:55 pm, Protasevich, Natalie wrote:
> > After sleeping on it, maybe the original code can be patched 
> > without having to hack assign_irq_vector(), etc.  How about:
> > 
> > --- io_apic.c   2005-08-11 10:14:33.564748923 -0700
> > +++ io_apic.c.new   2005-08-11 10:15:55.412331115 -0700
> > @@ -617,7 +617,7 @@ int gsi_irq_sharing(int gsi)
> >  * than PCI.
> >  */
> > for (i = 0; i < NR_IRQS; i++)
> > -   if (IO_APIC_VECTOR(i) == vector) {
> > +   if (IO_APIC_VECTOR(i) == vector && i != gsi) {
> > if (!platform_legacy_irq(i))
> > break;  /* got one */
> > IO_APIC_VECTOR(gsi) = 0;
> > 
> > 
> Yes that did it, on my small system it looked just right:
> 
> <7>IRQ to pin mappings:
> <7>IRQ0 -> 0:2
> <7>IRQ1 -> 0:1
> <7>IRQ3 -> 0:3
> <7>IRQ4 -> 0:4
> <7>IRQ5 -> 0:5
> <7>IRQ6 -> 0:6
> <7>IRQ7 -> 0:7
> <7>IRQ8 -> 0:8
> <7>IRQ9 -> 0:9
> <7>IRQ10 -> 0:10
> <7>IRQ11 -> 0:11
> <7>IRQ12 -> 0:12
> <7>IRQ14 -> 0:14
> <7>IRQ15 -> 0:15
> <7>IRQ16 -> 0:16
> <7>IRQ17 -> 0:17
> <7>IRQ18 -> 0:18
> <7>IRQ19 -> 0:19
> <7>IRQ20 -> 0:20
> <7>IRQ21 -> 0:23
> <7>IRQ22 -> 1:2
> <7>IRQ23 -> 1:3
> <7>IRQ24 -> 1:4
> <7>IRQ25 -> 1:5
> <7>IRQ26 -> 2:0
> <7>IRQ27 -> 2:1
> <7>IRQ28 -> 2:2
> <7>IRQ29 -> 2:3
> <7>IRQ30 -> 2:4
> <7>IRQ31 -> 2:5
> <7>IRQ32 -> 2:6
> <7>IRQ33 -> 2:7
> <7>IRQ34 -> 2:8
> :!cat /proc/interrupts
>CPU0   CPU1   CPU2   CPU3
>   0:  12621  15007  12781  20921IO-APIC-edge  timer
>   1: 72  0  2175IO-APIC-edge  i8042
>   2:  0  0  0  0  XT-PIC
> cascade
>   8:  0  0  0  1IO-APIC-edge  rtc
>   9:  0  0  0  0IO-APIC-edge  acpi
>  12:  4272  0110IO-APIC-edge  i8042
>  15:  4  0  0 39IO-APIC-edge  ide1
>  16:  0  0  0  0   IO-APIC-level
> uhci_hcd:usb1, uhci_hcd:usb4
>  17:  0  0  0  2   IO-APIC-level
> ohci1394
>  18:730   2407932   2083   IO-APIC-level
> libata, uhci_hcd:usb3
>  19:  0  0  0  0   IO-APIC-level
> uhci_hcd:usb2
>  21:  0  0  0  0   IO-APIC-level
> ehci_hcd:usb5
>  26:416  0  0  4   IO-APIC-level  eth0
> NMI:116 71 73 51
> LOC:  61280  61258  61236  61214
> ERR:  3
> MIS:  0
> 
> Looks good! I will try the patch also on the ES7000 hopefully big enough
> to exercise some vector sharing.
> 
> Regards,
> --Natalie


No, my quick fix still has some enumeration problems.  Suppose
gsi_irq_sharing has already handed out IRQ 16, then it is called with
GSI 16?  We'd call assign_irq_vector(16), which would clobber
irq_vector[16].  Not good.  We need to avoid assign_irq_vector's
habit of storing the vector in irq_vector until we commit to a
particular IRQ number.

Here's a quick and ugly kludge:

--- 2.6.12.3/arch/x86_64/kernel/io_apic.c   2005-07-15 14:18:57.0 
-0700
+++ z12.3/arch/x86_64/kernel/io_apic.c  2005-08-11 17:15:39.0 -0700
@@ -581,6 +586,69 @@ static inline int irq_trigger(int idx)
return MPBIOS_trigger(idx);
 }
 
+static int next_irq = 16;
+
+/*
+ * gsi_irq_sharing -- Name overload!  "irq" can be either a legacy IRQ
+ * in the range 0-15, a linux IRQ in the range 0-223, or a GSI number
+ * from ACPI, which can reach 800 in large boxen.
+ *
+ * Compact the sparse GSI space into a sequential IRQ series and reuse
+ * vectors if possible.
+ */
+int gsi_irq_sharing(int gsi)
+{
+   int i, tries, vector;
+   u8 saved_vector;
+
+   BUG_ON(gsi >= NR_IRQ_VECTORS);
+
+   if (platform_legacy_irq(gsi)) {
+   gsi_2_irq[gsi] = gsi;
+   return gsi;
+   }
+
+   if (gsi_2_irq[gsi] != 0xFF)
+   return (int)gsi_2_irq[gsi];
+
+   tries = NR_IRQS;
+  try_again:
+   saved_vector = IO_APIC_VECTOR(gsi); /* Kludge:  Need to make 
assign_irq_vector not always store vector in irq_vector */
+   vector = assign_irq_vector(gsi);
+   IO_APIC_VECTOR(gsi) = saved_vector; /* Rest of Kludge */
+
+   /*
+* Sharing vectors means sharing IRQs, so scan irq_vectors for previous
+* use of vector and if found, return that IRQ.  However, we never want
+* to share legacy IRQs, which usually have a different trigger mode
+* than PCI.
+*/
+   for (i = 0; i < NR_IRQS; i++)
+   if (IO_APIC_VECTOR(i) == vector)
+   break;
+   if (platform_legacy_irq(i)) {
+   if (--tries >= 0) {
+   IO_APIC_VECTOR(i) = 0;
+   goto try_again;
+   }
+   

suspect code in drivers/char/agp/generic.c

[Jeremy Fitzhardinge]

I was just looking at agp_copy_info(), which contains this code:

   318  if (bridge->mode & AGPSTAT_MODE_3_0)
   319  info->mode = bridge->mode & ~AGP3_RESERVED_MASK;
   320  else
   321  info->mode = bridge->mode & ~AGP2_RESERVED_MASK;
   322  info->mode = bridge->mode;

This looks wrong to me, since line 322 overrides the previous 4 lines'
work...

I have no idea whether this is actually causing a problem, but I'd
thought I'd call attention to it.

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

Re: [-mm patch] DLM must depend on IPV6 || IPV6=n

[Adrian Bunk]

On Tue, Aug 09, 2005 at 05:58:27PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2005-08-09 17:50:01 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > This patch fixes the following compile error with CONFIG_DLM=y and 
> > CONFIG_IPV6=m:
> 
> [...]
> 
> > --- linux-2.6.13-rc3-mm3-modular/drivers/dlm/Kconfig.old2005-07-30 
> > 14:07:12.0 +0200
> > +++ linux-2.6.13-rc3-mm3-modular/drivers/dlm/Kconfig2005-07-30 
> > 14:07:41.0 +0200
> > @@ -3,6 +3,7 @@
> >  
> >  config DLM
> > tristate "Distributed Lock Manager (DLM)"
> > +   depends on IPV6 || IPV6=n
> > select IP_SCTP
> > help
> > A general purpose distributed lock manager for kernel or userspace
> 
> Why don't you allow modular builds of both? ...or aren't the IPv6
> symbols exported?

Modular builds of both are supported.

CONFIG_DLM=y and CONFIG_IPV6=m is the evil combination since
CONFIG_IP_SCTP=y and CONFIG_IPV6=m doesn't compile.

> MfG, JBG

cu
Adrian

BTW: Please don't strip people from replies.

-- 

   "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: VGER news

[Willy Tarreau]

On Tue, Aug 09, 2005 at 05:12:17PM +0300, Matti Aarnio wrote:
> Folks at Dell have donated a new machine to be VGER, and
> folks at RedHat have installed it into co-location facility
> with 1000Mbps network connection into the machine.
> 
> This update got considerable performance increase into the
> machine for our list loads.  In terms of Bogomips around 7-8,
> but for actual loads nearly twice as much.
> 
> We did system switchover last weekend, and nobody reacted trulu
> adversely.Probably nobody noticed it either.   :-)

OK, I better understand now why the message I posted this morning
from mutt on tty1 was already caught by the other mutt when I switched
to tty2 to check other messages on the list. I can imagine that from
now, we'll get a very good interactivity again.

Thanks,
Willy

-
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: allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task)

[Siddha, Suresh B]

On Fri, Aug 12, 2005 at 09:49:36AM +1000, Nick Piggin wrote:
> Well, it is a departure from our current idea of balancing.

That idea is already changing from the first line of the patch. 
And the change is "allowing the load to grow upto the sched 
group's cpu_power"

> I would prefer to use my patch initially to fix the _bug_
> you found, then we can think about changing policy for
> power savings.

Second part of the patch is just a logical extension of the
first one.

> 
> Main things I'm worried about:
> 
> Idle time regressions that pop up any time we put
> restrictions on balancing.

We are talking about lightly loaded case anyway. We are not changing
the behavior of a heavily loaded system.

> 
> This can tend to unbalance memory controllers (eg. on POWER5,
> CMP Opteron) which can be a performance problem on those
> systems.

We will do that already with the first line in the patch. 

If we want to distribute uniformly among the memory controllers, 
cpu_power of the group should reflect it (shared resources bottle neck).

> Lastly, complexity in the calculation.

My first patch is a simple straight fwd one.

thanks,
suresh
-
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 4/8] [PATCH] Update in-kernel zlib routines

[Chris Wright]

* Peter Osterlund ([EMAIL PROTECTED]) wrote:
> Chris Wright <[EMAIL PROTECTED]> writes:
> > a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
> 
> Why does this 6 year old bug have to be fixed in the 2.6.12 stable
> series? Doesn't the patch violate this stable series rule?
> 
>  - It must fix a real bug that bothers people (not a, "This could be a
>problem..." type thing.)
> 
> Maybe the motivation was just missing from the patch description?

These can manifest as possible overflow (1st one, given CAN-2005-2458),
or NULL deref (2nd one given CAN-2005-2459), which could have possible
security consequences.

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

Re: [patch 4/8] [PATCH] Update in-kernel zlib routines

[Peter Osterlund]

Chris Wright <[EMAIL PROTECTED]> writes:

> -stable review patch.  If anyone has any  objections, please let us know.
> --
> 
> a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html

Why does this 6 year old bug have to be fixed in the 2.6.12 stable
series? Doesn't the patch violate this stable series rule?

 - It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing.)

Maybe the motivation was just missing from the patch description?

-- 
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
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: allow the load to grow upto its cpu_power (was Re: [Patch] don't kick ALB in the presence of pinned task)

[Nick Piggin]

Siddha, Suresh B wrote:

On Thu, Aug 11, 2005 at 01:09:10PM +1000, Nick Piggin wrote:


I have a variation on the 2nd part of your patch which I think
I would prefer. IMO it kind of generalises the current imbalance
calculation to handle this case rather than introducing a new
special case.



There is a difference between our changes. 

When the system is lightly loaded, my patch minimizes the number of 
groups picking up that load. This will help in power savings for 
example in the context of CMP. There are more changes required
(user or kernel) for complete power savings, but this is a direction 
towards that.


How about this patch?


Well, it is a departure from our current idea of balancing.
I would prefer to use my patch initially to fix the _bug_
you found, then we can think about changing policy for
power savings.

Main things I'm worried about:

Idle time regressions that pop up any time we put
restrictions on balancing.

This can tend to unbalance memory controllers (eg. on POWER5,
CMP Opteron) which can be a performance problem on those
systems.

Lastly, complexity in the calculation.

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.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: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Bjorn Helgaas wrote:

You deduce this by the absence of SecO and PriO?  I wonder if lspci
should be enhanced to notice this, too.  I assume that the IRQ 169
doesn't correspond to anything in /proc/interrupts.


Correct.



So the scenario in question (correct me if I'm wrong) is that we
have a PCI IDE device that is handed off in compatibility mode (and
may only work in that mode).  In that case, the PCI *device* still
exists, so shouldn't the IDE PCI code claim that device, notice that
it's in compatibility mode, and use the legacy ports and IRQs if
necessary?

It seems like that all should work even if we don't have IDE_GENERIC.


Yes, you're right.  Thinking more, the PCI IDE code should pick that up, 
not the IDE_GENERIC code.


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: Is it possible to control C.O.P

[Robert Hancock]

Luigi Genoni wrote:

HI,
there is a way that the kernel could cope with CPU Overheating Protection?

I am usng a Tyan MPX with Dual AthlonMP, but COP is configured to shutdown
the system toot early, when the temparature is still low.


I'm guessing this is controlled by the BIOS and handled by hardware, so 
I don't know that there's much the kernel can do about it. Is there a 
threshold temperature setting in the BIOS?


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

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

Re: [patch 3/8] [PATCH] x86_64: Fixing smpboot timing problem

[Chris Wright]

* Andi Kleen ([EMAIL PROTECTED]) wrote:
> >  static void __cpuinit tsc_sync_wait(void)
> >  {
> > if (notscsync || !cpu_has_tsc)
> > return;
> > -   printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> > -   boot_cpu_id);
> > -   sync_tsc();
> > +   sync_tsc(boot_cpu_id);
> 
> I actually found a bug in this today. This should be sync_tsc(0), not 
> sync_tsc(boot_cpu_id)
> Can you just fix it in your tree or should I submit a new patch? 

I'll fix it locally.  Thanks for the heads-up.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Via-Rhine NIC, Via SATA or reiserfs broken, how to tell??

[Grant Coady]

Greetings,

Situation is dataloss with no errors logged.

Test: unpack 2.6.12 tarball from NFS mount source, diff against 
previous attempt:

$ diff -Nrup linux-2.6.12.old linux-2.6.12
Binary files linux-2.6.12.old/include/asm-sparc/a.out.h and 
linux-2.6.12/include/asm-sparc/a.out.h differ
diff -Nrup linux-2.6.12.old/include/asm-sparc/apc.h 
linux-2.6.12/include/asm-sparc/apc.h
--- linux-2.6.12.old/include/asm-sparc/apc.h2005-06-18 05:48:29.0 
+1000
+++ linux-2.6.12/include/asm-sparc/apc.h2005-06-18 05:48:29.0 
+1000
@@ -31,7 +31,7 @@
 #define APC_BPORT_REG  0x30

 #define APC_REGMASK0x01
-define APC_BPMASK  0x03
+#define APC_BPMASK 0x03

 /*
  * IDLE - CPU standby values (set to initiate standby)
diff -Nrup linux-2.6.12.old/include/asm-sparc/svr4.h 
linux-2.6.12/include/asm-sparc/svr4.h
--- linux-2.6.12.old/include/asm-sparc/svr4.h   2005-06-18 05:48:29.0 
+1000
+++ linux-2.6.12/include/asm-sparc/svr4.h   2005-06-18 05:48:29.0 
+1000
@@ -15,7 +15,7 @@ typedef struct {/* signa

 /* Values for siginfo.code */
 #define SVR4_SINOINFO 32767
-/* Siginfo, sucker expects bunch of information on those paramEters */
+/* Siginfo, sucker expects bunch of information on those parameters */
 typedef union {
char total_size [128];
struct {


Seems like three bit errors for source tree.  Other times I've noted 
compile failures where unpacking source tree fresh would 'fix' error.
I'd previously assumed that I accidentally killed source tree with 
'cp -al ...' copies but I've had a segfault on that operation, hence 
I do not know if this be NIC or filesystem (reiserfs on via SATA).


Today disabled onboard via-rhine and used Intel pro/100 + e100 driver, 
several source trees unpacked identically, running 2.6.12.4 or 2.4.31-hf3

The fault occurs on 2.4 latest or 2.6 latest only on particular target 
box, so problem is not the NFS server.

How to test and isolate this error is in NIC driver, SATA driver or 
filesystem?  

Thanks,
Grant.

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

[Announce] sg3_utils-1.16 available

[Douglas Gilbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

sg3_utils is a package of command line utilities for sending
SCSI commands to devices. This package targets the lk 2.6 and
lk 2.4 series. In the lk 2.6 series these utilities (except
sgp_dd) can be used with any devices that support the SG_IO
ioctl.

This version adds sg_ident to report and set device identifiers.
It extends various device scanning utilities beyond 256 device
and includes bug fixes and man page improvements. See CHANGELOG
for more information.

A tarball, rpm and deb can be found on (see table 2):
http://www.torque.net/sg
For an overview of sg3_utils see this page:
http://www.torque.net/sg/u_index.html
The sg_dd utility has its own page at:
http://www.torque.net/sg/sg_dd.html
A changelog can be found at:
http://www.torque.net/sg/p/sg3_utils.CHANGELOG

A release announcement has been sent to freshmeat.net .

Doug Gilbert

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC++Eknayo+9E+FQIRAgQSAKCL7EirWTNuvvF3uqdN4OgnQr2bdwCdE/gY
sq8wzUyPkd/vPr1Xc8+T+Es=
=NU4B
-END PGP SIGNATURE-
-
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 3/8] [PATCH] x86_64: Fixing smpboot timing problem

[Andi Kleen]

>  static void __cpuinit tsc_sync_wait(void)
>  {
>   if (notscsync || !cpu_has_tsc)
>   return;
> - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> - boot_cpu_id);
> - sync_tsc();
> + sync_tsc(boot_cpu_id);

I actually found a bug in this today. This should be sync_tsc(0), not 
sync_tsc(boot_cpu_id)
Can you just fix it in your tree or should I submit a new patch? 

-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: Need help in understanding x86 syscall

[Bodo Eggert]

On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:

> > According to my documentation it isn't. A software interrupt is a far call
> > with an extra pushf, and a hardware interrupt is protected against recursion
> > by the PIC, not by an interrupt flag.
> 
> I disagree with your definition of a system call.  The "int 0x80"
> changes from user mode to kernel mode so it is much more powerful than a
> "far call".

Far calls and jumps can change to a inner ring. This is done by a special
segment selector containing the segment _and_ the offset to jump to (the
offset from the call instruction is ignored).

>  Also the CPU does protect against recursion and more than
> one interrupt coming in at the same time. The PIC also works with the
> CPU in this regard, but as I shown in my previous email, the interrupt
> flag _does_ protect against it.

Showing == claiming? However, my documentation was wrong.

http://www.baldwin.cx/386htm/INT.htm
-- 
Top 100 things you don't want the sysadmin to say:
99. Shit!!
-
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] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Thursday 11 August 2005 3:56 pm, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE 
> > Controller 
> > (rev 02) (prog-if 8a [Master SecP PriP])
> > Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> > Step
> > ping- SERR- FastB2B-
> > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> >  > - SERR-  > Latency: 0
> > Interrupt: pin A routed to IRQ 169
> > Region 0: I/O ports at 
> > Region 1: I/O ports at 
> > Region 2: I/O ports at 
> > Region 3: I/O ports at 
> > Region 4: I/O ports at 14c0 [size=16]
> > Region 5: Memory at 4000 (32-bit, non-prefetchable) [size=1K]
> > 
> > Trust me, IDE on PCI is still quite weird.
> 
> The above configuration also indicates that the IRQs for the PCI device 
> are 14 and 15, _not_ 169.

You deduce this by the absence of SecO and PriO?  I wonder if lspci
should be enhanced to notice this, too.  I assume that the IRQ 169
doesn't correspond to anything in /proc/interrupts.

So the scenario in question (correct me if I'm wrong) is that we
have a PCI IDE device that is handed off in compatibility mode (and
may only work in that mode).  In that case, the PCI *device* still
exists, so shouldn't the IDE PCI code claim that device, notice that
it's in compatibility mode, and use the legacy ports and IRQs if
necessary?

It seems like that all should work even if we don't have IDE_GENERIC.
-
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] IDE: don't offer IDE_GENERIC on ia64

[Jack Steiner]

(resend with correct cc list).

On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> around in I/O port space.  Poking at things that don't exist causes MCAs
> on HP ia64 systems.

 H, can you change the test so that IDE_GENERIC is off by default but
 can still be enabled on IA64. We use the generic IDE driver in our
 simulator environment - yes, it really works.

 Longer term, I'll see if it is feasible to switch to using a PCI device.

> 
> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
> 
> Index: work-vga/drivers/ide/Kconfig
> ===
> --- work-vga.orig/drivers/ide/Kconfig 2005-08-10 14:57:47.0 -0600
> +++ work-vga/drivers/ide/Kconfig  2005-08-10 14:58:02.0 -0600
> @@ -276,6 +276,7 @@
>  
>  config IDE_GENERIC
>   tristate "generic/default IDE chipset support"
> + depends on !IA64
>   default y
>   help
> If unsure, say Y.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Thanks

Jack Steiner ([EMAIL PROTECTED])  651-683-5302
Principal Engineer  SGI - Silicon Graphics, Inc.


-
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/8] CAN-2005-2099 Destruction of failed keyring oopses

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--

properly is destroyed without oopsing [CAN-2005-2099].

The problem occurs in three stages:

 (1) The key allocator initialises the type-specific data to all zeroes. In
 the case of a keyring, this will become a link in the keyring name list
 when the keyring is instantiated.

 (2) If a user (any user) attempts to add a keyring with anything other than
 an empty payload, the keyring instantiation function will fail with an
 error and won't add the keyring to the name list.

 (3) The keyring's destructor then sees that the keyring has a description
 (name) and tries to remove the keyring from the name list, which oopses
 because the link pointers are both zero.

This bug permits any user to take down a box trivially.

Signed-Off-By: David Howells <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 security/keys/keyring.c |6 +-
 1 files changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.12.y/security/keys/keyring.c
===
--- linux-2.6.12.y.orig/security/keys/keyring.c
+++ linux-2.6.12.y/security/keys/keyring.c
@@ -188,7 +188,11 @@ static void keyring_destroy(struct key *
 
if (keyring->description) {
write_lock(_name_lock);
-   list_del(>type_data.link);
+
+   if (keyring->type_data.link.next != NULL &&
+   !list_empty(>type_data.link))
+   list_del(>type_data.link);
+
write_unlock(_name_lock);
}
 

--
-
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 6/8] CAN-2005-2098 Error during attempt to join key management session can leave semaphore pinned

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--

from hanging future joins in the D state [CAN-2005-2098].

The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING
operation has one error path that doesn't release the session management
semaphore. Further attempts to get the semaphore will then sleep for ever in
the D state.

This can happen in four situations, all involving an attempt to allocate a new
session keyring:

 (1) ENOMEM.

 (2) The users key quota being reached.

 (3) A keyring name that is an empty string.

 (4) A keyring name that is too long.

Any user may attempt this operation, and so any user can cause the problem to
occur.

Signed-Off-By: David Howells <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 security/keys/process_keys.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.12.y/security/keys/process_keys.c
===
--- linux-2.6.12.y.orig/security/keys/process_keys.c
+++ linux-2.6.12.y/security/keys/process_keys.c
@@ -641,7 +641,7 @@ long join_session_keyring(const char *na
keyring = keyring_alloc(name, tsk->uid, tsk->gid, 0, NULL);
if (IS_ERR(keyring)) {
ret = PTR_ERR(keyring);
-   goto error;
+   goto error2;
}
}
else if (IS_ERR(keyring)) {

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

[patch 4/8] [PATCH] Update in-kernel zlib routines

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--


a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
b) http://bugs.gentoo.org/show_bug.cgi?id=94584

Signed-off-by: Tim Yamin <[EMAIL PROTECTED]>
Signed-off-by: Tavis Ormandy <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 arch/ppc64/boot/zlib.c  |3 ++-
 lib/inflate.c   |   16 +---
 lib/zlib_inflate/inftrees.c |2 +-
 3 files changed, 12 insertions(+), 9 deletions(-)

Index: linux-2.6.12.y/lib/inflate.c
===
--- linux-2.6.12.y.orig/lib/inflate.c
+++ linux-2.6.12.y/lib/inflate.c
@@ -326,7 +326,7 @@ DEBG("huft1 ");
   {
 *t = (struct huft *)NULL;
 *m = 0;
-return 0;
+return 2;
   }
 
 DEBG("huft2 ");
@@ -374,6 +374,7 @@ DEBG("huft5 ");
 if ((j = *p++) != 0)
   v[x[j]++] = i;
   } while (++i < n);
+  n = x[g];   /* set n to length of v */
 
 DEBG("h6 ");
 
@@ -410,12 +411,13 @@ DEBG1("1 ");
 DEBG1("2 ");
   f -= a + 1;   /* deduct codes from patterns left */
   xp = c + k;
-  while (++j < z)   /* try smaller tables up to z bits */
-  {
-if ((f <<= 1) <= *++xp)
-  break;/* enough codes to use up j bits */
-f -= *xp;   /* else deduct codes from patterns */
-  }
+  if (j < z)
+while (++j < z)   /* try smaller tables up to z bits */
+{
+  if ((f <<= 1) <= *++xp)
+break;/* enough codes to use up j bits */
+  f -= *xp;   /* else deduct codes from patterns */
+}
 }
 DEBG1("3 ");
 z = 1 << j; /* table entries for j-bit table */
Index: linux-2.6.12.y/lib/zlib_inflate/inftrees.c
===
--- linux-2.6.12.y.orig/lib/zlib_inflate/inftrees.c
+++ linux-2.6.12.y/lib/zlib_inflate/inftrees.c
@@ -141,7 +141,7 @@ static int huft_build(
   {
 *t = NULL;
 *m = 0;
-return Z_OK;
+return Z_DATA_ERROR;
   }
 
 
Index: linux-2.6.12.y/arch/ppc64/boot/zlib.c
===
--- linux-2.6.12.y.orig/arch/ppc64/boot/zlib.c
+++ linux-2.6.12.y/arch/ppc64/boot/zlib.c
@@ -1307,7 +1307,7 @@ local int huft_build(
   {
 *t = (inflate_huft *)Z_NULL;
 *m = 0;
-return Z_OK;
+return Z_DATA_ERROR;
   }
 
 
@@ -1351,6 +1351,7 @@ local int huft_build(
 if ((j = *p++) != 0)
   v[x[j]++] = i;
   } while (++i < n);
+  n = x[g];/* set n to length of v */
 
 
   /* Generate the Huffman codes and for each, make the table entries */

--
-
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] Stacker - single-use static slots

[James Morris]

On Thu, 11 Aug 2005, [EMAIL PROTECTED] wrote:

> I guess I should do some profiling runs - I'm surprised there would be
> this much of a hit with the static slots.

Yes.  It could be some cache effect, where the exact placement of the 
SELinux pointer might be critical, and also vary depending on the hook and 
subclass of SELinux security struct.

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

[patch 5/8] Check input buffer size in zisofs

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--


It's not the real deflateBound() in newer zlib libraries, partly because
the upcoming usage of it won't have the "stream" available, so we can't
have the same interfaces anyway.

This uses the new deflateBound() thing to sanity-check the input to the
zlib decompressor before we even bother to start reading in the blocks.

Problem noted by Tim Yamin <[EMAIL PROTECTED]>

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 fs/isofs/compress.c  |6 ++
 include/linux/zlib.h |5 +
 2 files changed, 11 insertions(+)

Index: linux-2.6.12.y/include/linux/zlib.h
===
--- linux-2.6.12.y.orig/include/linux/zlib.h
+++ linux-2.6.12.y/include/linux/zlib.h
@@ -506,6 +506,11 @@ extern int zlib_deflateReset (z_streamp 
stream state was inconsistent (such as zalloc or state being NULL).
 */
 
+static inline unsigned long deflateBound(unsigned long s)
+{
+   return s + ((s + 7) >> 3) + ((s + 63) >> 6) + 11;
+}
+
 extern int zlib_deflateParams (z_streamp strm, int level, int strategy);
 /*
  Dynamically update the compression level and compression strategy.  The
Index: linux-2.6.12.y/fs/isofs/compress.c
===
--- linux-2.6.12.y.orig/fs/isofs/compress.c
+++ linux-2.6.12.y/fs/isofs/compress.c
@@ -129,8 +129,14 @@ static int zisofs_readpage(struct file *
cend = le32_to_cpu(*(__le32 *)(bh->b_data + (blockendptr & bufmask)));
brelse(bh);
 
+   if (cstart > cend)
+   goto eio;
+   
csize = cend-cstart;
 
+   if (csize > deflateBound(1UL << zisofs_block_shift))
+   goto eio;
+
/* Now page[] contains an array of pages, any of which can be NULL,
   and the locks on which we hold.  We should now read the data and
   release the pages.  If the pages are NULL the decompressed data

--
-
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/8] [PATCH] Module per-cpu alignment cannot always be met

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--


The module code assumes noone will ever ask for a per-cpu area more than
SMP_CACHE_BYTES aligned.  However, as these cases show, gcc asks sometimes
asks for 32-byte alignment for the per-cpu section on a module, and if
CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON().  This is obviously an
unusual combination, as there have been few reports, but better to warn
than die.

See:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html
  
And more recently:
http://bugs.gentoo.org/show_bug.cgi?id=97006
  
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 kernel/module.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

Index: linux-2.6.12.y/kernel/module.c
===
--- linux-2.6.12.y.orig/kernel/module.c
+++ linux-2.6.12.y/kernel/module.c
@@ -249,13 +249,18 @@ static inline unsigned int block_size(in
 /* Created by linker magic */
 extern char __per_cpu_start[], __per_cpu_end[];
 
-static void *percpu_modalloc(unsigned long size, unsigned long align)
+static void *percpu_modalloc(unsigned long size, unsigned long align,
+const char *name)
 {
unsigned long extra;
unsigned int i;
void *ptr;
 
-   BUG_ON(align > SMP_CACHE_BYTES);
+   if (align > SMP_CACHE_BYTES) {
+   printk(KERN_WARNING "%s: per-cpu alignment %li > %i\n",
+  name, align, SMP_CACHE_BYTES);
+   align = SMP_CACHE_BYTES;
+   }
 
ptr = __per_cpu_start;
for (i = 0; i < pcpu_num_used; ptr += block_size(pcpu_size[i]), i++) {
@@ -347,7 +352,8 @@ static int percpu_modinit(void)
 }  
 __initcall(percpu_modinit);
 #else /* ... !CONFIG_SMP */
-static inline void *percpu_modalloc(unsigned long size, unsigned long align)
+static inline void *percpu_modalloc(unsigned long size, unsigned long align,
+   const char *name)
 {
return NULL;
 }
@@ -1554,7 +1560,8 @@ static struct module *load_module(void _
if (pcpuindex) {
/* We have a special allocation for this section. */
percpu = percpu_modalloc(sechdrs[pcpuindex].sh_size,
-sechdrs[pcpuindex].sh_addralign);
+sechdrs[pcpuindex].sh_addralign,
+mod->name);
if (!percpu) {
err = -ENOMEM;
goto free_mod;

--
-
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] IDE: don't offer IDE_GENERIC on ia64

[Jack Steiner]

On Thu, Aug 11, 2005 at 03:42:07PM -0600, Bjorn Helgaas wrote:
> On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> > Bjorn Helgaas wrote:
> > > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> > >>Bjorn Helgaas wrote:
> > >>> config IDE_GENERIC
> > >>> tristate "generic/default IDE chipset support"
> > >>>+depends on !IA64
> > >>
> > >>hm.  Are you POSITIVE that the legacy IDE ports are never enabled?
> > >>
> > >>In modern Intel chipsets, this still occurs with e.g. combined mode.
> > > 
> > > I don't know about combined mode.  If the legacy IDE ports are
> > > enabled, shouldn't they be described via ACPI, and hence usable
> > > via the ide_pnp - PNPACPI - ACPI path?
> > 
> > No idea...  that's more for platform IA64 people to answer :/
> 
> OK, well, I assert that failure to describe an IDE device that
> uses legacy ports would be an ACPI defect.
> 
> Tony, others, does this change give you any heartburn?  On
> the 460GX and 870 boxes I have, IDE is a PCI device.
> 
> (I have been told that the SGI ia64 simulator depends on
> IDE_GENERIC.  But it really should make the IDE device
> appear in PCI (or describe it via ACPI)).

Yes - we use IDE_GENERIC for the simulator. ACPI at this point is not an option
for us because (unfortunately) SN is not ACPI compliant. We plan additional
ACPI support in the future but it will take a while to get there.

I'm checking to see if we have any short term alternatives. More later


-- 
Thanks

Jack Steiner ([EMAIL PROTECTED])  651-683-5302
Principal Engineer  SGI - Silicon Graphics, Inc.


-
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/8] [PATCH] Fix SRAT for non dual core AMD systems

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--


This fixes a bug in SRAT handling on AMD systems that was introduced
with the dual core support. It would be disabled on CPUs without dual core.
Just drop the bogus check.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

Index: linux-2.6.12/arch/x86_64/kernel/setup.c
===
--- linux-2.6.12.orig/arch/x86_64/kernel/setup.c
+++ linux-2.6.12/arch/x86_64/kernel/setup.c
@@ -729,8 +729,6 @@ static void __init amd_detect_cmp(struct
int cpu = smp_processor_id();
int node = 0;
unsigned bits;
-   if (c->x86_num_cores == 1)
-   return;
 
bits = 0;
while ((1 << bits) < c->x86_num_cores)

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

[patch 0/8] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.12.5 release.
There are 8 patches in this series, all will be posted as a response to
this one.  If anyone has any issues with these being applied, please let
us know.  If anyone is a maintainer of the proper subsystem, and wants
to add a signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the
Cc: line.  If you wish to be a reviewer, please email [EMAIL PROTECTED]
to add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Sat, Aug 13, 22:00 UTC.  Anything received
after that time, might be too late.

thanks,

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

[patch 1/8] [PATCH] sys_set_mempolicy() doesnt check if mode < 0

[Chris Wright]

-stable review patch.  If anyone has any  objections, please let us know.
--


A kernel BUG() is triggered by a call to set_mempolicy() with a negative
first argument.  This is because the mode is declared as an int, and the
validity check doesnt check < 0 values.  Alternatively, mode could be
declared as unsigned int or unsigned long.

Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 mm/mempolicy.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.12.y/mm/mempolicy.c
===
--- linux-2.6.12.y.orig/mm/mempolicy.c
+++ linux-2.6.12.y/mm/mempolicy.c
@@ -409,7 +409,7 @@ asmlinkage long sys_set_mempolicy(int mo
struct mempolicy *new;
DECLARE_BITMAP(nodes, MAX_NUMNODES);
 
-   if (mode > MPOL_MAX)
+   if (mode < 0 || mode > MPOL_MAX)
return -EINVAL;
err = get_nodes(nodes, nmask, maxnode, mode);
if (err)

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

Re: Problem with usb-storage and /dev/sd?

[Horst von Brand]

DervishD <[EMAIL PROTECTED]> wrote:
>  * Pete Zaitcev <[EMAIL PROTECTED]> dixit:
> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <[EMAIL PROTECTED]> wrote:
> > > I'm not using hotplug currently so... how can I make the USB
> > > subsystem to assign always the same /dev/sd? entry to my USB Mass
> > > storage devices? [...]
> > You cannot. Just mount by label or something...

> Mounting by label won't work, the problem is the /dev entry,
> which changes every time.

That's why you should mount by label...

> > Better yet, install something like Fedora Core 4, which uses HAL,
> > and forget about it. The fstab-sync takes care of the rest.
> 
> Oh no, thanks, I've already used Fedora and it only reinforced my
> feeling about distros: I prefer my do-it-yourself box ;)

In Fedora rawhide it just works. I can't see how the knot you are tying
yourself into by diy is any better...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] sparsemem extreme: hotplug preparation

[Dave Hansen]

This splits up sparse_index_alloc() into two pieces.  This is needed
because we'll allocate the memory for the second level in a different
place from where we actually consume it to keep the allocation from
happening underneath a lock

Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---

 memhotplug-dave/include/linux/mmzone.h |1 
 memhotplug-dave/mm/sparse.c|   52 -
 2 files changed, 40 insertions(+), 13 deletions(-)

diff -puN mm/sparse.c~A6-extreme-hotplug-prepare mm/sparse.c
--- memhotplug/mm/sparse.c~A6-extreme-hotplug-prepare   2005-08-11 
15:46:18.0 -0700
+++ memhotplug-dave/mm/sparse.c 2005-08-11 15:46:18.0 -0700
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -22,27 +23,52 @@ struct mem_section mem_section[NR_SECTIO
 #endif
 EXPORT_SYMBOL(mem_section);
 
-static void sparse_alloc_root(unsigned long root, int nid)
-{
 #ifdef CONFIG_SPARSEMEM_EXTREME
-   mem_section[root] = alloc_bootmem_node(NODE_DATA(nid), PAGE_SIZE);
-#endif
+static struct mem_section *sparse_index_alloc(int nid)
+{
+   struct mem_section *section = NULL;
+   unsigned long array_size = SECTIONS_PER_ROOT *
+  sizeof(struct mem_section);
+
+   section = alloc_bootmem_node(NODE_DATA(nid), array_size);
+
+   if (section)
+   memset(section, 0, array_size);
+
+   return section;
 }
 
-static void sparse_index_init(unsigned long section, int nid)
+static int sparse_index_init(unsigned long section_nr, int nid)
 {
-   unsigned long root = SECTION_NR_TO_ROOT(section);
+   static spinlock_t index_init_lock = SPIN_LOCK_UNLOCKED;
+   unsigned long root = SECTION_NR_TO_ROOT(section_nr);
+   struct mem_section *section;
+   int ret = 0;
 
-   if (mem_section[root])
-   return;
+   section = sparse_index_alloc(nid);
+   /*
+* This lock keeps two different sections from
+* reallocating for the same index
+*/
+   spin_lock(_init_lock);
 
-   sparse_alloc_root(root, nid);
+   if (mem_section[root]) {
+   ret = -EEXIST;
+   goto out;
+   }
 
-   if (mem_section[root])
-   memset(mem_section[root], 0, PAGE_SIZE);
-   else
-   panic("memory_present: NO MEMORY\n");
+   mem_section[root] = section;
+out:
+   spin_unlock(_init_lock);
+   return ret;
+}
+#else /* !SPARSEMEM_EXTREME */
+static inline int sparse_index_init(unsigned long section_nr, int nid)
+{
+   return 0;
 }
+#endif
+
 /* Record a memory area against a node. */
 void memory_present(int nid, unsigned long start, unsigned long end)
 {
diff -puN include/linux/mmzone.h~A6-extreme-hotplug-prepare 
include/linux/mmzone.h
--- memhotplug/include/linux/mmzone.h~A6-extreme-hotplug-prepare
2005-08-11 15:46:18.0 -0700
+++ memhotplug-dave/include/linux/mmzone.h  2005-08-11 15:46:18.0 
-0700
@@ -588,6 +588,7 @@ static inline int pfn_valid(unsigned lon
 void sparse_init(void);
 #else
 #define sparse_init()  do {} while (0)
+#define sparse_index_init(_sec, _nid)  do {} while (0)
 #endif /* CONFIG_SPARSEMEM */
 
 #ifdef CONFIG_NODES_SPAN_OTHER_NODES
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] sparsemem extreme implementation

[Dave Hansen]

This applies to 2.6.13-rc5-mm1 and replaces the existing
sparsemem-extreme.patch



From: Bob Picco <[EMAIL PROTECTED]>
With cleanups from Dave Hansen <[EMAIL PROTECTED]>

SPARSEMEM_EXTREME makes mem_section a one dimensional array of
pointers to mem_sections. This two level layout scheme is able to achieve
smaller memory requirements for SPARSEMEM with the tradeoff of an additional
shift and load when fetching the memory section.  The current SPARSEMEM
implementation is a one dimensional array of mem_sections which is the default 
SPARSEMEM configuration.  The patch attempts isolates the implementation details
of the physical layout of the sparsemem section array.

SPARSEMEM_EXTREME requires bootmem to be functioning at the time of
memory_present() calls.  This is not always feasible, so architectures which
do not need it may allocate everything statically by using SPARSEMEM_STATIC.

Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Signed-off-by: Bob Picco <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---

 memhotplug-dave/arch/i386/Kconfig  |1 
 memhotplug-dave/include/linux/mmzone.h |   24 ++---
 memhotplug-dave/mm/Kconfig |   22 +++
 memhotplug-dave/mm/sparse.c|   46 -
 4 files changed, 83 insertions(+), 10 deletions(-)

diff -puN include/linux/mmzone.h~A3-sparsemem-extreme include/linux/mmzone.h
--- memhotplug/include/linux/mmzone.h~A3-sparsemem-extreme  2005-08-11 
15:46:16.0 -0700
+++ memhotplug-dave/include/linux/mmzone.h  2005-08-11 15:46:16.0 
-0700
@@ -487,11 +487,27 @@ struct mem_section {
unsigned long section_mem_map;
 };
 
-extern struct mem_section mem_section[NR_MEM_SECTIONS];
+#ifdef CONFIG_SPARSEMEM_EXTREME
+#define SECTIONS_PER_ROOT   (PAGE_SIZE / sizeof (struct mem_section))
+#else
+#define SECTIONS_PER_ROOT  1
+#endif
+
+#define SECTION_NR_TO_ROOT(sec)((sec) / SECTIONS_PER_ROOT)
+#define NR_SECTION_ROOTS   (NR_MEM_SECTIONS / SECTIONS_PER_ROOT)
+#define SECTION_ROOT_MASK  (SECTIONS_PER_ROOT - 1)
+
+#ifdef CONFIG_SPARSEMEM_EXTREME
+extern struct mem_section *mem_section[NR_SECTION_ROOTS];
+#else
+extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT];
+#endif
 
 static inline struct mem_section *__nr_to_section(unsigned long nr)
 {
-   return _section[nr];
+   if (!mem_section[SECTION_NR_TO_ROOT(nr)])
+   return NULL;
+   return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK];
 }
 
 /*
@@ -513,12 +529,12 @@ static inline struct page *__section_mem
 
 static inline int valid_section(struct mem_section *section)
 {
-   return (section->section_mem_map & SECTION_MARKED_PRESENT);
+   return (section && (section->section_mem_map & SECTION_MARKED_PRESENT));
 }
 
 static inline int section_has_mem_map(struct mem_section *section)
 {
-   return (section->section_mem_map & SECTION_HAS_MEM_MAP);
+   return (section && (section->section_mem_map & SECTION_HAS_MEM_MAP));
 }
 
 static inline int valid_section_nr(unsigned long nr)
diff -puN mm/Kconfig~A3-sparsemem-extreme mm/Kconfig
--- memhotplug/mm/Kconfig~A3-sparsemem-extreme  2005-08-11 15:46:16.0 
-0700
+++ memhotplug-dave/mm/Kconfig  2005-08-11 15:46:16.0 -0700
@@ -89,3 +89,25 @@ config NEED_MULTIPLE_NODES
 config HAVE_MEMORY_PRESENT
def_bool y
depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
+
+#
+# SPARSEMEM_EXTREME (which is the default) does some bootmem
+# allocations when memory_present() is called.  If this can not
+# be done on your architecture, select this option.  However,
+# statically allocating the mem_section[] array can potentially
+# consume vast quantities of .bss, so be careful.
+#
+# This option will also potentially produce smaller runtime code
+# with gcc 3.4 and later.
+#
+config SPARSEMEM_STATIC
+   def_bool n
+
+#
+# Architectecture platforms which require a two level mem_section in SPARSEMEM
+# must select this option. This is usually for architecture platforms with
+# an extremely sparse physical address space.
+#
+config SPARSEMEM_EXTREME
+   def_bool y
+   depends on SPARSEMEM && !SPARSEMEM_STATIC
diff -puN mm/sparse.c~A3-sparsemem-extreme mm/sparse.c
--- memhotplug/mm/sparse.c~A3-sparsemem-extreme 2005-08-11 15:46:16.0 
-0700
+++ memhotplug-dave/mm/sparse.c 2005-08-11 15:46:16.0 -0700
@@ -13,9 +13,36 @@
  *
  * 1) mem_section  - memory sections, mem_map's for valid memory
  */
-struct mem_section mem_section[NR_MEM_SECTIONS];
+#ifdef CONFIG_SPARSEMEM_EXTREME
+struct mem_section *mem_section[NR_SECTION_ROOTS]
+   cacheline_maxaligned_in_smp;
+#else
+struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]
+   cacheline_maxaligned_in_smp;
+#endif
 EXPORT_SYMBOL(mem_section);
 
+static void sparse_alloc_root(unsigned long root, int nid)
+{
+#ifdef CONFIG_SPARSEMEM_EXTREME
+   

Re: UML build broken on 2.6.13-rc5-mm1

[Jan Dittmer]

Miklos Szeredi wrote:
> UML is broken again in -mm.
> 
> Maybe UML should be added to one of the automatic build suites.

It is, see here: http://l4x.org/k/?d=6080 . But the maintainer (if he cares)
will know that it's broken and send a fix in time.
-mm is imho designed to be broken from time to time.

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

Re: [AES] Add module alias to x86_64 implementation

[David S. Miller]

From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 11 Aug 2005 22:28:35 +1000

> It looks good to me too.  Andrew, please add this to 2.6.13:

It's already in Linus's tree for a few days now.
-
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] deinline netif_carrier_on/off

[David S. Miller]

Applied to my net-2.6.14 GIT tree, but please provide a proper
Signed-off-by: line in future patch submissions.
-
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][2.6.12.3] IRQ compression/sharing patch

[Zwane Mwaikambo]

On Thu, 11 Aug 2005, Protasevich, Natalie wrote:

> > I added some of the suggestions brought forward (dynamically 
> > allocated IDTs, percpu IDT) last night, all that's left is 
> > MSI, which does work right now, but gets all its vectors 
> > allocated on the first irq handling domain. I should be done 
> > soon, time permitting.
> 
> Zwane, please let me know when I can try it on ES7000, even work in
> progress if you need it (see above about volunteering :)

Certainly and thanks for volunteering, here is what i had booting last 
night. There are some things which i need to resolve, for example 
allocations from __alloc_percpu don't seem to be cacheline aligned, let 
alone 2k (as i'd expect for a 2k allocation). IDTs are now per cpu, but 
the policy for distributing which cpus service which devices is still on a 
node basis. You may also need to ramp up NR_IRQS for the ES7000 subarch, 
what is a good number?

Index: linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 apic.c
--- linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c6 Aug 2005 18:46:41 
-   1.1.1.1
+++ linux-2.6.13-rc4-mm1/arch/i386/kernel/apic.c11 Aug 2005 03:39:33 
-
@@ -78,15 +78,15 @@ void __init apic_intr_init(void)
smp_intr_init();
 #endif
/* self generated IPI for local APIC timer */
-   set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt);
+   boot_set_intr_gate(LOCAL_TIMER_VECTOR, apic_timer_interrupt);
 
/* IPI vectors for APIC spurious and error interrupts */
-   set_intr_gate(SPURIOUS_APIC_VECTOR, spurious_interrupt);
-   set_intr_gate(ERROR_APIC_VECTOR, error_interrupt);
+   boot_set_intr_gate(SPURIOUS_APIC_VECTOR, spurious_interrupt);
+   boot_set_intr_gate(ERROR_APIC_VECTOR, error_interrupt);
 
/* thermal monitor LVT interrupt */
 #ifdef CONFIG_X86_MCE_P4THERMAL
-   set_intr_gate(THERMAL_APIC_VECTOR, thermal_interrupt);
+   boot_set_intr_gate(THERMAL_APIC_VECTOR, thermal_interrupt);
 #endif
 }
 
Index: linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S
===
RCS file: /home/cvsroot/linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 entry.S
--- linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S   6 Aug 2005 18:46:41 
-   1.1.1.1
+++ linux-2.6.13-rc4-mm1/arch/i386/kernel/entry.S   7 Aug 2005 01:27:16 
-
@@ -416,27 +416,18 @@ syscall_badsys:
FIXUP_ESPFIX_STACK \
 28:popl %eax;
 
-/*
- * Build the entry stubs and pointer table with
- * some assembler magic.
- */
-.data
-ENTRY(interrupt)
-.text
-
+/* Build the IRQ entry stubs */
 vector=0
-ENTRY(irq_entries_start)
+   .align IRQ_STUB_SIZE,0x90
+ENTRY(interrupt)
 .rept NR_IRQS
ALIGN
-1: pushl $vector-256
+   pushl $vector-0x1
jmp common_interrupt
-.data
-   .long 1b
-.text
+   .align IRQ_STUB_SIZE,0x90
 vector=vector+1
 .endr
 
-   ALIGN
 common_interrupt:
SAVE_ALL
movl %esp,%eax
Index: linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S
===
RCS file: /home/cvsroot/linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 head.S
--- linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S6 Aug 2005 18:46:41 
-   1.1.1.1
+++ linux-2.6.13-rc4-mm1/arch/i386/kernel/head.S11 Aug 2005 02:44:06 
-
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -304,7 +305,7 @@ is386:  movl $2,%ecx# set MP
 
call check_x87
lgdt cpu_gdt_descr
-   lidt idt_descr
+   lidt cpu_idt_descr  # we switch to per cpu IDTs later
ljmp $(__KERNEL_CS),$1f
 1: movl $(__KERNEL_DS),%eax# reload all the segment registers
movl %eax,%ss   # after changing gdt.
@@ -370,7 +371,7 @@ setup_idt:
movw %dx,%ax/* selector = 0x0010 = cs */
movw $0x8E00,%dx/* interrupt gate - dpl=0, present */
 
-   lea idt_table,%edi
+   lea boot_idt_table,%edi
mov $256,%ecx
 rp_sidt:
movl %eax,(%edi)
@@ -445,7 +446,7 @@ int_msg:
  */
 
 .globl boot_gdt_descr
-.globl idt_descr
+.globl cpu_idt_descr
 .globl cpu_gdt_descr
 
ALIGN
@@ -456,9 +457,10 @@ boot_gdt_descr:
.long boot_gdt_table - __PAGE_OFFSET
 
.word 0 # 32-bit align idt_desc.address
-idt_descr:
+cpu_idt_descr:
.word IDT_ENTRIES*8-1   # idt contains 256 entries
-   .long idt_table
+   .long boot_idt_table
+   .fill NR_CPUS-1,8,0
 
 # boot GDT descriptor (later on used by CPU#0):
.word 0 # 32 bit align 

Re: [PATCH/RFT 5/5] CLOCK-Pro page replacement

[Song Jiang]

My current test focuses on the looping case, where I repeatedly 
scan a file whose size is larger than the memory size but less 
than two times of memory sizes. My initial results are as follows:


My machine has 2GB memory.
The size of the file to be scanned is 2.5GB.
I looped for 4 time. The times and associated disk bandwidths
for each loop are below:

loop 0 time = 34.229424s bandwith = 76.58MB
loop 1 time = 37.574041s bandwith = 69.76MB
loop 2 time = 38.181791s bandwith = 68.65MB
loop 3 time = 38.141794s bandwith = 68.72MB

This shows that the current patches cannot do a 
better job than the original kernel, which notoriously
underperforms for the case -- no matter how many times
the file is accessed, no hits at all. Meanwhile, Clock-Pro
is supposed to do a better job, because part of the
file can be protected in the active list and get a decent 
number of hits.

Here is from /proc/meminfo:

Active:  11356 kB
Inactive:  1994400 kB

So no file pages are promoted into the active list, just
as in the original kernel.

Here is from /proc/refaults: 

Refault distance  Hits
 0 - 32768   192
32768 - 65536   269
65536 - 98304   447
98304 -131072   603
   131072 -163840  1087
   163840 -196608   909
   196608 -229376   558
   229376 -262144   404
   262144 -294912   287
   294912 -327680   191
   327680 -36044879
   360448 -39321668
   393216 -42598441
   425984 -45875245
   458752 -49152031
New/Beyond491520  2443

In the statistic, we do see many hits at the distance of around 
150,000 pages. If we consider the inactive list size (1.9GB), 
this position corresponds to the file size. However, if everything
happens as expected, all the hits should happen at the
distance. Unfortunately, there are also many hits listed as
New/Beyond. Because "Beyond"s should not be there, are they all
"New"s? Futhermore, I didn't see where the refault_histogram 
statistics get reset, though they almost stop increasing after
the first run. Can you show me that? 


   Song Jiang
   at LANL

-
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: I2C block reads with i2c-viapro: testers wanted

[Krzysztof Halasa]

Hi,

Jean Delvare <[EMAIL PROTECTED]> writes:

> Partly right. Actually, most SMBus controllers work the following way:
> you program a number of registers (typically SMBus transaction type,
> target chip address, target register address or command, and the data to
> send in the case of a write transaction),

So, with one transaction, can I write an arbitrary number of bytes to
the device, and then, in the same transaction, can I read one (or no,
or with some controllers, more than one) byte(s) back?

>> But wait, even then does the controller really know anything about
>> I^2C commands? How would it differentiate between, say, 8-bit and
>> 16-bit reads? Or is it just an 8-bit EEPROM bus?
>
> No, it is still physically a 2-wire serial bus.

Sure, I rather meant "a bus _for_ I^2C EEPROMs which use 8-bit (+3)
addressing".

> The limitation is due to
> the fast that the SMBus controller knows of a limited number of
> transactions, such as Send Byte, Read Byte, Read Word etc. If the SMBus
> controller doesn't know of the SMBus command you want to use (in my
> case, I2C block read), then there is no way to do it, because we have no
> direct control over the serial line.

Interesting. Still, that limits it to 8-bit-addressable EEPROMs.

Are such things documented somewhere on the net (some datasheet maybe)?
-- 
Krzysztof Halasa
-
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][2.6.12.3] IRQ compression/sharing patch

[Protasevich, Natalie]

> On Wed, 10 Aug 2005, Protasevich, Natalie wrote:
> 
> > our systems we are just about to use up all 224 interrupts, but not 
> > quiet.
> > I have to mention that as far as I know Zwane is about to 
> release his 
> > vector sharing mechanism, he had it implemented and working 
> for i386 
> > (I tested it on ES7000 successfully, by itself and combined with 
> > compression patch too), and was planning implementing it 
> for x86_64. I 
> > am officially volunteering for testing it in its present state, for 
> > both
> > i386 and x86_64 (I can still do this on our systems by removing the 
> > IRQ compression code :), hope this will help Zwane and Andi 
> to release 
> > it as soon as possible.
> 
> I added some of the suggestions brought forward (dynamically 
> allocated IDTs, percpu IDT) last night, all that's left is 
> MSI, which does work right now, but gets all its vectors 
> allocated on the first irq handling domain. I should be done 
> soon, time permitting.

Zwane, please let me know when I can try it on ES7000, even work in
progress if you need it (see above about volunteering :)

Regards,
--Natalie 
 
-
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] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Luck, Tony wrote:

Tony, others, does this change give you any heartburn?  On
the 460GX and 870 boxes I have, IDE is a PCI device.



No heartburn for me ... as you say IDE is built into one
of the 870 chips.

I don't know whether any non-Intel chipsets provide legacy IDE.


The question is not about ISA IDE, but more about the PCI IDE 
specification...  See the PCI IDE examples in my other emails.


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] IDE: don't offer IDE_GENERIC on ia64

[Luck, Tony]

>Tony, others, does this change give you any heartburn?  On
>the 460GX and 870 boxes I have, IDE is a PCI device.

No heartburn for me ... as you say IDE is built into one
of the 870 chips.

I don't know whether any non-Intel chipsets provide legacy IDE.

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

RE: [RFC][2.6.12.3] IRQ compression/sharing patch

[Protasevich, Natalie]

> After sleeping on it, maybe the original code can be patched 
> without having to hack assign_irq_vector(), etc.  How about:
> 
> --- io_apic.c 2005-08-11 10:14:33.564748923 -0700
> +++ io_apic.c.new 2005-08-11 10:15:55.412331115 -0700
> @@ -617,7 +617,7 @@ int gsi_irq_sharing(int gsi)
>* than PCI.
>*/
>   for (i = 0; i < NR_IRQS; i++)
> - if (IO_APIC_VECTOR(i) == vector) {
> + if (IO_APIC_VECTOR(i) == vector && i != gsi) {
>   if (!platform_legacy_irq(i))
>   break;  /* got one */
>   IO_APIC_VECTOR(gsi) = 0;
> 
> 
Yes that did it, on my small system it looked just right:

<7>IRQ to pin mappings:
<7>IRQ0 -> 0:2
<7>IRQ1 -> 0:1
<7>IRQ3 -> 0:3
<7>IRQ4 -> 0:4
<7>IRQ5 -> 0:5
<7>IRQ6 -> 0:6
<7>IRQ7 -> 0:7
<7>IRQ8 -> 0:8
<7>IRQ9 -> 0:9
<7>IRQ10 -> 0:10
<7>IRQ11 -> 0:11
<7>IRQ12 -> 0:12
<7>IRQ14 -> 0:14
<7>IRQ15 -> 0:15
<7>IRQ16 -> 0:16
<7>IRQ17 -> 0:17
<7>IRQ18 -> 0:18
<7>IRQ19 -> 0:19
<7>IRQ20 -> 0:20
<7>IRQ21 -> 0:23
<7>IRQ22 -> 1:2
<7>IRQ23 -> 1:3
<7>IRQ24 -> 1:4
<7>IRQ25 -> 1:5
<7>IRQ26 -> 2:0
<7>IRQ27 -> 2:1
<7>IRQ28 -> 2:2
<7>IRQ29 -> 2:3
<7>IRQ30 -> 2:4
<7>IRQ31 -> 2:5
<7>IRQ32 -> 2:6
<7>IRQ33 -> 2:7
<7>IRQ34 -> 2:8
:!cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3
  0:  12621  15007  12781  20921IO-APIC-edge  timer
  1: 72  0  2175IO-APIC-edge  i8042
  2:  0  0  0  0  XT-PIC
cascade
  8:  0  0  0  1IO-APIC-edge  rtc
  9:  0  0  0  0IO-APIC-edge  acpi
 12:  4272  0110IO-APIC-edge  i8042
 15:  4  0  0 39IO-APIC-edge  ide1
 16:  0  0  0  0   IO-APIC-level
uhci_hcd:usb1, uhci_hcd:usb4
 17:  0  0  0  2   IO-APIC-level
ohci1394
 18:730   2407932   2083   IO-APIC-level
libata, uhci_hcd:usb3
 19:  0  0  0  0   IO-APIC-level
uhci_hcd:usb2
 21:  0  0  0  0   IO-APIC-level
ehci_hcd:usb5
 26:416  0  0  4   IO-APIC-level  eth0
NMI:116 71 73 51
LOC:  61280  61258  61236  61214
ERR:  3
MIS:  0

Looks good! I will try the patch also on the ES7000 hopefully big enough
to exercise some vector sharing.

Regards,
--Natalie
-
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] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

Jeff Garzik wrote:
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller 
(rev 02) (prog-if 8a [Master SecP PriP])

Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at 14c0 [size=16]
Region 5: Memory at 4000 (32-bit, non-prefetchable) [size=1K]



Trust me, IDE on PCI is still quite weird.


The above configuration also indicates that the IRQs for the PCI device 
are 14 and 15, _not_ 169.


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/

SiI 3112A + Seagate HDs = still no go?

[Chris Boot]

Hi all,

I just recently took the plunge and bought 4 250 GB Seagate drives  
and a 2 port Silicon Image 3112A controller card for the 2 drives my  
motherboard doesn't handle. No matter how hard I try, I can't get the  
hard drives to work: they are detected correctly and work reasonably  
well under _very_ light load, but anything like building a RAID array  
is a bit much and the whole controller seems to lock up.


I've tried adding the drive to the blacklist in the sata_sil.c driver  
and I still have the same trouble: as you can see the messages below  
relate to my patched kernel with the blacklist fix. I've seen that  
this was discussed just yesterday, but that seemed to give nothing:  
http://www.ussg.iu.edu/hypermail/linux/kernel/0508.1/0310.html


Ready and willing to hack my kernel to pieces; this machine is no use  
until I get all the drives working! Needless to say the drives  
connected to the on-board VIA controller work fine, as do the drives  
currently on the SiI controller if I swap them around.


Any ideas?

TIA
Chris

The following messages are sent to the log when everything goes mad:

ata1: command 0x35 timeout, stat 0xd8 host_stat 0x0
ata1: status=0xd8 { Busy }
SCSI error : <0 0 0 0> return code = 0x8002
sda: Current: sense key=0xb
ASC=0x47 ASCQ=0x0
end_request: I/O error, dev sda, sector 2990370
ATA: abnormal status 0xD8 on port E0802087
ATA: abnormal status 0xD8 on port E0802087
ATA: abnormal status 0xD8 on port E0802087
[ the above is transcribed so may not be 100% accurate ]

Dmesg log during boot (and detection):

Aug 11 21:47:05 arcadia Linux version 2.6.12-gentoo-r6  
([EMAIL PROTECTED]) (gcc version 3.3.5-20050130 (Gentoo  
3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #2 Thu Aug 11  
20:19:00 BST 2005

...
Aug 11 17:30:12 arcadia sata_sil version 0.9
Aug 11 17:30:12 arcadia ACPI: PCI Interrupt :00:0a.0[A] -> GSI 18  
(level, low) -> IRQ 177
Aug 11 17:30:12 arcadia ata1: SATA max UDMA/100 cmd 0xE0802080 ctl  
0xE080208A bmdma 0xE0802000 irq 177
Aug 11 17:30:12 arcadia ata2: SATA max UDMA/100 cmd 0xE08020C0 ctl  
0xE08020CA bmdma 0xE0802008 irq 177
Aug 11 17:30:12 arcadia ata1: dev 0 cfg 49:2f00 82:346b 83:7d01  
84:4023 85:3469 86:3c01 87:4023 88:207f
Aug 11 17:30:12 arcadia ata1: dev 0 ATA, max UDMA/133, 488397168  
sectors: lba48

Aug 11 17:30:12 arcadia ata1(0): applying Seagate errata fix
Aug 11 17:30:12 arcadia ata1: dev 0 configured for UDMA/100
Aug 11 17:30:12 arcadia scsi0 : sata_sil
Aug 11 17:30:12 arcadia ata2: dev 0 cfg 49:2f00 82:346b 83:7d01  
84:4023 85:3469 86:3c01 87:4023 88:207f
Aug 11 17:30:12 arcadia ata2: dev 0 ATA, max UDMA/133, 488397168  
sectors: lba48

Aug 11 17:30:12 arcadia ata2(0): applying Seagate errata fix
Aug 11 17:30:12 arcadia ata2: dev 0 configured for UDMA/100
Aug 11 17:30:12 arcadia scsi1 : sata_sil
Aug 11 17:30:12 arcadia Vendor: ATA   Model: ST3250823AS
Rev: 3.03
Aug 11 17:30:12 arcadia Type:   Direct-Access   
ANSI SCSI revision: 05
Aug 11 17:30:12 arcadia Vendor: ATA   Model: ST3250823AS
Rev: 3.03
Aug 11 17:30:12 arcadia Type:   Direct-Access   
ANSI SCSI revision: 05


lspci:

:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600  
AGP] Host Bridge

:00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
:00:0a.0 Unknown mass storage controller: Silicon Image, Inc. SiI  
3112 [SATALink/SATARaid] Serial ATA Controller (rev 02)
:00:0c.0 FireWire (IEEE 1394): Agere Systems (former Lucent  
Microelectronics) FW323 (rev 61)
:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420  
SATA RAID Controller (rev 80)
:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/ 
VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
:00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI  
USB 1.1 Controller (rev 81)
:00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI  
USB 1.1 Controller (rev 81)
:00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI  
USB 1.1 Controller (rev 81)
:00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI  
USB 1.1 Controller (rev 81)

:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge  
[KT600/K8T800/K8T890 South]
:00:11.5 Multimedia audio controller: VIA Technologies, Inc.  
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102  
[Rhine-II] (rev 78)
:01:00.0 VGA compatible controller: nVidia Corporation NV11  
[GeForce2 MX/MX 400] (rev b2)


Many thanks,
Chris

--
Chris Boot
[EMAIL PROTECTED]
http://www.bootc.net/




-
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: CCITT-CRC16 in kernel

[linux]

>> CRC-CCITT = X^16 + X^12 + X^5 + X^0 = 0x8408, and NOT 0x1021
>> CRC-16 =  X^16 + X^15 + X^2 + X^0 = 0xa001, and NOT 0x8005
>>
> 
> Thank you very much for your time, but what you say is completely
> different than anything else I have found on the net.
> 
> Do the math:
> 
>   2^ 16 = 65536
>   2^ 12 =  4096
>   2^  5 =32
>   2^  0 = 1
> --
>  69655 = 0x11021
> 
> That's by convention 0x1021 as the X^16 is thrown away. I have
> no clue how you could possibly get 0x8408 out of this, nor
> how the CRC of 1 could possibly lie at offset 128 in a table
> of CRC polynomials. Now I read it in the header, but that
> doesn't make it right.

The thing is that X is not 2.  x is a formal variable with
no defined value.

x^0  is represented as to 0x8000
x^5  is represented as to 0x0400
x^12 is represented as to 0x0008
x^16 is not represented by any bit
TOTAL:0x8408

> The "RS-232C" order to which you refer simply means that the
> string of "bits" needs to handled as a string of bytes, not
> words or longwords, in other words, not interpreted as
> words, just bytes. If this isn't correct then ZMODEM and
> a few other protocols are wrong. You certainly don't
> swap every BIT in a string do you? You are not claiming
> that (0x01 == 0x80) and (0x02 == 0x40), etc, are you?

Not at all.  To repeat:

- A CRC is computed over a string of *bits*.  All of its error-corection
  properties are described in terms of *bit* patterns and *bit* positions
  and runs of adjacent *bits*.  It does not know or care about larger
  structures such a bytes.

- The CRC algorithm requires that the *first* bit it sees is the
  coefficient of the highest power of x, and the *last* bit it sees is
  the coefficient of x^0.  This is because it's basically long division.

- If you are working in software, you (the implementor) must define a
  mapping between a byte string and a bit string.  There are only two
  mappings that make any sense at all:
  1) The least-significant bit of each byte is considered "first",
 and the most-significant is considered "last".
  2) The most-significant bit of each byte is considered "first",
 and the least-significant is considered "last".

The logic of the CRC *does not care* which one you choose, but you have
to choose one.  If the bytes are to be converted to bit-serial form, it
is best to choose the form actually used for transmission to preserve the
burst error detection properies of the CRC.  Note that:

- Many people (including, apparently, you) find the second choice a bit
  easier to visualize, as bit i is the coefficient of x^i.
- The first choice is
  a) Easier to implement in software, and
  b) Matches RS-232 transmission order, and
  c) Is used by hardware such as the Z8530 SCC and MPC860 QUICC, and
  d) Is the form invariably used by experienced software implementors.

If you have some wierd piece of existing hardware, it might have chosen
either.  Just try them both and see which works.

However, if your hardware uses the opposite bit ordering within bytes,
DO NOT ATTEMPT to "fix" lib/crc-ccitt.c.  It will break all of the
existing users of the code.
-
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: cx88 teletext not yet implemented -was- Re: Linux-2.6.13-rc6: aic7xxx testers please..

[Gene Heskett]

On Thursday 11 August 2005 11:38, Michael Krufky wrote:
>Gene Heskett wrote:
>>I can also report that teletext decoding has ceased to work
>>here.  But I'm not sure what kernel version killed it.  Currently
>>running 2.6.13-rc6.  But my card is cx88 based, a pcHDTV-3000.  But
>>attempting to switch it on/off doesn't seem to generate any output
>>indicating it failed, it just Doesn't Work(TM)
>
>Gene-
>
>By teletext, I assume you are referring to closed captions.  Are you
>sure that closed captions EVER worked for you on a cx88-based card?
>AFAIK, this feature has not yet been implemented.  I am not at home
> now, so I cannot try it, however, IIRC, closed captions is
> implemented in bttv, and not yet in cx88.
>
>This is a v4l issue, not a dvb issue, however, it is NOT an issue. 
> This is not a regression, because the feature has not yet been
> implemented.
>
>Gene, if I am wrong, (this is possible) then please provide the last
>kernel version that had this feature correctly implemented.  I don't
>think that I am wrong, though.  Please investigate this and confirm
> that this is an actual regression or not.
>
>Cheers,

Its entirely possible that the last time I saw it work was in fact on
a bt878 card, one I junked because the tuner was apparently damaged,
needing something like 10,000 u-v to give a useable picture.  I
assumed (theres that word again) that the CC decoding was seperately
handled by inspecting the output video data stream regardless of its
source.  Mentally to me, that then would have been a tvtime function
and not a cx88 function.  It makes far more sense to me anyway.

Sorry for the false alarm.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

-
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] (6/7) I2C: Kill i2c_algorithm.id

[Jean Delvare]

In theory, there should be no more users of I2C_ALGO_* at this point.
However, it happens that several drivers were using I2C_ALGO_* for
adapter ids, so we need to correct these before we can get rid of all
the I2C_ALGO_* definitions.

Note that this also fixes a bug in media/video/tvaudio.c:

/* don't attach on saa7146 based cards,
   because dedicated drivers are used */
if ((adap->id & I2C_ALGO_SAA7146))
return 0;

This test was plain broken, as it would succeed for many more adapters
than just the saa7146: any those id would share at least one bit with
the saa7146 id. We are really lucky that the few other adapters we want
this driver to work with did not fulfill that condition.

Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>

 drivers/i2c/busses/i2c-keywest.c  |1 -
 drivers/i2c/busses/scx200_acb.c   |2 +-
 drivers/media/common/saa7146_i2c.c|2 +-
 drivers/media/dvb/b2c2/flexcop-i2c.c  |1 -
 drivers/media/dvb/dvb-usb/dvb-usb-i2c.c   |1 -
 drivers/media/dvb/pluto2/pluto2.c |1 -
 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |1 -
 drivers/media/video/ir-kbd-i2c.c  |2 +-
 drivers/media/video/saa7134/saa7134-i2c.c |2 +-
 drivers/media/video/tda9840.c |2 +-
 drivers/media/video/tda9887.c |2 +-
 drivers/media/video/tea6415c.c|2 +-
 drivers/media/video/tea6420.c |2 +-
 drivers/media/video/tvaudio.c |4 ++--
 drivers/video/aty/radeon_i2c.c|2 +-
 drivers/video/nvidia/nv_i2c.c |3 +--
 drivers/video/riva/rivafb-i2c.c   |3 +--
 drivers/video/savage/savagefb-i2c.c   |3 +--
 include/linux/i2c-id.h|7 +++
 include/media/id.h|5 -
 20 files changed, 21 insertions(+), 27 deletions(-)

--- linux-2.6.13-rc5.orig/drivers/video/aty/radeon_i2c.c2005-06-18 
09:32:50.0 +0200
+++ linux-2.6.13-rc5/drivers/video/aty/radeon_i2c.c 2005-08-02 
22:40:54.0 +0200
@@ -75,7 +75,7 @@
 
strcpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
-   chan->adapter.id= I2C_ALGO_ATI;
+   chan->adapter.id= I2C_HW_B_RADEON;
chan->adapter.algo_data = >algo;
chan->adapter.dev.parent= >rinfo->pdev->dev;
chan->algo.setsda   = radeon_gpio_setsda;
--- linux-2.6.13-rc5.orig/drivers/video/nvidia/nv_i2c.c 2005-06-18 
09:32:53.0 +0200
+++ linux-2.6.13-rc5/drivers/video/nvidia/nv_i2c.c  2005-08-02 
22:36:42.0 +0200
@@ -90,14 +90,13 @@
return val;
 }
 
-#define I2C_ALGO_NVIDIA   0x0e
 static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, const char *name)
 {
int rc;
 
strcpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
-   chan->adapter.id = I2C_ALGO_NVIDIA;
+   chan->adapter.id = I2C_HW_B_NVIDIA;
chan->adapter.algo_data = >algo;
chan->adapter.dev.parent = >par->pci_dev->dev;
chan->algo.setsda = nvidia_gpio_setsda;
--- linux-2.6.13-rc5.orig/drivers/video/riva/rivafb-i2c.c   2005-06-18 
09:32:53.0 +0200
+++ linux-2.6.13-rc5/drivers/video/riva/rivafb-i2c.c2005-08-02 
22:37:35.0 +0200
@@ -92,14 +92,13 @@
return val;
 }
 
-#define I2C_ALGO_RIVA   0x0e
 static int riva_setup_i2c_bus(struct riva_i2c_chan *chan, const char *name)
 {
int rc;
 
strcpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
-   chan->adapter.id= I2C_ALGO_RIVA;
+   chan->adapter.id= I2C_HW_B_RIVA;
chan->adapter.algo_data = >algo;
chan->adapter.dev.parent= >par->pdev->dev;
chan->algo.setsda   = riva_gpio_setsda;
--- linux-2.6.13-rc5.orig/drivers/video/savage/savagefb-i2c.c   2005-06-18 
09:32:53.0 +0200
+++ linux-2.6.13-rc5/drivers/video/savage/savagefb-i2c.c2005-08-02 
22:39:13.0 +0200
@@ -137,7 +137,6 @@
return (0 != (GET_CR_DATA(chan->ioaddr) & PROSAVAGE_I2C_SDA_IN));
 }
 
-#define I2C_ALGO_SAVAGE   0x0f
 static int savage_setup_i2c_bus(struct savagefb_i2c_chan *chan,
const char *name)
 {
@@ -147,7 +146,7 @@
if (add_bus && chan->par) {
strcpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
-   chan->adapter.id= I2C_ALGO_SAVAGE;
+   chan->adapter.id= I2C_HW_B_SAVAGE;
chan->adapter.algo_data = >algo;
chan->adapter.dev.parent= >par->pcidev->dev;

Re: I2C block reads with i2c-viapro: testers wanted

[Jean Delvare]

Hi Krzysztof,

> > However,
> > EEPROMs are also often found on SMBus busses, those controller only
> > implement a subset of all possible I2C commands.
> 
> You mean one can't drive clock and data lines at will, and the
> controller (some hardware) does it instead, based on commands received
> from the program (and, for example, the program interface is parallel,
> not 2-wire serial). Right?

Partly right. Actually, most SMBus controllers work the following way:
you program a number of registers (typically SMBus transaction type,
target chip address, target register address or command, and the data to
send in the case of a write transaction), then you tell the chip to
initiate the transaction. Then you poll for the transaction to be over
(or use an interupt, but most our SMBus drivers use polling), and read
the result in some register in the case of a read transaction.

> But wait, even then does the controller really know anything about
> I^2C commands? How would it differentiate between, say, 8-bit and
> 16-bit reads? Or is it just an 8-bit EEPROM bus?

No, it is still physically a 2-wire serial bus. The limitation is due to
the fast that the SMBus controller knows of a limited number of
transactions, such as Send Byte, Read Byte, Read Word etc. If the SMBus
controller doesn't know of the SMBus command you want to use (in my
case, I2C block read), then there is no way to do it, because we have no
direct control over the serial line.

> Does it do START and STOP automatically as well?

Absolutely. The good thing is that SMBus masters are not CPU intensive,
contrary to bit-banging I2C adapters.

-- 
Jean Delvare
-
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/7) I2C: Kill i2c_algorithm.id

[Jean Delvare]

The I2C_ALGO_* constants have no more users, delete them. Also update
the comments in i2c-id.h so that they reflect the current state of the
file.

Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>

 include/linux/i2c-id.h |   57 -
 1 files changed, 1 insertion(+), 56 deletions(-)

--- linux-2.6.13-rc5.orig/include/linux/i2c-id.h2005-08-03 
20:04:58.0 +0200
+++ linux-2.6.13-rc5/include/linux/i2c-id.h 2005-08-03 20:25:27.0 
+0200
@@ -1,6 +1,6 @@
 /* - */
 /*  */
-/* i2c.h - definitions for the i2c-bus interface*/
+/* i2c-id.h - identifier values for i2c drivers and adapters*/
 /*  */
 /* - */
 /*   Copyright (C) 1995-1999 Simon G. Vogl
@@ -24,16 +24,6 @@
 #define LINUX_I2C_ID_H
 
 /*
- * This file is part of the i2c-bus package and contains the identifier
- * values for drivers, adapters and other folk populating these serial
- * worlds. 
- *
- * These will change often (i.e. additions) , therefore this has been 
- * separated from the functional interface definitions of the i2c api.
- *
- */
-
-/*
  *  Driver types -
  *   device id name + numberfunction description, i2c address(es)
  *
@@ -170,51 +160,6 @@
 
 /*
  *  Adapter types 
- *
- * First, we distinguish between several algorithms to access the hardware
- * interface types, as a PCF 8584 needs other care than a bit adapter.
- */
-
-#define I2C_ALGO_NONE  0x00
-#define I2C_ALGO_BIT   0x01/* bit style adapters   */
-#define I2C_ALGO_PCF   0x02/* PCF 8584 style adapters  */
-#define I2C_ALGO_ATI   0x03/* ATI video card   */
-#define I2C_ALGO_SMBUS 0x04
-#define I2C_ALGO_ISA   0x05/* lm_sensors ISA pseudo-adapter */
-#define I2C_ALGO_SAA7146 0x06  /* SAA 7146 video decoder bus   */
-#define I2C_ALGO_ACB   0x07/* ACCESS.bus algorithm */
-#define I2C_ALGO_IIC0x08   /* ITE IIC bus */
-#define I2C_ALGO_SAA7134 0x09
-#define I2C_ALGO_MPC824X 0x0a  /* Motorola 8240 / 8245 */
-#define I2C_ALGO_IPMI  0x0b/* IPMI dummy adapter */
-#define I2C_ALGO_IPMB  0x0c/* IPMB adapter */
-#define I2C_ALGO_MPC107 0x0d
-#define I2C_ALGO_EC 0x10/* ACPI embedded controller */
-
-#define I2C_ALGO_MPC8XX 0x11   /* MPC8xx PowerPC I2C algorithm */
-#define I2C_ALGO_OCP0x12   /* IBM or otherwise On-chip I2C 
algorithm */
-#define I2C_ALGO_BITHS 0x13/* enhanced bit style adapters  */
-#define I2C_ALGO_IOP3XX0x14/* XSCALE IOP3XX On-chip I2C 
alg */
-#define I2C_ALGO_SIBYTE 0x15   /* Broadcom SiByte SOCs */
-#define I2C_ALGO_SGI   0x16/* SGI algorithm*/
-
-#define I2C_ALGO_USB   0x17/* USB algorithm*/
-#define I2C_ALGO_VIRT  0x18/* Virtual bus adapter  */
-
-#define I2C_ALGO_MV64XXX 0x19  /* Marvell mv64xxx i2c ctlr */
-#define I2C_ALGO_PCA   0x1a/* PCA 9564 style adapters  */
-#define I2C_ALGO_AU15500x1b/* Au1550 PSC algorithm 
*/
-
-#define I2C_ALGO_EXP   0x80/* experimental */
-
-#define I2C_ALGO_MASK  0xff/* Mask for algorithms  */
-#define I2C_ALGO_SHIFT 0x10/* right shift to get index values  */
-
-#define I2C_HW_ADAPS   0x1 /* # adapter types  */
-#define I2C_HW_MASK0x  
-
-
-/* hw specific modules that are defined per algorithm layer
  */
 
 /* --- Bit algorithm adapters  */

-- 
Jean Delvare
-
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] IDE: don't offer IDE_GENERIC on ia64

[Jeff Garzik]

On Thu, Aug 11, 2005 at 03:42:07PM -0600, Bjorn Helgaas wrote:
> Tony, others, does this change give you any heartburn?  On
> the 460GX and 870 boxes I have, IDE is a PCI device.
> 
> (I have been told that the SGI ia64 simulator depends on
> IDE_GENERIC.  But it really should make the IDE device
> appear in PCI (or describe it via ACPI)).

I think I was misunderstood.

Have you reviewed the PCI IDE specification?

On modern chipsets, the IDE device appears in PCI -- but often, the first 
four I/O ports will be zeroed out, indicating that the I/O regions are
actually 0x1f0/0x170.

For example:

00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller 
(rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at 14c0 [size=16]
Region 5: Memory at 4000 (32-bit, non-prefetchable) [size=1K]



Trust me, IDE on PCI is still quite weird.

Jeff



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

[PATCH] (5/7) I2C: Kill i2c_algorithm.id

[Jean Delvare]

Merge the algorithm id part (16 upper bits) of the i2c adapters ids
into the definition of the adapters ids directly. After that, we don't
need to OR both ids together for each i2c_adapter structure.

Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>

 drivers/i2c/algos/i2c-algo-bit.c   |2 
 drivers/i2c/algos/i2c-algo-ite.c   |2 
 drivers/i2c/algos/i2c-algo-pca.c   |2 
 drivers/i2c/algos/i2c-algo-pcf.c   |2 
 drivers/i2c/algos/i2c-algo-sgi.c   |1 
 drivers/i2c/algos/i2c-algo-sibyte.c|2 
 drivers/i2c/busses/i2c-ibm_iic.c   |2 
 drivers/i2c/busses/i2c-isa.c   |2 
 drivers/i2c/busses/i2c-mpc.c   |2 
 drivers/i2c/busses/i2c-mv64xxx.c   |2 
 drivers/media/video/bt832.c|2 
 drivers/media/video/bttv-i2c.c |2 
 drivers/media/video/ir-kbd-i2c.c   |2 
 drivers/media/video/ovcamchip/ov6x20.c |6 -
 drivers/media/video/ovcamchip/ov6x30.c |4 
 drivers/media/video/ovcamchip/ovcamchip_core.c |8 -
 drivers/media/video/tda7432.c  |2 
 drivers/media/video/tda9875.c  |2 
 drivers/media/video/tda9887.c  |4 
 drivers/media/video/tuner-3036.c   |2 
 drivers/media/video/tvaudio.c  |6 -
 drivers/media/video/tveeprom.c |2 
 drivers/media/video/tvmixer.c  |6 -
 drivers/usb/media/w9968cf.c|2 
 drivers/video/matrox/matroxfb_maven.c  |2 
 include/linux/i2c-id.h |  128 -
 include/linux/i2c-isa.h|2 
 27 files changed, 95 insertions(+), 106 deletions(-)

--- linux-2.6.13-rc5.orig/include/linux/i2c-id.h2005-08-02 
18:31:22.0 +0200
+++ linux-2.6.13-rc5/include/linux/i2c-id.h 2005-08-02 21:40:11.0 
+0200
@@ -218,103 +218,103 @@
  */
 
 /* --- Bit algorithm adapters  */
-#define I2C_HW_B_LP0x00/* Parallel port Philips style adapter  */
-#define I2C_HW_B_LPC   0x01/* Parallel port, over control reg. */
-#define I2C_HW_B_SER   0x02/* Serial line interface*/
-#define I2C_HW_B_ELV   0x03/* ELV Card */
-#define I2C_HW_B_VELLE 0x04/* Vellemann K8000  */
-#define I2C_HW_B_BT848 0x05/* BT848 video boards   */
-#define I2C_HW_B_WNV   0x06/* Winnov Videums   */
-#define I2C_HW_B_VIA   0x07/* Via vt82c586b*/
-#define I2C_HW_B_HYDRA 0x08/* Apple Hydra Mac I/O  */
-#define I2C_HW_B_G400  0x09/* Matrox G400  */
-#define I2C_HW_B_I810  0x0a/* Intel I810   */
-#define I2C_HW_B_VOO   0x0b/* 3dfx Voodoo 3 / Banshee  */
-#define I2C_HW_B_PPORT  0x0c   /* Primitive parallel port adapter  */
-#define I2C_HW_B_SAVG  0x0d/* Savage 4 */
-#define I2C_HW_B_SCX2000x0e/* Nat'l Semi SCx200 I2C
*/
-#define I2C_HW_B_RIVA  0x10/* Riva based graphics cards*/
-#define I2C_HW_B_IOC   0x11/* IOC bit-wiggling */
-#define I2C_HW_B_TSUNA  0x12   /* DEC Tsunami chipset  */
-#define I2C_HW_B_FRODO  0x13/* 2d3D, Inc. SA-1110 Development Board */
-#define I2C_HW_B_OMAHA  0x14/* Omaha I2C interface (ARM)   */
-#define I2C_HW_B_GUIDE  0x15/* Guide bit-basher*/
-#define I2C_HW_B_IXP2000 0x16  /* GPIO on IXP2000 systems  */
-#define I2C_HW_B_IXP4XX 0x17   /* GPIO on IXP4XX systems   */
-#define I2C_HW_B_S3VIA 0x18/* S3Via ProSavage adapter  */
-#define I2C_HW_B_ZR36067 0x19  /* Zoran-36057/36067 based boards   */
-#define I2C_HW_B_PCILYNX 0x1a  /* TI PCILynx I2C adapter   */
-#define I2C_HW_B_CX2388x 0x1b  /* connexant 2388x based tv cards   */
+#define I2C_HW_B_LP0x01 /* Parallel port Philips style */
+#define I2C_HW_B_LPC   0x010001 /* Parallel port control reg. */
+#define I2C_HW_B_SER   0x010002 /* Serial line interface */
+#define I2C_HW_B_ELV   0x010003 /* ELV Card */
+#define I2C_HW_B_VELLE 0x010004 /* Vellemann K8000 */
+#define I2C_HW_B_BT848 0x010005 /* BT848 video boards */
+#define I2C_HW_B_WNV   0x010006 /* Winnov Videums */
+#define I2C_HW_B_VIA   0x010007 /* Via vt82c586b */
+#define I2C_HW_B_HYDRA 0x010008 /* Apple Hydra Mac I/O */
+#define I2C_HW_B_G400  0x010009 /* Matrox G400 */
+#define I2C_HW_B_I810  0x01000a /* Intel I810 */
+#define I2C_HW_B_VOO   0x01000b /* 3dfx Voodoo 3 / Banshee */
+#define I2C_HW_B_PPORT 0x01000c /* 

Re: [PATCH] IDE: don't offer IDE_GENERIC on ia64

[Bjorn Helgaas]

On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> >>Bjorn Helgaas wrote:
> >>> config IDE_GENERIC
> >>>   tristate "generic/default IDE chipset support"
> >>>+  depends on !IA64
> >>
> >>hm.  Are you POSITIVE that the legacy IDE ports are never enabled?
> >>
> >>In modern Intel chipsets, this still occurs with e.g. combined mode.
> > 
> > I don't know about combined mode.  If the legacy IDE ports are
> > enabled, shouldn't they be described via ACPI, and hence usable
> > via the ide_pnp - PNPACPI - ACPI path?
> 
> No idea...  that's more for platform IA64 people to answer :/

OK, well, I assert that failure to describe an IDE device that
uses legacy ports would be an ACPI defect.

Tony, others, does this change give you any heartburn?  On
the 460GX and 870 boxes I have, IDE is a PCI device.

(I have been told that the SGI ia64 simulator depends on
IDE_GENERIC.  But it really should make the IDE device
appear in PCI (or describe it via ACPI)).
-
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/