Re: Latency tests with 2.6.12-rc1

[Lee Revell]

On Sat, 2005-03-19 at 08:08 +0100, Ingo Molnar wrote:
> great! The change in question is most likely the copy_page_range() fix
> that Hugh resurrected:
> 
> ChangeSet 1.2037, 2005/03/08 09:26:46-08:00, [EMAIL PROTECTED]
> 
>   [PATCH] copy_pte_range latency fix
>   
>   Ingo's patch to reduce scheduling latencies, by checking for lockbreak 
> in
>   copy_page_range, was in the -VP and -mm patchsets some months ago; but 
> got
>   preempted by the 4level rework, and not reinstated since. Restore it now
>   in copy_pte_range - which mercifully makes it easier.
> 
> are the ext3 related latencies are gone as well - or are you working it
> around by not using data=ordered?

As a matter of fact the ext3 latencies do not appear to be causing
problems, at least not at those settings, even with data=ordered.

It's impossible to tell much more because the mainline kernel lacks the
instrumentation that the realtime patchset provides.

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: Linux 2.6.11.5

[Greg KH]

diff -Nru a/Makefile b/Makefile
--- a/Makefile  2005-03-18 22:35:14 -08:00
+++ b/Makefile  2005-03-18 22:35:14 -08:00
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 11
-EXTRAVERSION = .4
+EXTRAVERSION = .5
 NAME=Woozy Numbat
 
 # *DOCUMENTATION*
diff -Nru a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
--- a/drivers/net/amd8111e.c2005-03-18 22:35:14 -08:00
+++ b/drivers/net/amd8111e.c2005-03-18 22:35:14 -08:00
@@ -1381,6 +1381,8 @@
 
if(amd8111e_restart(dev)){
spin_unlock_irq(>lock);
+   if (dev->irq)
+   free_irq(dev->irq, dev);
return -ENOMEM;
}
/* Start ipg timer */
diff -Nru a/drivers/net/tun.c b/drivers/net/tun.c
--- a/drivers/net/tun.c 2005-03-18 22:35:14 -08:00
+++ b/drivers/net/tun.c 2005-03-18 22:35:14 -08:00
@@ -229,7 +229,7 @@
size_t len = count;
 
if (!(tun->flags & TUN_NO_PI)) {
-   if ((len -= sizeof(pi)) > len)
+   if ((len -= sizeof(pi)) > count)
return -EINVAL;
 
if(memcpy_fromiovec((void *), iv, sizeof(pi)))
diff -Nru a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
--- a/drivers/net/via-rhine.c   2005-03-18 22:35:14 -08:00
+++ b/drivers/net/via-rhine.c   2005-03-18 22:35:14 -08:00
@@ -1197,8 +1197,10 @@
   dev->name, rp->pdev->irq);
 
rc = alloc_ring(dev);
-   if (rc)
+   if (rc) {
+   free_irq(rp->pdev->irq, dev);
return rc;
+   }
alloc_rbufs(dev);
alloc_tbufs(dev);
rhine_chip_reset(dev);
diff -Nru a/drivers/net/wan/hd6457x.c b/drivers/net/wan/hd6457x.c
--- a/drivers/net/wan/hd6457x.c 2005-03-18 22:35:14 -08:00
+++ b/drivers/net/wan/hd6457x.c 2005-03-18 22:35:14 -08:00
@@ -315,7 +315,7 @@
 #endif
stats->rx_packets++;
stats->rx_bytes += skb->len;
-   skb->dev->last_rx = jiffies;
+   dev->last_rx = jiffies;
skb->protocol = hdlc_type_trans(skb, dev);
netif_rx(skb);
 }
diff -Nru a/kernel/signal.c b/kernel/signal.c
--- a/kernel/signal.c   2005-03-18 22:35:14 -08:00
+++ b/kernel/signal.c   2005-03-18 22:35:14 -08:00
@@ -1728,6 +1728,7 @@
 * with another processor delivering a stop signal,
 * then the SIGCONT that wakes us up should clear it.
 */
+   read_unlock(_lock);
return 0;
}
 
diff -Nru a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
--- a/net/ipv4/fib_hash.c   2005-03-18 22:35:14 -08:00
+++ b/net/ipv4/fib_hash.c   2005-03-18 22:35:14 -08:00
@@ -919,13 +919,23 @@
return fa;
 }
 
+static struct fib_alias *fib_get_idx(struct seq_file *seq, loff_t pos)
+{
+   struct fib_alias *fa = fib_get_first(seq);
+
+   if (fa)
+   while (pos && (fa = fib_get_next(seq)))
+   --pos;
+   return pos ? NULL : fa;
+}
+
 static void *fib_seq_start(struct seq_file *seq, loff_t *pos)
 {
void *v = NULL;
 
read_lock(_hash_lock);
if (ip_fib_main_table)
-   v = *pos ? fib_get_next(seq) : SEQ_START_TOKEN;
+   v = *pos ? fib_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
return v;
 }
 
diff -Nru a/net/netrom/nr_in.c b/net/netrom/nr_in.c
--- a/net/netrom/nr_in.c2005-03-18 22:35:14 -08:00
+++ b/net/netrom/nr_in.c2005-03-18 22:35:14 -08:00
@@ -74,7 +74,6 @@
 static int nr_state1_machine(struct sock *sk, struct sk_buff *skb,
int frametype)
 {
-   bh_lock_sock(sk);
switch (frametype) {
case NR_CONNACK: {
nr_cb *nr = nr_sk(sk);
@@ -103,8 +102,6 @@
default:
break;
}
-   bh_unlock_sock(sk);
-
return 0;
 }
 
@@ -116,7 +113,6 @@
 static int nr_state2_machine(struct sock *sk, struct sk_buff *skb,
int frametype)
 {
-   bh_lock_sock(sk);
switch (frametype) {
case NR_CONNACK | NR_CHOKE_FLAG:
nr_disconnect(sk, ECONNRESET);
@@ -132,8 +128,6 @@
default:
break;
}
-   bh_unlock_sock(sk);
-
return 0;
 }
 
@@ -154,7 +148,6 @@
nr = skb->data[18];
ns = skb->data[17];
 
-   bh_lock_sock(sk);
switch (frametype) {
case NR_CONNREQ:
nr_write_internal(sk, NR_CONNACK);
@@ -265,8 +258,6 @@
default:
break;
}
-   bh_unlock_sock(sk);
-
return queued;
 }
 
diff -Nru a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
--- a/net/xfrm/xfrm_state.c 2005-03-18 22:35:14 -08:00
+++ b/net/xfrm/xfrm_state.c 2005-03-18 22:35:14 -08:00
@@ -609,7 +609,7 @@
 
for (i = 0; i < XFRM_DST_HSIZE; i++) {
list_for_each_entry(x, xfrm_state_bydst+i, bydst) {
-   if (x->km.seq == seq) {
+   if (x->km.seq == seq && x->km.state == XFRM_STATE_ACQ) {
   

Linux 2.6.11.5

[Greg KH]

As the -stable patch review cycle is now over, I've released the
2.6.11.5 kernel in the normal kernel.org places.  One patch was deemed
incorrect, so it was dropped.  Another one was added, within the review
email thread.  So it seems like the process is working so far, which is
refreshing :)

The diffstat and short summary of the fixes are below.  

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

thanks,
 
greg k-h

--
 Makefile|2 +-
 drivers/net/amd8111e.c  |2 ++
 drivers/net/tun.c   |2 +-
 drivers/net/via-rhine.c |4 +++-
 drivers/net/wan/hd6457x.c   |2 +-
 kernel/signal.c |1 +
 net/ipv4/fib_hash.c |   12 +++-
 net/netrom/nr_in.c  |9 -
 net/xfrm/xfrm_state.c   |2 +-
 sound/pci/ac97/ac97_codec.c |   13 -
 10 files changed, 29 insertions(+), 20 deletions(-)


Summary of changes from v2.6.11.4 to v2.6.11.5
==

:
  o Possible AMD8111e free irq issue
  o Possible VIA-Rhine free irq issue

Daniel Drake:
  o Fix stereo mutes on Surround volume control

David S. Miller:
  o [IPSEC]: Fix __xfrm_find_acq_byseq()

Greg Kroah-Hartman:
  o Linux 2.6.11.5

Hugh Dickins:
  o tasklist left locked

Krzysztof Halasa:
  o Fix kernel panic on receive with WAN Hitachi SCA HD6457x

Patrick McHardy:
  o Fix crash while reading /proc/net/route

Ralf Bächle:
  o NetROM locking

Stephen Hemminger:
  o Fix check for underflow

-
To unsubscribe from this list: send the 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: Locking changes to the driver-model core

[Greg KH]

On Wed, Mar 16, 2005 at 03:58:30PM -0500, Alan Stern wrote:
> Greg KH has said that he would like to remove the bus subsystem rwsem from 
> the driver model.  Here's a proposal for a way to accomplish that.  The 
> proposal is incomplete and requires changing the driver-model API a 
> little; I'd like to hear people's reactions and get suggestions on ways to 
> improve it.  (There's no patch with example code because it wouldn't be 
> functional yet.)



It all sounds good, and I think that Pat has some code that implements
almost all of this already (I've seen some rough versions from him
recently.)  Hopefully he'll get that all cleaned up and send it out for
people to beat up on soon (hint...)

thanks,

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

Re: Latency tests with 2.6.12-rc1

[Ingo Molnar]

* Lee Revell <[EMAIL PROTECTED]> wrote:

> I did the same quick latency tests with 2.6.12-rc1 that I posted about
> for 2.6.11 a few weeks ago.
> 
> 2.6.12-rc1 is significantly better than 2.6.11.  Running JACK at 64
> frames (1.3 ms) works very well.  I was not able to produce xruns even
> with "dbench 64", which slows the system to a crawl.  With 2.6.11, I
> could easily produce xruns with much lighter loads.
> 
> It would appear that the latency issues related to the 4 level page
> tables merge have been resolved.

great! The change in question is most likely the copy_page_range() fix
that Hugh resurrected:

ChangeSet 1.2037, 2005/03/08 09:26:46-08:00, [EMAIL PROTECTED]

[PATCH] copy_pte_range latency fix

Ingo's patch to reduce scheduling latencies, by checking for lockbreak 
in
copy_page_range, was in the -VP and -mm patchsets some months ago; but 
got
preempted by the 4level rework, and not reinstated since. Restore it now
in copy_pte_range - which mercifully makes it easier.

are the ext3 related latencies are gone as well - or are you working it
around by not using data=ordered?

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

Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation

[Arjan van de Ven]

On Fri, 2005-03-18 at 15:23 -0600, Matt Domsch wrote:
> For review and comment.
> 
> On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever
> there are any pages mapped above 4GB), pci_alloc_consistent() falls
> back to using ZONE_DMA for all allocations, even if the device's
> dma_mask could have supported using memory from other zones.  Problems
> can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
> all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.

scsi_malloc no longer uses ZONE_DMA nowadays


-
To unsubscribe from this list: send the 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: Buffer I/O error on device hdg1, system freeze.

[Robert Hancock]

Nils Radtke wrote:
Error 14 occurred at disk power-on lifetime: 2249 hours (93 days + 17
hours)
  When the command that caused the error occurred, the device was doing
SMART Offline or Self-test.
  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 f8 23 3e 56 e0  Error: UNC at LBA = 0x00563e23 = 5652003
  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --    
  24 00 f8 07 3e 56 10 00  00:36:28.850  READ SECTOR(S) EXT
  25 00 00 ff 3d 56 10 00  00:36:28.850  READ DMA EXT
  25 00 00 ff 3c 56 10 00  00:36:28.850  READ DMA EXT
  25 00 00 ff 3b 56 10 00  00:36:28.850  READ DMA EXT
  25 00 00 ff 3a 56 10 00  00:36:28.850  READ DMA EXT
Could you please explain what these errors mean exactly and what may
have caused them?
Might it be possible that these transmission/xxx errors be caused 
by a bad card and/or driver?

I'm asking this as the disk never showed errors on onboard IDE ports.
Nils
This error is reported by the drive itself, indicating uncorrectable 
errors when attempting to read data from the media. It is quite unlikely 
that the controller or driver is responsible for this sort of error, as 
can occasionally be the case for DMA timeout errors. Almost certainly 
the hard drive is failing.

--
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 07/12] Make the PCI remove routines safe for failed hot-plug

[Greg KH]

On Fri, Mar 18, 2005 at 02:11:44PM -0800, Rajesh Shah wrote:
> diff -puN drivers/pci/remove.c~pci-remove-device-hotplug-safe 
> drivers/pci/remove.c
> --- linux-2.6.11-mm4-iohp/drivers/pci/remove.c~pci-remove-device-hotplug-safe 
> 2005-03-16 13:07:22.667319764 -0800
> +++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c 2005-03-16 
> 13:07:22.775718200 -0800
> @@ -26,17 +26,21 @@ static void pci_free_resources(struct pc
>  
>  static void pci_destroy_dev(struct pci_dev *dev)
>  {
> - pci_proc_detach_device(dev);
> - pci_remove_sysfs_dev_files(dev);
> - device_unregister(>dev);
> + if (!list_empty(>global_list)) {
> + pci_proc_detach_device(dev);
> + pci_remove_sysfs_dev_files(dev);
> + device_unregister(>dev);
> + spin_lock(_bus_lock);
> + list_del(>global_list);
> + dev->global_list.next = dev->global_list.prev = NULL;
> + spin_unlock(_bus_lock);
> + }
>  
>   /* Remove the device from the device lists, and prevent any further
>* list accesses from this device */
>   spin_lock(_bus_lock);
>   list_del(>bus_list);
> - list_del(>global_list);
>   dev->bus_list.next = dev->bus_list.prev = NULL;
> - dev->global_list.next = dev->global_list.prev = NULL;
>   spin_unlock(_bus_lock);
>  
>   pci_free_resources(dev);

I did have a comment about this code at first glance, but in reviewing
it again, nevermind, it looks fine...

thanks,

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

Re: [RFC/Patch 0/12] ACPI based root bridge hot-add

[Greg KH]

On Fri, Mar 18, 2005 at 01:38:57PM -0800, Rajesh Shah wrote:
> Here is a series of patches to support ACPI hot-add of a root
> bridge hierarchy. The added hierarchy may contain other p2p 
> bridges and end/leaf I/O devices too. The root bridge itself is
> assumed to have been assigned resource ranges, but the p2p
> bridges and end devices are not required to be initialized by
> firmware. Most of the code changes are to make the existing code
> flows suitable for such a hierarchy of bridges & devices.
> 
> This code supports hot-add on ia64 only for now.It does not yet
> support I/O APIC hot-add, which is needed to make this fully
> functional.  The patches are against 2.6.11-mm4 (plus the patch 
> needed for ia64 to boot). I've tested to make sure this does not 
> break end/leaf device hotplug on the hotplug capable ia64 box I have.

This all looks very good, nice job.  I only had one minor comment on the
patches, which I'll reply to directly.

But I did have a few questions:
- This series relys on Mathew's rewrite of the acpiphp driver.
  Is that acceptable?  Is that patch necessary for your work?
  And if so, can you include it in the whole series?
- Does this break the i386 acpiphp functionality?
- Have you tested other pci hotplug systems with this patch
  series?  Like pci express hotplug, standard pci hotplug,
  cardbus, etc?
- Are you wanting the acpi specific patches to go into the tree
  through the acpi developers?  How about the ia64 specific
  patches?
- Have the acpi developers agreed with your acpi patches?

thanks,

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

Re: Real-Time Preemption and RCU

[Manfred Spraul]

Ingo Molnar wrote:
read_lock();
...
read_lock();
are still legal. (it's also done quite often.)
 

How do you handle the write_lock_irq()/read_lock locks?
E.g. the tasklist_lock or the fasync_lock.
--
   Manfred
-
To unsubscribe from this list: send the 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] alpha build fixes

[Jeff Garzik]

Needed this to build Fedora rawhide kernel (2.6.12-rc1 + some patches) 
on alpha.  This is the upstream portion of the build fixes.

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff -urN ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/agp/generic.c linux-2.6.11/drivers/char/agp/generic.c
--- ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/agp/generic.c	2005-03-18 16:45:23.0 -0500
+++ linux-2.6.11/drivers/char/agp/generic.c	2005-03-18 18:34:00.0 -0500
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff -urN ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/pci.h linux-2.6.11/include/asm-alpha/pci.h
--- ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/pci.h	2005-03-02 02:38:34.0 -0500
+++ linux-2.6.11/include/asm-alpha/pci.h	2005-03-18 18:39:31.0 -0500
@@ -223,6 +223,12 @@
 	/* Nothing to do. */
 }
 
+/* TODO: integrate with include/asm-generic/pci.h ? */
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+	return channel ? 15 : 14;
+}
+
 extern void pcibios_resource_to_bus(struct pci_dev *, struct pci_bus_region *,
 struct resource *);
 
diff -urN ../kernel-2.6.11.orig/linux-2.6.11/include/linux/debugfs.h linux-2.6.11/include/linux/debugfs.h
--- ../kernel-2.6.11.orig/linux-2.6.11/include/linux/debugfs.h	2005-03-02 02:38:33.0 -0500
+++ linux-2.6.11/include/linux/debugfs.h	2005-03-18 18:14:12.0 -0500
@@ -15,6 +15,8 @@
 #ifndef _DEBUGFS_H_
 #define _DEBUGFS_H_
 
+#include 
+
 #if defined(CONFIG_DEBUG_FS)
 struct dentry *debugfs_create_file(const char *name, mode_t mode,
    struct dentry *parent, void *data,
diff -ur ../kernel-2.6.11.orig/linux-2.6.11/drivers/atm/lanai.c linux-2.6.11/drivers/atm/lanai.c
--- ../kernel-2.6.11.orig/linux-2.6.11/drivers/atm/lanai.c	2005-03-18 20:06:31.0 -0500
+++ linux-2.6.11/drivers/atm/lanai.c	2005-03-18 20:36:19.0 -0500
@@ -61,6 +61,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff -ur ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/tpm/tpm.h linux-2.6.11/drivers/char/tpm/tpm.h
--- ../kernel-2.6.11.orig/linux-2.6.11/drivers/char/tpm/tpm.h	2005-03-18 20:06:31.0 -0500
+++ linux-2.6.11/drivers/char/tpm/tpm.h	2005-03-18 20:50:31.0 -0500
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define TPM_TIMEOUT msecs_to_jiffies(5)

[PATCH 2.4.30-pre3] x86_64: move init_tss declaration after tss_struct definition

[Matt Domsch]

Compiling 2.4.30-pre3 for x86_64 with FC4-test1 gcc-4.0.0-0.32 fails
because include/asm-x86_64/processor.h declares init_tss[NR_CPUS] as a
sized array before struct tss_struct has been defined.  Simple fix
moves this declaration to after the definition of tss_struct.

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

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

= include/asm-x86_64/processor.h 1.9 vs edited =
--- 1.9/include/asm-x86_64/processor.h  2004-03-21 18:35:56 -06:00
+++ edited/include/asm-x86_64/processor.h   2005-03-18 14:56:30 -06:00
@@ -68,7 +68,6 @@
 #define X86_VENDOR_UNKNOWN 0xff
 
 extern struct cpuinfo_x86 boot_cpu_data;
-extern struct tss_struct init_tss[NR_CPUS];
 
 #ifdef CONFIG_SMP
 extern struct cpuinfo_x86 cpu_data[];
@@ -298,6 +297,8 @@
u16 io_map_base;
u32 io_bitmap[IO_BITMAP_SIZE];
 } __attribute__((packed)) cacheline_aligned;
+
+extern struct tss_struct init_tss[NR_CPUS];
 
 struct thread_struct {
unsigned long   rsp0;
-
To unsubscribe from this list: send the 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] arch hook for notifying changes in PTE protections bits

[David S. Miller]

This is way overkill I think.

Take a look at set_pte_at().  You get the "mm", the
virtual address, the pte pointer, and the new pte value.

What else could you possibly need to track stuff like this
and react appropriately? :-)

It is even an argument for batched TLB processing on ia64.
It simplifies a lot of cache flushing issues and you can
control the flushing on a per-translation basis however
you like.
-
To unsubscribe from this list: send the 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/

Latency tests with 2.6.12-rc1

[Lee Revell]

I did the same quick latency tests with 2.6.12-rc1 that I posted about
for 2.6.11 a few weeks ago.

2.6.12-rc1 is significantly better than 2.6.11.  Running JACK at 64
frames (1.3 ms) works very well.  I was not able to produce xruns even
with "dbench 64", which slows the system to a crawl.  With 2.6.11, I
could easily produce xruns with much lighter loads.

It would appear that the latency issues related to the 4 level page
tables merge have been resolved.

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: Fix agp_backend usage in drm_agp_init (was: 2.6.11-mm3 - DRM/i915 broken)

[Jesse Barnes]

On Friday, March 18, 2005 7:40 pm, Jesse Barnes wrote:
> What does your patch look like?  Markus might like to try it out as he
> narrowed his problem down to something AGP related recently too:
> http://bugme.osdl.org/show_bug.cgi?id=4337

duh, ignore me.  At least Markus can give it a try.

Jesse
-
To unsubscribe from this list: send the 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: Kmap_atomic vs Kmap

[Andrew Morton]

Phillip Lougher <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote in relation to my initial SquashFS patch:
> > Phillip Lougher <[EMAIL PROTECTED]> wrote:
> > 
> >>+skip_read:
> >>+   memset(pageaddr + bytes, 0, PAGE_CACHE_SIZE - bytes);
> >>+   kunmap(page);
> >>+   flush_dcache_page(page);
> >>+   SetPageUptodate(page);
> >>+   unlock_page(page);
> >>+
> >>+   return 0;
> >>+}
> 
> > See if you can use kmap_atomic() here - kmap() is slow, theoretically
> > deadlocky and is deprecated.
> > 
> 
>  From some browsing of the kernel source and a useful article on lwn.net 
> I think I can replace all the readpage_xxx (symlink, readpage & 
> readpage4k) kmap/kunmaps with kmap_atomic(page, KM_USER0)/kunmap(kaddr, 
> KM_USER0)...

Yes.

Generally the only reason the kernel needs to modify pagecache pages is to
do a quick memset or to copy a string in there or something like that.  So
a quick kmap_atomic/memory copy/kunmap_atomic() cycle is a fairly common
pattern.

The one exception is the directory-in-pagecache code where we tend to do a
lot of stuff while holding the kmap.  Not that there's any particular
reason why we needed to do it that way.

> The lwn.net article mentions that k[un]map_atomic is the new alternative 
> to kmap (as Andrew Morton mentioned).
> 
> I've noticed in asm-ppc/highmem.h the following comment
> 
> /*
>   * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
>   * gives a more generic (and caching) interface. But kmap_atomic can
>   * be used in IRQ contexts, so in some (very limited) cases we need
>   * it.
>   */
> 
> Given what Andrew and the lwn.net article says, this comment is rather 
> confusing.  Is it wrong?

I'd say so, yes.  For a start, kmap_high() takes a global 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/

Re: Fix agp_backend usage in drm_agp_init (was: 2.6.11-mm3 - DRM/i915 broken)

[Jesse Barnes]

On Friday, March 18, 2005 6:45 pm, Brice Goglin wrote:
> agpioc_acquire_wrap is called, it increments the agp_in_use. Then (before
> agpioc_release_wrap happens), drm_agp_init is called (I don't know how).
> drm_agp_init uses agp_backend_acquire which fails because agp_in_use is
> non-null (hold by agpioc_acquire_wrap).
>
> The multi-bridge AGP patch actually changed drm_agp_init by adding
> agp_backend_acquire/release around agp_copy_info.
> It is why drm_agp_init fails now while it worked before.
>
> I don't think we need to "acquire" it during agp_copy_info.
> Why don't we just get a pointer to the bridge instead ?
> (is there any chance this bridge gets deleted during drm_agp_init ?)
> That's what the attached patch implements on top of 2.6.12-rc1.
>
> I chose to add a new agp_backend_find() function, but we might also
> directly call agp_find_bridge() from drm_agp_init(). I don't know what's
> the best.
>
> I'm not familiar enough with DRM/AGP code to understand everything here.
> I might be missing something...

What does your patch look like?  Markus might like to try it out as he 
narrowed his problem down to something AGP related recently too:
http://bugme.osdl.org/show_bug.cgi?id=4337

Thanks,
Jesse
-
To unsubscribe from this list: send the 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/

Kmap_atomic vs Kmap

[Phillip Lougher]

Andrew Morton wrote in relation to my initial SquashFS patch:
Phillip Lougher <[EMAIL PROTECTED]> wrote:
+skip_read:
+   memset(pageaddr + bytes, 0, PAGE_CACHE_SIZE - bytes);
+   kunmap(page);
+   flush_dcache_page(page);
+   SetPageUptodate(page);
+   unlock_page(page);
+
+   return 0;
+}

See if you can use kmap_atomic() here - kmap() is slow, theoretically
deadlocky and is deprecated.
From some browsing of the kernel source and a useful article on lwn.net 
I think I can replace all the readpage_xxx (symlink, readpage & 
readpage4k) kmap/kunmaps with kmap_atomic(page, KM_USER0)/kunmap(kaddr, 
KM_USER0)...

The lwn.net article mentions that k[un]map_atomic is the new alternative 
to kmap (as Andrew Morton mentioned).

I've noticed in asm-ppc/highmem.h the following comment
/*
 * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
 * gives a more generic (and caching) interface. But kmap_atomic can
 * be used in IRQ contexts, so in some (very limited) cases we need
 * it.
 */
Given what Andrew and the lwn.net article says, this comment is rather 
confusing.  Is it wrong?

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

Linux 2.4.30-rc1

[Marcelo Tosatti]

Here goes the first release candidate for v2.4.30. 

It contains a small number of fixes, including a fix for 
recently discovered ppp DoS (CAN-2005-0384).


Summary of changes from v2.4.30-pre3 to v2.4.30-rc1


:
  o [SPARC32]: Fix build dependencies for vmlinux.o
  o [SPARC32]: Fix sun4d sbus and current handling
  o [SPARC32]: sun4d needs ZS_WSYNC() zilog reg flushing too

:
  o [SPARC64]: Fix semtimedop compat ipc code

:
  o Fix softdog no reboot on unexpected close

Alan Hourihane:
  o agpgart Intel i915GM ID's and tweaks

Andrea Arcangeli:
  o Write throttling should not take free highmem into account

Chris Wedgwood:
  o early boot code references check_acpi_pci()

Linus Torvalds:
  o Workaround possible pty line discipline race

Marcelo Tosatti:
  o Andrea Arcangeli: get_user_pages() shall not grab PG_reserved pages
  o Paul Mackerras: Remote Linux DoS on ppp servers (CAN-2005-0384)
  o Change VERSION to 2.4.30-rc1

Roland McGrath:
  o i386/x86_64 fpu: fix x87 tag word simulation using fxsave

Solar Designer:
  o Enable gcc warnings for vsprintf/vsnprintf with "format" attribute

Stephen Hemminger:
  o TCP BIC not binary searching correctly

Willy Tarreau:
  o acpi.h needs 

-
To unsubscribe from this list: send the 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: [ACPI] Re: [BKPATCH] ACPI for 2.6.12-rc1

[Sérgio Monteiro Basto]

Andrew Morton wrote:
Romano Giannetti <[EMAIL PROTECTED]> wrote:
Could I humble advocating pushing the patch 
http://bugme.osdl.org/attachment.cgi?id=4516=view ,please? It fixed a
very bad regression in hotkey event from 2.6.9...

What bug number is that actually
attached to?  

http://bugme.osdl.org/show_bug.cgi?id=3851
There seems to be no way to go backwards from the URL.
search for id=4516 on Description/Comment:
on ACPI with all componenets and all status .
thanks,

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

Re: [BKPATCH] ACPI for 2.6.12-rc1

[Len Brown]

On Fri, 2005-03-18 at 18:21, Andrew Morton wrote:
> Romano Giannetti <[EMAIL PROTECTED]> wrote:
> >
> > Could I humble advocating pushing the patch
> >  http://bugme.osdl.org/attachment.cgi?id=4516=view ,please?
> It fixed a
> >  very bad regression in hotkey event from 2.6.9...
> 
> It seems to not be in ACPI bk yet.  What bug number is that actually
> attached to?  There seems to be no way to go backwards from the URL.


Yes, this is an important fix, and I'll be pushing
it up to-akpm tonight along with a bucket-full of
other important fixes.  The push to Linus yesterday
was to clear the pipeline for this next batch, which
should hopefully also make 2.6.12.

cheers,
-Len

ps. You can query bugzilla for comments containing string "id=4516"
and you find this is Luming's burst-mode EC patch:
http://bugzilla.kernel.org/show_bug.cgi?id=3851


-
To unsubscribe from this list: send the 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/

Fix agp_backend usage in drm_agp_init (was: 2.6.11-mm3 - DRM/i915 broken)

[Brice Goglin]

Dave Airlie wrote:
DRM/i915 does not work on my Dell Dimension 3000 (i865 chipset).
This is more than likely caused by the multi-bridge AGP stuff in -bk3
Yes, that's it! The bug appeared in -mm when the multi-bridge AGP stuff
was merged (2.6.10-mm3). It is still here in 2.6.12-rc1.
Here's the scenario I think I'm seeing:
agpioc_acquire_wrap is called, it increments the agp_in_use. Then (before
agpioc_release_wrap happens), drm_agp_init is called (I don't know how).
drm_agp_init uses agp_backend_acquire which fails because agp_in_use is
non-null (hold by agpioc_acquire_wrap).
The multi-bridge AGP patch actually changed drm_agp_init by adding
agp_backend_acquire/release around agp_copy_info.
It is why drm_agp_init fails now while it worked before.
I don't think we need to "acquire" it during agp_copy_info.
Why don't we just get a pointer to the bridge instead ?
(is there any chance this bridge gets deleted during drm_agp_init ?)
That's what the attached patch implements on top of 2.6.12-rc1.
I chose to add a new agp_backend_find() function, but we might also
directly call agp_find_bridge() from drm_agp_init(). I don't know what's
the best.
I'm not familiar enough with DRM/AGP code to understand everything here.
I might be missing something...
Regards,
Brice
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
--- linux-rc/include/linux/agp_backend.h.old2005-03-19 
03:26:36.0 +0100
+++ linux-rc/include/linux/agp_backend.h2005-03-19 03:35:43.0 
+0100
@@ -102,6 +102,7 @@ extern int agp_copy_info(struct agp_brid
 extern int agp_bind_memory(struct agp_memory *, off_t);
 extern int agp_unbind_memory(struct agp_memory *);
 extern void agp_enable(struct agp_bridge_data *, u32);
+extern struct agp_bridge_data *agp_backend_find(struct pci_dev *);
 extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *);
 extern void agp_backend_release(struct agp_bridge_data *);
--- linux-rc/drivers/char/agp/backend.c.old 2005-03-19 03:30:32.0 
+0100
+++ linux-rc/drivers/char/agp/backend.c 2005-03-19 03:35:24.0 +0100
@@ -58,6 +58,12 @@ LIST_HEAD(agp_bridges);
 EXPORT_SYMBOL(agp_bridge);
 EXPORT_SYMBOL(agp_bridges);
+struct agp_bridge_data *agp_backend_find(struct pci_dev *pdev)
+{
+   return agp_find_bridge(pdev);
+}
+EXPORT_SYMBOL(agp_backend_find);
+
 /**
  * agp_backend_acquire  -  attempt to acquire an agp backend.
  *
@@ -66,7 +72,7 @@ struct agp_bridge_data *agp_backend_acqu
 {
struct agp_bridge_data *bridge;
-   bridge = agp_find_bridge(pdev);
+   bridge = agp_backend_find(pdev);
if (!bridge)
return NULL;
--- linux-rc/drivers/char/drm/drm_agpsupport.c.old  2005-03-19 
03:29:50.0 +0100
+++ linux-rc/drivers/char/drm/drm_agpsupport.c  2005-03-19 03:34:28.0 
+0100
@@ -387,12 +387,11 @@ drm_agp_head_t *drm_agp_init(drm_device_
if (!(head = drm_alloc(sizeof(*head), DRM_MEM_AGPLISTS)))
return NULL;
memset((void *)head, 0, sizeof(*head));
-   if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
+   if (!(head->bridge = agp_backend_find(dev->pdev))) {
drm_free(head, sizeof(*head), DRM_MEM_AGPLISTS);
return NULL;
}
agp_copy_info(head->bridge, >agp_info);
-   agp_backend_release(head->bridge);
if (head->agp_info.chipset == NOT_SUPPORTED) {
drm_free(head, sizeof(*head), DRM_MEM_AGPLISTS);
return 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/

Re: [PATCH][RFC] /proc umask and gid [was: Make /proc/ chmod'able]

[Rene Scharfe]

On Tue, Mar 15, 2005 at 11:41:28PM -0500, Albert Cahalan wrote:
> Better interface:
> 
> /sbin/sysctl -w proc.maps=0440
> /sbin/sysctl -w proc.cmdline=0444
> /sbin/sysctl -w proc.status=0444

Indeed it is, but it's much harder to implement.

Patch is against 2.6.11-mm3 but works with -mm4, too.  I only made the
permissions configurable for some of the files, more can be added easily
if and when needed.

It's uglier than it needs to be, but before cleaning it up I'll go and
get some sleep.

Comments and patches much appreciated! :)

Rene



diff -pur linux-2.6.11-mm3/fs/proc/base.c l5/fs/proc/base.c
--- linux-2.6.11-mm3/fs/proc/base.c 2005-03-12 19:23:36.0 +0100
+++ l5/fs/proc/base.c   2005-03-19 01:08:40.0 +0100
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 
 /*
@@ -1419,6 +1420,93 @@ static struct file_operations proc_tgid_
 static struct inode_operations proc_tgid_attr_inode_operations;
 #endif
 
+static struct pid_entry *proc_base_entry_by_name(struct pid_entry *ents,
+ struct qstr *name)
+{
+   struct pid_entry *p;
+
+   for (p = ents; p->name; p++) {
+   if (p->len != name->len)
+   continue;
+   if (!memcmp(name->name, p->name, p->len))
+   return p;
+   }
+   return NULL;
+}
+
+#ifdef CONFIG_SYSCTL
+struct proc_sysctl_info {
+   int type;
+   mode_t mode;
+};
+
+/* order must match the CTL_PROC table in sysctl.h */
+struct proc_sysctl_info proc_base_permissions[] = {
+   {PROC_TGID_CMDLINE, S_IRUGO},
+   {PROC_TGID_MAPS,S_IRUGO},
+   {PROC_TGID_STAT,S_IRUGO},
+   {PROC_TGID_STATM,   S_IRUGO},
+   {PROC_TGID_STATUS,  S_IRUGO},
+   {0, 0}
+};
+
+static inline int is_system_task(struct task_struct *task)
+{
+   int rc = 0;
+
+   if (task->pid == 1)
+   rc = 1;
+   // TODO: kernel threads?
+   return rc;
+}
+
+static void proc_update_mode(mode_t *mode, int type, struct task_struct *task)
+{
+   struct proc_sysctl_info *s;
+
+   if (is_system_task(task))
+   return;
+   for (s = proc_base_permissions; s->type; s++) {
+   if (s->type == type) {
+   *mode = (*mode & ~S_IALLUGO) | s->mode;
+   break;
+   }
+   }
+}
+
+static int proc_base_permission(struct inode *inode, int mask,
+struct nameidata *nd)
+{
+   struct task_struct *task = proc_task(inode);
+   struct pid_entry *p;
+
+   p = proc_base_entry_by_name(tgid_base_stuff, >dentry->d_name);
+   if (p)
+   proc_update_mode(>i_mode, p->type, task);
+   return generic_permission(inode, mask, NULL);
+}
+
+static int proc_base_getattr(struct vfsmount *mnt, struct dentry *dentry,
+ struct kstat *stat)
+{
+   struct inode *inode = dentry->d_inode;
+   struct task_struct *task = proc_task(inode);
+   struct pid_entry *p;
+
+   generic_fillattr(inode, stat);
+   p = proc_base_entry_by_name(tgid_base_stuff, >d_name);
+   if (p)
+   proc_update_mode(>i_mode, p->type, task);
+   return 0;
+}
+
+static struct inode_operations proc_base_inode_operations = {
+   .getattr= proc_base_getattr,
+   .permission = proc_base_permission,
+};
+
+#endif /* CONFIG_SYSCTL */
+
 /* SMP-safe */
 static struct dentry *proc_pident_lookup(struct inode *dir, 
 struct dentry *dentry,
@@ -1436,13 +1524,8 @@ static struct dentry *proc_pident_lookup
if (!pid_alive(task))
goto out;
 
-   for (p = ents; p->name; p++) {
-   if (p->len != dentry->d_name.len)
-   continue;
-   if (!memcmp(dentry->d_name.name, p->name, p->len))
-   break;
-   }
-   if (!p->name)
+   p = proc_base_entry_by_name(ents, >d_name);
+   if (p == NULL)
goto out;
 
error = -EINVAL;
@@ -1452,6 +1535,10 @@ static struct dentry *proc_pident_lookup
 
ei = PROC_I(inode);
inode->i_mode = p->mode;
+#ifdef CONFIG_SYSCTL
+   proc_update_mode(>i_mode, p->type, task);
+   inode->i_op = _base_inode_operations;
+#endif
/*
 * Yes, it does not scale. And it should not. Don't add
 * new entries into /proc// without very good reasons.
diff -pur linux-2.6.11-mm3/include/linux/sysctl.h l5/include/linux/sysctl.h
--- linux-2.6.11-mm3/include/linux/sysctl.h 2005-03-12 19:23:37.0 
+0100
+++ l5/include/linux/sysctl.h   2005-03-18 23:40:59.0 +0100
@@ -654,6 +654,13 @@ enum {
 };
 
 /* CTL_PROC names: */
+enum {
+   PROC_CMDLINE= 1,
+   PROC_MAPS   = 2,
+   PROC_STAT   = 3,
+   PROC_STATM  = 4,
+   PROC_STATUS = 5,
+};
 
 /* CTL_FS names: */
 enum
diff -pur 

Re: [2.6.11-mm3] umount: Scheduling while atomic

[Andrew Morton]

Alexander Gran <[EMAIL PROTECTED]> wrote:
>
> while umounting an ext2 partition on a usb hdd I'm getting:
>  scheduling while atomic: umount/0x1001/14941
>   [] schedule+0x5f2/0x600
>   [] cond_resched+0x27/0x40
>   [] invalidate_mapping_pages+0x81/0xe0
>   [] kill_bdev+0xd/0x20
>   [] __set_blocksize+0x85/0xa0
>   [] __bd_release+0x70/0x80
>   [] __close_bdev_excl+0x8/0x10
>   [] deactivate_super+0x50/0x80
>   [] sys_umount+0x3b/0x90
>   [] do_munmap+0x120/0x150
>   [] sys_oldumount+0x15/0x20
>   [] sysenter_past_esp+0x54/0x75

hm, yes, that was a bug in blockdev-fixes-race-between-mount-umount.patch,
but that patch got dropped because Linus fixed things differently.

-
To unsubscribe from this list: send the 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: Real-life pci errors (Was: Re: PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC]PCIErrorRecovery)

[Benjamin Herrenschmidt]

On Fri, 2005-03-18 at 18:35 -0600, Linas Vepstas wrote:
> On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to 
> remark:
> > 
> > Additionally, in "real life", very few errors are cause by known errata.
> > If the drivers know about the errata, they usually already work around
> > them. Afaik, most of the errors are caused by transcient conditions on
> > the bus or the device, like a bit beeing flipped, or thermal
> > conditions... 
> 
> 
> Heh. Let me describe "real life" a bit more accurately.
> 
> We've been running with pci error detection enabled here for the last
> two years.  Based on this experience, the ballpark figures are:
> 
> 90% of all detected errors were device driver bugs coupled to 
> pci card hardware errata

Well, this have been in-lab testing to fight driver bugs/errata on early
rlease kernels, I'm talking about the context of a released solution
with stable drivers/hw.

> 9% poorly seated pci cards (remove/reseat will make problem go away)
> 
> 1% transient/other.

Ok.

> We've seen *EVERY* and I mean *EVERY* device driver that we've put
> under stress tests (e.g. peak i/o rates for > 72 hours, e.g. 
> massive tcp/nfs traffic, massive disk i/o traffic, etc), *EVERY*
> driver tripped on an EEH error detect that was traced back to 
> a device driver bug.  Not to blame the drivers, a lot of these
> were related to pci card hardware/foirmware bugs.  For example, 
> I think grepping for "split completion" and "NAPI" in the 
> patches/errata for e100 and e1000 for the last year will reveal 
> some of the stuff that was found.  As far as I know,
> for every bug found, a patch made it into mainline.

Yah, those are a pain. But then, it isn't the context described by
Nguyen where the driver "knows" about the errata and how to recover.
It's the context of a bug where the driver does not know what's going on
and/or doesn't have the proper workaround. My point was more that there
are very few cases where a driver will have to do recovery of PCI error
in known cases where it actually expect an error to happen.

> As a rule, it seems that finding these device driver bugs was
> very hard; we had some people work on these for months, and in 
> the case of the e1000, we managed to get Intel engineers to fly
> out here and stare at PCI bus traces for a few days.  (Thanks Intel!)
> Ditto for Emulex.  For ipr, we had inhouse people.
> 
> So overall, PCI error detection did have the expected effect 
> (protecting the kernel from corruption, e.g. due to DMA's going 
> to wild addresses), but I don't think anybody expected that the
> vast majority would be software/hardware bugs, instead of transient 
> effects.
> 
> What's ironic in all of this is that by adding error recovery,
> device driver bugs will be able to hide more effectively ... 
> if there's a pci bus error due to a driver bug, the pci card
> will get rebooted, the kernel will burp for 3 seconds, and 
> things will keep going, and most sysadmins won't notice or 
> won't care.

Yes, but it will be logged at least, so we'll spot a lot of these during
our tests.

Ben.


-
To unsubscribe from this list: send the 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: Real-Time Preemption and RCU

[Paul E. McKenney]

On Fri, Mar 18, 2005 at 02:22:30PM -0800, Paul E. McKenney wrote:
> On Fri, Mar 18, 2005 at 12:35:17PM -0800, Paul E. McKenney wrote:
> > Compiles, probably dies horribly.  "diff" didn't do such a good job
> > on this one, so attaching the raw rcupdate.[hc] files as well.
> 
> My prediction was all too accurate.  ;-)
> 
> The attached patch at least boots on a 1-CPU x86 box.  I added some
> interrupt disabling that is a bad idea in real-time preempt kernels,
> but necessary for stock kernels to even have a ghost of a chance.
> 
> Again, the diff is quite confusing to read (for me, anyway!), so attached
> the rcupdate.[hc] files.
> 
> Assuming this patch survives the LTP run (hah!!!), next step is a small
> SMP system.

It did survive the UP LTP run, here is an updated patch with a fix needed
for SMP.  Having trouble with test system (independent of this patch),
hopefully will get more testing in over the weekend.

Thanx, Paul
 
Signed-off-by: <[EMAIL PROTECTED]>

diff -urpN -X ../dontdiff linux-2.5/include/linux/rcupdate.h 
linux-2.5-rtRCU/include/linux/rcupdate.h
--- linux-2.5/include/linux/rcupdate.h  Wed Mar  9 12:37:06 2005
+++ linux-2.5-rtRCU/include/linux/rcupdate.hFri Mar 18 11:37:02 2005
@@ -58,169 +58,11 @@ struct rcu_head {
(ptr)->next = NULL; (ptr)->func = NULL; \
 } while (0)
 
-
-
-/* Global control variables for rcupdate callback mechanism. */
-struct rcu_ctrlblk {
-   longcur;/* Current batch number.  */
-   longcompleted;  /* Number of the last completed batch */
-   int next_pending;   /* Is the next batch already waiting? */
-} cacheline_maxaligned_in_smp;
-
-/* Is batch a before batch b ? */
-static inline int rcu_batch_before(long a, long b)
-{
-return (a - b) < 0;
-}
-
-/* Is batch a after batch b ? */
-static inline int rcu_batch_after(long a, long b)
-{
-return (a - b) > 0;
-}
-
-/*
- * Per-CPU data for Read-Copy UPdate.
- * nxtlist - new callbacks are added here
- * curlist - current batch for which quiescent cycle started if any
- */
-struct rcu_data {
-   /* 1) quiescent state handling : */
-   longquiescbatch; /* Batch # for grace period */
-   int passed_quiesc;   /* User-mode/idle loop etc. */
-   int qs_pending;  /* core waits for quiesc state */
-
-   /* 2) batch handling */
-   longbatch;   /* Batch # for current RCU batch */
-   struct rcu_head *nxtlist;
-   struct rcu_head **nxttail;
-   struct rcu_head *curlist;
-   struct rcu_head **curtail;
-   struct rcu_head *donelist;
-   struct rcu_head **donetail;
-   int cpu;
-};
-
-DECLARE_PER_CPU(struct rcu_data, rcu_data);
-DECLARE_PER_CPU(struct rcu_data, rcu_bh_data);
-extern struct rcu_ctrlblk rcu_ctrlblk;
-extern struct rcu_ctrlblk rcu_bh_ctrlblk;
-
-/*
- * Increment the quiescent state counter.
- * The counter is a bit degenerated: We do not need to know
- * how many quiescent states passed, just if there was at least
- * one since the start of the grace period. Thus just a flag.
- */
-static inline void rcu_qsctr_inc(int cpu)
-{
-   struct rcu_data *rdp = _cpu(rcu_data, cpu);
-   rdp->passed_quiesc = 1;
-}
-static inline void rcu_bh_qsctr_inc(int cpu)
-{
-   struct rcu_data *rdp = _cpu(rcu_bh_data, cpu);
-   rdp->passed_quiesc = 1;
-}
-
-static inline int __rcu_pending(struct rcu_ctrlblk *rcp,
-   struct rcu_data *rdp)
-{
-   /* This cpu has pending rcu entries and the grace period
-* for them has completed.
-*/
-   if (rdp->curlist && !rcu_batch_before(rcp->completed, rdp->batch))
-   return 1;
-
-   /* This cpu has no pending entries, but there are new entries */
-   if (!rdp->curlist && rdp->nxtlist)
-   return 1;
-
-   /* This cpu has finished callbacks to invoke */
-   if (rdp->donelist)
-   return 1;
-
-   /* The rcu core waits for a quiescent state from the cpu */
-   if (rdp->quiescbatch != rcp->cur || rdp->qs_pending)
-   return 1;
-
-   /* nothing to do */
-   return 0;
-}
-
-static inline int rcu_pending(int cpu)
-{
-   return __rcu_pending(_ctrlblk, _cpu(rcu_data, cpu)) ||
-   __rcu_pending(_bh_ctrlblk, _cpu(rcu_bh_data, cpu));
-}
-
-/**
- * rcu_read_lock - mark the beginning of an RCU read-side critical section.
- *
- * When synchronize_kernel() is invoked on one CPU while other CPUs
- * are within RCU read-side critical sections, then the
- * synchronize_kernel() is guaranteed to block until after all the other
- * CPUs exit their critical sections.  Similarly, if call_rcu() is invoked
- * on one CPU while other CPUs are within RCU read-side critical
- * sections, invocation of the corresponding RCU callback is deferred
- * until after the all the other CPUs exit 

Real-life pci errors (Was: Re: PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC]PCIErrorRecovery)

[Linas Vepstas]

On Sat, Mar 19, 2005 at 10:13:02AM +1100, Benjamin Herrenschmidt was heard to 
remark:
> 
> Additionally, in "real life", very few errors are cause by known errata.
> If the drivers know about the errata, they usually already work around
> them. Afaik, most of the errors are caused by transcient conditions on
> the bus or the device, like a bit beeing flipped, or thermal
> conditions... 


Heh. Let me describe "real life" a bit more accurately.

We've been running with pci error detection enabled here for the last
two years.  Based on this experience, the ballpark figures are:

90% of all detected errors were device driver bugs coupled to 
pci card hardware errata

9% poorly seated pci cards (remove/reseat will make problem go away)

1% transient/other.


We've seen *EVERY* and I mean *EVERY* device driver that we've put
under stress tests (e.g. peak i/o rates for > 72 hours, e.g. 
massive tcp/nfs traffic, massive disk i/o traffic, etc), *EVERY*
driver tripped on an EEH error detect that was traced back to 
a device driver bug.  Not to blame the drivers, a lot of these
were related to pci card hardware/foirmware bugs.  For example, 
I think grepping for "split completion" and "NAPI" in the 
patches/errata for e100 and e1000 for the last year will reveal 
some of the stuff that was found.  As far as I know,
for every bug found, a patch made it into mainline.

As a rule, it seems that finding these device driver bugs was
very hard; we had some people work on these for months, and in 
the case of the e1000, we managed to get Intel engineers to fly
out here and stare at PCI bus traces for a few days.  (Thanks Intel!)
Ditto for Emulex.  For ipr, we had inhouse people.

So overall, PCI error detection did have the expected effect 
(protecting the kernel from corruption, e.g. due to DMA's going 
to wild addresses), but I don't think anybody expected that the
vast majority would be software/hardware bugs, instead of transient 
effects.

What's ironic in all of this is that by adding error recovery,
device driver bugs will be able to hide more effectively ... 
if there's a pci bus error due to a driver bug, the pci card
will get rebooted, the kernel will burp for 3 seconds, and 
things will keep going, and most sysadmins won't notice or 
won't care.

--linas

-
To unsubscribe from this list: send the 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: fix-u32-vs-pm_message_t-in-usb

[Pavel Machek]

On Pá 18-03-05 15:53:13, Andrew Morton wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> > > Care to just rediff off of 2.6.12-rc1?  Then we can hopefully get these
> >  > changes in :)
> > 
> >  I can do the rediff tommorow. I just hope there are not some other
> >  changis waiting in -mm to spoil this ;-).
> 
> I have a boatload of these darn pm_message_t patches floating about.  I
> don't know if they depend on Greg's stuff or not.
> 
> Should I just hose them at him?

I see patches on their way, thanks!
Pavel

> fix-pm_message_t-in-generic-code.patch
> fix-u32-vs-pm_message_t-in-usb.patch
> fix-u32-vs-pm_message_t-in-usb-fix.patch
> more-pm_message_t-fixes.patch
> fix-u32-vs-pm_message_t-confusion-in-oss.patch
> fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch
> fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch
> fix-u32-vs-pm_message_t-confusion-in-mmc.patch
> fix-u32-vs-pm_message_t-confusion-in-serials.patch
> fix-u32-vs-pm_message_t-in-macintosh.patch
> fix-u32-vs-pm_message_t-confusion-in-agp.patch
> 

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the 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] arch hook for notifying changes in PTE protections bits

[Seth, Rohit]

Below is the description that I described couple of days back in a mail 
about the stale data issue on IA-64.

Seth, Rohit <> wrote on Tuesday, March 15, 2005 9:44 AM:

> Recently on IA-64, we have found an issue where old data could be used
> by apps.  The sequence of operations includes few mprotects from user
> space (glibc) goes like this:
> 
> 1- The text region of an executable is mmaped using
> PROT_READ|PROT_EXEC. As a result, a shared page is allocated to user.
> 
> 2- User then requests the text region to be mprotected with
> PROT_READ|PROT_WRITE.   Kernel removes the execute permission and
> leave the read permission on the text region.
> 
> 3- Subsequent write operation by user results in page fault and
> eventually resulting in COW break. User gets a new private copy of the
> page.  At this point kernel marks the new page for defered flush.
> 
> 4- User then request the text region to be mprotected back with
> PROT_READ|PROT_EXEC.  mprotect suppport code in kernel, flushes the
> caches, updates the PTEs and then flushes the TLBs.  Though after
> updating the PTEs  with new permissions,  we don't let the arch
> specific code know about the new mappings (through update_mmu_cache
> like routine).  IA-64 typically uses update_mmu_cache to check for the
> defered flush flag (that got set in step 3) to maintain cache
> coherency lazily (The local I and D caches on IA-64 are incoherent).
> 
> DavidM suggeested that we would need to add a hook in the function
> change_pte_range in mm/mprotect.c  This would let the architecture
> specific code to look at the new ptes to decide if it needs to update
> any other architectual/kernel state based on the updated (new
> permissions) PTE values.
> 

We have added a new hook lazy_mmu_prot_update(pte_t) that gets called 
when protection bits in PTEs change.  This hook provides an opportunity to 
arch specific code to do needful. On IA-64 this will be used for lazily
making the I and D caches coherent.

Signed-off-by: David Mosberger <[EMAIL PROTECTED]> 
Signed-off-by: Rohit Seth <[EMAIL PROTECTED]>

Validate on IA-64 and x86 platforms.

diff -Naru linux-2.6.11/include/asm-generic/pgtable.h 
linux-2.6.11.new/include/asm-generic/pgtable.h
--- linux-2.6.11/include/asm-generic/pgtable.h  2005-03-01 23:37:54.0 
-0800
+++ linux-2.6.11.new/include/asm-generic/pgtable.h  2005-03-17 
21:12:21.181174495 -0800
@@ -134,4 +134,7 @@
 #define pgd_offset_gate(mm, addr)  pgd_offset(mm, addr)
 #endif
 
+#ifndef __HAVE_ARCH_LAZY_MMU_UPDATE
+#define lazy_mmu_prot_update(pte)  do { } while (0)
+#endif
 #endif /* _ASM_GENERIC_PGTABLE_H */
diff -Naru linux-2.6.11/include/asm-ia64/pgtable.h 
linux-2.6.11.new/include/asm-ia64/pgtable.h
--- linux-2.6.11/include/asm-ia64/pgtable.h 2005-03-01 23:37:53.0 
-0800
+++ linux-2.6.11.new/include/asm-ia64/pgtable.h 2005-03-18 02:41:24.202417018 
-0800
@@ -420,6 +420,7 @@
 {
return pte_val(a) == pte_val(b);
 }
+#define update_mmu_cache(vma,address,pte) do { } while (0)
 
 extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
 extern void paging_init (void);
@@ -482,7 +483,7 @@
  * information.  However, we use this routine to take care of any (delayed) 
i-cache
  * flushing that may be necessary.
  */
-extern void update_mmu_cache (struct vm_area_struct *vma, unsigned long vaddr, 
pte_t pte);
+extern void lazy_mmu_prot_update (pte_t pte);
 
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 /*
@@ -561,6 +562,7 @@
 #define __HAVE_ARCH_PTEP_MKDIRTY
 #define __HAVE_ARCH_PTE_SAME
 #define __HAVE_ARCH_PGD_OFFSET_GATE
+#define __HAVE_ARCH_LAZY_MMU_UPDATE
 #include 
 #include 
 
 
diff -Naru linux-2.6.11/mm/memory.c linux-2.6.11.new/mm/memory.c
--- linux-2.6.11/mm/memory.c2005-03-01 23:38:08.0 -0800
+++ linux-2.6.11.new/mm/memory.c2005-03-18 01:49:05.498353905 -0800
@@ -1252,6 +1252,7 @@
  vma);
ptep_establish(vma, address, page_table, entry);
update_mmu_cache(vma, address, entry);
+   lazy_mmu_prot_update(entry);
 }
 
 /*
@@ -1304,6 +1305,7 @@
  vma);
ptep_set_access_flags(vma, address, page_table, entry, 
1);
update_mmu_cache(vma, address, entry);
+   lazy_mmu_prot_update(entry);
pte_unmap(page_table);
spin_unlock(>page_table_lock);
return VM_FAULT_MINOR;
@@ -1829,6 +1831,7 @@
 
/* No need to invalidate - it was non-present before */
update_mmu_cache(vma, addr, entry);
+   lazy_mmu_prot_update(entry);
spin_unlock(>page_table_lock);
 out:
return VM_FAULT_MINOR;
@@ -1956,6 +1959,7 @@
 
/* no need to invalidate: a not-present page shouldn't be cached */
update_mmu_cache(vma, address, entry);
+   lazy_mmu_prot_update(entry);
spin_unlock(>page_table_lock);
 out:
return ret;
@@ -2050,6 +2054,7 @@
entry 

[2.6.11-mm3] umount: Scheduling while atomic

[Alexander Gran]

Hi,

while umounting an ext2 partition on a usb hdd I'm getting:
scheduling while atomic: umount/0x1001/14941
 [] schedule+0x5f2/0x600
 [] cond_resched+0x27/0x40
 [] invalidate_mapping_pages+0x81/0xe0
 [] kill_bdev+0xd/0x20
 [] __set_blocksize+0x85/0xa0
 [] __bd_release+0x70/0x80
 [] __close_bdev_excl+0x8/0x10
 [] deactivate_super+0x50/0x80
 [] sys_umount+0x3b/0x90
 [] do_munmap+0x120/0x150
 [] sys_oldumount+0x15/0x20
 [] sysenter_past_esp+0x54/0x75

regards
Alex
-- 
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291


pgpEBevYA1cTQ.pgp
Description: PGP signature

Re: RFC: Bug in generic_forget_inode() ?

[Herbert Xu]

Russ Weight <[EMAIL PROTECTED]> wrote:
> 
> The problem is more likely in generic_forget_inode(). It releases the

Exactly.  It's a continuation of the greased turkey bug :)

When we're writing the inode out, we shouldn't place it on the unused
list at all.  Placing the inode on the unused list only makes sense
when we return from generic_forget_inode without actually destroying
the inode.

So we need something like this.  I'm not sure about the nr_unused
counter though.  Should we be incrementing it as we do now even when
we don't put the inode on the unused list?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
= fs/inode.c 1.144 vs edited =
--- 1.144/fs/inode.c2005-03-05 17:41:15 +11:00
+++ edited/fs/inode.c   2005-03-19 11:11:56 +11:00
@@ -1037,12 +1037,14 @@
struct super_block *sb = inode->i_sb;
 
if (!hlist_unhashed(>i_hash)) {
-   if (!(inode->i_state & (I_DIRTY|I_LOCK)))
-   list_move(>i_list, _unused);
inodes_stat.nr_unused++;
-   spin_unlock(_lock);
-   if (!sb || (sb->s_flags & MS_ACTIVE))
+   if (!sb || (sb->s_flags & MS_ACTIVE)) {
+   if (!(inode->i_state & (I_DIRTY|I_LOCK)))
+   list_move(>i_list, _unused);
+   spin_unlock(_lock);
return;
+   }
+   spin_unlock(_lock);
write_inode_now(inode, 1);
spin_lock(_lock);
inodes_stat.nr_unused--;
-
To unsubscribe from this list: send the 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: Bug in generic_forget_inode() ?

[Andrew Morton]

Russ Weight <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2005-03-18 at 14:17 -0800, Andrew Morton wrote:
> > Russ Weight <[EMAIL PROTECTED]> wrote:
> > >
> > > generic_forget_inode() is eventually called (within the context of
> > >  iput), the inode is placed on the unused list, and the inode_lock is
> > >  dropped.
> > > 
> > >  kswapd calls prune_icache(), locks the inode_lock, and pulls the same
> > >  inode off of the unused list. Upon completion, prune_icache() calls
> > >  dispose_list() for the inodes that it has collected.
> > > 
> > >  generic_forget_inode() calls write_inode_now(), which calls
> > >  __writeback_single_inode() which calls __sync_single_inode().
> > >  __sync_single_inode() panics when attempting to move the inode onto the
> > >  unused list (the last call to list_move). This is due to the poison
> > >  values that were previously loaded into the next and prev list pointers
> > >  by list_del().
> > 
> > It's not clear what the actual bug is here.  When you say that
> > __sync_single_inode() panics over the list pointers, who was it that
> > poisoned them?  dispose_list()?
> > 
> > Certainly isofs_fill_super() could trivially be rewritten to not do the
> > iget()/iput() but we should be sure that that's really the bug.  The inode
> > lifetime management is rather messy, I'm afraid.
> 
> The pointers are poisoned by dispose_list(). The race condition is
> between prune_icache() and generic_forget_inode().
> 
> When I suggested that a change to isofs_fill_super() might be
> considered, I was speculating that isofs_fill_super() might be creating
> an unexpected state by doing something unconventional in its usage of
> iget() and iput(). This is something I had not investigated.
> 
> The problem is more likely in generic_forget_inode(). It releases the
> inode_lock and then locks it again without doing anything to prevent the
> inode from being stolen, and without checking to see if it has been
> stolen. Likewise, write_inode_now() does not do any checks to see if the
> inode has been stolen.
> 

I dunno.  This is really fiddly code and does like to blow up in your face.
I doubt if the problem is in such a well-trodden path as
generic_forget_inode().

Perhaps isofs is breaking the rules by running iget() prior to setting
MS_ACTIVE.  (What rules, you ask?  hah.)

-
To unsubscribe from this list: send the 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] SUSPEND_PD_PAGES-fix

[Pavel Machek]

Hi!

> > > > This fixes SUSPEND_PD_PAGES, which wastes one page under most cases.
> > > 
> > > Ok, applied to my tree, will eventually propagate it. (I hope it looks
> > > okay to you, rafael).
> > 
> > SUSPEND_PD_PAGES is not necessary in swsusp any more. :-)  We can just
> > drop it, together with the pagedir_order variable, which is not used.  I'll
> > send a patch later today.
> 
> The patch follows.

Applied to my tree, will propagate.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the 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: Capabilities across execve

[Olaf Dietsche]

Chris Wright <[EMAIL PROTECTED]> writes:

> * Alexander Nyberg ([EMAIL PROTECTED]) wrote:
>> I can see useful scenarios of having the possiblity of capabilities per
>> inode (it appears the xattr way wins somewhat in the previous
>> discussion).
>
> It's how it should be done.

I agree to disagree :-)

>> Chris, have you seen any capabilities+xattr patches around?
>
> http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4-fcap/

Which is pretty useless, since it doesn't apply to any recent
(> 2.4.3) kernel. If you insist on a xattr based approach, take
Andy Lutomirski's 
patch. It is more recent, a lot smaller and considerably more
understandable (at least for me ;-).

Regards, Olaf.
-
To unsubscribe from this list: send the 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: fix-u32-vs-pm_message_t-in-usb

[Pavel Machek]

Hi!

> > > Care to just rediff off of 2.6.12-rc1?  Then we can hopefully get these
> >  > changes in :)
> > 
> >  I can do the rediff tommorow. I just hope there are not some other
> >  changis waiting in -mm to spoil this ;-).
> 
> I have a boatload of these darn pm_message_t patches floating about.  I
> don't know if they depend on Greg's stuff or not.
> 
> Should I just hose them at him?

I don't know what "hose" means in this context... Greg, can you take
those patches from Andrew? I think we managed to fix it right in his
tree.

Pavel

> fix-pm_message_t-in-generic-code.patch
> fix-u32-vs-pm_message_t-in-usb.patch
> fix-u32-vs-pm_message_t-in-usb-fix.patch
> more-pm_message_t-fixes.patch
> fix-u32-vs-pm_message_t-confusion-in-oss.patch
> fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch
> fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch
> fix-u32-vs-pm_message_t-confusion-in-mmc.patch
> fix-u32-vs-pm_message_t-confusion-in-serials.patch
> fix-u32-vs-pm_message_t-in-macintosh.patch
> fix-u32-vs-pm_message_t-confusion-in-agp.patch
> 

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the 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: Bug in generic_forget_inode() ?

[Russ Weight]

On Fri, 2005-03-18 at 14:17 -0800, Andrew Morton wrote:
> Russ Weight <[EMAIL PROTECTED]> wrote:
> >
> > generic_forget_inode() is eventually called (within the context of
> >  iput), the inode is placed on the unused list, and the inode_lock is
> >  dropped.
> > 
> >  kswapd calls prune_icache(), locks the inode_lock, and pulls the same
> >  inode off of the unused list. Upon completion, prune_icache() calls
> >  dispose_list() for the inodes that it has collected.
> > 
> >  generic_forget_inode() calls write_inode_now(), which calls
> >  __writeback_single_inode() which calls __sync_single_inode().
> >  __sync_single_inode() panics when attempting to move the inode onto the
> >  unused list (the last call to list_move). This is due to the poison
> >  values that were previously loaded into the next and prev list pointers
> >  by list_del().
> 
> It's not clear what the actual bug is here.  When you say that
> __sync_single_inode() panics over the list pointers, who was it that
> poisoned them?  dispose_list()?
> 
> Certainly isofs_fill_super() could trivially be rewritten to not do the
> iget()/iput() but we should be sure that that's really the bug.  The inode
> lifetime management is rather messy, I'm afraid.

The pointers are poisoned by dispose_list(). The race condition is
between prune_icache() and generic_forget_inode().

When I suggested that a change to isofs_fill_super() might be
considered, I was speculating that isofs_fill_super() might be creating
an unexpected state by doing something unconventional in its usage of
iget() and iput(). This is something I had not investigated.

The problem is more likely in generic_forget_inode(). It releases the
inode_lock and then locks it again without doing anything to prevent the
inode from being stolen, and without checking to see if it has been
stolen. Likewise, write_inode_now() does not do any checks to see if the
inode has been stolen.

- Russ 
-
To unsubscribe from this list: send the 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: fix-u32-vs-pm_message_t-in-usb

[Andrew Morton]

Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > Care to just rediff off of 2.6.12-rc1?  Then we can hopefully get these
>  > changes in :)
> 
>  I can do the rediff tommorow. I just hope there are not some other
>  changis waiting in -mm to spoil this ;-).

I have a boatload of these darn pm_message_t patches floating about.  I
don't know if they depend on Greg's stuff or not.

Should I just hose them at him?

fix-pm_message_t-in-generic-code.patch
fix-u32-vs-pm_message_t-in-usb.patch
fix-u32-vs-pm_message_t-in-usb-fix.patch
more-pm_message_t-fixes.patch
fix-u32-vs-pm_message_t-confusion-in-oss.patch
fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch
fix-u32-vs-pm_message_t-confusion-in-framebuffers.patch
fix-u32-vs-pm_message_t-confusion-in-mmc.patch
fix-u32-vs-pm_message_t-confusion-in-serials.patch
fix-u32-vs-pm_message_t-in-macintosh.patch
fix-u32-vs-pm_message_t-confusion-in-agp.patch

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

Re: yenta_socket "nobody cared - Disabling IRQ #4"

[Daniel Ritz]

On Saturday 19 March 2005 00:00, Jonas Oreland wrote:
> Daniel Ritz wrote:
> > hi
> 
> Hi 
> 
> Thanks for your effort!
> 
> > 
> > it's the second time now i see this problem with an atheros chipset in
> > combination with a TI bridge. last time it was the 1225...
> > attached a patch that could help...
> > 
> 
> Report:
> 1) It works somewhat better. irq doesn't get disabled.
> 2) however wlan card get disfunctional. I haven't been able to contact my wap
>even if i'm standing on it...

i was afraid that it could have some side effects. it's probably because just
writing a 0 to the MFUNC register is stupid...can you try to replace 
ti12xx_hook()
in ti113x.h with this one?

static int ti12xx_hook(struct pcmcia_socket *sock, int operation)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket, 
socket);
u32 tmp;

switch (operation) {
case HOOK_POWER_PRE:
tmp = config_readl(socket, TI122X_MFUNC);
socket->saved_state[0] = tmp;
config_writel(socket, TI122X_MFUNC, tmp & ~(TI122X_MFUNC0_MASK 
| TI122X_MFUNC3_MASK));
break;

case HOOK_POWER_POST:
config_writel(socket, TI122X_MFUNC, socket->saved_state[0]);
break;
default:
break;
}

return 0;
}

also try in a second step to replace the following lines in cs.c:
(~line 529)
status = socket_reset(skt);

if (skt->ops->generic_hook)
skt->ops->generic_hook(skt, HOOK_POWER_POST);


with

if (skt->ops->generic_hook)
skt->ops->generic_hook(skt, HOOK_POWER_POST);

status = socket_reset(skt);


> 3) unplug has resulted in kernel panic (twice)
>(btw: how do I do to capture and report those)

at a first guess i would blame the atheros driver which taints the kernel.
so try _not_ loading the atheros driver and see if it still happens. if
so the messages please. to capture them you can use a serial console
(null modem cable to second pc). check out the "remote serial console"
howto on www.tldp.org

> 4) when unlug don't produce kernel panic, then there is no way of power-oning 
> that card again.
> 5) booting with the card inserted makes it not power on when yenta_socket is 
> loaded (module)

anything in dmesg then?

> 
> comment: the card being disfunction could have something to with the driver.
> but before it worked sometimes...
> 
> > --
> > 
> > for TI bridges: turn off interrupts during card power-on. this seems
> > to be neccessary for some combination of TI bridges with at least CB cards
> > with atheros chipset...problem is that they produce an interrupt storm
> > during power-on so the kernel happens to disable the IRQ which is a bad
> > thing (tm).
> > adds a generic hook function so that a socket driver can hook into
> > almost anywhere (by adding more hook points of course). this is the
> > cleanest way i can think of. and it allows adding more workarounds
> > for more problems...
> > for the TI specific interrupt on-off stuff just save the MFUNC register
> > and set it to 0 to disable all interrupts, restore it afterwards.
> > 
> > Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
> 
> Some thoughts: (not I'm neither pcmcia nor linux expert).
> 
> The "irq storm", shouldn't that be "acked" in someway.
> I.e. the card produced a lot of irq's (that get ignored)
> isn't the "real" solution to capture them, and "do something clever"?
> 
> Instead of just "shutting the card down".
> 
> hmmm...wonder if that made sence

it's the CB device that is making the interrupt storm and the TI
bridge is stupid enough to let the interrupts thru during power
on. thing is you can't ack them at this time because the cardbus
resources are not set up at this time and ack'ing an IRQ is
device specifc.

> 
> Question: Why do you think that it worked sometimes before?

pure luck?

> 
> /Jonas
> 
> ps.
>   but the hook was/is nice :-)
> ds.
> 

can you also give me a dump of /proc/iomem?

rgds
-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] mpspec.h: Fix MAX_MP_BUSSES for compliance with MP specification

[achew]

MP specification uses an 8-bit field for bus ID.  Therefore, the highest bus ID 
is 0xff.
Since the tables allocated and used in mpparse.c are indexed by bus ID, we need 
to make
sure we allocate 256 entries for these tables.
Note that bus IDs can be noncontiguous, according to the MP specification.  The 
only
requirement is that they be listed in increasing order.
Signed-off-by: Andrew Chew <[EMAIL PROTECTED]>
---
diff -ru linux-2.4.29/include/asm-i386/mpspec.h linux/include/asm-i386/mpspec.h
--- linux-2.4.29/include/asm-i386/mpspec.h  2004-11-17 03:54:22.0 
-0800
+++ linux/include/asm-i386/mpspec.h 2005-03-18 15:02:20.0 -0800
@@ -191,7 +191,7 @@
#define MAX_IRQ_SOURCES 256
#endif /* CONFIG_MULTIQUAD */
-#define MAX_MP_BUSSES 32
+#define MAX_MP_BUSSES 256
enum mp_bustype {
MP_BUS_ISA = 1,
MP_BUS_EISA,
-
To unsubscribe from this list: send the 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: fix-u32-vs-pm_message_t-in-usb

[Pavel Machek]

On Pá 18-03-05 13:43:36, Greg KH wrote:
> On Fri, Mar 11, 2005 at 02:08:31PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > This patch has been spitting warnings:
> > > 
> > > drivers/usb/host/uhci-hcd.c:838: warning: initialization from 
> > > incompatible pointer type
> > > drivers/usb/host/ohci-pci.c:191: warning: initialization from 
> > > incompatible pointer type
> > > 
> > > Because hc_driver.suspend() takes a u32 as its second arg.  Changing that
> > > to pci_power_t causes build failures and including pci.h in usb.h seems
> > > wrong.
> > > 
> > > Wanna fix it sometime?
> > 
> > Yep. Here it is.
> > 
> > This fixes remaining confusion. Part of my old patch was merged, I
> > later decided passing pci_power_t down to drivers is bad idea; this
> > passes them pm_message_t which contains more info (and actually works
> > :-). Please apply,
> 
> Argh, this one is already partially in, and another one you just sent me
> has half of it in the tree too...
> 
> Care to just rediff off of 2.6.12-rc1?  Then we can hopefully get these
> changes in :)

I can do the rediff tommorow. I just hope there are not some other
changis waiting in -mm to spoil this ;-).
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the 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: yenta_socket "nobody cared - Disabling IRQ #4"

[Francois Romieu]

Jonas Oreland <[EMAIL PROTECTED]> :
[...]
> Report:
> 1) It works somewhat better. irq doesn't get disabled.
> 2) however wlan card get disfunctional. I haven't been able to contact my 
> wap
>   even if i'm standing on it...
> 3) unplug has resulted in kernel panic (twice)
>   (btw: how do I do to capture and report those)
> 4) when unlug don't produce kernel panic, then there is no way of 
> power-oning that card again.
> 5) booting with the card inserted makes it not power on when yenta_socket 
> is loaded (module)
> 
> comment: the card being disfunction could have something to with the driver.
> but before it worked sometimes...

static int
ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
[...]
if (request_irq(dev->irq, ath_intr, SA_SHIRQ, dev->name, dev)) {
printk(KERN_WARNING "%s: request_irq failed\n", dev->name);
goto bad3;
}
[...]
athname = ath_hal_probe(id->vendor, id->device);
printk(KERN_INFO "%s: %s: mem=0x%lx, irq=%d\n",
dev->name, athname ? athname : "Atheros ???", phymem, dev->irq);

/* ready to process interrupts */
sc->aps_sc.sc_invalid = 0;

No sources for ath_hal_probe, too bad.

However, even without any sources, a driver which includes an "I am not ready
to process interrupts" flag and issue request_irq() without having disabled
the device first makes me a bit nervous.

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

[PATCH 2.6.11.2][RFC] printk with antispam-feature

[Bodo Eggert]

Issue:

On some conditions, the dmesg is spammed with repeated warnings about the
same issue which is neither critical nor going to be fixed. This may
result in losing the boot messages or missing other important messages.

Examples are:

nfs warning: mount version older than kernel
 (my mount is newer than documented to be required)

atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
 (I'm using a keyboard switch and a IBM PS/2 keyboard)

program smartd is using a deprecated SCSI ioctl, please convert it to SG_IO
 (I'll use the latest version as soon as I need to)



Rate-limiting these messages is won't help, since it would still allow
these messages to (slowly or in a burst) spam the log.

Printing these messages only once after booting might result in missing
important messages, especially on long-running systems (e.g. if my
keyboard really breaks after I have used the keyboard switch).


Suggested solution:

Instead, I decided to use a global flag with a semi-random magic number,
which will indicate the last printk being supposed to be limited, and to
reset this flag on each normal printk. By doing this, dmesg will not be
spammed, but the latest issue is displayed last.

(I suggest using the first value from "cksum file.c" as the magic number
unless there are thousands of printks to convert.)

The magic number depends on the CPU being able to read and write a
complete int at once *or* being lucky not to have a magic value that can
be constructed by combining some other magic numbers and printking with
exactly that magic number while the update happens. I can convert the
variable to an atomic type if it is a concern, but that would increase the
chances of a clash due to the 24 bit limit.

The patch increases the size of vmlinux by 141 bytes.
-- 
The programmer's National Anthem is '' diff -uprN linux-2.6.11/drivers/block/scsi_ioctl.c 
linux-2.6.11.new/drivers/block/scsi_ioctl.c
--- linux-2.6.11/drivers/block/scsi_ioctl.c 2005-03-03 15:41:28.0 
+0100
+++ linux-2.6.11.new/drivers/block/scsi_ioctl.c 2005-03-18 22:08:35.0 
+0100
@@ -547,7 +547,7 @@ int scsi_cmd_ioctl(struct file *file, st
 * old junk scsi send command ioctl
 */
case SCSI_IOCTL_SEND_COMMAND:
-   printk(KERN_WARNING "program %s is using a deprecated 
SCSI ioctl, please convert it to SG_IO\n", current->comm);
+   printk_nospam(2296159591, KERN_WARNING "program %s is 
using a deprecated SCSI ioctl, please convert it to SG_IO\n", current->comm);
err = -EINVAL;
if (!arg)
break;
diff -uprN linux-2.6.11/drivers/input/keyboard/atkbd.c 
linux-2.6.11.new/drivers/input/keyboard/atkbd.c
--- linux-2.6.11/drivers/input/keyboard/atkbd.c 2005-03-03 15:41:33.0 
+0100
+++ linux-2.6.11.new/drivers/input/keyboard/atkbd.c 2005-03-18 
22:45:42.0 +0100
@@ -320,7 +320,7 @@ static irqreturn_t atkbd_interrupt(struc
atkbd_report_key(>dev, regs, KEY_HANJA, 3);
goto out;
case ATKBD_RET_ERR:
-   printk(KERN_DEBUG "atkbd.c: Keyboard on %s reports too 
many keys pressed.\n", serio->phys);
+   printk_nospam(2260620158, KERN_DEBUG "atkbd.c: Keyboard 
on %s reports too many keys pressed.\n", serio->phys);
goto out;
}
 
diff -uprN linux-2.6.11/fs/nfs/inode.c linux-2.6.11.new/fs/nfs/inode.c
--- linux-2.6.11/fs/nfs/inode.c 2005-03-03 15:41:59.0 +0100
+++ linux-2.6.11.new/fs/nfs/inode.c 2005-03-18 22:48:09.0 +0100
@@ -1386,7 +1386,7 @@ static struct super_block *nfs_get_sb(st
init_nfsv4_state(server);
 
if (data->version != NFS_MOUNT_VERSION) {
-   printk("nfs warning: mount version %s than kernel\n",
+   printk_nospam(1377481036, "nfs warning: mount version %s than 
kernel\n",
data->version < NFS_MOUNT_VERSION ? "older" : "newer");
if (data->version < 2)
data->namlen = 0;
diff -uprN linux-2.6.11/include/linux/kernel.h 
linux-2.6.11.new/include/linux/kernel.h
--- linux-2.6.11/include/linux/kernel.h 2005-03-03 15:42:13.0 +0100
+++ linux-2.6.11.new/include/linux/kernel.h 2005-03-18 22:06:42.0 
+0100
@@ -104,6 +104,10 @@ extern int session_of_pgrp(int pgrp);
 asmlinkage int vprintk(const char *fmt, va_list args);
 asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+asmlinkage int printk_nospam(int magic, const char * fmt, ...)
+   __attribute__ ((format (printf, 2, 3)));
+/* use a random value for the magic, e.g. the first value from
+   cksum on the file you're editing */
 
 unsigned long int_sqrt(unsigned long);
 
diff -uprN linux-2.6.11/kernel/printk.c linux-2.6.11.new/kernel/printk.c
--- linux-2.6.11/kernel/printk.c  

Re: Bug in __alloc_pages()?

[Nick Piggin]

Matthew Dobson wrote:
Agreed.  It seems unlikely, but not entirely impossible.  All it would 
take is one sloppily coded driver, right?  How about this patch instead?

Sure that would be fine with me. It kind of makes the logic
explicit, as Martin said.
Nick
-
To unsubscribe from this list: send the 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: Oops in 2.6.10 (EIP is at hid_init_reports+0x151/0x1d0 [usbhid])

[Andrew Morton]

Could you please test 2.6.11 or, even better, 2.6.12-rc1?
-
To unsubscribe from this list: send the 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: [BKPATCH] ACPI for 2.6.12-rc1

[Andrew Morton]

Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> Could I humble advocating pushing the patch 
>  http://bugme.osdl.org/attachment.cgi?id=4516=view ,please? It fixed a
>  very bad regression in hotkey event from 2.6.9...

It seems to not be in ACPI bk yet.  What bug number is that actually
attached to?  There seems to be no way to go backwards from the URL.

-
To unsubscribe from this list: send the 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] ppc32: Fix CONFIG_SERIAL_TEXT_DEBUG support on 83xx

[Kumar Gala]

Andrew,

The uart initialization for CONFIG_SERIAL_TEXT_DEBUG on 83xx was passing 
in physical addresses instead of effective.  Additional, fix the Kconfig 
support to be for all 83xx devices, not just the MPC834x SYS board.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---

diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig  2005-03-18 17:15:04 -06:00
+++ b/arch/ppc/Kconfig  2005-03-18 17:15:04 -06:00
@@ -733,7 +733,7 @@
depends on SANDPOINT || MCPN765 || SPRUCE || PPLUS || PCORE || \
PRPMC750 || K2 || PRPMC800 || LOPEC || \
(EV64260 && !SERIAL_MPSC) || CHESTNUT || RADSTONE_PPC7D || \
-   MPC834x_SYS
+   83xx
default y
 
 config FORCE
diff -Nru a/arch/ppc/platforms/83xx/mpc834x_sys.c 
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c 2005-03-18 17:15:04 -06:00
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c 2005-03-18 17:15:04 -06:00
@@ -243,14 +243,14 @@
 
memset(, 0, sizeof (p));
p.iotype = SERIAL_IO_MEM;
-   p.membase = (unsigned char __iomem *)immrbar + 0x4500;
+   p.membase = (unsigned char __iomem *)(VIRT_IMMRBAR + 0x4500);
p.uartclk = binfo->bi_busfreq;
 
gen550_init(0, );
 
memset(, 0, sizeof (p));
p.iotype = SERIAL_IO_MEM;
-   p.membase = (unsigned char __iomem *)immrbar + 0x4500;
+   p.membase = (unsigned char __iomem *)(VIRT_IMMRBAR + 0x4600);
p.uartclk = binfo->bi_busfreq;
 
gen550_init(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/

Re: [PATCH 1/4] io_remap_pfn_range: add for all arch-es

[Randy.Dunlap]

Paul Mackerras wrote:
Just by inspection, this looks like pfn should be changed to
paddr64 >> PAGE_SHIFT in that last line.
Paul.
Agreed, thank you.  Patch is attached.
--
~Randy

Fix asm-ppc argument, spotted by Paul Mackerras.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diffstat:=
 include/asm-ppc/pgtable.h |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -Naurp ./include/asm-ppc/pgtable.h~ioremap_ppc_shift ./include/asm-ppc/pgtable.h
--- ./include/asm-ppc/pgtable.h~ioremap_ppc_shift	2005-03-18 10:20:47.0 -0800
+++ ./include/asm-ppc/pgtable.h	2005-03-18 15:15:56.0 -0800
@@ -743,7 +743,7 @@ static inline int io_remap_pfn_range(str
 	pgprot_t prot)
 {
 	phys_addr_t paddr64 = fixup_bigphys_addr(pfn << PAGE_SHIFT, size);
-	return remap_pfn_range(vma, vaddr, pfn, size, prot);
+	return remap_pfn_range(vma, vaddr, paddr64 >> PAGE_SHIFT, size, prot);
 }
 #else
 #define io_remap_page_range(vma, vaddr, paddr, size, prot)		\

[PATCH] ppc32: Move 83xx & 85xx device and system description files

[Kumar Gala]

Andrew,

This patch moves the 83xx & 85xx device and system description files out 
of the platform directory (used for board code) and into the syslib 
directory (used for common system code).

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---

diff -Nru a/arch/ppc/platforms/83xx/Makefile b/arch/ppc/platforms/83xx/Makefile
--- a/arch/ppc/platforms/83xx/Makefile  2005-03-17 23:29:42 -06:00
+++ b/arch/ppc/platforms/83xx/Makefile  2005-03-17 23:29:42 -06:00
@@ -1,6 +1,4 @@
 #
 # Makefile for the PowerPC 83xx linux kernel.
 #
-obj-$(CONFIG_83xx) += mpc83xx_sys.o mpc83xx_devices.o
-
 obj-$(CONFIG_MPC834x_SYS)  += mpc834x_sys.o
diff -Nru a/arch/ppc/platforms/83xx/mpc83xx_devices.c 
b/arch/ppc/platforms/83xx/mpc83xx_devices.c
--- a/arch/ppc/platforms/83xx/mpc83xx_devices.c 2005-03-17 23:29:42 -06:00
+++ /dev/null   Wed Dec 31 16:00:00 196900
@@ -1,237 +0,0 @@
-/*
- * arch/ppc/platforms/83xx/mpc83xx_devices.c
- *
- * MPC83xx Device descriptions
- *
- * Maintainer: Kumar Gala <[EMAIL PROTECTED]>
- *
- * Copyright 2005 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* We use offsets for IORESOURCE_MEM since we do not know at compile time
- * what IMMRBAR is, will get fixed up by mach_mpc83xx_fixup
- */
-
-static struct gianfar_platform_data mpc83xx_tsec1_pdata = {
-   .device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
-   FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
-   FSL_GIANFAR_DEV_HAS_MULTI_INTR,
-   .phy_reg_addr = 0x24000,
-};
-
-static struct gianfar_platform_data mpc83xx_tsec2_pdata = {
-   .device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
-   FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
-   FSL_GIANFAR_DEV_HAS_MULTI_INTR,
-   .phy_reg_addr = 0x24000,
-};
-
-static struct fsl_i2c_platform_data mpc83xx_fsl_i2c1_pdata = {
-   .device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
-};
-
-static struct fsl_i2c_platform_data mpc83xx_fsl_i2c2_pdata = {
-   .device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
-};
-
-static struct plat_serial8250_port serial_platform_data[] = {
-   [0] = {
-   .mapbase= 0x4500,
-   .irq= MPC83xx_IRQ_UART1,
-   .iotype = UPIO_MEM,
-   .flags  = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
-   },
-   [1] = {
-   .mapbase= 0x4600,
-   .irq= MPC83xx_IRQ_UART2,
-   .iotype = UPIO_MEM,
-   .flags  = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
-   },
-};
-
-struct platform_device ppc_sys_platform_devices[] = {
-   [MPC83xx_TSEC1] = {
-   .name = "fsl-gianfar",
-   .id = 1,
-   .dev.platform_data = _tsec1_pdata,
-   .num_resources   = 4,
-   .resource = (struct resource[]) {
-   {
-   .start  = 0x24000,
-   .end= 0x24fff,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .name   = "tx",
-   .start  = MPC83xx_IRQ_TSEC1_TX,
-   .end= MPC83xx_IRQ_TSEC1_TX,
-   .flags  = IORESOURCE_IRQ,
-   },
-   {
-   .name   = "rx",
-   .start  = MPC83xx_IRQ_TSEC1_RX,
-   .end= MPC83xx_IRQ_TSEC1_RX,
-   .flags  = IORESOURCE_IRQ,
-   },
-   {
-   .name   = "error",
-   .start  = MPC83xx_IRQ_TSEC1_ERROR,
-   .end= MPC83xx_IRQ_TSEC1_ERROR,
-   .flags  = IORESOURCE_IRQ,
-   },
-   },
-   },
-   [MPC83xx_TSEC2] = {
-   .name = "fsl-gianfar",
-   .id = 2,
-   .dev.platform_data = _tsec2_pdata,
-   .num_resources   = 4,
-   .resource = (struct resource[]) {
-   {
-   .start  = 0x25000,
-   .end= 0x25fff,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .name   = "tx",
-   .start  = MPC83xx_IRQ_TSEC2_TX,
-   .end= MPC83xx_IRQ_TSEC2_TX,
-   .flags  = 

Re: [RFC][PATCH 5/6] sparsemem: more separation between NUMA and DISCONTIG

[Dave Hansen]

On Fri, 2005-03-18 at 15:08 -0800, Andrew Morton wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote:
> >
> >  There is some confusion with the SPARSEMEM patch between what
> >  is needed for DISCONTIG vs. NUMA.  For instance, the NODE_DATA()
> >  macro needs to be switched on NUMA, but not on FLATMEM.
> > 
> >  This patch is required if the previous patch is applied.
> 
> This patch breaks !CONFIG_NUMA ppc64:
> 
> include/linux/mmzone.h:387:1: warning: "NODE_DATA" redefined
> include/asm/mmzone.h:55:1: warning: this is the location of the previous 
> definition
> 
> I'll hack around it for now.

I'll make sure to have it fixed properly in my copy.

Could I have a copy of your .config?  I'm keeping a growing collection.

-- 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: PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC]PCIErrorRecovery)

[Benjamin Herrenschmidt]

On Fri, 2005-03-18 at 11:10 -0700, Grant Grundler wrote:
> On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
> > >Likewise, with EEH the device driver could take recovery action on its
> > >own.  But we don't want to end up with multiple sets of recovery code
> > >in drivers, if possible.  Also we want the recovery code to be as
> > >simple as possible, otherwise driver authors will get it wrong.
> > 
> > Drivers own their devices register sets.  Therefore if there are any
> > vendor unique actions that can be taken by the driver to recovery we
> > expect the driver to do so.
> ...
> 
> All drivers also need to cleanup driver state if they can't
> simply recover (and restart pending IOs). ie they need to release
> DMA resources and return suitable errors for pending requests.

Additionally, in "real life", very few errors are cause by known errata.
If the drivers know about the errata, they usually already work around
them. Afaik, most of the errors are caused by transcient conditions on
the bus or the device, like a bit beeing flipped, or thermal
conditions... 

> To the driver writer, it's all "platform" code.
> Folks who maintain PCI (and other) services differentiate between
> "generic" and "arch/platform" specific. Think first like a driver
> writer and then worry about if/how that can be divided between platform
> generic and platform/arch specific code.
> 
> Even PCI-Express has *some* arch specific component. At a minimum each
> architecture has it's own chipset and firmware to deal with
> for PCI Express bus discovery and initialization. But driver writers
> don't have to worry about that and they shouldn't for error
> recovery either.

Exactly. A given platform could use Intel's code as-is, or may choose to
do things differently while still showing the same interface to drivers.
Eventually we may end up adding platform hooks to the generic PCIE code
like we have in the PCI code if some platforms require them.



-
To unsubscribe from this list: send the 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 5/6] sparsemem: more separation between NUMA and DISCONTIG

[Andrew Morton]

Dave Hansen <[EMAIL PROTECTED]> wrote:
>
>  There is some confusion with the SPARSEMEM patch between what
>  is needed for DISCONTIG vs. NUMA.  For instance, the NODE_DATA()
>  macro needs to be switched on NUMA, but not on FLATMEM.
> 
>  This patch is required if the previous patch is applied.

This patch breaks !CONFIG_NUMA ppc64:

include/linux/mmzone.h:387:1: warning: "NODE_DATA" redefined
include/asm/mmzone.h:55:1: warning: this is the location of the previous 
definition

I'll hack around it for 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 1/4] io_remap_pfn_range: add for all arch-es

[Paul Mackerras]

Randy.Dunlap writes:

> diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
> linux-2611-bk3-pv/include/asm-ppc/pgtable.h 
> linux-2611-bk3-pfn/include/asm-ppc/pgtable.h
> --- linux-2611-bk3-pv/include/asm-ppc/pgtable.h   2005-03-07 
> 11:02:18.0 -0800
> +++ linux-2611-bk3-pfn/include/asm-ppc/pgtable.h  2005-03-07 
> 11:04:59.0 -0800
> @@ -735,11 +735,27 @@ static inline int io_remap_page_range(st
>   phys_addr_t paddr64 = fixup_bigphys_addr(paddr, size);
>   return remap_pfn_range(vma, vaddr, paddr64 >> PAGE_SHIFT, size, prot);
>  }
> +
> +static inline int io_remap_pfn_range(struct vm_area_struct *vma,
> + unsigned long vaddr,
> + unsigned long pfn,
> + unsigned long size,
> + pgprot_t prot)
> +{
> + phys_addr_t paddr64 = fixup_bigphys_addr(pfn << PAGE_SHIFT, size);
> + return remap_pfn_range(vma, vaddr, pfn, size, prot);

Just by inspection, this looks like pfn should be changed to
paddr64 >> PAGE_SHIFT in that last line.

Paul.
-
To unsubscribe from this list: send the 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: yenta_socket "nobody cared - Disabling IRQ #4"

[Jonas Oreland]

Daniel Ritz wrote:
hi
Hi 

Thanks for your effort!
it's the second time now i see this problem with an atheros chipset in
combination with a TI bridge. last time it was the 1225...
attached a patch that could help...
Report:
1) It works somewhat better. irq doesn't get disabled.
2) however wlan card get disfunctional. I haven't been able to contact my wap
  even if i'm standing on it...
3) unplug has resulted in kernel panic (twice)
  (btw: how do I do to capture and report those)
4) when unlug don't produce kernel panic, then there is no way of power-oning 
that card again.
5) booting with the card inserted makes it not power on when yenta_socket is 
loaded (module)
comment: the card being disfunction could have something to with the driver.
but before it worked sometimes...
--
for TI bridges: turn off interrupts during card power-on. this seems
to be neccessary for some combination of TI bridges with at least CB cards
with atheros chipset...problem is that they produce an interrupt storm
during power-on so the kernel happens to disable the IRQ which is a bad
thing (tm).
adds a generic hook function so that a socket driver can hook into
almost anywhere (by adding more hook points of course). this is the
cleanest way i can think of. and it allows adding more workarounds
for more problems...
for the TI specific interrupt on-off stuff just save the MFUNC register
and set it to 0 to disable all interrupts, restore it afterwards.
Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
Some thoughts: (not I'm neither pcmcia nor linux expert).
The "irq storm", shouldn't that be "acked" in someway.
I.e. the card produced a lot of irq's (that get ignored)
isn't the "real" solution to capture them, and "do something clever"?
Instead of just "shutting the card down".
hmmm...wonder if that made sence
Question: Why do you think that it worked sometimes before?
/Jonas
ps.
but the hook was/is nice :-)
ds.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 12/12] ACPI based root bridge hot-add

[Rajesh Shah]

acpiphp changes to support acpi based root bridge hot-add.
This patch applies on top of the acpiphp re-write patch by
Matthew Wilcox at:
http://marc.theaimsgroup.com/?l=linux-ia64=110616116714938=2

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/hotplug/acpiphp_glue.c |  211 
+-
 1 files changed, 202 insertions(+), 9 deletions(-)

diff -puN drivers/pci/hotplug/acpiphp_glue.c~acpiphp_h2p_add 
drivers/pci/hotplug/acpiphp_glue.c
--- linux-2.6.11-mm4-iohp/drivers/pci/hotplug/acpiphp_glue.c~acpiphp_h2p_add
2005-03-16 13:37:08.716126010 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/hotplug/acpiphp_glue.c 
2005-03-16 13:37:08.825501009 -0800
@@ -6,6 +6,8 @@
  * Copyright (C) 2002,2003 NEC Corporation
  * Copyright (C) 2003-2005 Matthew Wilcox ([EMAIL PROTECTED])
  * Copyright (C) 2003-2005 Hewlett Packard
+ * Copyright (C) 2005 Rajesh Shah ([EMAIL PROTECTED])
+ * Copyright (C) 2005 Intel Corporation
  *
  * All rights reserved.
  *
@@ -304,13 +306,15 @@ static void init_bridge_misc(struct acpi
 register_slot, bridge, NULL);
 
/* install notify handler */
-   status = acpi_install_notify_handler(bridge->handle,
+   if (bridge->type != BRIDGE_TYPE_HOST) {
+   status = acpi_install_notify_handler(bridge->handle,
 ACPI_SYSTEM_NOTIFY,
 handle_hotplug_event_bridge,
 bridge);
 
-   if (ACPI_FAILURE(status)) {
-   err("failed to register interrupt notify handler\n");
+   if (ACPI_FAILURE(status)) {
+   err("failed to register interrupt notify handler\n");
+   }
}
 
list_add(>list, _list);
@@ -802,6 +806,143 @@ static int acpiphp_check_bridge(struct a
return retval;
 }
 
+static void program_hpp(struct pci_dev *dev, struct acpiphp_bridge *bridge)
+{
+   u16 pci_cmd, pci_bctl;
+   struct pci_dev *cdev;
+
+   /* Program hpp values for this device */
+   if (!(dev->hdr_type == PCI_HEADER_TYPE_NORMAL ||
+   (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
+   (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI)))
+   return;
+   pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE,
+   bridge->hpp.cache_line_size);
+   pci_write_config_byte(dev, PCI_LATENCY_TIMER,
+   bridge->hpp.latency_timer);
+   pci_read_config_word(dev, PCI_COMMAND, _cmd);
+   if (bridge->hpp.enable_SERR)
+   pci_cmd |= PCI_COMMAND_SERR;
+   else
+   pci_cmd &= ~PCI_COMMAND_SERR;
+   if (bridge->hpp.enable_PERR)
+   pci_cmd |= PCI_COMMAND_PARITY;
+   else
+   pci_cmd &= ~PCI_COMMAND_PARITY;
+   pci_write_config_word(dev, PCI_COMMAND, pci_cmd);
+
+   /* Program bridge control value and child devices */
+   if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
+   pci_write_config_byte(dev, PCI_SEC_LATENCY_TIMER,
+   bridge->hpp.latency_timer);
+   pci_read_config_word(dev, PCI_BRIDGE_CONTROL, _bctl);
+   if (bridge->hpp.enable_SERR)
+   pci_bctl |= PCI_BRIDGE_CTL_SERR;
+   else
+   pci_bctl &= ~PCI_BRIDGE_CTL_SERR;
+   if (bridge->hpp.enable_PERR)
+   pci_bctl |= PCI_BRIDGE_CTL_PARITY;
+   else
+   pci_bctl &= ~PCI_BRIDGE_CTL_PARITY;
+   pci_write_config_word(dev, PCI_BRIDGE_CONTROL, pci_bctl);
+   if (dev->subordinate) {
+   list_for_each_entry(cdev, >subordinate->devices,
+   bus_list)
+   program_hpp(cdev, bridge);
+   }
+   }
+}
+
+static void acpiphp_set_hpp_values(acpi_handle handle, struct pci_bus *bus)
+{
+   struct acpiphp_bridge bridge;
+   struct pci_dev *dev;
+
+   memset(, 0, sizeof(bridge));
+   bridge.handle = handle;
+   decode_hpp();
+   list_for_each_entry(dev, >devices, bus_list)
+   program_hpp(dev, );
+
+}
+
+/*
+ * Remove devices for which we could not assign resources, call
+ * arch specific code to fix-up the bus
+ */
+static void acpiphp_sanitize_bus(struct pci_bus *bus)
+{
+   struct pci_dev *dev;
+   int i;
+   unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+
+   list_for_each_entry(dev, >devices, bus_list) {
+   for (i=0; iresource[i];
+   if ((res->flags & type_mask) && !res->start &&
+   res->end) {
+   /* Could not assign a required resources
+* for this device, remove it */
+   

Re: Real-Time Preemption and RCU

[Paul E. McKenney]

On Fri, Mar 18, 2005 at 12:35:17PM -0800, Paul E. McKenney wrote:
> Compiles, probably dies horribly.  "diff" didn't do such a good job
> on this one, so attaching the raw rcupdate.[hc] files as well.

My prediction was all too accurate.  ;-)

The attached patch at least boots on a 1-CPU x86 box.  I added some
interrupt disabling that is a bad idea in real-time preempt kernels,
but necessary for stock kernels to even have a ghost of a chance.

Again, the diff is quite confusing to read (for me, anyway!), so attached
the rcupdate.[hc] files.

Assuming this patch survives the LTP run (hah!!!), next step is a small
SMP system.

Thanx, Paul

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

diff -urpN -X ../dontdiff linux-2.5/include/linux/rcupdate.h 
linux-2.5-rtRCU/include/linux/rcupdate.h
--- linux-2.5/include/linux/rcupdate.h  Wed Mar  9 12:37:06 2005
+++ linux-2.5-rtRCU/include/linux/rcupdate.hFri Mar 18 11:37:02 2005
@@ -58,169 +58,11 @@ struct rcu_head {
(ptr)->next = NULL; (ptr)->func = NULL; \
 } while (0)
 
-
-
-/* Global control variables for rcupdate callback mechanism. */
-struct rcu_ctrlblk {
-   longcur;/* Current batch number.  */
-   longcompleted;  /* Number of the last completed batch */
-   int next_pending;   /* Is the next batch already waiting? */
-} cacheline_maxaligned_in_smp;
-
-/* Is batch a before batch b ? */
-static inline int rcu_batch_before(long a, long b)
-{
-return (a - b) < 0;
-}
-
-/* Is batch a after batch b ? */
-static inline int rcu_batch_after(long a, long b)
-{
-return (a - b) > 0;
-}
-
-/*
- * Per-CPU data for Read-Copy UPdate.
- * nxtlist - new callbacks are added here
- * curlist - current batch for which quiescent cycle started if any
- */
-struct rcu_data {
-   /* 1) quiescent state handling : */
-   longquiescbatch; /* Batch # for grace period */
-   int passed_quiesc;   /* User-mode/idle loop etc. */
-   int qs_pending;  /* core waits for quiesc state */
-
-   /* 2) batch handling */
-   longbatch;   /* Batch # for current RCU batch */
-   struct rcu_head *nxtlist;
-   struct rcu_head **nxttail;
-   struct rcu_head *curlist;
-   struct rcu_head **curtail;
-   struct rcu_head *donelist;
-   struct rcu_head **donetail;
-   int cpu;
-};
-
-DECLARE_PER_CPU(struct rcu_data, rcu_data);
-DECLARE_PER_CPU(struct rcu_data, rcu_bh_data);
-extern struct rcu_ctrlblk rcu_ctrlblk;
-extern struct rcu_ctrlblk rcu_bh_ctrlblk;
-
-/*
- * Increment the quiescent state counter.
- * The counter is a bit degenerated: We do not need to know
- * how many quiescent states passed, just if there was at least
- * one since the start of the grace period. Thus just a flag.
- */
-static inline void rcu_qsctr_inc(int cpu)
-{
-   struct rcu_data *rdp = _cpu(rcu_data, cpu);
-   rdp->passed_quiesc = 1;
-}
-static inline void rcu_bh_qsctr_inc(int cpu)
-{
-   struct rcu_data *rdp = _cpu(rcu_bh_data, cpu);
-   rdp->passed_quiesc = 1;
-}
-
-static inline int __rcu_pending(struct rcu_ctrlblk *rcp,
-   struct rcu_data *rdp)
-{
-   /* This cpu has pending rcu entries and the grace period
-* for them has completed.
-*/
-   if (rdp->curlist && !rcu_batch_before(rcp->completed, rdp->batch))
-   return 1;
-
-   /* This cpu has no pending entries, but there are new entries */
-   if (!rdp->curlist && rdp->nxtlist)
-   return 1;
-
-   /* This cpu has finished callbacks to invoke */
-   if (rdp->donelist)
-   return 1;
-
-   /* The rcu core waits for a quiescent state from the cpu */
-   if (rdp->quiescbatch != rcp->cur || rdp->qs_pending)
-   return 1;
-
-   /* nothing to do */
-   return 0;
-}
-
-static inline int rcu_pending(int cpu)
-{
-   return __rcu_pending(_ctrlblk, _cpu(rcu_data, cpu)) ||
-   __rcu_pending(_bh_ctrlblk, _cpu(rcu_bh_data, cpu));
-}
-
-/**
- * rcu_read_lock - mark the beginning of an RCU read-side critical section.
- *
- * When synchronize_kernel() is invoked on one CPU while other CPUs
- * are within RCU read-side critical sections, then the
- * synchronize_kernel() is guaranteed to block until after all the other
- * CPUs exit their critical sections.  Similarly, if call_rcu() is invoked
- * on one CPU while other CPUs are within RCU read-side critical
- * sections, invocation of the corresponding RCU callback is deferred
- * until after the all the other CPUs exit their critical sections.
- *
- * Note, however, that RCU callbacks are permitted to run concurrently
- * with RCU read-side critical sections.  One way that this can happen
- * is via the following sequence of events: (1) CPU 0 enters an RCU
- * read-side critical section, (2) CPU 1 invokes 

Re: Real-Time Preemption and RCU

[Herbert Xu]

Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> i really have no intention to allow multiple readers for rt-mutexes. We
> got away with that so far, and i'd like to keep it so. Imagine 100
> threads all blocked in the same critical section (holding the read-lock)
> when a highprio writer thread comes around: instant 100x latency to let
> all of them roll forward. The only sane solution is to not allow
> excessive concurrency. (That limits SMP scalability, but there's no
> other choice i can see.)

What about allowing only as many concurrent readers as there are CPUs?
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the 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 08/12] Remove hot-plugged devices that could not be allocated resources

[Rajesh Shah]

When hot-plugging an I/O hierarchy that contains many bridges
and leaf devices, it's possible that there are not enough 
resources to start all the device present. If we fail to assign
a resource, clear the corresponding value in the pci_dev structure,
so other code can take corrective action.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/setup-bus.c |5 -
 1 files changed, 4 insertions(+), 1 deletion(-)

diff -puN drivers/pci/setup-bus.c~discard_no_resource_devs 
drivers/pci/setup-bus.c
--- linux-2.6.11-mm4-iohp/drivers/pci/setup-bus.c~discard_no_resource_devs  
2005-03-16 13:07:26.557944717 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/setup-bus.c2005-03-16 
13:07:26.666343153 -0800
@@ -72,7 +72,10 @@ pbus_assign_resources_sorted(struct pci_
for (list = head.next; list;) {
res = list->res;
idx = res - >dev->resource[0];
-   pci_assign_resource(list->dev, idx);
+   if (pci_assign_resource(list->dev, idx)) {
+   res->start = 0;
+   res->flags = 0;
+   }
tmp = list;
list = list->next;
kfree(tmp);
_
-
To unsubscribe from this list: send the 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: BKCVS broken ?

[Stelian Pop]

On Fri, Mar 18, 2005 at 08:38:51PM +0530, Hong Kong Phoey wrote:

> IMHO, BKCVS is just fine, what's broken is your head.

Yup, that's what I said, that cvs HEAD is broken...

:)

Stelian.
-- 
Stelian Pop <[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 10/12] Allow ACPI .add and .start operations to be done independently

[Rajesh Shah]

Create new interfaces to recursively add an acpi namespace object
to the acpi device list, and recursively start the namespace 
object. This is needed for ACPI based hotplug of a root bridge
hierarchy where the add operation must be performed first and 
the start operation must be performed separately after the 
hot-plugged devices have been properly configured.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/container.c  |2 
 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/processor_core.c |2 
 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/scan.c   |  126 ++---
 linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_bus.h   |   17 +
 4 files changed, 119 insertions(+), 28 deletions(-)

diff -puN drivers/acpi/scan.c~acpi_separate_device_start drivers/acpi/scan.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/scan.c~acpi_separate_device_start
2005-03-16 13:07:34.326499309 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/scan.c2005-03-16 
13:07:34.452475870 -0800
@@ -553,20 +553,29 @@ acpi_bus_driver_init (
 * upon possible configuration and currently allocated resources.
 */
 
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Driver successfully bound to 
device\n"));
+   return_VALUE(0);
+}
+
+int
+acpi_start_single_object (
+   struct acpi_device *device)
+{
+   int result = 0;
+   struct acpi_driver *driver;
+
+   ACPI_FUNCTION_TRACE("acpi_start_single_object");
+
+   if (!(driver = device->driver))
+   return_VALUE(0);
+
if (driver->ops.start) {
result = driver->ops.start(device);
if (result && driver->ops.remove)
driver->ops.remove(device, ACPI_BUS_REMOVAL_NORMAL);
-   return_VALUE(result);
-   }
-
-   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Driver successfully bound to 
device\n"));
-
-   if (driver->ops.scan) {
-   driver->ops.scan(device);
}
 
-   return_VALUE(0);
+   return_VALUE(result);
 }
 
 static int acpi_driver_attach(struct acpi_driver * drv)
@@ -586,6 +595,7 @@ static int acpi_driver_attach(struct acp
 
if (!acpi_bus_match(dev, drv)) {
if (!acpi_bus_driver_init(dev, drv)) {
+   acpi_start_single_object(dev);
atomic_inc(>references);
count++;
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Found driver 
[%s] for device [%s]\n",
@@ -1009,8 +1019,8 @@ acpi_bus_remove (
 }
 
 
-int
-acpi_bus_add (
+static int
+acpi_add_single_object (
struct acpi_device  **child,
struct acpi_device  *parent,
acpi_handle handle,
@@ -1019,7 +1029,7 @@ acpi_bus_add (
int result = 0;
struct acpi_device  *device = NULL;
 
-   ACPI_FUNCTION_TRACE("acpi_bus_add");
+   ACPI_FUNCTION_TRACE("acpi_add_single_object");
 
if (!child)
return_VALUE(-EINVAL);
@@ -1140,7 +1150,7 @@ acpi_bus_add (
 *
 * TBD: Assumes LDM provides driver hot-plug capability.
 */
-   acpi_bus_find_driver(device);
+   result = acpi_bus_find_driver(device);
 
 end:
if (!result)
@@ -1153,10 +1163,10 @@ end:
 
return_VALUE(result);
 }
-EXPORT_SYMBOL(acpi_bus_add);
 
 
-int acpi_bus_scan (struct acpi_device  *start)
+static int acpi_bus_scan (struct acpi_device   *start,
+   struct acpi_bus_ops *ops)
 {
acpi_status status = AE_OK;
struct acpi_device  *parent = NULL;
@@ -1229,9 +1239,20 @@ int acpi_bus_scan (struct acpi_device*s
continue;
}
 
-   status = acpi_bus_add(, parent, chandle, type);
-   if (ACPI_FAILURE(status))
-   continue;
+   if (ops->acpi_op_add)
+   status = acpi_add_single_object(, parent,
+   chandle, type);
+else
+   status = acpi_bus_get_device(chandle, );
+
+if (ACPI_FAILURE(status))
+continue;
+
+   if (ops->acpi_op_start) {
+   status = acpi_start_single_object(child);
+   if (ACPI_FAILURE(status))
+   continue;
+   }
 
/*
 * If the device is present, enabled, and functioning then
@@ -1257,8 +1278,50 @@ int acpi_bus_scan (struct acpi_device*s
 
return_VALUE(0);
 }
-EXPORT_SYMBOL(acpi_bus_scan);
 
+int
+acpi_bus_add (
+   struct acpi_device  **child,
+   struct acpi_device  *parent,
+   acpi_handle handle,
+   int type)
+{
+   int result;
+   struct acpi_bus_ops ops;
+
+   ACPI_FUNCTION_TRACE("acpi_bus_add");
+
+   result = 

[patch 11/12] Export the interface to get PCI id for an ACPI handle

[Rajesh Shah]

Export an acpi interface to get PCI domain/bus/devfn information
from the corresponding namespace handle. Used by acpiphp code
to transpate the device handle of the hot-plugged root bridge to
the corresponding pci location information.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c |   11 +--
 linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_drivers.h |1 +
 2 files changed, 6 insertions(+), 6 deletions(-)

diff -puN drivers/acpi/pci_bind.c~acpi-get-pci-id drivers/acpi/pci_bind.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/pci_bind.c~acpi-get-pci-id   
2005-03-16 13:07:39.028647689 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c2005-03-16 
13:07:39.141928937 -0800
@@ -61,15 +61,14 @@ acpi_pci_data_handler (
 
 
 /**
- * acpi_os_get_pci_id
+ * acpi_get_pci_id
  * --
  * This function is used by the ACPI Interpreter (a.k.a. Core Subsystem)
  * to resolve PCI information for ACPI-PCI devices defined in the namespace.
  * This typically occurs when resolving PCI operation region information.
  */
-#ifdef ACPI_FUTURE_USAGE
 acpi_status
-acpi_os_get_pci_id (
+acpi_get_pci_id (
acpi_handle handle,
struct acpi_pci_id  *id)
 {
@@ -78,7 +77,7 @@ acpi_os_get_pci_id (
struct acpi_device  *device = NULL;
struct acpi_pci_data*data = NULL;
 
-   ACPI_FUNCTION_TRACE("acpi_os_get_pci_id");
+   ACPI_FUNCTION_TRACE("acpi_get_pci_id");
 
if (!id)
return_ACPI_STATUS(AE_BAD_PARAMETER);
@@ -92,7 +91,7 @@ acpi_os_get_pci_id (
}
 
status = acpi_get_data(handle, acpi_pci_data_handler, (void**) );
-   if (ACPI_FAILURE(status) || !data || !data->dev) {
+   if (ACPI_FAILURE(status) || !data) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
"Invalid ACPI-PCI context for device %s\n",
acpi_device_bid(device)));
@@ -115,7 +114,7 @@ acpi_os_get_pci_id (
 
return_ACPI_STATUS(AE_OK);
 }
-#endif  /*  ACPI_FUTURE_USAGE  */
+EXPORT_SYMBOL(acpi_get_pci_id);
 

 int
diff -puN include/acpi/acpi_drivers.h~acpi-get-pci-id 
include/acpi/acpi_drivers.h
--- linux-2.6.11-mm4-iohp/include/acpi/acpi_drivers.h~acpi-get-pci-id   
2005-03-16 13:07:39.033530501 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/include/acpi/acpi_drivers.h2005-03-16 
13:07:39.142905500 -0800
@@ -68,6 +68,7 @@ void acpi_pci_irq_del_prt (int segment, 
 
 struct pci_bus;
 
+acpi_status acpi_get_pci_id (acpi_handle handle, struct acpi_pci_id *id);
 int acpi_pci_bind (struct acpi_device *device);
 int acpi_pci_unbind (struct acpi_device *device);
 int acpi_pci_bind_root (struct acpi_device *device, struct acpi_pci_id *id, 
struct pci_bus *bus);
_
-
To unsubscribe from this list: send the 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 09/12] Read bridge resources when fixing up the bus

[Rajesh Shah]

Read bridge io/mem/pfmem ranges when fixing up the bus so that 
bus resources are tracked. This is required to properly support
pci end device and bridge hotplug.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |4 
 1 files changed, 4 insertions(+)

diff -puN arch/ia64/pci/pci.c~ia64-read_bridge_bases arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~ia64-read_bridge_bases
2005-03-16 13:07:30.503257168 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16 
13:07:30.612632167 -0800
@@ -436,6 +436,10 @@ pcibios_fixup_bus (struct pci_bus *b)
 {
struct pci_dev *dev;
 
+   if (b->self) {
+   pci_read_bridge_bases(b);
+   pcibios_fixup_device_resources(b->self);
+   }
list_for_each_entry(dev, >devices, bus_list)
pcibios_fixup_device_resources(dev);
 
_
-
To unsubscribe from this list: send the 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: kernel oops, 2.6.11.3

[Greg KH]

On Fri, Mar 18, 2005 at 09:03:59PM +0100, Milan Svoboda wrote:
> Hello,
> 
> usbnet (iPAQ with Familiar) and harddisk connected throught usb were in use 
> during this oops.
> 
> HW: HP Omnibook xt6200

Does this happen with preempt disabled?

thanks,

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

Re: Bug in __alloc_pages()?

[Matthew Dobson]

Nick Piggin wrote:
Matthew Dobson wrote:
While looking at some bugs related to OOM handling in 2.6, Martin 
Bligh and I noticed some order 0 page allocation failures from kswapd:

>> 
If, while the system is under memory pressure, something attempts to 
allocate a page from interrupt context while current == kswapd we will 
obviously fail the !in_interrupt() check and fall through.  If this 
allocation request was made with __GFP_WAIT set then we'll fall 
through the next !wait check.  We will then set the PF_MEMALLOC flag 
and set p->reclaim_state to point to __alloc_pages() local 
reclaim_state structure.  kswapd alread has it's own reclaim_state and 
already has PF_MEMALLOC set, which would then be lost when, after 
try_to_free_pages(), we unconditionally set the reclaim_state to NULL 
and turn off the PF_MEMALLOC flag.

I'm not 100% sure that this potential bug is even possible (ie: can we 
have an in_interrupt() page request that has __GFP_WAIT set?), or is 
the cause of the 0-order page allocation failures we see, but it does 
seem like potentially dangerous code.  I have attatched a patch 
(against 2.6.11-mm4) to check whether the current task has it's own 
reclaim_state or already has PF_MEMALLOC set and if so, no longer 
throws away this data.

I don't think in_interrupt allocations can have __GFP_WAIT set, so
this should probably be OK.
Nick
Agreed.  It seems unlikely, but not entirely impossible.  All it would take 
is one sloppily coded driver, right?  How about this patch instead?

-Matt
diff -Nurp --exclude-from=/home/mcd/.dontdiff linux-2.6.11-mm4/mm/page_alloc.c 
linux-2.6.11-mm4+fix-__alloc_pages/mm/page_alloc.c
--- linux-2.6.11-mm4/mm/page_alloc.c2005-03-16 16:07:49.0 -0800
+++ linux-2.6.11-mm4+fix-__alloc_pages/mm/page_alloc.c  2005-03-18 
14:10:27.433667720 -0800
@@ -957,8 +957,10 @@ rebalance:
cond_resched();
 
/* We now go into synchronous reclaim */
+   BUG_ON(p->flags & PF_MEMALLOC);
p->flags |= PF_MEMALLOC;
reclaim_state.reclaimed_slab = 0;
+   BUG_ON(p->reclaim_state);
p->reclaim_state = _state;
 
did_some_progress = try_to_free_pages(zones, gfp_mask, order);

[PATCH 2.6.11] aoe [4/12]: handle distros that have a udev rules file instead of dir

[Ed L. Cashin]

handle distros that have a udev rules file instead of dir

Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>

diff -uprN a/Documentation/aoe/udev-install.sh 
b/Documentation/aoe/udev-install.sh
--- a/Documentation/aoe/udev-install.sh 2005-03-10 11:59:55.0 -0500
+++ b/Documentation/aoe/udev-install.sh 2005-03-10 12:19:18.0 -0500
@@ -23,4 +23,8 @@ fi
 # /etc/udev/rules.d
 #
 rules_d="`sed -n '/^udev_rules=/{ s!udev_rules=!!; s!\"!!g; p; }' $conf`"
-test "$rules_d" && sh -xc "cp `dirname $0`/udev.txt $rules_d/60-aoe.rules"
+if test -z "$rules_d" || test ! -d "$rules_d"; then
+   echo "$me Error: cannot find udev rules directory" 1>&2
+   exit 1
+fi
+sh -xc "cp `dirname $0`/udev.txt $rules_d/60-aoe.rules"


-- 
  Ed L. Cashin <[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: Bug in generic_forget_inode() ?

[Andrew Morton]

Russ Weight <[EMAIL PROTECTED]> wrote:
>
> generic_forget_inode() is eventually called (within the context of
>  iput), the inode is placed on the unused list, and the inode_lock is
>  dropped.
> 
>  kswapd calls prune_icache(), locks the inode_lock, and pulls the same
>  inode off of the unused list. Upon completion, prune_icache() calls
>  dispose_list() for the inodes that it has collected.
> 
>  generic_forget_inode() calls write_inode_now(), which calls
>  __writeback_single_inode() which calls __sync_single_inode().
>  __sync_single_inode() panics when attempting to move the inode onto the
>  unused list (the last call to list_move). This is due to the poison
>  values that were previously loaded into the next and prev list pointers
>  by list_del().

It's not clear what the actual bug is here.  When you say that
__sync_single_inode() panics over the list pointers, who was it that
poisoned them?  dispose_list()?

Certainly isofs_fill_super() could trivially be rewritten to not do the
iget()/iput() but we should be sure that that's really the bug.  The inode
lifetime management is rather messy, I'm afraid.
-
To unsubscribe from this list: send the 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 06/12] Link newly created pci child bus to its parent on creation

[Rajesh Shah]

When a pci child bus is created, add it to the parent's children
list immediately rather than waiting till pci_bus_add_devices().
For hot-plug bridges/devices, pci_bus_add_devices() may be called
much later, after they have been properly configured. In the 
meantime, this allows us to use the normal pci bus search functions
for the hot-plug bridges/buses.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/bus.c   |   11 +++
 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |4 ++--
 2 files changed, 9 insertions(+), 6 deletions(-)

diff -puN drivers/pci/probe.c~pci_link_child_bus drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~pci_link_child_bus
2005-03-16 13:07:18.745444812 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16 
13:07:18.857749498 -0800
@@ -457,7 +457,7 @@ int __devinit pci_scan_bridge(struct pci
return max;
}
 
-   child = pci_alloc_child_bus(bus, dev, busnr);
+   child = pci_add_new_bus(bus, dev, busnr);
if (!child)
return max;
child->primary = buses & 0xFF;
@@ -484,7 +484,7 @@ int __devinit pci_scan_bridge(struct pci
 * This can happen when a bridge is hot-plugged */
if (pci_find_bus(pci_domain_nr(bus), max+1))
return max;
-   child = pci_alloc_child_bus(bus, dev, ++max);
+   child = pci_add_new_bus(bus, dev, ++max);
buses = (buses & 0xff00)
  | ((unsigned int)(child->primary) <<  0)
  | ((unsigned int)(child->secondary)   <<  8)
diff -puN drivers/pci/bus.c~pci_link_child_bus drivers/pci/bus.c
--- linux-2.6.11-mm4-iohp/drivers/pci/bus.c~pci_link_child_bus  2005-03-16 
13:07:18.749351062 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/bus.c  2005-03-16 
13:07:18.858726061 -0800
@@ -121,10 +121,13 @@ void __devinit pci_bus_add_devices(struc
 * If there is an unattached subordinate bus, attach
 * it and then scan for unattached PCI devices.
 */
-   if (dev->subordinate && list_empty(>subordinate->node)) {
-   spin_lock(_bus_lock);
-   list_add_tail(>subordinate->node, 
>bus->children);
-   spin_unlock(_bus_lock);
+   if (dev->subordinate) {
+  if (list_empty(>subordinate->node)) {
+  spin_lock(_bus_lock);
+  list_add_tail(>subordinate->node,
+  >bus->children);
+  spin_unlock(_bus_lock);
+  }
pci_bus_add_devices(dev->subordinate);
 
sysfs_create_link(>subordinate->class_dev.kobj, 
>dev.kobj, "bridge");
_
-
To unsubscribe from this list: send the 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 07/12] Make the PCI remove routines safe for failed hot-plug

[Rajesh Shah]

When a root bridge hierarchy is hot-plugged, resource requirements
for the new devices may be greater than what the root bridge is
decoding. In this case, we want to remove devices that did not
get needed resources. These devices have been scanned into bus
specific lists but not yet added to the global device list.
Make sure the pci remove functions can handle this case.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff -puN drivers/pci/remove.c~pci-remove-device-hotplug-safe 
drivers/pci/remove.c
--- linux-2.6.11-mm4-iohp/drivers/pci/remove.c~pci-remove-device-hotplug-safe   
2005-03-16 13:07:22.667319764 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/remove.c   2005-03-16 
13:07:22.775718200 -0800
@@ -26,17 +26,21 @@ static void pci_free_resources(struct pc
 
 static void pci_destroy_dev(struct pci_dev *dev)
 {
-   pci_proc_detach_device(dev);
-   pci_remove_sysfs_dev_files(dev);
-   device_unregister(>dev);
+   if (!list_empty(>global_list)) {
+   pci_proc_detach_device(dev);
+   pci_remove_sysfs_dev_files(dev);
+   device_unregister(>dev);
+   spin_lock(_bus_lock);
+   list_del(>global_list);
+   dev->global_list.next = dev->global_list.prev = NULL;
+   spin_unlock(_bus_lock);
+   }
 
/* Remove the device from the device lists, and prevent any further
 * list accesses from this device */
spin_lock(_bus_lock);
list_del(>bus_list);
-   list_del(>global_list);
dev->bus_list.next = dev->bus_list.prev = NULL;
-   dev->global_list.next = dev->global_list.prev = NULL;
spin_unlock(_bus_lock);
 
pci_free_resources(dev);
_
-
To unsubscribe from this list: send the 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 05/12] Take the PCI lock when modifying pci bus or device lists

[Rajesh Shah]

With root bridge and pci bridge hot-plug, new buses and devices
can be added or removed at run time. Protect the pci bus and
device lists with the pci lock when doing so.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |   12 +++-
 1 files changed, 11 insertions(+), 1 deletion(-)

diff -puN drivers/pci/probe.c~lock-pci-root-bus-add drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~lock-pci-root-bus-add 
2005-03-16 13:07:14.694663612 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16 
13:07:14.802085486 -0800
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include "pci.h"
 
 #undef DEBUG
 
@@ -380,8 +381,11 @@ struct pci_bus * __devinit pci_add_new_b
struct pci_bus *child;
 
child = pci_alloc_child_bus(parent, dev, busnr);
-   if (child)
+   if (child) {
+   spin_lock(_bus_lock);
list_add_tail(>node, >children);
+   spin_unlock(_bus_lock);
+   }
return child;
 }
 
@@ -771,7 +775,9 @@ pci_scan_single_device(struct pci_bus *b
 * and the bus list for fixup functions, etc.
 */
INIT_LIST_HEAD(>global_list);
+   spin_lock(_bus_lock);
list_add_tail(>bus_list, >devices);
+   spin_unlock(_bus_lock);
 
return dev;
 }
@@ -891,7 +897,9 @@ struct pci_bus * __devinit pci_scan_bus_
DBG("PCI: Bus %04x:%02x already known\n", pci_domain_nr(b), 
bus);
goto err_out;
}
+   spin_lock(_bus_lock);
list_add_tail(>node, _root_buses);
+   spin_unlock(_bus_lock);
 
memset(dev, 0, sizeof(*dev));
dev->parent = parent;
@@ -933,7 +941,9 @@ class_dev_create_file_err:
 class_dev_reg_err:
device_unregister(dev);
 dev_reg_err:
+   spin_lock(_bus_lock);
list_del(>node);
+   spin_unlock(_bus_lock);
 err_out:
kfree(dev);
kfree(b);
_
-
To unsubscribe from this list: send the 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 04/12] Prevent duplicate bus numbers when scanning PCI bridge

[Rajesh Shah]

When hot-plugging a root bridge, as we try to assign bus numbers
we may find that the hotplugged hieratchy has more PCI to PCI
bridges (i.e. bus requirements) than available.  Make sure we
don't step over an existing bus when that happens. 

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff -puN drivers/pci/probe.c~prevent_duplicate_busnr drivers/pci/probe.c
--- linux-2.6.11-mm4-iohp/drivers/pci/probe.c~prevent_duplicate_busnr   
2005-03-16 13:07:10.376304290 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c2005-03-16 
13:07:10.496421476 -0800
@@ -417,7 +417,7 @@ int __devinit pci_scan_bridge(struct pci
 {
struct pci_bus *child;
int is_cardbus = (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS);
-   u32 buses;
+   u32 buses, i;
u16 bctl;
 
pci_read_config_dword(dev, PCI_PRIMARY_BUS, );
@@ -476,6 +476,10 @@ int __devinit pci_scan_bridge(struct pci
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0x);
 
+   /* Prevent assigning a bus number that already exists.
+* This can happen when a bridge is hot-plugged */
+   if (pci_find_bus(pci_domain_nr(bus), max+1))
+   return max;
child = pci_alloc_child_bus(bus, dev, ++max);
buses = (buses & 0xff00)
  | ((unsigned int)(child->primary) <<  0)
@@ -507,7 +511,11 @@ int __devinit pci_scan_bridge(struct pci
 * as cards with a PCI-to-PCI bridge can be
 * inserted later.
 */
-   max += CARDBUS_RESERVE_BUSNR;
+   for (i=0; ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 03/12] Make pcibios_fixup_bus() hot-plug safe

[Rajesh Shah]

PCI scan code calls the arch specific pcibios_fixup_bus() each
time it scans a new bridge. For root bridge hot-plug, the bridge
and it's attached devices may not have been configured properly
yet, so it's not safe to claim those resources at this time.

This code goes away when we clean up the way pci resources are
claimed (in pci_enable_device()), so this is only a stopgap fix.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |   22 +-
 1 files changed, 21 insertions(+), 1 deletion(-)

diff -puN arch/ia64/pci/pci.c~ia64-pcibios_fixup_bus-hotplug-safe 
arch/ia64/pci/pci.c
--- 
linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~ia64-pcibios_fixup_bus-hotplug-safe   
2005-03-16 13:07:06.343101214 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16 
13:07:06.450523088 -0800
@@ -391,6 +391,25 @@ void pcibios_bus_to_resource(struct pci_
res->end = region->end + offset;
 }
 
+static int __devinit is_valid_resource(struct pci_dev *dev, int idx)
+{
+   unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
+   struct resource *devr = >resource[idx];
+
+   if (!dev->bus)
+   return 0;
+   for (i=0; ibus->resource[i];
+
+   if (!busr || ((busr->flags ^ devr->flags) & type_mask))
+   continue;
+   if ((devr->start) && (devr->start >= busr->start) &&
+   (devr->end <= busr->end))
+   return 1;
+   }
+   return 0;
+}
+
 static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
 {
struct pci_bus_region region;
@@ -404,7 +423,8 @@ static void __devinit pcibios_fixup_devi
region.start = dev->resource[i].start;
region.end = dev->resource[i].end;
pcibios_bus_to_resource(dev, >resource[i], );
-   pci_claim_resource(dev, i);
+   if ((is_valid_resource(dev, i)))
+   pci_claim_resource(dev, i);
}
 }
 
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Suspend-to-disk woes

[Nigel Cunningham]

Hi.

The simplest solution is to mkswap your swap partitions during boot.

Nigel

On Sat, 2005-03-19 at 03:28, Erik Andrén wrote:
> Hello, I experienced a pretty nasty problem a couple of days back:
> 
> I ran 2.6.11-ck1 and built 2.6.11-ck2. The last thing I did before 
> booting the new kernel was to suspend-to-disk the old kernel (something 
> I usually do as I'm working on this laptop).
> I ran the new kernel a couple of days and decided to boot the old kernel 
> to do some performance tests. Imagine my dread as the old kernel instead 
> of detecting that the system has booted another kernel just reloads the 
> old suspend-to-disk image. The result is that after succesfully 
> resuming, my harddrive goes bonkers and starts to work. After a couple 
> of minutes the whole kernel hangs. I reboot and try to boot the -ck2 
> kernel again only to find that the system complains as it finds missing 
> nodes. The reisertools try to rebuild the system unsucessully. The 
> --rebuild-tree parameter worked but a lot of files were still missing. 
> In the end I had to reinstall the whole system as it went so unstable.
> 
> My question is: Why isn't there a check before resuming a 
> suspend-to-disk image if the system has booted another kernel since the 
> suspend to prevent this kind of hassle?
> //Regards Erik Andrén
> 
> Please cc me as I'm not on the lkml list yadda yadda
> 
> -
> To unsubscribe from this list: send the 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/
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.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: fix-u32-vs-pm_message_t-in-usb

[Greg KH]

On Fri, Mar 11, 2005 at 02:08:31PM +0100, Pavel Machek wrote:
> Hi!
> 
> > This patch has been spitting warnings:
> > 
> > drivers/usb/host/uhci-hcd.c:838: warning: initialization from incompatible 
> > pointer type
> > drivers/usb/host/ohci-pci.c:191: warning: initialization from incompatible 
> > pointer type
> > 
> > Because hc_driver.suspend() takes a u32 as its second arg.  Changing that
> > to pci_power_t causes build failures and including pci.h in usb.h seems
> > wrong.
> > 
> > Wanna fix it sometime?
> 
> Yep. Here it is.
> 
> This fixes remaining confusion. Part of my old patch was merged, I
> later decided passing pci_power_t down to drivers is bad idea; this
> passes them pm_message_t which contains more info (and actually works
> :-). Please apply,

Argh, this one is already partially in, and another one you just sent me
has half of it in the tree too...

Care to just rediff off of 2.6.12-rc1?  Then we can hopefully get these
changes in :)

thanks,

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

[Patch 2/12] Fix pci_enable_device() for p2p bridges

[Rajesh Shah]

When checking if a PCI to PCI bridge should be enabled to decode
memory and/or IO resources, we need to look at all device 
resources not just the first 6. This is needed to allow PCI
bridges to pass down memory and IO accesses to child devices
even when the bridge itself does not consume resources in its
PCI BARs.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff -puN arch/ia64/pci/pci.c~fix-ia64-pcibios_enable_resources 
arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~fix-ia64-pcibios_enable_resources 
2005-03-16 13:07:02.055015329 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16 
13:07:02.164390328 -0800
@@ -436,18 +436,24 @@ pcibios_enable_resources (struct pci_dev
u16 cmd, old_cmd;
int idx;
struct resource *r;
+   unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM;
 
if (!dev)
return -EINVAL;
 
pci_read_config_word(dev, PCI_COMMAND, );
old_cmd = cmd;
-   for (idx=0; idx<6; idx++) {
+   for (idx=0; idxresource[idx];
+   if (!(r->flags & type_mask))
+   continue;
+   if ((idx == PCI_ROM_RESOURCE) &&
+   (!(r->flags & IORESOURCE_ROM_ENABLE)))
+   continue;
if (!r->start && r->end) {
printk(KERN_ERR
   "PCI: Device %s not available because of 
resource collisions\n",
@@ -459,8 +465,6 @@ pcibios_enable_resources (struct pci_dev
if (r->flags & IORESOURCE_MEM)
cmd |= PCI_COMMAND_MEMORY;
}
-   if (dev->resource[PCI_ROM_RESOURCE].start)
-   cmd |= PCI_COMMAND_MEMORY;
if (cmd != old_cmd) {
printk("PCI: Enabling device %s (%04x -> %04x)\n", 
pci_name(dev), old_cmd, cmd);
pci_write_config_word(dev, PCI_COMMAND, cmd);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RFC: Bug in generic_forget_inode() ?

[Russ Weight]

Andrew, Kirill,

I have been investigating a panic on an IBM X255 machine (4 physical
processors, 8 virtual with hyper-threading, 24GB RAM). I have narrowed
this down to a race condition between isofs mount and kswapd. I believe
this race condition is associated with the generic_forget_inode() issue
that you discussed in your email exchange back in September:

Kirill Korotaev <[EMAIL PROTECTED]> wrote:
>
> Hello,
> 
> 1. I found that generic_forget_inode() calls write_inode_now() 
> dropping inode_lock and destroys inode after that. The problem
> is that write_inode_now() can sleep and during this sleep someone
> can find inode in the hash, w/o I_FREEING state and with i_count = 0.

Although I have been testing with RHEL4 (2.6.9-5.ELsmp), I believe (by
code inspection) that the problem also exists in Linus' tree. I have
attempted to reproduce the problem with the 2.6.11 kernel, but I have
not succeeded in doing so - probably because of variations in low memory
usage, or timing differences...?

During the isofs mount, isofs_fill_super() allocates an inode and then
quickly frees it with iput (both cases are marked in the following code
snippet:

/*
 * Read the root inode, which _may_ result in changing
 * the s_rock flag. Once we have the final s_rock value,
 * we then decide whether to use the Joliet descriptor.
 */
>   inode = isofs_iget(s, sbi->s_firstdatazone, 0);
BC_LOG(1, 0xddd0, , 4);

/*
 * If this disk has both Rock Ridge and Joliet on it, then we
 * want to use Rock Ridge by default.  This can be overridden
 * by using the norock mount option.  There is still one other
 * possibility that is not taken into account: a Rock Ridge
 * CD with Unicode names.  Until someone sees such a beast, it
 * will not be supported.
 */
if (sbi->s_rock == 1) {
joliet_level = 0;
} else if (joliet_level) {
sbi->s_rock = 0;
if (sbi->s_firstdatazone != first_data_zone) {
sbi->s_firstdatazone = first_data_zone;
printk(KERN_DEBUG
"ISOFS: changing to secondary root\n");
BC_TAG(1, 0xddd1);
>   iput(inode);
inode = isofs_iget(s, sbi->s_firstdatazone, 0);
}
}

generic_forget_inode() is eventually called (within the context of
iput), the inode is placed on the unused list, and the inode_lock is
dropped.

kswapd calls prune_icache(), locks the inode_lock, and pulls the same
inode off of the unused list. Upon completion, prune_icache() calls
dispose_list() for the inodes that it has collected.

generic_forget_inode() calls write_inode_now(), which calls
__writeback_single_inode() which calls __sync_single_inode().
__sync_single_inode() panics when attempting to move the inode onto the
unused list (the last call to list_move). This is due to the poison
values that were previously loaded into the next and prev list pointers
by list_del().

I initially thought that I might be able to fix this particular case by 
removing the two lines of code below (delineated with the
FIX_INODE_PANIC constant). However, I believe that even if this didn't
break other code, it is not a complete fix, because __sync_single_inode
will eventually put the same inode on the unused list, the inode_lock
will be dropped, and you essentially have the same scenario:
generic_forget_inode() will cause a panic when calling list_del_init()
for this inode.

It seems to me that there needs to be a flag associated with the inode
(or the superblock?) that prevents kswapd from selecting this inode. Or,
since at this point the problem is specifically related to isofs, maybe
the isofs_fill_super() logic should be changed?

I would appreciate any suggestions for how this can best be fixed - or
if you have a fix in mind, I would be happy to test it (in the context
of the 2.6.9-5.ELsmp redhat kernel).

Thanks!

- Russ

static void generic_forget_inode(struct inode *inode)
{
struct super_block *sb = inode->i_sb;

if (!hlist_unhashed(>i_hash)) {
#define FIX_INODE_PANIC
#ifndef FIX_INODE_PANIC
if (!(inode->i_state & (I_DIRTY|I_LOCK)))
list_move(>i_list, _unused);
#endif /* FIX_INODE_PANIC */
inodes_stat.nr_unused++;
spin_unlock(_lock);
if (!sb || (sb->s_flags & MS_ACTIVE))
return;
write_inode_now(inode, 1);
spin_lock(_lock);
inodes_stat.nr_unused--;
hlist_del_init(>i_hash);
}
list_del_init(>i_list);
inode->i_state|=I_FREEING;
inodes_stat.nr_inodes--;
spin_unlock(_lock);
if (inode->i_data.nrpages)
truncate_inode_pages(>i_data, 0);
clear_inode(inode);

Re: [PATCH 2.6.11] aoe [1/12]: remove too-low cap on minor number

[Ed L Cashin]

Greg KH <[EMAIL PROTECTED]> writes:

> I've applied 11 of these 12 patches (the one from Randy was already
> included) to my trees.

Those haven't gone to the lkml yet.  I'll post them through gmane.
(The original postings never made it to the list, and I can't get in
touch with the lkml admins, but gmane should work.)

-- 
  Ed L Cashin <[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 1/12] ACPI based root bridge hot-add

[Rajesh Shah]

When you hot-plug a (root) bridge hierarchy, it may have p2p
bridges and devices attached to it that have not been configured
by firmware. In this case, we need to configure the devices 
before starting them. This patch separates device start from
device scan so that we can introduce the configuration step in
the middle. 

I kept the existing semantics for pci_scan_bus() since there
are a huge number of callers to that function.

Also, I have no way of testing the changes I made to the parisc
files, so this needs review by those folks. Sorry for the massive
cross-post, this touches files in many different places.

Signed-off-by: Rajesh Shah <[EMAIL PROTECTED]>
---

 linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c   |2 -
 linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c   |2 +
 linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c |2 +
 linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c  |2 -
 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c  |   16 +++-
 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_root.c  |   24 +-
 linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/dino.c|1 
 linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/lba_pci.c |2 +
 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c  |2 -
 linux-2.6.11-mm4-iohp-rshah1/include/linux/pci.h  |8 --
 10 files changed, 53 insertions(+), 8 deletions(-)

diff -puN arch/i386/pci/common.c~pci_serparate_device_add arch/i386/pci/common.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/common.c~pci_serparate_device_add   
2005-03-16 13:06:53.259117000 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c 2005-03-16 
13:06:53.419273248 -0800
@@ -133,7 +133,7 @@ struct pci_bus * __devinit pcibios_scan_
 
printk("PCI: Probing PCI hardware (bus %02x)\n", busnum);
 
-   return pci_scan_bus(busnum, _root_ops, NULL);
+   return pci_scan_bus_parented(NULL, busnum, _root_ops, NULL);
 }
 
 extern u8 pci_cache_line_size;
diff -puN arch/i386/pci/legacy.c~pci_serparate_device_add arch/i386/pci/legacy.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/legacy.c~pci_serparate_device_add   
2005-03-16 13:06:53.263999812 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c 2005-03-16 
13:06:53.420249810 -0800
@@ -45,6 +45,8 @@ static int __init pci_legacy_init(void)
 
printk("PCI: Probing PCI hardware\n");
pci_root_bus = pcibios_scan_root(0);
+   if (pci_root_bus)
+   pci_bus_add_devices(pci_root_bus);
 
pcibios_fixup_peer_bridges();
 
diff -puN arch/i386/pci/numa.c~pci_serparate_device_add arch/i386/pci/numa.c
--- linux-2.6.11-mm4-iohp/arch/i386/pci/numa.c~pci_serparate_device_add 
2005-03-16 13:06:53.267906062 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c   2005-03-16 
13:06:53.421226373 -0800
@@ -115,6 +115,8 @@ static int __init pci_numa_init(void)
return 0;
 
pci_root_bus = pcibios_scan_root(0);
+   if (pci_root_bus)
+   pci_bus_add_devices(pci_root_bus);
if (num_online_nodes() > 1)
for_each_online_node(quad) {
if (quad == 0)
diff -puN arch/ia64/pci/pci.c~pci_serparate_device_add arch/ia64/pci/pci.c
--- linux-2.6.11-mm4-iohp/arch/ia64/pci/pci.c~pci_serparate_device_add  
2005-03-16 13:06:53.272788874 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c2005-03-16 
13:06:53.430991997 -0800
@@ -330,7 +330,7 @@ pci_acpi_scan_root(struct acpi_device *d
acpi_walk_resources(device->handle, METHOD_NAME__CRS, add_window,
);
 
-   pbus = pci_scan_bus(bus, _root_ops, controller);
+   pbus = pci_scan_bus_parented(NULL, bus, _root_ops, controller);
if (pbus)
pcibios_setup_root_windows(pbus, controller);
 
diff -puN drivers/acpi/pci_bind.c~pci_serparate_device_add 
drivers/acpi/pci_bind.c
--- linux-2.6.11-mm4-iohp/drivers/acpi/pci_bind.c~pci_serparate_device_add  
2005-03-16 13:06:53.276695124 -0800
+++ linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c2005-03-16 
13:06:53.431968560 -0800
@@ -129,6 +129,8 @@ acpi_pci_bind (
char*pathname = NULL;
struct acpi_buffer  buffer = {0, NULL};
acpi_handle handle = NULL;
+   struct pci_dev  *dev;
+   struct pci_bus  *bus;
 
ACPI_FUNCTION_TRACE("acpi_pci_bind");
 
@@ -193,8 +195,20 @@ acpi_pci_bind (
 * Locate matching device in PCI namespace.  If it doesn't exist
 * this typically means that the device isn't currently inserted
 * (e.g. docking station, port replicator, etc.).
+* We cannot simply search the global pci device list, since
+* PCI devices are added to the global pci list when the root
+* bridge start ops are run, which may not have happened yet.
 */
-   data->dev = pci_find_slot(data->id.bus, PCI_DEVFN(data->id.device, 
data->id.function));
+   bus = 

Re: yenta_socket "nobody cared - Disabling IRQ #4"

[Daniel Ritz]

hi

it's the second time now i see this problem with an atheros chipset in
combination with a TI bridge. last time it was the 1225...
attached a patch that could help...

rgds
-daniel

--

for TI bridges: turn off interrupts during card power-on. this seems
to be neccessary for some combination of TI bridges with at least CB cards
with atheros chipset...problem is that they produce an interrupt storm
during power-on so the kernel happens to disable the IRQ which is a bad
thing (tm).
adds a generic hook function so that a socket driver can hook into
almost anywhere (by adding more hook points of course). this is the
cleanest way i can think of. and it allows adding more workarounds
for more problems...
for the TI specific interrupt on-off stuff just save the MFUNC register
and set it to 0 to disable all interrupts, restore it afterwards.

Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>



--- 1.22/drivers/pcmcia/ti113x.h2005-03-11 21:32:12 +01:00
+++ edited/drivers/pcmcia/ti113x.h  2005-03-18 22:06:12 +01:00
@@ -591,6 +591,35 @@
}
 }
 
+
+/* 
+ * TI specifiy parts for generic hook. generic hook really is specifiy to the
+ * chipset so there's no point having it in yenta_socket.c (for now)
+ *
+ * some TI's with some CB's produces interrupt storm on power on. it has been
+ * seen with atheros wlan cards on TI1225 and TI1410. solution is simply to
+ * disable any CB interrupts during this time.
+ */
+static int ti12xx_hook(struct pcmcia_socket *sock, int operation)
+{
+   struct yenta_socket *socket = container_of(sock, struct yenta_socket, 
socket);
+
+   switch (operation) {
+   case HOOK_POWER_PRE:
+   socket->saved_state[0] = config_readl(socket, TI122X_MFUNC);
+   config_writel(socket, TI122X_MFUNC, 0);
+   break;
+   
+   case HOOK_POWER_POST:
+   config_writel(socket, TI122X_MFUNC, socket->saved_state[0]);
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int ti12xx_override(struct yenta_socket *socket)
 {
u32 val, val_orig;
@@ -633,6 +662,9 @@
ti12xx_irqroute_func0(socket);
else
ti12xx_irqroute_func1(socket);
+
+   /* install generic hook */
+   socket->socket.ops->generic_hook = ti12xx_hook;
 
return ti_override(socket);
 }
--- 1.125/drivers/pcmcia/cs.c   2005-03-11 21:32:13 +01:00
+++ edited/drivers/pcmcia/cs.c  2005-03-12 21:22:38 +01:00
@@ -508,6 +508,10 @@
cs_err(skt, "unsupported voltage key.\n");
return CS_BAD_TYPE;
}
+
+   if (skt->ops->generic_hook)
+   skt->ops->generic_hook(skt, HOOK_POWER_PRE);
+
skt->socket.flags = 0;
skt->ops->set_socket(skt, >socket);
 
@@ -522,7 +526,12 @@
return CS_BAD_TYPE;
}
 
-   return socket_reset(skt);
+   status = socket_reset(skt);
+
+   if (skt->ops->generic_hook)
+   skt->ops->generic_hook(skt, HOOK_POWER_POST);
+
+   return status;
 }
 
 /*
--- 1.48/include/pcmcia/ss.h2005-03-11 21:32:13 +01:00
+++ edited/include/pcmcia/ss.h  2005-03-12 21:22:39 +01:00
@@ -77,6 +77,11 @@
 /* Use this just for bridge windows */
 #define MAP_IOSPACE0x20
 
+/* generic hook operations */
+#define HOOK_POWER_PRE 0x01
+#define HOOK_POWER_POST0x02
+
+
 typedef struct pccard_io_map {
 u_char map;
 u_char flags;
@@ -113,6 +118,7 @@
int (*set_socket)(struct pcmcia_socket *sock, socket_state_t *state);
nt (*set_io_map)(struct pcmcia_socket *sock, struct pccard_io_map *io);
int (*set_mem_map)(struct pcmcia_socket *sock, struct pccard_mem_map 
*mem);
+   int (*generic_hook)(struct pcmcia_socket *sock, int operation);
 };
 
 struct pccard_resource_ops {

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

[RFC/Patch 0/12] ACPI based root bridge hot-add

[Rajesh Shah]

Here is a series of patches to support ACPI hot-add of a root
bridge hierarchy. The added hierarchy may contain other p2p 
bridges and end/leaf I/O devices too. The root bridge itself is
assumed to have been assigned resource ranges, but the p2p
bridges and end devices are not required to be initialized by
firmware. Most of the code changes are to make the existing code
flows suitable for such a hierarchy of bridges & devices.

This code supports hot-add on ia64 only for now.It does not yet
support I/O APIC hot-add, which is needed to make this fully
functional.  The patches are against 2.6.11-mm4 (plus the patch 
needed for ia64 to boot). I've tested to make sure this does not 
break end/leaf device hotplug on the hotplug capable ia64 box I have.

Thanks,
Rajesh
-
To unsubscribe from this list: send the 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.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation

[Matt Domsch]

For review and comment.

On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones.  Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.

Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.

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

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

--- linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 13:01:44 2005
+++ linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 06:56:55 2005
@@ -13,18 +13,28 @@ void *pci_alloc_consistent(struct pci_de
   dma_addr_t *dma_handle)
 {
void *ret;
+   u64 mask;
+   int order = get_order(size);
int gfp = GFP_ATOMIC;
-   
-   if (hwdev == NULL ||
-   end_pfn > (hwdev->dma_mask>>PAGE_SHIFT) ||  /* XXX */
-   (u32)hwdev->dma_mask < 0x)
-   gfp |= GFP_DMA;
-   ret = (void *)__get_free_pages(gfp, get_order(size));
 
-   if (ret != NULL) {
-   memset(ret, 0, size);
+   if (hwdev)
+   mask = hwdev->dma_mask;
+   else
+   mask = 0xULL;
+
+   for (;;) {
+   ret = (void *)__get_free_pages(gfp, order);
+   if (ret == NULL)
+   return NULL;
*dma_handle = virt_to_bus(ret);
+   if ((*dma_handle & ~mask) == 0)
+   break;
+   free_pages((unsigned long)ret, order);
+   if (gfp & GFP_DMA)
+   return NULL;
+   gfp |= GFP_DMA;
}
+   memset(ret, 0, size);
return ret;
 }
 
-
To unsubscribe from this list: send the 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.4.30-pre3] linux/fs.h: remove root_device_name declaration

[Matt Domsch]

include/linux/fs.h has:
extern char root_device_name[];

but it's been declared static in init/do_mounts.c since March 2002.
gcc-4.0.0-0.32 from FC4-test1 errors out due to the static/non-static
mismatch.  Time to kill it from include/linux/fs.h.  

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

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

= include/linux/fs.h 1.100 vs edited =
--- 1.100/include/linux/fs.h2005-02-07 12:30:59 -06:00
+++ edited/include/linux/fs.h   2005-03-18 15:00:48 -06:00
@@ -1559,7 +1559,6 @@
 unsigned long generate_cluster(kdev_t, int b[], int);
 unsigned long generate_cluster_swab32(kdev_t, int b[], int);
 extern kdev_t ROOT_DEV;
-extern char root_device_name[];
 
 
 extern void show_buffers(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] io_remap_pfn_range: intro.

[David S. Miller]

On Fri, 18 Mar 2005 11:25:45 -0800
"Randy.Dunlap" <[EMAIL PROTECTED]> wrote:

> The sparc32 & sparc64 code needs live testing.

These patches look great Randy.  I think they should go in.

If sparc explodes, I'll clean up the mess.  Any problem which
crops up should not be difficult to solve.
-
To unsubscribe from this list: send the 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: Suspend-to-disk woes

[Stefan Seyfried]

Erik Andrén wrote:

> My question is: Why isn't there a check before resuming a 
> suspend-to-disk image if the system has booted another kernel since the 
> suspend to prevent this kind of hassle?

Just provide a patch which does this. Hint: this is highly nontrivial.
If you boot a kernel, that does not know swsusp (and if it knew, it
would have invalidated the suspend image in the swap), or which does not
have the necessary information (because of a missing resume= parameter),
this kernel cannot do much.

Stefan

-
To unsubscribe from this list: send the 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: Real-Time Preemption and RCU

[Paul E. McKenney]

On Fri, Mar 18, 2005 at 06:11:26PM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> 
> > For the patch, here are my questions:
> > 
> > o   What is the best way to select between classic RCU and this
> > scheme?
> > 
> > 1.  Massive #ifdef across rcupdate.c
> > 
> > 2.  Create an rcupdate_rt.c and browbeat the build system
> > into picking one or the other (no clue if this is
> > possible...)
> > 
> > 3.  Create an rcupdate_rt.c and rely on the linker to pick
> > one or the other, with rcupdate.h generating different
> > external symbol names to make the choice.
> 
> you can also go for option #0: just replace the existing RCU code with
> the new one, and i'll then deal with the configuration details.
> 
> what will have to happen is most likely #2 (since there is near zero
> code sharing between the two variants, right?). Picking rcupdate_rt.c is
> as simple as doing this:
> 
>  obj-$(CONFIG_DONT_PREEMPT_RCU) += rcupdate.o
>  obj-$(CONFIG_PREEMPT_RCU) += rcupdate_rt.o
> 
> and then use Kconfig to generate either CONFIG_DONT_PREEMPT_RCU
> (default) or CONFIG_PREEMPT_RCU (if the user selects it).
> 
> but it's not yet clear whether we want to offer this to users as a
> configurable option. The simplest solution for you would be to go with
> option #0 :-) [or if you prefer switchability, #1 is good too - i can
> then extract the bits and do #2 based on that.]
> 
> > o   How best to interface to OOM?  Left to myself, I leave this
> > for later.  ;-)
> 
> yeah, i'd not worry about OOM that much at this stage.
> 
> > I will take the cowardly approach of patching against the upstream
> > kernel.
> 
> sure. This is in fact easier for me: i'll first rip all my RCU hackery
> out of -RT and then add your code, so the base i'll be merging against
> will be closer to upstream than to current -RT.

Compiles, probably dies horribly.  "diff" didn't do such a good job
on this one, so attaching the raw rcupdate.[hc] files as well.

Thanx, Paul

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

diff -urpN -X ../dontdiff linux-2.5/include/linux/rcupdate.h 
linux-2.5-rtRCU/include/linux/rcupdate.h
--- linux-2.5/include/linux/rcupdate.h  Wed Mar  9 12:37:06 2005
+++ linux-2.5-rtRCU/include/linux/rcupdate.hFri Mar 18 11:37:02 2005
@@ -58,169 +58,11 @@ struct rcu_head {
(ptr)->next = NULL; (ptr)->func = NULL; \
 } while (0)
 
-
-
-/* Global control variables for rcupdate callback mechanism. */
-struct rcu_ctrlblk {
-   longcur;/* Current batch number.  */
-   longcompleted;  /* Number of the last completed batch */
-   int next_pending;   /* Is the next batch already waiting? */
-} cacheline_maxaligned_in_smp;
-
-/* Is batch a before batch b ? */
-static inline int rcu_batch_before(long a, long b)
-{
-return (a - b) < 0;
-}
-
-/* Is batch a after batch b ? */
-static inline int rcu_batch_after(long a, long b)
-{
-return (a - b) > 0;
-}
-
-/*
- * Per-CPU data for Read-Copy UPdate.
- * nxtlist - new callbacks are added here
- * curlist - current batch for which quiescent cycle started if any
- */
-struct rcu_data {
-   /* 1) quiescent state handling : */
-   longquiescbatch; /* Batch # for grace period */
-   int passed_quiesc;   /* User-mode/idle loop etc. */
-   int qs_pending;  /* core waits for quiesc state */
-
-   /* 2) batch handling */
-   longbatch;   /* Batch # for current RCU batch */
-   struct rcu_head *nxtlist;
-   struct rcu_head **nxttail;
-   struct rcu_head *curlist;
-   struct rcu_head **curtail;
-   struct rcu_head *donelist;
-   struct rcu_head **donetail;
-   int cpu;
-};
-
-DECLARE_PER_CPU(struct rcu_data, rcu_data);
-DECLARE_PER_CPU(struct rcu_data, rcu_bh_data);
-extern struct rcu_ctrlblk rcu_ctrlblk;
-extern struct rcu_ctrlblk rcu_bh_ctrlblk;
-
-/*
- * Increment the quiescent state counter.
- * The counter is a bit degenerated: We do not need to know
- * how many quiescent states passed, just if there was at least
- * one since the start of the grace period. Thus just a flag.
- */
-static inline void rcu_qsctr_inc(int cpu)
-{
-   struct rcu_data *rdp = _cpu(rcu_data, cpu);
-   rdp->passed_quiesc = 1;
-}
-static inline void rcu_bh_qsctr_inc(int cpu)
-{
-   struct rcu_data *rdp = _cpu(rcu_bh_data, cpu);
-   rdp->passed_quiesc = 1;
-}
-
-static inline int __rcu_pending(struct rcu_ctrlblk *rcp,
-   struct rcu_data *rdp)
-{
-   /* This cpu has pending rcu entries and the grace period
-* for them has completed.
-*/
-   if (rdp->curlist && !rcu_batch_before(rcp->completed, rdp->batch))
-   return 1;
-
-   /* This cpu has no pending entries, but 

Re: [PATCH] add a clear_pages function to clear pages of higher order

[Christoph Lameter]

On Fri, 18 Mar 2005, Andi Kleen wrote:

> It does not make any sense if you think of it - the memory bus
> of the CPU cannot be that much faster than the cache.

The memory bus would be able to reach a higher rate if properly optimized
for sequential writes to memory. A cache typically does random writes.
-
To unsubscribe from this list: send the 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/

kernel oops, 2.6.11.3

[Milan Svoboda]

Hello,

usbnet (iPAQ with Familiar) and harddisk connected throught usb were in use 
during this oops.

HW: HP Omnibook xt6200

Mar 18 20:09:07 drak_mrak kernel: Unable to handle kernel paging request at 
virtual address 1840
Mar 18 20:09:07 drak_mrak kernel:  printing eip:
Mar 18 20:09:07 drak_mrak kernel: c016ba37
Mar 18 20:09:07 drak_mrak kernel: *pde = 
Mar 18 20:09:07 drak_mrak kernel: Oops: 0002 [#1]
Mar 18 20:09:07 drak_mrak kernel: PREEMPT
Mar 18 20:09:07 drak_mrak kernel: Modules linked in: radeon drm nfsd exportfs 
lockd sunrpc nls_iso8859_2 nls_cp852
 vfat fat nls_base usb_storage usbnet snd_pcm_oss snd_mixer_oss uhci_hcd 
ehci_hcd ohci_hcd usbcore snd_ali5451 snd
_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc 8139too orinoco_pci 
orinoco hermes pcmcia yenta_socket
rsrc_nonstatic pcmcia_core sd_mod 8250 serial_core cpufreq_powersave 
cpufreq_ondemand thermal button battery acpi_
cpufreq freq_table processor evdev ali_agp agpgart psmouse
Mar 18 20:09:07 drak_mrak kernel: CPU:0
Mar 18 20:09:07 drak_mrak kernel: EIP:0060:[]Not tainted VLI
Mar 18 20:09:07 drak_mrak kernel: EFLAGS: 00010282   (2.6.11.3)
Mar 18 20:09:07 drak_mrak kernel: EIP is at prune_icache+0x197/0x210
Mar 18 20:09:07 drak_mrak kernel: eax: cf72cedc   ebx: cc40c084   ecx: 
cc40c084   edx: 1840
Mar 18 20:09:07 drak_mrak kernel: esi: cc40c07c   edi: 007b   ebp: 
c13e7ed8   esp: c13e7ec8
Mar 18 20:09:07 drak_mrak kernel: ds: 007b   es: 007b   ss: 0068
Mar 18 20:09:07 drak_mrak kernel: Process kswapd0 (pid: 150, 
threadinfo=c13e6000 task=c13bba80)
Mar 18 20:09:07 drak_mrak kernel: Stack: cc40c07c c13e7efc 0024 007b 
cc40cd74 cc819364 0081 
Mar 18 20:09:07 drak_mrak kernel: cfeee9e0 c016bacf 0080 
c013c0d4 0080 00d0 db3a
Mar 18 20:09:07 drak_mrak kernel:0002bc00  0003  
c02f1520 0002 c02f1520 db39
Mar 18 20:09:07 drak_mrak kernel: Call Trace:
Mar 18 20:09:07 drak_mrak kernel:  [] shrink_icache_memory+0x1f/0x50
Mar 18 20:09:07 drak_mrak kernel:  [] shrink_slab+0x154/0x190
Mar 18 20:09:07 drak_mrak kernel:  [] balance_pgdat+0x2db/0x3b0
Mar 18 20:09:07 drak_mrak kernel:  [] kswapd+0xe9/0x110
Mar 18 20:09:07 drak_mrak kernel:  [] 
autoremove_wake_function+0x0/0x60
Mar 18 20:09:07 drak_mrak kernel:  [] ret_from_fork+0x6/0x14
Mar 18 20:09:07 drak_mrak kernel:  [] 
autoremove_wake_function+0x0/0x60
Mar 18 20:09:07 drak_mrak kernel:  [] kswapd+0x0/0x110
Mar 18 20:09:07 drak_mrak kernel:  [] kernel_thread_helper+0x5/0x18
Mar 18 20:09:07 drak_mrak kernel: Code: a1 24 29 2f c0 83 e8 08 39 c6 0f 85 18 
ff ff ff 89 34 24 e8 2c fe ff ff 85
 c0 0f 84 08 ff ff ff 8b 56 04 85 d2 74 18 8b 06 85 c0 <89> 02 74 03 89 50 04 
c7 06 00 00 00 00 c7 46 04 00 00 00
00 8d
Mar 18 20:09:07 drak_mrak kernel:  <6>note: kswapd0[150] exited with 
preempt_count 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/

2.6.12-rc1-kj

[Domen Puncer]

A new release from kernel janitors (http://janitor.kernelnewbies.org/).

206 patches in this release.
88 patches were merged since 2.6.11-kj! Thanks to all maintainers!

Patchset is at http://coderock.org/kj/2.6.12-rc1-kj/


new in this release:

dma_mask-drivers_net.patch
  From: Tobias Klauser <[EMAIL PROTECTED]>
  Subject: drivers/net/: Use the DMA_{64,32}BIT_MASK constants

dma_mask-drivers_scsi.patch
  From: Tobias Klauser <[EMAIL PROTECTED]>
  Subject: drivers/scsi/: Use the DMA_{64,32}BIT_MASK constants

printk-drivers_video.patch
  From: James Nelson <[EMAIL PROTECTED]>
  Subject: drivers/video/: Clean up printk()'s

msleep-arch_m68k_atari_time.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [UPDATE PATCH] m68k/time: replace schedule_timeout() with   
msleep_interruptible()

msleep-drivers_acpi_osl.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [UPDATE PATCH] acpi/osl: correct HZ dependencies

msleep-drivers_block_paride_pg.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] paride/pg: replace pg_sleep() with msleep()

msleep-drivers_block_swim_iop.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] block/swim_iop: replace schedule_timeout() with 
msleep_interruptible()

wait_event-drivers_char_drm_drm_os_linux.h.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] drm/drm_os_linux: use   
wait_event_interruptible_timeout()

msleep-drivers_char_ds1620.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] char/ds1620: use msleep() instead of schedule_timeout()

msleep-drivers_char_tty_io.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] char/tty_io: replace schedule_timeout() with
msleep_interruptible()

msleep-drivers_serial_68360serial.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] serial/68360serial: replace schedule_timeout() with 
msleep_interruptible()

msleep-drivers_serial_68328serial.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] serial/68328serial: replace schedule_timeout() with 
msleep_interruptible()

msleep_interruptible_comment-kernel_timer.patch
  From: Nishanth Aravamudan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] kernel/timer: fix msleep_interruptible() comment

return_code-drivers_telephony_ixj.patch
  From: "Stephen Biggs" <[EMAIL PROTECTED]>
  Subject: [KJ] [UPDATED PATCH] ixj* - compile warning cleanup

whitespace-arch_i386_boot_bootsect.S.patch
  From: Daniel Dickman <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 2.6.11-bk1] CodingStyle: trivial whitespace fixups

dma_mask-drivers_ide_pci_cs5520.patch
  From: Tobias Klauser <[EMAIL PROTECTED]>
  Subject: [KJ] Re: [PATCH UPDATE] drivers/ide/cs5520.c : Use the DMA_{64,  
32}BIT_MASK constants

typo-include_linux_mm.h.patch
  From: Martin Hicks <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH/2.6.11] Spelling cleanups in shrinker code

sparse-init_do_mounts_initrd.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 1/] init/do_mounts_initrd.c: fix sparse warning

sparse-arch_i386_kernel_traps.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 2/] arch/i386/kernel/traps.c: fix sparse warnings

sparse-arch_i386_kernel_apm.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 3/] arch/i386/kernel/apm.c: fix sparse warnings

sparse-arch_i386_mm_fault.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 4/] arch/i386/mm/fault.c: fix sparse warnings

sparse-arch_i386_crypto_aes.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 5/] arch/i386/crypto/aes.c: fix sparse warnings

sparse-fs_cifs_cifssmb.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 6/] __le'ify posix_acl_xattr_entry,  
posix_acl_xattr_header

sparse-fs_affs_super.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 7/] fs/affs/super.c: fix sparse warning

sparse-fs_befs_endian.h.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 8/] fs/befs/endian.h: fix sparse warnings

sparse-fs_cifs_cifssmb-2.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH 9/] fs/cifs/cifssmb.c: fix the rest of sparse warnings

sparse-security_selinux_ss_policydb.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] security/selinux/ss/policydb.c: fix sparse warnings

sparse-fs_cifs_netmisc.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] fs/cifs/netmisc.c: fix sparse warning

sparse-fs_ext3_super.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] fs/ext3/super.c: fix sparse warnings

sparse-fs_ext3_resize.patch
  From: Alexey Dobriyan <[EMAIL PROTECTED]>
  Subject: [KJ] [PATCH] fs/ext3/resize.c: fix sparse warnings

sparse-fs_hpfs_inode.patch
  From: Alexey Dobriyan 

Re: [PATCH] Reading deterministic cache parameters and exporting it in /sysfs

[Dave Jones]

On Fri, Mar 18, 2005 at 11:18:47AM -0800, Venkatesh Pallipadi wrote:
 > 
 > Here is the updated patch. 
 > 
 > I have seperated out the changes related to 
 > (1) using new method to determine cache size in existing /proc/cpuinfo and
 > kernel boot messages (All but last hunk below)
 > (2) code to look at sharedness of the caches and store these details for 
 > future
 > uses inside kernel and also exporting the cache details in /sysfs (last
 > hunk in the patch)
 >   
 > Dave: Do you still feel having the cache details exported in /sysfs is a bad
 > idea? If yes, we can go ahead with the basic part of this patch (1 - above)
 > and look at (2) sometime later, as and when required.

tbh I think its just bloat, but if no-one else has any objections I won't 
oppose it.
The rest of the patch I have no problem with.

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/

[PATCH 0/4] io_remap_pfn_range: intro.

[Randy.Dunlap]

This is a combination of io_remap_pfn_range patches posted in the
last week or so by Keir Fraser and me.

This description is mostly from Keir's original post.


This patch introduces a new interface function for mapping bus/device
memory: io_remap_pfn_range. This accepts the same parameters as
remap_pfn_range and io_remap_page_range but should be used in any
situation where the caller is not simply remapping ordinary RAM.
For example, when mapping device registers the new function should be used.

The distinction between remapping device memory and ordinary RAM is
critical for the Xen hypervisor.

This patch series also cleans up the remaining users of
io_remap_page_range (in particular, the several sparc-specific
sections in various drivers that use a special form of io_remap_page_range:
an extra  argument for SPARC arch.) by converting them to
use io_remap_pfn_range(), where io_remap_pfn_range() supports
passing  as part of the pfn argument.

The sparc32 & sparc64 code needs live testing.


(from Keir:)
I have audited the drivers/ and sound/ directories. Most uses of
remap_pfn_range are okay, but there are a small handful that are
remapping device memory (mostly AGP and DRM drivers).

Of particular driver is the HPET driver, whose mmap function is broken
even for native (non-Xen) builds. If nothing else, vmalloc_to_phys
should be used instead of __pa to convert an ioremapped virtual
address to a valid physical address. The fix in this patch is to
remember the original bus address as probed at boot time and to pass
this to io_remap_pfn_range.


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

[PATCH 1/4] io_remap_pfn_range: add for all arch-es

[Randy.Dunlap]

io_remap_pfn_range():
  add io_remap_pfn_range() for all arches;
  add MK_IOSPACE_PFN(), GET_IOSPACE(), and GET_PFN()
for all arches but primarily for sparc32/64's extended IO space,
  sparc: kill the hack of using low bit of  to mean
write_combine or set side-effect (_PAGE_E) bit;
(DaveM suggested that I kill it;)
  future: convert remaining callers of io_remap_page_range() to
io_remap_pfn_range() and deprecate io_remap_page_range();

 arch/sparc/kernel/sparc_ksyms.c |1
 arch/sparc/mm/generic.c |   34 
 arch/sparc64/kernel/pci.c   |   15 +-
 arch/sparc64/kernel/sparc64_ksyms.c |6 +++-
 arch/sparc64/mm/generic.c   |   50 
 include/asm-alpha/pgtable.h |7 +
 include/asm-arm/pgtable.h   |7 +
 include/asm-arm26/pgtable.h |7 +
 include/asm-frv/pgtable.h   |7 +
 include/asm-h8300/pgtable.h |7 +
 include/asm-i386/pgtable.h  |7 +
 include/asm-ia64/pgtable.h  |7 +
 include/asm-m32r/pgtable.h  |7 +
 include/asm-m68k/pgtable.h  |7 +
 include/asm-m68knommu/pgtable.h |7 +
 include/asm-mips/pgtable.h  |   18 
 include/asm-parisc/pgtable.h|7 +
 include/asm-ppc/pgtable.h   |   16 +++
 include/asm-ppc64/pgtable.h |7 +
 include/asm-sh/pgtable.h|7 +
 include/asm-sh64/pgtable.h  |8 +
 include/asm-sparc/pgtable.h |   14 +-
 include/asm-sparc64/pgtable.h   |   12 
 include/asm-x86_64/pgtable.h|7 +
 24 files changed, 251 insertions(+), 21 deletions(-)

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/arch/sparc/kernel/sparc_ksyms.c 
linux-2611-bk3-pfn/arch/sparc/kernel/sparc_ksyms.c
--- linux-2611-bk3-pv/arch/sparc/kernel/sparc_ksyms.c   2005-03-01 
23:37:48.0 -0800
+++ linux-2611-bk3-pfn/arch/sparc/kernel/sparc_ksyms.c  2005-03-07 
11:04:59.0 -0800
@@ -164,6 +164,7 @@ EXPORT_SYMBOL(get_auxio);
 #endif
 EXPORT_SYMBOL(request_fast_irq);
 EXPORT_SYMBOL(io_remap_page_range);
+EXPORT_SYMBOL(io_remap_pfn_range);
   /* P3: iounit_xxx may be needed, sun4d users */
 /* EXPORT_SYMBOL(iounit_map_dma_init); */
 /* EXPORT_SYMBOL(iounit_map_dma_page); */
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/arch/sparc/mm/generic.c 
linux-2611-bk3-pfn/arch/sparc/mm/generic.c
--- linux-2611-bk3-pv/arch/sparc/mm/generic.c   2005-03-07 11:02:16.0 
-0800
+++ linux-2611-bk3-pfn/arch/sparc/mm/generic.c  2005-03-07 13:23:18.0 
-0800
@@ -118,3 +118,37 @@ int io_remap_page_range(struct vm_area_s
flush_tlb_range(vma, beg, end);
return error;
 }
+
+int io_remap_pfn_range(struct vm_area_struct *vma, unsigned long from,
+   unsigned long pfn, unsigned long size, pgprot_t prot)
+{
+   int error = 0;
+   pgd_t * dir;
+   unsigned long beg = from;
+   unsigned long end = from + size;
+   struct mm_struct *mm = vma->vm_mm;
+   int space = GET_IOSPACE(pfn);
+   unsigned long offset = GET_PFN(pfn) << PAGE_SHIFT;
+
+   prot = __pgprot(pg_iobits);
+   offset -= from;
+   dir = pgd_offset(mm, from);
+   flush_cache_range(vma, beg, end);
+
+   spin_lock(>page_table_lock);
+   while (from < end) {
+   pmd_t *pmd = pmd_alloc(current->mm, dir, from);
+   error = -ENOMEM;
+   if (!pmd)
+   break;
+   error = io_remap_pmd_range(mm, pmd, from, end - from, offset + 
from, prot, space);
+   if (error)
+   break;
+   from = (from + PGDIR_SIZE) & PGDIR_MASK;
+   dir++;
+   }
+   spin_unlock(>page_table_lock);
+
+   flush_tlb_range(vma, beg, end);
+   return error;
+}
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/arch/sparc64/kernel/pci.c 
linux-2611-bk3-pfn/arch/sparc64/kernel/pci.c
--- linux-2611-bk3-pv/arch/sparc64/kernel/pci.c 2005-03-07 11:02:16.0 
-0800
+++ linux-2611-bk3-pfn/arch/sparc64/kernel/pci.c2005-03-07 
11:04:59.0 -0800
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -734,12 +735,10 @@ static void __pci_mmap_set_flags(struct 
 static void __pci_mmap_set_pgprot(struct pci_dev *dev, struct vm_area_struct 
*vma,
 enum pci_mmap_state mmap_state)
 {
-   /* Our io_remap_page_range takes care of this, do nothing. */
+   /* Our io_remap_page_range/io_remap_pfn_range takes care of this,
+  do nothing. */
 }
 
-extern int io_remap_page_range(struct vm_area_struct *vma, unsigned long from, 
unsigned long offset,
-  unsigned long 

[PATCH 4/4] io_remap_pfn_range: convert last callers

[Randy.Dunlap]

io_remap_pfn_range() remaining callers:
  convert all remaining callers of io_remap_page_range()
  to io_remap_pfn_range();
  add io_remap_page_range() to feature-removal-schedule.txt;

 Documentation/feature-removal-schedule.txt |9 +
 arch/sh/kernel/cpu/sh4/sq.c|2 +-
 drivers/video/acornfb.c|2 +-
 drivers/video/au1100fb.c   |2 +-
 drivers/video/controlfb.c  |2 +-
 drivers/video/sa1100fb.c   |2 +-
 sound/core/pcm_native.c|4 ++--
 7 files changed, 16 insertions(+), 7 deletions(-)

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk10-remap1/arch/sh/kernel/cpu/sh4/sq.c 
linux-2611-bk10-remap2/arch/sh/kernel/cpu/sh4/sq.c
--- linux-2611-bk10-remap1/arch/sh/kernel/cpu/sh4/sq.c  2005-03-01 
23:38:07.0 -0800
+++ linux-2611-bk10-remap2/arch/sh/kernel/cpu/sh4/sq.c  2005-03-16 
09:46:10.0 -0800
@@ -379,7 +379,7 @@ static int sq_mmap(struct file *file, st
 
map = __sq_alloc_mapping(vma->vm_start, offset, size, "Userspace");
 
-   if (io_remap_page_range(vma, map->sq_addr, map->addr,
+   if (io_remap_pfn_range(vma, map->sq_addr, map->addr >> PAGE_SHIFT,
size, vma->vm_page_prot))
return -EAGAIN;
 
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk10-remap1/Documentation/feature-removal-schedule.txt 
linux-2611-bk10-remap2/Documentation/feature-removal-schedule.txt
--- linux-2611-bk10-remap1/Documentation/feature-removal-schedule.txt   
2005-03-16 09:16:26.0 -0800
+++ linux-2611-bk10-remap2/Documentation/feature-removal-schedule.txt   
2005-03-16 10:01:18.0 -0800
@@ -31,9 +31,18 @@ Why: /proc/sys/cpu/* has been deprecated
Both interfaces are superseded by the cpufreq interface in
/sys/devices/system/cpu/cpu%n/cpufreq/.
 Who:   Dominik Brodowski <[EMAIL PROTECTED]>
+---
 
 What:  ACPI S4bios support
 When:  May 2005
 Why:   Noone uses it, and it probably does not work, anyway. swsusp is
faster, more reliable, and people are actually using it.
 Who:   Pavel Machek <[EMAIL PROTECTED]>
+---
+
+What:  io_remap_page_range() (macro or function)
+When:  September 2005
+Why:   Replaced by io_remap_pfn_range() which allows more memory space
+   addressabilty (by using a pfn) and supports sparc & sparc64
+   iospace as part of the pfn.
+Who:   Randy Dunlap <[EMAIL PROTECTED]>
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk10-remap1/drivers/video/acornfb.c 
linux-2611-bk10-remap2/drivers/video/acornfb.c
--- linux-2611-bk10-remap1/drivers/video/acornfb.c  2005-03-01 
23:38:26.0 -0800
+++ linux-2611-bk10-remap2/drivers/video/acornfb.c  2005-03-16 
09:38:24.0 -0800
@@ -909,7 +909,7 @@ acornfb_mmap(struct fb_info *info, struc
 * some updates to the screen occasionally, but process switches
 * should cause the caches and buffers to be flushed often enough.
 */
-   if (io_remap_page_range(vma, vma->vm_start, off,
+   if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk10-remap1/drivers/video/au1100fb.c 
linux-2611-bk10-remap2/drivers/video/au1100fb.c
--- linux-2611-bk10-remap1/drivers/video/au1100fb.c 2005-03-01 
23:37:48.0 -0800
+++ linux-2611-bk10-remap2/drivers/video/au1100fb.c 2005-03-16 
09:33:56.0 -0800
@@ -408,7 +408,7 @@ au1100fb_mmap(struct fb_info *_fb,
/* This is an IO map - tell maydump to skip this VMA */
vma->vm_flags |= VM_IO;
 
-   if (io_remap_page_range(vma, vma->vm_start, off,
+   if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot)) {
return -EAGAIN;
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk10-remap1/drivers/video/controlfb.c 
linux-2611-bk10-remap2/drivers/video/controlfb.c
--- linux-2611-bk10-remap1/drivers/video/controlfb.c2005-03-01 
23:37:50.0 -0800
+++ linux-2611-bk10-remap2/drivers/video/controlfb.c2005-03-16 
09:37:11.0 -0800
@@ -315,7 +315,7 @@ static int controlfb_mmap(struct fb_info
return -EINVAL;
off += start;
vma->vm_pgoff = off >> PAGE_SHIFT;
-   if (io_remap_page_range(vma, vma->vm_start, off,
+   if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
 
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk10-remap1/drivers/video/sa1100fb.c 

[PATCH 2/4] io_remap_pfn_range: convert sparc callers

[Randy.Dunlap]

io_remap_pfn_range():
  convert sparc32/64 callers of io_remap_page_range(with 6 args)
  to io_remap_pfn_range(with 5 args);

 drivers/char/drm/drm_vm.c   |6 +++---
 drivers/sbus/char/vfc_dev.c |6 --
 drivers/video/fbmem.c   |6 +++---
 drivers/video/sbuslib.c |8 +---
 4 files changed, 15 insertions(+), 11 deletions(-)

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/drivers/char/drm/drm_vm.c 
linux-2611-bk3-pfn/drivers/char/drm/drm_vm.c
--- linux-2611-bk3-pv/drivers/char/drm/drm_vm.c 2005-03-01 23:38:33.0 
-0800
+++ linux-2611-bk3-pfn/drivers/char/drm/drm_vm.c2005-03-07 
11:04:59.0 -0800
@@ -625,10 +625,10 @@ int drm_mmap(struct file *filp, struct v
 #endif
offset = dev->driver->get_reg_ofs(dev);
 #ifdef __sparc__
-   if (io_remap_page_range(DRM_RPR_ARG(vma) vma->vm_start,
-   VM_OFFSET(vma) + offset,
+   if (io_remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start,
+   (VM_OFFSET(vma) + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
-   vma->vm_page_prot, 0))
+   vma->vm_page_prot))
 #else
if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start,
 (VM_OFFSET(vma) + offset) >> PAGE_SHIFT,
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/drivers/sbus/char/vfc_dev.c 
linux-2611-bk3-pfn/drivers/sbus/char/vfc_dev.c
--- linux-2611-bk3-pv/drivers/sbus/char/vfc_dev.c   2005-03-01 
23:38:10.0 -0800
+++ linux-2611-bk3-pfn/drivers/sbus/char/vfc_dev.c  2005-03-07 
11:04:59.0 -0800
@@ -626,8 +626,10 @@ static int vfc_mmap(struct file *file, s
vma->vm_flags |=
(VM_SHM | VM_LOCKED | VM_IO | VM_MAYREAD | VM_MAYWRITE | 
VM_MAYSHARE);
map_offset = (unsigned int) (long)dev->phys_regs;
-   ret = io_remap_page_range(vma, vma->vm_start, map_offset, map_size, 
- vma->vm_page_prot, dev->which_io);
+   ret = io_remap_pfn_range(vma, vma->vm_start,
+ MK_IOSPACE_PFN(dev->which_io,
+   map_offset >> PAGE_SHIFT),
+ map_size, vma->vm_page_prot);
 
if(ret)
return -EAGAIN;
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/drivers/video/fbmem.c linux-2611-bk3-pfn/drivers/video/fbmem.c
--- linux-2611-bk3-pv/drivers/video/fbmem.c 2005-03-01 23:37:30.0 
-0800
+++ linux-2611-bk3-pfn/drivers/video/fbmem.c2005-03-07 11:04:59.0 
-0800
@@ -940,8 +940,8 @@ fb_mmap(struct file *file, struct vm_are
/* This is an IO map - tell maydump to skip this VMA */
vma->vm_flags |= VM_IO | VM_RESERVED;
 #if defined(__sparc_v9__)
-   if (io_remap_page_range(vma, vma->vm_start, off,
-   vma->vm_end - vma->vm_start, vma->vm_page_prot, 
0))
+   if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
+   vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
 #else
 #if defined(__mc68000__)
@@ -977,7 +977,7 @@ fb_mmap(struct file *file, struct vm_are
 #else
 #warning What do we have to do here??
 #endif
-   if (io_remap_page_range(vma, vma->vm_start, off,
+   if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
 vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
 #endif /* !__sparc_v9__ */
diff -Naurp -X /home/rddunlap/doc/dontdiff-osdl 
linux-2611-bk3-pv/drivers/video/sbuslib.c 
linux-2611-bk3-pfn/drivers/video/sbuslib.c
--- linux-2611-bk3-pv/drivers/video/sbuslib.c   2005-03-01 23:37:52.0 
-0800
+++ linux-2611-bk3-pfn/drivers/video/sbuslib.c  2005-03-07 11:04:59.0 
-0800
@@ -74,10 +74,12 @@ int sbusfb_mmap_helper(struct sbus_mmap_
}
if (page + map_size > size)
map_size = size - page;
-   r = io_remap_page_range(vma,
+   r = io_remap_pfn_range(vma,
vma->vm_start + page,
-   map_offset, map_size,
-   vma->vm_page_prot, iospace);
+   MK_IOSPACE_PFN(iospace,
+   map_offset >> PAGE_SHIFT),
+   map_size,
+   vma->vm_page_prot);
if (r)
return -EAGAIN;
page += map_size;
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

[PATCH 3/4] io_remap_pfn_range: fix some callers for XEN

[Randy.Dunlap]

(from Keir:)
I have audited the drivers/ and sound/ directories. Most uses of
remap_pfn_range are okay, but there are a small handful that are
remapping device memory (mostly AGP and DRM drivers).

Of particular driver is the HPET driver, whose mmap function is broken
even for native (non-Xen) builds. If nothing else, vmalloc_to_phys
should be used instead of __pa to convert an ioremapped virtual
address to a valid physical address. The fix in this patch is to
remember the original bus address as probed at boot time and to pass
this to io_remap_pfn_range.

 drivers/char/agp/frontend.c |4 ++--
 drivers/char/drm/drm_vm.c   |2 +-
 drivers/char/drm/i810_dma.c |2 +-
 drivers/char/drm/i830_dma.c |2 +-
 drivers/char/hpet.c |6 --
 drivers/sbus/char/flash.c   |2 +-
 6 files changed, 10 insertions(+), 8 deletions(-)

Signed-off-by: Keir Fraser <[EMAIL PROTECTED]>


--- linux-2.6-old/drivers/char/agp/frontend.c   2005-03-16 10:30:25 +00:00
+++ linux-2.6-new/drivers/char/agp/frontend.c   2005-03-16 10:34:58 +00:00
@@ -628,7 +628,7 @@
DBG("client vm_ops=%p", kerninfo.vm_ops);
if (kerninfo.vm_ops) {
vma->vm_ops = kerninfo.vm_ops;
-   } else if (remap_pfn_range(vma, vma->vm_start,
+   } else if (io_remap_pfn_range(vma, vma->vm_start,
(kerninfo.aper_base + offset) >> PAGE_SHIFT,
size, vma->vm_page_prot)) {
goto out_again;
@@ -644,7 +644,7 @@
DBG("controller vm_ops=%p", kerninfo.vm_ops);
if (kerninfo.vm_ops) {
vma->vm_ops = kerninfo.vm_ops;
-   } else if (remap_pfn_range(vma, vma->vm_start,
+   } else if (io_remap_pfn_range(vma, vma->vm_start,
kerninfo.aper_base >> PAGE_SHIFT,
size, vma->vm_page_prot)) {
goto out_again;
--- linux-2.6-old/drivers/char/drm/drm_vm.c 2005-03-16 10:30:25 +00:00
+++ linux-2.6-new/drivers/char/drm/drm_vm.c 2005-03-16 10:34:58 +00:00
@@ -630,7 +630,7 @@
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
 #else
-   if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start,
+   if (io_remap_pfn_range(vma, vma->vm_start,
 (VM_OFFSET(vma) + offset) >> PAGE_SHIFT,
 vma->vm_end - vma->vm_start,
 vma->vm_page_prot))
--- linux-2.6-old/drivers/char/drm/i810_dma.c   2005-03-16 10:30:25 +00:00
+++ linux-2.6-new/drivers/char/drm/i810_dma.c   2005-03-16 10:34:58 +00:00
@@ -119,7 +119,7 @@
buf_priv->currently_mapped = I810_BUF_MAPPED;
unlock_kernel();
 
-   if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start,
+   if (io_remap_pfn_range(vma, vma->vm_start,
 VM_OFFSET(vma) >> PAGE_SHIFT,
 vma->vm_end - vma->vm_start,
 vma->vm_page_prot)) return -EAGAIN;
--- linux-2.6-old/drivers/char/drm/i830_dma.c   2005-03-16 10:30:25 +00:00
+++ linux-2.6-new/drivers/char/drm/i830_dma.c   2005-03-16 10:34:58 +00:00
@@ -121,7 +121,7 @@
buf_priv->currently_mapped = I830_BUF_MAPPED;
unlock_kernel();
 
-   if (remap_pfn_range(DRM_RPR_ARG(vma) vma->vm_start,
+   if (io_remap_pfn_range(vma, vma->vm_start,
 VM_OFFSET(vma) >> PAGE_SHIFT,
 vma->vm_end - vma->vm_start,
 vma->vm_page_prot)) return -EAGAIN;
--- linux-2.6-old/drivers/char/hpet.c   2005-03-16 10:30:25 +00:00
+++ linux-2.6-new/drivers/char/hpet.c   2005-03-16 10:34:58 +00:00
@@ -76,6 +76,7 @@
 struct hpets {
struct hpets *hp_next;
struct hpet __iomem *hp_hpet;
+   unsigned long hp_hpet_phys;
struct time_interpolator *hp_interpolator;
unsigned long hp_period;
unsigned long hp_delta;
@@ -265,7 +266,7 @@
return -EINVAL;
 
devp = file->private_data;
-   addr = (unsigned long)devp->hd_hpet;
+   addr = devp->hd_hpets->hp_hpet_phys;
 
if (addr & (PAGE_SIZE - 1))
return -ENOSYS;
@@ -274,7 +275,7 @@
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
addr = __pa(addr);
 
-   if (remap_pfn_range(vma, vma->vm_start, addr >> PAGE_SHIFT,
+   if (io_remap_pfn_range(vma, vma->vm_start, addr >> PAGE_SHIFT,
PAGE_SIZE, vma->vm_page_prot)) {
printk(KERN_ERR "remap_pfn_range failed in hpet.c\n");
return -EAGAIN;
@@ -795,6 +796,7 @@
 
hpetp->hp_which = hpet_nhpet++;
hpetp->hp_hpet = hdp->hd_address;
+   hpetp->hp_hpet_phys = hdp->hd_phys_address;
 

Announce loop-AES-v3.0c file/swap crypto package

[Jari Ruusu]

loop-AES changes since previous release:
- Changed gpg pipe code in losetup/mount to use '--no-options' instead of
  '--options /dev/null'. Fix from Lars Packschies.
- Changed losetup/mount programs to warn about unknown key data format.
- Added workaround for vanished QUEUE_FLAG_ORDERED define in 2.6.11-rc3-mm1
  kernel.
- Changed gcc command line parameter order to be same as in kernel Makefile.
  Wrong parameter order caused miscompilation with Xen architecture (2.6
  kernels).

bzip2 compressed tarball is here:

http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0c.tar.bz2
md5sum 3ba40e971da6a18df3e82fbbd3795ac8

http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0c.tar.bz2.sign


Additional ciphers package changes since previous release:
- Changed gcc command line parameter order to be same as in kernel Makefile.
  Wrong parameter order caused miscompilation with Xen architecture (2.6
  kernels).

bzip2 compressed tarball is here:

http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0b.tar.bz2
md5sum 603b188299dfbe1d05e3bca7d281a9a2

http://loop-aes.sourceforge.net/ciphers/ciphers-v3.0b.tar.bz2.sign

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PCI Error Recovery API Proposal. (WAS:: [PATCH/RFC]PCIErrorRecovery)

[Nguyen, Tom L]

On Thursday, March 17, 2005 2:58 PM Benjamin Herrenschmidt wrote:
> Does the link side of PCIE provides a way to trigger a hard reset of
the
> rest of the card ? If not, then it's dodgy as there may be no way to
> consistently "reset" the card if it's in a bad state. 

The PCI Express spec does not make it clear of whether an in-band
mechanism, called a hot-reset, triggers a hard reset of the rest of the
card. I agree that if not, then it's dodgy.

Thanks,
Long
-
To unsubscribe from this list: send the 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] add a clear_pages function to clear pages of higher order

[Andi Kleen]

On Fri, Mar 18, 2005 at 07:00:06AM -0800, Christoph Lameter wrote:
> On Fri, 18 Mar 2005, Denis Vlasenko wrote:
> 
> > NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> > the fact that zeroed page ends up evicted from cache. Luckily, this is 
> > exactly
> > what you want with prezeroing.
> 
> These are pretty significant results. Maybe its best to use non-temporal

The differences are actually less. I do not know what Denis benchmarked,
but in my tests the difference was never more than ~10%.  He got a zero
too much? 

It does not make any sense if you think of it - the memory bus
of the CPU cannot be that much faster than the cache.

And the drawback of eating the cache misses later is really very
significant.

> stores in general for clearing pages? I checked and Itanium has always
> used non-temporal stores. So there will be no benefit for us from this

That is weird. I would actually try to switch to temporal stores, maybe
it will improve some benchmarks. 

> approach (we have 16k and 64k page sizes which may make the situation a
> bit different). Try to update the i386 architectures to do the same?

Definitely not. 

You can experiment with using it for the cleaner daemon, but even
there I would use some heuristic to make sure you only use it 
on a page that are at the end of a pretty long queue.

e.g. if you can guarantee that the page allocator will go through
500k-1MB before going to the NT page that is cache cold it may
be a good idea. But that might be pretty complicated and I am not
sure it will be worth it.

But for the clear running in the page fault handler context it is 
definitely a bad idea.

-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: Questions about request_irq and reading PCI_INTERRUPT_LINE

[linux-os]

On Fri, 18 Mar 2005, Le Wen wrote:
On Fri, 18 Mar 2005, Le Wen wrote:
Hi, there,
I have problem to grab video from my ati all-in-wonder card. The card is in 
a PII Celeron machine with an on board video card (ATI Technologies Inc 3D 
Rage IIC AGP). there is no monitor connected with the on board video card. 
I only hook my AIW card with a monitor.

I use km-0.6 from gatos project. I load this km_drv module, but kernel 
always complains:

km: IRQ 0 busy
I checked code:
  km_probe(struct pci_dev *dev, const struct pci_device_id *pci_id)
here dev->irq with a value 0.
When km_probe gets called, it try to request an IRQ0 returns a -EBUSY:
  kms_irq=dev.irq;
  result=request_irq(kms->irq, handler, SA_SHIRQ, tag, (void *)kms);
  if(result==-EBUSY){
  printk(KERN_ERR "km: IRQ %ld busy\n", kms->irq);
  goto fail;
  }
So I tried to get right IRQ number using:
  u8 myirq;
  int rtn=pci_read_config_byte(dev,PCI_INTERRUPT_LINE, );
  dev->irq=myirq;
  kms->irq=dev_irq;
  result=request_irq(kms->irq, handler, SA_SHIRQ, tag, (void *)kms);
  if(result==-EBUSY){
  printk(KERN_ERR "km: IRQ %ld busy\n", kms->irq);
  goto fail;
  }
  if(result<0){
  printk(KERN_ERR "km: could not install irq handler: 
result=%d\n",result);
  goto fail;
  }
But this time I got:

km: kms->irq=24
km: could not install irq handler: result=-38
My questions are:
1. I don't know why dev->irq has value of 0?
The PCI interface now needs to be enabled first. The IRQ value
returned is BAD until after one calls pci_enable_device(). This
is a BUG, now considered a FEATURE so it's unlikely to be fixed!
There are lots of people who have encountered this problem
with modules that are not in the "distribution".
2. Is an IRQ number of 24 valid for a Intel PII Celeron?
Could be, but it;s probably invalid considering the way you
got it.
3. What does this result=-38 mean?
Probably errno 38, i.e., ENOSYS
Wen, Le
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Thank you Dick!
But pci_enable_device(dev) was called sucussful before read 
pci_read_config_byte():

static int __devinit km_probe(struct pci_dev *dev, const struct pci_device_id 
*pci_id)
{
...
if (pci_enable_device(dev))
  return -EIO;
  printk(KERN_DEBUG "pci_read_config_byte(dev,PCI_INTERRUPT_LINE, 
)\n");
  u8 myirq;//=0;
  int rtn=pci_read_config_byte(dev,PCI_INTERRUPT_LINE, );
  kms->dev=dev;
  dev->irq=myirq;
  kms->irq=dev->irq;
and then call
 result=request_irq(kms->irq, handler, SA_SHIRQ, tag, (void *)kms);

Whatever you do, do NOT read the PCI_INTERRUPT_LINE and think that
it is an IRQ. It's not. The low 4-bits show some stuff called an
"interrupt line", then there is the next 4-bits that is called
"interrupt pin". None of these values show you the IRQ to use!
In fact, INTA is required to be used for a "single-function"
device to generate interrupts. Therefore everything on the
usual PCI/Bus will be connected to INTA. INTA is some pin
that gets connected to a PC-board trace that only the vendor
(and BIOS group) knows. The Linux PCI interface gets its
information from the BIOS so it "knows" what the actual
IRQ is. You can't get that information by reading a PCI/Bus
device configuration register.
You code should do:
 find your device, then:
pci_enable_device(dev);
irq = dev->irq;
result=request_irq(irq, handler, SA_INTERRUPT|SA_SHIRQ,
  "device name", (void *)parameters);
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the 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] Reading deterministic cache parameters and exporting it in /sysfs

[Venkatesh Pallipadi]

Here is the updated patch. 

I have seperated out the changes related to 
(1) using new method to determine cache size in existing /proc/cpuinfo and
kernel boot messages (All but last hunk below)
(2) code to look at sharedness of the caches and store these details for future
uses inside kernel and also exporting the cache details in /sysfs (last
hunk in the patch)
  
Dave: Do you still feel having the cache details exported in /sysfs is a bad
idea? If yes, we can go ahead with the basic part of this patch (1 - above)
and look at (2) sometime later, as and when required.

Thanks,
Venki



The attached patch adds support for using cpuid(4) instead of cpuid(2), to get
CPU cache information in a deterministic way for Intel CPUs, whenever
supported. The details of cpuid(4) can be found here

IA-32 Intel Architecture Software Developer's Manual (vol 2a)
(http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a)
and
Prescott New Instructions (PNI) Technology: Software Developer's Guide
(http://www.intel.com/cd/ids/developer/asmo-na/eng/events/43988.htm)

The advantage of using the cpuid(4) ('Deterministic Cache Parameters Leaf') are:
* It provides more information than the descriptors provided by cpuid(2)
* It is not table based as cpuid(2). So, we will not need changes to the
  kernel to support new cache descriptors in the descriptor table (as is the
  case with cpuid(2)).

The patch also adds a bunch of interfaces under
/sys/devices/system/cpu/cpuX/cache, showing various information about the
caches. Most useful field being shared_cpu_map, which says what caches are
shared among which logical cpus.

The patch adds support for both i386 and x86-64.

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>


--- linux-2.6.11/include/asm-i386/processor.h.org   2005-03-18 
12:39:09.0 -0800
+++ linux-2.6.11/include/asm-i386/processor.h   2005-03-18 08:44:56.0 
-0800
@@ -147,6 +147,18 @@ static inline void cpuid(int op, int *ea
: "0" (op), "c"(0));
 }
 
+/* Some CPUID calls want 'count' to be placed in ecx */
+static inline void cpuid_count(int op, int count, int *eax, int *ebx, int *ecx,
+   int *edx)
+{
+   __asm__("cpuid"
+   : "=a" (*eax),
+ "=b" (*ebx),
+ "=c" (*ecx),
+ "=d" (*edx)
+   : "0" (op), "c" (count));
+}
+
 /*
  * CPUID functions returning a single datum
  */
--- linux-2.6.11/include/asm-x86_64/msr.h.org   2005-03-14 13:27:47.0 
-0800
+++ linux-2.6.11/include/asm-x86_64/msr.h   2005-03-18 08:46:22.0 
-0800
@@ -78,6 +78,18 @@ extern inline void cpuid(int op, unsigne
: "0" (op));
 }
 
+/* Some CPUID calls want 'count' to be placed in ecx */
+static inline void cpuid_count(int op, int count, int *eax, int *ebx, int *ecx,
+   int *edx)
+{
+   __asm__("cpuid"
+   : "=a" (*eax),
+ "=b" (*ebx),
+ "=c" (*ecx),
+ "=d" (*edx)
+   : "0" (op), "c" (count));
+}
+
 /*
  * CPUID functions returning a single datum
  */
--- linux-2.6.11/arch/i386/kernel/cpu/intel_cacheinfo.c.org 2005-03-14 
13:27:20.0 -0800
+++ linux-2.6.11/arch/i386/kernel/cpu/intel_cacheinfo.c 2005-03-18 
13:46:54.0 -0800
@@ -1,5 +1,18 @@
+/*
+ *  Routines to indentify caches on Intel CPU.
+ *
+ *  Changes:
+ *  Venkatesh Pallipadi: Adding cache identification through cpuid(4)
+ */
+
 #include 
+#include 
+#include 
+#include 
+#include 
+
 #include 
+#include 
 
 #define LVL_1_INST 1
 #define LVL_1_DATA 2
@@ -58,10 +71,142 @@ static struct _cache_table cache_table[]
{ 0x00, 0, 0}
 };
 
+
+enum _cache_type
+{
+   CACHE_TYPE_NULL = 0,
+   CACHE_TYPE_DATA = 1,
+   CACHE_TYPE_INST = 2,
+   CACHE_TYPE_UNIFIED = 3
+};
+
+union _cpuid4_leaf_eax {
+   struct {
+   enum _cache_typetype:5;
+   unsigned intlevel:3;
+   unsigned intis_self_initializing:1;
+   unsigned intis_fully_associative:1;
+   unsigned intreserved:4;
+   unsigned intnum_threads_sharing:12;
+   unsigned intnum_cores_on_die:6;
+   } split;
+   u32 full;
+};
+
+union _cpuid4_leaf_ebx {
+   struct {
+   unsigned intcoherency_line_size:12;
+   unsigned intphysical_line_partition:10;
+   unsigned intways_of_associativity:10;
+   } split;
+   u32 full;
+};
+
+union _cpuid4_leaf_ecx {
+   struct {
+   unsigned intnumber_of_sets:32;
+   } split;
+   u32 full;
+};
+
+struct _cpuid4_info {
+   union _cpuid4_leaf_eax eax;
+   union _cpuid4_leaf_ebx ebx;
+   union _cpuid4_leaf_ecx ecx;
+   unsigned long size;
+   cpumask_t shared_cpu_map;
+};
+

Re: vm_dirty_ratio seems a bit large.

[Andrew Morton]

Robin Holt <[EMAIL PROTECTED]> wrote:
>
> > No, you could just extend them to understand fixed point.  Keep
>  > printing integers as integers, print non-integers with one (or two:
>  > will we ever need 0.01% increments?) decimal places.
> 
>  Right now, it is possible to build our largest Altix configuration with
>  64TB of memory (unfortunatetly, we can't get any customers to pay that
>  large of bill ;).  We are currently shipping a few 4TB systems and hope
>  to be selling 20TB systems by the end of the year (at least engineering
>  hopes to).
> 
>  Given that, two decimal places are really not enough.  We probably need
>  at least 3.
> 
>  Is there any reason to not do 3 places?  Is this the right direction to
>  head or does anybody know of problems this would cause?

It's a rather unorthodox fix, but not illogical.  I guess it depends upon
how much sysctl infrastructure it adds.  Probably quite a lot.

Another approach would be to just say the ratio now has a range 0 .. 
999,999 and then, if it happens to be less than 100, treat that as a
percentage for back-compatibility reasons.  Although that's a bit kludgy
and perhaps a completely new /proc entry would be better.

-
To unsubscribe from this list: send the 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.11 breaks modules gratuitously

[Adrian Bunk]

On Fri, Mar 18, 2005 at 02:01:02PM -0500, John Kacur wrote:
> 
> So perhaps we can introduce a new term to linux kernel development,
> reexporting a symbol can now be known as debunking?
>...
 
Are you saying unexporting a symbol was bunk?  ;-)

cu
Adrian

-- 

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

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

Re: Questions about request_irq and reading PCI_INTERRUPT_LINE

[Le Wen]

On Fri, 18 Mar 2005, Le Wen wrote:
Hi, there,
I have problem to grab video from my ati all-in-wonder card. The card is in 
a PII Celeron machine with an on board video card (ATI Technologies Inc 3D 
Rage IIC AGP). there is no monitor connected with the on board video card. 
I only hook my AIW card with a monitor.

I use km-0.6 from gatos project. I load this km_drv module, but kernel 
always complains:

km: IRQ 0 busy
I checked code:
  km_probe(struct pci_dev *dev, const struct pci_device_id *pci_id)
here dev->irq with a value 0.
When km_probe gets called, it try to request an IRQ0 returns a -EBUSY:
  kms_irq=dev.irq;
  result=request_irq(kms->irq, handler, SA_SHIRQ, tag, (void *)kms);
  if(result==-EBUSY){
  printk(KERN_ERR "km: IRQ %ld busy\n", kms->irq);
  goto fail;
  }
So I tried to get right IRQ number using:
  u8 myirq;
  int rtn=pci_read_config_byte(dev,PCI_INTERRUPT_LINE, );
  dev->irq=myirq;
  kms->irq=dev_irq;
  result=request_irq(kms->irq, handler, SA_SHIRQ, tag, (void *)kms);
  if(result==-EBUSY){
  printk(KERN_ERR "km: IRQ %ld busy\n", kms->irq);
  goto fail;
  }
  if(result<0){
  printk(KERN_ERR "km: could not install irq handler: 
result=%d\n",result);
  goto fail;
  }
But this time I got:

km: kms->irq=24
km: could not install irq handler: result=-38
My questions are:
1. I don't know why dev->irq has value of 0?
The PCI interface now needs to be enabled first. The IRQ value
returned is BAD until after one calls pci_enable_device(). This
is a BUG, now considered a FEATURE so it's unlikely to be fixed!
There are lots of people who have encountered this problem
with modules that are not in the "distribution".
2. Is an IRQ number of 24 valid for a Intel PII Celeron?
Could be, but it;s probably invalid considering the way you
got it.
3. What does this result=-38 mean?
Probably errno 38, i.e., ENOSYS
Wen, Le
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
Thank you Dick!
But pci_enable_device(dev) was called sucussful before read 
pci_read_config_byte():

static int __devinit km_probe(struct pci_dev *dev, const struct 
pci_device_id *pci_id)
{
...
if (pci_enable_device(dev))
   return -EIO;
   printk(KERN_DEBUG "pci_read_config_byte(dev,PCI_INTERRUPT_LINE, 
)\n");
   u8 myirq;//=0;
   int rtn=pci_read_config_byte(dev,PCI_INTERRUPT_LINE, );
   kms->dev=dev;
   dev->irq=myirq;
   kms->irq=dev->irq;
and then call
  result=request_irq(kms->irq, handler, SA_SHIRQ, tag, (void *)kms);

-
To unsubscribe from this list: send the 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/