[patch 00/69] -stable review

[patch 00/69] -stable review

[Chris Wright]

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

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

Responses should be made by Wed May 23 19:15 UTC.  Anything received
after that time might be too late.

thanks,

the -stable release team
-- 

[patch 01/69] ipv6: track device renames in snmp6

[Chris Wright]

[-- Attachment #1: ipv6-track-device-renames-in-snmp6.patch --]
[-- Type: text/plain, Size: 1554 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

When network device's are renamed, the IPV6 snmp6 code
gets confused. It doesn't track name changes so it will OOPS
when network device's are removed.

The fix is trivial, just unregister/re-register in notify handler.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/ipv6/addrconf.c |    6 ++++--
 net/ipv6/proc.c     |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

--- linux-2.6.21.1.orig/net/ipv6/addrconf.c
+++ linux-2.6.21.1/net/ipv6/addrconf.c
@@ -2281,8 +2281,9 @@ static int addrconf_notify(struct notifi
 		break;
 
 	case NETDEV_CHANGENAME:
-#ifdef CONFIG_SYSCTL
 		if (idev) {
+			snmp6_unregister_dev(idev);
+#ifdef CONFIG_SYSCTL
 			addrconf_sysctl_unregister(&idev->cnf);
 			neigh_sysctl_unregister(idev->nd_parms);
 			neigh_sysctl_register(dev, idev->nd_parms,
@@ -2290,8 +2291,9 @@ static int addrconf_notify(struct notifi
 					      &ndisc_ifinfo_sysctl_change,
 					      NULL);
 			addrconf_sysctl_register(idev, &idev->cnf);
-		}
 #endif
+			snmp6_register_dev(idev);
+		}
 		break;
 	};
 
--- linux-2.6.21.1.orig/net/ipv6/proc.c
+++ linux-2.6.21.1/net/ipv6/proc.c
@@ -236,6 +236,7 @@ int snmp6_unregister_dev(struct inet6_de
 		return -EINVAL;
 	remove_proc_entry(idev->stats.proc_dir_entry->name,
 			  proc_net_devsnmp6);
+	idev->stats.proc_dir_entry = NULL;
 	return 0;
 }
 

-- 

[patch 02/69] sis900: Allocate rx replacement buffer before rx operation

[Chris Wright]

[-- Attachment #1: sis900-allocate-rx-replacement-buffer-before-rx-operation.patch --]
[-- Type: text/plain, Size: 2285 bytes --]

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

From: Neil Horman <nhorman@tuxdriver.com>

Just found a hole in my last patch.  It was reported to me that shortly after we
integrated this patch.  The report was of an oops that took place inside of
netif_rx when using the sis900 driver.  Looking at my origional patch I noted
that there was a spot between the new skb_alloc and the refill_rx_ring label
where skb got reassigned to the pointer currently held in the rx_ring for the
purposes of receiveing the frame.  The result of this is however that the buffer
that gets passed to netif_rx (if it is called), then gets placed right back into
the rx_ring.  So if you receive frames fast enough the skb being processed by
the network stack can get corrupted.  The reporter is testing out the fix I've
written for this below (I'm not near my hardware at the moment to test myself),
but I wanted to post it for review ASAP.  I'll post test results when I hear
them, but I think this is a pretty straightforward fix.  It just uses a separate
pointer to do the rx operation, so that we don't improperly reassign the pointer
that we use to refill the rx ring.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/net/sis900.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/sis900.c
+++ linux-2.6.21.1/drivers/net/sis900.c
@@ -1754,6 +1754,7 @@ static int sis900_rx(struct net_device *
 			sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE;
 		} else {
 			struct sk_buff * skb;
+			struct sk_buff * rx_skb;
 
 			pci_unmap_single(sis_priv->pci_dev,
 				sis_priv->rx_ring[entry].bufptr, RX_BUF_SIZE,
@@ -1787,10 +1788,10 @@ static int sis900_rx(struct net_device *
 			}
 
 			/* give the socket buffer to upper layers */
-			skb = sis_priv->rx_skbuff[entry];
-			skb_put(skb, rx_size);
-			skb->protocol = eth_type_trans(skb, net_dev);
-			netif_rx(skb);
+			rx_skb = sis_priv->rx_skbuff[entry];
+			skb_put(rx_skb, rx_size);
+			rx_skb->protocol = eth_type_trans(rx_skb, net_dev);
+			netif_rx(rx_skb);
 
 			/* some network statistics */
 			if ((rx_status & BCAST) == MCAST)

-- 

[patch 03/69] smc911x: fix compilation breakage wjen debug is on

[Chris Wright]

[-- Attachment #1: smc911x-fix-compilation-breakage-wjen-debug-is-on.patch --]
[-- Type: text/plain, Size: 916 bytes --]

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

From: Vitaly Wool <vwool@ru.mvista.com>

the patch below fixes compilation breakage of smc911x driver when ENABLE_SMC_DEBUG_PKTS equals to 1.

Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 drivers/net/smc911x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


--- linux-2.6.21.1.orig/drivers/net/smc911x.c
+++ linux-2.6.21.1/drivers/net/smc911x.c
@@ -499,7 +499,7 @@ static inline void	 smc911x_rcv(struct n
 		SMC_SET_RX_CFG(RX_CFG_RX_END_ALGN4_ | ((2<<8) & RX_CFG_RXDOFF_));
 		SMC_PULL_DATA(data, pkt_len+2+3);
 
-		DBG(SMC_DEBUG_PKTS, "%s: Received packet\n", dev->name,);
+		DBG(SMC_DEBUG_PKTS, "%s: Received packet\n", dev->name);
 		PRINT_PKT(data, ((pkt_len - 4) <= 64) ? pkt_len - 4 : 64);
 		dev->last_rx = jiffies;
 		skb->dev = dev;

-- 

[patch 04/69] ACPI: Fix 2.6.21 boot regression on P4/HT

[Chris Wright]

[-- Attachment #1: acpi-fix-2.6.21-boot-regression-on-p4-ht.patch --]
[-- Type: text/plain, Size: 1484 bytes --]

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

From: Len Brown <lenb@kernel.org>

Up through 2.6.20 we cleared the FADT.CSTATE_CONTROL field
for FADT versions before r3, because it made no sense
for that reserved field to be set for pre-ACPI 2.0 systems.

It turns out that not clearing this field exposes
Linux to SMM BIOS failures, so do the same in 2.6.21.

http://bugzilla.kernel.org/show_bug.cgi?id=8346

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/acpi/tables/tbfadt.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- linux-2.6.21.1.orig/drivers/acpi/tables/tbfadt.c
+++ linux-2.6.21.1/drivers/acpi/tables/tbfadt.c
@@ -347,6 +347,20 @@ static void acpi_tb_convert_fadt(void)
 		acpi_gbl_xpm1b_enable.space_id = acpi_gbl_FADT.xpm1a_event_block.space_id;
 
 	}
+	/*
+	 * _CST object and C States change notification start with
+	 * ACPI 2.0 (FADT r3).  Although the field should be Reserved
+	 * and 0 before then, some pre-r3 FADT set this field and
+	 * it results in SMM-related boot failures.  For them, clear it.
+	 */
+	if ((acpi_gbl_FADT.header.revision < 3) &&
+		(acpi_gbl_FADT.cst_control != 0)) {
+			ACPI_WARNING((AE_INFO,
+				"Ignoring BIOS FADT r%u C-state control",
+				acpi_gbl_FADT.header.revision));
+		 	acpi_gbl_FADT.cst_control = 0;
+	}
+
 }
 
 /******************************************************************************

-- 

[patch 05/69] cxacru: Fix infinite loop when trying to cancel polling task

[Chris Wright]

[-- Attachment #1: cxacru-fix-infinite-loop-when-trying-to-cancel-polling-task.patch --]
[-- Type: text/plain, Size: 3313 bytes --]

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

From: Simon Arlott <simon@fire.lp0.eu>

As part of the device initialisation cxacru_atm_start starts 
a rearming status polling task, which is cancelled in 
cxacru_unbind. Failure to ever start the task means an 
infinite loop occurs trying to cancel it.

Possible reasons for not starting the polling task:
* Firmware files missing
* Device initialisation fails
* User unplugs device or unloads module

Effect:
* Infinite loop in khubd trying to add/remove the device (or rmmod if timed right)

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
Fixed for 2.6.22 by 6a02c996bce297a782432e29c69268356e97fadd.

 drivers/usb/atm/cxacru.c |   40 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 36 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/drivers/usb/atm/cxacru.c
+++ linux-2.6.21.1/drivers/usb/atm/cxacru.c
@@ -146,6 +146,12 @@ enum cxacru_info_idx {
 	CXINF_MAX = 0x1c,
 };
 
+enum poll_state {
+	CX_INIT,
+	CX_POLLING,
+	CX_ABORT
+};
+
 struct cxacru_modem_type {
 	u32 pll_f_clk;
 	u32 pll_b_clk;
@@ -159,6 +165,8 @@ struct cxacru_data {
 
 	int line_status;
 	struct delayed_work poll_work;
+	struct mutex poll_state_serialize;
+	enum poll_state poll_state;
 
 	/* contol handles */
 	struct mutex cm_serialize;
@@ -356,7 +364,7 @@ static int cxacru_atm_start(struct usbat
 	/*
 	struct atm_dev *atm_dev = usbatm_instance->atm_dev;
 	*/
-	int ret;
+	int ret, start_polling = 1;
 
 	dbg("cxacru_atm_start");
 
@@ -376,7 +384,15 @@ static int cxacru_atm_start(struct usbat
 	}
 
 	/* Start status polling */
-	cxacru_poll_status(&instance->poll_work.work);
+	mutex_lock(&instance->poll_state_serialize);
+	if (instance->poll_state == CX_INIT)
+		instance->poll_state = CX_POLLING;
+	else /* poll_state == CX_ABORT */
+		start_polling = 0;
+	mutex_unlock(&instance->poll_state_serialize);
+
+	if (start_polling)
+		cxacru_poll_status(&instance->poll_work.work);
 	return 0;
 }
 
@@ -685,6 +701,9 @@ static int cxacru_bind(struct usbatm_dat
 	instance->usbatm = usbatm_instance;
 	instance->modem_type = (struct cxacru_modem_type *) id->driver_info;
 
+	mutex_init(&instance->poll_state_serialize);
+	instance->poll_state = CX_INIT;
+
 	instance->rcv_buf = (u8 *) __get_free_page(GFP_KERNEL);
 	if (!instance->rcv_buf) {
 		dbg("cxacru_bind: no memory for rcv_buf");
@@ -744,6 +763,7 @@ static void cxacru_unbind(struct usbatm_
 		struct usb_interface *intf)
 {
 	struct cxacru_data *instance = usbatm_instance->driver_data;
+	int stop_polling = 1;
 
 	dbg("cxacru_unbind entered");
 
@@ -752,8 +772,20 @@ static void cxacru_unbind(struct usbatm_
 		return;
 	}
 
-	while (!cancel_delayed_work(&instance->poll_work))
-	       flush_scheduled_work();
+	mutex_lock(&instance->poll_state_serialize);
+	if (instance->poll_state != CX_POLLING) {
+		/* Polling hasn't started yet and with
+		 * the mutex locked it can be prevented
+		 * from starting.
+		 */
+		instance->poll_state = CX_ABORT;
+		stop_polling = 0;
+	}
+	mutex_unlock(&instance->poll_state_serialize);
+
+	if (stop_polling)
+		while (!cancel_delayed_work(&instance->poll_work))
+			flush_scheduled_work();
 
 	usb_kill_urb(instance->snd_urb);
 	usb_kill_urb(instance->rcv_urb);

-- 

[patch 06/69] reiserfs: suppress lockdep warning

[Chris Wright]

[-- Attachment #1: reiserfs-suppress-lockdep-warning.patch --]
[-- Type: text/plain, Size: 1024 bytes --]

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

From: Jeff Mahoney <jeffm@suse.de>

We're getting lockdep warnings due to a post-2.6.21-rc7 bugfix.

The xattr_sem can never be taken in the manner described. Internal inodes
are protected by I_PRIVATE.  Add the appropriate annotation.

Cc: <stable@kernel.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 fs/reiserfs/xattr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/fs/reiserfs/xattr.c
+++ linux-2.6.21.1/fs/reiserfs/xattr.c
@@ -68,7 +68,7 @@ static struct dentry *get_xa_root(struct
 	if (!privroot)
 		return ERR_PTR(-ENODATA);
 
-	mutex_lock(&privroot->d_inode->i_mutex);
+	mutex_lock_nested(&privroot->d_inode->i_mutex, I_MUTEX_XATTR);
 	if (REISERFS_SB(sb)->xattr_root) {
 		xaroot = dget(REISERFS_SB(sb)->xattr_root);
 		goto out;

-- 

[patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Chris Wright]

[-- Attachment #1: libata-sff-undo-bug-introduced-with-pci_iomap-changes.patch --]
[-- Type: text/plain, Size: 2382 bytes --]

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

From: Alan Cox <alan@lxorguk.ukuu.org.uk>

If you have a controller with one channel disabled and unmapped the new
iomap code blindly tries to iomap unconfigured BARs. Later on the code
does the right thing and checks for unmapped bars but it is done in the
wrong order

Reorder the checks and make the iomap conditional

Tejun: I think the code below is now correct but would appreciate you
giving it a review.

Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
[chrisw: Why is this not upstream yet?]

 drivers/ata/libata-sff.c |   35 +++++++++++++++++++++++------------
 1 file changed, 23 insertions(+), 12 deletions(-)

--- linux-2.6.21.1.orig/drivers/ata/libata-sff.c
+++ linux-2.6.21.1/drivers/ata/libata-sff.c
@@ -557,12 +557,30 @@ ata_pci_init_native_mode(struct pci_dev 
 	int i, p = 0;
 	void __iomem * const *iomap;
 
+	/* Discard disabled ports. Some controllers show their
+	   unused channels this way */
+	if (ata_resources_present(pdev, 0) == 0)
+		ports &= ~ATA_PORT_PRIMARY;
+	if (ata_resources_present(pdev, 1) == 0)
+		ports &= ~ATA_PORT_SECONDARY;
+
 	/* iomap BARs */
-	for (i = 0; i < 4; i++) {
-		if (pcim_iomap(pdev, i, 0) == NULL) {
-			dev_printk(KERN_ERR, &pdev->dev,
-				   "failed to iomap PCI BAR %d\n", i);
-			return NULL;
+	if (ports & ATA_PORT_PRIMARY) {
+		for (i = 0; i <= 1; i++) {
+			if (pcim_iomap(pdev, i, 0) == NULL) {
+				dev_printk(KERN_ERR, &pdev->dev,
+					   "failed to iomap PCI BAR %d\n", i);
+				return NULL;
+			}
+		}
+	}
+	if (ports & ATA_PORT_SECONDARY) {
+		for (i = 2; i <= 3; i++) {
+			if (pcim_iomap(pdev, i, 0) == NULL) {
+				dev_printk(KERN_ERR, &pdev->dev,
+					   "failed to iomap PCI BAR %d\n", i);
+				return NULL;
+			}
 		}
 	}
 
@@ -577,13 +595,6 @@ ata_pci_init_native_mode(struct pci_dev 
 	probe_ent->irq = pdev->irq;
 	probe_ent->irq_flags = IRQF_SHARED;
 
-	/* Discard disabled ports. Some controllers show their
-	   unused channels this way */
-	if (ata_resources_present(pdev, 0) == 0)
-		ports &= ~ATA_PORT_PRIMARY;
-	if (ata_resources_present(pdev, 1) == 0)
-		ports &= ~ATA_PORT_SECONDARY;
-
 	if (ports & ATA_PORT_PRIMARY) {
 		probe_ent->port[p].cmd_addr = iomap[0];
 		probe_ent->port[p].altstatus_addr =

-- 

Re: [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Linus Torvalds]

On Mon, 21 May 2007, Chris Wright wrote:
> ---
> [chrisw: Why is this not upstream yet?]

And equally importantly, why is it even in the stable queue if it's not 
upstream.

It's against stable rules, and it means that we may have stuff that gets 
fixed in -stable and not in -upstream, if people don't notice. THAT IS 
BAD!

Having fixes in stable that don't exist in upstream make -stable be 
worse than pointless - it means that we actively _lose_ bug-reports. It 
may sound like a good idea in the short run, but it's a *horrible* thing 
for the long run.

IOW, this should not be on the table for -stable, and people involved 
should have made sure it's in -upstream first!

And no, I do not think it's languishing in my mailqueue. I'm pretty sure 
it's languishing somewhere else. 

		Linus

Re: [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Mon, 21 May 2007, Chris Wright wrote:
>> ---
>> [chrisw: Why is this not upstream yet?]
> 
> And equally importantly, why is it even in the stable queue if it's not 
> upstream.
> 
> It's against stable rules, and it means that we may have stuff that gets 
> fixed in -stable and not in -upstream, if people don't notice. THAT IS 
> BAD!
> 
> Having fixes in stable that don't exist in upstream make -stable be 
> worse than pointless - it means that we actively _lose_ bug-reports. It 
> may sound like a good idea in the short run, but it's a *horrible* thing 
> for the long run.
> 
> IOW, this should not be on the table for -stable, and people involved 
> should have made sure it's in -upstream first!

Strongly agreed.


> And no, I do not think it's languishing in my mailqueue. I'm pretty sure 
> it's languishing somewhere else. 

AFAIK it was obsoleted by another Tejun patch which -is- upstream.

Am I missing something?

	Jeff

Re: [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Linus Torvalds]

On Mon, 21 May 2007, Jeff Garzik wrote:
> > And no, I do not think it's languishing in my mailqueue. I'm pretty sure
> > it's languishing somewhere else. 
> 
> AFAIK it was obsoleted by another Tejun patch which -is- upstream.
> 
> Am I missing something?

Ahh, in that case it should hopefully be noted as such. I just got worried 
when I saw Chris' note.

		Linus

Re: [stable] [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Chris Wright]

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Mon, 21 May 2007, Chris Wright wrote:
> > ---
> > [chrisw: Why is this not upstream yet?]
> 
> And equally importantly, why is it even in the stable queue if it's not 
> upstream.
> 
> It's against stable rules, and it means that we may have stuff that gets 
> fixed in -stable and not in -upstream, if people don't notice. THAT IS 
> BAD!

It's there specifically to fish out why it was sent to -stable w/out
ever making it upstream.  Having sent the same question w/ no response
5 days ago

Re: [stable] [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Alan Cox]

> It's there specifically to fish out why it was sent to -stable w/out
> ever making it upstream.  Having sent the same question w/ no response
> 5 days ago

Yeah - fix your mailer, you got a reply 5 days ago.

Alan

Re: [stable] [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> Yeah - fix your mailer, you got a reply 5 days ago.

Sure wouldn't be the first time something broke.  I'll take a look.

thanks,
-chris

Re: [stable] [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Chris Wright]

* Chris Wright (chrisw@sous-sol.org) wrote:
> * Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> > Yeah - fix your mailer, you got a reply 5 days ago.
> 
> Sure wouldn't be the first time something broke.  I'll take a look.

Thanks for the prod.  I found 2 quite stale RBL entries, causing
long connection delay (enough from some MTAs to walk away perhaps).

thanks,
-chris

Re: [patch 07/69] libata-sff: Undo bug introduced with pci_iomap changes

[Alan Cox]

On Mon, 21 May 2007 16:18:25 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Mon, 21 May 2007, Chris Wright wrote:
> > ---
> > [chrisw: Why is this not upstream yet?]
> 
> And equally importantly, why is it even in the stable queue if it's not 
> upstream.

Its not relevant to upstream - upstream has different updates which
removed the bug but not in a clean "backport this" way.

> It's against stable rules, and it means that we may have stuff that gets 
> fixed in -stable and not in -upstream, if people don't notice. THAT IS 
> BAD

Then the rules are stupid in this specific case.

Alan

[patch 08/69] iop: fix iop_getttimeoffset

[Chris Wright]

[-- Attachment #1: iop-fix-iop_getttimeoffset.patch --]
[-- Type: text/plain, Size: 1386 bytes --]

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

From: Dan Williams <dan.j.williams@intel.com>

Fix a typo which causes a necessary cpwait to be missed on iop3xx, Michael
Brunner <mibru@gmx.de>

Save a register in the assembly routine, rmk

Cc: Lennert Buytenhek <kernel@wantstofly.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 arch/arm/plat-iop/time.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/arch/arm/plat-iop/time.c
+++ linux-2.6.21.1/arch/arm/plat-iop/time.c
@@ -32,22 +32,22 @@ static unsigned long next_jiffy_time;
 
 unsigned long iop_gettimeoffset(void)
 {
-	unsigned long offset, temp1, temp2;
+	unsigned long offset, temp;
 
 	/* enable cp6, if necessary, to avoid taking the overhead of an
 	 * undefined instruction trap
 	 */
 	asm volatile (
 	"mrc	p15, 0, %0, c15, c1, 0\n\t"
-	"ands	%1, %0, #(1 << 6)\n\t"
+	"tst	%0, #(1 << 6)\n\t"
 	"orreq	%0, %0, #(1 << 6)\n\t"
 	"mcreq	p15, 0, %0, c15, c1, 0\n\t"
-#ifdef CONFIG_XSCALE
+#ifdef CONFIG_CPU_XSCALE
 	"mrceq	p15, 0, %0, c15, c1, 0\n\t"
 	"moveq	%0, %0\n\t"
 	"subeq	pc, pc, #4\n\t"
 #endif
-	: "=r"(temp1), "=r"(temp2) : : "cc");
+	: "=r"(temp) : : "cc");
 
 	offset = next_jiffy_time - read_tcr1();
 

-- 

[patch 09/69] iop13xx: fix i/o address translation

[Chris Wright]

[-- Attachment #1: iop13xx-fix-i-o-address-translation.patch --]
[-- Type: text/plain, Size: 4886 bytes --]

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

From: Dan Williams <dan.j.williams@intel.com>

PCI devices were being programmed with an incorrect base address value.
This patch moves I/O space into a 16-bit addressable region and corrects
the i/o offset.

Much thanks to Martin Michlmayr for tracking this issue and testing
debug patches.

Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 arch/arm/mach-iop13xx/pci.c            |    8 ++++----
 include/asm-arm/arch-iop13xx/iop13xx.h |   22 +++++++++++++---------
 2 files changed, 17 insertions(+), 13 deletions(-)

--- linux-2.6.21.1.orig/arch/arm/mach-iop13xx/pci.c
+++ linux-2.6.21.1/arch/arm/mach-iop13xx/pci.c
@@ -1023,7 +1023,7 @@ int iop13xx_pci_setup(int nr, struct pci
 				  << IOP13XX_ATUX_PCIXSR_FUNC_NUM;
 		__raw_writel(pcixsr, IOP13XX_ATUX_PCIXSR);
 
-		res[0].start = IOP13XX_PCIX_LOWER_IO_PA;
+		res[0].start = IOP13XX_PCIX_LOWER_IO_PA + IOP13XX_PCIX_IO_BUS_OFFSET;
 		res[0].end   = IOP13XX_PCIX_UPPER_IO_PA;
 		res[0].name  = "IQ81340 ATUX PCI I/O Space";
 		res[0].flags = IORESOURCE_IO;
@@ -1033,7 +1033,7 @@ int iop13xx_pci_setup(int nr, struct pci
 		res[1].name  = "IQ81340 ATUX PCI Memory Space";
 		res[1].flags = IORESOURCE_MEM;
 		sys->mem_offset = IOP13XX_PCIX_MEM_OFFSET;
-		sys->io_offset = IOP13XX_PCIX_IO_OFFSET;
+		sys->io_offset = IOP13XX_PCIX_LOWER_IO_PA;
 		break;
 	case IOP13XX_INIT_ATU_ATUE:
 		/* Note: the function number field in the PCSR is ro */
@@ -1044,7 +1044,7 @@ int iop13xx_pci_setup(int nr, struct pci
 
 		__raw_writel(pcsr, IOP13XX_ATUE_PCSR);
 
-		res[0].start = IOP13XX_PCIE_LOWER_IO_PA;
+		res[0].start = IOP13XX_PCIE_LOWER_IO_PA + IOP13XX_PCIE_IO_BUS_OFFSET;
 		res[0].end   = IOP13XX_PCIE_UPPER_IO_PA;
 		res[0].name  = "IQ81340 ATUE PCI I/O Space";
 		res[0].flags = IORESOURCE_IO;
@@ -1054,7 +1054,7 @@ int iop13xx_pci_setup(int nr, struct pci
 		res[1].name  = "IQ81340 ATUE PCI Memory Space";
 		res[1].flags = IORESOURCE_MEM;
 		sys->mem_offset = IOP13XX_PCIE_MEM_OFFSET;
-		sys->io_offset = IOP13XX_PCIE_IO_OFFSET;
+		sys->io_offset = IOP13XX_PCIE_LOWER_IO_PA;
 		sys->map_irq = iop13xx_pcie_map_irq;
 		break;
 	default:
--- linux-2.6.21.1.orig/include/asm-arm/arch-iop13xx/iop13xx.h
+++ linux-2.6.21.1/include/asm-arm/arch-iop13xx/iop13xx.h
@@ -27,19 +27,24 @@ static inline int iop13xx_cpu_id(void)
 #define IOP13XX_PCI_OFFSET	 IOP13XX_MAX_RAM_SIZE
 
 /* PCI MAP
- * 0x0000.0000 - 0x8000.0000           1:1 mapping with Physical RAM
- * 0x8000.0000 - 0x8800.0000           PCIX/PCIE memory window (128MB)
-*/
+ * bus range		cpu phys	cpu virt	note
+ * 0x0000.0000 + 2GB	(n/a)		(n/a)		inbound, 1:1 mapping with Physical RAM
+ * 0x8000.0000 + 928M	0x1.8000.0000   (ioremap)	PCIX outbound memory window
+ * 0x8000.0000 + 928M	0x2.8000.0000   (ioremap)	PCIE outbound memory window
+ * 
+ * IO MAP
+ * 0x1000 + 64K	0x0.fffb.1000	0xfec6.1000	PCIX outbound i/o window
+ * 0x1000 + 64K	0x0.fffd.1000	0xfed7.1000	PCIE outbound i/o window
+ */
 #define IOP13XX_PCIX_IO_WINDOW_SIZE   0x10000UL
 #define IOP13XX_PCIX_LOWER_IO_PA      0xfffb0000UL
 #define IOP13XX_PCIX_LOWER_IO_VA      0xfec60000UL
-#define IOP13XX_PCIX_LOWER_IO_BA      0x0fff0000UL
+#define IOP13XX_PCIX_LOWER_IO_BA      0x0UL /* OIOTVR */
+#define IOP13XX_PCIX_IO_BUS_OFFSET    0x1000UL
 #define IOP13XX_PCIX_UPPER_IO_PA      (IOP13XX_PCIX_LOWER_IO_PA +\
 				       IOP13XX_PCIX_IO_WINDOW_SIZE - 1)
 #define IOP13XX_PCIX_UPPER_IO_VA      (IOP13XX_PCIX_LOWER_IO_VA +\
 				       IOP13XX_PCIX_IO_WINDOW_SIZE - 1)
-#define IOP13XX_PCIX_IO_OFFSET        (IOP13XX_PCIX_LOWER_IO_VA -\
-				       IOP13XX_PCIX_LOWER_IO_BA)
 #define IOP13XX_PCIX_IO_PHYS_TO_VIRT(addr) (u32) ((u32) addr -\
 					   (IOP13XX_PCIX_LOWER_IO_PA\
 					   - IOP13XX_PCIX_LOWER_IO_VA))
@@ -65,15 +70,14 @@ static inline int iop13xx_cpu_id(void)
 #define IOP13XX_PCIE_IO_WINDOW_SIZE   	 0x10000UL
 #define IOP13XX_PCIE_LOWER_IO_PA      	 0xfffd0000UL
 #define IOP13XX_PCIE_LOWER_IO_VA      	 0xfed70000UL
-#define IOP13XX_PCIE_LOWER_IO_BA      	 0x0fff0000UL
+#define IOP13XX_PCIE_LOWER_IO_BA      	 0x0UL  /* OIOTVR */
+#define IOP13XX_PCIE_IO_BUS_OFFSET	 0x1000UL
 #define IOP13XX_PCIE_UPPER_IO_PA      	 (IOP13XX_PCIE_LOWER_IO_PA +\
 					 IOP13XX_PCIE_IO_WINDOW_SIZE - 1)
 #define IOP13XX_PCIE_UPPER_IO_VA      	 (IOP13XX_PCIE_LOWER_IO_VA +\
 					 IOP13XX_PCIE_IO_WINDOW_SIZE - 1)
 #define IOP13XX_PCIE_UPPER_IO_BA      	 (IOP13XX_PCIE_LOWER_IO_BA +\
 					 IOP13XX_PCIE_IO_WINDOW_SIZE - 1)
-#define IOP13XX_PCIE_IO_OFFSET        	 (IOP13XX_PCIE_LOWER_IO_VA -\
-					 IOP13XX_PCIE_LOWER_IO_BA)
 #define IOP13XX_PCIE_IO_PHYS_TO_VIRT(addr) (u32) ((u32) addr -\
 					   (IOP13XX_PCIE_LOWER_IO_PA\
 					   - IOP13XX_PCIE_LOWER_IO_VA))

-- 

[patch 10/69] kbuild: fixdep segfault on pathological string-o-death

[Chris Wright]

[-- Attachment #1: kbuild-fixdep-segfault-on-pathological-string-o-death.patch --]
[-- Type: text/plain, Size: 1089 bytes --]

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

From: Andy Green <andy@warmcat.com>

build scripts: fixdep blows segfault on string CONFIG_MODULE seen

The string "CONFIG_MODULE" appearing anywhere in a source file causes
fixdep to segfault.  This string appeared in the wild in the current
mISDN sources (I think they meant CONFIG_MODULES).  But it shouldn't
segfault (esp as CONFIG_MODULE appeared in a quoted string).

Signed-off-by: Andy Green <andy@warmcat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

This is not an important fix per see - but I do not like SEGV during compilation...
Will be pushed to Linus today.

	Sam

 scripts/basic/fixdep.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.21.1.orig/scripts/basic/fixdep.c
+++ linux-2.6.21.1/scripts/basic/fixdep.c
@@ -249,6 +249,8 @@ void parse_config_file(char *map, size_t
 	found:
 		if (!memcmp(q - 7, "_MODULE", 7))
 			q -= 7;
+		if( (q-p-7) < 0 )
+			continue;
 		use_config(p+7, q-p-7);
 	}
 }

-- 

[patch 11/69] NETFILTER: {ip,nf}_nat_proto_gre: do not modify/corrupt GREv0 packets through NAT

[Chris Wright]

[-- Attachment #1: ip-nf-_nat_proto_gre-do-not-modify-corrupt-grev0-packets-through-nat.patch --]
[-- Type: text/plain, Size: 5311 bytes --]

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

From: Jorge Boncompte <jorge@dti2.net>

While porting some changes of the 2.6.21-rc7 pptp/proto_gre conntrack
and nat modules to a 2.4.32 kernel I noticed that the gre_key function
returns a wrong pointer to the GRE key of a version 0 packet thus
corrupting the packet payload.
    
The intended behaviour for GREv0 packets is to act like
nf_conntrack_proto_generic/nf_nat_proto_unknown so I have ripped the
offending functions (not used anymore) and modified the
nf_nat_proto_gre modules to not touch version 0 (non PPTP) packets.
    
Signed-off-by: Jorge Boncompte <jorge@dti2.net>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
commit 244c67aee5750eb3a79c727d09c01a500e68bbbe
tree 29bbce944bba681886a6d58c0c6b7bca3858c0e1
parent 8d8b10482fffcb72b15515231bb942e2ad6395c9
author Jorge Boncompte <jorge@dti2.net> Thu, 03 May 2007 02:50:51 +0200
committer Patrick McHardy <kaber@trash.net> Thu, 03 May 2007 02:50:51 +0200

 include/linux/netfilter/nf_conntrack_proto_gre.h      |   18 ----------------
 include/linux/netfilter_ipv4/ip_conntrack_proto_gre.h |   19 -----------------
 net/ipv4/netfilter/ip_nat_proto_gre.c                 |   20 +++++++-----------
 net/ipv4/netfilter/nf_nat_proto_gre.c                 |   20 +++++++-----------
 4 files changed, 16 insertions(+), 61 deletions(-)

--- linux-2.6.21.1.orig/include/linux/netfilter/nf_conntrack_proto_gre.h
+++ linux-2.6.21.1/include/linux/netfilter/nf_conntrack_proto_gre.h
@@ -87,24 +87,6 @@ int nf_ct_gre_keymap_add(struct nf_conn 
 /* delete keymap entries */
 void nf_ct_gre_keymap_destroy(struct nf_conn *ct);
 
-/* get pointer to gre key, if present */
-static inline __be32 *gre_key(struct gre_hdr *greh)
-{
-	if (!greh->key)
-		return NULL;
-	if (greh->csum || greh->routing)
-		return (__be32 *)(greh+sizeof(*greh)+4);
-	return (__be32 *)(greh+sizeof(*greh));
-}
-
-/* get pointer ot gre csum, if present */
-static inline __sum16 *gre_csum(struct gre_hdr *greh)
-{
-	if (!greh->csum)
-		return NULL;
-	return (__sum16 *)(greh+sizeof(*greh));
-}
-
 extern void nf_ct_gre_keymap_flush(void);
 extern void nf_nat_need_gre(void);
 
--- linux-2.6.21.1.orig/include/linux/netfilter_ipv4/ip_conntrack_proto_gre.h
+++ linux-2.6.21.1/include/linux/netfilter_ipv4/ip_conntrack_proto_gre.h
@@ -90,25 +90,6 @@ int ip_ct_gre_keymap_add(struct ip_connt
 /* delete keymap entries */
 void ip_ct_gre_keymap_destroy(struct ip_conntrack *ct);
 
-
-/* get pointer to gre key, if present */
-static inline __be32 *gre_key(struct gre_hdr *greh)
-{
-	if (!greh->key)
-		return NULL;
-	if (greh->csum || greh->routing)
-		return (__be32 *) (greh+sizeof(*greh)+4);
-	return (__be32 *) (greh+sizeof(*greh));
-}
-
-/* get pointer ot gre csum, if present */
-static inline __sum16 *gre_csum(struct gre_hdr *greh)
-{
-	if (!greh->csum)
-		return NULL;
-	return (__sum16 *) (greh+sizeof(*greh));
-}
-
 #endif /* __KERNEL__ */
 
 #endif /* _CONNTRACK_PROTO_GRE_H */
--- linux-2.6.21.1.orig/net/ipv4/netfilter/ip_nat_proto_gre.c
+++ linux-2.6.21.1/net/ipv4/netfilter/ip_nat_proto_gre.c
@@ -70,6 +70,11 @@ gre_unique_tuple(struct ip_conntrack_tup
 	__be16 *keyptr;
 	unsigned int min, i, range_size;
 
+	/* If there is no master conntrack we are not PPTP,
+	   do not change tuples */
+	if (!conntrack->master)
+		return 0;
+		
 	if (maniptype == IP_NAT_MANIP_SRC)
 		keyptr = &tuple->src.u.gre.key;
 	else
@@ -122,18 +127,9 @@ gre_manip_pkt(struct sk_buff **pskb,
 	if (maniptype == IP_NAT_MANIP_DST) {
 		/* key manipulation is always dest */
 		switch (greh->version) {
-		case 0:
-			if (!greh->key) {
-				DEBUGP("can't nat GRE w/o key\n");
-				break;
-			}
-			if (greh->csum) {
-				/* FIXME: Never tested this code... */
-				nf_proto_csum_replace4(gre_csum(greh), *pskb,
-							*(gre_key(greh)),
-							tuple->dst.u.gre.key, 0);
-			}
-			*(gre_key(greh)) = tuple->dst.u.gre.key;
+		case GRE_VERSION_1701:
+			/* We do not currently NAT any GREv0 packets.
+			 * Try to behave like "ip_nat_proto_unknown" */
 			break;
 		case GRE_VERSION_PPTP:
 			DEBUGP("call_id -> 0x%04x\n",
--- linux-2.6.21.1.orig/net/ipv4/netfilter/nf_nat_proto_gre.c
+++ linux-2.6.21.1/net/ipv4/netfilter/nf_nat_proto_gre.c
@@ -72,6 +72,11 @@ gre_unique_tuple(struct nf_conntrack_tup
 	__be16 *keyptr;
 	unsigned int min, i, range_size;
 
+	/* If there is no master conntrack we are not PPTP,
+	   do not change tuples */
+	if (!conntrack->master)
+		return 0;
+		
 	if (maniptype == IP_NAT_MANIP_SRC)
 		keyptr = &tuple->src.u.gre.key;
 	else
@@ -122,18 +127,9 @@ gre_manip_pkt(struct sk_buff **pskb, uns
 	if (maniptype != IP_NAT_MANIP_DST)
 		return 1;
 	switch (greh->version) {
-	case 0:
-		if (!greh->key) {
-			DEBUGP("can't nat GRE w/o key\n");
-			break;
-		}
-		if (greh->csum) {
-			/* FIXME: Never tested this code... */
-			nf_proto_csum_replace4(gre_csum(greh), *pskb,
-					       *(gre_key(greh)),
-					       tuple->dst.u.gre.key, 0);
-		}
-		*(gre_key(greh)) = tuple->dst.u.gre.key;
+	case GRE_VERSION_1701:
+		/* We do not currently NAT any GREv0 packets.
+		 * Try to behave like "nf_nat_proto_unknown" */
 		break;
 	case GRE_VERSION_PPTP:
 		DEBUGP("call_id -> 0x%04x\n", ntohs(tuple->dst.u.gre.key));

-- 

[patch 12/69] sata_via: add missing PM hooks

[Chris Wright]

[-- Attachment #1: sata_via-add-missing-pm-hooks.patch --]
[-- Type: text/plain, Size: 1195 bytes --]

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

From: Tejun Heo <htejun@gmail.com>

For some reason, sata_via is missing PM hooks.  Add them.  Spotted by
Jeroen Janssen <jeroen.janssen@gmail.com>.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Jeroen Janssen <jeroen.janssen@gmail.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 drivers/ata/sata_via.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- linux-2.6.21.1.orig/drivers/ata/sata_via.c
+++ linux-2.6.21.1/drivers/ata/sata_via.c
@@ -97,6 +97,10 @@ static struct pci_driver svia_pci_driver
 	.name			= DRV_NAME,
 	.id_table		= svia_pci_tbl,
 	.probe			= svia_init_one,
+#ifdef CONFIG_PM
+	.suspend		= ata_pci_device_suspend,
+	.resume			= ata_pci_device_resume,
+#endif
 	.remove			= ata_pci_remove_one,
 };
 
@@ -116,6 +120,10 @@ static struct scsi_host_template svia_sh
 	.slave_configure	= ata_scsi_slave_config,
 	.slave_destroy		= ata_scsi_slave_destroy,
 	.bios_param		= ata_std_bios_param,
+#ifdef CONFIG_PM
+	.suspend		= ata_scsi_device_suspend,
+	.resume			= ata_scsi_device_resume,
+#endif
 };
 
 static const struct ata_port_operations vt6420_sata_ops = {

-- 

[patch 13/69] arm: fix handling of svc mode undefined instructions

[Chris Wright]

[-- Attachment #1: arm-fix-handling-of-svc-mode-undefined-instructions.patch --]
[-- Type: text/plain, Size: 1402 bytes --]

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

From: Dan Williams <dan.j.williams@intel.com>

Now that do_undefinstr handles kernel and user mode undefined
instruction exceptions it must not assume that interrupts are enabled at
entry.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 arch/arm/kernel/traps.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2.6.21.1.orig/arch/arm/kernel/traps.c
+++ linux-2.6.21.1/arch/arm/kernel/traps.c
@@ -273,6 +273,7 @@ asmlinkage void do_undefinstr(struct pt_
 	struct undef_hook *hook;
 	siginfo_t info;
 	void __user *pc;
+	unsigned long flags;
 
 	/*
 	 * According to the ARM ARM, PC is 2 or 4 bytes ahead,
@@ -291,7 +292,7 @@ asmlinkage void do_undefinstr(struct pt_
 		get_user(instr, (u32 __user *)pc);
 	}
 
-	spin_lock_irq(&undef_lock);
+	spin_lock_irqsave(&undef_lock, flags);
 	list_for_each_entry(hook, &undef_hook, node) {
 		if ((instr & hook->instr_mask) == hook->instr_val &&
 		    (regs->ARM_cpsr & hook->cpsr_mask) == hook->cpsr_val) {
@@ -301,7 +302,7 @@ asmlinkage void do_undefinstr(struct pt_
 			}
 		}
 	}
-	spin_unlock_irq(&undef_lock);
+	spin_unlock_irqrestore(&undef_lock, flags);
 
 #ifdef CONFIG_DEBUG_USER
 	if (user_debug & UDBG_UNDEFINED) {

-- 

[patch 14/69] oom: fix constraint deadlock

[Chris Wright]

[-- Attachment #1: oom-fix-constraint-deadlock.patch --]
[-- Type: text/plain, Size: 2130 bytes --]

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

From: David Rientjes <rientjes@google.com>

Fixes a deadlock in the OOM killer for allocations that are not
__GFP_HARDWALL.

Before the OOM killer checks for the allocation constraint, it takes
callback_mutex.

constrained_alloc() iterates through each zone in the allocation zonelist
and calls cpuset_zone_allowed_softwall() to determine whether an allocation
for gfp_mask is possible.  If a zone's node is not in the OOM-triggering
task's mems_allowed, it is not exiting, and we did not fail on a
__GFP_HARDWALL allocation, cpuset_zone_allowed_softwall() attempts to take
callback_mutex to check the nearest exclusive ancestor of current's cpuset.
 This results in deadlock.

We now take callback_mutex after iterating through the zonelist since we
don't need it yet.

Cc: Andi Kleen <ak@suse.de>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: Martin J. Bligh <mbligh@mbligh.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 mm/oom_kill.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/mm/oom_kill.c
+++ linux-2.6.21.1/mm/oom_kill.c
@@ -397,6 +397,7 @@ void out_of_memory(struct zonelist *zone
 	struct task_struct *p;
 	unsigned long points = 0;
 	unsigned long freed = 0;
+	int constraint;
 
 	blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
 	if (freed > 0)
@@ -411,14 +412,15 @@ void out_of_memory(struct zonelist *zone
 		show_mem();
 	}
 
-	cpuset_lock();
-	read_lock(&tasklist_lock);
-
 	/*
 	 * Check if there were limitations on the allocation (only relevant for
 	 * NUMA) that may require different handling.
 	 */
-	switch (constrained_alloc(zonelist, gfp_mask)) {
+	constraint = constrained_alloc(zonelist, gfp_mask);
+	cpuset_lock();
+	read_lock(&tasklist_lock);
+
+	switch (constraint) {
 	case CONSTRAINT_MEMORY_POLICY:
 		oom_kill_process(current, points,
 				"No available memory (MPOL_BIND)");

-- 

[patch 15/69] slob: fix page order calculation on not 4KB page

[Chris Wright]

[-- Attachment #1: slob-fix-page-order-calculation-on-not-4kb-page.patch --]
[-- Type: text/plain, Size: 1830 bytes --]

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

From: Akinobu Mita <akinobu.mita@gmail.com>

SLOB doesn't calculate correct page order when page size is not 4KB.  This
patch fixes it with using get_order() instead of find_order() which is SLOB
version of get_order().

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 mm/slob.c |   15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

--- linux-2.6.21.1.orig/mm/slob.c
+++ linux-2.6.21.1/mm/slob.c
@@ -150,15 +150,6 @@ static void slob_free(void *block, int s
 	spin_unlock_irqrestore(&slob_lock, flags);
 }
 
-static int FASTCALL(find_order(int size));
-static int fastcall find_order(int size)
-{
-	int order = 0;
-	for ( ; size > 4096 ; size >>=1)
-		order++;
-	return order;
-}
-
 void *__kmalloc(size_t size, gfp_t gfp)
 {
 	slob_t *m;
@@ -174,7 +165,7 @@ void *__kmalloc(size_t size, gfp_t gfp)
 	if (!bb)
 		return 0;
 
-	bb->order = find_order(size);
+	bb->order = get_order(size);
 	bb->pages = (void *)__get_free_pages(gfp, bb->order);
 
 	if (bb->pages) {
@@ -284,7 +275,7 @@ void *kmem_cache_alloc(struct kmem_cache
 	if (c->size < PAGE_SIZE)
 		b = slob_alloc(c->size, flags, c->align);
 	else
-		b = (void *)__get_free_pages(flags, find_order(c->size));
+		b = (void *)__get_free_pages(flags, get_order(c->size));
 
 	if (c->ctor)
 		c->ctor(b, c, SLAB_CTOR_CONSTRUCTOR);
@@ -311,7 +302,7 @@ void kmem_cache_free(struct kmem_cache *
 	if (c->size < PAGE_SIZE)
 		slob_free(b, c->size);
 	else
-		free_pages((unsigned long)b, find_order(c->size));
+		free_pages((unsigned long)b, get_order(c->size));
 }
 EXPORT_SYMBOL(kmem_cache_free);
 

-- 

[patch 16/69] ppp: Fix ppp_deflate issues with recent zlib_inflate changes

[Chris Wright]

[-- Attachment #1: ppp-fix-ppp_deflate-issues-with-recent-zlib_inflate-changes.patch --]
[-- Type: text/plain, Size: 1432 bytes --]

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

From: Richard Purdie <rpurdie@rpsys.net>

The last zlib_inflate update broke certain corner cases for ppp_deflate
decompression handling.  This patch fixes some logic to make things work
properly again.  Users other than ppp_deflate (the only Z_PACKET_FLUSH
user) should be unaffected.

Fixes bug 8405 (confirmed by Stefan)

Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Cc: Stefan Wenk <stefan.wenk@gmx.at>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 lib/zlib_inflate/inflate.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/lib/zlib_inflate/inflate.c
+++ linux-2.6.21.1/lib/zlib_inflate/inflate.c
@@ -743,12 +743,14 @@ int zlib_inflate(z_streamp strm, int flu
 
     strm->data_type = state->bits + (state->last ? 64 : 0) +
                       (state->mode == TYPE ? 128 : 0);
-    if (((in == 0 && out == 0) || flush == Z_FINISH) && ret == Z_OK)
-        ret = Z_BUF_ERROR;
 
     if (flush == Z_PACKET_FLUSH && ret == Z_OK &&
-            (strm->avail_out != 0 || strm->avail_in == 0))
+            strm->avail_out != 0 && strm->avail_in == 0)
 		return zlib_inflateSyncPacket(strm);
+
+    if (((in == 0 && out == 0) || flush == Z_FINISH) && ret == Z_OK)
+        ret = Z_BUF_ERROR;
+
     return ret;
 }
 

-- 

[patch 17/69] knfsd: Avoid use of unitialised variables on error path when nfs exports.

[Chris Wright]

[-- Attachment #1: knfsd-avoid-use-of-unitialised-variables-on-error-path-when-nfs-exports.patch --]
[-- Type: text/plain, Size: 1206 bytes --]

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

From: NeilBrown <neilb@suse.de>

We need to zero various parts of 'exp' before any 'goto out', otherwise
when we go to free the contents... we die.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 fs/nfsd/export.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff .prev/fs/nfsd/export.c ./fs/nfsd/export.c
--- linux-2.6.21.1.orig/fs/nfsd/export.c
+++ linux-2.6.21.1/fs/nfsd/export.c
@@ -469,6 +469,13 @@ static int svc_export_parse(struct cache
 	nd.dentry = NULL;
 	exp.ex_path = NULL;
 
+	/* fs locations */
+	exp.ex_fslocs.locations = NULL;
+	exp.ex_fslocs.locations_count = 0;
+	exp.ex_fslocs.migrated = 0;
+
+	exp.ex_uuid = NULL;
+
 	if (mesg[mlen-1] != '\n')
 		return -EINVAL;
 	mesg[mlen-1] = 0;
@@ -509,13 +516,6 @@ static int svc_export_parse(struct cache
 	if (exp.h.expiry_time == 0)
 		goto out;
 
-	/* fs locations */
-	exp.ex_fslocs.locations = NULL;
-	exp.ex_fslocs.locations_count = 0;
-	exp.ex_fslocs.migrated = 0;
-
-	exp.ex_uuid = NULL;
-
 	/* flags */
 	err = get_int(&mesg, &an_int);
 	if (err == -ENOENT)

-- 

[patch 18/69] knfsd: rpc: fix server-side wrapping of krb5i replies

[Chris Wright]

[-- Attachment #1: knfsd-rpc-fix-server-side-wrapping-of-krb5i-replies.patch --]
[-- Type: text/plain, Size: 1355 bytes --]

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

From: NeilBrown <neilb@suse.de>

It's not necessarily correct to assume that the xdr_buf used to hold the
server's reply must have page data whenever it has tail data.

And there's no need for us to deal with that case separately anyway.

Acked-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 net/sunrpc/auth_gss/svcauth_gss.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff .prev/net/sunrpc/auth_gss/svcauth_gss.c ./net/sunrpc/auth_gss/svcauth_gss.c
--- linux-2.6.21.1.orig/net/sunrpc/auth_gss/svcauth_gss.c
+++ linux-2.6.21.1/net/sunrpc/auth_gss/svcauth_gss.c
@@ -1196,13 +1196,7 @@ svcauth_gss_wrap_resp_integ(struct svc_r
 	if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset,
 				integ_len))
 		BUG();
-	if (resbuf->page_len == 0
-			&& resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE
-			< PAGE_SIZE) {
-		BUG_ON(resbuf->tail[0].iov_len);
-		/* Use head for everything */
-		resv = &resbuf->head[0];
-	} else if (resbuf->tail[0].iov_base == NULL) {
+	if (resbuf->tail[0].iov_base == NULL) {
 		if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
 			goto out_err;
 		resbuf->tail[0].iov_base = resbuf->head[0].iov_base

-- 

[patch 19/69] skge: default WOL should be magic only (rev2)

[Chris Wright]

[-- Attachment #1: skge-default-wol-should-be-magic-only.patch --]
[-- Type: text/plain, Size: 946 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

By default, the skge driver now enables wake on magic and wake on PHY.
This is a bad default (bug), wake on PHY means machine will never shutdown 
if connected to a switch.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/skge.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.21.1.orig/drivers/net/skge.c
+++ linux-2.6.21.1/drivers/net/skge.c
@@ -3583,7 +3583,9 @@ static struct net_device *skge_devinit(s
 	skge->duplex = -1;
 	skge->speed = -1;
 	skge->advertising = skge_supported_modes(hw);
-	skge->wol = pci_wake_enabled(hw->pdev) ? wol_supported(hw) : 0;
+
+	if (pci_wake_enabled(hw->pdev))
+		skge->wol = wol_supported(hw) & WAKE_MAGIC;
 
 	hw->dev[port] = dev;
 

-- 

[patch 20/69] skge: allow WOL except for known broken chips

[Chris Wright]

[-- Attachment #1: skge-allow-wol-except-for-known-broken-chips.patch --]
[-- Type: text/plain, Size: 1007 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

Wake On Lan works correctly on Yukon-FE and other variants.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/skge.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/skge.c
+++ linux-2.6.21.1/drivers/net/skge.c
@@ -135,10 +135,13 @@ static void skge_get_regs(struct net_dev
 /* Wake on Lan only supported on Yukon chips with rev 1 or above */
 static u32 wol_supported(const struct skge_hw *hw)
 {
-	if (hw->chip_id == CHIP_ID_YUKON && hw->chip_rev != 0)
-		return WAKE_MAGIC | WAKE_PHY;
-	else
+	if (hw->chip_id == CHIP_ID_GENESIS)
 		return 0;
+
+	if (hw->chip_id == CHIP_ID_YUKON && hw->chip_rev == 0)
+		return 0;
+
+	return WAKE_MAGIC | WAKE_PHY;
 }
 
 static u32 pci_wake_enabled(struct pci_dev *dev)

-- 

[patch 21/69] TG3: Fix TSO bugs.

[Chris Wright]

[-- Attachment #1: tg3-fix-tso-bugs.patch --]
[-- Type: text/plain, Size: 2131 bytes --]

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

From:  <mchan@broadcom.com>

1. Remove the check for skb->len greater than MTU when doing TSO.
When the destination has a smaller MSS than the source, a TSO packet
may be smaller than the MTU and we still need to process it as a TSO
packet.

2. On 5705A3 devices with TSO enabled, the DMA engine can hang due to a
hardware bug.  This patch avoids the hanging condition by reducing the
DMA burst size.

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

---
 drivers/net/tg3.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/tg3.c
+++ linux-2.6.21.1/drivers/net/tg3.c
@@ -3895,8 +3895,7 @@ static int tg3_start_xmit(struct sk_buff
 	entry = tp->tx_prod;
 	base_flags = 0;
 	mss = 0;
-	if (skb->len > (tp->dev->mtu + ETH_HLEN) &&
-	    (mss = skb_shinfo(skb)->gso_size) != 0) {
+	if ((mss = skb_shinfo(skb)->gso_size) != 0) {
 		int tcp_opt_len, ip_tcp_len;
 
 		if (skb_header_cloned(skb) &&
@@ -4053,8 +4052,7 @@ static int tg3_start_xmit_dma_bug(struct
 	if (skb->ip_summed == CHECKSUM_PARTIAL)
 		base_flags |= TXD_FLAG_TCPUDP_CSUM;
 	mss = 0;
-	if (skb->len > (tp->dev->mtu + ETH_HLEN) &&
-	    (mss = skb_shinfo(skb)->gso_size) != 0) {
+	if ((mss = skb_shinfo(skb)->gso_size) != 0) {
 		int tcp_opt_len, ip_tcp_len, hdr_len;
 
 		if (skb_header_cloned(skb) &&
@@ -6348,8 +6346,7 @@ static int tg3_reset_hw(struct tg3 *tp, 
 	     tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) ||
 	    (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750)) {
 		if (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE &&
-		    (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 ||
-		     tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) {
+		    GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) {
 			rdmac_mode |= RDMAC_MODE_FIFO_SIZE_128;
 		} else if (!(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH) &&
 			   !(tp->tg3_flags2 & TG3_FLG2_IS_5788)) {

-- 

[patch 22/69] TG3: Remove reset during MAC address changes.

[Chris Wright]

[-- Attachment #1: tg3-remove-reset-during-mac-address-changes.patch --]
[-- Type: text/plain, Size: 3097 bytes --]

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

From:  <mchan@broadcom.com>

The reset was added a while back so that ASF could re-init whatever
MAC address it wanted to use after the MAC address was changed.
Instead of resetting, we can just keep MAC address 1 unchanged during
MAC address changes if MAC address 1 is different from MAC address 0.

This fixes 2 problems:

1. Bonding calls set_mac_address in contexts that cannot sleep.
It no longer sleeps with the chip reset removed.

2. When ASF shares the same MAC address as the NIC, it needs to
always do that even when the MAC address is changed.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

---
 drivers/net/tg3.c |   35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/tg3.c
+++ linux-2.6.21.1/drivers/net/tg3.c
@@ -5934,7 +5934,7 @@ static int tg3_load_tso_firmware(struct 
 
 
 /* tp->lock is held. */
-static void __tg3_set_mac_addr(struct tg3 *tp)
+static void __tg3_set_mac_addr(struct tg3 *tp, int skip_mac_1)
 {
 	u32 addr_high, addr_low;
 	int i;
@@ -5946,6 +5946,8 @@ static void __tg3_set_mac_addr(struct tg
 		    (tp->dev->dev_addr[4] <<  8) |
 		    (tp->dev->dev_addr[5] <<  0));
 	for (i = 0; i < 4; i++) {
+		if (i == 1 && skip_mac_1)
+			continue;
 		tw32(MAC_ADDR_0_HIGH + (i * 8), addr_high);
 		tw32(MAC_ADDR_0_LOW + (i * 8), addr_low);
 	}
@@ -5972,7 +5974,7 @@ static int tg3_set_mac_addr(struct net_d
 {
 	struct tg3 *tp = netdev_priv(dev);
 	struct sockaddr *addr = p;
-	int err = 0;
+	int err = 0, skip_mac_1 = 0;
 
 	if (!is_valid_ether_addr(addr->sa_data))
 		return -EINVAL;
@@ -5983,22 +5985,21 @@ static int tg3_set_mac_addr(struct net_d
 		return 0;
 
 	if (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) {
-		/* Reset chip so that ASF can re-init any MAC addresses it
-		 * needs.
-		 */
-		tg3_netif_stop(tp);
-		tg3_full_lock(tp, 1);
+		u32 addr0_high, addr0_low, addr1_high, addr1_low;
 
-		tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
-		err = tg3_restart_hw(tp, 0);
-		if (!err)
-			tg3_netif_start(tp);
-		tg3_full_unlock(tp);
-	} else {
-		spin_lock_bh(&tp->lock);
-		__tg3_set_mac_addr(tp);
-		spin_unlock_bh(&tp->lock);
+		addr0_high = tr32(MAC_ADDR_0_HIGH);
+		addr0_low = tr32(MAC_ADDR_0_LOW);
+		addr1_high = tr32(MAC_ADDR_1_HIGH);
+		addr1_low = tr32(MAC_ADDR_1_LOW);
+
+		/* Skip MAC addr 1 if ASF is using it. */
+		if ((addr0_high != addr1_high || addr0_low != addr1_low) &&
+		    !(addr1_high == 0 && addr1_low == 0))
+			skip_mac_1 = 1;
 	}
+	spin_lock_bh(&tp->lock);
+	__tg3_set_mac_addr(tp, skip_mac_1);
+	spin_unlock_bh(&tp->lock);
 
 	return err;
 }
@@ -6315,7 +6316,7 @@ static int tg3_reset_hw(struct tg3 *tp, 
 		     tp->rx_jumbo_ptr);
 
 	/* Initialize MAC address and backoff seed. */
-	__tg3_set_mac_addr(tp);
+	__tg3_set_mac_addr(tp, 0);
 
 	/* MTU + ethernet header + FCS + optional VLAN tag */
 	tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8);

-- 

[patch 23/69] TG3: Update version and reldate.

[Chris Wright]

[-- Attachment #1: tg3-update-version-and-reldate.patch --]
[-- Type: text/plain, Size: 727 bytes --]

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

From:  <mchan@broadcom.com>

Update version to 3.75.1.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
 drivers/net/tg3.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/tg3.c
+++ linux-2.6.21.1/drivers/net/tg3.c
@@ -64,8 +64,8 @@
 
 #define DRV_MODULE_NAME		"tg3"
 #define PFX DRV_MODULE_NAME	": "
-#define DRV_MODULE_VERSION	"3.75"
-#define DRV_MODULE_RELDATE	"March 23, 2007"
+#define DRV_MODULE_VERSION	"3.75.1"
+#define DRV_MODULE_RELDATE	"May 7, 2007"
 
 #define TG3_DEF_MAC_MODE	0
 #define TG3_DEF_RX_MODE		0

-- 

[patch 24/69] BNX2: Fix TSO problem with small MSS.

[Chris Wright]

[-- Attachment #1: bnx2-fix-tso-problem-with-small-mss.patch --]
[-- Type: text/plain, Size: 1105 bytes --]

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

From:  <mchan@broadcom.com>

Remove the check for skb->len greater than MTU when doing TSO.  When
the destination has a smaller MSS than the source, a TSO packet may
be smaller than the MTU at the source and we still need to process it
as a TSO packet.

Thanks to Brian Ristuccia <bristuccia@starentnetworks.com> for
reporting the problem.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/bnx2.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/bnx2.c
+++ linux-2.6.21.1/drivers/net/bnx2.c
@@ -4510,8 +4510,7 @@ bnx2_start_xmit(struct sk_buff *skb, str
 		vlan_tag_flags |=
 			(TX_BD_FLAGS_VLAN_TAG | (vlan_tx_tag_get(skb) << 16));
 	}
-	if ((mss = skb_shinfo(skb)->gso_size) &&
-		(skb->len > (bp->dev->mtu + ETH_HLEN))) {
+	if ((mss = skb_shinfo(skb)->gso_size)) {
 		u32 tcp_opt_len, ip_tcp_len;
 
 		if (skb_header_cloned(skb) &&

-- 

[patch 25/69] BNX2: Block MII access when ifdown.

[Chris Wright]

[-- Attachment #1: bnx2-block-mii-access-when-ifdown.patch --]
[-- Type: text/plain, Size: 1098 bytes --]

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

From:  <mchan@broadcom.com>

The device may be in D3hot state and should not allow MII register
access.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

---
 drivers/net/bnx2.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- linux-2.6.21.1.orig/drivers/net/bnx2.c
+++ linux-2.6.21.1/drivers/net/bnx2.c
@@ -5564,6 +5564,9 @@ bnx2_ioctl(struct net_device *dev, struc
 	case SIOCGMIIREG: {
 		u32 mii_regval;
 
+		if (!netif_running(dev))
+			return -EAGAIN;
+
 		spin_lock_bh(&bp->phy_lock);
 		err = bnx2_read_phy(bp, data->reg_num & 0x1f, &mii_regval);
 		spin_unlock_bh(&bp->phy_lock);
@@ -5577,6 +5580,9 @@ bnx2_ioctl(struct net_device *dev, struc
 		if (!capable(CAP_NET_ADMIN))
 			return -EPERM;
 
+		if (!netif_running(dev))
+			return -EAGAIN;
+
 		spin_lock_bh(&bp->phy_lock);
 		err = bnx2_write_phy(bp, data->reg_num & 0x1f, data->val_in);
 		spin_unlock_bh(&bp->phy_lock);

-- 

[patch 26/69] BNX2: Save PCI state during suspend.

[Chris Wright]

[-- Attachment #1: bnx2-save-pci-state-during-suspend.patch --]
[-- Type: text/plain, Size: 987 bytes --]

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

From:  <mchan@broadcom.com>

This is needed to save the MSI state which will be lost during
suspend.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

---
 drivers/net/bnx2.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.21.1.orig/drivers/net/bnx2.c
+++ linux-2.6.21.1/drivers/net/bnx2.c
@@ -6148,6 +6148,7 @@ bnx2_suspend(struct pci_dev *pdev, pm_me
 		reset_code = BNX2_DRV_MSG_CODE_SUSPEND_NO_WOL;
 	bnx2_reset_chip(bp, reset_code);
 	bnx2_free_skbs(bp);
+	pci_save_state(pdev);
 	bnx2_set_power_state(bp, pci_choose_state(pdev, state));
 	return 0;
 }
@@ -6161,6 +6162,7 @@ bnx2_resume(struct pci_dev *pdev)
 	if (!netif_running(dev))
 		return 0;
 
+	pci_restore_state(pdev);
 	bnx2_set_power_state(bp, PCI_D0);
 	netif_device_attach(dev);
 	bnx2_init_nic(bp);

-- 

[patch 27/69] BNX2: Update version and reldate.

[Chris Wright]

[-- Attachment #1: bnx2-update-version-and-reldate.patch --]
[-- Type: text/plain, Size: 769 bytes --]

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

From:  <mchan@broadcom.com>

Update version to 1.5.8.1.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

---
 drivers/net/bnx2.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/bnx2.c
+++ linux-2.6.21.1/drivers/net/bnx2.c
@@ -54,8 +54,8 @@
 
 #define DRV_MODULE_NAME		"bnx2"
 #define PFX DRV_MODULE_NAME	": "
-#define DRV_MODULE_VERSION	"1.5.8"
-#define DRV_MODULE_RELDATE	"April 24, 2007"
+#define DRV_MODULE_VERSION	"1.5.8.1"
+#define DRV_MODULE_RELDATE	"May 7, 2007"
 
 #define RUN_AT(x) (jiffies + (x))
 

-- 

[patch 28/69] highres/dyntick: prevent xtime lock contention

[Chris Wright]

[-- Attachment #1: highres-dyntick-prevent-xtime-lock-contention.patch --]
[-- Type: text/plain, Size: 4678 bytes --]

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

From: Thomas Gleixner <tglx@linutronix.de>

While the !highres/!dyntick code assigns the duty of the do_timer() call to
one specific CPU, this was dropped in the highres/dyntick part during
development.

Steven Rostedt discovered the xtime lock contention on highres/dyntick due
to several CPUs trying to update jiffies.

Add the single CPU assignement back.  In the dyntick case this needs to be
handled carefully, as the CPU which has the do_timer() duty must drop the
assignement and let it be grabbed by another CPU, which is active. 
Otherwise the do_timer() calls would not happen during the long sleep.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 kernel/time/tick-common.c   |    8 +++++++-
 kernel/time/tick-internal.h |    1 +
 kernel/time/tick-sched.c    |   42 ++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 48 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/kernel/time/tick-common.c
+++ linux-2.6.21.1/kernel/time/tick-common.c
@@ -31,7 +31,7 @@ DEFINE_PER_CPU(struct tick_device, tick_
  */
 ktime_t tick_next_period;
 ktime_t tick_period;
-static int tick_do_timer_cpu = -1;
+int tick_do_timer_cpu __read_mostly = -1;
 DEFINE_SPINLOCK(tick_device_lock);
 
 /*
@@ -295,6 +295,12 @@ static void tick_shutdown(unsigned int *
 		clockevents_exchange_device(dev, NULL);
 		td->evtdev = NULL;
 	}
+	/* Transfer the do_timer job away from this cpu */
+	if (*cpup == tick_do_timer_cpu) {
+		int cpu = first_cpu(cpu_online_map);
+
+		tick_do_timer_cpu = (cpu != NR_CPUS) ? cpu : -1;
+	}
 	spin_unlock_irqrestore(&tick_device_lock, flags);
 }
 
--- linux-2.6.21.1.orig/kernel/time/tick-internal.h
+++ linux-2.6.21.1/kernel/time/tick-internal.h
@@ -5,6 +5,7 @@ DECLARE_PER_CPU(struct tick_device, tick
 extern spinlock_t tick_device_lock;
 extern ktime_t tick_next_period;
 extern ktime_t tick_period;
+extern int tick_do_timer_cpu __read_mostly;
 
 extern void tick_setup_periodic(struct clock_event_device *dev, int broadcast);
 extern void tick_handle_periodic(struct clock_event_device *dev);
--- linux-2.6.21.1.orig/kernel/time/tick-sched.c
+++ linux-2.6.21.1/kernel/time/tick-sched.c
@@ -221,6 +221,18 @@ void tick_nohz_stop_sched_tick(void)
 			ts->tick_stopped = 1;
 			ts->idle_jiffies = last_jiffies;
 		}
+
+		/*
+		 * If this cpu is the one which updates jiffies, then
+		 * give up the assignment and let it be taken by the
+		 * cpu which runs the tick timer next, which might be
+		 * this cpu as well. If we don't drop this here the
+		 * jiffies might be stale and do_timer() never
+		 * invoked.
+		 */
+		if (cpu == tick_do_timer_cpu)
+			tick_do_timer_cpu = -1;
+
 		/*
 		 * calculate the expiry time for the next timer wheel
 		 * timer
@@ -338,12 +350,24 @@ static void tick_nohz_handler(struct clo
 {
 	struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
 	struct pt_regs *regs = get_irq_regs();
+	int cpu = smp_processor_id();
 	ktime_t now = ktime_get();
 
 	dev->next_event.tv64 = KTIME_MAX;
 
+	/*
+	 * Check if the do_timer duty was dropped. We don't care about
+	 * concurrency: This happens only when the cpu in charge went
+	 * into a long sleep. If two cpus happen to assign themself to
+	 * this duty, then the jiffies update is still serialized by
+	 * xtime_lock.
+	 */
+	if (unlikely(tick_do_timer_cpu == -1))
+		tick_do_timer_cpu = cpu;
+
 	/* Check, if the jiffies need an update */
-	tick_do_update_jiffies64(now);
+	if (tick_do_timer_cpu == cpu)
+		tick_do_update_jiffies64(now);
 
 	/*
 	 * When we are idle and the tick is stopped, we have to touch
@@ -431,9 +455,23 @@ static enum hrtimer_restart tick_sched_t
 	struct hrtimer_cpu_base *base = timer->base->cpu_base;
 	struct pt_regs *regs = get_irq_regs();
 	ktime_t now = ktime_get();
+	int cpu = smp_processor_id();
+
+#ifdef CONFIG_NO_HZ
+	/*
+	 * Check if the do_timer duty was dropped. We don't care about
+	 * concurrency: This happens only when the cpu in charge went
+	 * into a long sleep. If two cpus happen to assign themself to
+	 * this duty, then the jiffies update is still serialized by
+	 * xtime_lock.
+	 */
+	if (unlikely(tick_do_timer_cpu == -1))
+		tick_do_timer_cpu = cpu;
+#endif
 
 	/* Check, if the jiffies need an update */
-	tick_do_update_jiffies64(now);
+	if (tick_do_timer_cpu == cpu)
+		tick_do_update_jiffies64(now);
 
 	/*
 	 * Do not call, when we are not in irq context and have

-- 

[patch 29/69] fat: fix VFAT compat ioctls on 64-bit systems

[Chris Wright]

[-- Attachment #1: fat-fix-vfat-compat-ioctls-on-64-bit-systems.patch --]
[-- Type: text/plain, Size: 9606 bytes --]

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

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

If you compile and run the below test case in an msdos or vfat directory on
an x86-64 system with -m32 you'll get garbage in the kernel_dirent struct
followed by a SIGSEGV.

The patch fixes this.

Reported and initial fix by Bart Oldeman

#include <sys/types.h>
#include <sys/ioctl.h>
#include <dirent.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
struct kernel_dirent {
         long            d_ino;
         long		d_off;
         unsigned short  d_reclen;
         char            d_name[256]; /* We must not include limits.h! */
};
#define VFAT_IOCTL_READDIR_BOTH  _IOR('r', 1, struct kernel_dirent [2])
#define VFAT_IOCTL_READDIR_SHORT  _IOR('r', 2, struct kernel_dirent [2])

int main(void)
{
         int fd = open(".", O_RDONLY);
         struct kernel_dirent de[2];

         while (1) {
                 int i = ioctl(fd, VFAT_IOCTL_READDIR_BOTH, (long)de);
                 if (i == -1) break;
                 if (de[0].d_reclen == 0) break;
                 printf("SFN: reclen=%2d off=%d ino=%d, %-12s",
 		       de[0].d_reclen, de[0].d_off, de[0].d_ino, de[0].d_name);
 		if (de[1].d_reclen)
 		  printf("\tLFN: reclen=%2d off=%d ino=%d, %s",
 		    de[1].d_reclen, de[1].d_off, de[1].d_ino, de[1].d_name);
 		printf("\n");
         }
         return 0;
}

Signed-off-by: Bart Oldeman <bartoldeman@users.sourceforge.net>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 fs/fat/dir.c |  199 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 100 insertions(+), 99 deletions(-)

--- linux-2.6.21.1.orig/fs/fat/dir.c
+++ linux-2.6.21.1/fs/fat/dir.c
@@ -422,7 +422,7 @@ EODir:
 EXPORT_SYMBOL_GPL(fat_search_long);
 
 struct fat_ioctl_filldir_callback {
-	struct dirent __user *dirent;
+	void __user *dirent;
 	int result;
 	/* for dir ioctl */
 	const char *longname;
@@ -647,62 +647,85 @@ static int fat_readdir(struct file *filp
 	return __fat_readdir(inode, filp, dirent, filldir, 0, 0);
 }
 
-static int fat_ioctl_filldir(void *__buf, const char *name, int name_len,
-			     loff_t offset, u64 ino, unsigned int d_type)
+#define FAT_IOCTL_FILLDIR_FUNC(func, dirent_type)			   \
+static int func(void *__buf, const char *name, int name_len,		   \
+			     loff_t offset, u64 ino, unsigned int d_type)  \
+{									   \
+	struct fat_ioctl_filldir_callback *buf = __buf;			   \
+	struct dirent_type __user *d1 = buf->dirent;			   \
+	struct dirent_type __user *d2 = d1 + 1;				   \
+									   \
+	if (buf->result)						   \
+		return -EINVAL;						   \
+	buf->result++;							   \
+									   \
+	if (name != NULL) {						   \
+		/* dirent has only short name */			   \
+		if (name_len >= sizeof(d1->d_name))			   \
+			name_len = sizeof(d1->d_name) - 1;		   \
+									   \
+		if (put_user(0, d2->d_name)			||	   \
+		    put_user(0, &d2->d_reclen)			||	   \
+		    copy_to_user(d1->d_name, name, name_len)	||	   \
+		    put_user(0, d1->d_name + name_len)		||	   \
+		    put_user(name_len, &d1->d_reclen))			   \
+			goto efault;					   \
+	} else {							   \
+		/* dirent has short and long name */			   \
+		const char *longname = buf->longname;			   \
+		int long_len = buf->long_len;				   \
+		const char *shortname = buf->shortname;			   \
+		int short_len = buf->short_len;				   \
+									   \
+		if (long_len >= sizeof(d1->d_name))			   \
+			long_len = sizeof(d1->d_name) - 1;		   \
+		if (short_len >= sizeof(d1->d_name))			   \
+			short_len = sizeof(d1->d_name) - 1;		   \
+									   \
+		if (copy_to_user(d2->d_name, longname, long_len)	|| \
+		    put_user(0, d2->d_name + long_len)			|| \
+		    put_user(long_len, &d2->d_reclen)			|| \
+		    put_user(ino, &d2->d_ino)				|| \
+		    put_user(offset, &d2->d_off)			|| \
+		    copy_to_user(d1->d_name, shortname, short_len)	|| \
+		    put_user(0, d1->d_name + short_len)			|| \
+		    put_user(short_len, &d1->d_reclen))			   \
+			goto efault;					   \
+	}								   \
+	return 0;							   \
+efault:									   \
+	buf->result = -EFAULT;						   \
+	return -EFAULT;							   \
+}
+
+FAT_IOCTL_FILLDIR_FUNC(fat_ioctl_filldir, dirent)
+
+static int fat_ioctl_readdir(struct inode *inode, struct file *filp,
+			     void __user *dirent, filldir_t filldir,
+			     int short_only, int both)
 {
-	struct fat_ioctl_filldir_callback *buf = __buf;
-	struct dirent __user *d1 = buf->dirent;
-	struct dirent __user *d2 = d1 + 1;
-
-	if (buf->result)
-		return -EINVAL;
-	buf->result++;
-
-	if (name != NULL) {
-		/* dirent has only short name */
-		if (name_len >= sizeof(d1->d_name))
-			name_len = sizeof(d1->d_name) - 1;
-
-		if (put_user(0, d2->d_name)			||
-		    put_user(0, &d2->d_reclen)			||
-		    copy_to_user(d1->d_name, name, name_len)	||
-		    put_user(0, d1->d_name + name_len)		||
-		    put_user(name_len, &d1->d_reclen))
-			goto efault;
-	} else {
-		/* dirent has short and long name */
-		const char *longname = buf->longname;
-		int long_len = buf->long_len;
-		const char *shortname = buf->shortname;
-		int short_len = buf->short_len;
-
-		if (long_len >= sizeof(d1->d_name))
-			long_len = sizeof(d1->d_name) - 1;
-		if (short_len >= sizeof(d1->d_name))
-			short_len = sizeof(d1->d_name) - 1;
-
-		if (copy_to_user(d2->d_name, longname, long_len)	||
-		    put_user(0, d2->d_name + long_len)			||
-		    put_user(long_len, &d2->d_reclen)			||
-		    put_user(ino, &d2->d_ino)				||
-		    put_user(offset, &d2->d_off)			||
-		    copy_to_user(d1->d_name, shortname, short_len)	||
-		    put_user(0, d1->d_name + short_len)			||
-		    put_user(short_len, &d1->d_reclen))
-			goto efault;
+	struct fat_ioctl_filldir_callback buf;
+	int ret;
+
+	buf.dirent = dirent;
+	buf.result = 0;
+	mutex_lock(&inode->i_mutex);
+	ret = -ENOENT;
+	if (!IS_DEADDIR(inode)) {
+		ret = __fat_readdir(inode, filp, &buf, filldir,
+				    short_only, both);
 	}
-	return 0;
-efault:
-	buf->result = -EFAULT;
-	return -EFAULT;
+	mutex_unlock(&inode->i_mutex);
+	if (ret >= 0)
+		ret = buf.result;
+	return ret;
 }
 
-static int fat_dir_ioctl(struct inode * inode, struct file * filp,
-		  unsigned int cmd, unsigned long arg)
+static int fat_dir_ioctl(struct inode *inode, struct file *filp,
+			 unsigned int cmd, unsigned long arg)
 {
-	struct fat_ioctl_filldir_callback buf;
-	struct dirent __user *d1;
-	int ret, short_only, both;
+	struct dirent __user *d1 = (struct dirent __user *)arg;
+	int short_only, both;
 
 	switch (cmd) {
 	case VFAT_IOCTL_READDIR_SHORT:
@@ -717,7 +740,6 @@ static int fat_dir_ioctl(struct inode * 
 		return fat_generic_ioctl(inode, filp, cmd, arg);
 	}
 
-	d1 = (struct dirent __user *)arg;
 	if (!access_ok(VERIFY_WRITE, d1, sizeof(struct dirent[2])))
 		return -EFAULT;
 	/*
@@ -728,69 +750,48 @@ static int fat_dir_ioctl(struct inode * 
 	if (put_user(0, &d1->d_reclen))
 		return -EFAULT;
 
-	buf.dirent = d1;
-	buf.result = 0;
-	mutex_lock(&inode->i_mutex);
-	ret = -ENOENT;
-	if (!IS_DEADDIR(inode)) {
-		ret = __fat_readdir(inode, filp, &buf, fat_ioctl_filldir,
-				    short_only, both);
-	}
-	mutex_unlock(&inode->i_mutex);
-	if (ret >= 0)
-		ret = buf.result;
-	return ret;
+	return fat_ioctl_readdir(inode, filp, d1, fat_ioctl_filldir,
+				 short_only, both);
 }
 
 #ifdef CONFIG_COMPAT
 #define	VFAT_IOCTL_READDIR_BOTH32	_IOR('r', 1, struct compat_dirent[2])
 #define	VFAT_IOCTL_READDIR_SHORT32	_IOR('r', 2, struct compat_dirent[2])
 
-static long fat_compat_put_dirent32(struct dirent *d,
-				    struct compat_dirent __user *d32)
-{
-        if (!access_ok(VERIFY_WRITE, d32, sizeof(struct compat_dirent)))
-                return -EFAULT;
+FAT_IOCTL_FILLDIR_FUNC(fat_compat_ioctl_filldir, compat_dirent)
 
-        __put_user(d->d_ino, &d32->d_ino);
-        __put_user(d->d_off, &d32->d_off);
-        __put_user(d->d_reclen, &d32->d_reclen);
-        if (__copy_to_user(d32->d_name, d->d_name, d->d_reclen))
-		return -EFAULT;
-
-        return 0;
-}
-
-static long fat_compat_dir_ioctl(struct file *file, unsigned cmd,
+static long fat_compat_dir_ioctl(struct file *filp, unsigned cmd,
 				 unsigned long arg)
 {
-	struct compat_dirent __user *p = compat_ptr(arg);
-	int ret;
-	mm_segment_t oldfs = get_fs();
-	struct dirent d[2];
+	struct inode *inode = filp->f_path.dentry->d_inode;
+	struct compat_dirent __user *d1 = compat_ptr(arg);
+	int short_only, both;
 
 	switch (cmd) {
-	case VFAT_IOCTL_READDIR_BOTH32:
-		cmd = VFAT_IOCTL_READDIR_BOTH;
-		break;
 	case VFAT_IOCTL_READDIR_SHORT32:
-		cmd = VFAT_IOCTL_READDIR_SHORT;
+		short_only = 1;
+		both = 0;
+		break;
+	case VFAT_IOCTL_READDIR_BOTH32:
+		short_only = 0;
+		both = 1;
 		break;
 	default:
 		return -ENOIOCTLCMD;
 	}
 
-	set_fs(KERNEL_DS);
-	lock_kernel();
-	ret = fat_dir_ioctl(file->f_path.dentry->d_inode, file,
-			    cmd, (unsigned long) &d);
-	unlock_kernel();
-	set_fs(oldfs);
-	if (ret >= 0) {
-		ret |= fat_compat_put_dirent32(&d[0], p);
-		ret |= fat_compat_put_dirent32(&d[1], p + 1);
-	}
-	return ret;
+	if (!access_ok(VERIFY_WRITE, d1, sizeof(struct compat_dirent[2])))
+		return -EFAULT;
+	/*
+	 * Yes, we don't need this put_user() absolutely. However old
+	 * code didn't return the right value. So, app use this value,
+	 * in order to check whether it is EOF.
+	 */
+	if (put_user(0, &d1->d_reclen))
+		return -EFAULT;
+
+	return fat_ioctl_readdir(inode, filp, d1, fat_compat_ioctl_filldir,
+				 short_only, both);
 }
 #endif /* CONFIG_COMPAT */
 

-- 

[patch 30/69] udf: decrement correct link count in udf_rmdir

[Chris Wright]

[-- Attachment #1: udf-decrement-correct-link-count-in-udf_rmdir.patch --]
[-- Type: text/plain, Size: 1339 bytes --]

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

From: Stephen Mollett <molletts@yahoo.com>

It appears that a minor thinko occurred in udf_rmdir and the
(already-cleared) link count on the directory that is being removed was
being decremented instead of the link count on its parent directory.  This
gives rise to lots of kernel messages similar to:

UDF-fs warning (device loop1): udf_rmdir: empty directory has nlink != 2 (8)

when removing directory trees.  No other ill effects have been observed but
I guess it could theoretically result in the link count overflowing on a
very long-lived, much modified directory.

Signed-off-by: Stephen Mollett <molletts@yahoo.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Jan Kara <jack@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 fs/udf/namei.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/fs/udf/namei.c
+++ linux-2.6.21.1/fs/udf/namei.c
@@ -878,7 +878,7 @@ static int udf_rmdir(struct inode * dir,
 			inode->i_nlink);
 	clear_nlink(inode);
 	inode->i_size = 0;
-	inode_dec_link_count(inode);
+	inode_dec_link_count(dir);
 	inode->i_ctime = dir->i_ctime = dir->i_mtime = current_fs_time(dir->i_sb);
 	mark_inode_dirty(dir);
 

-- 

[patch 31/69] IPV6: Fix slab corruption running ip6sic

[Chris Wright]

[-- Attachment #1: ipv6-fix-slab-corruption-running-ip6sic.patch --]
[-- Type: text/plain, Size: 623 bytes --]

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

From: Eric Sesterhenn <snakebyte@gmx.de>

---
 net/ipv6/xfrm6_tunnel.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/net/ipv6/xfrm6_tunnel.c
+++ linux-2.6.21.1/net/ipv6/xfrm6_tunnel.c
@@ -261,7 +261,7 @@ static int xfrm6_tunnel_rcv(struct sk_bu
 	__be32 spi;
 
 	spi = xfrm6_tunnel_spi_lookup((xfrm_address_t *)&iph->saddr);
-	return xfrm6_rcv_spi(skb, spi);
+	return xfrm6_rcv_spi(skb, spi) > 0 ? : 0;
 }
 
 static int xfrm6_tunnel_err(struct sk_buff *skb, struct inet6_skb_parm *opt,

-- 

[patch 32/69] NETPOLL: Fix TX queue overflow in trapped mode.

[Chris Wright]

[-- Attachment #1: netpoll-fix-tx-queue-overflow-in-trapped-mode.patch --]
[-- Type: text/plain, Size: 1538 bytes --]

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

From: Sergei Shtylyov <sshtylyov@ru.mvista.com>

CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in
the netpoll's "trapped" mode which easily causes overflows in the drivers with
short TX queues (most notably, in 8139too with its 4-deep queue).  So, make
this option more sensible by making it only bypass the TX softirq wakeup.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Acked-by: Tom Rini <trini@kernel.crashing.org>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 include/linux/netdevice.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

--- linux-2.6.21.1.orig/include/linux/netdevice.h
+++ linux-2.6.21.1/include/linux/netdevice.h
@@ -647,8 +647,10 @@ static inline void netif_start_queue(str
 static inline void netif_wake_queue(struct net_device *dev)
 {
 #ifdef CONFIG_NETPOLL_TRAP
-	if (netpoll_trap())
+	if (netpoll_trap()) {
+		clear_bit(__LINK_STATE_XOFF, &dev->state);
 		return;
+	}
 #endif
 	if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state))
 		__netif_schedule(dev);
@@ -656,10 +658,6 @@ static inline void netif_wake_queue(stru
 
 static inline void netif_stop_queue(struct net_device *dev)
 {
-#ifdef CONFIG_NETPOLL_TRAP
-	if (netpoll_trap())
-		return;
-#endif
 	set_bit(__LINK_STATE_XOFF, &dev->state);
 }
 

-- 

[patch 33/69] NETPOLL: Remove CONFIG_NETPOLL_RX

[Chris Wright]

[-- Attachment #1: netpoll-remove-config_netpoll_rx.patch --]
[-- Type: text/plain, Size: 914 bytes --]

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

From: Sergei Shtylyov <sshtylyov@ru.mvista.com>

Get rid of the CONFIG_NETPOLL_RX option completely since all the
dependencies have been removed long ago...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/Kconfig |    5 -----
 1 file changed, 5 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/Kconfig
+++ linux-2.6.21.1/drivers/net/Kconfig
@@ -2929,11 +2929,6 @@ endif #NETDEVICES
 config NETPOLL
 	def_bool NETCONSOLE
 
-config NETPOLL_RX
-	bool "Netpoll support for trapping incoming packets"
-	default n
-	depends on NETPOLL
-
 config NETPOLL_TRAP
 	bool "Netpoll traffic trapping"
 	default n

-- 

[patch 34/69] SCTP: Fix sctp_getsockopt_local_addrs_old() to use local storage.

[Chris Wright]

[-- Attachment #1: sctp-fix-sctp_getsockopt_local_addrs_old-to-use-local-storage.patch --]
[-- Type: text/plain, Size: 7031 bytes --]

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

From: Vlad Yasevich <vladislav.yasevich@hp.com>

sctp_getsockopt_local_addrs_old() in net/sctp/socket.c calls
copy_to_user() while the spinlock addr_lock is held. this should not
be done as copy_to_user() might sleep. the call to
sctp_copy_laddrs_to_user() while holding the lock is also problematic
as it calls copy_to_user()

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/sctp/socket.c |   96 +++++++++++++++++++++++++++++++++---------------------
 1 file changed, 60 insertions(+), 36 deletions(-)

--- linux-2.6.21.1.orig/net/sctp/socket.c
+++ linux-2.6.21.1/net/sctp/socket.c
@@ -3847,7 +3847,7 @@ static int sctp_getsockopt_peer_addrs(st
 		memcpy(&temp, &from->ipaddr, sizeof(temp));
 		sctp_get_pf_specific(sk->sk_family)->addr_v4map(sp, &temp);
 		addrlen = sctp_get_af_specific(sk->sk_family)->sockaddr_len;
-		if(space_left < addrlen)
+		if (space_left < addrlen)
 			return -ENOMEM;
 		if (copy_to_user(to, &temp, addrlen))
 			return -EFAULT;
@@ -3936,8 +3936,9 @@ done:
 /* Helper function that copies local addresses to user and returns the number
  * of addresses copied.
  */
-static int sctp_copy_laddrs_to_user_old(struct sock *sk, __u16 port, int max_addrs,
-					void __user *to)
+static int sctp_copy_laddrs_old(struct sock *sk, __u16 port,
+					int max_addrs, void *to,
+					int *bytes_copied)
 {
 	struct list_head *pos, *next;
 	struct sctp_sockaddr_entry *addr;
@@ -3954,10 +3955,10 @@ static int sctp_copy_laddrs_to_user_old(
 		sctp_get_pf_specific(sk->sk_family)->addr_v4map(sctp_sk(sk),
 								&temp);
 		addrlen = sctp_get_af_specific(temp.sa.sa_family)->sockaddr_len;
-		if (copy_to_user(to, &temp, addrlen))
-			return -EFAULT;
+		memcpy(to, &temp, addrlen);
 
 		to += addrlen;
+		*bytes_copied += addrlen;
 		cnt ++;
 		if (cnt >= max_addrs) break;
 	}
@@ -3965,8 +3966,8 @@ static int sctp_copy_laddrs_to_user_old(
 	return cnt;
 }
 
-static int sctp_copy_laddrs_to_user(struct sock *sk, __u16 port,
-				    void __user **to, size_t space_left)
+static int sctp_copy_laddrs(struct sock *sk, __u16 port, void *to,
+			    size_t space_left, int *bytes_copied)
 {
 	struct list_head *pos, *next;
 	struct sctp_sockaddr_entry *addr;
@@ -3983,14 +3984,14 @@ static int sctp_copy_laddrs_to_user(stru
 		sctp_get_pf_specific(sk->sk_family)->addr_v4map(sctp_sk(sk),
 								&temp);
 		addrlen = sctp_get_af_specific(temp.sa.sa_family)->sockaddr_len;
-		if(space_left<addrlen)
+		if (space_left < addrlen)
 			return -ENOMEM;
-		if (copy_to_user(*to, &temp, addrlen))
-			return -EFAULT;
+		memcpy(to, &temp, addrlen);
 
-		*to += addrlen;
+		to += addrlen;
 		cnt ++;
 		space_left -= addrlen;
+		bytes_copied += addrlen;
 	}
 
 	return cnt;
@@ -4014,6 +4015,8 @@ static int sctp_getsockopt_local_addrs_o
 	int addrlen;
 	rwlock_t *addr_lock;
 	int err = 0;
+	void *addrs;
+	int bytes_copied = 0;
 
 	if (len != sizeof(struct sctp_getaddrs_old))
 		return -EINVAL;
@@ -4041,6 +4044,15 @@ static int sctp_getsockopt_local_addrs_o
 
 	to = getaddrs.addrs;
 
+	/* Allocate space for a local instance of packed array to hold all
+	 * the data.  We store addresses here first and then put write them
+	 * to the user in one shot.
+	 */
+	addrs = kmalloc(sizeof(union sctp_addr) * getaddrs.addr_num,
+			GFP_KERNEL);
+	if (!addrs)
+		return -ENOMEM;
+
 	sctp_read_lock(addr_lock);
 
 	/* If the endpoint is bound to 0.0.0.0 or ::0, get the valid
@@ -4050,13 +4062,9 @@ static int sctp_getsockopt_local_addrs_o
 		addr = list_entry(bp->address_list.next,
 				  struct sctp_sockaddr_entry, list);
 		if (sctp_is_any(&addr->a)) {
-			cnt = sctp_copy_laddrs_to_user_old(sk, bp->port,
-							   getaddrs.addr_num,
-							   to);
-			if (cnt < 0) {
-				err = cnt;
-				goto unlock;
-			}
+			cnt = sctp_copy_laddrs_old(sk, bp->port,
+						   getaddrs.addr_num,
+						   addrs, &bytes_copied);
 			goto copy_getaddrs;
 		}
 	}
@@ -4066,22 +4074,29 @@ static int sctp_getsockopt_local_addrs_o
 		memcpy(&temp, &addr->a, sizeof(temp));
 		sctp_get_pf_specific(sk->sk_family)->addr_v4map(sp, &temp);
 		addrlen = sctp_get_af_specific(temp.sa.sa_family)->sockaddr_len;
-		if (copy_to_user(to, &temp, addrlen)) {
-			err = -EFAULT;
-			goto unlock;
-		}
+		memcpy(addrs, &temp, addrlen);
 		to += addrlen;
+		bytes_copied += addrlen;
 		cnt ++;
 		if (cnt >= getaddrs.addr_num) break;
 	}
 
 copy_getaddrs:
+	sctp_read_unlock(addr_lock);
+
+	/* copy the entire address list into the user provided space */
+	if (copy_to_user(to, addrs, bytes_copied)) {
+		err = -EFAULT;
+		goto error;
+	}
+
+	/* copy the leading structure back to user */
 	getaddrs.addr_num = cnt;
 	if (copy_to_user(optval, &getaddrs, sizeof(struct sctp_getaddrs_old)))
 		err = -EFAULT;
 
-unlock:
-	sctp_read_unlock(addr_lock);
+error:
+	kfree(addrs);
 	return err;
 }
 
@@ -4101,7 +4116,8 @@ static int sctp_getsockopt_local_addrs(s
 	rwlock_t *addr_lock;
 	int err = 0;
 	size_t space_left;
-	int bytes_copied;
+	int bytes_copied = 0;
+	void *addrs;
 
 	if (len <= sizeof(struct sctp_getaddrs))
 		return -EINVAL;
@@ -4129,6 +4145,9 @@ static int sctp_getsockopt_local_addrs(s
 	to = optval + offsetof(struct sctp_getaddrs,addrs);
 	space_left = len - sizeof(struct sctp_getaddrs) -
 			 offsetof(struct sctp_getaddrs,addrs);
+	addrs = kmalloc(space_left, GFP_KERNEL);
+	if (!addrs)
+		return -ENOMEM;
 
 	sctp_read_lock(addr_lock);
 
@@ -4139,11 +4158,11 @@ static int sctp_getsockopt_local_addrs(s
 		addr = list_entry(bp->address_list.next,
 				  struct sctp_sockaddr_entry, list);
 		if (sctp_is_any(&addr->a)) {
-			cnt = sctp_copy_laddrs_to_user(sk, bp->port,
-						       &to, space_left);
+			cnt = sctp_copy_laddrs(sk, bp->port, addrs,
+						space_left, &bytes_copied);
 			if (cnt < 0) {
 				err = cnt;
-				goto unlock;
+				goto error;
 			}
 			goto copy_getaddrs;
 		}
@@ -4154,26 +4173,31 @@ static int sctp_getsockopt_local_addrs(s
 		memcpy(&temp, &addr->a, sizeof(temp));
 		sctp_get_pf_specific(sk->sk_family)->addr_v4map(sp, &temp);
 		addrlen = sctp_get_af_specific(temp.sa.sa_family)->sockaddr_len;
-		if(space_left < addrlen)
-			return -ENOMEM; /*fixme: right error?*/
-		if (copy_to_user(to, &temp, addrlen)) {
-			err = -EFAULT;
-			goto unlock;
+		if (space_left < addrlen) {
+			err =  -ENOMEM; /*fixme: right error?*/
+			goto error;
 		}
+		memcpy(addrs, &temp, addrlen);
 		to += addrlen;
+		bytes_copied += addrlen;
 		cnt ++;
 		space_left -= addrlen;
 	}
 
 copy_getaddrs:
+	sctp_read_unlock(addr_lock);
+
+	if (copy_to_user(to, addrs, bytes_copied)) {
+		err = -EFAULT;
+		goto error;
+	}
 	if (put_user(cnt, &((struct sctp_getaddrs __user *)optval)->addr_num))
 		return -EFAULT;
-	bytes_copied = ((char __user *)to) - optval;
 	if (put_user(bytes_copied, optlen))
 		return -EFAULT;
 
-unlock:
-	sctp_read_unlock(addr_lock);
+error:
+	kfree(addrs);
 	return err;
 }
 

-- 

[patch 35/69] SCTP: Correctly copy addresses in sctp_copy_laddrs

[Chris Wright]

[-- Attachment #1: sctp-correctly-copy-addresses-in-sctp_copy_laddrs.patch --]
[-- Type: text/plain, Size: 2092 bytes --]

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

From: Vlad Yasevich <vladislav.yasevich@hp.com>

I broke the  non-wildcard case recently.  This is to fixes it.
Now, explictitly bound addresses can ge retrieved using the API.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 net/sctp/socket.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/net/sctp/socket.c
+++ linux-2.6.21.1/net/sctp/socket.c
@@ -4016,6 +4016,7 @@ static int sctp_getsockopt_local_addrs_o
 	rwlock_t *addr_lock;
 	int err = 0;
 	void *addrs;
+	void *buf;
 	int bytes_copied = 0;
 
 	if (len != sizeof(struct sctp_getaddrs_old))
@@ -4069,13 +4070,14 @@ static int sctp_getsockopt_local_addrs_o
 		}
 	}
 
+	buf = addrs;
 	list_for_each(pos, &bp->address_list) {
 		addr = list_entry(pos, struct sctp_sockaddr_entry, list);
 		memcpy(&temp, &addr->a, sizeof(temp));
 		sctp_get_pf_specific(sk->sk_family)->addr_v4map(sp, &temp);
 		addrlen = sctp_get_af_specific(temp.sa.sa_family)->sockaddr_len;
-		memcpy(addrs, &temp, addrlen);
-		to += addrlen;
+		memcpy(buf, &temp, addrlen);
+		buf += addrlen;
 		bytes_copied += addrlen;
 		cnt ++;
 		if (cnt >= getaddrs.addr_num) break;
@@ -4118,6 +4120,7 @@ static int sctp_getsockopt_local_addrs(s
 	size_t space_left;
 	int bytes_copied = 0;
 	void *addrs;
+	void *buf;
 
 	if (len <= sizeof(struct sctp_getaddrs))
 		return -EINVAL;
@@ -4168,6 +4171,7 @@ static int sctp_getsockopt_local_addrs(s
 		}
 	}
 
+	buf = addrs;
 	list_for_each(pos, &bp->address_list) {
 		addr = list_entry(pos, struct sctp_sockaddr_entry, list);
 		memcpy(&temp, &addr->a, sizeof(temp));
@@ -4177,8 +4181,8 @@ static int sctp_getsockopt_local_addrs(s
 			err =  -ENOMEM; /*fixme: right error?*/
 			goto error;
 		}
-		memcpy(addrs, &temp, addrlen);
-		to += addrlen;
+		memcpy(buf, &temp, addrlen);
+		buf += addrlen;
 		bytes_copied += addrlen;
 		cnt ++;
 		space_left -= addrlen;

-- 

[patch 36/69] TCP: zero out rx_opt in tcp_disconnect()

[Chris Wright]

[-- Attachment #1: tcp-zero-out-rx_opt-in-tcp_disconnect.patch --]
[-- Type: text/plain, Size: 1606 bytes --]

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

From: Srinivas Aji <Aji_Srinivas@emc.com>

When the server drops its connection, NFS client reconnects using the
same socket after disconnecting. If the new connection's SYN,ACK
doesn't contain the TCP timestamp option and the old connection's did,
tp->tcp_header_len is recomputed assuming no timestamp header but
tp->rx_opt.tstamp_ok remains set. Then tcp_build_and_update_options()
adds in a timestamp option past the end of the allocated TCP header,
overwriting TCP data, or when the data is in skb_shinfo(skb)->frags[],
overwriting skb_shinfo(skb) causing a crash soon after. (The issue was
debugged from such a crash.)

Similarly, wscale_ok and sack_ok also get set based on the SYN,ACK
packet but not reset on disconnect, since they are zeroed out at
initialization. The patch zeroes out the entire tp->rx_opt struct in
tcp_disconnect() to avoid this sort of problem.

Signed-off-by: Srinivas Aji <Aji_Srinivas@emc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/ipv4/tcp.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.21.1.orig/net/ipv4/tcp.c
+++ linux-2.6.21.1/net/ipv4/tcp.c
@@ -1759,8 +1759,7 @@ int tcp_disconnect(struct sock *sk, int 
 	tcp_clear_retrans(tp);
 	inet_csk_delack_init(sk);
 	sk->sk_send_head = NULL;
-	tp->rx_opt.saw_tstamp = 0;
-	tcp_sack_reset(&tp->rx_opt);
+	memset(&tp->rx_opt, 0, sizeof(tp->rx_opt));
 	__sk_dst_reset(sk);
 
 	BUG_TRAP(!inet->num || icsk->icsk_bind_hash);

-- 

[patch 37/69] fix leaky resv_huge_pages when cpuset is in use

[Chris Wright]

[-- Attachment #1: fix-leaky-resv_huge_pages-when-cpuset-is-in-use.patch --]
[-- Type: text/plain, Size: 1751 bytes --]

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

From:  <kenchen@google.com>

The internal hugetlb resv_huge_pages variable can permanently leak nonzero
value in the error path of hugetlb page fault handler when hugetlb page is
used in combination of cpuset.  The leaked count can permanently trap N
number of hugetlb pages in unusable "reserved" state.

Steps to reproduce the bug:

  (1) create two cpuset, user1 and user2
  (2) reserve 50 htlb pages in cpuset user1
  (3) attempt to shmget/shmat 50 htlb page inside cpuset user2
  (4) kernel oom the user process in step 3
  (5) ipcrm the shm segment

At this point resv_huge_pages will have a count of 49, even though
there are no active hugetlbfs file nor hugetlb shared memory segment
in the system.  The leak is permanent and there is no recovery method
other than system reboot. The leaked count will hold up all future use
of that many htlb pages in all cpusets.

The culprit is that the error path of alloc_huge_page() did not
properly undo the change it made to resv_huge_page, causing
inconsistent state.

Signed-off-by: Ken Chen <kenchen@google.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Adam Litke <agl@us.ibm.com>
Cc: Martin Bligh <mbligh@google.com>
Acked-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 mm/hugetlb.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6.21.1.orig/mm/hugetlb.c
+++ linux-2.6.21.1/mm/hugetlb.c
@@ -140,6 +140,8 @@ static struct page *alloc_huge_page(stru
 	return page;
 
 fail:
+	if (vma->vm_flags & VM_MAYSHARE)
+		resv_huge_pages++;
 	spin_unlock(&hugetlb_lock);
 	return NULL;
 }

-- 

[patch 38/69] clocksource: fix resume logic

[Chris Wright]

[-- Attachment #1: clocksource-fix-resume-logic.patch --]
[-- Type: text/plain, Size: 4589 bytes --]

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

From: Thomas Gleixner <tglx@linutronix.de>

We need to make sure that the clocksources are resumed, when timekeeping is
resumed.  The current resume logic does not guarantee this.

Add a resume function pointer to the clocksource struct, so clocksource
drivers which need to reinitialize the clocksource can provide a resume
function.

Add a resume function, which calls the maybe available clocksource resume
functions and resets the watchdog function, so a stable TSC can be used
accross suspend/resume.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 include/linux/clocksource.h |    3 ++
 kernel/time/clocksource.c   |   45 ++++++++++++++++++++++++++++++++++++++++++++
 kernel/timer.c              |    2 +
 3 files changed, 50 insertions(+)

--- linux-2.6.21.1.orig/include/linux/clocksource.h
+++ linux-2.6.21.1/include/linux/clocksource.h
@@ -48,6 +48,7 @@ struct clocksource;
  * @shift:		cycle to nanosecond divisor (power of two)
  * @flags:		flags describing special properties
  * @vread:		vsyscall based read
+ * @resume:		resume function for the clocksource, if necessary
  * @cycle_interval:	Used internally by timekeeping core, please ignore.
  * @xtime_interval:	Used internally by timekeeping core, please ignore.
  */
@@ -61,6 +62,7 @@ struct clocksource {
 	u32 shift;
 	unsigned long flags;
 	cycle_t (*vread)(void);
+	void (*resume)(void);
 
 	/* timekeeping specific data, ignore */
 	cycle_t cycle_last, cycle_interval;
@@ -198,6 +200,7 @@ static inline void clocksource_calculate
 extern int clocksource_register(struct clocksource*);
 extern struct clocksource* clocksource_get_next(void);
 extern void clocksource_change_rating(struct clocksource *cs, int rating);
+extern void clocksource_resume(void);
 
 #ifdef CONFIG_GENERIC_TIME_VSYSCALL
 extern void update_vsyscall(struct timespec *ts, struct clocksource *c);
--- linux-2.6.21.1.orig/kernel/time/clocksource.c
+++ linux-2.6.21.1/kernel/time/clocksource.c
@@ -74,6 +74,8 @@ static struct clocksource *watchdog;
 static struct timer_list watchdog_timer;
 static DEFINE_SPINLOCK(watchdog_lock);
 static cycle_t watchdog_last;
+static int watchdog_resumed;
+
 /*
  * Interval: 0.5sec Treshold: 0.0625s
  */
@@ -98,15 +100,26 @@ static void clocksource_watchdog(unsigne
 	struct clocksource *cs, *tmp;
 	cycle_t csnow, wdnow;
 	int64_t wd_nsec, cs_nsec;
+	int resumed;
 
 	spin_lock(&watchdog_lock);
 
+	resumed = watchdog_resumed;
+	if (unlikely(resumed))
+		watchdog_resumed = 0;
+
 	wdnow = watchdog->read();
 	wd_nsec = cyc2ns(watchdog, (wdnow - watchdog_last) & watchdog->mask);
 	watchdog_last = wdnow;
 
 	list_for_each_entry_safe(cs, tmp, &watchdog_list, wd_list) {
 		csnow = cs->read();
+
+		if (unlikely(resumed)) {
+			cs->wd_last = csnow;
+			continue;
+		}
+
 		/* Initialized ? */
 		if (!(cs->flags & CLOCK_SOURCE_WATCHDOG)) {
 			if ((cs->flags & CLOCK_SOURCE_IS_CONTINUOUS) &&
@@ -136,6 +149,13 @@ static void clocksource_watchdog(unsigne
 	}
 	spin_unlock(&watchdog_lock);
 }
+static void clocksource_resume_watchdog(void)
+{
+	spin_lock(&watchdog_lock);
+	watchdog_resumed = 1;
+	spin_unlock(&watchdog_lock);
+}
+
 static void clocksource_check_watchdog(struct clocksource *cs)
 {
 	struct clocksource *cse;
@@ -182,9 +202,34 @@ static void clocksource_check_watchdog(s
 	if (cs->flags & CLOCK_SOURCE_IS_CONTINUOUS)
 		cs->flags |= CLOCK_SOURCE_VALID_FOR_HRES;
 }
+
+static inline void clocksource_resume_watchdog(void) { }
 #endif
 
 /**
+ * clocksource_resume - resume the clocksource(s)
+ */
+void clocksource_resume(void)
+{
+	struct list_head *tmp;
+	unsigned long flags;
+
+	spin_lock_irqsave(&clocksource_lock, flags);
+
+	list_for_each(tmp, &clocksource_list) {
+		struct clocksource *cs;
+
+		cs = list_entry(tmp, struct clocksource, list);
+		if (cs->resume)
+			cs->resume();
+	}
+
+	clocksource_resume_watchdog();
+
+	spin_unlock_irqrestore(&clocksource_lock, flags);
+}
+
+/**
  * clocksource_get_next - Returns the selected clocksource
  *
  */
--- linux-2.6.21.1.orig/kernel/timer.c
+++ linux-2.6.21.1/kernel/timer.c
@@ -1903,6 +1903,8 @@ unregister_time_interpolator(struct time
 		prev = &curr->next;
 	}
 
+	clocksource_resume();
+
 	write_seqlock_irqsave(&xtime_lock, flags);
 	if (ti == time_interpolator) {
 		/* we lost the best time-interpolator: */

-- 

[patch 39/69] md: Avoid a possibility that a read error can wrongly propagate through md/raid1 to a filesystem.

[Chris Wright]

[-- Attachment #1: md-avoid-a-possibility-that-a-read-error-can-wrongly-propagate-through-md-raid1-to-a-filesystem.patch --]
[-- Type: text/plain, Size: 2823 bytes --]

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

From: NeilBrown <neilb@suse.de>

When a raid1 has only one working drive, we want read error to
propagate up to the filesystem as there is no point failing the last
drive in an array.

Currently the code perform this check is racy.  If a write and a read
a both submitted to a device on a 2-drive raid1, and the write fails
followed by the read failing, the read will see that there is only one
working drive and will pass the failure up, even though the one
working drive is actually the *other* one.

So, tighten up the locking.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 drivers/md/raid1.c |   33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff .prev/drivers/md/raid1.c ./drivers/md/raid1.c
--- linux-2.6.21.1.orig/drivers/md/raid1.c
+++ linux-2.6.21.1/drivers/md/raid1.c
@@ -271,21 +271,25 @@ static int raid1_end_read_request(struct
 	 */
 	update_head_pos(mirror, r1_bio);
 
-	if (uptodate || (conf->raid_disks - conf->mddev->degraded) <= 1) {
-		/*
-		 * Set R1BIO_Uptodate in our master bio, so that
-		 * we will return a good error code for to the higher
-		 * levels even if IO on some other mirrored buffer fails.
-		 *
-		 * The 'master' represents the composite IO operation to
-		 * user-side. So if something waits for IO, then it will
-		 * wait for the 'master' bio.
+	if (uptodate)
+		set_bit(R1BIO_Uptodate, &r1_bio->state);
+	else {
+		/* If all other devices have failed, we want to return
+		 * the error upwards rather than fail the last device.
+		 * Here we redefine "uptodate" to mean "Don't want to retry"
 		 */
-		if (uptodate)
-			set_bit(R1BIO_Uptodate, &r1_bio->state);
+		unsigned long flags;
+		spin_lock_irqsave(&conf->device_lock, flags);
+		if (r1_bio->mddev->degraded == conf->raid_disks ||
+		    (r1_bio->mddev->degraded == conf->raid_disks-1 &&
+		     !test_bit(Faulty, &conf->mirrors[mirror].rdev->flags)))
+			uptodate = 1;
+		spin_unlock_irqrestore(&conf->device_lock, flags);
+	}
 
+	if (uptodate)
 		raid_end_bio_io(r1_bio);
-	} else {
+	else {
 		/*
 		 * oops, read error:
 		 */
@@ -992,13 +996,14 @@ static void error(mddev_t *mddev, mdk_rd
 		unsigned long flags;
 		spin_lock_irqsave(&conf->device_lock, flags);
 		mddev->degraded++;
+		set_bit(Faulty, &rdev->flags);
 		spin_unlock_irqrestore(&conf->device_lock, flags);
 		/*
 		 * if recovery is running, make sure it aborts.
 		 */
 		set_bit(MD_RECOVERY_ERR, &mddev->recovery);
-	}
-	set_bit(Faulty, &rdev->flags);
+	} else
+		set_bit(Faulty, &rdev->flags);
 	set_bit(MD_CHANGE_DEVS, &mddev->flags);
 	printk(KERN_ALERT "raid1: Disk failure on %s, disabling device. \n"
 		"	Operation continuing on %d devices\n",

-- 

[patch 40/69] driver-core: dont free devt_attr till the device is released

[Chris Wright]

[-- Attachment #1: driver-core-don-t-free-devt_attr-till-the-device-is-released.patch --]
[-- Type: text/plain, Size: 1665 bytes --]

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

From: Tejun Heo <htejun@gmail.com>

Currently, devt_attr for the "dev" file is freed immediately on device
removal, but if the "dev" sysfs file is open when a device is removed,
sysfs will access its attribute structure for further access including
close resulting in jumping to garbled address.  Fix it by postponing
freeing devt_attr to device release time.

Note that devt_attr for class_device is already freed on release.

This bug is reported by Chris Rankin as bugzilla bug#8198.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
Applies well to 2.6.20 and 21.  As sysfs-immediate-disconnect doesn't
seem to be included in 2.6.22, this should be included in linus#master
too (applies well there as well).

 drivers/base/core.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/drivers/base/core.c
+++ linux-2.6.21.1/drivers/base/core.c
@@ -93,6 +93,9 @@ static void device_release(struct kobjec
 {
 	struct device * dev = to_dev(kobj);
 
+	kfree(dev->devt_attr);
+	dev->devt_attr = NULL;
+
 	if (dev->release)
 		dev->release(dev);
 	else if (dev->type && dev->type->release)
@@ -765,10 +768,8 @@ void device_del(struct device * dev)
 
 	if (parent)
 		klist_del(&dev->knode_parent);
-	if (dev->devt_attr) {
+	if (dev->devt_attr)
 		device_remove_file(dev, dev->devt_attr);
-		kfree(dev->devt_attr);
-	}
 	if (dev->class) {
 		sysfs_remove_link(&dev->kobj, "subsystem");
 		/* If this is not a "fake" compatible device, remove the

-- 

[patch 41/69] pci-quirks: disable MSI on RS400-200 and RS480

[Chris Wright]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: pci-quirks-disable-msi-on-rs400-200-and-rs480.patch --]
[-- Type: text/plain, Size: 2477 bytes --]

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

From: Tejun Heo <htejun@gmail.com>

MSI doesn't work on RS400-200 and RS480 requiring pci=nomsi kernel boot
parameter for ahci to work.  This patch renames quirk_svw_msi() to
quirk_disable_all_msi() and use it to disable MSI on those chips.

  http://thread.gmane.org/gmane.linux.ide/17820
  http://thread.gmane.org/gmane.linux.ide/17516
  https://bugzilla.novell.com/show_bug.cgi?id=263893

Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Matí-as Alejandro Torres <torresmat@gmail.com>
Cc: Greg K-H <greg@kroah.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 drivers/pci/quirks.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

--- linux-2.6.21.1.orig/drivers/pci/quirks.c
+++ linux-2.6.21.1/drivers/pci/quirks.c
@@ -1737,18 +1737,20 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_N
 			quirk_nvidia_ck804_pcie_aer_ext_cap);
 
 #ifdef CONFIG_PCI_MSI
-/* The Serverworks PCI-X chipset does not support MSI. We cannot easily rely
- * on setting PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually
- * some other busses controlled by the chipset even if Linux is not aware of it.
- * Instead of setting the flag on all busses in the machine, simply disable MSI
- * globally.
+/* Some chipsets do not support MSI. We cannot easily rely on setting
+ * PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually
+ * some other busses controlled by the chipset even if Linux is not
+ * aware of it.  Instead of setting the flag on all busses in the
+ * machine, simply disable MSI globally.
  */
-static void __init quirk_svw_msi(struct pci_dev *dev)
+static void __init quirk_disable_all_msi(struct pci_dev *dev)
 {
 	pci_no_msi();
 	printk(KERN_WARNING "PCI: MSI quirk detected. MSI deactivated.\n");
 }
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_svw_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi);
 
 /* Disable MSI on chipsets that are known to not support it */
 static void __devinit quirk_disable_msi(struct pci_dev *dev)

-- 

[patch 42/69] fix for bugzilla 8426: massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[Chris Wright]

[-- Attachment #1: fix-for-bugzilla-8426-massive-slowdown-on-scsi-cd-dvd-drive-connected-to-mptspi-driver.patch --]
[-- Type: text/plain, Size: 1478 bytes --]

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

From: Doug Chapman <doug.chapman@hp.com>

Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426

A recent code cleanup that moved code from mptscsih to mptspi inadvertently
change the order some code was called.  This caused a massive slowdown (of
150x to 300x) on the CD/DVD drive on the high-end HP Integrity servers.

Signed-off-by: Doug Chapman <doug.chapman@hp.com>
Cc: <Eric.Moore@lsil.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
[chrisw: Why is this not upstream yet?]

 drivers/message/fusion/mptspi.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/drivers/message/fusion/mptspi.c
+++ linux-2.6.21.1/drivers/message/fusion/mptspi.c
@@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct
 	struct _MPT_SCSI_HOST *hd =
 		(struct _MPT_SCSI_HOST *)sdev->host->hostdata;
 	VirtTarget *vtarget = scsi_target(sdev)->hostdata;
-	int ret = mptscsih_slave_configure(sdev);
+	int ret;
+
+	mptspi_initTarget(hd, vtarget, sdev);
+
+	ret = mptscsih_slave_configure(sdev);
 
 	if (ret)
 		return ret;
 
-	mptspi_initTarget(hd, vtarget, sdev);
-
 	ddvprintk((MYIOC_s_INFO_FMT "id=%d min_period=0x%02x"
 		" max_offset=0x%02x max_width=%d\n", hd->ioc->name,
 		sdev->id, spi_min_period(scsi_target(sdev)),

-- 

[patch 43/69] i386: HPET, check if the counter works

[Chris Wright]

[-- Attachment #1: i386-hpet-check-if-the-counter-works.patch --]
[-- Type: text/plain, Size: 1424 bytes --]

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

From: Thomas Gleixner <tglx@linutronix.de>

Some systems have a HPET which is not incrementing, which leads to a
complete hang. Detect it during HPET setup.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
[chrisw: Why is this not upstream yet?]

---
 arch/i386/kernel/hpet.c |   24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

--- linux-2.6.21.1.orig/arch/i386/kernel/hpet.c
+++ linux-2.6.21.1/arch/i386/kernel/hpet.c
@@ -226,7 +226,8 @@ int __init hpet_enable(void)
 {
 	unsigned long id;
 	uint64_t hpet_freq;
-	u64 tmp;
+	u64 tmp, start, now;
+	cycle_t t1;
 
 	if (!is_hpet_capable())
 		return 0;
@@ -273,6 +274,27 @@ int __init hpet_enable(void)
 	/* Start the counter */
 	hpet_start_counter();
 
+	/* Verify whether hpet counter works */
+	t1 = read_hpet();
+	rdtscll(start);
+
+	/*
+	 * We don't know the TSC frequency yet, but waiting for
+	 * 200000 TSC cycles is safe:
+	 * 4 GHz == 50us
+	 * 1 GHz == 200us
+	 */
+	do {
+		rep_nop();
+		rdtscll(now);
+	} while ((now - start) < 200000UL);
+
+	if (t1 == read_hpet()) {
+		printk(KERN_WARNING
+		       "HPET counter not counting. HPET disabled\n");
+		goto out_nohpet;
+	}
+
 	/* Initialize and register HPET clocksource
 	 *
 	 * hpet period is in femto seconds per cycle

-- 

Re: [patch 43/69] i386: HPET, check if the counter works

[Thomas Gleixner]

On Mon, 2007-05-21 at 12:16 -0700, Chris Wright wrote:
> plain text document attachment
> (i386-hpet-check-if-the-counter-works.patch)
> -stable review patch.  If anyone has any objections, please let us know.
> ---------------------
> 
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Some systems have a HPET which is not incrementing, which leads to a
> complete hang. Detect it during HPET setup.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> ---
> [chrisw: Why is this not upstream yet?]

Dunno. There is another one missing:

------------------------------->
Subject: NOHZ: Rate limit the local softirq pending warning output

The warning in the NOHZ code, which triggers when a CPU goes idle with
softirqs pending can fill up the logs quite quickly. Rate limit the
output until we found the root cause of that problem.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Index: linux-2.6.21/kernel/time/tick-sched.c
===================================================================
--- linux-2.6.21.orig/kernel/time/tick-sched.c
+++ linux-2.6.21/kernel/time/tick-sched.c
@@ -167,9 +167,15 @@ void tick_nohz_stop_sched_tick(void)
 		goto end;
 
 	cpu = smp_processor_id();
-	if (unlikely(local_softirq_pending()))
-		printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
-		       local_softirq_pending());
+	if (unlikely(local_softirq_pending())) {
+		static int ratelimit;
+
+		if (ratelimit < 10) {
+			printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
+			       local_softirq_pending());
+			ratelimit++;
+		}
+	}
 
 	now = ktime_get();
 	/*

Re: [patch 43/69] i386: HPET, check if the counter works

[Thomas Gleixner]

On Mon, 2007-05-21 at 21:58 +0200, Thomas Gleixner wrote:

> Dunno. There is another one missing:

What happened to the maxcpus=1 hard lock prevention patch ?

	tglx

Re: [patch 43/69] i386: HPET, check if the counter works

[Chris Wright]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> What happened to the maxcpus=1 hard lock prevention patch ?

i placed it in the queue for .3.  (primarily due to timing and since it
hadn't hit upstream yet).

Re: [patch 43/69] i386: HPET, check if the counter works

[Thomas Gleixner]

On Mon, 2007-05-21 at 13:33 -0700, Chris Wright wrote:
> * Thomas Gleixner (tglx@linutronix.de) wrote:
> > What happened to the maxcpus=1 hard lock prevention patch ?
> 
> i placed it in the queue for .3.  (primarily due to timing and since it
> hadn't hit upstream yet).

Fair enough.

	tglx

Re: [patch 43/69] i386: HPET, check if the counter works

[Andrew Morton]

On Mon, 21 May 2007 21:58:55 +0200
Thomas Gleixner <tglx@linutronix.de> wrote:

> The warning in the NOHZ code, which triggers when a CPU goes idle with
> softirqs pending can fill up the logs quite quickly. Rate limit the
> output until we found the root cause of that problem.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> Index: linux-2.6.21/kernel/time/tick-sched.c
> ===================================================================
> --- linux-2.6.21.orig/kernel/time/tick-sched.c
> +++ linux-2.6.21/kernel/time/tick-sched.c
> @@ -167,9 +167,15 @@ void tick_nohz_stop_sched_tick(void)
>  		goto end;
>  
>  	cpu = smp_processor_id();
> -	if (unlikely(local_softirq_pending()))
> -		printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> -		       local_softirq_pending());
> +	if (unlikely(local_softirq_pending())) {
> +		static int ratelimit;
> +
> +		if (ratelimit < 10) {
> +			printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> +			       local_softirq_pending());
> +			ratelimit++;
> +		}
> +	}

that's not a "rate" limit.  I resist the temptation to rename it to "limit"
to keep mainline and -stable in sync, and coz it's temporary (we hope).

Re: [patch 43/69] i386: HPET, check if the counter works

[Thomas Gleixner]

On Mon, 2007-05-21 at 14:57 -0700, Andrew Morton wrote:
> On Mon, 21 May 2007 21:58:55 +0200
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > The warning in the NOHZ code, which triggers when a CPU goes idle with
> > softirqs pending can fill up the logs quite quickly. Rate limit the
> > output until we found the root cause of that problem.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > 
> > Index: linux-2.6.21/kernel/time/tick-sched.c
> > ===================================================================
> > --- linux-2.6.21.orig/kernel/time/tick-sched.c
> > +++ linux-2.6.21/kernel/time/tick-sched.c
> > @@ -167,9 +167,15 @@ void tick_nohz_stop_sched_tick(void)
> >  		goto end;
> >  
> >  	cpu = smp_processor_id();
> > -	if (unlikely(local_softirq_pending()))
> > -		printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> > -		       local_softirq_pending());
> > +	if (unlikely(local_softirq_pending())) {
> > +		static int ratelimit;
> > +
> > +		if (ratelimit < 10) {
> > +			printk(KERN_ERR "NOHZ: local_softirq_pending %02x\n",
> > +			       local_softirq_pending());
> > +			ratelimit++;
> > +		}
> > +	}
> 
> that's not a "rate" limit.  I resist the temptation to rename it to "limit"
> to keep mainline and -stable in sync, and coz it's temporary (we hope).

Point taken.

	tglx

Re: [patch 43/69] i386: HPET, check if the counter works

[dean gaudet]

the HPET specification allows for HPETs with *much* lower resolution than 
50us.  in fact Fmin is 10Hz iirc.  (sorry to jump in so late, but i'm 
about a month behind on the list.)

-dean

On Mon, 21 May 2007, Chris Wright wrote:

> -stable review patch.  If anyone has any objections, please let us know.
> ---------------------
> 
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Some systems have a HPET which is not incrementing, which leads to a
> complete hang. Detect it during HPET setup.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> ---
> [chrisw: Why is this not upstream yet?]
> 
> ---
>  arch/i386/kernel/hpet.c |   24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> --- linux-2.6.21.1.orig/arch/i386/kernel/hpet.c
> +++ linux-2.6.21.1/arch/i386/kernel/hpet.c
> @@ -226,7 +226,8 @@ int __init hpet_enable(void)
>  {
>  	unsigned long id;
>  	uint64_t hpet_freq;
> -	u64 tmp;
> +	u64 tmp, start, now;
> +	cycle_t t1;
>  
>  	if (!is_hpet_capable())
>  		return 0;
> @@ -273,6 +274,27 @@ int __init hpet_enable(void)
>  	/* Start the counter */
>  	hpet_start_counter();
>  
> +	/* Verify whether hpet counter works */
> +	t1 = read_hpet();
> +	rdtscll(start);
> +
> +	/*
> +	 * We don't know the TSC frequency yet, but waiting for
> +	 * 200000 TSC cycles is safe:
> +	 * 4 GHz == 50us
> +	 * 1 GHz == 200us
> +	 */
> +	do {
> +		rep_nop();
> +		rdtscll(now);
> +	} while ((now - start) < 200000UL);
> +
> +	if (t1 == read_hpet()) {
> +		printk(KERN_WARNING
> +		       "HPET counter not counting. HPET disabled\n");
> +		goto out_nohpet;
> +	}
> +
>  	/* Initialize and register HPET clocksource
>  	 *
>  	 * hpet period is in femto seconds per cycle
> 
> -- 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [patch 43/69] i386: HPET, check if the counter works

[dean gaudet]

ugh... do not send email before breakfast.  do not send email before 
breakfast.  nevermind :)

-dean

On Tue, 5 Jun 2007, dean gaudet wrote:

> the HPET specification allows for HPETs with *much* lower resolution than 
> 50us.  in fact Fmin is 10Hz iirc.  (sorry to jump in so late, but i'm 
> about a month behind on the list.)
> 
> -dean
> 
> On Mon, 21 May 2007, Chris Wright wrote:
> 
> > -stable review patch.  If anyone has any objections, please let us know.
> > ---------------------
> > 
> > From: Thomas Gleixner <tglx@linutronix.de>
> > 
> > Some systems have a HPET which is not incrementing, which leads to a
> > complete hang. Detect it during HPET setup.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> > ---
> > [chrisw: Why is this not upstream yet?]
> > 
> > ---
> >  arch/i386/kernel/hpet.c |   24 +++++++++++++++++++++++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> > 
> > --- linux-2.6.21.1.orig/arch/i386/kernel/hpet.c
> > +++ linux-2.6.21.1/arch/i386/kernel/hpet.c
> > @@ -226,7 +226,8 @@ int __init hpet_enable(void)
> >  {
> >  	unsigned long id;
> >  	uint64_t hpet_freq;
> > -	u64 tmp;
> > +	u64 tmp, start, now;
> > +	cycle_t t1;
> >  
> >  	if (!is_hpet_capable())
> >  		return 0;
> > @@ -273,6 +274,27 @@ int __init hpet_enable(void)
> >  	/* Start the counter */
> >  	hpet_start_counter();
> >  
> > +	/* Verify whether hpet counter works */
> > +	t1 = read_hpet();
> > +	rdtscll(start);
> > +
> > +	/*
> > +	 * We don't know the TSC frequency yet, but waiting for
> > +	 * 200000 TSC cycles is safe:
> > +	 * 4 GHz == 50us
> > +	 * 1 GHz == 200us
> > +	 */
> > +	do {
> > +		rep_nop();
> > +		rdtscll(now);
> > +	} while ((now - start) < 200000UL);
> > +
> > +	if (t1 == read_hpet()) {
> > +		printk(KERN_WARNING
> > +		       "HPET counter not counting. HPET disabled\n");
> > +		goto out_nohpet;
> > +	}
> > +
> >  	/* Initialize and register HPET clocksource
> >  	 *
> >  	 * hpet period is in femto seconds per cycle
> > 
> > -- 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [patch 43/69] i386: HPET, check if the counter works

[Linus Torvalds]

On Tue, 5 Jun 2007, dean gaudet wrote:
>
> the HPET specification allows for HPETs with *much* lower resolution than 
> 50us.  in fact Fmin is 10Hz iirc.  (sorry to jump in so late, but i'm 
> about a month behind on the list.)

Well, for such a broken HPET, the right thing to do is to just not use it, 
so who cares? It might as well be considered non-incrementing at all.

		Linus

[patch 44/69] ALSA: hda-codec - Fix resume of STAC92xx codecs

[Chris Wright]

[-- Attachment #1: alsa-hda-codec-fix-resume-of-stac92xx-codecs.patch --]
[-- Type: text/plain, Size: 824 bytes --]

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

From: Takashi Iwai <tiwai@suse.de>

Added a missing call to resume mixer controls for STAC92xx codecs.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

---
 sound/pci/hda/patch_sigmatel.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.21.1.orig/sound/pci/hda/patch_sigmatel.c
+++ linux-2.6.21.1/sound/pci/hda/patch_sigmatel.c
@@ -1751,6 +1751,7 @@ static int stac92xx_resume(struct hda_co
 
 	stac92xx_init(codec);
 	stac92xx_set_config_regs(codec);
+	snd_hda_resume_ctls(codec, spec->mixer);
 	for (i = 0; i < spec->num_mixers; i++)
 		snd_hda_resume_ctls(codec, spec->mixers[i]);
 	if (spec->multiout.dig_out_nid)

-- 

[patch 45/69] IPMI: fix SI address space settings

[Chris Wright]

[-- Attachment #1: ipmi-fix-si-address-space-settings.patch --]
[-- Type: text/plain, Size: 1194 bytes --]

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

From: Corey Minyard <minyard@acm.org>

Fix a rather obvious error that Patrick found in the setup routines.  Need to
set the proper address space in the ACPI case.

Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Patrick Schoeller <Patrick.Schoeller@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 drivers/char/ipmi/ipmi_si_intf.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.21.1.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.21.1/drivers/char/ipmi/ipmi_si_intf.c
@@ -1859,10 +1859,10 @@ static __devinit int try_init_acpi(struc
 
 	if (spmi->addr.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
 		info->io_setup = mem_setup;
-		info->io.addr_type = IPMI_IO_ADDR_SPACE;
+		info->io.addr_type = IPMI_MEM_ADDR_SPACE;
 	} else if (spmi->addr.space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
 		info->io_setup = port_setup;
-		info->io.addr_type = IPMI_MEM_ADDR_SPACE;
+		info->io.addr_type = IPMI_IO_ADDR_SPACE;
 	} else {
 		kfree(info);
 		printk("ipmi_si: Unknown ACPI I/O Address type\n");

-- 

[patch 46/69] [PATCH] x86_64 : Fix vgettimeofday()

[Chris Wright]

[-- Attachment #1: x86_64-fix-vgettimeofday.patch --]
[-- Type: text/plain, Size: 830 bytes --]

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

From: Eric Dumazet <dada1@cosmosbay.com>

vgettimeofday() may return some bad timeval values, (tv_usec = 1000000), because of a wrong compare.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86_64/kernel/vsyscall.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/arch/x86_64/kernel/vsyscall.c
+++ linux-2.6.21.1/arch/x86_64/kernel/vsyscall.c
@@ -132,7 +132,7 @@ static __always_inline void do_vgettimeo
 
 	/* convert to usecs and add to timespec: */
 	tv->tv_usec += nsec_delta / NSEC_PER_USEC;
-	while (tv->tv_usec > USEC_PER_SEC) {
+	while (tv->tv_usec >= USEC_PER_SEC) {
 		tv->tv_sec += 1;
 		tv->tv_usec -= USEC_PER_SEC;
 	}

-- 

[patch 47/69] IPV6: Send ICMPv6 error on scope violations.

[Chris Wright]

[-- Attachment #1: ipv6-send-icmpv6-error-on-scope-violations.patch --]
[-- Type: text/plain, Size: 1335 bytes --]

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

From: David L Stevens <dlstevens@us.ibm.com>

When an IPv6 router is forwarding a packet with a link-local scope source
address off-link, RFC 4007 requires it to send an ICMPv6 destination
unreachable with code 2 ("not neighbor"), but Linux doesn't. Fix below.

Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/ipv6/ip6_output.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/net/ipv6/ip6_output.c
+++ linux-2.6.21.1/net/ipv6/ip6_output.c
@@ -449,10 +449,17 @@ int ip6_forward(struct sk_buff *skb)
 		 */
 		if (xrlim_allow(dst, 1*HZ))
 			ndisc_send_redirect(skb, n, target);
-	} else if (ipv6_addr_type(&hdr->saddr)&(IPV6_ADDR_MULTICAST|IPV6_ADDR_LOOPBACK
-						|IPV6_ADDR_LINKLOCAL)) {
+	} else {
+		int addrtype = ipv6_addr_type(&hdr->saddr);
+
 		/* This check is security critical. */
-		goto error;
+		if (addrtype & (IPV6_ADDR_MULTICAST|IPV6_ADDR_LOOPBACK))
+			goto error;
+		if (addrtype & IPV6_ADDR_LINKLOCAL) {
+			icmpv6_send(skb, ICMPV6_DEST_UNREACH,
+				ICMPV6_NOT_NEIGHBOUR, 0, skb->dev);
+			goto error;
+		}
 	}
 
 	if (skb->len > dst_mtu(dst)) {

-- 

[patch 48/69] IPV6: Do no rely on skb->dst before it is assigned.

[Chris Wright]

[-- Attachment #1: ipv6-do-no-rely-on-skb-dst-before-it-is-assigned.patch --]
[-- Type: text/plain, Size: 2244 bytes --]

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

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Because skb->dst is assigned in ip6_route_input(), it is really
bad to use it in hop-by-hop option handler(s).

Closes: Bug #8450 (Eric Sesterhenn <snakebyte@gmx.de>)
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/ipv6/exthdrs.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/net/ipv6/exthdrs.c
+++ linux-2.6.21.1/net/ipv6/exthdrs.c
@@ -652,6 +652,14 @@ EXPORT_SYMBOL_GPL(ipv6_invert_rthdr);
   Hop-by-hop options.
  **********************************/
 
+/*
+ * Note: we cannot rely on skb->dst before we assign it in ip6_route_input().
+ */
+static inline struct inet6_dev *ipv6_skb_idev(struct sk_buff *skb)
+{
+	return skb->dst ? ip6_dst_idev(skb->dst) : __in6_dev_get(skb->dev);
+}
+
 /* Router Alert as of RFC 2711 */
 
 static int ipv6_hop_ra(struct sk_buff **skbp, int optoff)
@@ -678,25 +686,25 @@ static int ipv6_hop_jumbo(struct sk_buff
 	if (skb->nh.raw[optoff+1] != 4 || (optoff&3) != 2) {
 		LIMIT_NETDEBUG(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt length/alignment %d\n",
 			       skb->nh.raw[optoff+1]);
-		IP6_INC_STATS_BH(ip6_dst_idev(skb->dst),
+		IP6_INC_STATS_BH(ipv6_skb_idev(skb),
 				 IPSTATS_MIB_INHDRERRORS);
 		goto drop;
 	}
 
 	pkt_len = ntohl(*(__be32*)(skb->nh.raw+optoff+2));
 	if (pkt_len <= IPV6_MAXPLEN) {
-		IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), IPSTATS_MIB_INHDRERRORS);
+		IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INHDRERRORS);
 		icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff+2);
 		return 0;
 	}
 	if (skb->nh.ipv6h->payload_len) {
-		IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), IPSTATS_MIB_INHDRERRORS);
+		IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INHDRERRORS);
 		icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff);
 		return 0;
 	}
 
 	if (pkt_len > skb->len - sizeof(struct ipv6hdr)) {
-		IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), IPSTATS_MIB_INTRUNCATEDPKTS);
+		IP6_INC_STATS_BH(ipv6_skb_idev(skb), IPSTATS_MIB_INTRUNCATEDPKTS);
 		goto drop;
 	}
 

-- 

[patch 49/69] IPV6 ROUTE: Assign rt6i_idev for ip6_{prohibit,blk_hole}_entry.

[Chris Wright]

[-- Attachment #1: ipv6-route-assign-rt6i_idev-for-ip6_-prohibit-blk_hole-_entry.patch --]
[-- Type: text/plain, Size: 888 bytes --]

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

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

I think this is less critical, but is also suitable for -stable
release.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/ipv6/addrconf.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-2.6.21.1.orig/net/ipv6/addrconf.c
+++ linux-2.6.21.1/net/ipv6/addrconf.c
@@ -4062,6 +4062,10 @@ int __init addrconf_init(void)
 		return err;
 
 	ip6_null_entry.rt6i_idev = in6_dev_get(&loopback_dev);
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+	ip6_prohibit_entry.rt6i_idev = in6_dev_get(&loopback_dev);
+	ip6_blk_hole_entry.rt6i_idev = in6_dev_get(&loopback_dev);
+#endif
 
 	register_netdevice_notifier(&ipv6_dev_notf);
 

-- 

[patch 50/69] IPV6: Reverse sense of promisc tests in ip6_mc_input

[Chris Wright]

[-- Attachment #1: ipv6-reverse-sense-of-promisc-tests-in-ip6_mc_input.patch --]
[-- Type: text/plain, Size: 955 bytes --]

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

From: Corey Mutter <crm-netdev@mutternet.com>

Reverse the sense of the promiscuous-mode tests in ip6_mc_input(). 

Signed-off-by: Corey Mutter <crm-netdev@mutternet.com>
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/ipv6/ip6_input.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/net/ipv6/ip6_input.c
+++ linux-2.6.21.1/net/ipv6/ip6_input.c
@@ -235,7 +235,7 @@ int ip6_mc_input(struct sk_buff *skb)
 	IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), IPSTATS_MIB_INMCASTPKTS);
 
 	hdr = skb->nh.ipv6h;
-	deliver = likely(!(skb->dev->flags & (IFF_PROMISC|IFF_ALLMULTI))) ||
+	deliver = unlikely(skb->dev->flags & (IFF_PROMISC|IFF_ALLMULTI)) ||
 	    ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, NULL);
 
 	/*

-- 

[patch 51/69] NET_SCHED: prio qdisc boundary condition

[Chris Wright]

[-- Attachment #1: net_sched-prio-qdisc-boundary-condition.patch --]
[-- Type: text/plain, Size: 794 bytes --]

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

From: Jamal Hadi Salim <hadi@cyberus.ca>

This fixes an out-of-boundary condition when the classified
band equals q->bands. Caught by Alexey

Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/sched/sch_prio.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/net/sched/sch_prio.c
+++ linux-2.6.21.1/net/sched/sch_prio.c
@@ -74,7 +74,7 @@ prio_classify(struct sk_buff *skb, struc
 		band = res.classid;
 	}
 	band = TC_H_MIN(band) - 1;
-	if (band > q->bands)
+	if (band >= q->bands)
 		return q->queues[q->prio2band[0]];
 
 	return q->queues[band];

-- 

[patch 52/69] SCTP: Prevent OOPS if hmac modules didnt load

[Chris Wright]

[-- Attachment #1: sctp-prevent-oops-if-hmac-modules-didn-t-load.patch --]
[-- Type: text/plain, Size: 1090 bytes --]

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

From: Vlad Yasevich <vladislav.yasevich@hp.com>

SCTP was checking for NULL when trying to detect hmac
allocation failure where it should have been using IS_ERR.
Also, print a rate limited warning to the log telling the
user what happend.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/sctp/socket.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- linux-2.6.21.1.orig/net/sctp/socket.c
+++ linux-2.6.21.1/net/sctp/socket.c
@@ -4985,7 +4985,12 @@ int sctp_inet_listen(struct socket *sock
 	/* Allocate HMAC for generating cookie. */
 	if (sctp_hmac_alg) {
 		tfm = crypto_alloc_hash(sctp_hmac_alg, 0, CRYPTO_ALG_ASYNC);
-		if (!tfm) {
+		if (IS_ERR(tfm)) {
+			if (net_ratelimit()) {
+				printk(KERN_INFO
+				       "SCTP: failed to load transform for %s: %ld\n",
+					sctp_hmac_alg, PTR_ERR(tfm));
+			}
 			err = -ENOSYS;
 			goto out;
 		}

-- 

[patch 53/69] IPSEC: Check validity of direction in xfrm_policy_byid

[Chris Wright]

[-- Attachment #1: ipsec-check-validity-of-direction-in-xfrm_policy_byid.patch --]
[-- Type: text/plain, Size: 1402 bytes --]

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

From: Herbert Xu <herbert@gondor.apana.org.au>

The function xfrm_policy_byid takes a dir argument but finds the policy
using the index instead.  We only use the dir argument to update the
policy count for that direction.  Since the user can supply any value
for dir, this can corrupt our policy count.

I know this is the problem because a few days ago I was deleting
policies by hand using indicies and accidentally typed in the wrong
direction.  It still deleted the policy and at the time I thought
that was cool.  In retrospect it isn't such a good idea :)

I decided against letting it delete the policy anyway just in case
we ever remove the connection between indicies and direction.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 net/xfrm/xfrm_policy.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-2.6.21.1.orig/net/xfrm/xfrm_policy.c
+++ linux-2.6.21.1/net/xfrm/xfrm_policy.c
@@ -782,6 +782,10 @@ struct xfrm_policy *xfrm_policy_byid(u8 
 	struct hlist_head *chain;
 	struct hlist_node *entry;
 
+	*err = -ENOENT;
+	if (xfrm_policy_id2dir(id) != dir)
+		return NULL;
+
 	*err = 0;
 	write_lock_bh(&xfrm_policy_lock);
 	chain = xfrm_policy_byidx + idx_hash(id);

-- 

[patch 54/69] SPARC64: Add missing cpus_empty() check in hypervisor xcall handling.

[Chris Wright]

[-- Attachment #1: sparc64-add-missing-cpus_empty-check-in-hypervisor-xcall-handling.patch --]
[-- Type: text/plain, Size: 677 bytes --]

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

From: David Miller <davem@davemloft.net>

---
 arch/sparc64/kernel/smp.c |    3 +++
 1 file changed, 3 insertions(+)

--- linux-2.6.21.1.orig/arch/sparc64/kernel/smp.c
+++ linux-2.6.21.1/arch/sparc64/kernel/smp.c
@@ -566,6 +566,9 @@ static void hypervisor_xcall_deliver(u64
 	unsigned long flags, status;
 	int cnt, retries, this_cpu, prev_sent, i;
 
+	if (cpus_empty(mask))
+		return;
+
 	/* We have to do this whole thing with interrupts fully disabled.
 	 * Otherwise if we send an xcall from interrupt context it will
 	 * corrupt both our mondo block and cpu list state.

-- 

[patch 55/69] SPARC64: Fix recursion in PROM tree building.

[Chris Wright]

[-- Attachment #1: sparc64-fix-recursion-in-prom-tree-building.patch --]
[-- Type: text/plain, Size: 1413 bytes --]

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

From: David Miller <davem@davemloft.net>

Use iteration for scanning of PROM node siblings.

Based upon a patch by Greg Onufer, who found this bug.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 arch/sparc64/kernel/prom.c |   19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

--- linux-2.6.21.1.orig/arch/sparc64/kernel/prom.c
+++ linux-2.6.21.1/arch/sparc64/kernel/prom.c
@@ -1555,10 +1555,21 @@ static struct device_node * __init creat
 
 static struct device_node * __init build_tree(struct device_node *parent, phandle node, struct device_node ***nextp)
 {
+	struct device_node *ret = NULL, *prev_sibling = NULL;
 	struct device_node *dp;
 
-	dp = create_node(node, parent);
-	if (dp) {
+	while (1) {
+		dp = create_node(node, parent);
+		if (!dp)
+			break;
+
+		if (prev_sibling)
+			prev_sibling->sibling = dp;
+
+		if (!ret)
+			ret = dp;
+		prev_sibling = dp;
+
 		*(*nextp) = dp;
 		*nextp = &dp->allnext;
 
@@ -1567,10 +1578,10 @@ static struct device_node * __init build
 
 		dp->child = build_tree(dp, prom_getchild(node), nextp);
 
-		dp->sibling = build_tree(parent, prom_getsibling(node), nextp);
+		node = prom_getsibling(node);
 	}
 
-	return dp;
+	return ret;
 }
 
 void __init prom_build_devicetree(void)

-- 

[patch 56/69] SERIAL SUNHV: Add an ID string.

[Chris Wright]

[-- Attachment #1: serial-sunhv-add-an-id-string.patch --]
[-- Type: text/plain, Size: 710 bytes --]

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

From: David Miller <davem@davemloft.net>

The 'compatible' property can be SUNW,sun4v-console as
well as 'qcn'.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/serial/sunhv.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-2.6.21.1.orig/drivers/serial/sunhv.c
+++ linux-2.6.21.1/drivers/serial/sunhv.c
@@ -493,6 +493,10 @@ static struct of_device_id hv_match[] = 
 		.name = "console",
 		.compatible = "qcn",
 	},
+	{
+		.name = "console",
+		.compatible = "SUNW,sun4v-console",
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, hv_match);

-- 

[patch 57/69] SPARC64: Bump PROMINTR_MAX to 32.

[Chris Wright]

[-- Attachment #1: sparc64-bump-promintr_max-to-32.patch --]
[-- Type: text/plain, Size: 807 bytes --]

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

From: David Miller <davem@davemloft.net>

Some devices have more than 15 which was the previous
setting.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 include/asm-sparc64/openprom.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/include/asm-sparc64/openprom.h
+++ linux-2.6.21.1/include/asm-sparc64/openprom.h
@@ -177,7 +177,7 @@ struct linux_nodeops {
 /* More fun PROM structures for device probing. */
 #define PROMREG_MAX     24
 #define PROMVADDR_MAX   16
-#define PROMINTR_MAX    15
+#define PROMINTR_MAX    32
 
 struct linux_prom_registers {
 	unsigned which_io;	/* hi part of physical address			*/

-- 

[patch 58/69] SPARC64: Be more resiliant with PCI I/O space regs.

[Chris Wright]

[-- Attachment #1: sparc64-be-more-resiliant-with-pci-i-o-space-regs.patch --]
[-- Type: text/plain, Size: 837 bytes --]

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

From: David Miller <davem@davemloft.net>

If we miss on the ranges, just toss the translation up to the parent
instead of failing.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 arch/sparc64/kernel/of_device.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- linux-2.6.21.1.orig/arch/sparc64/kernel/of_device.c
+++ linux-2.6.21.1/arch/sparc64/kernel/of_device.c
@@ -508,6 +508,13 @@ static int __init build_one_resource(str
 			return 0;
 	}
 
+	/* When we miss an I/O space match on PCI, just pass it up
+	 * to the next PCI bridge and/or controller.
+	 */
+	if (!strcmp(bus->name, "pci") &&
+	    (addr[0] & 0x03000000) == 0x01000000)
+		return 0;
+
 	return 1;
 }
 

-- 

[patch 59/69] sky2: allow 88E8056

[Chris Wright]

[-- Attachment #1: sky2-88e8056-allow.patch --]
[-- Type: text/plain, Size: 1147 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

It looks like the problems of Gigabyte 88E8056 are unique to that chip
motherboard and maybe fixable by EEPROM update.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/sky2.c |    3 ---
 1 file changed, 3 deletions(-)

--- linux-2.6.21.1.orig/drivers/net/sky2.c
+++ linux-2.6.21.1/drivers/net/sky2.c
@@ -123,10 +123,7 @@ static const struct pci_device_id sky2_i
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361) }, /* 88E8050 */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4362) }, /* 88E8053 */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4363) }, /* 88E8055 */
-#ifdef broken
-	/* This device causes data corruption problems that are not resolved */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4364) }, /* 88E8056 */
-#endif
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4366) }, /* 88EC036 */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4367) }, /* 88EC032 */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4368) }, /* 88EC034 */

-- 

[patch 60/69] sky2: 88e8071 support not ready

[Chris Wright]

[-- Attachment #1: sky2-88e8071-support-not-ready.patch --]
[-- Type: text/plain, Size: 933 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

The driver is not ready to support 88e8071 chip, it requires several
more changes (not done yet). If this chip is present, system will hang on boot.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>

---
 drivers/net/sky2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.21.1.orig/drivers/net/sky2.c
+++ linux-2.6.21.1/drivers/net/sky2.c
@@ -129,7 +129,7 @@ static const struct pci_device_id sky2_i
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4368) }, /* 88EC034 */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4369) }, /* 88EC042 */
 	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436A) }, /* 88E8058 */
-	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+//	{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
 	{ 0 }
 };
 

-- 

[patch 61/69] skge: crash on shutdown/suspend

[Chris Wright]

[-- Attachment #1: skge-shutdown.patch --]
[-- Type: text/plain, Size: 1318 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

If device fails during module startup for some reason (like unsupported chip
version) then driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/skge.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- linux-2.6.21.1.orig/drivers/net/skge.c
+++ linux-2.6.21.1/drivers/net/skge.c
@@ -3794,6 +3794,9 @@ static int skge_suspend(struct pci_dev *
 	struct skge_hw *hw  = pci_get_drvdata(pdev);
 	int i, err, wol = 0;
 
+	if (!hw)
+		return 0;
+
 	err = pci_save_state(pdev);
 	if (err)
 		return err;
@@ -3822,6 +3825,9 @@ static int skge_resume(struct pci_dev *p
 	struct skge_hw *hw  = pci_get_drvdata(pdev);
 	int i, err;
 
+	if (!hw)
+		return 0;
+
 	err = pci_set_power_state(pdev, PCI_D0);
 	if (err)
 		goto out;
@@ -3860,6 +3866,9 @@ static void skge_shutdown(struct pci_dev
 	struct skge_hw *hw  = pci_get_drvdata(pdev);
 	int i, wol = 0;
 
+	if (!hw)
+		return;
+
 	for (i = 0; i < hw->ports; i++) {
 		struct net_device *dev = hw->dev[i];
 		struct skge_port *skge = netdev_priv(dev);

-- 

[patch 62/69] sky2: fix oops on shutdown

[Chris Wright]

[-- Attachment #1: sky2-fix-oops-on-shutdown.patch --]
[-- Type: text/plain, Size: 1443 bytes --]

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

From: Stephen Hemminger <shemminger@linux-foundation.org>

If the device fails during module startup for some reason like unsupported chip
version then the driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 drivers/net/sky2.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- linux-2.6.21.1.orig/drivers/net/sky2.c
+++ linux-2.6.21.1/drivers/net/sky2.c
@@ -3719,6 +3719,7 @@ err_out_free_regions:
 	pci_release_regions(pdev);
 	pci_disable_device(pdev);
 err_out:
+	pci_set_drvdata(pdev, NULL);
 	return err;
 }
 
@@ -3771,6 +3772,9 @@ static int sky2_suspend(struct pci_dev *
 	struct sky2_hw *hw = pci_get_drvdata(pdev);
 	int i, wol = 0;
 
+	if (!hw)
+		return 0;
+
 	del_timer_sync(&hw->idle_timer);
 	netif_poll_disable(hw->dev[0]);
 
@@ -3802,6 +3806,9 @@ static int sky2_resume(struct pci_dev *p
 	struct sky2_hw *hw = pci_get_drvdata(pdev);
 	int i, err;
 
+	if (!hw)
+		return 0;
+
 	err = pci_set_power_state(pdev, PCI_D0);
 	if (err)
 		goto out;
@@ -3848,6 +3855,9 @@ static void sky2_shutdown(struct pci_dev
 	struct sky2_hw *hw = pci_get_drvdata(pdev);
 	int i, wol = 0;
 
+	if (!hw)
+		return;
+
 	del_timer_sync(&hw->idle_timer);
 	netif_poll_disable(hw->dev[0]);
 

-- 

[patch 63/69] USB HID: hiddev - fix race between hiddev_send_event() and hiddev_release()

[Chris Wright]

[-- Attachment #1: usb-hid-hiddev-fix-race-between-hiddev_send_event-and-hiddev_release.patch --]
[-- Type: text/plain, Size: 2717 bytes --]

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

From: Jiri Kosina <jkosina@suse.cz>

USB HID: hiddev - fix race between hiddev_send_event() and hiddev_release()
    
There is a small race window in which hiddev_release() could corrupt the
list that is being processed for new event in hiddev_send_event().
Synchronize the operations over this list.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
(in Linus' tree as cdcb44e87bedcf5070eece61f89f9373a3810031)

---
 drivers/usb/input/hiddev.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- linux-2.6.21.1.orig/drivers/usb/input/hiddev.c
+++ linux-2.6.21.1/drivers/usb/input/hiddev.c
@@ -51,6 +51,7 @@ struct hiddev {
 	wait_queue_head_t wait;
 	struct hid_device *hid;
 	struct list_head list;
+	spinlock_t list_lock;
 };
 
 struct hiddev_list {
@@ -161,7 +162,9 @@ static void hiddev_send_event(struct hid
 {
 	struct hiddev *hiddev = hid->hiddev;
 	struct hiddev_list *list;
+	unsigned long flags;
 
+	spin_lock_irqsave(&hiddev->list_lock, flags);
 	list_for_each_entry(list, &hiddev->list, node) {
 		if (uref->field_index != HID_FIELD_INDEX_NONE ||
 		    (list->flags & HIDDEV_FLAG_REPORT) != 0) {
@@ -171,6 +174,7 @@ static void hiddev_send_event(struct hid
 			kill_fasync(&list->fasync, SIGIO, POLL_IN);
 		}
 	}
+	spin_unlock_irqrestore(&hiddev->list_lock, flags);
 
 	wake_up_interruptible(&hiddev->wait);
 }
@@ -235,9 +239,13 @@ static int hiddev_fasync(int fd, struct 
 static int hiddev_release(struct inode * inode, struct file * file)
 {
 	struct hiddev_list *list = file->private_data;
+	unsigned long flags;
 
 	hiddev_fasync(-1, file, 0);
+
+	spin_lock_irqsave(&list->hiddev->list_lock, flags);
 	list_del(&list->node);
+	spin_unlock_irqrestore(&list->hiddev->list_lock, flags);
 
 	if (!--list->hiddev->open) {
 		if (list->hiddev->exist)
@@ -257,6 +265,7 @@ static int hiddev_release(struct inode *
 static int hiddev_open(struct inode *inode, struct file *file)
 {
 	struct hiddev_list *list;
+	unsigned long flags;
 
 	int i = iminor(inode) - HIDDEV_MINOR_BASE;
 
@@ -267,7 +276,11 @@ static int hiddev_open(struct inode *ino
 		return -ENOMEM;
 
 	list->hiddev = hiddev_table[i];
+
+	spin_lock_irqsave(&list->hiddev->list_lock, flags);
 	list_add_tail(&list->node, &hiddev_table[i]->list);
+	spin_unlock_irqrestore(&list->hiddev->list_lock, flags);
+
 	file->private_data = list;
 
 	if (!list->hiddev->open++)
@@ -773,6 +786,7 @@ int hiddev_connect(struct hid_device *hi
 
 	init_waitqueue_head(&hiddev->wait);
 	INIT_LIST_HEAD(&hiddev->list);
+	spin_lock_init(&hiddev->list_lock);
 	hiddev->hid = hid;
 	hiddev->exist = 1;
 

-- 

[patch 64/69] JFS: Fix race waking up jfsIO kernel thread

[Chris Wright]

[-- Attachment #1: jfs-fix-race-waking-up-jfsio-kernel-thread.patch --]
[-- Type: text/plain, Size: 1138 bytes --]

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

From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>

It's possible for a journal I/O request to be added to the log_redrive
queue and the jfsIO thread to be awakened after the thread releases
log_redrive_lock but before it sets its state to TASK_INTERRUPTIBLE.

The jfsIO thread should set the state before giving up the spinlock, so
the waking thread will really wake it.

Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 fs/jfs/jfs_logmgr.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.21.1.orig/fs/jfs/jfs_logmgr.c
+++ linux-2.6.21.1/fs/jfs/jfs_logmgr.c
@@ -2354,12 +2354,13 @@ int jfsIOWait(void *arg)
 			lbmStartIO(bp);
 			spin_lock_irq(&log_redrive_lock);
 		}
-		spin_unlock_irq(&log_redrive_lock);
 
 		if (freezing(current)) {
+			spin_unlock_irq(&log_redrive_lock);
 			refrigerator();
 		} else {
 			set_current_state(TASK_INTERRUPTIBLE);
+			spin_unlock_irq(&log_redrive_lock);
 			schedule();
 			current->state = TASK_RUNNING;
 		}

-- 

[patch 65/69] NETFILTER: {ip,nf}_conntrack: fix use-after-free in helper destroy callback invocation

[Chris Wright]

[-- Attachment #1: netfilter-ip-nf-_conntrack-fix-use-after-free-in-helper-destroy-callback-invocation.patch --]
[-- Type: text/plain, Size: 3891 bytes --]

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

From: Patrick McHardy <kaber@trash.net>

When the helper module is removed for a master connection that has a
fulfilled expectation, but has already timed out and got removed from
the hash tables, nf_conntrack_helper_unregister can't find the master
connection to unset the helper, causing a use-after-free when the
expected connection is destroyed and releases the last reference to
the master.

The helper destroy callback was introduced for the PPtP helper to clean
up expectations and expected connections when the master connection
times out, but doing this from destroy_conntrack only works for
unfulfilled expectations since expected connections hold a reference
to the master, preventing its destruction. Move the destroy callback to
the timeout function, which fixes both problems.

Reported/tested by Gabor Burjan <buga@buvoshetes.hu>.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
commit 441f15ce23ef5c4d149b7e7985f63c1ddd334c45
tree 8783e067803def0fc2773ef3515190143ac47320
parent 8d8b10482fffcb72b15515231bb942e2ad6395c9
author Patrick McHardy <kaber@trash.net> Wed, 16 May 2007 18:52:36 +0200
committer Patrick McHardy <kaber@trash.net> Wed, 16 May 2007 18:52:36 +0200

 net/ipv4/netfilter/ip_conntrack_core.c |   10 +++++-----
 net/netfilter/nf_conntrack_core.c      |    8 ++++----
 2 files changed, 9 insertions(+), 9 deletions(-)

--- linux-2.6.21.1.orig/net/ipv4/netfilter/ip_conntrack_core.c
+++ linux-2.6.21.1/net/ipv4/netfilter/ip_conntrack_core.c
@@ -302,7 +302,6 @@ destroy_conntrack(struct nf_conntrack *n
 {
 	struct ip_conntrack *ct = (struct ip_conntrack *)nfct;
 	struct ip_conntrack_protocol *proto;
-	struct ip_conntrack_helper *helper;
 	typeof(ip_conntrack_destroyed) destroyed;
 
 	DEBUGP("destroy_conntrack(%p)\n", ct);
@@ -312,10 +311,6 @@ destroy_conntrack(struct nf_conntrack *n
 	ip_conntrack_event(IPCT_DESTROY, ct);
 	set_bit(IPS_DYING_BIT, &ct->status);
 
-	helper = ct->helper;
-	if (helper && helper->destroy)
-		helper->destroy(ct);
-
 	/* To make sure we don't get any weird locking issues here:
 	 * destroy_conntrack() MUST NOT be called with a write lock
 	 * to ip_conntrack_lock!!! -HW */
@@ -356,6 +351,11 @@ destroy_conntrack(struct nf_conntrack *n
 static void death_by_timeout(unsigned long ul_conntrack)
 {
 	struct ip_conntrack *ct = (void *)ul_conntrack;
+	struct ip_conntrack_helper *helper;
+
+	helper = ct->helper;
+	if (helper && helper->destroy)
+		helper->destroy(ct);
 
 	write_lock_bh(&ip_conntrack_lock);
 	/* Inside lock so preempt is disabled on module removal path.
--- linux-2.6.21.1.orig/net/netfilter/nf_conntrack_core.c
+++ linux-2.6.21.1/net/netfilter/nf_conntrack_core.c
@@ -315,7 +315,6 @@ static void
 destroy_conntrack(struct nf_conntrack *nfct)
 {
 	struct nf_conn *ct = (struct nf_conn *)nfct;
-	struct nf_conn_help *help = nfct_help(ct);
 	struct nf_conntrack_l3proto *l3proto;
 	struct nf_conntrack_l4proto *l4proto;
 	typeof(nf_conntrack_destroyed) destroyed;
@@ -327,9 +326,6 @@ destroy_conntrack(struct nf_conntrack *n
 	nf_conntrack_event(IPCT_DESTROY, ct);
 	set_bit(IPS_DYING_BIT, &ct->status);
 
-	if (help && help->helper && help->helper->destroy)
-		help->helper->destroy(ct);
-
 	/* To make sure we don't get any weird locking issues here:
 	 * destroy_conntrack() MUST NOT be called with a write lock
 	 * to nf_conntrack_lock!!! -HW */
@@ -375,6 +371,10 @@ destroy_conntrack(struct nf_conntrack *n
 static void death_by_timeout(unsigned long ul_conntrack)
 {
 	struct nf_conn *ct = (void *)ul_conntrack;
+	struct nf_conn_help *help = nfct_help(ct);
+
+	if (help && help->helper && help->helper->destroy)
+		help->helper->destroy(ct);
 
 	write_lock_bh(&nf_conntrack_lock);
 	/* Inside lock so preempt is disabled on module removal path.

-- 

[patch 66/69] CPUFREQ: Support rev H AMD64s in powernow-k8

[Chris Wright]

[-- Attachment #1: support-rev-h-amd64s-in-powernow-k8.patch --]
[-- Type: text/plain, Size: 1424 bytes --]

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

From: Dave Jones <davej@redhat.com>

---
 arch/i386/kernel/cpu/cpufreq/powernow-k8.c |    2 +-
 arch/i386/kernel/cpu/cpufreq/powernow-k8.h |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
+++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
@@ -521,7 +521,7 @@ static int check_supported_cpu(unsigned 
 
 	if ((eax & CPUID_XFAM) == CPUID_XFAM_K8) {
 		if (((eax & CPUID_USE_XFAM_XMOD) != CPUID_USE_XFAM_XMOD) ||
-		    ((eax & CPUID_XMOD) > CPUID_XMOD_REV_G)) {
+		    ((eax & CPUID_XMOD) > CPUID_XMOD_REV_H)) {
 			printk(KERN_INFO PFX "Processor cpuid %x not supported\n", eax);
 			goto out;
 		}
--- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/powernow-k8.h
+++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/powernow-k8.h
@@ -46,8 +46,8 @@ struct powernow_k8_data {
 #define CPUID_XFAM			0x0ff00000	/* extended family */
 #define CPUID_XFAM_K8			0
 #define CPUID_XMOD			0x000f0000	/* extended model */
-#define CPUID_XMOD_REV_G		0x00060000
-#define CPUID_XFAM_10H 			0x00100000	/* family 0x10 */
+#define CPUID_XMOD_REV_H		0x00070000
+#define CPUID_XFAM_10H			0x00100000	/* family 0x10 */
 #define CPUID_USE_XFAM_XMOD		0x00000f00
 #define CPUID_GET_MAX_CAPABILITIES	0x80000000
 #define CPUID_FREQ_VOLT_CAPABILITIES	0x80000007

-- 

[patch 67/69] CPUFREQ: Correct revision mask for powernow-k8

[Chris Wright]

[-- Attachment #1: correct-revision-mask-for-powernow-k8.patch --]
[-- Type: text/plain, Size: 1798 bytes --]

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

From: Dave Jones <davej@redhat.com>

Mark Langsdorf points out that the correct define for this
revision bump is 0x80000.  Also to save us having to keep
renaming the #define, give it a more meaningful name.

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/i386/kernel/cpu/cpufreq/powernow-k8.c |    2 +-
 arch/i386/kernel/cpu/cpufreq/powernow-k8.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
index 5c715f1..4ade55c 100644
--- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
@@ -521,7 +521,7 @@ static int check_supported_cpu(unsigned int cpu)
 
 	if ((eax & CPUID_XFAM) == CPUID_XFAM_K8) {
 		if (((eax & CPUID_USE_XFAM_XMOD) != CPUID_USE_XFAM_XMOD) ||
-		    ((eax & CPUID_XMOD) > CPUID_XMOD_REV_H)) {
+		    ((eax & CPUID_XMOD) > CPUID_XMOD_REV_MASK)) {
 			printk(KERN_INFO PFX "Processor cpuid %x not supported\n", eax);
 			goto out;
 		}
diff --git a/arch/i386/kernel/cpu/cpufreq/powernow-k8.h b/arch/i386/kernel/cpu/cpufreq/powernow-k8.h
index ae2d9da..b06c812 100644
--- a/arch/i386/kernel/cpu/cpufreq/powernow-k8.h
+++ b/arch/i386/kernel/cpu/cpufreq/powernow-k8.h
@@ -46,7 +46,7 @@ struct powernow_k8_data {
 #define CPUID_XFAM			0x0ff00000	/* extended family */
 #define CPUID_XFAM_K8			0
 #define CPUID_XMOD			0x000f0000	/* extended model */
-#define CPUID_XMOD_REV_H		0x00070000
+#define CPUID_XMOD_REV_MASK		0x00080000
 #define CPUID_XFAM_10H			0x00100000	/* family 0x10 */
 #define CPUID_USE_XFAM_XMOD		0x00000f00
 #define CPUID_GET_MAX_CAPABILITIES	0x80000000

-- 

[patch 68/69] CPUFREQ: powernow-k7: fix MHz rounding issue with perflib

[Chris Wright]

[-- Attachment #1: cpufreq-powernow-k7-fix-mhz-rounding-issue-with-perflib.patch --]
[-- Type: text/plain, Size: 4511 bytes --]

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

From: Daniel Drake <dsd@gentoo.org>

When the PST tables are broken, powernow-k7 uses ACPI's processor_perflib to
deduce the available frequency multipliers from the _PSS tables.

Upon frequency change, processor_perflib performs some verification on the
frequency (checks that it's within allowable bounds).

powernow-k7 deals with absolute frequencies in KHz, whereas perflib only
deals with MHz values. When performing the above verification, perflib
multiplies the MHz values by 1000 to obtain the KHz value.

We then end up with situations like the following:
 - powernow-k7 multiplies the multiplier by the FSB, and obtains a value
   such as 1266768 KHz
 - perflib belives the same state has frequency of 1266 MHz
 - acpi_processor_ppc_notifier calls cpufreq_verify_within_limits to verify
   that 1266768 is in the allowable range of 0 to 1266000 (i.e. 1266 * 1000)
 - it's not, so that frequency is rejected
 - the maximum CPU frequency is not reachable

This patch solves the problem by rounding up the MHz values stored in perflib's
tables. Additionally it corrects a broken URL.

It also fixes http://bugzilla.kernel.org/show_bug.cgi?id=8255 although this
case is a bit different: the frequencies in the _PSS tables are wildly wrong,
but we get better results if we force ACPI to respect the fsb * multiplier
calculations (even though it seems that the multiplier values aren't entirely
correct either).

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 arch/i386/kernel/cpu/cpufreq/powernow-k7.c |   36 ++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 8 deletions(-)

--- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
+++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
@@ -341,15 +341,17 @@ static int powernow_acpi_init(void)
 	pc.val = (unsigned long) acpi_processor_perf->states[0].control;
 	for (i = 0; i < number_scales; i++) {
 		u8 fid, vid;
-		unsigned int speed;
+		struct acpi_processor_px *state =
+			&acpi_processor_perf->states[i];
+		unsigned int speed, speed_mhz;
 
-		pc.val = (unsigned long) acpi_processor_perf->states[i].control;
+		pc.val = (unsigned long) state->control;
 		dprintk ("acpi:  P%d: %d MHz %d mW %d uS control %08x SGTC %d\n",
 			 i,
-			 (u32) acpi_processor_perf->states[i].core_frequency,
-			 (u32) acpi_processor_perf->states[i].power,
-			 (u32) acpi_processor_perf->states[i].transition_latency,
-			 (u32) acpi_processor_perf->states[i].control,
+			 (u32) state->core_frequency,
+			 (u32) state->power,
+			 (u32) state->transition_latency,
+			 (u32) state->control,
 			 pc.bits.sgtc);
 
 		vid = pc.bits.vid;
@@ -360,6 +362,18 @@ static int powernow_acpi_init(void)
 		powernow_table[i].index |= (vid << 8); /* upper 8 bits */
 
 		speed = powernow_table[i].frequency;
+		speed_mhz = speed / 1000;
+
+		/* processor_perflib will multiply the MHz value by 1000 to
+		 * get a KHz value (e.g. 1266000). However, powernow-k7 works
+		 * with true KHz values (e.g. 1266768). To ensure that all
+		 * powernow frequencies are available, we must ensure that
+		 * ACPI doesn't restrict them, so we round up the MHz value
+		 * to ensure that perflib's computed KHz value is greater than
+		 * or equal to powernow's KHz value.
+		 */
+		if (speed % 1000 > 0)
+			speed_mhz++;
 
 		if ((fid_codes[fid] % 10)==5) {
 			if (have_a0 == 1)
@@ -368,10 +382,16 @@ static int powernow_acpi_init(void)
 
 		dprintk ("   FID: 0x%x (%d.%dx [%dMHz])  "
 			 "VID: 0x%x (%d.%03dV)\n", fid, fid_codes[fid] / 10,
-			 fid_codes[fid] % 10, speed/1000, vid,
+			 fid_codes[fid] % 10, speed_mhz, vid,
 			 mobile_vid_table[vid]/1000,
 			 mobile_vid_table[vid]%1000);
 
+		if (state->core_frequency != speed_mhz) {
+			state->core_frequency = speed_mhz;
+			dprintk("   Corrected ACPI frequency to %d\n",
+				speed_mhz);
+		}
+
 		if (latency < pc.bits.sgtc)
 			latency = pc.bits.sgtc;
 
@@ -602,7 +622,7 @@ static int __init powernow_cpu_init (str
 			result = powernow_acpi_init();
 			if (result) {
 				printk (KERN_INFO PFX "ACPI and legacy methods failed\n");
-				printk (KERN_INFO PFX "See http://www.codemonkey.org.uk/projects/cpufreq/powernow-k7.shtml\n");
+				printk (KERN_INFO PFX "See http://www.codemonkey.org.uk/projects/cpufreq/powernow-k7.html\n");
 			}
 		} else {
 			/* SGTC use the bus clock as timer */

-- 

[patch 69/69] CRYPTO: api: Read module pointer before freeing algorithm

[Chris Wright]

[-- Attachment #1: crypto-api-read-module-pointer-before-freeing-algorithm.patch --]
[-- Type: text/plain, Size: 1023 bytes --]

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

From: Herbert Xu <herbert@gondor.apana.org.au>

The function crypto_mod_put first frees the algorithm and then drops
the reference to its module.  Unfortunately we read the module pointer
which after freeing the algorithm and that pointer sits inside the
object that we just freed.

So this patch reads the module pointer out before we free the object.

Thanks to Luca Tettamanti for reporting this.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 crypto/api.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.21.1.orig/crypto/api.c
+++ linux-2.6.21.1/crypto/api.c
@@ -48,8 +48,10 @@ EXPORT_SYMBOL_GPL(crypto_mod_get);
 
 void crypto_mod_put(struct crypto_alg *alg)
 {
+	struct module *module = alg->cra_module;
+
 	crypto_alg_put(alg);
-	module_put(alg->cra_module);
+	module_put(module);
 }
 EXPORT_SYMBOL_GPL(crypto_mod_put);
 

-- 

Re: [patch 00/69] -stable review

[Andrew Morton]

On Mon, 21 May 2007 12:16:12 -0700
Chris Wright <chrisw@sous-sol.org> wrote:

> This is the start of the stable review cycle for the 2.6.21.2 release.

Gee a lot of these are fixing recently-added regressions :(

Did we fix oprofile on x86_64 yet?  If not, I'd suggest we should
hold off 2.6.21.2 until we have done so.

I assume ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/oprofile-allocation
is what we want.

Re: [stable] [patch 00/69] -stable review

[Chris Wright]

* Andrew Morton (akpm@linux-foundation.org) wrote:
> On Mon, 21 May 2007 12:16:12 -0700
> Chris Wright <chrisw@sous-sol.org> wrote:
> 
> > This is the start of the stable review cycle for the 2.6.21.2 release.
> 
> Gee a lot of these are fixing recently-added regressions :(
> 
> Did we fix oprofile on x86_64 yet?  If not, I'd suggest we should
> hold off 2.6.21.2 until we have done so.

No, we've seen 2 versions of the patch, no word from Andi, and nothing
upstream that I saw.  Andi?

> I assume ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/oprofile-allocation
> is what we want.

Re: [stable] [patch 00/69] -stable review

[Eric Dumazet]

Chris Wright a écrit :
> * Andrew Morton (akpm@linux-foundation.org) wrote:
>> On Mon, 21 May 2007 12:16:12 -0700
>> Chris Wright <chrisw@sous-sol.org> wrote:
>>
>>> This is the start of the stable review cycle for the 2.6.21.2 release.
>> Gee a lot of these are fixing recently-added regressions :(
>>
>> Did we fix oprofile on x86_64 yet?  If not, I'd suggest we should
>> hold off 2.6.21.2 until we have done so.
> 
> No, we've seen 2 versions of the patch, no word from Andi, and nothing
> upstream that I saw.  Andi?
> 

Seems Linus tree includes a fix from Andi, check commit 
6c977aad03a18019015035958c65b6729cd0574c

Probably good enough for 2.6.21.2 ?

Re: [stable] [patch 00/69] -stable review

[Chris Wright]

* Eric Dumazet (dada1@cosmosbay.com) wrote:
> Chris Wright a écrit :
> >* Andrew Morton (akpm@linux-foundation.org) wrote:
> >>On Mon, 21 May 2007 12:16:12 -0700
> >>Chris Wright <chrisw@sous-sol.org> wrote:
> >>
> >>>This is the start of the stable review cycle for the 2.6.21.2 release.
> >>Gee a lot of these are fixing recently-added regressions :(
> >>
> >>Did we fix oprofile on x86_64 yet?  If not, I'd suggest we should
> >>hold off 2.6.21.2 until we have done so.
> >
> >No, we've seen 2 versions of the patch, no word from Andi, and nothing
> >upstream that I saw.  Andi?
> 
> Seems Linus tree includes a fix from Andi, check commit 
> 6c977aad03a18019015035958c65b6729cd0574c

Indeed, it's there now.

thanks,
-chris

Re: [patch 00/69] -stable review

[Adrian Bunk]

On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote:
> On Mon, 21 May 2007 12:16:12 -0700
> Chris Wright <chrisw@sous-sol.org> wrote:
> 
> > This is the start of the stable review cycle for the 2.6.21.2 release.
> 
> Gee a lot of these are fixing recently-added regressions :(
>...

If only it would fix all of them...

Michal's list [1] currently contains 51 different regressions in
2.6.21 compared to 2.6.20 (12 of them were already reported before
2.6.21 was released).

cu
Adrian

[1] http://kernelnewbies.org/known_regressions [2]
[2] the 2.6.21 regressions are listed after the 28 known 2.6.22-rc 
    regressions

-- 

       "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

Re: [patch 00/69] -stable review

[Chuck Ebbert]

Adrian Bunk wrote:
> On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote:
>> On Mon, 21 May 2007 12:16:12 -0700
>> Chris Wright <chrisw@sous-sol.org> wrote:
>>
>>> This is the start of the stable review cycle for the 2.6.21.2 release.
>> Gee a lot of these are fixing recently-added regressions :(
>> ...
> 
> If only it would fix all of them...
> 
> Michal's list [1] currently contains 51 different regressions in
> 2.6.21 compared to 2.6.20 (12 of them were already reported before
> 2.6.21 was released).

Yeah, 2.6.21 seems awfully buggy, and patches to fix many of the bugs
haven't appeared.

Another 2.6.20 update seems to be in order...

Re: [stable] [patch 00/69] -stable review

[Chris Wright]

* Chuck Ebbert (cebbert@redhat.com) wrote:
> Another 2.6.20 update seems to be in order...

Yes, the queue's there, just not ready to go yet.  There's still bits that were 
for sent for to .21 and are applicable to .20 (which I'm wading through ATM).

thanks,
-chris

RE: [patch 00/69] -stable review

[Fortier,Vincent [Montreal]]

> -----Message d'origine-----
> De : linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] De la part de Chuck Ebbert
> Envoyé : 21 mai 2007 18:24
> 
> Adrian Bunk wrote:
> > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote:
> >> On Mon, 21 May 2007 12:16:12 -0700
> >> Chris Wright <chrisw@sous-sol.org> wrote:
> >>
> >>> This is the start of the stable review cycle for the 2.6.21.2 release.
> >> Gee a lot of these are fixing recently-added regressions :( ...
> > 
> > If only it would fix all of them...
> > 
> > Michal's list [1] currently contains 51 different regressions in
> > 2.6.21 compared to 2.6.20 (12 of them were already reported before
> > 2.6.21 was released).
> 
> Yeah, 2.6.21 seems awfully buggy, and patches to fix many of 
> the bugs haven't appeared.
> 
> Another 2.6.20 update seems to be in order...

Hi,

If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both contain also this patch to keep the same behaviour between 2.6.20 -> 2.6.22 kernels regarding paravirt_ops GPL export?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7

Thnx!

- vin

Re: [stable] [patch 00/69] -stable review

[Greg KH]

On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent [Montreal] wrote:
> > -----Message d'origine-----
> > De : linux-kernel-owner@vger.kernel.org 
> > [mailto:linux-kernel-owner@vger.kernel.org] De la part de Chuck Ebbert
> > Envoy? : 21 mai 2007 18:24
> > 
> > Adrian Bunk wrote:
> > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote:
> > >> On Mon, 21 May 2007 12:16:12 -0700
> > >> Chris Wright <chrisw@sous-sol.org> wrote:
> > >>
> > >>> This is the start of the stable review cycle for the 2.6.21.2 release.
> > >> Gee a lot of these are fixing recently-added regressions :( ...
> > > 
> > > If only it would fix all of them...
> > > 
> > > Michal's list [1] currently contains 51 different regressions in
> > > 2.6.21 compared to 2.6.20 (12 of them were already reported before
> > > 2.6.21 was released).
> > 
> > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of 
> > the bugs haven't appeared.
> > 
> > Another 2.6.20 update seems to be in order...
> 
> Hi,
> 
> If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both contain also this patch to keep the same behaviour between 2.6.20 -> 2.6.22 kernels regarding paravirt_ops GPL export?
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7

Why?  Is there an in-kernel use for that export?

thanks,

greg k-h

RE: [stable] [patch 00/69] -stable review

[Fortier,Vincent [Montreal]]

> -----Message d'origine-----
> De : Greg KH [mailto:greg@kroah.com] 
> Envoyé : 22 mai 2007 23:37
> À : Fortier,Vincent [Montreal]
> 
> On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent 
> [Montreal] wrote:
> > > -----Message d'origine-----
> > > De : linux-kernel-owner@vger.kernel.org
> > > [mailto:linux-kernel-owner@vger.kernel.org] De la part de Chuck 
> > > Ebbert Envoy? : 21 mai 2007 18:24
> > > 
> > > Adrian Bunk wrote:
> > > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote:
> > > >> On Mon, 21 May 2007 12:16:12 -0700 Chris Wright 
> > > >> <chrisw@sous-sol.org> wrote:
> > > >>
> > > >>> This is the start of the stable review cycle for the 2.6.21.2 release.
> > > >> Gee a lot of these are fixing recently-added regressions :( ...
> > > > 
> > > > If only it would fix all of them...
> > > > 
> > > > Michal's list [1] currently contains 51 different regressions in
> > > > 2.6.21 compared to 2.6.20 (12 of them were already reported before
> > > > 2.6.21 was released).
> > > 
> > > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of the 
> > > bugs haven't appeared.
> > > 
> > > Another 2.6.20 update seems to be in order...
> > 
> > Hi,
> > 
> > If there is a new stable 2.6.20 / 2.6.21, would it be 
> possible that they both contain also this patch to keep the 
> same behaviour between 2.6.20 -> 2.6.22 kernels regarding 
> paravirt_ops GPL export?
> > 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com
> > mit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7
> 
> Why?  Is there an in-kernel use for that export?

I sincerely dont know... Although:
- * NOTE: CONFIG_PARAVIRT is experimental and the paravirt_ops
- * semantics are subject to change. Hence we only do this
- * internal-only export of this, until it gets sorted out and
- * all lowlevel CPU ops used by modules are separately exported.

Makes me think there was a "good enough" reason to export instead of export GPL and that it "could" be usefull to keep the same behaviour for that same experimental feature under 2.6.20 / 2.6.21.  Although, the "until it gets sorted out" makes me think it might planned to get removed before the end of 2.6.22 

Thnx.

- vin

Re: [stable] [patch 00/69] -stable review

[Greg KH]

On Wed, May 23, 2007 at 07:02:29AM -0400, Fortier,Vincent [Montreal] wrote:
> > -----Message d'origine-----
> > De : Greg KH [mailto:greg@kroah.com] 
> > Envoy? : 22 mai 2007 23:37
> > ? : Fortier,Vincent [Montreal]
> > 
> > On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent 
> > [Montreal] wrote:
> > > > -----Message d'origine-----
> > > > De : linux-kernel-owner@vger.kernel.org
> > > > [mailto:linux-kernel-owner@vger.kernel.org] De la part de Chuck 
> > > > Ebbert Envoy? : 21 mai 2007 18:24
> > > > 
> > > > Adrian Bunk wrote:
> > > > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote:
> > > > >> On Mon, 21 May 2007 12:16:12 -0700 Chris Wright 
> > > > >> <chrisw@sous-sol.org> wrote:
> > > > >>
> > > > >>> This is the start of the stable review cycle for the 2.6.21.2 release.
> > > > >> Gee a lot of these are fixing recently-added regressions :( ...
> > > > > 
> > > > > If only it would fix all of them...
> > > > > 
> > > > > Michal's list [1] currently contains 51 different regressions in
> > > > > 2.6.21 compared to 2.6.20 (12 of them were already reported before
> > > > > 2.6.21 was released).
> > > > 
> > > > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of the 
> > > > bugs haven't appeared.
> > > > 
> > > > Another 2.6.20 update seems to be in order...
> > > 
> > > Hi,
> > > 
> > > If there is a new stable 2.6.20 / 2.6.21, would it be 
> > possible that they both contain also this patch to keep the 
> > same behaviour between 2.6.20 -> 2.6.22 kernels regarding 
> > paravirt_ops GPL export?
> > > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com
> > > mit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7
> > 
> > Why?  Is there an in-kernel use for that export?
> 
> I sincerely dont know... Although:

Then I'd prefer to not make this change to the -stable tree :)

thanks,

greg k-h

Re: [patch 00/69] -stable review

[Chuck Ebbert]

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

What happened to:

"Fix ACPI suspend / device suspend ordering problem"
52ade9b3b97fd3bea42842a056fe0786c28d0555

Re: [patch 00/69] -stable review

[Linus Torvalds]

On Mon, 21 May 2007, Chuck Ebbert wrote:
> 
> What happened to:
> 
> "Fix ACPI suspend / device suspend ordering problem"
> 52ade9b3b97fd3bea42842a056fe0786c28d0555

I would suggest waiting on problem reports for that one a bit longer.

Maybe it fixes everything, and has no downsides. But the problem it fixed 
isn't new, and the order change certainly has the _potential_ to be scary.

Do we have reports of that one fixing a lot of machines? I know of only 
one person it made a difference for..

		Linus

Re: [patch 00/69] -stable review

[Chris Wright]

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Mon, 21 May 2007, Chuck Ebbert wrote:
> > 
> > What happened to:
> > 
> > "Fix ACPI suspend / device suspend ordering problem"
> > 52ade9b3b97fd3bea42842a056fe0786c28d0555
> 
> I would suggest waiting on problem reports for that one a bit longer.

It's queued for the next 21.y stable, to give it a little more time.

thanks,
-chris

Re: [patch 00/69] -stable review

[Linus Torvalds]

On Tue, 22 May 2007, Romano Giannetti wrote:
> 
> It's an useful patch for me. Without it, my sony vaio pcg-fx701 was very
> erratic in resume (kernel 2.6.21.1; it works well with the .17 ubuntu
> kernel). With this patch, I have done 7 cycles flawlessly. Even the
> out-of-tree rtl8180 wireless driver [1] works ok across resumes. 

Ok, good to hear.

> The only problem is that there is an gaping delay of 60 seconds (more or
> less) on resume. I have the syslog trace copied below; could be a timer
> problem? Is it known? (It is scaring because the laptop seems dead
> during this time. I'm not and expert, but it seems here:

It's not known, no, and yeah, that's scary (and 60 seconds is long enough 
that most people would have grown bored and pushed the power button for 
five seconds, having considered the resume a failure).

> [    1.617972] pcmcia: registering new device pcmcia1.0 
> [   61.612517] PM: Writing back config space on device 0000:00:[...]
> 
> ...and time do not advance.

Do you mean that doing "date" twice does not increase the seconds? If so, 
that's almost certainly related to the gaping delay. Which timer do you 
end up using (what does "dmesg | grep clocksource" say)? Does adding 
"clocksource=acpi_pm" to the kernel command line change things?

Also, what does your lspci look like?

		Linus

Re: [patch 00/69] -stable review

[Romano Giannetti]

(changing email. My employer server adds a stupid and malformed
disclaimer, so that vger refuses the post. Oh well. I will no trim the
quot to my original message so that it's here for anyone).

On Tue, 2007-05-22 at 15:07 -0700, Linus Torvalds wrote:
> 
> On Tue, 22 May 2007, Romano Giannetti wrote:
> > 
> > It's an useful patch for me. Without it, my sony vaio pcg-fx701 was very
> > erratic in resume (kernel 2.6.21.1; it works well with the .17 ubuntu
> > kernel). With this patch, I have done 7 cycles flawlessly. Even the
> > out-of-tree rtl8180 wireless driver [1] works ok across resumes. 
> 
> Ok, good to hear.
> 
> > The only problem is that there is an gaping delay of 60 seconds (more or
> > less) on resume. I have the syslog trace copied below; could be a timer
> > problem? Is it known? (It is scaring because the laptop seems dead
> > during this time. I'm not and expert, but it seems here:
> 
> It's not known, no, and yeah, that's scary (and 60 seconds is long enough 
> that most people would have grown bored and pushed the power button for 
> five seconds, having considered the resume a failure).
> 
> > [    1.617972] pcmcia: registering new device pcmcia1.0 
> > [   61.612517] PM: Writing back config space on device 0000:00:[...]
> > 
> > ...and time do not advance.
> 
> Do you mean that doing "date" twice does not increase the seconds? If so, 
> that's almost certainly related to the gaping delay. Which timer do you 
> end up using (what does "dmesg | grep clocksource" say)? Does adding 
> "clocksource=acpi_pm" to the kernel command line change things?
> 

I forgot to mention that I have Ingo cfs patch in. But I had the same
behaviour without, so I do not think it's related.

root@rukbat:/sys/power# dmesg | grep clock
[   19.600060] Time: tsc clocksource has been installed.
[   23.028323] Time: acpi_pm clocksource has been installed.

The "time do not advance was an error of my side... I was basing myself
on the timestamp on the syslog, but then realized that this has nothig
to do with the time at which te message is sent. 

Will try to reboot with clocksource=acpi_pm, althoughI think that this
is the one I'm using. 

> Also, what does your lspci look like?
> 
> 		Linus

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
00:07.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 30)
00:0a.0 CardBus bridge: Texas Instruments PCI1420
00:0a.1 CardBus bridge: Texas Instruments PCI1420
00:0e.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link)
00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC (rev 20)

By the way, suspend to disk (ehem... snapshot/restart) is busted too
(and yes, I have done the echo shutdown > /sys/power/disk thing, he
machine resumes but X no...worked like a charm in 2.6.17.13).

Romano 

Re: [patch 00/69] -stable review

[Paolo Ornati]

On Wed, 23 May 2007 09:09:00 +0200
Romano Giannetti <romano.giannetti@gmail.com> wrote:

> Will try to reboot with clocksource=acpi_pm, althoughI think that this
> is the one I'm using. 

you can see that with:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

-- 
	Paolo Ornati
	Linux 2.6.22-rc2-gd2579053 on x86_64

Re: [patch 00/69] -stable review

[Romano Giannetti]

On Wed, 2007-05-23 at 09:19 +0200, Paolo Ornati wrote:
> On Wed, 23 May 2007 09:09:00 +0200
> Romano Giannetti <romano.giannetti@gmail.com> wrote:
> 
> > Will try to reboot with clocksource=acpi_pm, althoughI think that this
> > is the one I'm using. 
> 
> you can see that with:
> 
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> 

Hmmm:

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm 

So I am using it. 

Thanks

Re: [patch 00/69] -stable review

[Romano Giannetti]

On Tue, 2007-05-22 at 15:07 -0700, Linus Torvalds wrote:
>
> On Tue, 22 May 2007, Romano Giannetti wrote:
> >

> It's not known, no, and yeah, that's scary (and 60 seconds is long enough
> that most people would have grown bored and pushed the power button for
> five seconds, having considered the resume a failure).
>
> > [    1.617972] pcmcia: registering new device pcmcia1.0
> > [   61.612517] PM: Writing back config space on device 0000:00:[...]
> >

I discovered that SysRq-t works during the pause. So I pressed it more
or less halfway the pause; the full result is here:
http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume.txt

It seems that most of the tasks are in

[<c0138931>] refrigerator+0x41/0x60

So, I tried to suspend without any card in the pcmcia slot. Guess what?
I extracted the card and the system did not suspend. Just stopped dead.

Sigh.

	Romano


--
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Romano Giannetti]

(Changing subject to something more informative. You are lost,
original thread is at http://lkml.org/lkml/2007/5/23/38 )

On Thu, 2007-05-24 at 14:06 +0200, Romano Giannetti wrote:
> On Tue, 2007-05-22 at 15:07 -0700, Linus Torvalds wrote:
> >
> > On Tue, 22 May 2007, Romano Giannetti wrote:
> > >
>
> > It's not known, no, and yeah, that's scary (and 60 seconds is long enough
> > that most people would have grown bored and pushed the power button for
> > five seconds, having considered the resume a failure).
> >
> > > [    1.617972] pcmcia: registering new device pcmcia1.0
> > > [   61.612517] PM: Writing back config space on device 0000:00:[...]
> > >

More data. I compiled 2.6.21.2 + the patch "Fix ACPI suspend / device
suspend ordering problem  (52ade9b3b97fd3bea42842a056fe0786c28d0555)

and I discovered that if I do not put the 3Com 3CXEM556B card into the
pcmcia slot, the suspend/resume (and the snapshot/restore) works ok,
without delay at all. It continues to work even with a cardbus wifi in
the slot, so my conclusions are that the probable culprit is restricted
to:

      *  a race when loading the .cis file from userspace
      * the serial_cs or 3c589_cs driver (only when the device is in;
        they are loaded still now and all is working ok)

...what now?
	Romano





--
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Linus Torvalds]

On Thu, 24 May 2007, Romano Giannetti wrote:
> 
> More data. I compiled 2.6.21.2 + the patch "Fix ACPI suspend / device
> suspend ordering problem  (52ade9b3b97fd3bea42842a056fe0786c28d0555)
> 
> and I discovered that if I do not put the 3Com 3CXEM556B card into the
> pcmcia slot, the suspend/resume (and the snapshot/restore) works ok,
> without delay at all.

Ok. That was probably true even before you added the suspend ordering 
patch.

> It continues to work even with a cardbus wifi in the slot, so my 
> conclusions are that the probable culprit is restricted to:
> 
>       *  a race when loading the .cis file from userspace
>       * the serial_cs or 3c589_cs driver (only when the device is in;
>         they are loaded still now and all is working ok)
> 
> ...what now?

Can you compile those two modules with PCMCIA_DEBUG=4?

Something like

	make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4

should do it. You might also enable CONFIG_PCMCIA_DEBUG while you're at 
it. And then the extra debugging output hopefully will narrow down where 
things go south.

		Linus

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Linus Torvalds]

On Thu, 24 May 2007, Linus Torvalds wrote:
> 
> Ok. That was probably true even before you added the suspend ordering 
> patch.

Oh, no it apparently wasn't. I missed your other email that said

   "So, I tried to suspend without any card in the pcmcia slot. Guess what?
    I extracted the card and the system did not suspend. Just stopped dead."

so apparently the patch actually did matter for you. Can you double-check 
and confirm?

		Linus

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 08:52 -0700, Linus Torvalds wrote:
> 
> On Thu, 24 May 2007, Linus Torvalds wrote:
> > 
> > Ok. That was probably true even before you added the suspend ordering 
> > patch.
> 
> Oh, no it apparently wasn't. I missed your other email that said
> 
>    "So, I tried to suspend without any card in the pcmcia slot. Guess what?
>     I extracted the card and the system did not suspend. Just stopped dead."
> 
> so apparently the patch actually did matter for you. Can you double-check 
> and confirm?
> 

Well, I've made a bit of a mess. The setup that has not the delay when
the card is out is a plain 2.6.21.2 (without suspend ordering). 

The lockup ocurred on a 2.6.21.1 WITH the suspend ordering patch, but
was just one time, after I plugged and unplugged the card several time.
Could not reproduce it, however. Puzzled.

Romano 
 

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Linus Torvalds]

On Thu, 24 May 2007, Romano Giannetti wrote:
> 
> Well, I've made a bit of a mess. The setup that has not the delay when
> the card is out is a plain 2.6.21.2 (without suspend ordering). 
> 
> The lockup ocurred on a 2.6.21.1 WITH the suspend ordering patch, but
> was just one time, after I plugged and unplugged the card several time.
> Could not reproduce it, however. Puzzled.

Ok, I'm pretty sure that the suspend ordering doesn't matter at all for 
you.

Occasional lockups on resume is probably a separate issue, and it might 
well be a race, or even just firmware timing bugs.

		Linus

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Linus Torvalds]

On Thu, 24 May 2007, Linus Torvalds wrote:
> 
> Occasional lockups on resume is probably a separate issue, and it might 
> well be a race, or even just firmware timing bugs.

Btw, to solve the 60-second timeout problem, do you actually _need_ to 
have CONFIG_PCMCIA_LOAD_CIS enabled for those cards to work for you? Quite 
likely that's the "firmware" that screws up for you, and it's also not 
totally unlikely that you don't even need it.

			Linus

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 13:35 -0700, Linus Torvalds wrote:
> 
> On Thu, 24 May 2007, Linus Torvalds wrote:
> > 
> > Occasional lockups on resume is probably a separate issue, and it might 
> > well be a race, or even just firmware timing bugs.
> 
> Btw, to solve the 60-second timeout problem, do you actually _need_ to 
> have CONFIG_PCMCIA_LOAD_CIS enabled for those cards to work for you? Quite 
> likely that's the "firmware" that screws up for you, and it's also not 
> totally unlikely that you don't even need it.

I could try to undefine it. As a fast try, I simply removed the .cis
file, and the card do not work (complains it can't find cis file). I do
not remember where, but I read that I need this file --- I think I found
it mentioned in the cardmgr->pccardctl conversion HOWTO. 

Romano 

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 08:28 -0700, Linus Torvalds wrote:
> 

> Can you compile those two modules with PCMCIA_DEBUG=4?
> 
> Something like
> 
> 	make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4
> 
> should do it. You might also enable CONFIG_PCMCIA_DEBUG while you're at 
> it. And then the extra debugging output hopefully will narrow down where 
> things go south.

Compiling now. I had lost a lot of time because at first try it stopped
in ntfs:

  CC [M]  fs/ntfs/super.o
fs/ntfs/super.c: In function ‘init_ntfs_fs’:
fs/ntfs/super.c:3152: error: expected ‘)’ before ‘NTFS_VERSION’
fs/ntfs/super.c: At top level:
fs/ntfs/super.c:3262: error: expected ‘,’ or ‘;’ before ‘NTFS_VERSION’
make[2]: *** [fs/ntfs/super.o] Error 1
make[1]: *** [fs/ntfs] Error 2
make: *** [fs] Error 2
  
I suppose because NTFS_VERSION were defined as EXTRA_CFLAGS too in the Makefile, 
and I corrected it adding a fake #define NTFS_VERSION in super.c. Then I
got to a meeting, and coming back:
  
  CC [M]  fs/xfs/quota/xfs_dquot.o
fs/xfs/quota/xfs_dquot.c:18:17: error: xfs.h: No such file or directory
fs/xfs/quota/xfs_dquot.c:19:20: error: xfs_fs.h: No such file or directory
fs/xfs/quota/xfs_dquot.c:20:21: error: xfs_bit.h: No such file or directory
fs/xfs/quota/xfs_dquot.c:21:21: error: xfs_log.h: No such file or directory

So I gave up and lost^Wused a couple of hours trimming  down .config, and 
now it's compiling.

Romano

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Andrew Morton]

On Thu, 24 May 2007 22:14:08 +0200
Romano Giannetti <romano.giannetti@gmail.com> wrote:

> Compiling now. I had lost a lot of time because at first try it stopped
> in ntfs:
> 
>   CC [M]  fs/ntfs/super.o
> fs/ntfs/super.c: In function ___init_ntfs_fs___:
> fs/ntfs/super.c:3152: error: expected ___)___ before ___NTFS_VERSION___
> fs/ntfs/super.c: At top level:
> fs/ntfs/super.c:3262: error: expected ___,___ or ___;___ before ___NTFS_VERSION___
> make[2]: *** [fs/ntfs/super.o] Error 1
> make[1]: *** [fs/ntfs] Error 2
> make: *** [fs] Error 2
>   
> I suppose because NTFS_VERSION were defined as EXTRA_CFLAGS too in the Makefile, 

ntfs is being naughty.

--- a/fs/ntfs/Makefile~a
+++ a/fs/ntfs/Makefile
@@ -6,7 +6,7 @@ ntfs-objs := aops.o attrib.o collate.o c
 	     index.o inode.o mft.o mst.o namei.o runlist.o super.o sysctl.o \
 	     unistr.o upcase.o
 
-EXTRA_CFLAGS = -DNTFS_VERSION=\"2.1.28\"
+EXTRA_CFLAGS += -DNTFS_VERSION=\"2.1.28\"
 
 ifeq ($(CONFIG_NTFS_DEBUG),y)
 EXTRA_CFLAGS += -DDEBUG
_


akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep '+=' | wc -l 
131
akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep -v '+=' | wc -l 
55

hm, lots of Makefiles commit the same sin.  Sam, is this as busted as
I think it is?

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Sam Ravnborg]

On Thu, May 24, 2007 at 02:01:54PM -0700, Andrew Morton wrote:
> On Thu, 24 May 2007 22:14:08 +0200
> Romano Giannetti <romano.giannetti@gmail.com> wrote:
> 
> > Compiling now. I had lost a lot of time because at first try it stopped
> > in ntfs:
> > 
> >   CC [M]  fs/ntfs/super.o
> > fs/ntfs/super.c: In function ___init_ntfs_fs___:
> > fs/ntfs/super.c:3152: error: expected ___)___ before ___NTFS_VERSION___
> > fs/ntfs/super.c: At top level:
> > fs/ntfs/super.c:3262: error: expected ___,___ or ___;___ before ___NTFS_VERSION___
> > make[2]: *** [fs/ntfs/super.o] Error 1
> > make[1]: *** [fs/ntfs] Error 2
> > make: *** [fs] Error 2
> >   
> > I suppose because NTFS_VERSION were defined as EXTRA_CFLAGS too in the Makefile, 
> 
> ntfs is being naughty.
> 
> --- a/fs/ntfs/Makefile~a
> +++ a/fs/ntfs/Makefile
> @@ -6,7 +6,7 @@ ntfs-objs := aops.o attrib.o collate.o c
>  	     index.o inode.o mft.o mst.o namei.o runlist.o super.o sysctl.o \
>  	     unistr.o upcase.o
>  
> -EXTRA_CFLAGS = -DNTFS_VERSION=\"2.1.28\"
> +EXTRA_CFLAGS += -DNTFS_VERSION=\"2.1.28\"
>  
>  ifeq ($(CONFIG_NTFS_DEBUG),y)
>  EXTRA_CFLAGS += -DDEBUG
> _
> 
> 
> akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep '+=' | wc -l 
> 131
> akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep -v '+=' | wc -l 
> 55
> 
> hm, lots of Makefiles commit the same sin.  Sam, is this as busted as
> I think it is?

I really cannot see why it makes a difference.
If you use += (and :=) make will resolve EXTRA_CFLAGS when it see it.
Whereas with = make will resolve it only when actually referenced.

But the way we use EXTRA_CFLAGS it should not matter.
If the fix above really helps nfs I need to take a closer look tomorrow.

	Sam

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Andrew Morton]

On Thu, 24 May 2007 23:12:37 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> On Thu, May 24, 2007 at 02:01:54PM -0700, Andrew Morton wrote:
> > On Thu, 24 May 2007 22:14:08 +0200
> > Romano Giannetti <romano.giannetti@gmail.com> wrote:
> > 
> > > Compiling now. I had lost a lot of time because at first try it stopped
> > > in ntfs:
> > > 
> > >   CC [M]  fs/ntfs/super.o
> > > fs/ntfs/super.c: In function ___init_ntfs_fs___:
> > > fs/ntfs/super.c:3152: error: expected ___)___ before ___NTFS_VERSION___
> > > fs/ntfs/super.c: At top level:
> > > fs/ntfs/super.c:3262: error: expected ___,___ or ___;___ before ___NTFS_VERSION___
> > > make[2]: *** [fs/ntfs/super.o] Error 1
> > > make[1]: *** [fs/ntfs] Error 2
> > > make: *** [fs] Error 2
> > >   
> > > I suppose because NTFS_VERSION were defined as EXTRA_CFLAGS too in the Makefile, 
> > 
> > ntfs is being naughty.
> > 
> > --- a/fs/ntfs/Makefile~a
> > +++ a/fs/ntfs/Makefile
> > @@ -6,7 +6,7 @@ ntfs-objs := aops.o attrib.o collate.o c
> >  	     index.o inode.o mft.o mst.o namei.o runlist.o super.o sysctl.o \
> >  	     unistr.o upcase.o
> >  
> > -EXTRA_CFLAGS = -DNTFS_VERSION=\"2.1.28\"
> > +EXTRA_CFLAGS += -DNTFS_VERSION=\"2.1.28\"
> >  
> >  ifeq ($(CONFIG_NTFS_DEBUG),y)
> >  EXTRA_CFLAGS += -DDEBUG
> > _
> > 
> > 
> > akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep '+=' | wc -l 
> > 131
> > akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep -v '+=' | wc -l 
> > 55
> > 
> > hm, lots of Makefiles commit the same sin.  Sam, is this as busted as
> > I think it is?
> 
> I really cannot see why it makes a difference.
> If you use += (and :=) make will resolve EXTRA_CFLAGS when it see it.
> Whereas with = make will resolve it only when actually referenced.

It's not a matter of when it's evaluated.  The user is supposed to be
able to set EXTRA_CFLAGS on the command-line, yes?  If they do that then
the "=" in there will rub out their efforts.  The makefiles should be
appending new things to EXTRA_CFLAGS, rather than doing a replacement?

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Sam Ravnborg]

On Thu, May 24, 2007 at 02:21:26PM -0700, Andrew Morton wrote:
> 
> It's not a matter of when it's evaluated.  The user is supposed to be
> able to set EXTRA_CFLAGS on the command-line, yes?  If they do that then
> the "=" in there will rub out their efforts.  The makefiles should be
> appending new things to EXTRA_CFLAGS, rather than doing a replacement?

There is no way to specify additional CFLAGS on the commandline today.
For sparse we took the shorthand CF so you can do:

make C=2 CF=-warn-bitwise

But we have no such thing for CFLAGS.
If there is a real need I can cook up something.
But frankly I have alway edited top-level Makefile and be doen with it.

I will fix it so Kbuild do not barf out if you set EXTRA_* on the commandline
but silently ignore it instead.

	Sam

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 23:12 +0200, Sam Ravnborg wrote:

> 
> I really cannot see why it makes a difference.
> If you use += (and :=) make will resolve EXTRA_CFLAGS when it see it.
> Whereas with = make will resolve it only when actually referenced.
> 
> But the way we use EXTRA_CFLAGS it should not matter.
> If the fix above really helps nfs I need to take a closer look tomorrow.
> 

No, you're right, it doesn't help. What could help is a form of saying
to make "add this EXTRA_CFLAGS  to whatever is specified in the command
line". No idea if it exists.

Romano

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Johannes Stezenbach]

On Thu, May 24, 2007 at 11:51:53PM +0200, Romano Giannetti wrote:
> On Thu, 2007-05-24 at 23:12 +0200, Sam Ravnborg wrote:
> 
> > 
> > I really cannot see why it makes a difference.
> > If you use += (and :=) make will resolve EXTRA_CFLAGS when it see it.
> > Whereas with = make will resolve it only when actually referenced.
> > 
> > But the way we use EXTRA_CFLAGS it should not matter.
> > If the fix above really helps nfs I need to take a closer look tomorrow.
> 
> No, you're right, it doesn't help. What could help is a form of saying
> to make "add this EXTRA_CFLAGS  to whatever is specified in the command
> line". No idea if it exists.

The GNU make manual says:

"To append more text to a variable defined on the command line, use:

     override VARIABLE += MORE TEXT
"


HTH,
Johannes

Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 14:01 -0700, Andrew Morton wrote:
> On Thu, 24 May 2007 22:14:08 +0200
> Romano Giannetti <romano.giannetti@gmail.com> wrote:
> 

> ntfs is being naughty.
> 

> hm, lots of Makefiles commit the same sin.  Sam, is this as busted as
> I think it is?

Hmmm... 

CC [M]  drivers/ide/pci/amd74xx.o
drivers/ide/pci/amd74xx.c:28:24: error: ide-timing.h: No such file or
directory
(etc etc)

... and in Makefile:

EXTRA_CFLAGS    := -Idrivers/ide

I changed it to 

EXTRA_CFLAGS    += -Idrivers/ide

but I have the same error. Puzzled (yes, again).

Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 08:28 -0700, Linus Torvalds wrote:

> Can you compile those two modules with PCMCIA_DEBUG=4?
>
> Something like
>
> 	make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4
>

Well, I have to give up for tonight... that make do not works (see the
problem explained in other messages, some part of the kernel fails to
compile for the redefined EXTRA_CFLAGS); I naively tried to do:

     make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4 drivers/pcmcia/

(which worked)

and then

     make

(alone) but the second one recompiled the  drivers/pcmcia/ subdir, too.
Too tired to think right now (good excuse), so I will try to find a bit
of time tomorrow.

Another naive doubt I have is: in 2.6.17.13, with additional patches
http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045
http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2
http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3

(now in the mainline), it works. And it used the cis file too.

Romano



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)

[Linus Torvalds]

On Fri, 25 May 2007, Romano Giannetti wrote:
> 
> Another naive doubt I have is: in 2.6.17.13, with additional patches
> http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045
> http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2
> http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3
> 
> (now in the mainline), it works. And it used the cis file too.

It really would be nice of you to just "git bisect" this, to see where it 
started having that 60-second delay..

		Linus

Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 15:49 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Romano Giannetti wrote:
> >
> > Another naive doubt I have is: in 2.6.17.13, with additional patches
> > http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045
> > http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2
> > http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3
> >
> > (now in the mainline), it works. And it used the cis file too.
>
> It really would be nice of you to just "git bisect" this, to see where it
> started having that 60-second delay..
>
> 		Linus

Yep, it would be nice. I will try; but this has to wait a week or more,
end term is approaching and this is a busy period not only for student.
Meanwhile, I tried to compile with PCMCIA debug with nil result (it
seems that a good part of the kernel do not compile if you override
EXTRA_CFLAGS on the make command line). So I tried to define
PCMCIA_DEBUG=4 in the source(s) file affected, but no joy... then I
checked in a clean tree:

cd /linux-2.6.21.3/drivers/pcmcia
% grep PCMCIA_DEBUG *
Kconfig:config PCMCIA_DEBUG
m8xx_pcmcia.c:#ifdef PCMCIA_DEBUG
m8xx_pcmcia.c:static int pc_debug = PCMCIA_DEBUG;
Makefile:ifeq ($(CONFIG_PCMCIA_DEBUG),y)

...so it's seems that only the m8xx modules uses it, and the modules
that load the drivers for my card is yenta_socket... no idea on how to
enable debug.

Romano



--
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)

[Romano Giannetti]

On Thu, 2007-05-24 at 15:49 -0700, Linus Torvalds wrote:
>

> It really would be nice of you to just "git bisect" this, to see where it
> started having that 60-second delay..

...and while at it, I decided to start by learning a bit more of git,
and installed the last version...

% git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Initialized empty Git repository in /usr/src/git/linux-2.6/.git/
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?

I cannot use git protocol from here (overfirewalling, you know...)

Romano

--
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)

[Linus Torvalds]

On Fri, 25 May 2007, Romano Giannetti wrote:
> 
> ...and while at it, I decided to start by learning a bit more of git,
> and installed the last version...
> 
> % git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> Initialized empty Git repository in /usr/src/git/linux-2.6/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?

Heh. If you are using http://, you should _not_ ask for "git.kernel.org".

So use

	git clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

instead. That should work (modulo mirroring issues - but mirroring has 
worked pretty well lately)

> I cannot use git protocol from here (overfirewalling, you know...)

http:// will suck, but should work. It will be a bit frustrating, because 
when it downloads the big packs, it will just say something like

	Getting pack 4f22c0234340c4f3470c04f912969fc59ae8babc
	 which contains ...

and then it will be quiet for a _loong_ time while it downloads that 164MB 
pack..

And the real problem with http:// will come later, if you use git to keep 
up-to-date with the kernel, and I end up repacking the archive (which I 
usually do around major releases). Then it will end up fetching the newly 
repacked data - even though most of it you already have.

Anyway, there's a reason why the "native" protocols are much preferred, 
but the http:// one does work. It just requires www.kernel.org, not 
git.kernel.org.

			Linus

Re: [patch 00/69] -stable review

[Linus Torvalds]

On Thu, 24 May 2007, Romano Giannetti wrote:
> 
> I discovered that SysRq-t works during the pause. So I pressed it more
> or less halfway the pause; the full result is here:
> http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume.txt
> 
> It seems that most of the tasks are in
> 
> [<c0138931>] refrigerator+0x41/0x60

Yeah, but the interesting one is this pair:

  events/0      R running     0     4      1 (L-TLB)

  sleep.sh      D 0000014F     0  5798   5789 (NOTLB)
  Call Trace:
   [<c01d3c01>] kobject_uevent_env+0x3a1/0x4a0
   [<c02d8509>] wait_for_completion+0x79/0xb0
   [<c0116640>] default_wake_function+0x0/0x10
   [<c0238a08>] _request_firmware+0x1c8/0x310
   [<c0238bef>] request_firmware+0xf/0x20
   [<e0a35d5d>] pcmcia_bus_match+0x28d/0x3c0 [pcmcia]
   [<c02864a7>] netlink_broadcast+0x1f7/0x310
   [<c0233d74>] driver_probe_device+0x34/0xc0
   [<c02d79ee>] klist_next+0x4e/0xa0
   [<c0233014>] bus_for_each_drv+0x44/0x70
   [<c0233eba>] device_attach+0x7a/0x80
   [<c0233e00>] __device_attach+0x0/0x10
   [<c0232f56>] bus_attach_device+0x26/0x60
   [<c0231d06>] device_add+0x5e6/0x6e0
   [<c01d350f>] kobject_init+0x2f/0x50
   [<e0a360f5>] pcmcia_device_add+0x185/0x220 [pcmcia]
   [<e0a36261>] pcmcia_card_add+0xa1/0xc0 [pcmcia]
   [<e0913900>] ti12xx_power_hook+0x180/0x1d0 [yenta_socket]
   [<e0a36300>] ds_event+0x80/0xb0 [pcmcia]
   [<e0967359>] send_event+0x39/0x70 [pcmcia_core]
   [<e09677b6>] socket_insert+0x86/0xe0 [pcmcia_core]
   [<e0967c2b>] pcmcia_socket_dev_resume+0x7b/0x90 [pcmcia_core]
   [<c01e135f>] pci_device_resume+0x1f/0x60
   [<c023815f>] resume_device+0x5f/0xf0

ie we have a deadlock because resume wants to do that firmware request,
but the event daemon is apparently spinning like mad. 

And yes, request_firmware() has a "loading_timeout" in seconds.  And
it's 60. So that explains your pause right there!

It might be some unfortunate interaction with process freezing (my
favorite whipping boy), but it could also be something else.  I suspect
we should treat suspend/resume as a bootup event, and not allow execve()
for that case at all. Right now we have:

        retval = -EPERM;
        if (current->fs->root)
                retval = kernel_execve(sub_info->path,
                                sub_info->argv, sub_info->envp);

in kernel/kmod.c, and that "current->fs->root" thing basically protects
us from trying to run a user-mode helper early in the boot sequence, but
we might want to add a conditional like "&& !resuming" to that test..

		Linus

pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> Yeah, but the interesting one is this pair:
> 
>   events/0      R running     0     4      1 (L-TLB)
> 
>   sleep.sh      D 0000014F     0  5798   5789 (NOTLB)
>   Call Trace:
>    [<c01d3c01>] kobject_uevent_env+0x3a1/0x4a0
>    [<c02d8509>] wait_for_completion+0x79/0xb0
>    [<c0116640>] default_wake_function+0x0/0x10
>    [<c0238a08>] _request_firmware+0x1c8/0x310
>    [<c0238bef>] request_firmware+0xf/0x20
>    [<e0a35d5d>] pcmcia_bus_match+0x28d/0x3c0 [pcmcia]
>    [<c02864a7>] netlink_broadcast+0x1f7/0x310
>    [<c0233d74>] driver_probe_device+0x34/0xc0
>    [<c02d79ee>] klist_next+0x4e/0xa0
>    [<c0233014>] bus_for_each_drv+0x44/0x70
>    [<c0233eba>] device_attach+0x7a/0x80
>    [<c0233e00>] __device_attach+0x0/0x10
>    [<c0232f56>] bus_attach_device+0x26/0x60
>    [<c0231d06>] device_add+0x5e6/0x6e0
>    [<c01d350f>] kobject_init+0x2f/0x50
>    [<e0a360f5>] pcmcia_device_add+0x185/0x220 [pcmcia]
>    [<e0a36261>] pcmcia_card_add+0xa1/0xc0 [pcmcia]
>    [<e0913900>] ti12xx_power_hook+0x180/0x1d0 [yenta_socket]
>    [<e0a36300>] ds_event+0x80/0xb0 [pcmcia]
>    [<e0967359>] send_event+0x39/0x70 [pcmcia_core]
>    [<e09677b6>] socket_insert+0x86/0xe0 [pcmcia_core]
>    [<e0967c2b>] pcmcia_socket_dev_resume+0x7b/0x90 [pcmcia_core]
>    [<c01e135f>] pci_device_resume+0x1f/0x60
>    [<c023815f>] resume_device+0x5f/0xf0
> 
> ie we have a deadlock because resume wants to do that firmware request,
> but the event daemon is apparently spinning like mad. 
> 
> And yes, request_firmware() has a "loading_timeout" in seconds.  And
> it's 60. So that explains your pause right there!

If someone does request_firmware from resume function... that's
bad. Resume function should be fixed. Pcmcia? ti12xx driver?

> It might be some unfortunate interaction with process freezing (my
> favorite whipping boy), but it could also be something else.  I
> suspect

Well. we'd like to present hardware in working state as soon as we
resume (if eth0 was there before resume, it should be there after
resume. not 3 seconds after resume); so if someone needs to load the
firmware, they should just store it in the kernel memory, and load it
during boot or during (very early) suspend.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Thu, 24 May 2007, Pavel Machek wrote:
> 
> If someone does request_firmware from resume function... that's
> bad. Resume function should be fixed. Pcmcia? ti12xx driver?

Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS.

> Well. we'd like to present hardware in working state as soon as we
> resume (if eth0 was there before resume, it should be there after
> resume. not 3 seconds after resume); so if someone needs to load the
> firmware, they should just store it in the kernel memory, and load it
> during boot or during (very early) suspend.

Equally arguably, we should just have a "resume_late()" call that can be 
used to do this after everything is up and running.

And quite frankly, I don't actually see any reason why firmware loading 
shouldn't work in the resume path. I really do think that this is ANOTHER 
bug that has no other reason than the fact that that f*cking freezer 
killed the system for no really good reason.

		Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Thursday, 24 May 2007 22:27, Linus Torvalds wrote:
> 
> On Thu, 24 May 2007, Pavel Machek wrote:
> > 
> > If someone does request_firmware from resume function... that's
> > bad. Resume function should be fixed. Pcmcia? ti12xx driver?
> 
> Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS.
> 
> > Well. we'd like to present hardware in working state as soon as we
> > resume (if eth0 was there before resume, it should be there after
> > resume. not 3 seconds after resume); so if someone needs to load the
> > firmware, they should just store it in the kernel memory, and load it
> > during boot or during (very early) suspend.
> 
> Equally arguably, we should just have a "resume_late()" call that can be 
> used to do this after everything is up and running.
> 
> And quite frankly, I don't actually see any reason why firmware loading 
> shouldn't work in the resume path. I really do think that this is ANOTHER 
> bug that has no other reason than the fact that that f*cking freezer 
> killed the system for no really good reason.

Well, if I understand request_firmware() correctly, it does something in sysfs
and waits for the user land to react, but at this point the user land can't do
anything.

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > Well. we'd like to present hardware in working state as soon as we
> > resume (if eth0 was there before resume, it should be there after
> > resume. not 3 seconds after resume); so if someone needs to load the
> > firmware, they should just store it in the kernel memory, and load it
> > during boot or during (very early) suspend.
> 
> Equally arguably, we should just have a "resume_late()" call that can be 
> used to do this after everything is up and running.

Yes, we can do that. But userland will see devices "not there" for a
few seconds after boot.

...that is ugly, but we can survive it for ethernet cards etc... but
it will be really fatal for any block device. Pcmcia block devices
exist, so I do not think we can do that.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Pavel Machek wrote:
> > 
> > Equally arguably, we should just have a "resume_late()" call that can be 
> > used to do this after everything is up and running.
> 
> Yes, we can do that. But userland will see devices "not there" for a
> few seconds after boot.

No they won't.

Why the HELL cannot you realize that kernel threads are different?

The right thing to do is AND HAS ALWAYS BEEN, to stop and start user 
threads only around the whole thing.

Don't touch those kernel threads. Stop freezing them.

Then, what you do is:
 - stop user space
 - suspend
 - resume
 - start user space

and at no point do you touch any kernel threads.

And yes, that "resume" part is multi-phase. We already have 
"resume_early()" to do bus-level setup, and then "resume()" to do the 
"make devices work". I was suggesting adding a "resume_late()" phase to 
let the devices do things that require other devices to work, like doing 
firmware loading.

But stopping kernel threads is STUPID. As long as we continue to do that, 
it will never _ever_ work.

Yeah, we could re-start the kernel thread before "resume_late()", but the 
fact is, they shouldn't have been stopped in the first place.

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

On Thu 2007-05-24 15:10:29, Linus Torvalds wrote:
> 
> 
> On Fri, 25 May 2007, Pavel Machek wrote:
> > > 
> > > Equally arguably, we should just have a "resume_late()" call that can be 
> > > used to do this after everything is up and running.
> > 
> > Yes, we can do that. But userland will see devices "not there" for a
> > few seconds after boot.
> 
> No they won't.
> 
> Why the HELL cannot you realize that kernel threads are different?

Ugh? We are talking about request_firmware() here, right? That's
calling userland helper to load the firmware...? Looks like USER
thread to me.
								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Pavel Machek wrote:
> > 
> > Why the HELL cannot you realize that kernel threads are different?
> 
> Ugh? We are talking about request_firmware() here, right? That's
> calling userland helper to load the firmware...? Looks like USER
> thread to me.

Right. And if we had had the nice old /sbin/hotplug thing, it would all 
have worked fine - because it would just have done an execve(), and things 
would be happy.

But people screwed that up too, and now udevd is an undebuggable user 
thread. Shit happens. See my other email about why even user threads can 
probably not be frozen, and the whole freezer thing is misdesigned.

And I repeat: PowerPC had working and stable suspend five _years_ ago, 
without any of that freezing crud. We should rip it out.

		Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > > Why the HELL cannot you realize that kernel threads are different?
> > 
> > Ugh? We are talking about request_firmware() here, right? That's
> > calling userland helper to load the firmware...? Looks like USER
> > thread to me.
> 
> Right. And if we had had the nice old /sbin/hotplug thing, it would all 
> have worked fine - because it would just have done an execve(), and things 
> would be happy.
> 
> But people screwed that up too, and now udevd is an undebuggable user 
> thread. Shit happens. See my other email about why even user threads can 
> probably not be frozen, and the whole freezer thing is misdesigned.

I'm not ready to redesign udevd :-(.

Your other mail proves that either

1) we can stop freezing udevd, and pray udevd does not become confused
by "half hardware not available" while system is being suspended

_or_

2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.

> And I repeat: PowerPC had working and stable suspend five _years_ ago, 
> without any of that freezing crud. We should rip it out.

Imageine we killed freezer. Also imagine Romano has IDE card his
PCMCIA slot. Kaboom, we solved nothing. We'll either deadlock or do
something very nasty to the filesystem on the IDE card ... because
we'll have udevd running, but fs on IDE card not available.

That does not work. "Not freezing udevd" only makes problems hard to
trigger, see?

Now... "should we rip freezer out of suspend" is a different story. It
does not help _here_. We still need to load the firmware during
_suspend_.

[Can you ack this point and we can have nice flamewar about ripping
out freezer?]

But I'd actually like to get rid of freezer for suspend (I believe
it is needed for hibernation) -- we'll need to do similar that for
runtime suspending of devices, anyway. But "just rip it out" will
cause some hard to debug breakage, we need to somehow audit the
drivers, or ask driver writers to audit them or something. ... and
yes, ripping freezer out _will_ make drivers more complex. Your video
capture card will now have to deal with

"ouch, I was already told to suspend, and now someone is calling my
ioctls() ?!".
								
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Pavel Machek wrote:
> 
> 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> PEOPLE FOR FIVE YEARS NOW.

And people aren't listening. Have you thought about _why_?

The thing is, it should just work. Even without pre-loading.

> Imageine we killed freezer. Also imagine Romano has IDE card his
> PCMCIA slot. Kaboom, we solved nothing.

Don't be silly. We solved it. The firmware has to be loadable from 
somewhere else, since otherwise his IDE card wouldn't have been accessible 
in the first place! 

So all your arguments are just bogus crap.

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi Linus.

On Thu, 2007-05-24 at 17:37 -0700, Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Pavel Machek wrote:
> > 
> > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > PEOPLE FOR FIVE YEARS NOW.
> 
> And people aren't listening. Have you thought about _why_?
> 
> The thing is, it should just work. Even without pre-loading.
> 
> > Imageine we killed freezer. Also imagine Romano has IDE card his
> > PCMCIA slot. Kaboom, we solved nothing.
> 
> Don't be silly. We solved it. The firmware has to be loadable from 
> somewhere else, since otherwise his IDE card wouldn't have been accessible 
> in the first place! 
> 
> So all your arguments are just bogus crap.

Let me see if I can help. I'll probably fail miserably, but I can only
try :)

First, let me agree with you that for the atomic copy itself, the
freezer is unnecessary. Disabling irqs and so on is enough to ensure the
atomic copy is atomic. I don't think any of us are arguing with you
there.

Where we see the problem is with what happens after the atomic copy is
made. The problem is that the atomic copy includes struct inodes, dnodes
and such like - an in memory representation of the state of mounted
filesystems. Imagine that, post atomic copy, we don't have the freezer.
Processes can then make on-disk changes to these mounted filesystems in
the time before we complete saving the image and powering down. If, at
resume time, we then restore the atomic copy, we have a mismatch between
what the in-memory data structures say and what the on-disk data says.
This leads to corruption.

How to avoid?

Well, there are only two options as far as I can see. We either stop
those changes occurring in the first place, or we make them undoable.

Freezing processes, and/or filesystems would be the first path,
checkpointing the second.

So, as far as I can see, we're stuck with freezing processes at least
until checkpointing is implemented.

I have to admit though, that even if checkpointing was implemented, I'd
like to see freezing processes remain. The image gets written faster if
we don't have to compete for cpu and i/o. It also allows us to do a
fuller image of memory than is otherwise possible (Yes, I know some
people don't care for full images, but others of us have usage patterns
that make the system far more useable if a full image is kept, or simply
prefer to have our machines as if the power had never gone away).
Without processes freezing, I'd have to work a lot harder to find a way
to do that full image. The simplest way would probably be to carry the
freezer code myself. (Yeah, I'm reconciled to the idea of never getting
Suspend2 merged. I'd like it to happen, but won't hold my breath.
Someone needs to break your suspend-to-ram or battery so you see the use
for hibernation :>).

Hope this helps.

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Nigel Cunningham wrote:
> 
> First, let me agree with you that for the atomic copy itself, the
> freezer is unnecessary. Disabling irqs and so on is enough to ensure the
> atomic copy is atomic. I don't think any of us are arguing with you
> there.

First off, realize that the problem actually happens during 
suspend-to-ram.

Think about that for a second.

In fact, think about it for a _loong_ time. Because dammit, people seem to 
have a really hard time even realizing this.

	There is no "atomic copy".

	There is no "checkpointing".

	There is no "spoon".

> Hope this helps.

Hope _the_above_ helps. Why is it so hard for people to accept that 
suspend-to-ram shouldn't break because of some IDIOTIC issues with disk 
snapshots?

And why do you people _always_ keep mixing the two up?

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi Linus.

On Thu, 2007-05-24 at 19:10 -0700, Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> > 
> > First, let me agree with you that for the atomic copy itself, the
> > freezer is unnecessary. Disabling irqs and so on is enough to ensure the
> > atomic copy is atomic. I don't think any of us are arguing with you
> > there.
> 
> First off, realize that the problem actually happens during 
> suspend-to-ram.
> 
> Think about that for a second.
> 
> In fact, think about it for a _loong_ time. Because dammit, people seem to 
> have a really hard time even realizing this.
> 
> 	There is no "atomic copy".
> 
> 	There is no "checkpointing".
> 
> 	There is no "spoon".
> 
> > Hope this helps.
> 
> Hope _the_above_ helps. Why is it so hard for people to accept that 
> suspend-to-ram shouldn't break because of some IDIOTIC issues with disk 
> snapshots?
> 
> And why do you people _always_ keep mixing the two up?

It does. Sorry. I didn't read enough of the context.

To answer the question, I guess the answer is that although they're
different creatures, they have similarities. This is one of them, which
is why I could make the mistake I did. Nothing in the issue being
discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus
too much on the similarities, but that doesn't mean they're not there.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Nigel Cunningham wrote:
> 
> To answer the question, I guess the answer is that although they're
> different creatures, they have similarities. This is one of them, which
> is why I could make the mistake I did. Nothing in the issue being
> discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus
> too much on the similarities, but that doesn't mean they're not there.

I agree that the current bug is not unique to STR. In fact, I think Romano 
tested both STD and STR, and both had the same bug with the 60s timeout.

But what irritates me is that STR really shouldn't have _had_ that bug at 
all. The only reason STR had the same bug as STD was exactly the fact that 
the two features are too closely inter-twined in the kernel. 

That irritates me hugely. We had a bug we should never had had! We had a 
bug because people are sharing code that shouldn't be shared! We had a bug 
because of code that makes no sense in the first place!

I agree that disk snapshotting is much harder. If we had a bug just in 
that part, I wouldn't mind it so much. Getting hard problems wrong isn't 
something you should be ashamed of. What I mind is that the _easier_ 
problem got infected by all the bugs from the _harder_ issue. That just 
makes me really really angry and frustrated.

Look at it this way: if you designed a CPU, and you made the integer 
code-path share everything with the floating point side, because "addition 
is addition", and as a result the latency for the simple arithmetic and 
logical ops in integer ALU was four cycles, what would you be?

You'd be a moron, that's what. 

And that is _exactly_ what the current STD/STR code does. It says "suspend 
is suspend" and tries to share the same pipeline, even though the two 
operations are totally different, and share nothing but the name people 
use for it (and even the name is really pretty weak, and I've tried to 
get people to use some other name for STD).

So yes,the two things _do_ share the problem, but they really really 
shouldn't. There's no reason to think that they should. And it drives me 
absolutely bonkers that people seem to have such a hard time seeing that.

That said, I think freezing is crap even for snapshotting/suspend-to-disk, 
but the point of the above rant is to show how insane it is to think that 
problems and complexity in one area should translate into problems and 
complexity in another area.

And if the snapshot people want to screw up their snapshots with freezing, 
I don't actually care that much. I'd much rather have working STR. As it 
is now, they're now _both_ broken.

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi.

On Thu, 2007-05-24 at 19:41 -0700, Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> > 
> > To answer the question, I guess the answer is that although they're
> > different creatures, they have similarities. This is one of them, which
> > is why I could make the mistake I did. Nothing in the issue being
> > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus
> > too much on the similarities, but that doesn't mean they're not there.
> 
> I agree that the current bug is not unique to STR. In fact, I think Romano 
> tested both STD and STR, and both had the same bug with the 60s timeout.
> 
> But what irritates me is that STR really shouldn't have _had_ that bug at 
> all. The only reason STR had the same bug as STD was exactly the fact that 
> the two features are too closely inter-twined in the kernel. 
> 
> That irritates me hugely. We had a bug we should never had had! We had a 
> bug because people are sharing code that shouldn't be shared! We had a bug 
> because of code that makes no sense in the first place!
> 
> I agree that disk snapshotting is much harder. If we had a bug just in 
> that part, I wouldn't mind it so much. Getting hard problems wrong isn't 
> something you should be ashamed of. What I mind is that the _easier_ 
> problem got infected by all the bugs from the _harder_ issue. That just 
> makes me really really angry and frustrated.
> 
> Look at it this way: if you designed a CPU, and you made the integer 
> code-path share everything with the floating point side, because "addition 
> is addition", and as a result the latency for the simple arithmetic and 
> logical ops in integer ALU was four cycles, what would you be?
> 
> You'd be a moron, that's what. 
> 
> And that is _exactly_ what the current STD/STR code does. It says "suspend 
> is suspend" and tries to share the same pipeline, even though the two 
> operations are totally different, and share nothing but the name people 
> use for it (and even the name is really pretty weak, and I've tried to 
> get people to use some other name for STD).

I think I get what you're trying to say, but I also think you're either
overstating your case ("...totally different and share nothing but the
name...") or underestimating the similiarity - they both need (albeit
for different reasons) to do the cpu hotplugging, driver suspending
(yeah, there are similarities and differences there) and irq disabling.
That's _some_ similarity. Apart from that, yeah - they are totally
different.

Re the name, we discussed changing the name of Suspend2 on IRC a night
or two ago. We came to the conclusion that, for better or for worse,
it's too well known now. I can see your logic in wanting to
differentiate them, but I seem to be a bit stuck :\. Push some more.
Maybe we'll get there anyway :) Maybe you can get rid of that horrible,
unpronounceable 'swsusp' name while you're at it? :)

> So yes,the two things _do_ share the problem, but they really really 
> shouldn't. There's no reason to think that they should. And it drives me 
> absolutely bonkers that people seem to have such a hard time seeing that.
> 
> That said, I think freezing is crap even for snapshotting/suspend-to-disk, 
> but the point of the above rant is to show how insane it is to think that 
> problems and complexity in one area should translate into problems and 
> complexity in another area.

Does that imply that you'd prefer to see filesystem checkpointing code,
that you think freezing can be done better, or do you have some other
solution that hasn't occurred to me?

> And if the snapshot people want to screw up their snapshots with freezing, 
> I don't actually care that much. I'd much rather have working STR. As it 
> is now, they're now _both_ broken.

Fair enough :).

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Nigel Cunningham wrote:
> > 
> > That said, I think freezing is crap even for snapshotting/suspend-to-disk, 
> > but the point of the above rant is to show how insane it is to think that 
> > problems and complexity in one area should translate into problems and 
> > complexity in another area.
> 
> Does that imply that you'd prefer to see filesystem checkpointing code,
> that you think freezing can be done better, or do you have some other
> solution that hasn't occurred to me?

I actually don't think that processes should be frozen really at all.

I agree that filesystems have to be frozen (and I think that checkpointing 
of the filesystem or block device is "too clever"), but I just don't think 
that has anything to do with freezing processes.

So I'd actually much prefer to freeze at the VFS (and socket layers, etc), 
and make sure that anybody who tries to write or do something else that we 
cannot do until resuming, will just be blocked (or perhaps just buffered)!

See? I actually think that this process-based thing is barking up the 
wrong tree. After all, it's really not the case that we need to stop 
processes, and stopping processes really does have some problems. It's 
simpler in some ways, but I think a more directed solution would actually 
be better.

>bviously we _do_ want to actually try to quiesce normal user processes. 
>But by "normal user", I'd be willing to limit it to non-uid-zero things, 
>for example. Exactly because it does turn out that the kernel kind of 
>depends on user-land things for stuff like network filesystem connection 
>setup etc (ie we tend to do things like the mount encryption stuff in 
>userland!).

But I really don't care that deeply per se, exactly because I don't use it 
myself. I think people are going down the wrong rabbit-hole, but it 
wouldn't _irritate_ me that much except for the fact that it now also 
impacts suspend-to-RAM.

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Howdy.

On Thu, 2007-05-24 at 20:31 -0700, Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> > > 
> > > That said, I think freezing is crap even for snapshotting/suspend-to-disk, 
> > > but the point of the above rant is to show how insane it is to think that 
> > > problems and complexity in one area should translate into problems and 
> > > complexity in another area.
> > 
> > Does that imply that you'd prefer to see filesystem checkpointing code,
> > that you think freezing can be done better, or do you have some other
> > solution that hasn't occurred to me?
> 
> I actually don't think that processes should be frozen really at all.
> 
> I agree that filesystems have to be frozen (and I think that checkpointing 
> of the filesystem or block device is "too clever"), but I just don't think 
> that has anything to do with freezing processes.
> 
> So I'd actually much prefer to freeze at the VFS (and socket layers, etc), 
> and make sure that anybody who tries to write or do something else that we 
> cannot do until resuming, will just be blocked (or perhaps just buffered)!
> 
> See? I actually think that this process-based thing is barking up the 
> wrong tree. After all, it's really not the case that we need to stop 
> processes, and stopping processes really does have some problems. It's 
> simpler in some ways, but I think a more directed solution would actually 
> be better.

That does sound doable.

I'm sorry to say it, but dropping process freezing still seems to me
like the better way though. I prefer it because of the reliability
aspect. With the current code, having frozen processes, I can look at
the state of memory, calculate how much I'll need for this or that and
know that I'll have sufficient memory for the atomic copy and for doing
the I/O  (making assumptions about how much memory drivers will
allocate) before I start to do either. If we stop freezing processes,
that predictability will go away. There'll always be a possibility that
some process will get memory hungry and stop me from being able to get
the image on disk, and I'll have to either abort or give up and try
again and again until I can complete writing the image, the battery runs
out or whatever... 

> >bviously we _do_ want to actually try to quiesce normal user processes. 
> >But by "normal user", I'd be willing to limit it to non-uid-zero things, 
> >for example. Exactly because it does turn out that the kernel kind of 
> >depends on user-land things for stuff like network filesystem connection 
> >setup etc (ie we tend to do things like the mount encryption stuff in 
> >userland!).

Not sure who you're quoting here, but it's not me. Pavel maybe? I was
unsub'd for a couple of weeks, so guess it's from during that period.

> But I really don't care that deeply per se, exactly because I don't use it 
> myself. I think people are going down the wrong rabbit-hole, but it 
> wouldn't _irritate_ me that much except for the fact that it now also 
> impacts suspend-to-RAM.

Does that mean you never ever power off your laptop (assuming you have
one), and the battery never runs out? Surely you must power it off
completely sometimes? If you do, doesn't that ever happen at a time when
you're part way through something and you'd like to be able to pick up
your merge or whatever later without having to say "Now, where was I up
to?" *shrug* Maybe you're just exceptional :) (Yeah, we know you are in
other ways, but this way?...)

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Fri, 25 May 2007, Nigel Cunningham wrote:
> 
> Does that mean you never ever power off your laptop (assuming you have
> one), and the battery never runs out? Surely you must power it off
> completely sometimes?

So? The bootup isn't that much worse than a disk suspend/resume, and it's 
reliable.

And actually, I don't use laptops much. I use mostly desktops, and STR 
works fine on at least some of them. In contrast, doing some 
suspend-to-disk thing would just be insane and idiotic. If I have to wait 
for half a minute and have a slow system even after that because my git 
trees aren't in the cache, I really might as well just shut them off.

In contrast, STR means they are quiet and don't waste energy when I don't 
use them, but they're instantly available when I care. HUGE difference.

I really think suspend-to-disk is just a total waste of my time.

		Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi.

On Thu, 2007-05-24 at 21:49 -0700, Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> > 
> > Does that mean you never ever power off your laptop (assuming you have
> > one), and the battery never runs out? Surely you must power it off
> > completely sometimes?
> 
> So? The bootup isn't that much worse than a disk suspend/resume, and it's 
> reliable.
> 
> And actually, I don't use laptops much. I use mostly desktops, and STR 
> works fine on at least some of them. In contrast, doing some 
> suspend-to-disk thing would just be insane and idiotic. If I have to wait 
> for half a minute and have a slow system even after that because my git 
> trees aren't in the cache, I really might as well just shut them off.
> 
> In contrast, STR means they are quiet and don't waste energy when I don't 
> use them, but they're instantly available when I care. HUGE difference.
> 
> I really think suspend-to-disk is just a total waste of my time.

Ah. That's because you're using [u]swsusp. If you used Suspend2, your
git trees would be in the cache, your system wouldn't be slow and you'd
still be back up in that half a minute or so - probably less time. Give
it a try for a week, and then go back to rebooting. After that, tell me
rebooting is better and I've wasted the last 5 or 6 years improving the
code.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Mark Lord]

Linus Torvalds wrote:
> 
> On Fri, 25 May 2007, Nigel Cunningham wrote:
>> Does that mean you never ever power off your laptop (assuming you have
>> one), and the battery never runs out? Surely you must power it off
>> completely sometimes?
>
> So? The bootup isn't that much worse than a disk suspend/resume, and it's 
> reliable.

I very much prefer suspend (to RAM) over hibernate (to DISK).
But once in a while, primarily when travelling, I'll use hibernate.

And the "swsusp" in the kernel is just plain crappy and slow,
which leads many people (including our beloved chief penguin, it seems)
into thinking that hibernate *has* to be too slow to be useful.

But with Suspend2, it is very quick and usable by comparism.
Try it, you'll like it (at least a little).

Cheers

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Mark Lord]

Nigel Cunningham wrote:
>
> I'm sorry to say it, but dropping process freezing still seems to me
> like the better way though. I prefer it because of the reliability
> aspect. With the current code, having frozen processes, I can look at
> the state of memory, calculate how much I'll need for this or that and
> know that I'll have sufficient memory for the atomic copy and for doing
> the I/O  (making assumptions about how much memory drivers will
> allocate) before I start to do either. If we stop freezing processes,
> that predictability will go away. There'll always be a possibility that
> some process will get memory hungry and stop me from being able to get
> the image on disk, and I'll have to either abort or give up and try
> again and again until I can complete writing the image, the battery runs
> out or whatever... 

How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
the filesystem VFS callers?   Or is that starting to get messy again?

Cheers

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi.

On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
> Nigel Cunningham wrote:
> >
> > I'm sorry to say it, but dropping process freezing still seems to me
> > like the better way though. I prefer it because of the reliability
> > aspect. With the current code, having frozen processes, I can look at
> > the state of memory, calculate how much I'll need for this or that and
> > know that I'll have sufficient memory for the atomic copy and for doing
> > the I/O  (making assumptions about how much memory drivers will
> > allocate) before I start to do either. If we stop freezing processes,
> > that predictability will go away. There'll always be a possibility that
> > some process will get memory hungry and stop me from being able to get
> > the image on disk, and I'll have to either abort or give up and try
> > again and again until I can complete writing the image, the battery runs
> > out or whatever... 
> 
> How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> the filesystem VFS callers?   Or is that starting to get messy again?

Yeah. Getting messy again :)

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Wed, 30 May 2007, Nigel Cunningham wrote:
> 
> On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
> > 
> > How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> > the filesystem VFS callers?   Or is that starting to get messy again?
> 
> Yeah. Getting messy again :)

Indeed. And also misses the point - the point being that we don't actually 
need to freeze anything at all most of the time. There's nothing wrong 
with making memory allocations etc.

And yes, suspend is different from hibernate. I can see how hibernate 
people are worried about people writing to things after doing the 
snapshot, but those concerns don't exist with suspend. With suspend, the 
biggest concern is accessing a device after it has been suspended, but on 
the other hand, also the fact that we end up having driver writers used 
to the system being "runnable", so they do things that really do require a 
full-fledged system (and sometimes that means just some delayed action 
using a kernel thread, other times it seems to rely on more complex 
behaviour like firmware loading :^p )

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi.

On Tue, 2007-05-29 at 14:33 -0700, Linus Torvalds wrote:
> 
> On Wed, 30 May 2007, Nigel Cunningham wrote:
> > 
> > On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
> > > 
> > > How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> > > the filesystem VFS callers?   Or is that starting to get messy again?
> > 
> > Yeah. Getting messy again :)
> 
> Indeed. And also misses the point - the point being that we don't actually 
> need to freeze anything at all most of the time. There's nothing wrong 
> with making memory allocations etc.
> 
> And yes, suspend is different from hibernate. I can see how hibernate 
> people are worried about people writing to things after doing the 
> snapshot, but those concerns don't exist with suspend. With suspend, the 
> biggest concern is accessing a device after it has been suspended, but on 
> the other hand, also the fact that we end up having driver writers used 
> to the system being "runnable", so they do things that really do require a 
> full-fledged system (and sometimes that means just some delayed action 
> using a kernel thread, other times it seems to rely on more complex 
> behaviour like firmware loading :^p )

Yeah, but they can't. Even after the freezing of processes has been
removed from the normal suspend to ram path, we're still going to have
this issue with the suspend to ram after writing a hibernation image
path.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > > How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> > > the filesystem VFS callers?   Or is that starting to get messy again?
> > 
> > Yeah. Getting messy again :)
> 
> Indeed. And also misses the point - the point being that we don't actually 
> need to freeze anything at all most of the time. There's nothing wrong 
> with making memory allocations etc.
> 
> And yes, suspend is different from hibernate. I can see how hibernate 
> people are worried about people writing to things after doing the 
> snapshot, but those concerns don't exist with suspend. With suspend, the 
> biggest concern is accessing a device after it has been suspended, but on 
> the other hand, also the fact that we end up having driver writers used 
> to the system being "runnable", so they do things that really do require a 
> full-fledged system (and sometimes that means just some delayed action 
> using a kernel thread, other times it seems to rely on more complex 
> behaviour like firmware loading :^p )

Notice that we want to be able to suspend while hibernating -- for
suspend to both behaviour. So drivers may _not_ rely on system being
runnable.

(Suspend to both is: write image to disk, then suspend to RAM. If you
do not run out of battery, resume is from RAM and fast, if you do, you
still can do resume from disk, not loosing your data).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:

(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond 
the original point)

> Notice that we want to be able to suspend while hibernating -- for
> suspend to both behaviour. So drivers may _not_ rely on system being
> runnable.

So keep the driver layers read-only and unfreeze the processes after 
doing the atomic copy.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
> 
> (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond 
> the original point)
> 
> > Notice that we want to be able to suspend while hibernating -- for
> > suspend to both behaviour. So drivers may _not_ rely on system being
> > runnable.
> 
> So keep the driver layers read-only and unfreeze the processes after 
> doing the atomic copy.

I know you probably won't care, but that's not an option for Suspend2 -
I get the possibility of a full image by overwriting LRU pages that were
saved prior to the atomic copy.

That aside, keeping the driver layers read-only sounds more complicated
than just freezing processes.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Wed, May 30, 2007 at 11:17:47PM +1000, Nigel Cunningham wrote:

> That aside, keeping the driver layers read-only sounds more complicated
> than just freezing processes.

It's a problem that effectively has to be solved for STR anyway if 
we're going to suspend without freezing. The midlayers need to be able 
to block requests when the low-level devices are suspended, so we can 
just re-use that code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Wednesday, 30 May 2007 15:29, Matthew Garrett wrote:
> On Wed, May 30, 2007 at 11:17:47PM +1000, Nigel Cunningham wrote:
> 
> > That aside, keeping the driver layers read-only sounds more complicated
> > than just freezing processes.
> 
> It's a problem that effectively has to be solved for STR anyway if 
> we're going to suspend without freezing. The midlayers need to be able 
> to block requests when the low-level devices are suspended,

Very true.  And I think the right order should be to make the midlayers do
this and then remove the freezer from the STR code path, not the other way
around. :-)

> so we can just re-use that code.

Yes, that should be possible.

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Wed, 30 May 2007, Rafael J. Wysocki wrote:
> 
> Very true.  And I think the right order should be to make the midlayers do
> this and then remove the freezer from the STR code path, not the other way
> around. :-)

Yes. After all, STR simply shouldn't _care_.

The rule should be that in a well-written setup, STR "just works" whether 
user processes are suspended or not. In other words, the whole freezing 
part isn't about STR. It should be totally immaterial.

(Of course, that assumes that the freezing is _sane_, of course: ie the 
core kernel threads shouldn't all be frozen. I think Rafael's patch to 
turn the defaults around are a big step in the right direction).

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
> On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> > On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
> > 
> > (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond 
> > the original point)
> > 
> > > Notice that we want to be able to suspend while hibernating -- for
> > > suspend to both behaviour. So drivers may _not_ rely on system being
> > > runnable.
> > 
> > So keep the driver layers read-only and unfreeze the processes after 
> > doing the atomic copy.
> 
> I know you probably won't care, but that's not an option for Suspend2 -
> I get the possibility of a full image by overwriting LRU pages that were
> saved prior to the atomic copy.

This generally is a problem, not only for suspend2. :-)

Once you've unfrozen the user land, we can't rely on the hibernation image any
more, because some tasks may cause the on-disk filesystems' state to change.

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Wed, May 30, 2007 at 04:04:22PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
> > On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> > > So keep the driver layers read-only and unfreeze the processes after 
> > > doing the atomic copy.
> > 
> > I know you probably won't care, but that's not an option for Suspend2 -
> > I get the possibility of a full image by overwriting LRU pages that were
> > saved prior to the atomic copy.
> 
> This generally is a problem, not only for suspend2. :-)
> 
> Once you've unfrozen the user land, we can't rely on the hibernation image any
> more, because some tasks may cause the on-disk filesystems' state to change.

Hence "keep the driver layers read-only" :) 

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi.

On Wed, 2007-05-30 at 16:04 +0200, Rafael J. Wysocki wrote:
> On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
> > On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> > > On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
> > > 
> > > (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond 
> > > the original point)
> > > 
> > > > Notice that we want to be able to suspend while hibernating -- for
> > > > suspend to both behaviour. So drivers may _not_ rely on system being
> > > > runnable.
> > > 
> > > So keep the driver layers read-only and unfreeze the processes after 
> > > doing the atomic copy.
> > 
> > I know you probably won't care, but that's not an option for Suspend2 -
> > I get the possibility of a full image by overwriting LRU pages that were
> > saved prior to the atomic copy.
> 
> This generally is a problem, not only for suspend2. :-)
> 
> Once you've unfrozen the user land, we can't rely on the hibernation image any
> more, because some tasks may cause the on-disk filesystems' state to change.

True. I understood, perhaps wrongly, that when Matthew spoke of keeping
the drivers layers read-only, he was meaning stopping filesystem changes
by some other means.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond 
> the original point)
> 
> > Notice that we want to be able to suspend while hibernating -- for
> > suspend to both behaviour. So drivers may _not_ rely on system being
> > runnable.
> 
> So keep the driver layers read-only and unfreeze the processes after 
> doing the atomic copy.

To read firmware you probably need to _write_ atimes.

Anyway, make-disks-read-only patch would be welcome. I just think it
is going to be more complex than freezer.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Need suspend-to-ram maintainer Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > To answer the question, I guess the answer is that although they're
> > different creatures, they have similarities. This is one of them, which
> > is why I could make the mistake I did. Nothing in the issue being
> > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus
> > too much on the similarities, but that doesn't mean they're not there.
> 
> I agree that the current bug is not unique to STR. In fact, I think Romano 
> tested both STD and STR, and both had the same bug with the 60s timeout.
> 
> But what irritates me is that STR really shouldn't have _had_ that bug at 
> all. The only reason STR had the same bug as STD was exactly the fact that 
> the two features are too closely inter-twined in the kernel. 

And what do you expect? We have three people working on
hibernation, and suspend-to-ram was created as "oh, if we do this,
this, and this, we get get suspend-to-ram with existing code".

> I agree that disk snapshotting is much harder. If we had a bug just in 
> that part, I wouldn't mind it so much. Getting hard problems wrong isn't 
> something you should be ashamed of. What I mind is that the _easier_ 
> problem got infected by all the bugs from the _harder_ issue. That just 
> makes me really really angry and frustrated.
> 
> Look at it this way: if you designed a CPU, and you made the integer 
> code-path share everything with the floating point side, because "addition 
> is addition", and as a result the latency for the simple arithmetic and 
> logical ops in integer ALU was four cycles, what would you be?

You'd be seriously overstaffed in FPU side, and seriously understaffed
on ALU side.

This is basically what happened here. I tell people to get hibernation
to work _first_ because it is usually easier.

And what does that mean? We need three people to work on
suspend-to-RAM. Heck, we need at least _one_ person to work on
suspend-to-RAM, but he needs to be listed in MAINTAINERS.

With hibernation people trying to maintain suspend in their spare
cycles, how do you expect suspend to work? Similar to hibernation,
that's how it looks today.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > PEOPLE FOR FIVE YEARS NOW.
> 
> And people aren't listening. Have you thought about _why_?
> 
> The thing is, it should just work. Even without pre-loading.

But it does not work, and as you demonstrated, getting it to work w/o
preloading is awful lot of work. Feel free to send a patch. Unless you
are ready to do that, stop confusing driver authors.

> > Imageine we killed freezer. Also imagine Romano has IDE card his
> > PCMCIA slot. Kaboom, we solved nothing.
> 
> Don't be silly. We solved it. The firmware has to be loadable from 
> somewhere else, since otherwise his IDE card wouldn't have been accessible 
> in the first place! 

Firmware loader is complex userspace process. That's not silly. It is
userland, and I'd hate to explain to its authors detailed rules. 

It could do 'find / -name "pcmcia-card-firmware"' for example. It
could do dbus message to tell gnome-graphical-crap to display window
to say that it is loading firmware. Maybe it also writes to syslog
when syslogd is available.

It is userland process, so it is allowed to do stupid stuff.

[If you do not agree, please try to write up
"Doc*/what-firmware-loader-must-do.txt" -- at that point you should
realize how ugly the solution you are suggesting is.]
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Kay Sievers]

On 5/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 25 May 2007, Pavel Machek wrote:
> >
> > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > PEOPLE FOR FIVE YEARS NOW.
>
> And people aren't listening. Have you thought about _why_?
>
> The thing is, it should just work. Even without pre-loading.
>
> > Imageine we killed freezer. Also imagine Romano has IDE card his
> > PCMCIA slot. Kaboom, we solved nothing.
>
> Don't be silly. We solved it. The firmware has to be loadable from
> somewhere else, since otherwise his IDE card wouldn't have been accessible
> in the first place!

The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still sold to the idea of userspace firmware loading, why
don't we keep the data in the driver, instead of immediately
discarding it after the first upload? Not to waste a few hundred
kilobytes? That doesn't sound like a convincing deal, after all the
years people try to work around the issues it causes.

Kay

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
> On 5/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Fri, 25 May 2007, Pavel Machek wrote:
> > >
> > > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > > PEOPLE FOR FIVE YEARS NOW.
> >
> > And people aren't listening. Have you thought about _why_?
> >
> > The thing is, it should just work. Even without pre-loading.
> >
> > > Imageine we killed freezer. Also imagine Romano has IDE card his
> > > PCMCIA slot. Kaboom, we solved nothing.
> >
> > Don't be silly. We solved it. The firmware has to be loadable from
> > somewhere else, since otherwise his IDE card wouldn't have been accessible
> > in the first place!
> 
> The shiny userspace firmware loading causes problems since it exists,
> every second box has problems with it, in all sorts of situations. If
> people are still sold to the idea of userspace firmware loading, why
> don't we keep the data in the driver, instead of immediately
> discarding it after the first upload? Not to waste a few hundred
> kilobytes? That doesn't sound like a convincing deal, after all the
> years people try to work around the issues it causes.

Agreed.

Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Michael-Luke Jones]

Rafael J. Wysocki wrote:
> On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
>> The shiny userspace firmware loading causes problems since it exists,
>> every second box has problems with it, in all sorts of situations. If
>> people are still sold to the idea of userspace firmware loading, why
>> don't we keep the data in the driver, instead of immediately
>> discarding it after the first upload? Not to waste a few hundred
>> kilobytes? That doesn't sound like a convincing deal, after all the
>> years people try to work around the issues it causes.
> 
> Agreed.
> 
> Rafael

Rather than most drivers being told to make this step, can this be added 
to the firmware_class such that firmware objects are cached in RAM and 
subsequent calls to request_firmware() don't have to query userspace.

This seems the least intrusive solution to this problem.

Thanks,

Michael-Luke

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Tuesday, 29 May 2007 14:00, Michael-Luke Jones wrote:
> Rafael J. Wysocki wrote:
> > On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
> >> The shiny userspace firmware loading causes problems since it exists,
> >> every second box has problems with it, in all sorts of situations. If
> >> people are still sold to the idea of userspace firmware loading, why
> >> don't we keep the data in the driver, instead of immediately
> >> discarding it after the first upload? Not to waste a few hundred
> >> kilobytes? That doesn't sound like a convincing deal, after all the
> >> years people try to work around the issues it causes.
> > 
> > Agreed.
> > 
> > Rafael
> 
> Rather than most drivers being told to make this step, can this be added 
> to the firmware_class such that firmware objects are cached in RAM and 
> subsequent calls to request_firmware() don't have to query userspace.
> 
> This seems the least intrusive solution to this problem.

Agreed again. :-)

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Kay Sievers]

On Tue, 2007-05-29 at 13:00 +0100, Michael-Luke Jones wrote:
> Rafael J. Wysocki wrote:
> > On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
> >> The shiny userspace firmware loading causes problems since it exists,
> >> every second box has problems with it, in all sorts of situations. If
> >> people are still sold to the idea of userspace firmware loading, why
> >> don't we keep the data in the driver, instead of immediately
> >> discarding it after the first upload? Not to waste a few hundred
> >> kilobytes? That doesn't sound like a convincing deal, after all the
> >> years people try to work around the issues it causes.
> > 
> > Agreed.
> > 
> > Rafael
> 
> Rather than most drivers being told to make this step, can this be added 
> to the firmware_class such that firmware objects are cached in RAM and 
> subsequent calls to request_firmware() don't have to query userspace.
> 
> This seems the least intrusive solution to this problem.

Who is going to keep track of the data hiding in the firmware_class? On
driver unbind, module unload, you want to release the data.

Kay

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Thu, May 24, 2007 at 03:53:28PM -0700, Linus Torvalds wrote:

> And I repeat: PowerPC had working and stable suspend five _years_ ago, 
> without any of that freezing crud. We should rip it out.

As far as I can tell the PPC code simply shuts down the devices without 
worrying about userspace at all. If this was reliable, what prevents us 
from simply disabling the freezer for STR?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Sun, 27 May 2007, Matthew Garrett wrote:
> 
> As far as I can tell the PPC code simply shuts down the devices without 
> worrying about userspace at all. If this was reliable, what prevents us 
> from simply disabling the freezer for STR?

Personally, I think that's the right thing to do. 

And by "disabling the freezer", I think we should just not call it at all. 
However, sadly, right now it's called from common code. I'll happily take 
a tested patch to split that code sequence up, and try to do it in 2.6.23, 
if somebody has the energy (I'm getting to the point where I may just do 
it myself, but my lazy nature still hopes for a STR person to step 
forward).

		Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Sun, May 27, 2007 at 09:26:00AM -0700, Linus Torvalds wrote:

> And by "disabling the freezer", I think we should just not call it at all. 
> However, sadly, right now it's called from common code. I'll happily take 
> a tested patch to split that code sequence up, and try to do it in 2.6.23, 
> if somebody has the energy (I'm getting to the point where I may just do 
> it myself, but my lazy nature still hopes for a STR person to step 
> forward).

I'll take a look at this. It probably makes sense to build on Rafael's 
work on splitting the codepaths up.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Sunday, 27 May 2007 18:43, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 09:26:00AM -0700, Linus Torvalds wrote:
> 
> > And by "disabling the freezer", I think we should just not call it at all. 
> > However, sadly, right now it's called from common code. I'll happily take 
> > a tested patch to split that code sequence up, and try to do it in 2.6.23, 
> > if somebody has the energy (I'm getting to the point where I may just do 
> > it myself, but my lazy nature still hopes for a STR person to step 
> > forward).
> 
> I'll take a look at this. It probably makes sense to build on Rafael's 
> work on splitting the codepaths up.

Actaully, removing the freezer from the suspend code path is simple.  You only
need to remove calls to freeze_processes() and thaw_processes() from
kernel/power/main.c .

That said, I don't think that PPC does what you say only.  We've discussed this
a bit on linux-pm, in this thread:

https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012242.html

In particular, please see this message:

https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Sun, May 27, 2007 at 08:32:14PM +0200, Rafael J. Wysocki wrote:

> In particular, please see this message:
> 
> https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html

Yes, there's also the notifier chain for the hardware. However, very few 
drivers seem to use that - adb seems to be the only one still in the 
tree. For everything else, the device tree is used in exactly the same 
way as on x86. If it's safe on Macs but not on x86, then (as far as I 
can tell) it looks like it's only by luck.

Anyway. I've tested the following patch on a dual-core x86. No obvious 
issues yet, but I'll try to put it through a few hundred cycles.

diff --git a/include/linux/pm.h b/include/linux/pm.h
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 8812985..1db3012 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -19,7 +19,6 @@
 #include <linux/console.h>
 #include <linux/cpu.h>
 #include <linux/resume-trace.h>
-#include <linux/freezer.h>
 #include <linux/vmstat.h>
 
 #include "power.h"
@@ -66,9 +65,10 @@ static inline void pm_finish(suspend_state_t state)
  *	suspend_prepare - Do prep work before entering low-power state.
  *	@state:		State we're entering.
  *
- *	This is common code that is called for each state that we're 
- *	entering. Allocate a console, stop all processes, then make sure
- *	the platform can enter the requested state.
+ *	This is common code that is called for each state that we're
+ *	entering. Allocate a console, then make sure the platform can
+ *	enter the requested state. This is not called for
+ *	suspend-to-disk.
  */
 
 static int suspend_prepare(suspend_state_t state)
@@ -81,11 +81,6 @@ static int suspend_prepare(suspend_state_t state)
 
 	pm_prepare_console();
 
-	if (freeze_processes()) {
-		error = -EAGAIN;
-		goto Thaw;
-	}
-
 	if ((free_pages = global_page_state(NR_FREE_PAGES))
 			< FREE_PAGE_NUMBER) {
 		pr_debug("PM: free some memory\n");
@@ -93,7 +88,7 @@ static int suspend_prepare(suspend_state_t state)
 		if (nr_free_pages() < FREE_PAGE_NUMBER) {
 			error = -ENOMEM;
 			printk(KERN_ERR "PM: No enough memory\n");
-			goto Thaw;
+			goto Exit;
 		}
 	}
 
@@ -118,8 +113,7 @@ static int suspend_prepare(suspend_state_t state)
 	device_resume();
  Resume_console:
 	resume_console();
- Thaw:
-	thaw_processes();
+ Exit:
 	pm_restore_console();
 	return error;
 }
@@ -160,8 +154,8 @@ int suspend_enter(suspend_state_t state)
  *	suspend_finish - Do final work before exiting suspend sequence.
  *	@state:		State we're coming out of.
  *
- *	Call platform code to clean up, restart processes, and free the 
- *	console that we've allocated. This is not called for suspend-to-disk.
+ *	Call platform code to clean up and free the console that we've
+ *	allocated. This is not called for suspend-to-disk.
  */
 
 static void suspend_finish(suspend_state_t state)
@@ -170,7 +164,6 @@ static void suspend_finish(suspend_state_t state)
 	pm_finish(state);
 	device_resume();
 	resume_console();
-	thaw_processes();
 	pm_restore_console();
 }
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Sunday, 27 May 2007 20:44, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 08:32:14PM +0200, Rafael J. Wysocki wrote:
> 
> > In particular, please see this message:
> > 
> > https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html
> 
> Yes, there's also the notifier chain for the hardware. However, very few 
> drivers seem to use that - adb seems to be the only one still in the 
> tree. For everything else, the device tree is used in exactly the same 
> way as on x86. If it's safe on Macs but not on x86, then (as far as I 
> can tell) it looks like it's only by luck.
> 
> Anyway. I've tested the following patch on a dual-core x86. No obvious 
> issues yet, but I'll try to put it through a few hundred cycles.

OK

I'm working on a patch that introduces hibernation/suspend notifiers.  It will
conflict with this one a bit, but OTOH it might be useful here too.

I'll post it in a while in a separate thread.

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:

> Anyway. I've tested the following patch on a dual-core x86. No obvious 
> issues yet, but I'll try to put it through a few hundred cycles.

This /mostly/ works - I've had my test machine cycling through a suspend 
cycle every 10 seconds for the past hour without any difficulties 
providing I unload USB first. If USB is loaded, the suspend occasionally 
fails with one of the devices returning -EBUSY and causing it to be 
aborted. I haven't looked into this in any detail yet, but it's 
presumably sufficiently generic code that it's potentially biting people 
on PPC anyway.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Monday, 28 May 2007 03:05, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:
> 
> > Anyway. I've tested the following patch on a dual-core x86. No obvious 
> > issues yet, but I'll try to put it through a few hundred cycles.
> 
> This /mostly/ works - I've had my test machine cycling through a suspend 
> cycle every 10 seconds for the past hour without any difficulties 
> providing I unload USB first. If USB is loaded, the suspend occasionally 
> fails with one of the devices returning -EBUSY and causing it to be 
> aborted. I haven't looked into this in any detail yet, but it's 
> presumably sufficiently generic code that it's potentially biting people 
> on PPC anyway.

Most probably.

Still, please take what I said in the other thread into consideration: We've
been using the freezer for so long that at least some drivers started to rely
on it being used.

Even if there are no such drivers on your system, they can be used by other
systems.

Greetings,
Rafael

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Mon, May 28, 2007 at 10:11:15AM +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 03:05, Matthew Garrett wrote:
> > This /mostly/ works - I've had my test machine cycling through a suspend 
> > cycle every 10 seconds for the past hour without any difficulties 
> > providing I unload USB first. If USB is loaded, the suspend occasionally 
> > fails with one of the devices returning -EBUSY and causing it to be 
> > aborted. I haven't looked into this in any detail yet, but it's 
> > presumably sufficiently generic code that it's potentially biting people 
> > on PPC anyway.
> 
> Most probably.
> 
> Still, please take what I said in the other thread into consideration: We've
> been using the freezer for so long that at least some drivers started to rely
> on it being used.
> 
> Even if there are no such drivers on your system, they can be used by other
> systems.

Sure, but if any of these drivers run on PPC then they're broken anyway. 
The assumption that processes will be frozen during suspend is true in 
the specific case of ACPI and some of the ARM platforms, but not true on 
PPC or APM systems. We either need to fix the drivers to stop assuming 
this or add the process freezer to the other PM systems. Right now, 
they're buggy.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > > This /mostly/ works - I've had my test machine cycling through a suspend 
> > > cycle every 10 seconds for the past hour without any difficulties 
> > > providing I unload USB first. If USB is loaded, the suspend occasionally 
> > > fails with one of the devices returning -EBUSY and causing it to be 
> > > aborted. I haven't looked into this in any detail yet, but it's 
> > > presumably sufficiently generic code that it's potentially biting people 
> > > on PPC anyway.
> > 
> > Most probably.
> > 
> > Still, please take what I said in the other thread into consideration: We've
> > been using the freezer for so long that at least some drivers started to rely
> > on it being used.
> > 
> > Even if there are no such drivers on your system, they can be used by other
> > systems.
> 
> Sure, but if any of these drivers run on PPC then they're broken anyway. 
> The assumption that processes will be frozen during suspend is true in 
> the specific case of ACPI and some of the ARM platforms, but not true on 
> PPC or APM systems. We either need to fix the drivers to stop assuming 
> this or add the process freezer to the other PM systems. Right now, 
> they're buggy.

Well, PPC people are aware of this, and they think they can fix the
drivers. We probably want to drop the freezer for suspend long-term,
so. PPC machines use small subset of all the drivers, so it apparently
is not big problem for them.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Matthew Garrett]

On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:

> Well, PPC people are aware of this, and they think they can fix the
> drivers. We probably want to drop the freezer for suspend long-term,
> so. PPC machines use small subset of all the drivers, so it apparently
> is not big problem for them.

I'm fairly certain that PPC uses USB. In any case, it's not limited to 
PPC - APM has the same issue. Any driver that assumes processes will be 
frozen during suspend to RAM is broken now, not the future.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > Well, PPC people are aware of this, and they think they can fix the
> > drivers. We probably want to drop the freezer for suspend long-term,
> > so. PPC machines use small subset of all the drivers, so it apparently
> > is not big problem for them.
> 
> I'm fairly certain that PPC uses USB. In any case, it's not limited to 
> PPC - APM has the same issue. Any driver that assumes processes will be 
> frozen during suspend to RAM is broken now, not the future.

Yup, that's a possible view. Fixes welcome.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Nigel Cunningham]

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

Hi.

On Mon, 2007-05-28 at 14:03 +0100, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:
> 
> > Well, PPC people are aware of this, and they think they can fix the
> > drivers. We probably want to drop the freezer for suspend long-term,
> > so. PPC machines use small subset of all the drivers, so it apparently
> > is not big problem for them.
> 
> I'm fairly certain that PPC uses USB. In any case, it's not limited to 
> PPC - APM has the same issue. Any driver that assumes processes will be 
> frozen during suspend to RAM is broken now, not the future.

The converse is also true, though. Any process that assumes processes
aren't frozen during suspend to RAM is also broken now, and will be
while we allow the possibility of suspending to ram after writing a
hibernation image.

In short, drivers should be designed to work whether processes are
frozen or not.

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Romano Giannetti]

On Sun, 2007-05-27 at 19:44 +0100, Matthew Garrett wrote:
>
> Anyway. I've tested the following patch on a dual-core x86. No obvious
> issues yet, but I'll try to put it through a few hundred cycles.
[patch to disable freezer deleted]

First of all, excuse me for being a quite lousy tester. Could not come
around to try bisecting, no time at all. Yesterday in the autobus I gave
a shot to this "wild test" and I report the results here.

- The good (?) news. I have made 7 suspend/resume cycle (to ram, I
haven't tested hibernation) with a 2.6.21.2 with that patch, applied
manually. The system did suspend and resume nicely even compiling a
kernel and opening openoffice. Normally (le me stress _normally_) no
delay was apparent on resume. I do not know how dangerous is this... :-)

- The bad (?) news. One time out of 7 I had the 60 seconds delay. I
attach here the dmesg(s) of the resumes,  a good one, a delayed one, and
another good one after a reboot (where you can, by the way, see the
dancing serial effect... the card is sometime /dev/ttyS1,
sometime /dev/ttyS2). 


[ 1112.984000] Back to C!
[ 1112.985000] Applying VIA southbridge workaround.
[ 1112.985000] PCI: Disabling Via external APIC routing
[ 1113.418000] PM: Writing back config space on device 0000:00:00.0 at offset 1 (was 2100006, writing 12100006)
[ 1113.418000] PM: Writing back config space on device 0000:00:01.0 at offset 9 (was fff0, writing 38003800)
[ 1113.418000] PCI: Setting latency timer of device 0000:00:01.0 to 64
[ 1114.408000] ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[ 1114.408000] PCI: Setting latency timer of device 0000:00:07.2 to 64
[ 1114.408000] usb usb1: root hub lost power or was reset
[ 1114.481000] ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[ 1114.481000] PCI: Setting latency timer of device 0000:00:07.3 to 64
[ 1114.481000] usb usb2: root hub lost power or was reset
[ 1114.657000] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
[ 1114.657000] PCI: Setting latency timer of device 0000:00:07.5 to 64
[ 1115.347000] pccard: PCMCIA card inserted into slot 1
[ 1115.347000] pcmcia: registering new device pcmcia1.0
[ 1115.459000] pcmcia: request for exclusive IRQ could not be fulfilled.
[ 1115.459000] pcmcia: the driver needs updating to supported shared IRQ lines.
[ 1115.504000] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8
[ 1115.504000]   8K FIFO split 5:3 Rx:Tx, auto xcvr
[ 1115.504000] pcmcia: registering new device pcmcia1.1
[ 1115.504000] pcmcia: request for exclusive IRQ could not be fulfilled.
[ 1115.504000] pcmcia: the driver needs updating to supported shared IRQ lines.
[ 1115.545000] 1.1: ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A
[ 1115.558000] PM: Writing back config space on device 0000:00:0e.0 at offset 3 (was 8, writing 4008)
[ 1115.558000] PM: Writing back config space on device 0000:00:0e.0 at offset 1 (was 2100012, writing 2100016)
[ 1115.609000] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9]  MMIO=[e8004000-e80047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[ 1115.615000] PM: Writing back config space on device 0000:00:10.0 at offset 5 (was 0, writing e8004800)
[ 1115.615000] PM: Writing back config space on device 0000:00:10.0 at offset 4 (was 1, writing 1801)
[ 1115.615000] PM: Writing back config space on device 0000:00:10.0 at offset 1 (was 2900000, writing 2900003)
[ 1115.670000] pnp: Device 00:08 activated.
[ 1115.670000] pnp: Failed to activate device 00:0a.
[ 1115.670000] pnp: Failed to activate device 00:0b.
[ 1117.648000] 8139too Fast Ethernet driver 0.9.28
[ 1117.650000] ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
[ 1117.653000] eth0: RealTek RTL8139 at 0xe0a72800, 08:00:46:6e:93:a8, IRQ 10
[ 1117.653000] eth0:  Identified 8139 chip type 'RTL-8139C'
[ 1118.403000] input: Power Button (FF) as /class/input/input13
[ 1118.404000] ACPI: Power Button (FF) [PWRF]
[ 1118.404000] input: Sleep Button (CM) as /class/input/input14
[ 1118.405000] ACPI: Sleep Button (CM) [SBTN]
[ 1118.406000] input: Lid Switch as /class/input/input15
[ 1118.407000] ACPI: Lid Switch [LID]
[ 1118.830000] ACPI: Thermal Zone [THRM] (36 C)
[ 1119.431000] ACPI: AC Adapter [ACAD] (off-line)
[ 1119.899000] ACPI: Battery Slot [BAT1] (battery present)
[ 1119.904000] ACPI: Battery Slot [BAT2] (battery absent)
[ 1126.226000] eth1: no IPv6 routers present

suspend...

[ 2019.310000] pccard: card ejected from slot 0
[ 2019.345000] PCMCIA: socket dc99bc28: *** DANGER *** unable to remove socket power
[ 2019.346000] pccard: card ejected from slot 1
[ 2020.041000] ACPI: PCI interrupt for device 0000:00:10.0 disabled
[ 2024.641000] Suspending console(s)
[ 2024.656000]  usbdev2.1: PM: suspend 0->2, parent usb2 already 2
[ 2024.656000]  usbdev2.1_ep81: PM: suspend 0->2, parent 2-0:1.0 already 2
[ 2024.656000] hub 2-0:1.0: PM: suspend 2->2, parent usb2 already 2
[ 2024.656000]  usbdev2.1_ep00: PM: suspend 0->2, parent usb2 already 2
[ 2026.121000] pnp: Device 00:08 disabled.
[ 2026.137000] ACPI: PCI interrupt for device 0000:00:07.5 disabled
[ 2026.158000] ACPI: PCI interrupt for device 0000:00:07.3 disabled
[ 2026.169000] ACPI: PCI interrupt for device 0000:00:07.2 disabled
[ 2026.191000] Back to C!
[ 2026.191000] Applying VIA southbridge workaround.
[ 2026.191000] PCI: Disabling Via external APIC routing
[ 2026.247000] PM: Writing back config space on device 0000:00:00.0 at offset 1 (was 2100006, writing 12100006)
[ 2026.247000] PM: Writing back config space on device 0000:00:01.0 at offset 9 (was fff0, writing 38003800)
[ 2026.247000] PCI: Setting latency timer of device 0000:00:01.0 to 64
[ 2026.258000] ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[ 2026.258000] PCI: Setting latency timer of device 0000:00:07.2 to 64
[ 2026.258000] usb usb1: root hub lost power or was reset
[ 2026.269000] ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[ 2026.269000] PCI: Setting latency timer of device 0000:00:07.3 to 64
[ 2026.269000] usb usb2: root hub lost power or was reset
[ 2026.282000] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
[ 2026.282000] PCI: Setting latency timer of device 0000:00:07.5 to 64
[ 2027.240000] pccard: CardBus card inserted into slot 0
[ 2027.844000] pccard: PCMCIA card inserted into slot 1
[ 2027.844000] pcmcia: registering new device pcmcia1.0

YEP! Again!

[ 2087.910000] PM: Writing back config space on device 0000:00:0e.0 at offset 3 (was 8, writing 4008)
[ 2087.910000] PM: Writing back config space on device 0000:00:0e.0 at offset 1 (was 2100012, writing 2100016)
[ 2087.961000] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9]  MMIO=[e8004000-e80047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[ 2087.965000] PM: Writing back config space on device 0000:00:10.0 at offset 5 (was 0, writing e8004800)
[ 2087.965000] PM: Writing back config space on device 0000:00:10.0 at offset 4 (was 1, writing 1801)
[ 2087.965000] PM: Writing back config space on device 0000:00:10.0 at offset 1 (was 2900000, writing 2900003)
[ 2087.967000] pnp: Device 00:08 activated.
[ 2087.967000] pnp: Failed to activate device 00:0a.
[ 2087.967000] pnp: Failed to activate device 00:0b.
[ 2089.036000]  usbdev1.2_ep00: PM: resume from 0, parent 1-2 still 2
[ 2089.036000] usbhid 1-2:1.0: PM: resume from 2, parent 1-2 still 2
[ 2089.036000]  usbdev1.2_ep81: PM: resume from 0, parent 1-2:1.0 still 2
[ 2089.036000]  usbdev1.2: PM: resume from 0, parent 1-2 still 2
[ 2089.108000] usb 1-2: USB disconnect, address 2
[ 2089.314000] usb 1-2: new low speed USB device using uhci_hcd and address 3
[ 2089.332000] pcmcia: registering new device pcmcia1.1
[ 2089.332000] pcmcia: request for exclusive IRQ could not be fulfilled.
[ 2089.332000] pcmcia: the driver needs updating to supported shared IRQ lines.
[ 2089.372000] 1.1: ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A
[ 2089.374000] pcmcia: request for exclusive IRQ could not be fulfilled.
[ 2089.374000] pcmcia: the driver needs updating to supported shared IRQ lines.
[ 2089.417000] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8
[ 2089.417000]   8K FIFO split 5:3 Rx:Tx, auto xcvr
[ 2089.458000] usb 1-2: configuration #1 chosen from 1 choice
[ 2089.474000] input: HID 062a:0001 as /class/input/input17
[ 2089.474000] input: USB HID v1.10 Mouse [HID 062a:0001] on usb-0000:00:07.2-2
[ 2093.871000] 8139too Fast Ethernet driver 0.9.28
[ 2093.873000] ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
[ 2093.874000] eth0: RealTek RTL8139 at 0xe0a72800, 08:00:46:6e:93:a8, IRQ 10
[ 2093.874000] eth0:  Identified 8139 chip type 'RTL-8139C'
[ 2095.392000] input: Power Button (FF) as /class/input/input18
[ 2095.393000] ACPI: Power Button (FF) [PWRF]
[ 2095.394000] input: Sleep Button (CM) as /class/input/input19
[ 2095.396000] ACPI: Sleep Button (CM) [SBTN]
[ 2095.397000] input: Lid Switch as /class/input/input20
[ 2095.398000] ACPI: Lid Switch [LID]
[ 2095.693000] ACPI: Thermal Zone [THRM] (62 C)
[ 2095.807000] ACPI: AC Adapter [ACAD] (on-line)
[ 2098.010000] ACPI: Battery Slot [BAT1] (battery present)
[ 2098.038000] ACPI: Battery Slot [BAT2] (battery absent)
[ 2102.654000] eth1: no IPv6 routers present
[ 2154.791000] pccard: card ejected from slot 0
[ 2174.376000] pccard: card ejected from slot 1
[ 2175.533000] ACPI: PCI interrupt for device 0000:00:10.0 disabled
[ 2178.997000] Suspending console(s)
[ 2179.010000]  usbdev2.1: PM: suspend 0->2, parent usb2 already 2
[ 2179.010000]  usbdev2.1_ep81: PM: suspend 0->2, parent 2-0:1.0 already 2
[ 2179.010000] hub 2-0:1.0: PM: suspend 2->2, parent usb2 already 2
[ 2179.010000]  usbdev2.1_ep00: PM: suspend 0->2, parent usb2 already 2
[ 2180.469000] pnp: Device 00:08 disabled.
[ 2180.485000] ACPI: PCI interrupt for device 0000:00:07.5 disabled
[ 2180.498000] ACPI: PCI interrupt for device 0000:00:07.3 disabled
[ 2180.509000] ACPI: PCI interrupt for device 0000:00:07.2 disabled
[ 2180.531000] Back to C!
[ 2180.535000] Applying VIA southbridge workaround.
[ 2180.535000] PCI: Disabling Via external APIC routing
[ 2181.319000] PM: Writing back config space on device 0000:00:00.0 at offset 1 (was 2100006, writing 12100006)
[ 2181.319000] PM: Writing back config space on device 0000:00:01.0 at offset 9 (was fff0, writing 38003800)
[ 2181.319000] PCI: Setting latency timer of device 0000:00:01.0 to 64
[ 2181.330000] ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[ 2181.330000] PCI: Setting latency timer of device 0000:00:07.2 to 64
[ 2181.330000] usb usb1: root hub lost power or was reset
[ 2181.356000] ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[ 2181.356000] PCI: Setting latency timer of device 0000:00:07.3 to 64
[ 2181.356000] usb usb2: root hub lost power or was reset
[ 2182.038000] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
[ 2182.038000] PCI: Setting latency timer of device 0000:00:07.5 to 64
[ 2182.676000] pccard: PCMCIA card inserted into slot 1
[ 2182.676000] pcmcia: registering new device pcmcia1.0
[ 2182.734000] pcmcia: request for exclusive IRQ could not be fulfilled.
[ 2182.734000] pcmcia: the driver needs updating to supported shared IRQ lines.
[ 2182.777000] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8
[ 2182.777000]   8K FIFO split 5:3 Rx:Tx, auto xcvr
[ 2182.777000] pcmcia: registering new device pcmcia1.1
[ 2182.777000] pcmcia: request for exclusive IRQ could not be fulfilled.
[ 2182.777000] pcmcia: the driver needs updating to supported shared IRQ lines.
[ 2182.818000] 1.1: ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A
[ 2182.831000] PM: Writing back config space on device 0000:00:0e.0 at offset 3 (was 8, writing 4008)
[ 2182.831000] PM: Writing back config space on device 0000:00:0e.0 at offset 1 (was 2100012, writing 2100016)
[ 2182.882000] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9]  MMIO=[e8004000-e80047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[ 2182.886000] PM: Writing back config space on device 0000:00:10.0 at offset 5 (was 0, writing e8004800)
[ 2182.886000] PM: Writing back config space on device 0000:00:10.0 at offset 4 (was 1, writing 1801)
[ 2182.886000] PM: Writing back config space on device 0000:00:10.0 at offset 1 (was 2900000, writing 2900003)
[ 2182.888000] pnp: Device 00:08 activated.
[ 2182.888000] pnp: Failed to activate device 00:0a.
[ 2182.888000] pnp: Failed to activate device 00:0b.
[ 2183.798000] usb 1-2: USB disconnect, address 3
[ 2184.004000] usb 1-2: new low speed USB device using uhci_hcd and address 4
[ 2184.146000] usb 1-2: configuration #1 chosen from 1 choice
[ 2184.162000] input: HID 062a:0001 as /class/input/input21
[ 2184.162000] input: USB HID v1.10 Mouse [HID 062a:0001] on usb-0000:00:07.2-2
[ 2186.486000] 8139too Fast Ethernet driver 0.9.28
[ 2186.487000] ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
[ 2186.489000] eth0: RealTek RTL8139 at 0xe0a72800, 08:00:46:6e:93:a8, IRQ 10
[ 2186.489000] eth0:  Identified 8139 chip type 'RTL-8139C'
[ 2188.033000] input: Power Button (FF) as /class/input/input22
[ 2188.034000] ACPI: Power Button (FF) [PWRF]
[ 2188.035000] input: Sleep Button (CM) as /class/input/input23
[ 2188.035000] ACPI: Sleep Button (CM) [SBTN]
[ 2188.036000] input: Lid Switch as /class/input/input24
[ 2188.037000] ACPI: Lid Switch [LID]
[ 2188.675000] ACPI: Thermal Zone [THRM] (57 C)
[ 2188.718000] ACPI: AC Adapter [ACAD] (on-line)
[ 2194.020000] eth1: no IPv6 routers present
[ 2200.209000] ACPI: Battery Slot [BAT1] (battery present)
[ 2200.213000] ACPI: Battery Slot [BAT2] (battery absent)
[ 2262.913000] pccard: card ejected from slot 1
[ 2263.924000] ACPI: PCI interrupt for device 0000:00:10.0 disabled
[ 2267.459000] Suspending console(s)
[ 2267.472000]  usbdev2.1: PM: suspend 0->2, parent usb2 already 2
[ 2267.472000]  usbdev2.1_ep81: PM: suspend 0->2, parent 2-0:1.0 already 2
[ 2267.472000] hub 2-0:1.0: PM: suspend 2->2, parent usb2 already 2
[ 2267.472000]  usbdev2.1_ep00: PM: suspend 0->2, parent usb2 already 2
[ 2268.920000] pnp: Device 00:08 disabled.
[ 2268.936000] ACPI: PCI interrupt for device 0000:00:07.5 disabled
[ 2268.949000] ACPI: PCI interrupt for device 0000:00:07.3 disabled
[ 2268.960000] ACPI: PCI interrupt for device 0000:00:07.2 disabled

I recompiled with wireless, rebooted and it's all ok:

[  364.711000] Back to C!
[  364.712000] Applying VIA southbridge workaround.
[  364.712000] PCI: Disabling Via external APIC routing
[  364.741000] PM: Writing back config space on device 0000:00:00.0 at offset 1 (was 2100006, writing b2100006)
[  364.741000] PM: Writing back config space on device 0000:00:01.0 at offset 9 (was fff0, writing 38003800)
[  364.741000] PCI: Setting latency timer of device 0000:00:01.0 to 64
[  364.754000] ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[  364.755000] PCI: Setting latency timer of device 0000:00:07.2 to 64
[  364.755000] usb usb1: root hub lost power or was reset
[  364.766000] ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
[  364.766000] PCI: Setting latency timer of device 0000:00:07.3 to 64
[  364.766000] usb usb2: root hub lost power or was reset
[  364.803000] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
[  364.803000] PCI: Setting latency timer of device 0000:00:07.5 to 64
[  365.761000] pccard: CardBus card inserted into slot 0
[  365.819000] rtl8180: Configuring chip resources
[  365.819000] PCI: Enabling device 0000:02:00.0 (0000 -> 0003)
[  365.819000] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9
[  365.819000] PCI: Setting latency timer of device 0000:02:00.0 to 64
[  365.819000] rtl8180: Memory mapped space @ 0x34000000
[  365.819000] rtl8180: MAC controller is a RTL8180 (v. F)

(rtl8180 deleted)

[  367.007000] pccard: PCMCIA card inserted into slot 1
[  367.007000] pcmcia: registering new device pcmcia1.0
[  367.061000] pcmcia: request for exclusive IRQ could not be fulfilled.
[  367.061000] pcmcia: the driver needs updating to supported shared IRQ lines.
[  367.112000] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8
[  367.112000]   8K FIFO split 5:3 Rx:Tx, auto xcvr
[  367.112000] pcmcia: registering new device pcmcia1.1
[  367.112000] pcmcia: request for exclusive IRQ could not be fulfilled.
[  367.112000] pcmcia: the driver needs updating to supported shared IRQ lines.
[  367.153000] 1.1: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

well, now the modem is S1. Not too much trouble, it's doing this since
immemorial time.

[  367.165000] PM: Writing back config space on device 0000:00:0e.0 at offset 3 (was 8, writing 4008)
[  367.165000] PM: Writing back config space on device 0000:00:0e.0 at offset 1 (was 2100012, writing 2100016)
[  367.216000] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9]  MMIO=[e8004000-e80047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[  367.222000] PM: Writing back config space on device 0000:00:10.0 at offset 5 (was 0, writing e8004800)
[  367.222000] PM: Writing back config space on device 0000:00:10.0 at offset 4 (was 1, writing 1801)
[  367.222000] PM: Writing back config space on device 0000:00:10.0 at offset 1 (was 2900000, writing 2900003)
[  367.223000] pnp: Device 00:08 activated.
[  367.223000] pnp: Failed to activate device 00:0a.
[  367.223000] pnp: Failed to activate device 00:0b.
[  368.041000] Associated successfully
[  368.041000] Using B rates
[  368.080000]  usbdev1.2_ep00: PM: resume from 0, parent 1-2 still 2
[  368.080000] usbhid 1-2:1.0: PM: resume from 2, parent 1-2 still 2
[  368.080000]  usbdev1.2_ep81: PM: resume from 0, parent 1-2:1.0 still 2
[  368.080000]  usbdev1.2: PM: resume from 0, parent 1-2 still 2
[  368.151000] usb 1-2: USB disconnect, address 2
[  368.357000] usb 1-2: new low speed USB device using uhci_hcd and address 3
[  368.498000] usb 1-2: configuration #1 chosen from 1 choice
[  368.515000] input: HID 062a:0001 as /class/input/input8
[  368.515000] input: USB HID v1.10 Mouse [HID 062a:0001] on usb-0000:00:07.2-2
[  369.826000] 8139too Fast Ethernet driver 0.9.28
[  369.827000] ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
[  369.828000] eth0: RealTek RTL8139 at 0xe0a98800, 08:00:46:6e:93:a8, IRQ 10
[  369.828000] eth0:  Identified 8139 chip type 'RTL-8139C'
[  371.247000] input: Power Button (FF) as /class/input/input9
[  371.297000] ACPI: Power Button (FF) [PWRF]
[  371.359000] input: Sleep Button (CM) as /class/input/input10
[  371.359000] ACPI: Sleep Button (CM) [SBTN]
[  371.402000] input: Lid Switch as /class/input/input11
[  371.403000] ACPI: Lid Switch [LID]
[  371.607000] ACPI: Thermal Zone [THRM] (54 C)
[  371.661000] ACPI: AC Adapter [ACAD] (on-line)
[  372.010000] ACPI: Battery Slot [BAT1] (battery present)
[  372.020000] ACPI: Battery Slot [BAT2] (battery absent)



--
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Tue, 29 May 2007, Romano Giannetti wrote:
>
> - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> haven't tested hibernation) with a 2.6.21.2 with that patch, applied
> manually. The system did suspend and resume nicely even compiling a
> kernel and opening openoffice. Normally (le me stress _normally_) no
> delay was apparent on resume. I do not know how dangerous is this... :-)
> 
> - The bad (?) news. One time out of 7 I had the 60 seconds delay.

Interesting. If you can re-create it, please do the sysrq-T thing again, 
to see what's up. (Also, you might do "sysrq-p", which gives the current 
process data, which sysrq-T does not).

			Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Romano Giannetti]

On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
> 
> On Tue, 29 May 2007, Romano Giannetti wrote:
> >
> > - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> > haven't tested hibernation) with a 2.6.21.2 with that patch, applied
> > manually. The system did suspend and resume nicely even compiling a
> > kernel and opening openoffice. Normally (le me stress _normally_) no
> > delay was apparent on resume. I do not know how dangerous is this... :-)
> > 
> > - The bad (?) news. One time out of 7 I had the 60 seconds delay.
> 
> Interesting. If you can re-create it, please do the sysrq-T thing again, 
> to see what's up. (Also, you might do "sysrq-p", which gives the current 
> process data, which sysrq-T does not).


I've got it, but I had a problem: I filled the dmesg buffer. I will try
to find where to enlarge it. I have posted the partial result to: 

http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume-nofreeze.txt

in the hope that something can be used. I am running 2.6.21.2, with the
"no freeze kthreads at all" patch from Matthew Garrett, with this
add-on:

--- drivers/base/firmware_class.c.orig	2007-05-30 12:19:59.000000000 +0200
+++ drivers/base/firmware_class.c	2007-05-29 19:39:56.000000000 +0200
@@ -471,7 +471,11 @@
                  struct device *device)
 {
         int uevent = 1;
-        return _request_firmware(firmware_p, name, device, uevent);
+        int rval;
+        printk(KERN_ERR "FW: requesting firmware (sync) for %s\n", name);
+        rval = _request_firmware(firmware_p, name, device, uevent);
+        printk(KERN_ERR "FW: return %d\n", rval);
+        return rval;
 }
 
 /**
@@ -545,7 +549,9 @@
 	struct task_struct *task;
 	struct firmware_work *fw_work = kmalloc(sizeof (struct firmware_work),
 						GFP_ATOMIC);
-
+        
+        printk(KERN_ERR "FW: requesting firmware (async) for %s\n", name);
+        
 	if (!fw_work)
 		return -ENOMEM;
 	if (!try_module_get(module)) {
@@ -569,8 +575,12 @@
 		fw_work->cont(NULL, fw_work->context);
 		module_put(fw_work->module);
 		kfree(fw_work);
+                printk(KERN_ERR "FW: failing return %d\n", PTR_ERR(task));
 		return PTR_ERR(task);
 	}
+        
+        printk(KERN_ERR "FW: normal return\n");
+
 	return 0;
 }
 




-- 
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.
 


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Randy Dunlap]

On Wed, 30 May 2007 12:26:57 +0200 Romano Giannetti wrote:

> 
> On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
> > 
> > On Tue, 29 May 2007, Romano Giannetti wrote:
> > >
> > > - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> > > haven't tested hibernation) with a 2.6.21.2 with that patch, applied
> > > manually. The system did suspend and resume nicely even compiling a
> > > kernel and opening openoffice. Normally (le me stress _normally_) no
> > > delay was apparent on resume. I do not know how dangerous is this... :-)
> > > 
> > > - The bad (?) news. One time out of 7 I had the 60 seconds delay.
> > 
> > Interesting. If you can re-create it, please do the sysrq-T thing again, 
> > to see what's up. (Also, you might do "sysrq-p", which gives the current 
> > process data, which sysrq-T does not).
> 
> 
> I've got it, but I had a problem: I filled the dmesg buffer. I will try
> to find where to enlarge it. I have posted the partial result to: 

use 'dmesg -s 100000' if it's just dmesg(8) that needs help.
If it's the kernel buffer filling up, you can rebuild the kernel
after changing CONFIG_LOG_BUF_SHIFT, but it's easier just to boot
using this:
	log_buf_len=n	Sets the size of the printk ring buffer, in bytes.
			Format: { n | nk | nM }
			n must be a power of two.  The default size
			is set in the kernel config file.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > As far as I can tell the PPC code simply shuts down the devices without 
> > worrying about userspace at all. If this was reliable, what prevents us 
> > from simply disabling the freezer for STR?
> 
> Personally, I think that's the right thing to do. 
> 
> And by "disabling the freezer", I think we should just not call it at all. 
> However, sadly, right now it's called from common code. I'll happily take 
> a tested patch to split that code sequence up, and try to do it in 2.6.23, 
> if somebody has the energy (I'm getting to the point where I may just do 
> it myself, but my lazy nature still hopes for a STR person to step 
> forward).

I guess we should warn the driver authors, then; and decide what
driver authors should do.

If I'm video4linux driver for grabbing screen, have been suspended,
and someone asks me to read a frame, should I

a) return -ESORRYIMSUSPENDED

b) just block the caller

?

a) seems ugly to my eyes (userspace should not know about suspend).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Mon, 28 May 2007, Pavel Machek wrote:
> 
> I guess we should warn the driver authors, then; and decide what driver 
> authors should do.

Drivers really shouldn't do anythign at all.

> If I'm video4linux driver for grabbing screen, have been suspended, and 
> someone asks me to read a frame, should I
> 
> a) return -ESORRYIMSUSPENDED
> 
> b) just block the caller

The "subsystem" thing should have stopped the queues, and the device 
should never even _see_ this.

Before we suspend a device, we call the subsystem that that device has 
been registered with. Ie, we have code like this:

	if (dev->class && dev->class->suspend)
		error = dev->class->suspend(dev, state);

which was very much designed so that individual devices wouldn't have to 
always know - if the upper layer devices for that class can handle these 
things, they should.

Do people actually _do_ this, right now? No. But we do actually have the 
infrastructure, and I think we have one or two classes that actually do 
use it (at least the "rfkill_class" has a suspend member, dunno how well 
this model actually works).

I think Greg had some patches to make network drivers use this, for 
example. Network drivers right now all end up doing stuff that really 
doesn't belong in the driver at all when they suspend, and the 
infrastructure _should_ just do it for them (ie do all the _network_ 
related stuff, as opposed to the actual hardware-related stuff).

(Examples of things that we probably _should_ do for network devices on a 
class level:

	suspend:
		netif_poll_disable()
		if (netif_running(dev))
			dev->stop(dev);

	resume:
		if (netif_running(dev))
			dev->start(dev);
		netif_poll_enable(dev);

or something similar).

			Linus

Re: [stable] pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Greg KH]

On Mon, May 28, 2007 at 09:53:50AM -0700, Linus Torvalds wrote:
> 
> Before we suspend a device, we call the subsystem that that device has 
> been registered with. Ie, we have code like this:
> 
> 	if (dev->class && dev->class->suspend)
> 		error = dev->class->suspend(dev, state);
> 
> which was very much designed so that individual devices wouldn't have to 
> always know - if the upper layer devices for that class can handle these 
> things, they should.
> 
> Do people actually _do_ this, right now? No. But we do actually have the 
> infrastructure, and I think we have one or two classes that actually do 
> use it (at least the "rfkill_class" has a suspend member, dunno how well 
> this model actually works).
> 
> I think Greg had some patches to make network drivers use this, for 
> example. Network drivers right now all end up doing stuff that really 
> doesn't belong in the driver at all when they suspend, and the 
> infrastructure _should_ just do it for them (ie do all the _network_ 
> related stuff, as opposed to the actual hardware-related stuff).

Yes, I started to work on it, as it is the correct thing to do, but got
sidetracked, sorry :(

> (Examples of things that we probably _should_ do for network devices on a 
> class level:
> 
> 	suspend:
> 		netif_poll_disable()
> 		if (netif_running(dev))
> 			dev->stop(dev);
> 
> 	resume:
> 		if (netif_running(dev))
> 			dev->start(dev);
> 		netif_poll_enable(dev);
> 
> or something similar).

I'll try to hack something together later this week along this line and
see how it works...

thanks,

greg k-h

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!

> > I guess we should warn the driver authors, then; and decide what driver 
> > authors should do.
> 
> Drivers really shouldn't do anythign at all.

*)

> > If I'm video4linux driver for grabbing screen, have been suspended, and 
> > someone asks me to read a frame, should I
> > 
> > a) return -ESORRYIMSUSPENDED
> > 
> > b) just block the caller
> 
> The "subsystem" thing should have stopped the queues, and the device 
> should never even _see_ this.

Okay, _if_ there's a subsystem, subsystem should have stopped the
queues. End result should be that userspace is blocked when trying to
access suspended device/suspended subsystem.

I guess we are in violent agreement.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Linus Torvalds]

On Thu, 24 May 2007, Linus Torvalds wrote:
> 
> Then, what you do is:
>  - stop user space
>  - suspend
>  - resume
>  - start user space

Btw, this is where things like "udevd" can be really problematic. That 
whole "uevent over netlink" stuff is really nasty for things like this.

It's quite possible that even for user-level threads, we simply MUST NOT 
freeze them the way we do. Exactly because of deadlocks.

I'm personally really really convinced that the whole freezer thing is a 
total disaster. I don't know how anybody can even imagine anything else. 
It's simply deadlock city.

We should freeze IO, not processes.

		Linus

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

On Thu 2007-05-24 15:23:56, Linus Torvalds wrote:
> 
> 
> On Thu, 24 May 2007, Linus Torvalds wrote:
> > 
> > Then, what you do is:
> >  - stop user space
> >  - suspend
> >  - resume
> >  - start user space
> 
> Btw, this is where things like "udevd" can be really problematic. That 
> whole "uevent over netlink" stuff is really nasty for things like this.
> 
> It's quite possible that even for user-level threads, we simply MUST NOT 
> freeze them the way we do. Exactly because of deadlocks.

Killing freezer will not help you in any way. udevd may need access to
arbitrary devices. You will still have the deadlocks, only this time
userland will be involved, too.

Just load the firmware before starting suspend.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

Hi!
> 
> On Fri, 25 May 2007, Pavel Machek wrote:
> > > 
> > > Equally arguably, we should just have a "resume_late()" call that can be 
> > > used to do this after everything is up and running.
> > 
> > Yes, we can do that. But userland will see devices "not there" for a
> > few seconds after boot.
> 
> No they won't.
> 
> Why the HELL cannot you realize that kernel threads are different?
> 
> The right thing to do is AND HAS ALWAYS BEEN, to stop and start user 
> threads only around the whole thing.
> 
> Don't touch those kernel threads. Stop freezing them.
> 
> Then, what you do is:
>  - stop user space
>  - suspend
>  - resume
~~~~~~~~~~~
notice how resume of pcmcia card that poor user has needs
userspace. So this does not work.

>  - start user space

My proposed solution is "fix pcmcia to load firmware before suspend
even starts"

- HERE
>  - stop user space
>  - suspend
>  - resume
>  - start user space

Maybe freezer causes cancer in small children, but lets not blame it
for this.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Henrique de Moraes Holschuh]

On Fri, 25 May 2007, Pavel Machek wrote:
> My proposed solution is "fix pcmcia to load firmware before suspend
> even starts"

s/pcmcia/all drivers that load firmware/ if you are going to go that way.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Pavel Machek]

On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote:
> On Fri, 25 May 2007, Pavel Machek wrote:
> > My proposed solution is "fix pcmcia to load firmware before suspend
> > even starts"
> 
> s/pcmcia/all drivers that load firmware/ if you are going to go that way.

I'm not "going that way". It always was that way. If driver tries to
load firmware during suspend, it will deadlock.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

[Rafael J. Wysocki]

On Friday, 25 May 2007 01:19, Pavel Machek wrote:
> On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote:
> > On Fri, 25 May 2007, Pavel Machek wrote:
> > > My proposed solution is "fix pcmcia to load firmware before suspend
> > > even starts"
> > 
> > s/pcmcia/all drivers that load firmware/ if you are going to go that way.
> 
> I'm not "going that way". It always was that way. If driver tries to
> load firmware during suspend, it will deadlock.

Exactly.

And the freezing of user land has _nothing_ to do with that.  The fact is
the user land is not reliable while device drivers are being suspended,
regardless of whether it's frozen at that point or not.

BTW, we are going (or at least I'm going) to untangle the hibernation and
suspend code paths, but I have limited time for that and I just _can't_ do this
any faster.  In the meantime, we have bugs like this one that need to be fixed
_within_ the current limitations, because we just _can't_ remove these
limitations overnight..

Greetings,
Rafael

Re: [patch 00/69] -stable review

[Romano Giannetti]

(resent, using gmail)

On Mon, 2007-05-21 at 14:25 -0700, Chris Wright wrote: 
> * Linus Torvalds (torvalds@linux-foundation.org) wrote:
> > On Mon, 21 May 2007, Chuck Ebbert wrote:
> > > 
> > > What happened to:
> > > 
> > > "Fix ACPI suspend / device suspend ordering problem"
> > > 52ade9b3b97fd3bea42842a056fe0786c28d0555
> > 
> > I would suggest waiting on problem reports for that one a bit longer.
> 
> It's queued for the next 21.y stable, to give it a little more time.
> 

It's an useful patch for me. Without it, my sony vaio pcg-fx701 was very
erratic in resume (kernel 2.6.21.1; it works well with the .17 ubuntu
kernel). With this patch, I have done 7 cycles flawlessly. Even the
out-of-tree rtl8180 wireless driver [1] works ok across resumes. 

The only problem is that there is an gaping delay of 60 seconds (more or
less) on resume. I have the syslog trace copied below; could be a timer
problem? Is it known? (It is scaring because the laptop seems dead
during this time. I'm not and expert, but it seems here:

[    1.617972] pcmcia: registering new device pcmcia1.0 
[   61.612517] PM: Writing back config space on device 0000:00:[...]

...and time do not advance.

Romano 

[1] http://rtl-wifi.sourceforge.net/wiki/Main_Page

May 22 17:55:28 localhost kernel: [    0.565042] Back to C!
May 22 17:55:28 localhost kernel: [    0.566588] Applying VIA southbridge workaround.
May 22 17:55:28 localhost kernel: [    0.566598] PCI: Disabling Via external APIC routing
May 22 17:55:28 localhost kernel: [    0.595156] PM: Writing back config space on device 0000:00:00.0 at offset 1 (was 2100006, writing b2100006)
May 22 17:55:28 localhost kernel: [    0.595181] PM: Writing back config space on device 0000:00:01.0 at offset 9 (was fff0, writing 40004000)
May 22 17:55:28 localhost kernel: [    0.595207] PCI: Setting latency timer of device 0000:00:01.0 to 64
May 22 17:55:28 localhost kernel: [    0.605346] ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
May 22 17:55:28 localhost kernel: [    0.605355] PCI: Setting latency timer of device 0000:00:07.2 to 64
May 22 17:55:28 localhost kernel: [    0.605395] usb usb1: root hub lost power or was reset
May 22 17:55:28 localhost kernel: [    0.616334] ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
May 22 17:55:28 localhost kernel: [    0.616342] PCI: Setting latency timer of device 0000:00:07.3 to 64
May 22 17:55:28 localhost kernel: [    0.616379] usb usb2: root hub lost power or was reset
May 22 17:55:28 localhost kernel: [    0.629345] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
May 22 17:55:28 localhost kernel: [    0.629356] PCI: Setting latency timer of device 0000:00:07.5 to 64
May 22 17:55:28 localhost kernel: [    1.617815] pccard: PCMCIA card inserted into slot 1
May 22 17:55:28 localhost kernel: [    1.617972] pcmcia: registering new device pcmcia1.0
May 22 17:55:28 localhost kernel: [   61.612517] PM: Writing back config space on device 0000:00:0e.0 at offset 3 (was 8, writing 4008)
May 22 17:55:28 localhost kernel: [   61.612526] PM: Writing back config space on device 0000:00:0e.0 at offset 1 (was 2100012, writing 2100016)
May 22 17:55:28 localhost kernel: [   61.663580] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9]  MMIO=[e8004000-e80047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
May 22 17:55:28 localhost kernel: [   61.666769] PM: Writing back config space on device 0000:00:10.0 at offset 5 (was 0, writing e8004800)
May 22 17:55:28 localhost kernel: [   61.666777] PM: Writing back config space on device 0000:00:10.0 at offset 4 (was 1, writing 1801)
May 22 17:55:28 localhost kernel: [   61.666785] PM: Writing back config space on device 0000:00:10.0 at offset 1 (was 2900000, writing 2900003)
May 22 17:55:28 localhost kernel: [   61.668452] pnp: Device 00:08 activated.
May 22 17:55:28 localhost kernel: [   61.668484] pnp: Failed to activate device 00:0a.
May 22 17:55:28 localhost kernel: [   61.668501] pnp: Failed to activate device 00:0b.
May 22 17:55:28 localhost kernel: [   62.713961]  usbdev1.2_ep00: PM: resume from 0, parent 1-2 still 2
May 22 17:55:28 localhost kernel: [   62.713968] usbhid 1-2:1.0: PM: resume from 2, parent 1-2 still 2
May 22 17:55:28 localhost kernel: [   62.713972]  usbdev1.2_ep81: PM: resume from 0, parent 1-2:1.0 still 2
May 22 17:55:28 localhost kernel: [   62.713977]  usbdev1.2: PM: resume from 0, parent 1-2 still 2
May 22 17:55:28 localhost kernel: [   62.714451] Restarting tasks ... done.
May 22 17:55:28 localhost kernel: [   62.799267] pcmcia: request for exclusive IRQ could not be fulfilled.
May 22 17:55:28 localhost kernel: [   62.799279] pcmcia: the driver needs updating to supported shared IRQ lines.
May 22 17:55:28 localhost kernel: [   62.842007] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8
May 22 17:55:28 localhost kernel: [   62.842019]   8K FIFO split 5:3 Rx:Tx, auto xcvr
May 22 17:55:28 localhost kernel: [   62.843128] pcmcia: registering new device pcmcia1.1
May 22 17:55:28 localhost kernel: [   62.843327] pcmcia: request for exclusive IRQ could not be fulfilled.
May 22 17:55:28 localhost kernel: [   62.843331] pcmcia: the driver needs updating to supported shared IRQ lines.
May 22 17:55:28 localhost kernel: [   62.883453] usb 1-2: USB disconnect, address 2
May 22 17:55:28 localhost firmware_helper[6082]: main: error loading '/lib/firmware/3CXEM556.cis' for device '/class/firmware/1.0' with driver '(unknown)'
May 22 17:55:28 localhost kernel: [   62.898934] 1.1: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
May 22 17:55:28 localhost gnome-power-manager: (romano) Resuming computer
May 22 17:55:29 localhost kernel: [   63.122753] usb 1-2: new low speed USB device using uhci_hcd and address 3
May 22 17:55:29 localhost kernel: [   63.266890] usb 1-2: configuration #1 chosen from 1 choice
May 22 17:55:29 localhost kernel: [   63.283145] input: HID 062a:0001 as /class/input/input8
May 22 17:55:29 localhost kernel: [   63.283254] input: USB HID v1.10 Mouse [HID 062a:0001] on usb-0000:00:07.2-2
May 22 17:55:31 localhost kernel: [   65.443554] tsdev (compaq touchscreen emulation) is scheduled for removal.
May 22 17:55:31 localhost kernel: [   65.443560] See Documentation/feature-removal-schedule.txt for details.
May 22 17:55:32 localhost kernel: [   66.383183] 8139too Fast Ethernet driver 0.9.28
May 22 17:55:32 localhost kernel: [   66.384536] ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
May 22 17:55:32 localhost kernel: [   66.385555] eth0: RealTek RTL8139 at 0xe0bae800, 08:00:46:6e:93:a8, IRQ 10
May 22 17:55:32 localhost kernel: [   66.385562] eth0:  Identified 8139 chip type 'RTL-8139C'
May 22 17:55:33 localhost kernel: [   67.631633] input: Power Button (FF) as /class/input/input9
May 22 17:55:33 localhost kernel: [   67.631865] ACPI: Power Button (FF) [PWRF]
May 22 17:55:33 localhost kernel: [   67.632345] input: Sleep Button (CM) as /class/input/input10
May 22 17:55:33 localhost kernel: [   67.642920] ACPI: Sleep Button (CM) [SBTN]
May 22 17:55:33 localhost kernel: [   67.643101] input: Lid Switch as /class/input/input11
May 22 17:55:33 localhost kernel: [   67.643130] ACPI: Lid Switch [LID]
May 22 17:55:33 localhost kernel: [   68.336279] ACPI: Thermal Zone [THRM] (51 C)
May 22 17:55:34 localhost kernel: [   68.494424] ACPI: AC Adapter [ACAD] (on-line)
May 22 17:55:34 localhost kernel: [   68.853089] ACPI: Battery Slot [BAT1] (battery present)
May 22 17:55:34 localhost kernel: [   68.857492] ACPI: Battery Slot [BAT2] (battery absent)
May 22 17:55:34 localhost anacron[6386]: Anacron 2.3 started on 2007-05-22
May 22 17:55:34 localhost anacron[6386]: Normal exit (0 jobs run)

Re: [patch 00/69] -stable review

[Chris Wright]

* Chris Wright (chrisw@sous-sol.org) wrote:
> This is the start of the stable review cycle for the 2.6.21.2 release.
> There are 69 patches in this series, all will be posted as a response
> to this one.

Roll-up patch available at:
	http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.21.2-rc1.{gz,bz2}

thanks,
-chris