Re: [PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
"Thomas Maier" <[EMAIL PROTECTED]> writes: > this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: > > - update documentation > - removed DECLARE_BUF_AS_STRING macro This part looks good. > - use clear_bdi_congested/set_bdi_congested functions directly instead of old > wrappers I'm unsure about this one. What's the point of having the blk_clear_queue_congested()/blk_set_queue_congested() functions if they are not supposed to be used? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Thomas Maier [EMAIL PROTECTED] writes: this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - removed DECLARE_BUF_AS_STRING macro This part looks good. - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers I'm unsure about this one. What's the point of having the blk_clear_queue_congested()/blk_set_queue_congested() functions if they are not supposed to be used? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Please attach patches as inline text, not as a binary file, so that we can all read it. Thomas Maier wrote: Hello, this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers - removed DECLARE_BUF_AS_STRING macro Signed-off-by: Thomas Maier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Hello, this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers - removed DECLARE_BUF_AS_STRING macro Signed-off-by: Thomas Maier <[EMAIL PROTECTED]> pktcdvd-2.6.20-rc1-mm1.patch Description: Binary data
[PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Hello, this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers - removed DECLARE_BUF_AS_STRING macro Signed-off-by: Thomas Maier [EMAIL PROTECTED] pktcdvd-2.6.20-rc1-mm1.patch Description: Binary data
Re: [PATCH 1/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
Please attach patches as inline text, not as a binary file, so that we can all read it. Thomas Maier wrote: Hello, this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: - update documentation - use clear_bdi_congested/set_bdi_congested functions directly instead of old wrappers - removed DECLARE_BUF_AS_STRING macro Signed-off-by: Thomas Maier [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
Hi, On Friday, 22 December 2006 18:30, Larry Finger wrote: > I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on > an HPC nx6325, with no luck, so far, although I'm using a firmware that has > been reported to work with these boxes > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29). > > The driver loads and seems to operate the hardware to some extent, but there > seems to be a problem with interrupts. Namely, the chip doesn't seem to > generate any. > Raphael J. Wysocki wrote: > > > Right after a fresh 'modprobe bcm43xx' I get the following messages in > dmesg: > > > bcm43xx driver > > ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 18 > > PCI: Setting latency timer of device :30:00.0 to 64 > > bcm43xx: Chip ID 0x4311, rev 0x1 > > bcm43xx: Number of cores: 4 > > bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 > > bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 > > bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 > > bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 > > bcm43xx: PHY connected > > bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 > > bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) > > bcm43xx: Radio turned off > > bcm43xx: Radio turned off > > PM: Adding info for No Bus:eth1 > > printk: 3 messages suppressed. > > SoftMAC: ASSERTION FAILED (0) at: > > net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() > > > > but, strangely enough, eth1 does not appear, but eth2 appears instead: > > > > Usually the problem generates an oops, but I think your problem is due to the > changes in the work > struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not > propagated through the system. > > You should apply the work_struct2 patch attached. If your computer has a > switch to kill the RF, you > may also wish to apply the radio_hwenable patch, which should cause the radio > LED to be turned on. > > The selection of eth2 rather than eth1 is probably due to the rules in > /etc/udev/rules.d/30-net_persistent_names.rules. Ah, I'll check that, thanks. It used to be eth1, though, and I haven't changed the udev configuration myself. > When I boot a softmac version, my bcm43xx device is > wlan0, but when I boot the d80211 version, it is eth1. I have a second > bcm43xx card, which becomes > eth2 under softmac. Thanks for the patch. In the meantime I've browsed the bcm43xx-dev archives and found some other interesting patches for me to try. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
Hi, On Friday, 22 December 2006 18:30, Larry Finger wrote: I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on an HPC nx6325, with no luck, so far, although I'm using a firmware that has been reported to work with these boxes (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29). The driver loads and seems to operate the hardware to some extent, but there seems to be a problem with interrupts. Namely, the chip doesn't seem to generate any. Raphael J. Wysocki wrote: Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg: bcm43xx driver ACPI: PCI Interrupt :30:00.0[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :30:00.0 to 64 bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off PM: Adding info for No Bus:eth1 printk: 3 messages suppressed. SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() but, strangely enough, eth1 does not appear, but eth2 appears instead: Usually the problem generates an oops, but I think your problem is due to the changes in the work struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not propagated through the system. You should apply the work_struct2 patch attached. If your computer has a switch to kill the RF, you may also wish to apply the radio_hwenable patch, which should cause the radio LED to be turned on. The selection of eth2 rather than eth1 is probably due to the rules in /etc/udev/rules.d/30-net_persistent_names.rules. Ah, I'll check that, thanks. It used to be eth1, though, and I haven't changed the udev configuration myself. When I boot a softmac version, my bcm43xx device is wlan0, but when I boot the d80211 version, it is eth1. I have a second bcm43xx card, which becomes eth2 under softmac. Thanks for the patch. In the meantime I've browsed the bcm43xx-dev archives and found some other interesting patches for me to try. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29).
The driver loads and seems to operate the hardware to some extent, but there
seems to be a problem with interrupts. Namely, the chip doesn't seem to
generate any.
Raphael J. Wysocki wrote:
> Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg:
> bcm43xx driver
> ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 18
> PCI: Setting latency timer of device :30:00.0 to 64
> bcm43xx: Chip ID 0x4311, rev 0x1
> bcm43xx: Number of cores: 4
> bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
> bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
> bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
> bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
> bcm43xx: PHY connected
> bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8
> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> bcm43xx: Radio turned off
> bcm43xx: Radio turned off
> PM: Adding info for No Bus:eth1
> printk: 3 messages suppressed.
> SoftMAC: ASSERTION FAILED (0) at: >
net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate()
>
> but, strangely enough, eth1 does not appear, but eth2 appears instead:
>
Usually the problem generates an oops, but I think your problem is due to the changes in the work
struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not propagated through the system.
You should apply the work_struct2 patch attached. If your computer has a switch to kill the RF, you
may also wish to apply the radio_hwenable patch, which should cause the radio LED to be turned on.
The selection of eth2 rather than eth1 is probably due to the rules in
/etc/udev/rules.d/30-net_persistent_names.rules. When I boot a softmac version, my bcm43xx device is
wlan0, but when I boot the d80211 version, it is eth1. I have a second bcm43xx card, which becomes
eth2 under softmac.
Larry
From: Ulrich Kunitz <[EMAIL PROTECTED]>
The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.
Larry
net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(>associnfo.work.work);
}
static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(>associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
if (err)
goto err_gpio_cleanup;
bcm43xx_radio_turn_on(bcm);
+ bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
+ printk(KERN_INFO PFX "Radio %s by hardware\n",
+ (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
bcm43xx_write16
bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29).
The driver loads and seems to operate the hardware to some extent, but there
seems to be a problem with interrupts. Namely, the chip doesn't seem to
generate any.
Raphael J. Wysocki wrote:
Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg:
bcm43xx driver
ACPI: PCI Interrupt :30:00.0[A] - GSI 18 (level, low) - IRQ 18
PCI: Setting latency timer of device :30:00.0 to 64
bcm43xx: Chip ID 0x4311, rev 0x1
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
PM: Adding info for No Bus:eth1
printk: 3 messages suppressed.
SoftMAC: ASSERTION FAILED (0) at:
net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate()
but, strangely enough, eth1 does not appear, but eth2 appears instead:
Usually the problem generates an oops, but I think your problem is due to the changes in the work
struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not propagated through the system.
You should apply the work_struct2 patch attached. If your computer has a switch to kill the RF, you
may also wish to apply the radio_hwenable patch, which should cause the radio LED to be turned on.
The selection of eth2 rather than eth1 is probably due to the rules in
/etc/udev/rules.d/30-net_persistent_names.rules. When I boot a softmac version, my bcm43xx device is
wlan0, but when I boot the d80211 version, it is eth1. I have a second bcm43xx card, which becomes
eth2 under softmac.
Larry
From: Ulrich Kunitz [EMAIL PROTECTED]
The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.
Larry
net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(mac-associnfo.work.work);
}
static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(mac-associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
if (err)
goto err_gpio_cleanup;
bcm43xx_radio_turn_on(bcm);
+ bcm-radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
+ printk(KERN_INFO PFX Radio %s by hardware\n,
+ (bcm-radio_hw_enable == 0) ? disabled : enabled);
bcm43xx_write16(bcm, 0x03E6, 0x);
err = bcm43xx_phy_init(bcm);
@@ -3172,9 +3175,24 @@ static void bcm43xx_periodic_every30sec(
static void bcm43xx_periodic_every15sec(struct
bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
Hi, I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on an HPC nx6325, with no luck, so far, although I'm using a firmware that has been reported to work with these boxes (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29). The driver loads and seems to operate the hardware to some extent, but there seems to be a problem with interrupts. Namely, the chip doesn't seem to generate any. Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg: bcm43xx driver ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device :30:00.0 to 64 bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off PM: Adding info for No Bus:eth1 printk: 3 messages suppressed. SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() but, strangely enough, eth1 does not appear, but eth2 appears instead: # ifconfig eth1 up eth1: unknown interface: No such device # ifconfig eth2 up # Now there are lots of SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() messages in dmesg followed by bcm43xx: PHY connected PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 bcm43xx: Microcode rev 0x122, pl 0x98 (2004-11-16 07:21:20) bcm43xx: Radio turned on bcm43xx: Chip initialized bcm43xx: 32-bit DMA initialized bcm43xx: Keys cleared bcm43xx: Selected 802.11 core (phytype 2) PM: Adding info for No Bus:hw_random ADDRCONF(NETDEV_UP): eth2: link is not ready Now, if I run iwconfig on it, I get eth2 IEEE 802.11b/g ESSID:off/any Nickname:"Broadcom 4311" Mode:Managed Frequency=2.437 GHz Access Point: Invalid Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 and 'iwlist eth2 scan' says 'eth2 No scan results', although a working access point is standing next to the box and the following line appears in dmesg: SoftMAC: Scanning finished: scanned 14 channels starting with channel 1 _But_ if I do 'cat /proc/interrupts' now, I get: CPU0 CPU1 0:1247596 0-edge timer 1: 3939 1170 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 12:150170 IO-APIC-edge i8042 14: 38129 6047 IO-APIC-edge ide0 16: 99585 18389 IO-APIC-fasteoi libata, HDA Intel 18: 0 0 IO-APIC-fasteoi bcm43xx 19: 48003 9582 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 20: 0 3 IO-APIC-fasteoi yenta, tifm_7xx1, ohci1394, sdhci:slot0 21: 11522 2467 IO-APIC-fasteoi acpi 23: 68971 11663 IO-APIC-fasteoi eth0 NMI: 0 0 LOC:12476621247039 ERR: 10 so apparently there's something wrong. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] alsa soc wm8750 fix 2.6.20-rc1-mm1
At Wed, 20 Dec 2006 21:47:44 -0800,
Andrew Morton wrote:
>
> On Wed, 20 Dec 2006 20:20:45 +0300
> "Eugene Ilkov" <[EMAIL PROTECTED]> wrote:
>
> > There was some INIT_WORK related changes, here is patch against
> > wm8750 codec driver. Tested on sharp sl-c1000
> >
> >
> > --- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c 2006-12-20
> > 19:23:27.0 +0300
> > +++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c2006-12-20
> > 19:27:28.0 +0300
> > @@ -52,7 +52,6 @@
> > printk(KERN_WARNING AUDIO_NAME ": " format "\n" , ## arg)
> > static struct workqueue_struct *wm8750_workq = NULL;
> > -static struct work_struct wm8750_dapm_work;
> > /*
> > * wm8750 register cache
> > @@ -1001,9 +1000,11 @@
> > };
> > EXPORT_SYMBOL_GPL(wm8750_dai);
> > -static void wm8750_work(void *data)
> > +static void wm8750_work(struct work_struct *work)
> > {
> > - struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
> > + struct snd_soc_device *socdev =
> > + container_of(work, struct snd_soc_device, delayed_work.work);
> > + struct snd_soc_codec *codec = socdev->codec;
> > wm8750_dapm_event(codec, codec->dapm_state);
> > }
> > @@ -1039,7 +1040,7 @@
> > if (codec->suspend_dapm_state == SNDRV_CTL_POWER_D0) {
> > wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
> > codec->dapm_state = SNDRV_CTL_POWER_D0;
> > - queue_delayed_work(wm8750_workq, _dapm_work,
> > + queue_delayed_work(wm8750_workq, >delayed_work,
> > msecs_to_jiffies(1000));
> > }
> > @@ -1084,7 +1085,7 @@
> > /* charge output caps */
> > wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
> > codec->dapm_state = SNDRV_CTL_POWER_D3hot;
> > - queue_delayed_work(wm8750_workq, _dapm_work,
> > + queue_delayed_work(wm8750_workq, >delayed_work,
> > msecs_to_jiffies(1000));
> > /* set the update bits */
> > @@ -1227,7 +1228,7 @@
> > INIT_LIST_HEAD(>dapm_widgets);
> > INIT_LIST_HEAD(>dapm_paths);
> > wm8750_socdev = socdev;
> > - INIT_WORK(_dapm_work, wm8750_work, codec);
> > + INIT_DELAYED_WORK(>delayed_work, wm8750_work);
> > wm8750_workq = create_workqueue("wm8750");
> > if (wm8750_workq == NULL) {
> > kfree(codec);
> >
>
> I'm really not sure what's going on here. Your patch appears to be against
> a version of the driver which someone had attempted to fix up. But the
> version of the driver which I see in today's alsa git tree doesn't have
> even those fixes.
>
> Shrug. Oh well, I queued up something which hopefuly will work, but please
> retest next -mm, thanks.
Oh yeah, there are conflicts in ALSA git tree and this change.
The problem is that the ALSA patches haven't been merged to 2.6.20
tree, and the development went parallel.
Anyway, the patch looks wrong, too. socdev->delayed_work is used for
another thing at closing PCM stream in soc-core.c, thus this
conflicts. The codec code should have its own work struct.
The below is the patch I applied to ALSA tree. The alsa-git will be
updated soon with this, too.
I'll try to collect the necessary patches from alsa-git to make these
things consistent, and pass to Jaroslav to push to upstream.
thanks,
Takashi
---
diff -r e276b2632752 include/sound/soc.h
--- a/include/sound/soc.h Wed Dec 20 19:20:07 2006 +0100
+++ b/include/sound/soc.h Thu Dec 21 10:44:06 2006 +0100
@@ -374,6 +374,7 @@ struct snd_soc_codec {
struct list_head dapm_paths;
unsigned int dapm_state;
unsigned int suspend_dapm_state;
+ struct delayed_work delayed_work;
/* codec DAI's */
struct snd_soc_codec_dai *dai;
diff -r e276b2632752 soc/codecs/wm8750.c
--- a/sound/soc/codecs/wm8750.c Wed Dec 20 19:20:07 2006 +0100
+++ b/sound/soc/codecs/wm8750.c Thu Dec 21 10:45:28 2006 +0100
@@ -50,8 +50,6 @@
printk(KERN_INFO AUDIO_NAME ": " format "\n" , ## arg)
#define warn(format, arg...) \
printk(KERN_WARNING AUDIO_NAME ": " format "\n" , ## arg)
-
-static struct work_struct wm8750_dapm_work;
/*
* wm8750 register cache
@@ -1000,9 +998,10 @@ struct snd_soc_codec_dai wm8750_dai = {
};
EXPORT_SYMBOL_GPL(wm8750_dai);
-static void wm8750_work(void *data)
-{
- struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
+static void wm8750_work(struct work_struct *work)
+{
+ struct snd_soc_codec *codec =
+ container_of(work, struct snd_soc_codec, delayed_work.work);
wm8750_dapm_event(codec,
Re: [PATCH] alsa soc wm8750 fix 2.6.20-rc1-mm1
At Wed, 20 Dec 2006 21:47:44 -0800,
Andrew Morton wrote:
On Wed, 20 Dec 2006 20:20:45 +0300
Eugene Ilkov [EMAIL PROTECTED] wrote:
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c 2006-12-20
19:23:27.0 +0300
+++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c2006-12-20
19:27:28.0 +0300
@@ -52,7 +52,6 @@
printk(KERN_WARNING AUDIO_NAME : format \n , ## arg)
static struct workqueue_struct *wm8750_workq = NULL;
-static struct work_struct wm8750_dapm_work;
/*
* wm8750 register cache
@@ -1001,9 +1000,11 @@
};
EXPORT_SYMBOL_GPL(wm8750_dai);
-static void wm8750_work(void *data)
+static void wm8750_work(struct work_struct *work)
{
- struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
+ struct snd_soc_device *socdev =
+ container_of(work, struct snd_soc_device, delayed_work.work);
+ struct snd_soc_codec *codec = socdev-codec;
wm8750_dapm_event(codec, codec-dapm_state);
}
@@ -1039,7 +1040,7 @@
if (codec-suspend_dapm_state == SNDRV_CTL_POWER_D0) {
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D0;
- queue_delayed_work(wm8750_workq, wm8750_dapm_work,
+ queue_delayed_work(wm8750_workq, socdev-delayed_work,
msecs_to_jiffies(1000));
}
@@ -1084,7 +1085,7 @@
/* charge output caps */
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D3hot;
- queue_delayed_work(wm8750_workq, wm8750_dapm_work,
+ queue_delayed_work(wm8750_workq, socdev-delayed_work,
msecs_to_jiffies(1000));
/* set the update bits */
@@ -1227,7 +1228,7 @@
INIT_LIST_HEAD(codec-dapm_widgets);
INIT_LIST_HEAD(codec-dapm_paths);
wm8750_socdev = socdev;
- INIT_WORK(wm8750_dapm_work, wm8750_work, codec);
+ INIT_DELAYED_WORK(socdev-delayed_work, wm8750_work);
wm8750_workq = create_workqueue(wm8750);
if (wm8750_workq == NULL) {
kfree(codec);
I'm really not sure what's going on here. Your patch appears to be against
a version of the driver which someone had attempted to fix up. But the
version of the driver which I see in today's alsa git tree doesn't have
even those fixes.
Shrug. Oh well, I queued up something which hopefuly will work, but please
retest next -mm, thanks.
Oh yeah, there are conflicts in ALSA git tree and this change.
The problem is that the ALSA patches haven't been merged to 2.6.20
tree, and the development went parallel.
Anyway, the patch looks wrong, too. socdev-delayed_work is used for
another thing at closing PCM stream in soc-core.c, thus this
conflicts. The codec code should have its own work struct.
The below is the patch I applied to ALSA tree. The alsa-git will be
updated soon with this, too.
I'll try to collect the necessary patches from alsa-git to make these
things consistent, and pass to Jaroslav to push to upstream.
thanks,
Takashi
---
diff -r e276b2632752 include/sound/soc.h
--- a/include/sound/soc.h Wed Dec 20 19:20:07 2006 +0100
+++ b/include/sound/soc.h Thu Dec 21 10:44:06 2006 +0100
@@ -374,6 +374,7 @@ struct snd_soc_codec {
struct list_head dapm_paths;
unsigned int dapm_state;
unsigned int suspend_dapm_state;
+ struct delayed_work delayed_work;
/* codec DAI's */
struct snd_soc_codec_dai *dai;
diff -r e276b2632752 soc/codecs/wm8750.c
--- a/sound/soc/codecs/wm8750.c Wed Dec 20 19:20:07 2006 +0100
+++ b/sound/soc/codecs/wm8750.c Thu Dec 21 10:45:28 2006 +0100
@@ -50,8 +50,6 @@
printk(KERN_INFO AUDIO_NAME : format \n , ## arg)
#define warn(format, arg...) \
printk(KERN_WARNING AUDIO_NAME : format \n , ## arg)
-
-static struct work_struct wm8750_dapm_work;
/*
* wm8750 register cache
@@ -1000,9 +998,10 @@ struct snd_soc_codec_dai wm8750_dai = {
};
EXPORT_SYMBOL_GPL(wm8750_dai);
-static void wm8750_work(void *data)
-{
- struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
+static void wm8750_work(struct work_struct *work)
+{
+ struct snd_soc_codec *codec =
+ container_of(work, struct snd_soc_codec, delayed_work.work);
wm8750_dapm_event(codec, codec-dapm_state);
}
@@ -1038,7 +1037,7 @@ static int wm8750_resume(struct platform
if (codec-suspend_dapm_state == SNDRV_CTL_POWER_D0) {
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D0;
- schedule_delayed_work(wm8750_dapm_work,
+ schedule_delayed_work(codec-delayed_work,
msecs_to_jiffies(1000));
}
@@ -1083,7 +1082,7 @@ static int wm8750_init(struct snd_soc_de
/* charge output caps */
wm8750_dapm_event
bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
Hi, I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on an HPC nx6325, with no luck, so far, although I'm using a firmware that has been reported to work with these boxes (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29). The driver loads and seems to operate the hardware to some extent, but there seems to be a problem with interrupts. Namely, the chip doesn't seem to generate any. Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg: bcm43xx driver ACPI: PCI Interrupt :30:00.0[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :30:00.0 to 64 bcm43xx: Chip ID 0x4311, rev 0x1 bcm43xx: Number of cores: 4 bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243 bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243 bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243 bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243 bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off PM: Adding info for No Bus:eth1 printk: 3 messages suppressed. SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() but, strangely enough, eth1 does not appear, but eth2 appears instead: # ifconfig eth1 up eth1: unknown interface: No such device # ifconfig eth2 up # Now there are lots of SoftMAC: ASSERTION FAILED (0) at: net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate() messages in dmesg followed by bcm43xx: PHY connected PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 PM: Adding info for No Bus::30:00.0 PM: Removing info for No Bus::30:00.0 bcm43xx: Microcode rev 0x122, pl 0x98 (2004-11-16 07:21:20) bcm43xx: Radio turned on bcm43xx: Chip initialized bcm43xx: 32-bit DMA initialized bcm43xx: Keys cleared bcm43xx: Selected 802.11 core (phytype 2) PM: Adding info for No Bus:hw_random ADDRCONF(NETDEV_UP): eth2: link is not ready Now, if I run iwconfig on it, I get eth2 IEEE 802.11b/g ESSID:off/any Nickname:Broadcom 4311 Mode:Managed Frequency=2.437 GHz Access Point: Invalid Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 and 'iwlist eth2 scan' says 'eth2 No scan results', although a working access point is standing next to the box and the following line appears in dmesg: SoftMAC: Scanning finished: scanned 14 channels starting with channel 1 _But_ if I do 'cat /proc/interrupts' now, I get: CPU0 CPU1 0:1247596 0NULL-edge timer 1: 3939 1170 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 12:150170 IO-APIC-edge i8042 14: 38129 6047 IO-APIC-edge ide0 16: 99585 18389 IO-APIC-fasteoi libata, HDA Intel 18: 0 0 IO-APIC-fasteoi bcm43xx 19: 48003 9582 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 20: 0 3 IO-APIC-fasteoi yenta, tifm_7xx1, ohci1394, sdhci:slot0 21: 11522 2467 IO-APIC-fasteoi acpi 23: 68971 11663 IO-APIC-fasteoi eth0 NMI: 0 0 LOC:12476621247039 ERR: 10 so apparently there's something wrong. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] alsa soc wm8750 fix 2.6.20-rc1-mm1
On Wed, 20 Dec 2006 20:20:45 +0300
"Eugene Ilkov" <[EMAIL PROTECTED]> wrote:
> There was some INIT_WORK related changes, here is patch against
> wm8750 codec driver. Tested on sharp sl-c1000
>
>
> --- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c2006-12-20
> 19:23:27.0 +0300
> +++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c 2006-12-20
> 19:27:28.0 +0300
> @@ -52,7 +52,6 @@
> printk(KERN_WARNING AUDIO_NAME ": " format "\n" , ## arg)
> static struct workqueue_struct *wm8750_workq = NULL;
> -static struct work_struct wm8750_dapm_work;
> /*
> * wm8750 register cache
> @@ -1001,9 +1000,11 @@
> };
> EXPORT_SYMBOL_GPL(wm8750_dai);
> -static void wm8750_work(void *data)
> +static void wm8750_work(struct work_struct *work)
> {
> - struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
> + struct snd_soc_device *socdev =
> + container_of(work, struct snd_soc_device, delayed_work.work);
> + struct snd_soc_codec *codec = socdev->codec;
> wm8750_dapm_event(codec, codec->dapm_state);
> }
> @@ -1039,7 +1040,7 @@
> if (codec->suspend_dapm_state == SNDRV_CTL_POWER_D0) {
> wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
> codec->dapm_state = SNDRV_CTL_POWER_D0;
> - queue_delayed_work(wm8750_workq, _dapm_work,
> + queue_delayed_work(wm8750_workq, >delayed_work,
>msecs_to_jiffies(1000));
> }
> @@ -1084,7 +1085,7 @@
> /* charge output caps */
> wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
> codec->dapm_state = SNDRV_CTL_POWER_D3hot;
> - queue_delayed_work(wm8750_workq, _dapm_work,
> + queue_delayed_work(wm8750_workq, >delayed_work,
> msecs_to_jiffies(1000));
> /* set the update bits */
> @@ -1227,7 +1228,7 @@
> INIT_LIST_HEAD(>dapm_widgets);
> INIT_LIST_HEAD(>dapm_paths);
> wm8750_socdev = socdev;
> - INIT_WORK(_dapm_work, wm8750_work, codec);
> + INIT_DELAYED_WORK(>delayed_work, wm8750_work);
> wm8750_workq = create_workqueue("wm8750");
> if (wm8750_workq == NULL) {
> kfree(codec);
>
I'm really not sure what's going on here. Your patch appears to be against
a version of the driver which someone had attempted to fix up. But the
version of the driver which I see in today's alsa git tree doesn't have
even those fixes.
Shrug. Oh well, I queued up something which hopefuly will work, but please
retest next -mm, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
On Wed, 20 Dec 2006 15:06:28 -0500 "Bob Picco" <[EMAIL PROTECTED]> wrote: > Sorry I was looking for AIM VII and/or reaim which are multiuser loads. > The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and > SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM+VMEMMAP AIM VII > wasn't benchmarked to higher load limit because of my time constraints. > The runs should be repeated more times. Thank you. > > Any difference between the three configurations looks insignificant and > within benchmark noise. > looks so ;) Because I'm now exhausted by other works, I can't go ahead until the next year. My concern is io-benchmark like iozone. Andrew-san, please drop the patch set if anyone isn't interested in. I'll retry with new benchmark result if necessary. -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
Hiroyuki KAMEZAWA wrote:[Sat Dec 16 2006, 03:31:36AM EST] > This patch implements pfn_valid() micro optimization. > > This uses ia64_pfn_valid() idea to check mem_map is valid or not instead of > sparsemem's logic. > > By this, we'll not access mem_section[] in usual ops. > > I attaches my easy test result with *micro* benchmark on SMP system. > I'm glad if you give me an advice about testing. Sorry I was looking for AIM VII and/or reaim which are multiuser loads. The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM+VMEMMAP AIM VII wasn't benchmarked to higher load limit because of my time constraints. The runs should be repeated more times. Any difference between the three configurations looks insignificant and within benchmark noise. After tomorrow I'm on vacation until Jan 2. bob > > -Kame > == > AIM Independent Resource Benchmark - Suite IX "1.1" > > test on > CPU: Itanium2(madison) 1.3GHz x2, SMP > Memory: memory 8G > 2.6.20-rc1-m1 / > extreme means SPARSEMEM_VMEMMAP=n > vmem_map means SPARSEMEM_VMEMMAP=y + optimze pfn_valid patch. > == > extreme vmem_map > creat-clo 136322 136989 File Creations and Closes per second > page_test 1042187 1076976 System Allocations & Pages per second > brk_test2678559 2727286 System Memory Allocations per second > signal_test 309525 321052 Signal Traps per second > exec_test 803 801 Program Loads per second > fork_test 93549679Task Creations per second > disk_rr 103766 103970 Random Disk Reads (K) per second > disk_rw 82978 80244 Random Disk Writes (K) per second > disk_rd 802548 872983 Sequential Disk Reads (K) per second > disk_wrt130342 131408 Sequential Disk Writes (K) per second > disk_cp 107498 107823 Disk Copies (K) per second > sync_disk_rw800 752 Sync Random Disk Writes (K) per second > sync_disk_wrt 81 78 Sync Sequential Disk Writes (K) per second > sync_disk_cp84 78 Sync Disk Copies (K) per second > disk_src44417 44379 Directory Searches per second > mem_rtns_1 3239352 3222140 Dynamic Memory Operations per second > mem_rtns_2 1157321 1155260 Block Memory Operations per second > misc_rtns_1 10799 10993 Auxiliary Loops per second > dir_rtns_1 1276159 1373725 Directory Operations per second > shell_rtns_1175 176 Shell Scripts per second > shell_rtns_2174 175 Shell Scripts per second > shell_rtns_3175 175 Shell Scripts per second > shared_memory 646725 628769 Shared Memory Operations per second > tcp_test93258 94928 TCP/IP Messages per second > udp_test177984 177276 UDP/IP DataGrams per second > fifo_test 362774 385434 FIFO Messages per second > stream_pipe 320825 325931 Stream Pipe Messages per second > dgram_pipe 300789 303339 DataGram Pipe Messages per second > pipe_cpy410539 449521 Pipe Messages per second > EXTREME AIM Multiuser Benchmark - Suite VII Run Beginning Tasksjobs/min jti jobs/min/task real cpu 1 111.22 100 111.2215 52.33 0.88 Tue Dec 19 13:43:42 2006 101 6896.87 9668.2858 85.23 42.02 Tue Dec 19 13:49:31 2006 201 7997.07 9439.7864146.28 83.69 Tue Dec 19 13:59:30 2006 301 8580.37 9528.5062204.17125.72 Tue Dec 19 14:13:27 2006 401 8800.62 9421.9467265.19167.80 Tue Dec 19 14:31:33 2006 501 9445.73 9118.8537308.69210.16 Tue Dec 19 14:52:38 2006 601 9446.80 9315.7185370.26252.50 Tue Dec 19 15:17:55 2006 701 9353.27 9213.3427436.19295.04 Tue Dec 19 15:47:42 2006 918 9543.22 9110.3957559.85387.02 Tue Dec 19 16:25:55 2006 1000 9571.14 93 9.5711608.08421.95 Tue Dec 19 17:07:26 2006 AIM Multiuser Benchmark - Suite VII Run Beginning Tasksjobs/min jti jobs/min/task real cpu 1 111.43 100 111.4281 52.23 0.88 Wed Dec 20 07:16:00 2006 101 6940.84 9568.7212 84.69 42.08 Wed Dec 20 07:21:47 2006 201 8206.67 9440.8292142.54 83.68 Wed Dec 20 07:31:31 2006 301 8692.77 9428.8796201.53125.65 Wed Dec 20 07:45:16 2006 401 8910.40 9322.2204261.92167.79 Wed Dec 20 08:03:09 2006 500 9149.02 9318.2980318.07209.55 Wed Dec 20 08:24:52 2006
[PATCH] alsa soc wm8750 fix 2.6.20-rc1-mm1
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c 2006-12-20
19:23:27.0 +0300
+++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c2006-12-20
19:27:28.0 +0300
@@ -52,7 +52,6 @@
printk(KERN_WARNING AUDIO_NAME ": " format "\n" , ## arg)
static struct workqueue_struct *wm8750_workq = NULL;
-static struct work_struct wm8750_dapm_work;
/*
* wm8750 register cache
@@ -1001,9 +1000,11 @@
};
EXPORT_SYMBOL_GPL(wm8750_dai);
-static void wm8750_work(void *data)
+static void wm8750_work(struct work_struct *work)
{
- struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
+ struct snd_soc_device *socdev =
+ container_of(work, struct snd_soc_device, delayed_work.work);
+ struct snd_soc_codec *codec = socdev->codec;
wm8750_dapm_event(codec, codec->dapm_state);
}
@@ -1039,7 +1040,7 @@
if (codec->suspend_dapm_state == SNDRV_CTL_POWER_D0) {
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec->dapm_state = SNDRV_CTL_POWER_D0;
- queue_delayed_work(wm8750_workq, _dapm_work,
+ queue_delayed_work(wm8750_workq, >delayed_work,
msecs_to_jiffies(1000));
}
@@ -1084,7 +1085,7 @@
/* charge output caps */
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec->dapm_state = SNDRV_CTL_POWER_D3hot;
- queue_delayed_work(wm8750_workq, _dapm_work,
+ queue_delayed_work(wm8750_workq, >delayed_work,
msecs_to_jiffies(1000));
/* set the update bits */
@@ -1227,7 +1228,7 @@
INIT_LIST_HEAD(>dapm_widgets);
INIT_LIST_HEAD(>dapm_paths);
wm8750_socdev = socdev;
- INIT_WORK(_dapm_work, wm8750_work, codec);
+ INIT_DELAYED_WORK(>delayed_work, wm8750_work);
wm8750_workq = create_workqueue("wm8750");
if (wm8750_workq == NULL) {
kfree(codec);
--- Begin Message ---
--- End Message ---
[PATCH] alsa soc wm8750 fix 2.6.20-rc1-mm1
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c 2006-12-20
19:23:27.0 +0300
+++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c2006-12-20
19:27:28.0 +0300
@@ -52,7 +52,6 @@
printk(KERN_WARNING AUDIO_NAME : format \n , ## arg)
static struct workqueue_struct *wm8750_workq = NULL;
-static struct work_struct wm8750_dapm_work;
/*
* wm8750 register cache
@@ -1001,9 +1000,11 @@
};
EXPORT_SYMBOL_GPL(wm8750_dai);
-static void wm8750_work(void *data)
+static void wm8750_work(struct work_struct *work)
{
- struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
+ struct snd_soc_device *socdev =
+ container_of(work, struct snd_soc_device, delayed_work.work);
+ struct snd_soc_codec *codec = socdev-codec;
wm8750_dapm_event(codec, codec-dapm_state);
}
@@ -1039,7 +1040,7 @@
if (codec-suspend_dapm_state == SNDRV_CTL_POWER_D0) {
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D0;
- queue_delayed_work(wm8750_workq, wm8750_dapm_work,
+ queue_delayed_work(wm8750_workq, socdev-delayed_work,
msecs_to_jiffies(1000));
}
@@ -1084,7 +1085,7 @@
/* charge output caps */
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D3hot;
- queue_delayed_work(wm8750_workq, wm8750_dapm_work,
+ queue_delayed_work(wm8750_workq, socdev-delayed_work,
msecs_to_jiffies(1000));
/* set the update bits */
@@ -1227,7 +1228,7 @@
INIT_LIST_HEAD(codec-dapm_widgets);
INIT_LIST_HEAD(codec-dapm_paths);
wm8750_socdev = socdev;
- INIT_WORK(wm8750_dapm_work, wm8750_work, codec);
+ INIT_DELAYED_WORK(socdev-delayed_work, wm8750_work);
wm8750_workq = create_workqueue(wm8750);
if (wm8750_workq == NULL) {
kfree(codec);
---BeginMessage---
---End Message---
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
Hiroyuki KAMEZAWA wrote:[Sat Dec 16 2006, 03:31:36AM EST] This patch implements pfn_valid() micro optimization. This uses ia64_pfn_valid() idea to check mem_map is valid or not instead of sparsemem's logic. By this, we'll not access mem_section[] in usual ops. I attaches my easy test result with *micro* benchmark on SMP system. I'm glad if you give me an advice about testing. Sorry I was looking for AIM VII and/or reaim which are multiuser loads. The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM+VMEMMAP AIM VII wasn't benchmarked to higher load limit because of my time constraints. The runs should be repeated more times. Any difference between the three configurations looks insignificant and within benchmark noise. After tomorrow I'm on vacation until Jan 2. bob -Kame == AIM Independent Resource Benchmark - Suite IX 1.1 test on CPU: Itanium2(madison) 1.3GHz x2, SMP Memory: memory 8G 2.6.20-rc1-m1 / extreme means SPARSEMEM_VMEMMAP=n vmem_map means SPARSEMEM_VMEMMAP=y + optimze pfn_valid patch. == extreme vmem_map creat-clo 136322 136989 File Creations and Closes per second page_test 1042187 1076976 System Allocations Pages per second brk_test2678559 2727286 System Memory Allocations per second signal_test 309525 321052 Signal Traps per second exec_test 803 801 Program Loads per second fork_test 93549679Task Creations per second disk_rr 103766 103970 Random Disk Reads (K) per second disk_rw 82978 80244 Random Disk Writes (K) per second disk_rd 802548 872983 Sequential Disk Reads (K) per second disk_wrt130342 131408 Sequential Disk Writes (K) per second disk_cp 107498 107823 Disk Copies (K) per second sync_disk_rw800 752 Sync Random Disk Writes (K) per second sync_disk_wrt 81 78 Sync Sequential Disk Writes (K) per second sync_disk_cp84 78 Sync Disk Copies (K) per second disk_src44417 44379 Directory Searches per second mem_rtns_1 3239352 3222140 Dynamic Memory Operations per second mem_rtns_2 1157321 1155260 Block Memory Operations per second misc_rtns_1 10799 10993 Auxiliary Loops per second dir_rtns_1 1276159 1373725 Directory Operations per second shell_rtns_1175 176 Shell Scripts per second shell_rtns_2174 175 Shell Scripts per second shell_rtns_3175 175 Shell Scripts per second shared_memory 646725 628769 Shared Memory Operations per second tcp_test93258 94928 TCP/IP Messages per second udp_test177984 177276 UDP/IP DataGrams per second fifo_test 362774 385434 FIFO Messages per second stream_pipe 320825 325931 Stream Pipe Messages per second dgram_pipe 300789 303339 DataGram Pipe Messages per second pipe_cpy410539 449521 Pipe Messages per second EXTREME AIM Multiuser Benchmark - Suite VII Run Beginning Tasksjobs/min jti jobs/min/task real cpu 1 111.22 100 111.2215 52.33 0.88 Tue Dec 19 13:43:42 2006 101 6896.87 9668.2858 85.23 42.02 Tue Dec 19 13:49:31 2006 201 7997.07 9439.7864146.28 83.69 Tue Dec 19 13:59:30 2006 301 8580.37 9528.5062204.17125.72 Tue Dec 19 14:13:27 2006 401 8800.62 9421.9467265.19167.80 Tue Dec 19 14:31:33 2006 501 9445.73 9118.8537308.69210.16 Tue Dec 19 14:52:38 2006 601 9446.80 9315.7185370.26252.50 Tue Dec 19 15:17:55 2006 701 9353.27 9213.3427436.19295.04 Tue Dec 19 15:47:42 2006 918 9543.22 9110.3957559.85387.02 Tue Dec 19 16:25:55 2006 1000 9571.14 93 9.5711608.08421.95 Tue Dec 19 17:07:26 2006 AIM Multiuser Benchmark - Suite VII Run Beginning Tasksjobs/min jti jobs/min/task real cpu 1 111.43 100 111.4281 52.23 0.88 Wed Dec 20 07:16:00 2006 101 6940.84 9568.7212 84.69 42.08 Wed Dec 20 07:21:47 2006 201 8206.67 9440.8292142.54 83.68 Wed Dec 20 07:31:31 2006 301 8692.77 9428.8796201.53125.65 Wed Dec 20 07:45:16 2006 401 8910.40 9322.2204261.92167.79 Wed Dec 20 08:03:09 2006 500 9149.02 9318.2980318.07209.55 Wed Dec 20 08:24:52 2006 REAIM Workload Times are in seconds - Child times from tms.cstime and tms.cutime Num Parent Child Child Jobs per Jobs/min/ Std_dev Std_dev JTI Forked Time SysTime UTime Minute Child Time Percent 1
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
On Wed, 20 Dec 2006 15:06:28 -0500 Bob Picco [EMAIL PROTECTED] wrote: Sorry I was looking for AIM VII and/or reaim which are multiuser loads. The results (2.6.20-rc1-mm1) for EXTREME, SPARSEMEM+VMEMMAP and SPARSEMEM+VMEMMAP+your+patch are below. Note SPARSEMEM+VMEMMAP AIM VII wasn't benchmarked to higher load limit because of my time constraints. The runs should be repeated more times. Thank you. Any difference between the three configurations looks insignificant and within benchmark noise. looks so ;) Because I'm now exhausted by other works, I can't go ahead until the next year. My concern is io-benchmark like iozone. Andrew-san, please drop the patch set if anyone isn't interested in. I'll retry with new benchmark result if necessary. -Kame - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] alsa soc wm8750 fix 2.6.20-rc1-mm1
On Wed, 20 Dec 2006 20:20:45 +0300
Eugene Ilkov [EMAIL PROTECTED] wrote:
There was some INIT_WORK related changes, here is patch against
wm8750 codec driver. Tested on sharp sl-c1000
--- linux-2.6.20-rc1-mm1/sound/soc/codecs/wm8750.c2006-12-20
19:23:27.0 +0300
+++ linux-2.6.20-rc1-mm.z1/sound/soc/codecs/wm8750.c 2006-12-20
19:27:28.0 +0300
@@ -52,7 +52,6 @@
printk(KERN_WARNING AUDIO_NAME : format \n , ## arg)
static struct workqueue_struct *wm8750_workq = NULL;
-static struct work_struct wm8750_dapm_work;
/*
* wm8750 register cache
@@ -1001,9 +1000,11 @@
};
EXPORT_SYMBOL_GPL(wm8750_dai);
-static void wm8750_work(void *data)
+static void wm8750_work(struct work_struct *work)
{
- struct snd_soc_codec *codec = (struct snd_soc_codec *)data;
+ struct snd_soc_device *socdev =
+ container_of(work, struct snd_soc_device, delayed_work.work);
+ struct snd_soc_codec *codec = socdev-codec;
wm8750_dapm_event(codec, codec-dapm_state);
}
@@ -1039,7 +1040,7 @@
if (codec-suspend_dapm_state == SNDRV_CTL_POWER_D0) {
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D0;
- queue_delayed_work(wm8750_workq, wm8750_dapm_work,
+ queue_delayed_work(wm8750_workq, socdev-delayed_work,
msecs_to_jiffies(1000));
}
@@ -1084,7 +1085,7 @@
/* charge output caps */
wm8750_dapm_event(codec, SNDRV_CTL_POWER_D2);
codec-dapm_state = SNDRV_CTL_POWER_D3hot;
- queue_delayed_work(wm8750_workq, wm8750_dapm_work,
+ queue_delayed_work(wm8750_workq, socdev-delayed_work,
msecs_to_jiffies(1000));
/* set the update bits */
@@ -1227,7 +1228,7 @@
INIT_LIST_HEAD(codec-dapm_widgets);
INIT_LIST_HEAD(codec-dapm_paths);
wm8750_socdev = socdev;
- INIT_WORK(wm8750_dapm_work, wm8750_work, codec);
+ INIT_DELAYED_WORK(socdev-delayed_work, wm8750_work);
wm8750_workq = create_workqueue(wm8750);
if (wm8750_workq == NULL) {
kfree(codec);
I'm really not sure what's going on here. Your patch appears to be against
a version of the driver which someone had attempted to fix up. But the
version of the driver which I see in today's alsa git tree doesn't have
even those fixes.
Shrug. Oh well, I queued up something which hopefuly will work, but please
retest next -mm, thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
--- Damien Wyart <[EMAIL PROTECTED]> wrote: > > > > The reiser4 failure is unexpected. Could you please see if you can > > > > capture a trace, let the people at [EMAIL PROTECTED] know? > > > > Ok, I've handwritten the messages, here they are : > > > > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom > > > (fs/reiser4/txmngr.c:1087) (zam-597) > > > write log failed (-5) > > > > [ got 2 copies of them because I have 2 reiser4 fs) > > > > I got them mainly when I try to reboot or halt the machine, and the > > > process doesn't finish, the computer gets stuck after the reiser4 > > > messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. > > * Laurent Riffard <[EMAIL PROTECTED]> [2006-12-18 09:03]: > > fix-sense-key-medium-error-processing-and-retry.patch seems to be the > > culprit. > > > Reverting it fix those reiser4 panics for me. Damien, could you confirm > > please ? > > Yes, this fixes it too on my side. Thanks for this tracking ! I had a bug in my dev tree which got picked up by the patch when I diffed against master: - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; As james explained, the other chunk of the patch is still good. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: NMI Watchdog detected LOCKUP (was: 2.6.20-rc1-mm1)
On Thu, 2006-12-14 at 22:59 -0800, Tilman Schmidt wrote: > [] rb_insert_color+0x55/0xbe > [] enqueue_hrtimer+0x10a/0x116 > [] hrtimer_start+0x78/0x93 > [] get_signal_to_deliver+0xf3/0x74e > [] do_notify_resume+0x93/0x655 > [] work_notifysig+0x13/0x1a > [] 0xb7f5f410 Not really helpful. > Config file available upon request. (The system won't boot right now, > it wants a manual fsck first.) Bisecting this promises to take about > 8 hours per iteration if I add up the wait for the hang, the fsck > afterwards and the time this system needs for compiling a kernel, so > I'll wait for you to tell me if it's really necessary. ;-) Can you send me the config file please and the boot log of the machine ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-mm1 suspicious prececence code ( was Re: [PATCH/v2] CodingStyle updates
On Fri, 15 Dec 2006 22:59:12 +0100, Jan Engelhardt said: > I take it that people will automatically DTRT for obscure cases like > shown before. Well, and if they don't, hopefully some reviewer catches > things like 3*i + l<<2. So I hacked up a few very ugly 'find|egrep' to look for some cases of that, and found: ./include/asm-arm/arch-ebsa110/hardware.h:18: * Region 0 (addr = 0xf000 + io << 2) Only one odd-looking use of +-*/ and <> - and it's in a comment. And that's using a pattern like '\+[^,()=]*<<' (basically, any plus sign that has a << after it, but no comma parens or equals to force grouping in between), and then using /bin/eyeball to filter the resulting several hundred lines. I admit I didn't try to catch expressions split over multiple lines, and something of the form "foo * bar + (a-b) << 2" would have snuck by (but I suspect if somebody bothered doing the (a-b), they would have another pair). So either that sort of thing isn't really an error we make often, or the reviewers are very good at catching it, or I'm a lot worse at finding them than I thought I was... :) pgpGQVM0MLXmr.pgp Description: PGP signature
BUG: NMI Watchdog detected LOCKUP (was: 2.6.20-rc1-mm1)
I tried kernel 2.6.20-rc1-mm1 with the "tickless" option on my P3/933 but it has now for the second time in a row caused a system freeze as soon as I left the system idle for a couple of hours. The second time I was warned and switched to a text console before I left the system, and was able to collect this BUG message (copied manually, beware of typos): BUG: NMI Watchdog detected LOCKUP on CPU0, eip c021cf4d, registers: Modules linked in: xt_pkttype ipt_LOG xt_limit usbserial snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal processor fan button battery ac af_packet bas_gigaset gigaset isdn slhc crc_ccitt ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 uhci_hcd ipv6 nls_iso8859_1 nls_cp437 vfat fat nsl_utf8 ntfs dm_mod CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00200082 (2.6.20-rc1-mm1-noinitrd #0) EIP is at __rb_rotate_right+0x1/0x54 eax: dea0c77c ebx: dea0c77c ecx: dae0c77c edx: c04beb8c esi: dea0c77c edi: dea0c77c ebp: deaf3d74 esp: deaf3d54 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process X (pid: 3255, ti=deaf2000 task=c14deb00 task.ti=deaf2000) Stack: deaf3d74 c021d049 c04beb8c dea0c77c de8d5f3e 0995 deaf3d98 c012d15b 0001 c04beb84 dea0c780 dea0c77c de8d5f3e 0995 c04beb84 deaf3dc4 c012d9b4 c012d323 dea0c77c 00200096 dea0c77c Call Trace: [] rb_insert_color+0x55/0xbe [] enqueue_hrtimer+0x10a/0x116 [] hrtimer_start+0x78/0x93 [] get_signal_to_deliver+0xf3/0x74e [] do_notify_resume+0x93/0x655 [] work_notifysig+0x13/0x1a [] 0xb7f5f410 === Code: 39 d0 74 22 8b 4a 08 85 c9 74 0d 8b 41 04 85 c0 74 14 89 c1 eb f5 89 c2 8b 02 83 e0 fc 74 05 3b 50 08 74 f2 89 c1 5d 89 c8 c3 55 <89> e5 57 89 d7 56 53 89 c3 8b 50 08 8b 30 8b 4a 04 83 e6 fc 85 Config file available upon request. (The system won't boot right now, it wants a manual fsck first.) Bisecting this promises to take about 8 hours per iteration if I add up the wait for the hang, the fsck afterwards and the time this system needs for compiling a kernel, so I'll wait for you to tell me if it's really necessary. ;-) HTH Tilman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: NMI Watchdog detected LOCKUP (was: 2.6.20-rc1-mm1)
I tried kernel 2.6.20-rc1-mm1 with the tickless option on my P3/933 but it has now for the second time in a row caused a system freeze as soon as I left the system idle for a couple of hours. The second time I was warned and switched to a text console before I left the system, and was able to collect this BUG message (copied manually, beware of typos): BUG: NMI Watchdog detected LOCKUP on CPU0, eip c021cf4d, registers: Modules linked in: xt_pkttype ipt_LOG xt_limit usbserial snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal processor fan button battery ac af_packet bas_gigaset gigaset isdn slhc crc_ccitt ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 uhci_hcd ipv6 nls_iso8859_1 nls_cp437 vfat fat nsl_utf8 ntfs dm_mod CPU:0 EIP:0060:[c021cf4d]Not tainted VLI EFLAGS: 00200082 (2.6.20-rc1-mm1-noinitrd #0) EIP is at __rb_rotate_right+0x1/0x54 eax: dea0c77c ebx: dea0c77c ecx: dae0c77c edx: c04beb8c esi: dea0c77c edi: dea0c77c ebp: deaf3d74 esp: deaf3d54 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process X (pid: 3255, ti=deaf2000 task=c14deb00 task.ti=deaf2000) Stack: deaf3d74 c021d049 c04beb8c dea0c77c de8d5f3e 0995 deaf3d98 c012d15b 0001 c04beb84 dea0c780 dea0c77c de8d5f3e 0995 c04beb84 deaf3dc4 c012d9b4 c012d323 dea0c77c 00200096 dea0c77c Call Trace: [c021d049] rb_insert_color+0x55/0xbe [c012d15b] enqueue_hrtimer+0x10a/0x116 [c012d9b4] hrtimer_start+0x78/0x93 [c0123453] get_signal_to_deliver+0xf3/0x74e [c01026ee] do_notify_resume+0x93/0x655 [c0102ef5] work_notifysig+0x13/0x1a [b7f5f410] 0xb7f5f410 === Code: 39 d0 74 22 8b 4a 08 85 c9 74 0d 8b 41 04 85 c0 74 14 89 c1 eb f5 89 c2 8b 02 83 e0 fc 74 05 3b 50 08 74 f2 89 c1 5d 89 c8 c3 55 89 e5 57 89 d7 56 53 89 c3 8b 50 08 8b 30 8b 4a 04 83 e6 fc 85 Config file available upon request. (The system won't boot right now, it wants a manual fsck first.) Bisecting this promises to take about 8 hours per iteration if I add up the wait for the hang, the fsck afterwards and the time this system needs for compiling a kernel, so I'll wait for you to tell me if it's really necessary. ;-) HTH Tilman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-mm1 suspicious prececence code ( was Re: [PATCH/v2] CodingStyle updates
On Fri, 15 Dec 2006 22:59:12 +0100, Jan Engelhardt said: I take it that people will automatically DTRT for obscure cases like shown before. Well, and if they don't, hopefully some reviewer catches things like 3*i + l2. So I hacked up a few very ugly 'find|egrep' to look for some cases of that, and found: ./include/asm-arm/arch-ebsa110/hardware.h:18: * Region 0 (addr = 0xf000 + io 2) Only one odd-looking use of +-*/ and / - and it's in a comment. And that's using a pattern like '\+[^,()=]*' (basically, any plus sign that has a after it, but no comma parens or equals to force grouping in between), and then using /bin/eyeball to filter the resulting several hundred lines. I admit I didn't try to catch expressions split over multiple lines, and something of the form foo * bar + (a-b) 2 would have snuck by (but I suspect if somebody bothered doing the (a-b), they would have another pair). So either that sort of thing isn't really an error we make often, or the reviewers are very good at catching it, or I'm a lot worse at finding them than I thought I was... :) pgpGQVM0MLXmr.pgp Description: PGP signature
Re: BUG: NMI Watchdog detected LOCKUP (was: 2.6.20-rc1-mm1)
On Thu, 2006-12-14 at 22:59 -0800, Tilman Schmidt wrote: [c021d049] rb_insert_color+0x55/0xbe [c012d15b] enqueue_hrtimer+0x10a/0x116 [c012d9b4] hrtimer_start+0x78/0x93 [c0123453] get_signal_to_deliver+0xf3/0x74e [c01026ee] do_notify_resume+0x93/0x655 [c0102ef5] work_notifysig+0x13/0x1a [b7f5f410] 0xb7f5f410 Not really helpful. Config file available upon request. (The system won't boot right now, it wants a manual fsck first.) Bisecting this promises to take about 8 hours per iteration if I add up the wait for the hang, the fsck afterwards and the time this system needs for compiling a kernel, so I'll wait for you to tell me if it's really necessary. ;-) Can you send me the config file please and the boot log of the machine ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
--- Damien Wyart [EMAIL PROTECTED] wrote: The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. * Laurent Riffard [EMAIL PROTECTED] [2006-12-18 09:03]: fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? Yes, this fixes it too on my side. Thanks for this tracking ! I had a bug in my dev tree which got picked up by the patch when I diffed against master: - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; As james explained, the other chunk of the patch is still good. Luben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006 17:18:12 -0800 (PST)
David Rientjes <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2006, Andrew Morton wrote:
>
> > diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
> > --- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
> > +++ a/mm/vmscan.c
> > @@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
> > return ret;
> > }
> >
> > +static unsigned long count_lru_pages(void)
> > +{
> > + struct zone *zone;
> > + unsigned long ret = 0;
> > +
> > + for_each_zone(zone);
> > + ret += zone->nr_active + zone->nr_inactive;
> > + return ret;
> > +}
> > +
> > /*
> > * Try to free `nr_pages' of memory, system-wide, and return the number of
> > * freed pages.
>
> There's an extra semicolon there
Sigh. coding-while-diseased.
> that results in only the final zone being
> used.
>
Actually it'll go oops. Fixed, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006, Andrew Morton wrote:
> diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
> --- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
> +++ a/mm/vmscan.c
> @@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
> return ret;
> }
>
> +static unsigned long count_lru_pages(void)
> +{
> + struct zone *zone;
> + unsigned long ret = 0;
> +
> + for_each_zone(zone);
> + ret += zone->nr_active + zone->nr_inactive;
> + return ret;
> +}
> +
> /*
> * Try to free `nr_pages' of memory, system-wide, and return the number of
> * freed pages.
There's an extra semicolon there that results in only the final zone being
used.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Tuesday, 19 December 2006 00:17, Andrew Morton wrote: > On Mon, 18 Dec 2006 23:38:23 +0100 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > Looks like we have a problem with slab shrinking here. > > > > > > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? > > > > > > Sure, but not till Friday, sorry (I am away). > > > > I reproduced this on one box, but then it turned out that EIP was at line > > 195 > > of mm/vmscan.c where there was > > > > do_div(delta, lru_pages + 1); > > That implies that we passed it lru_pages=-1. > > Presumably the logic in > vmscanc-account-for-memory-already-freed-in-seeking-to.patch caused that. > > > Well, I have no idea how this can lead to a divide error (lru_pages is > > unsigned). > > > > I'm unable to reproduce this on another i386 box, so it seems to be somewhat > > configuration specific. > > > > There is one wart in shrink_all_memory() and I think we should fix that in > 2.6.20. > > Please check the below. Fine by me. > I'll drop vmscanc-account-for-memory-already-freed-in-seeking-to.patch. It > has other stuff in it which we might still need. But altering > sc->swap_cluster_max in that manner looks odd. Agreed. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On Mon, 18 Dec 2006 16:29:02 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote: > > Got this on booting up on x86_64 test box. > Didn't happen on next boot. > > > BUG: scheduling while atomic: hald-addon-stor/0x2000/3300 > > Call Trace: > [] show_trace+0x34/0x47 > [] dump_stack+0x12/0x17 > [] __sched_text_start+0x5d/0x7ba > [] __cond_resched+0x1c/0x44 > [] cond_resched+0x29/0x30 > [] __reacquire_kernel_lock+0x26/0x44 > [] thread_return+0xac/0xea > [] __cond_resched+0x1c/0x44 > [] cond_resched+0x29/0x30 > [] wait_for_completion+0x17/0xd2 > [] blk_execute_rq+0x98/0xb8 > [] scsi_execute+0xd4/0xf1 > [] scsi_execute_req+0xb9/0xde > [] scsi_test_unit_ready+0x39/0x75 > [] sd_media_changed+0x40/0x87 > [] check_disk_change+0x1f/0x76 > [] sd_open+0x80/0x113 > [] do_open+0x9f/0x2a7 > [] blkdev_open+0x2e/0x5d > [] __dentry_open+0xd9/0x1a7 > [] do_filp_open+0x2a/0x38 > [] do_sys_open+0x44/0xc8 > [] system_call+0x7e/0x83 Bit 29 of current->preempt_count got set. I don't think there's any way in which that can happen normally. So probably some hardware or software error reached out and flipped that bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote: Got this on booting up on x86_64 test box. Didn't happen on next boot. BUG: scheduling while atomic: hald-addon-stor/0x2000/3300 Call Trace: [] show_trace+0x34/0x47 [] dump_stack+0x12/0x17 [] __sched_text_start+0x5d/0x7ba [] __cond_resched+0x1c/0x44 [] cond_resched+0x29/0x30 [] __reacquire_kernel_lock+0x26/0x44 [] thread_return+0xac/0xea [] __cond_resched+0x1c/0x44 [] cond_resched+0x29/0x30 [] wait_for_completion+0x17/0xd2 [] blk_execute_rq+0x98/0xb8 [] scsi_execute+0xd4/0xf1 [] scsi_execute_req+0xb9/0xde [] scsi_test_unit_ready+0x39/0x75 [] sd_media_changed+0x40/0x87 [] check_disk_change+0x1f/0x76 [] sd_open+0x80/0x113 [] do_open+0x9f/0x2a7 [] blkdev_open+0x2e/0x5d [] __dentry_open+0xd9/0x1a7 [] do_filp_open+0x2a/0x38 [] do_sys_open+0x44/0xc8 [] system_call+0x7e/0x83 [<2b6c5bb34580>] --- ~Randy kconfig: http://oss.oracle.com/~rdunlap/configs/config-2620-rc1mm1 full log: http://oss.oracle.com/~rdunlap/logs/2620-rc1mm1.out - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006 23:38:23 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > Looks like we have a problem with slab shrinking here.
> > >
> > > Could you please use gdb to check what exactly is at shrink_slab+0x9e?
> >
> > Sure, but not till Friday, sorry (I am away).
>
> I reproduced this on one box, but then it turned out that EIP was at line 195
> of mm/vmscan.c where there was
>
> do_div(delta, lru_pages + 1);
That implies that we passed it lru_pages=-1.
Presumably the logic in
vmscanc-account-for-memory-already-freed-in-seeking-to.patch caused that.
> Well, I have no idea how this can lead to a divide error (lru_pages is
> unsigned).
>
> I'm unable to reproduce this on another i386 box, so it seems to be somewhat
> configuration specific.
>
There is one wart in shrink_all_memory() and I think we should fix that in
2.6.20.
Please check the below. I'll drop
vmscanc-account-for-memory-already-freed-in-seeking-to.patch. It has other
stuff in it which we might still need. But altering sc->swap_cluster_max
in that manner looks odd.
From: Andrew Morton <[EMAIL PROTECTED]>
At the end of shrink_all_memory() we forget to recalculate lru_pages: it can
be zero.
Fix that up, and add a helper function for this operation too.
Also, recalculate lru_pages each time around the inner loop to get the
balancing correct.
Cc: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
mm/vmscan.c | 33 -
1 files changed, 16 insertions(+), 17 deletions(-)
diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
--- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
+++ a/mm/vmscan.c
@@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
return ret;
}
+static unsigned long count_lru_pages(void)
+{
+ struct zone *zone;
+ unsigned long ret = 0;
+
+ for_each_zone(zone);
+ ret += zone->nr_active + zone->nr_inactive;
+ return ret;
+}
+
/*
* Try to free `nr_pages' of memory, system-wide, and return the number of
* freed pages.
@@ -1498,7 +1508,6 @@ unsigned long shrink_all_memory(unsigned
unsigned long ret = 0;
int pass;
struct reclaim_state reclaim_state;
- struct zone *zone;
struct scan_control sc = {
.gfp_mask = GFP_KERNEL,
.may_swap = 0,
@@ -1509,10 +1518,7 @@ unsigned long shrink_all_memory(unsigned
current->reclaim_state = _state;
- lru_pages = 0;
- for_each_zone(zone)
- lru_pages += zone->nr_active + zone->nr_inactive;
-
+ lru_pages = count_lru_pages();
nr_slab = global_page_state(NR_SLAB_RECLAIMABLE);
/* If slab caches are huge, it's better to hit them first */
while (nr_slab >= lru_pages) {
@@ -1539,13 +1545,6 @@ unsigned long shrink_all_memory(unsigned
for (pass = 0; pass < 5; pass++) {
int prio;
- /* Needed for shrinking slab caches later on */
- if (!lru_pages)
- for_each_zone(zone) {
- lru_pages += zone->nr_active;
- lru_pages += zone->nr_inactive;
- }
-
/* Force reclaiming mapped pages in the passes #3 and #4 */
if (pass > 2) {
sc.may_swap = 1;
@@ -1561,7 +1560,8 @@ unsigned long shrink_all_memory(unsigned
goto out;
reclaim_state.reclaimed_slab = 0;
- shrink_slab(sc.nr_scanned, sc.gfp_mask, lru_pages);
+ shrink_slab(sc.nr_scanned, sc.gfp_mask,
+ count_lru_pages());
ret += reclaim_state.reclaimed_slab;
if (ret >= nr_pages)
goto out;
@@ -1569,20 +1569,19 @@ unsigned long shrink_all_memory(unsigned
if (sc.nr_scanned && prio < DEF_PRIORITY - 2)
congestion_wait(WRITE, HZ / 10);
}
-
- lru_pages = 0;
}
/*
* If ret = 0, we could not shrink LRUs, but there may be something
* in slab caches
*/
- if (!ret)
+ if (!ret) {
do {
reclaim_state.reclaimed_slab = 0;
- shrink_slab(nr_pages, sc.gfp_mask, lru_pages);
+ shrink_slab(nr_pages, sc.gfp_mask, count_lru_pages());
ret += reclaim_state.reclaimed_slab;
} while (ret < nr_pages && reclaim_state.reclaimed_slab > 0);
+ }
out:
current->reclaim_state = NULL;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi. On Tue, 2006-12-19 at 00:09 +0100, Rafael J. Wysocki wrote: > Hi, > > On Monday, 18 December 2006 23:44, Nigel Cunningham wrote: > > Hi. > > > > On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote: > > > On Monday, 18 December 2006 18:02, Jiri Slaby wrote: > > > > Rafael J. Wysocki wrote: > > > > > Hi, > > > > > > > > > > On Monday, 18 December 2006 12:20, Jiri Slaby wrote: > > > > >> Hi. > > > > >> > > > > >> I got this oops while suspending: > > > > >> [ 309.366557] Disabling non-boot CPUs ... > > > > >> [ 309.386563] CPU 1 is now offline > > > > >> [ 309.387625] CPU1 is down > > > > >> [ 309.387704] Stopping tasks ... done. > > > > >> [ 310.030991] Shrinking memory... -<0>divide error: [#1] > > > > >> [ 310.456669] SMP > > > > >> [ 310.456814] last sysfs file: > > > > >> /devices/pci:00/0000:00:1e.0/0000:02:08.0/eth0/statistics/collisions > > > > >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd > > > > >> ieee1394 cdrom > > > > >> [ 310.457259] CPU:0 > > > > >> [ 310.457260] EIP:0060:[]Not tainted VLI > > > > >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) > > > > >> [ 310.457478] EIP is at shrink_slab+0x9e/0x169 > > > > > > > > > > Looks like we have a problem with slab shrinking here. > > > > > > > > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? > > > > > > > > Sure, but not till Friday, sorry (I am away). > > > > > > I reproduced this on one box, but then it turned out that EIP was at line > > > 195 > > > of mm/vmscan.c where there was > > > > > > do_div(delta, lru_pages + 1); > > > > > > Well, I have no idea how this can lead to a divide error (lru_pages is > > > unsigned). > > > > > > I'm unable to reproduce this on another i386 box, so it seems to be > > > somewhat > > > configuration specific. > > > > > > Does 2.6.20-rc1 work for you? > > > > I have a patch in -mm that reduces lru_pages by what shrink_all_zones > > returns. Could shrink_all_zones perhaps be returning incorrect values > > such that lru_pages ends up becoming -1? > > I don't think so, but look at the appended patch. ;-) > > Greetings, > Rafael > > > --- > Fix a (really bad) typo in shrink_all_memory(). > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > --- > mm/vmscan.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6.20-rc1-mm1/mm/vmscan.c > === > --- linux-2.6.20-rc1-mm1.orig/mm/vmscan.c > +++ linux-2.6.20-rc1-mm1/mm/vmscan.c > @@ -1569,7 +1569,7 @@ unsigned long shrink_all_memory(unsigned > sc.swap_cluster_max = nr_pages - ret; > freed = shrink_all_zones(nr_to_scan, prio, pass, ); > ret += freed; > - lru_pages =- freed; > + lru_pages -= freed; > nr_to_scan = nr_pages - ret; > if (ret >= nr_pages) > goto out; Heh, yeah. Definitely acked! :) Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi, On Monday, 18 December 2006 23:44, Nigel Cunningham wrote: > Hi. > > On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote: > > On Monday, 18 December 2006 18:02, Jiri Slaby wrote: > > > Rafael J. Wysocki wrote: > > > > Hi, > > > > > > > > On Monday, 18 December 2006 12:20, Jiri Slaby wrote: > > > >> Hi. > > > >> > > > >> I got this oops while suspending: > > > >> [ 309.366557] Disabling non-boot CPUs ... > > > >> [ 309.386563] CPU 1 is now offline > > > >> [ 309.387625] CPU1 is down > > > >> [ 309.387704] Stopping tasks ... done. > > > >> [ 310.030991] Shrinking memory... -<0>divide error: [#1] > > > >> [ 310.456669] SMP > > > >> [ 310.456814] last sysfs file: > > > >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions > > > >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd > > > >> ieee1394 cdrom > > > >> [ 310.457259] CPU:0 > > > >> [ 310.457260] EIP:0060:[]Not tainted VLI > > > >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) > > > >> [ 310.457478] EIP is at shrink_slab+0x9e/0x169 > > > > > > > > Looks like we have a problem with slab shrinking here. > > > > > > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? > > > > > > Sure, but not till Friday, sorry (I am away). > > > > I reproduced this on one box, but then it turned out that EIP was at line > > 195 > > of mm/vmscan.c where there was > > > > do_div(delta, lru_pages + 1); > > > > Well, I have no idea how this can lead to a divide error (lru_pages is > > unsigned). > > > > I'm unable to reproduce this on another i386 box, so it seems to be somewhat > > configuration specific. > > > > Does 2.6.20-rc1 work for you? > > I have a patch in -mm that reduces lru_pages by what shrink_all_zones > returns. Could shrink_all_zones perhaps be returning incorrect values > such that lru_pages ends up becoming -1? I don't think so, but look at the appended patch. ;-) Greetings, Rafael --- Fix a (really bad) typo in shrink_all_memory(). Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> --- mm/vmscan.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.20-rc1-mm1/mm/vmscan.c === --- linux-2.6.20-rc1-mm1.orig/mm/vmscan.c +++ linux-2.6.20-rc1-mm1/mm/vmscan.c @@ -1569,7 +1569,7 @@ unsigned long shrink_all_memory(unsigned sc.swap_cluster_max = nr_pages - ret; freed = shrink_all_zones(nr_to_scan, prio, pass, ); ret += freed; - lru_pages =- freed; + lru_pages -= freed; nr_to_scan = nr_pages - ret; if (ret >= nr_pages) goto out; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi. On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote: > On Monday, 18 December 2006 18:02, Jiri Slaby wrote: > > Rafael J. Wysocki wrote: > > > Hi, > > > > > > On Monday, 18 December 2006 12:20, Jiri Slaby wrote: > > >> Hi. > > >> > > >> I got this oops while suspending: > > >> [ 309.366557] Disabling non-boot CPUs ... > > >> [ 309.386563] CPU 1 is now offline > > >> [ 309.387625] CPU1 is down > > >> [ 309.387704] Stopping tasks ... done. > > >> [ 310.030991] Shrinking memory... -<0>divide error: [#1] > > >> [ 310.456669] SMP > > >> [ 310.456814] last sysfs file: > > >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions > > >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd > > >> ieee1394 cdrom > > >> [ 310.457259] CPU:0 > > >> [ 310.457260] EIP:0060:[]Not tainted VLI > > >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) > > >> [ 310.457478] EIP is at shrink_slab+0x9e/0x169 > > > > > > Looks like we have a problem with slab shrinking here. > > > > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? > > > > Sure, but not till Friday, sorry (I am away). > > I reproduced this on one box, but then it turned out that EIP was at line 195 > of mm/vmscan.c where there was > > do_div(delta, lru_pages + 1); > > Well, I have no idea how this can lead to a divide error (lru_pages is > unsigned). > > I'm unable to reproduce this on another i386 box, so it seems to be somewhat > configuration specific. > > Does 2.6.20-rc1 work for you? I have a patch in -mm that reduces lru_pages by what shrink_all_zones returns. Could shrink_all_zones perhaps be returning incorrect values such that lru_pages ends up becoming -1? Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Monday, 18 December 2006 18:02, Jiri Slaby wrote: > Rafael J. Wysocki wrote: > > Hi, > > > > On Monday, 18 December 2006 12:20, Jiri Slaby wrote: > >> Hi. > >> > >> I got this oops while suspending: > >> [ 309.366557] Disabling non-boot CPUs ... > >> [ 309.386563] CPU 1 is now offline > >> [ 309.387625] CPU1 is down > >> [ 309.387704] Stopping tasks ... done. > >> [ 310.030991] Shrinking memory... -<0>divide error: [#1] > >> [ 310.456669] SMP > >> [ 310.456814] last sysfs file: > >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions > >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 > >> cdrom > >> [ 310.457259] CPU:0 > >> [ 310.457260] EIP:0060:[]Not tainted VLI > >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) > >> [ 310.457478] EIP is at shrink_slab+0x9e/0x169 > > > > Looks like we have a problem with slab shrinking here. > > > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? > > Sure, but not till Friday, sorry (I am away). I reproduced this on one box, but then it turned out that EIP was at line 195 of mm/vmscan.c where there was do_div(delta, lru_pages + 1); Well, I have no idea how this can lead to a divide error (lru_pages is unsigned). I'm unable to reproduce this on another i386 box, so it seems to be somewhat configuration specific. Does 2.6.20-rc1 work for you? Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006 18:02:20 +0100
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Monday, 18 December 2006 12:20, Jiri Slaby wrote:
> >> Hi.
> >>
> >> I got this oops while suspending:
> >> [ 309.366557] Disabling non-boot CPUs ...
> >> [ 309.386563] CPU 1 is now offline
> >> [ 309.387625] CPU1 is down
> >> [ 309.387704] Stopping tasks ... done.
> >> [ 310.030991] Shrinking memory... -<0>divide error: [#1]
> >> [ 310.456669] SMP
> >> [ 310.456814] last sysfs file:
> >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
> >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394
> >> cdrom
> >> [ 310.457259] CPU:0
> >> [ 310.457260] EIP:0060:[]Not tainted VLI
> >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
> >> [ 310.457478] EIP is at shrink_slab+0x9e/0x169
> >
> > Looks like we have a problem with slab shrinking here.
> >
> > Could you please use gdb to check what exactly is at shrink_slab+0x9e?
>
> Sure, but not till Friday, sorry (I am away).
I think there's only one divide in there which can do this, so...
--- a/mm/vmscan.c~shrink_slab-handle-bad-shrinkers
+++ a/mm/vmscan.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -190,7 +191,13 @@ unsigned long shrink_slab(unsigned long
unsigned long total_scan;
unsigned long max_pass = (*shrinker->shrinker)(0, gfp_mask);
- delta = (4 * scanned) / shrinker->seeks;
+ if (!shrinker->seeks) {
+ print_symbol("shrinker %s has zero seeks\n",
+ (unsigned long)shrinker->shrinker);
+ delta = (4 * scanned) / DEFAULT_SEEKS;
+ } else {
+ delta = (4 * scanned) / shrinker->seeks;
+ }
delta *= max_pass;
do_div(delta, lru_pages + 1);
shrinker->nr += delta;
_
A quick grep shows that all set_shrinker() callers are doing the right
thing, so something kooky has happened.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On 12/15/06, Andrew Morton <[EMAIL PROTECTED]> wrote: +toshiba-tc86c001-ide-driver-take-2.patch Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> IMO this can be merged for 2.6.20 as it is new driver (which is clean, tested and acked by Alan already) All 693 patches: hpt3xx-rework-rate-filtering.patch HPT3xx: rework rate filtering ACK hpt3xx-rework-rate-filtering-tidy.patch hpt3xx-rework-rate-filtering-tidy ACK hpt3xx-print-the-real-chip-name-at-startup.patch HPT3xx: print the real chip name at startup ACK hpt3xx-switch-to-using-pci_get_slot.patch HPT3xx: switch to using pci_get_slot() ACK hpt3xx-cache-channels-mcr-address.patch [PATCH] HPT3xx: cache channel's MCR address ACK hpt3x7-merge-speedproc-handlers.patch HPT3x7: merge speedproc handlers ACK hpt370-clean-up-dma-timeout-handling.patch HPT370: clean up DMA timeout handling ACK hpt3xx-init-code-rewrite.patch HPT3xx: init code rewrite ACK piix-fix-82371mx-enablebits.patch PIIX: fix 82371MX enablebits ACK, thought I haven't compared wrt datasheet yet piix-remove-check-for-broken-mw-dma-mode-0.patch PIIX: remove check for broken MW DMA mode 0 ACK, 100% correct and non-intrusive cleanup piix-slc90e66-pio-mode-fallback-fix.patch PIIX/SLC90E66: PIO mode fallback fix ACK, this is an important bugfix pdc202xx_new-remove-useless-code.patch pdc202xx_new: remove useless code ACK, nice cleanup pdc202xx_-remove-check_in_drive_lists-abomination.patch pdc202xx_*: remove check_in_drive_lists() abomination ACK, ditto I think that all above patches from Sergei should be merged now as they are either bugfixes or not-intrusive cleanups and got more than enough exposure in -mm (since 2.6.17-mm). jmicron-warning-fix.patch Wouldn't it be neater to add BUG() instead? Seems to fix warning for me and documents nicely that this case cannot happen. Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
Miles Lane wrote: > On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote: >> Miles Lane wrote: >> > Sorry, I am not finding who maintains highmem. Please forward. >> > >> > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic() >> > [] dump_trace+0x68/0x1d2 >> > [] show_trace_log_lvl+0x18/0x2c >> > [] show_trace+0xf/0x11 >> > [] dump_stack+0x12/0x14 >> > [] kmap_atomic+0x6f/0x1ca >> > [] ntfs_end_buffer_async_read+0x25d/0x2ca [ntfs] >> > [] end_bio_bh_io_sync+0x2c/0x37 >> > [] bio_endio+0x5a/0x62 >> > [] __end_that_request_first+0x145/0x3ab >> > [] ide_end_request+0x80/0xd8 >> > [] ide_dma_intr+0x55/0x9a >> > [] ide_intr+0x182/0x1f2 >> > [] handle_IRQ_event+0x1a/0x3f >> > [] handle_edge_irq+0xc6/0x11c >> > [] do_IRQ+0x57/0x71 >> > [] common_interrupt+0x23/0x28 >> > [] acpi_processor_idle+0x1cc/0x36c [processor] >> > [] cpu_idle+0x3e/0x6c >> > [] start_kernel+0x2fa/0x2fe >> > === >> >> Reported yet, you might see it here: >> http://lkml.org/lkml/2006/12/15/222 > > It is certainly very similar, and probably has the same root cause. > Though, the trace isn't an exact match. So, who should look into > this? The trace needn't be the same. The problem was, that kmap_atomic didn't know KM_BIO_SRC_IRQ which is called (twice) from ntfs_end_buffer_async_read. It doesn't matter who called this ntfs function and why. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
On 12/18/06, Jiri Slaby <[EMAIL PROTECTED]> wrote: Miles Lane wrote: > Sorry, I am not finding who maintains highmem. Please forward. > > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic() > [] dump_trace+0x68/0x1d2 > [] show_trace_log_lvl+0x18/0x2c > [] show_trace+0xf/0x11 > [] dump_stack+0x12/0x14 > [] kmap_atomic+0x6f/0x1ca > [] ntfs_end_buffer_async_read+0x25d/0x2ca [ntfs] > [] end_bio_bh_io_sync+0x2c/0x37 > [] bio_endio+0x5a/0x62 > [] __end_that_request_first+0x145/0x3ab > [] ide_end_request+0x80/0xd8 > [] ide_dma_intr+0x55/0x9a > [] ide_intr+0x182/0x1f2 > [] handle_IRQ_event+0x1a/0x3f > [] handle_edge_irq+0xc6/0x11c > [] do_IRQ+0x57/0x71 > [] common_interrupt+0x23/0x28 > [] acpi_processor_idle+0x1cc/0x36c [processor] > [] cpu_idle+0x3e/0x6c > [] start_kernel+0x2fa/0x2fe > === Reported yet, you might see it here: http://lkml.org/lkml/2006/12/15/222 It is certainly very similar, and probably has the same root cause. Though, the trace isn't an exact match. So, who should look into this? Thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
Miles Lane wrote: > Sorry, I am not finding who maintains highmem. Please forward. > > WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic() > [] dump_trace+0x68/0x1d2 > [] show_trace_log_lvl+0x18/0x2c > [] show_trace+0xf/0x11 > [] dump_stack+0x12/0x14 > [] kmap_atomic+0x6f/0x1ca > [] ntfs_end_buffer_async_read+0x25d/0x2ca [ntfs] > [] end_bio_bh_io_sync+0x2c/0x37 > [] bio_endio+0x5a/0x62 > [] __end_that_request_first+0x145/0x3ab > [] ide_end_request+0x80/0xd8 > [] ide_dma_intr+0x55/0x9a > [] ide_intr+0x182/0x1f2 > [] handle_IRQ_event+0x1a/0x3f > [] handle_edge_irq+0xc6/0x11c > [] do_IRQ+0x57/0x71 > [] common_interrupt+0x23/0x28 > [] acpi_processor_idle+0x1cc/0x36c [processor] > [] cpu_idle+0x3e/0x6c > [] start_kernel+0x2fa/0x2fe > === Reported yet, you might see it here: http://lkml.org/lkml/2006/12/15/222 regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
> > > The reiser4 failure is unexpected. Could you please see if you can > > > capture a trace, let the people at [EMAIL PROTECTED] know? > > Ok, I've handwritten the messages, here they are : > > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom > > (fs/reiser4/txmngr.c:1087) (zam-597) > > write log failed (-5) > > [ got 2 copies of them because I have 2 reiser4 fs) > > I got them mainly when I try to reboot or halt the machine, and the > > process doesn't finish, the computer gets stuck after the reiser4 > > messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. * Laurent Riffard <[EMAIL PROTECTED]> [2006-12-18 09:03]: > fix-sense-key-medium-error-processing-and-retry.patch seems to be the > culprit. > Reverting it fix those reiser4 panics for me. Damien, could you confirm > please ? Yes, this fixes it too on my side. Thanks for this tracking ! -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Rafael J. Wysocki wrote: > Hi, > > On Monday, 18 December 2006 12:20, Jiri Slaby wrote: >> Hi. >> >> I got this oops while suspending: >> [ 309.366557] Disabling non-boot CPUs ... >> [ 309.386563] CPU 1 is now offline >> [ 309.387625] CPU1 is down >> [ 309.387704] Stopping tasks ... done. >> [ 310.030991] Shrinking memory... -<0>divide error: [#1] >> [ 310.456669] SMP >> [ 310.456814] last sysfs file: >> /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions >> [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 >> cdrom >> [ 310.457259] CPU:0 >> [ 310.457260] EIP:0060:[]Not tainted VLI >> [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) >> [ 310.457478] EIP is at shrink_slab+0x9e/0x169 > > Looks like we have a problem with slab shrinking here. > > Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). >> [ 310.457548] eax: ebx: ecx: edx: >> [ 310.457623] esi: edi: c18fe500 ebp: f7b3fe3c esp: f7b3fe08 >> [ 310.457696] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 >> [ 310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030 >> task.ti=f7b3e000) >> [ 310.457845] Stack: c175d8a0 c175daa0 c175db00 c053cec0 >> 45ec 00d0 >> [ 310.458286] 1179 1179 f7b3fe94 >> c0151445 0001 >> [ 310.458723]f7b3fe64 1df1 0002 0001 0001 00038000 >> 0c79 117b >> [ 310.459199] Call Trace: >> [ 310.459334] [] show_trace_log_lvl+0x1a/0x30 >> [ 310.459450] [] show_stack_log_lvl+0xa5/0xca >> [ 310.459562] [] show_registers+0x1d3/0x2b8 >> [ 310.459673] [] die+0x121/0x243 >> [ 310.459781] [] do_trap+0x76/0x9c >> [ 310.459892] [] do_divide_error+0x94/0x9e >> [ 310.460001] [] error_code+0x7c/0x84 >> [ 310.460113] [] shrink_all_memory+0x211/0x2eb >> [ 310.460225] [] swsusp_shrink_memory+0x187/0x196 >> [ 310.460335] [] prepare_processes+0x35/0xc8 >> [ 310.460446] [] pm_suspend_disk+0xd/0x16f >> [ 310.460558] [] enter_state+0x129/0x19b >> [ 310.460668] [] state_store+0xa3/0xac >> [ 310.460777] [] subsys_attr_store+0x20/0x25 >> [ 310.460889] [] sysfs_write_file+0x97/0xd8 >> [ 310.460998] [] vfs_write+0x8b/0x149 >> [ 310.461108] [] sys_write+0x3d/0x64 >> [ 310.461216] [] syscall_call+0x7/0xb >> [ 310.461328] === >> [ 310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 >> d8 89 >> 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0 75 >> f0 >> 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85 >> [ 310.464079] EIP: [] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08 >> [ 310.464228] >> >> swsusp script is something like this: >> echo platform > /sys/power/disk >> echo disk > /sys/power/state regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-mm1 - TPM Follies on Dell Latitude D820
(Yes, I *know* the answer is probably "Get Dell to fix the BIOS settings", but I'll need some more info on exactly what to tell them so it gets fixed right. Scenario - I recently got a Dell Latitude D820 to replace my aging C840. Am running Fedora Core Rawhide in (mostly) 64-bit mode. Folly 1: If you boot with the BIOS TPM setting to 'Disabled', you get this: [0.00] DMI 2.4 present. [0.00] ACPI: RSDP (v000 DELL ) @ 0x000fc0b0 [0.00] ACPI: RSDT (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe8198a [0.00] ACPI: FADT (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe82800 [0.00] ACPI: HPET (v001 DELLM07 0x0001 ASL 0x0061) @ 0x7fe82f00 [0.00] ACPI: MADT (v001 DELLM07 0x27d60a0d ASL 0x0047) @ 0x7fe83000 [0.00] ACPI: ASF! (v016 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe82c00 [0.00] ACPI: MCFG (v016 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe82fc0 [0.00] ACPI: SLIC (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe8309c [0.00] ACPI: TCPA (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe83300 [0.00] >>> ERROR: Invalid checksum [0.00] ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20050624) @ 0x7fe81a11 [0.00] ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 INTL 0x20050624) @ 0x The 'invalid checksum' message goes away if you enable the TPM. Note that this one happens even if you don't have TPM support enabled in the kernel. The code in drivers/acpi/tables.c isn't incredibly verbose about what the exact problem is - I'm willing to add instrumentation if somebody can tell me what would be actually useful to dump out. Folly 2: when userspace gets around to doing a 'modprobe tpm_tis', we get the following complaint: [ 76.318668] tpm_tis 00:0d: 1.2 TPM (device-id 0x1001, rev-id 2) [ 76.378236] IRQ handler type mismatch for IRQ 8 [ 76.378239] current handler: rtc [ 76.378240] [ 76.378241] Call Trace: [ 76.378255] [] dump_trace+0xb9/0x3b3 [ 76.378261] [] show_trace+0x3c/0x52 [ 76.378265] [] dump_stack+0x15/0x17 [ 76.378270] [] setup_irq+0x1c2/0x1e6 [ 76.378275] [] request_irq+0x9e/0xc7 [ 76.378282] [] :tpm_tis:tpm_tis_init+0x205/0x44c [ 76.378290] [] :tpm_tis:tpm_tis_pnp_init+0x2e/0x30 [ 76.378296] [] pnp_device_probe+0x7b/0xa0 [ 76.378302] [] driver_probe_device+0xbc/0x138 [ 76.378307] [] __driver_attach+0x5b/0x94 [ 76.378312] [] bus_for_each_dev+0x49/0x7a [ 76.378316] [] driver_attach+0x1c/0x1e [ 76.378320] [] bus_add_driver+0x75/0x199 [ 76.378324] [] driver_register+0x85/0x89 [ 76.378328] [] pnp_register_driver+0x1c/0x1e [ 76.378333] [] :tpm_tis:init_tis+0x81/0x89 [ 76.378339] [] sys_init_module+0xac/0x17d [ 76.378345] [] system_call+0x7e/0x83 [ 76.378352] [<0039d1acd90a>] [ 76.378354] [ 76.378355] tpm_tis 00:0d: Unable to request irq: 8 for probe (2.6.19-rc6-mm2 would repeat the complaint on IRQ 14 and then 15 as well) /proc/interrupts says: CPU0 CPU1 0:1577201 0 IO-APIC-edge timer 1: 4851 0 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 9: 2 0 IO-APIC-fasteoi acpi 12:145 0 IO-APIC-edge i8042 14: 13647 40481 IO-APIC-edge libata 15: 59 7876 IO-APIC-edge libata 16: 64047 0 IO-APIC-fasteoi nvidia 17: 0 0 IO-APIC-fasteoi ipw3945 19: 10 0 IO-APIC-fasteoi yenta, ohci1394 20: 28 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 5303 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel 22: 29 4701 IO-APIC-fasteoi uhci_hcd:usb4 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb5 NMI: 0 0 LOC:15770871577049 ERR: 0 Any ideas/suggestions? pgpP8C6vfTIja.pgp Description: PGP signature
2.6.20-rc1-mm1 - another minor Dell Latitude D820 issue...
I'd never have noticed an issue if I hadn't looked in the dmesg for something else, so it isn't a high-priority item.. I admit being fuzzy on what, if anything, even *actually* needs fixing (ISTR for some people, there was some config issue with the transparent bridges being only translucent, but as I don't currently use the Firewire or Cardbus hardware, it's hard to tell..) Seen in dmesg: [ 64.846421] Boot video device is :01:00.0 [ 64.847312] PCI: Transparent bridge - :00:1e.0 [ 64.847380] PCI: Bus #04 (-#07) is hidden behind transparent bridge #03 (-#04) (try 'pci=assign-busses') [ 64.847385] Please report the result to linux-kernel to fix this permanently lspci without assign-busses: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 110M / GeForce Go 7300 (rev a1) 03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) and with assign-busses: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 110M / GeForce Go 7300 (rev a1) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02) 06:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 06:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) What, if anything, needs to happen here? pgpuQngNtEnAO.pgp Description: PGP signature
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: > Hi. > > I got this oops while suspending: > [ 309.366557] Disabling non-boot CPUs ... > [ 309.386563] CPU 1 is now offline > [ 309.387625] CPU1 is down > [ 309.387704] Stopping tasks ... done. > [ 310.030991] Shrinking memory... -<0>divide error: [#1] > [ 310.456669] SMP > [ 310.456814] last sysfs file: > /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions > [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 > cdrom > [ 310.457259] CPU:0 > [ 310.457260] EIP:0060:[]Not tainted VLI > [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) > [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? > [ 310.457548] eax: ebx: ecx: edx: > [ 310.457623] esi: edi: c18fe500 ebp: f7b3fe3c esp: f7b3fe08 > [ 310.457696] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [ 310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030 > task.ti=f7b3e000) > [ 310.457845] Stack: c175d8a0 c175daa0 c175db00 c053cec0 > 45ec 00d0 > [ 310.458286] 1179 1179 f7b3fe94 > c0151445 0001 > [ 310.458723]f7b3fe64 1df1 0002 0001 0001 00038000 > 0c79 117b > [ 310.459199] Call Trace: > [ 310.459334] [] show_trace_log_lvl+0x1a/0x30 > [ 310.459450] [] show_stack_log_lvl+0xa5/0xca > [ 310.459562] [] show_registers+0x1d3/0x2b8 > [ 310.459673] [] die+0x121/0x243 > [ 310.459781] [] do_trap+0x76/0x9c > [ 310.459892] [] do_divide_error+0x94/0x9e > [ 310.460001] [] error_code+0x7c/0x84 > [ 310.460113] [] shrink_all_memory+0x211/0x2eb > [ 310.460225] [] swsusp_shrink_memory+0x187/0x196 > [ 310.460335] [] prepare_processes+0x35/0xc8 > [ 310.460446] [] pm_suspend_disk+0xd/0x16f > [ 310.460558] [] enter_state+0x129/0x19b > [ 310.460668] [] state_store+0xa3/0xac > [ 310.460777] [] subsys_attr_store+0x20/0x25 > [ 310.460889] [] sysfs_write_file+0x97/0xd8 > [ 310.460998] [] vfs_write+0x8b/0x149 > [ 310.461108] [] sys_write+0x3d/0x64 > [ 310.461216] [] syscall_call+0x7/0xb > [ 310.461328] === > [ 310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 > 89 > 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0 75 > f0 > 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85 > [ 310.464079] EIP: [] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08 > [ 310.464228] > > swsusp script is something like this: > echo platform > /sys/power/disk > echo disk > /sys/power/state > > regards, Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -<0>divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 [ 310.457548] eax: ebx: ecx: edx: [ 310.457623] esi: edi: c18fe500 ebp: f7b3fe3c esp: f7b3fe08 [ 310.457696] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030 task.ti=f7b3e000) [ 310.457845] Stack: c175d8a0 c175daa0 c175db00 c053cec0 45ec 00d0 [ 310.458286] 1179 1179 f7b3fe94 c0151445 0001 [ 310.458723]f7b3fe64 1df1 0002 0001 0001 00038000 0c79 117b [ 310.459199] Call Trace: [ 310.459334] [] show_trace_log_lvl+0x1a/0x30 [ 310.459450] [] show_stack_log_lvl+0xa5/0xca [ 310.459562] [] show_registers+0x1d3/0x2b8 [ 310.459673] [] die+0x121/0x243 [ 310.459781] [] do_trap+0x76/0x9c [ 310.459892] [] do_divide_error+0x94/0x9e [ 310.460001] [] error_code+0x7c/0x84 [ 310.460113] [] shrink_all_memory+0x211/0x2eb [ 310.460225] [] swsusp_shrink_memory+0x187/0x196 [ 310.460335] [] prepare_processes+0x35/0xc8 [ 310.460446] [] pm_suspend_disk+0xd/0x16f [ 310.460558] [] enter_state+0x129/0x19b [ 310.460668] [] state_store+0xa3/0xac [ 310.460777] [] subsys_attr_store+0x20/0x25 [ 310.460889] [] sysfs_write_file+0x97/0xd8 [ 310.460998] [] vfs_write+0x8b/0x149 [ 310.461108] [] sys_write+0x3d/0x64 [ 310.461216] [] syscall_call+0x7/0xb [ 310.461328] === [ 310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 89 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0 75 f0 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85 [ 310.464079] EIP: [] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08 [ 310.464228] swsusp script is something like this: echo platform > /sys/power/disk echo disk > /sys/power/state regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
Le 17.12.2006 12:07, Damien Wyart a écrit : Also, I got panics when unmounting reiser4 filesystems with 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 being broken in 2.6.19-mm1 (even if it is not listed in notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report the xfs messages which seems a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? ~~ laurent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
Le 17.12.2006 12:07, Damien Wyart a écrit : Also, I got panics when unmounting reiser4 filesystems with 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 being broken in 2.6.19-mm1 (even if it is not listed in notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report the xfs messages which seems a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? ~~ laurent - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 [ 310.457548] eax: ebx: ecx: edx: [ 310.457623] esi: edi: c18fe500 ebp: f7b3fe3c esp: f7b3fe08 [ 310.457696] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030 task.ti=f7b3e000) [ 310.457845] Stack: c175d8a0 c175daa0 c175db00 c053cec0 45ec 00d0 [ 310.458286] 1179 1179 f7b3fe94 c0151445 0001 [ 310.458723]f7b3fe64 1df1 0002 0001 0001 00038000 0c79 117b [ 310.459199] Call Trace: [ 310.459334] [c0103f1b] show_trace_log_lvl+0x1a/0x30 [ 310.459450] [c0103fd6] show_stack_log_lvl+0xa5/0xca [ 310.459562] [c01041ce] show_registers+0x1d3/0x2b8 [ 310.459673] [c01043d4] die+0x121/0x243 [ 310.459781] [c010456c] do_trap+0x76/0x9c [ 310.459892] [c0104bd8] do_divide_error+0x94/0x9e [ 310.460001] [c038a7e4] error_code+0x7c/0x84 [ 310.460113] [c0151445] shrink_all_memory+0x211/0x2eb [ 310.460225] [c01418c1] swsusp_shrink_memory+0x187/0x196 [ 310.460335] [c0141a07] prepare_processes+0x35/0xc8 [ 310.460446] [c0141cce] pm_suspend_disk+0xd/0x16f [ 310.460558] [c0140c87] enter_state+0x129/0x19b [ 310.460668] [c0140d9c] state_store+0xa3/0xac [ 310.460777] [c0198ab0] subsys_attr_store+0x20/0x25 [ 310.460889] [c0198b9f] sysfs_write_file+0x97/0xd8 [ 310.460998] [c0165262] vfs_write+0x8b/0x149 [ 310.461108] [c01658cb] sys_write+0x3d/0x64 [ 310.461216] [c0102fe4] syscall_call+0x7/0xb [ 310.461328] === [ 310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 89 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0 f7 75 f0 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85 [ 310.464079] EIP: [c0150c9a] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08 [ 310.464228] swsusp script is something like this: echo platform /sys/power/disk echo disk /sys/power/state regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? [ 310.457548] eax: ebx: ecx: edx: [ 310.457623] esi: edi: c18fe500 ebp: f7b3fe3c esp: f7b3fe08 [ 310.457696] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030 task.ti=f7b3e000) [ 310.457845] Stack: c175d8a0 c175daa0 c175db00 c053cec0 45ec 00d0 [ 310.458286] 1179 1179 f7b3fe94 c0151445 0001 [ 310.458723]f7b3fe64 1df1 0002 0001 0001 00038000 0c79 117b [ 310.459199] Call Trace: [ 310.459334] [c0103f1b] show_trace_log_lvl+0x1a/0x30 [ 310.459450] [c0103fd6] show_stack_log_lvl+0xa5/0xca [ 310.459562] [c01041ce] show_registers+0x1d3/0x2b8 [ 310.459673] [c01043d4] die+0x121/0x243 [ 310.459781] [c010456c] do_trap+0x76/0x9c [ 310.459892] [c0104bd8] do_divide_error+0x94/0x9e [ 310.460001] [c038a7e4] error_code+0x7c/0x84 [ 310.460113] [c0151445] shrink_all_memory+0x211/0x2eb [ 310.460225] [c01418c1] swsusp_shrink_memory+0x187/0x196 [ 310.460335] [c0141a07] prepare_processes+0x35/0xc8 [ 310.460446] [c0141cce] pm_suspend_disk+0xd/0x16f [ 310.460558] [c0140c87] enter_state+0x129/0x19b [ 310.460668] [c0140d9c] state_store+0xa3/0xac [ 310.460777] [c0198ab0] subsys_attr_store+0x20/0x25 [ 310.460889] [c0198b9f] sysfs_write_file+0x97/0xd8 [ 310.460998] [c0165262] vfs_write+0x8b/0x149 [ 310.461108] [c01658cb] sys_write+0x3d/0x64 [ 310.461216] [c0102fe4] syscall_call+0x7/0xb [ 310.461328] === [ 310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 89 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0 f7 75 f0 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85 [ 310.464079] EIP: [c0150c9a] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08 [ 310.464228] swsusp script is something like this: echo platform /sys/power/disk echo disk /sys/power/state regards, Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-mm1 - another minor Dell Latitude D820 issue...
I'd never have noticed an issue if I hadn't looked in the dmesg for something else, so it isn't a high-priority item.. I admit being fuzzy on what, if anything, even *actually* needs fixing (ISTR for some people, there was some config issue with the transparent bridges being only translucent, but as I don't currently use the Firewire or Cardbus hardware, it's hard to tell..) Seen in dmesg: [ 64.846421] Boot video device is :01:00.0 [ 64.847312] PCI: Transparent bridge - :00:1e.0 [ 64.847380] PCI: Bus #04 (-#07) is hidden behind transparent bridge #03 (-#04) (try 'pci=assign-busses') [ 64.847385] Please report the result to linux-kernel to fix this permanently lspci without assign-busses: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 110M / GeForce Go 7300 (rev a1) 03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) and with assign-busses: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 110M / GeForce Go 7300 (rev a1) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02) 06:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 06:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) What, if anything, needs to happen here? pgpuQngNtEnAO.pgp Description: PGP signature
2.6.20-rc1-mm1 - TPM Follies on Dell Latitude D820
(Yes, I *know* the answer is probably Get Dell to fix the BIOS settings, but I'll need some more info on exactly what to tell them so it gets fixed right. Scenario - I recently got a Dell Latitude D820 to replace my aging C840. Am running Fedora Core Rawhide in (mostly) 64-bit mode. Folly 1: If you boot with the BIOS TPM setting to 'Disabled', you get this: [0.00] DMI 2.4 present. [0.00] ACPI: RSDP (v000 DELL ) @ 0x000fc0b0 [0.00] ACPI: RSDT (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe8198a [0.00] ACPI: FADT (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe82800 [0.00] ACPI: HPET (v001 DELLM07 0x0001 ASL 0x0061) @ 0x7fe82f00 [0.00] ACPI: MADT (v001 DELLM07 0x27d60a0d ASL 0x0047) @ 0x7fe83000 [0.00] ACPI: ASF! (v016 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe82c00 [0.00] ACPI: MCFG (v016 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe82fc0 [0.00] ACPI: SLIC (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe8309c [0.00] ACPI: TCPA (v001 DELLM07 0x27d60a0d ASL 0x0061) @ 0x7fe83300 [0.00]ERROR: Invalid checksum [0.00] ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20050624) @ 0x7fe81a11 [0.00] ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 INTL 0x20050624) @ 0x The 'invalid checksum' message goes away if you enable the TPM. Note that this one happens even if you don't have TPM support enabled in the kernel. The code in drivers/acpi/tables.c isn't incredibly verbose about what the exact problem is - I'm willing to add instrumentation if somebody can tell me what would be actually useful to dump out. Folly 2: when userspace gets around to doing a 'modprobe tpm_tis', we get the following complaint: [ 76.318668] tpm_tis 00:0d: 1.2 TPM (device-id 0x1001, rev-id 2) [ 76.378236] IRQ handler type mismatch for IRQ 8 [ 76.378239] current handler: rtc [ 76.378240] [ 76.378241] Call Trace: [ 76.378255] [80266d56] dump_trace+0xb9/0x3b3 [ 76.378261] [8026708c] show_trace+0x3c/0x52 [ 76.378265] [802670b7] dump_stack+0x15/0x17 [ 76.378270] [802a3839] setup_irq+0x1c2/0x1e6 [ 76.378275] [802a38fb] request_irq+0x9e/0xc7 [ 76.378282] [885f58c5] :tpm_tis:tpm_tis_init+0x205/0x44c [ 76.378290] [885f5b3a] :tpm_tis:tpm_tis_pnp_init+0x2e/0x30 [ 76.378296] [80392838] pnp_device_probe+0x7b/0xa0 [ 76.378302] [803b4813] driver_probe_device+0xbc/0x138 [ 76.378307] [803b497a] __driver_attach+0x5b/0x94 [ 76.378312] [803b3cdd] bus_for_each_dev+0x49/0x7a [ 76.378316] [803b4666] driver_attach+0x1c/0x1e [ 76.378320] [803b4011] bus_add_driver+0x75/0x199 [ 76.378324] [803b4c8a] driver_register+0x85/0x89 [ 76.378328] [80392521] pnp_register_driver+0x1c/0x1e [ 76.378333] [8800f081] :tpm_tis:init_tis+0x81/0x89 [ 76.378339] [80295e62] sys_init_module+0xac/0x17d [ 76.378345] [8025a11e] system_call+0x7e/0x83 [ 76.378352] [0039d1acd90a] [ 76.378354] [ 76.378355] tpm_tis 00:0d: Unable to request irq: 8 for probe (2.6.19-rc6-mm2 would repeat the complaint on IRQ 14 and then 15 as well) /proc/interrupts says: CPU0 CPU1 0:1577201 0 IO-APIC-edge timer 1: 4851 0 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 9: 2 0 IO-APIC-fasteoi acpi 12:145 0 IO-APIC-edge i8042 14: 13647 40481 IO-APIC-edge libata 15: 59 7876 IO-APIC-edge libata 16: 64047 0 IO-APIC-fasteoi nvidia 17: 0 0 IO-APIC-fasteoi ipw3945 19: 10 0 IO-APIC-fasteoi yenta, ohci1394 20: 28 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 5303 0 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel 22: 29 4701 IO-APIC-fasteoi uhci_hcd:usb4 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb5 NMI: 0 0 LOC:15770871577049 ERR: 0 Any ideas/suggestions? pgpP8C6vfTIja.pgp Description: PGP signature
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Rafael J. Wysocki wrote: Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). [ 310.457548] eax: ebx: ecx: edx: [ 310.457623] esi: edi: c18fe500 ebp: f7b3fe3c esp: f7b3fe08 [ 310.457696] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 310.457772] Process swsusp (pid: 3243, ti=f7b3e000 task=f756f030 task.ti=f7b3e000) [ 310.457845] Stack: c175d8a0 c175daa0 c175db00 c053cec0 45ec 00d0 [ 310.458286] 1179 1179 f7b3fe94 c0151445 0001 [ 310.458723]f7b3fe64 1df1 0002 0001 0001 00038000 0c79 117b [ 310.459199] Call Trace: [ 310.459334] [c0103f1b] show_trace_log_lvl+0x1a/0x30 [ 310.459450] [c0103fd6] show_stack_log_lvl+0xa5/0xca [ 310.459562] [c01041ce] show_registers+0x1d3/0x2b8 [ 310.459673] [c01043d4] die+0x121/0x243 [ 310.459781] [c010456c] do_trap+0x76/0x9c [ 310.459892] [c0104bd8] do_divide_error+0x94/0x9e [ 310.460001] [c038a7e4] error_code+0x7c/0x84 [ 310.460113] [c0151445] shrink_all_memory+0x211/0x2eb [ 310.460225] [c01418c1] swsusp_shrink_memory+0x187/0x196 [ 310.460335] [c0141a07] prepare_processes+0x35/0xc8 [ 310.460446] [c0141cce] pm_suspend_disk+0xd/0x16f [ 310.460558] [c0140c87] enter_state+0x129/0x19b [ 310.460668] [c0140d9c] state_store+0xa3/0xac [ 310.460777] [c0198ab0] subsys_attr_store+0x20/0x25 [ 310.460889] [c0198b9f] sysfs_write_file+0x97/0xd8 [ 310.460998] [c0165262] vfs_write+0x8b/0x149 [ 310.461108] [c01658cb] sys_write+0x3d/0x64 [ 310.461216] [c0102fe4] syscall_call+0x7/0xb [ 310.461328] === [ 310.461397] Code: 31 c0 ff 17 89 c3 8b 45 e4 31 d2 f7 77 0c f7 e3 89 45 d8 89 55 dc 89 d1 89 c6 31 d2 85 c9 74 09 89 c8 31 d2 f7 75 f0 89 c1 89 f0 f7 75 f0 89 ca 89 45 d8 89 55 dc 8b 45 d8 03 47 10 89 47 10 85 [ 310.464079] EIP: [c0150c9a] shrink_slab+0x9e/0x169 SS:ESP 0068:f7b3fe08 [ 310.464228] swsusp script is something like this: echo platform /sys/power/disk echo disk /sys/power/state regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. * Laurent Riffard [EMAIL PROTECTED] [2006-12-18 09:03]: fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit. Reverting it fix those reiser4 panics for me. Damien, could you confirm please ? Yes, this fixes it too on my side. Thanks for this tracking ! -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
Miles Lane wrote: Sorry, I am not finding who maintains highmem. Please forward. WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic() [c0103c25] dump_trace+0x68/0x1d2 [c0103da7] show_trace_log_lvl+0x18/0x2c [c0104410] show_trace+0xf/0x11 [c010449b] dump_stack+0x12/0x14 [c01144d9] kmap_atomic+0x6f/0x1ca [f930e25d] ntfs_end_buffer_async_read+0x25d/0x2ca [ntfs] [c017c294] end_bio_bh_io_sync+0x2c/0x37 [c017dc29] bio_endio+0x5a/0x62 [c01c8412] __end_that_request_first+0x145/0x3ab [c0237695] ide_end_request+0x80/0xd8 [c023e3f0] ide_dma_intr+0x55/0x9a [c02388dc] ide_intr+0x182/0x1f2 [c0140775] handle_IRQ_event+0x1a/0x3f [c0141baa] handle_edge_irq+0xc6/0x11c [c0105416] do_IRQ+0x57/0x71 [c010366b] common_interrupt+0x23/0x28 [f8826ee4] acpi_processor_idle+0x1cc/0x36c [processor] [c010132b] cpu_idle+0x3e/0x6c [c03f06d9] start_kernel+0x2fa/0x2fe === Reported yet, you might see it here: http://lkml.org/lkml/2006/12/15/222 regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1 -- WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic()
On 12/18/06, Jiri Slaby [EMAIL PROTECTED] wrote: Miles Lane wrote: Sorry, I am not finding who maintains highmem. Please forward. WARNING (1) at arch/i386/mm/highmem.c:41 kmap_atomic() [c0103c25] dump_trace+0x68/0x1d2 [c0103da7] show_trace_log_lvl+0x18/0x2c [c0104410] show_trace+0xf/0x11 [c010449b] dump_stack+0x12/0x14 [c01144d9] kmap_atomic+0x6f/0x1ca [f930e25d] ntfs_end_buffer_async_read+0x25d/0x2ca [ntfs] [c017c294] end_bio_bh_io_sync+0x2c/0x37 [c017dc29] bio_endio+0x5a/0x62 [c01c8412] __end_that_request_first+0x145/0x3ab [c0237695] ide_end_request+0x80/0xd8 [c023e3f0] ide_dma_intr+0x55/0x9a [c02388dc] ide_intr+0x182/0x1f2 [c0140775] handle_IRQ_event+0x1a/0x3f [c0141baa] handle_edge_irq+0xc6/0x11c [c0105416] do_IRQ+0x57/0x71 [c010366b] common_interrupt+0x23/0x28 [f8826ee4] acpi_processor_idle+0x1cc/0x36c [processor] [c010132b] cpu_idle+0x3e/0x6c [c03f06d9] start_kernel+0x2fa/0x2fe === Reported yet, you might see it here: http://lkml.org/lkml/2006/12/15/222 It is certainly very similar, and probably has the same root cause. Though, the trace isn't an exact match. So, who should look into this? Thanks, Miles - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On 12/15/06, Andrew Morton [EMAIL PROTECTED] wrote: +toshiba-tc86c001-ide-driver-take-2.patch Acked-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] IMO this can be merged for 2.6.20 as it is new driver (which is clean, tested and acked by Alan already) All 693 patches: hpt3xx-rework-rate-filtering.patch HPT3xx: rework rate filtering ACK hpt3xx-rework-rate-filtering-tidy.patch hpt3xx-rework-rate-filtering-tidy ACK hpt3xx-print-the-real-chip-name-at-startup.patch HPT3xx: print the real chip name at startup ACK hpt3xx-switch-to-using-pci_get_slot.patch HPT3xx: switch to using pci_get_slot() ACK hpt3xx-cache-channels-mcr-address.patch [PATCH] HPT3xx: cache channel's MCR address ACK hpt3x7-merge-speedproc-handlers.patch HPT3x7: merge speedproc handlers ACK hpt370-clean-up-dma-timeout-handling.patch HPT370: clean up DMA timeout handling ACK hpt3xx-init-code-rewrite.patch HPT3xx: init code rewrite ACK piix-fix-82371mx-enablebits.patch PIIX: fix 82371MX enablebits ACK, thought I haven't compared wrt datasheet yet piix-remove-check-for-broken-mw-dma-mode-0.patch PIIX: remove check for broken MW DMA mode 0 ACK, 100% correct and non-intrusive cleanup piix-slc90e66-pio-mode-fallback-fix.patch PIIX/SLC90E66: PIO mode fallback fix ACK, this is an important bugfix pdc202xx_new-remove-useless-code.patch pdc202xx_new: remove useless code ACK, nice cleanup pdc202xx_-remove-check_in_drive_lists-abomination.patch pdc202xx_*: remove check_in_drive_lists() abomination ACK, ditto I think that all above patches from Sergei should be merged now as they are either bugfixes or not-intrusive cleanups and got more than enough exposure in -mm (since 2.6.17-mm). jmicron-warning-fix.patch Wouldn't it be neater to add BUG() instead? Seems to fix warning for me and documents nicely that this case cannot happen. Thanks, Bart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006 18:02:20 +0100
Jiri Slaby [EMAIL PROTECTED] wrote:
Rafael J. Wysocki wrote:
Hi,
On Monday, 18 December 2006 12:20, Jiri Slaby wrote:
Hi.
I got this oops while suspending:
[ 309.366557] Disabling non-boot CPUs ...
[ 309.386563] CPU 1 is now offline
[ 309.387625] CPU1 is down
[ 309.387704] Stopping tasks ... done.
[ 310.030991] Shrinking memory... -0divide error: [#1]
[ 310.456669] SMP
[ 310.456814] last sysfs file:
/devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions
[ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394
cdrom
[ 310.457259] CPU:0
[ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI
[ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207)
[ 310.457478] EIP is at shrink_slab+0x9e/0x169
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
Sure, but not till Friday, sorry (I am away).
I think there's only one divide in there which can do this, so...
--- a/mm/vmscan.c~shrink_slab-handle-bad-shrinkers
+++ a/mm/vmscan.c
@@ -20,6 +20,7 @@
#include linux/pagemap.h
#include linux/init.h
#include linux/highmem.h
+#include linux/kallsyms.h
#include linux/vmstat.h
#include linux/file.h
#include linux/writeback.h
@@ -190,7 +191,13 @@ unsigned long shrink_slab(unsigned long
unsigned long total_scan;
unsigned long max_pass = (*shrinker-shrinker)(0, gfp_mask);
- delta = (4 * scanned) / shrinker-seeks;
+ if (!shrinker-seeks) {
+ print_symbol(shrinker %s has zero seeks\n,
+ (unsigned long)shrinker-shrinker);
+ delta = (4 * scanned) / DEFAULT_SEEKS;
+ } else {
+ delta = (4 * scanned) / shrinker-seeks;
+ }
delta *= max_pass;
do_div(delta, lru_pages + 1);
shrinker-nr += delta;
_
A quick grep shows that all set_shrinker() callers are doing the right
thing, so something kooky has happened.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Monday, 18 December 2006 18:02, Jiri Slaby wrote: Rafael J. Wysocki wrote: Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). I reproduced this on one box, but then it turned out that EIP was at line 195 of mm/vmscan.c where there was do_div(delta, lru_pages + 1); Well, I have no idea how this can lead to a divide error (lru_pages is unsigned). I'm unable to reproduce this on another i386 box, so it seems to be somewhat configuration specific. Does 2.6.20-rc1 work for you? Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi. On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote: On Monday, 18 December 2006 18:02, Jiri Slaby wrote: Rafael J. Wysocki wrote: Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). I reproduced this on one box, but then it turned out that EIP was at line 195 of mm/vmscan.c where there was do_div(delta, lru_pages + 1); Well, I have no idea how this can lead to a divide error (lru_pages is unsigned). I'm unable to reproduce this on another i386 box, so it seems to be somewhat configuration specific. Does 2.6.20-rc1 work for you? I have a patch in -mm that reduces lru_pages by what shrink_all_zones returns. Could shrink_all_zones perhaps be returning incorrect values such that lru_pages ends up becoming -1? Regards, Nigel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi, On Monday, 18 December 2006 23:44, Nigel Cunningham wrote: Hi. On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote: On Monday, 18 December 2006 18:02, Jiri Slaby wrote: Rafael J. Wysocki wrote: Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). I reproduced this on one box, but then it turned out that EIP was at line 195 of mm/vmscan.c where there was do_div(delta, lru_pages + 1); Well, I have no idea how this can lead to a divide error (lru_pages is unsigned). I'm unable to reproduce this on another i386 box, so it seems to be somewhat configuration specific. Does 2.6.20-rc1 work for you? I have a patch in -mm that reduces lru_pages by what shrink_all_zones returns. Could shrink_all_zones perhaps be returning incorrect values such that lru_pages ends up becoming -1? I don't think so, but look at the appended patch. ;-) Greetings, Rafael --- Fix a (really bad) typo in shrink_all_memory(). Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] --- mm/vmscan.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.20-rc1-mm1/mm/vmscan.c === --- linux-2.6.20-rc1-mm1.orig/mm/vmscan.c +++ linux-2.6.20-rc1-mm1/mm/vmscan.c @@ -1569,7 +1569,7 @@ unsigned long shrink_all_memory(unsigned sc.swap_cluster_max = nr_pages - ret; freed = shrink_all_zones(nr_to_scan, prio, pass, sc); ret += freed; - lru_pages =- freed; + lru_pages -= freed; nr_to_scan = nr_pages - ret; if (ret = nr_pages) goto out; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
Hi. On Tue, 2006-12-19 at 00:09 +0100, Rafael J. Wysocki wrote: Hi, On Monday, 18 December 2006 23:44, Nigel Cunningham wrote: Hi. On Mon, 2006-12-18 at 23:38 +0100, Rafael J. Wysocki wrote: On Monday, 18 December 2006 18:02, Jiri Slaby wrote: Rafael J. Wysocki wrote: Hi, On Monday, 18 December 2006 12:20, Jiri Slaby wrote: Hi. I got this oops while suspending: [ 309.366557] Disabling non-boot CPUs ... [ 309.386563] CPU 1 is now offline [ 309.387625] CPU1 is down [ 309.387704] Stopping tasks ... done. [ 310.030991] Shrinking memory... -0divide error: [#1] [ 310.456669] SMP [ 310.456814] last sysfs file: /devices/pci:00/:00:1e.0/:02:08.0/eth0/statistics/collisions [ 310.456919] Modules linked in: eth1394 floppy ohci1394 ide_cd ieee1394 cdrom [ 310.457259] CPU:0 [ 310.457260] EIP:0060:[c0150c9a]Not tainted VLI [ 310.457261] EFLAGS: 00210246 (2.6.20-rc1-mm1 #207) [ 310.457478] EIP is at shrink_slab+0x9e/0x169 Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). I reproduced this on one box, but then it turned out that EIP was at line 195 of mm/vmscan.c where there was do_div(delta, lru_pages + 1); Well, I have no idea how this can lead to a divide error (lru_pages is unsigned). I'm unable to reproduce this on another i386 box, so it seems to be somewhat configuration specific. Does 2.6.20-rc1 work for you? I have a patch in -mm that reduces lru_pages by what shrink_all_zones returns. Could shrink_all_zones perhaps be returning incorrect values such that lru_pages ends up becoming -1? I don't think so, but look at the appended patch. ;-) Greetings, Rafael --- Fix a (really bad) typo in shrink_all_memory(). Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] --- mm/vmscan.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.20-rc1-mm1/mm/vmscan.c === --- linux-2.6.20-rc1-mm1.orig/mm/vmscan.c +++ linux-2.6.20-rc1-mm1/mm/vmscan.c @@ -1569,7 +1569,7 @@ unsigned long shrink_all_memory(unsigned sc.swap_cluster_max = nr_pages - ret; freed = shrink_all_zones(nr_to_scan, prio, pass, sc); ret += freed; - lru_pages =- freed; + lru_pages -= freed; nr_to_scan = nr_pages - ret; if (ret = nr_pages) goto out; Heh, yeah. Definitely acked! :) Nigel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006 23:38:23 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Looks like we have a problem with slab shrinking here.
Could you please use gdb to check what exactly is at shrink_slab+0x9e?
Sure, but not till Friday, sorry (I am away).
I reproduced this on one box, but then it turned out that EIP was at line 195
of mm/vmscan.c where there was
do_div(delta, lru_pages + 1);
That implies that we passed it lru_pages=-1.
Presumably the logic in
vmscanc-account-for-memory-already-freed-in-seeking-to.patch caused that.
Well, I have no idea how this can lead to a divide error (lru_pages is
unsigned).
I'm unable to reproduce this on another i386 box, so it seems to be somewhat
configuration specific.
There is one wart in shrink_all_memory() and I think we should fix that in
2.6.20.
Please check the below. I'll drop
vmscanc-account-for-memory-already-freed-in-seeking-to.patch. It has other
stuff in it which we might still need. But altering sc-swap_cluster_max
in that manner looks odd.
From: Andrew Morton [EMAIL PROTECTED]
At the end of shrink_all_memory() we forget to recalculate lru_pages: it can
be zero.
Fix that up, and add a helper function for this operation too.
Also, recalculate lru_pages each time around the inner loop to get the
balancing correct.
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
mm/vmscan.c | 33 -
1 files changed, 16 insertions(+), 17 deletions(-)
diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
--- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
+++ a/mm/vmscan.c
@@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
return ret;
}
+static unsigned long count_lru_pages(void)
+{
+ struct zone *zone;
+ unsigned long ret = 0;
+
+ for_each_zone(zone);
+ ret += zone-nr_active + zone-nr_inactive;
+ return ret;
+}
+
/*
* Try to free `nr_pages' of memory, system-wide, and return the number of
* freed pages.
@@ -1498,7 +1508,6 @@ unsigned long shrink_all_memory(unsigned
unsigned long ret = 0;
int pass;
struct reclaim_state reclaim_state;
- struct zone *zone;
struct scan_control sc = {
.gfp_mask = GFP_KERNEL,
.may_swap = 0,
@@ -1509,10 +1518,7 @@ unsigned long shrink_all_memory(unsigned
current-reclaim_state = reclaim_state;
- lru_pages = 0;
- for_each_zone(zone)
- lru_pages += zone-nr_active + zone-nr_inactive;
-
+ lru_pages = count_lru_pages();
nr_slab = global_page_state(NR_SLAB_RECLAIMABLE);
/* If slab caches are huge, it's better to hit them first */
while (nr_slab = lru_pages) {
@@ -1539,13 +1545,6 @@ unsigned long shrink_all_memory(unsigned
for (pass = 0; pass 5; pass++) {
int prio;
- /* Needed for shrinking slab caches later on */
- if (!lru_pages)
- for_each_zone(zone) {
- lru_pages += zone-nr_active;
- lru_pages += zone-nr_inactive;
- }
-
/* Force reclaiming mapped pages in the passes #3 and #4 */
if (pass 2) {
sc.may_swap = 1;
@@ -1561,7 +1560,8 @@ unsigned long shrink_all_memory(unsigned
goto out;
reclaim_state.reclaimed_slab = 0;
- shrink_slab(sc.nr_scanned, sc.gfp_mask, lru_pages);
+ shrink_slab(sc.nr_scanned, sc.gfp_mask,
+ count_lru_pages());
ret += reclaim_state.reclaimed_slab;
if (ret = nr_pages)
goto out;
@@ -1569,20 +1569,19 @@ unsigned long shrink_all_memory(unsigned
if (sc.nr_scanned prio DEF_PRIORITY - 2)
congestion_wait(WRITE, HZ / 10);
}
-
- lru_pages = 0;
}
/*
* If ret = 0, we could not shrink LRUs, but there may be something
* in slab caches
*/
- if (!ret)
+ if (!ret) {
do {
reclaim_state.reclaimed_slab = 0;
- shrink_slab(nr_pages, sc.gfp_mask, lru_pages);
+ shrink_slab(nr_pages, sc.gfp_mask, count_lru_pages());
ret += reclaim_state.reclaimed_slab;
} while (ret nr_pages reclaim_state.reclaimed_slab 0);
+ }
out:
current-reclaim_state = NULL;
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote: Got this on booting up on x86_64 test box. Didn't happen on next boot. BUG: scheduling while atomic: hald-addon-stor/0x2000/3300 Call Trace: [8020ac30] show_trace+0x34/0x47 [8020ac55] dump_stack+0x12/0x17 [8050c2dd] __sched_text_start+0x5d/0x7ba [8022b3f0] __cond_resched+0x1c/0x44 [8050cb4d] cond_resched+0x29/0x30 [8050e7aa] __reacquire_kernel_lock+0x26/0x44 [8050cae6] thread_return+0xac/0xea [8022b3f0] __cond_resched+0x1c/0x44 [8050cb4d] cond_resched+0x29/0x30 [8050cb83] wait_for_completion+0x17/0xd2 [80337a19] blk_execute_rq+0x98/0xb8 [80413e7b] scsi_execute+0xd4/0xf1 [80413f51] scsi_execute_req+0xb9/0xde [80413faf] scsi_test_unit_ready+0x39/0x75 [804443cd] sd_media_changed+0x40/0x87 [8029cde0] check_disk_change+0x1f/0x76 [8044417e] sd_open+0x80/0x113 [8029d4c4] do_open+0x9f/0x2a7 [8029d8bc] blkdev_open+0x2e/0x5d [8027afeb] __dentry_open+0xd9/0x1a7 [8027b16a] do_filp_open+0x2a/0x38 [8027b1bc] do_sys_open+0x44/0xc8 [8020956e] system_call+0x7e/0x83 [2b6c5bb34580] --- ~Randy kconfig: http://oss.oracle.com/~rdunlap/configs/config-2620-rc1mm1 full log: http://oss.oracle.com/~rdunlap/logs/2620-rc1mm1.out - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On Mon, 18 Dec 2006 16:29:02 -0800 Randy Dunlap [EMAIL PROTECTED] wrote: On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote: Got this on booting up on x86_64 test box. Didn't happen on next boot. BUG: scheduling while atomic: hald-addon-stor/0x2000/3300 Call Trace: [8020ac30] show_trace+0x34/0x47 [8020ac55] dump_stack+0x12/0x17 [8050c2dd] __sched_text_start+0x5d/0x7ba [8022b3f0] __cond_resched+0x1c/0x44 [8050cb4d] cond_resched+0x29/0x30 [8050e7aa] __reacquire_kernel_lock+0x26/0x44 [8050cae6] thread_return+0xac/0xea [8022b3f0] __cond_resched+0x1c/0x44 [8050cb4d] cond_resched+0x29/0x30 [8050cb83] wait_for_completion+0x17/0xd2 [80337a19] blk_execute_rq+0x98/0xb8 [80413e7b] scsi_execute+0xd4/0xf1 [80413f51] scsi_execute_req+0xb9/0xde [80413faf] scsi_test_unit_ready+0x39/0x75 [804443cd] sd_media_changed+0x40/0x87 [8029cde0] check_disk_change+0x1f/0x76 [8044417e] sd_open+0x80/0x113 [8029d4c4] do_open+0x9f/0x2a7 [8029d8bc] blkdev_open+0x2e/0x5d [8027afeb] __dentry_open+0xd9/0x1a7 [8027b16a] do_filp_open+0x2a/0x38 [8027b1bc] do_sys_open+0x44/0xc8 [8020956e] system_call+0x7e/0x83 Bit 29 of current-preempt_count got set. I don't think there's any way in which that can happen normally. So probably some hardware or software error reached out and flipped that bit. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Tuesday, 19 December 2006 00:17, Andrew Morton wrote: On Mon, 18 Dec 2006 23:38:23 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: Looks like we have a problem with slab shrinking here. Could you please use gdb to check what exactly is at shrink_slab+0x9e? Sure, but not till Friday, sorry (I am away). I reproduced this on one box, but then it turned out that EIP was at line 195 of mm/vmscan.c where there was do_div(delta, lru_pages + 1); That implies that we passed it lru_pages=-1. Presumably the logic in vmscanc-account-for-memory-already-freed-in-seeking-to.patch caused that. Well, I have no idea how this can lead to a divide error (lru_pages is unsigned). I'm unable to reproduce this on another i386 box, so it seems to be somewhat configuration specific. There is one wart in shrink_all_memory() and I think we should fix that in 2.6.20. Please check the below. Fine by me. I'll drop vmscanc-account-for-memory-already-freed-in-seeking-to.patch. It has other stuff in it which we might still need. But altering sc-swap_cluster_max in that manner looks odd. Agreed. Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006, Andrew Morton wrote:
diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
--- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
+++ a/mm/vmscan.c
@@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
return ret;
}
+static unsigned long count_lru_pages(void)
+{
+ struct zone *zone;
+ unsigned long ret = 0;
+
+ for_each_zone(zone);
+ ret += zone-nr_active + zone-nr_inactive;
+ return ret;
+}
+
/*
* Try to free `nr_pages' of memory, system-wide, and return the number of
* freed pages.
There's an extra semicolon there that results in only the final zone being
used.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] OOPS: divide error while s2dsk (2.6.20-rc1-mm1)
On Mon, 18 Dec 2006 17:18:12 -0800 (PST)
David Rientjes [EMAIL PROTECTED] wrote:
On Mon, 18 Dec 2006, Andrew Morton wrote:
diff -puN mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling mm/vmscan.c
--- a/mm/vmscan.c~shrink_all_memory-fix-lru_pages-handling
+++ a/mm/vmscan.c
@@ -1484,6 +1484,16 @@ static unsigned long shrink_all_zones(un
return ret;
}
+static unsigned long count_lru_pages(void)
+{
+ struct zone *zone;
+ unsigned long ret = 0;
+
+ for_each_zone(zone);
+ ret += zone-nr_active + zone-nr_inactive;
+ return ret;
+}
+
/*
* Try to free `nr_pages' of memory, system-wide, and return the number of
* freed pages.
There's an extra semicolon there
Sigh. coding-while-diseased.
that results in only the final zone being
used.
Actually it'll go oops. Fixed, thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On Fri, Dec 15 2006, Andrew Morton wrote: > On Fri, 15 Dec 2006 21:39:36 +0100 > Damien Wyart <[EMAIL PROTECTED]> wrote: > > > With this new kernel, I notice two messages I do not have with > > 2.6.19-rc6-mm2 : > > > > Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling > > barriers,trial barrier write failed > > Dec 15 20:00:47 brouette kernel: Filesystem "sda5": Disabling > > barriers,trial barrier write failed > > > > Nothing changed in the config between the two, and going back to > > 2.6.19-rc6-mm2 do not give the messages. > > I don't think anything has changed in this area in XFS. I'd expect that > something got broken in sata, ata_piix or the block core which caused the > "trial barrier write" to start failing. Various cc's hopefully added. There hasn't been any barrier changes lately (or block layer handling of such), so I don't think it's in that area. I'll do some barrier testing today to verify that things work for me. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
> > Also, I got panics when unmounting reiser4 filesystems with > > 2.6.20-rc1-mm1 but I guess this is related to your waring about > > reiser4 being broken in 2.6.19-mm1 (even if it is not listed in > > notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the > > reiser4 panics did not get logged and I am not able to reboot on > > 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report > > the xfs messages which seems a bit suspect. > The reiser4 failure is unexpected. Could you please see if you can > capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. -- Damien Wyart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
Also, I got panics when unmounting reiser4 filesystems with 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 being broken in 2.6.19-mm1 (even if it is not listed in notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report the xfs messages which seems a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. -- Damien Wyart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc1-mm1
On Fri, Dec 15 2006, Andrew Morton wrote: On Fri, 15 Dec 2006 21:39:36 +0100 Damien Wyart [EMAIL PROTECTED] wrote: With this new kernel, I notice two messages I do not have with 2.6.19-rc6-mm2 : Dec 15 20:00:47 brouette kernel: Filesystem sdb9: Disabling barriers,trial barrier write failed Dec 15 20:00:47 brouette kernel: Filesystem sda5: Disabling barriers,trial barrier write failed Nothing changed in the config between the two, and going back to 2.6.19-rc6-mm2 do not give the messages. I don't think anything has changed in this area in XFS. I'd expect that something got broken in sata, ata_piix or the block core which caused the trial barrier write to start failing. Various cc's hopefully added. There hasn't been any barrier changes lately (or block layer handling of such), so I don't think it's in that area. I'll do some barrier testing today to verify that things work for me. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
On Sat, 16 Dec 2006 10:38:53 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote: > > > By this, we'll not access mem_section[] in usual ops. > > Why do we need mem_section? We have a page table that fulfills the same > role. > Basically, we don't need it. But I use mem_section[] in bootstrap and I want to keep patches small in this time. I think it's not too late that we'll consider removing it after implementing memory hot unplug.(and confirm we never use it.) -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote: > By this, we'll not access mem_section[] in usual ops. Why do we need mem_section? We have a page table that fulfills the same role. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Cross) compiling fails on first try (was Re: 2.6.20-rc1-mm1)
Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc, sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs. 2.6.20-rc1 is also affected. # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um defconfig # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um GEN /tmp/tmp.abUIc11429/out/um/Makefile scripts/kconfig/conf -s arch/um/Kconfig MKDIR /tmp/tmp.abUIc11429/out/um/arch/um/include SYMLINK arch/um/include/kern_constants.h SYMLINK include/asm-um/arch SYMLINK arch/um/include/sysdep SYMLINK arch/um/os SYMLINK include/asm-um/archparam.h SYMLINK include/asm-um/system.h SYMLINK include/asm-um/sigcontext.h SYMLINK include/asm-um/processor.h SYMLINK include/asm-um/ptrace.h SYMLINK include/asm-um/module.h SYMLINK include/asm-um/vm-flags.h SYMLINK include/asm-um/elf.h SYMLINK include/asm-um/host_ldt.h CHK arch/um/include/uml-config.h UPD arch/um/include/uml-config.h CC arch/um/sys-x86_64/user-offsets.s CHK arch/um/include/user_constants.h UPD arch/um/include/user_constants.h Using /tmp/x as source for kernel GEN /tmp/tmp.abUIc11429/out/um/Makefile CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/compile.h UPD include/linux/compile.h CHK include/linux/utsrelease.h "2.6.20-rc1-mm1cat:include/config/kernel.release:Nosuchfileordirectory" exceeds 64 characters make[1]: *** [include/linux/utsrelease.h] Error 1 make: *** [_all] Error 2 # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um SYMLINK arch/um/include/kern_constants.h SYMLINK arch/um/include/sysdep make[2]: `arch/um/sys-x86_64/user-offsets.s' is up to date. Using /tmp/x as source for kernel GEN /tmp/tmp.abUIc11429/out/um/Makefile CHK include/linux/version.h CHK include/linux/compile.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm -> include/asm-um CC arch/um/kernel/asm-offsets.s GEN include/asm-um/asm-offsets.h CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/bin2c CC init/main.o CC init/version.o CC init/do_mounts.o LD init/mounts.o CC init/noinitramfs.o Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [2/2] for ia64
ia64 support for sparsemem vmem_map optimize pfn_valid() patch. Because ia64 has its own virtual mem_map, we can reuse the same code. So this patch is simple. To support optimized pfn_valid() in other arch, you (may) have to modify fault handler in kernel address space. Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> arch/ia64/Kconfig|4 arch/ia64/mm/fault.c |4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) Index: devel-2.6.20-rc1-mm1/arch/ia64/Kconfig === --- devel-2.6.20-rc1-mm1.orig/arch/ia64/Kconfig 2006-12-16 14:42:57.0 +0900 +++ devel-2.6.20-rc1-mm1/arch/ia64/Kconfig 2006-12-16 14:43:14.0 +0900 @@ -353,6 +353,10 @@ def_bool y depends on SPARSEMEM_VMEMMAP +config ARCH_SPARSEMEM_VMEMMAP_OPT_PFN_VALID + def_bool y + depends on SPARSEMEM_VMEMMAP + config ARCH_DISCONTIGMEM_DEFAULT def_bool y if (IA64_SGI_SN2 || IA64_GENERIC || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB) depends on ARCH_DISCONTIGMEM_ENABLE Index: devel-2.6.20-rc1-mm1/arch/ia64/mm/fault.c === --- devel-2.6.20-rc1-mm1.orig/arch/ia64/mm/fault.c 2006-12-16 14:42:57.0 +0900 +++ devel-2.6.20-rc1-mm1/arch/ia64/mm/fault.c 2006-12-16 14:43:40.0 +0900 @@ -103,7 +103,7 @@ if (in_atomic() || !mm) goto no_context; -#ifdef CONFIG_VIRTUAL_MEM_MAP +#if defined(CONFIG_VIRTUAL_MEM_MAP) || defined(CONFIG_SPARSEMEM_VMEMMAP_OPT_PFNVALID) /* * If fault is in region 5 and we are in the kernel, we may already * have the mmap_sem (pfn_valid macro is called during mmap). There @@ -211,7 +211,7 @@ bad_area: up_read(>mmap_sem); -#ifdef CONFIG_VIRTUAL_MEM_MAP +#if defined(CONFIG_VIRTUAL_MEM_MAP) || defined(CONFIG_SPARSEMEM_VMEMMAP_OPT_PFNVALID) bad_area_no_up: #endif if ((isr & IA64_ISR_SP) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [1/2] generic arch.
This patch is for implementing optimized pfn_valid() for sparsemem_vmemmap.
By this, we can avoid accessing mem_section[] in usual codes.
(memory hotplug will access it.)
This patch checks vmem_map is mapped or not by get_user().
If fault, pfn is not valid.
Because sparsemem_vmemmap's virtual mem_map per section is always aligned to
PAGE_SIZE, pfn_valid(pfn) can assume a whole struct page is fully mapped.
So it only access the first byte.
How to use:
1. set ARCH_SPARSEMEM_VMEMMAP_OPT_PFNVALID config in arch/Kconfig
2. modify page fault handler in each arch to handle fault in mem_map range.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
include/linux/mmzone.h | 10 ++
mm/Kconfig |4
mm/sparse.c|7 +++
3 files changed, 21 insertions(+)
Index: devel-2.6.20-rc1-mm1/include/linux/mmzone.h
===
--- devel-2.6.20-rc1-mm1.orig/include/linux/mmzone.h2006-12-16
13:48:52.0 +0900
+++ devel-2.6.20-rc1-mm1/include/linux/mmzone.h 2006-12-16 14:43:08.0
+0900
@@ -752,12 +752,22 @@
return __nr_to_section(pfn_to_section_nr(pfn));
}
+#ifdef CONFIG_SPARSEMEM_VMEMMAP_OPT_PFNVALID
+extern int vmemmap_test_valid(struct page *pg);
+static inline int pfn_valid(unsigned long pfn)
+{
+ if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
+ return 0;
+ return vmemmap_test_valid(pfn_to_page(pfn));
+}
+#else
static inline int pfn_valid(unsigned long pfn)
{
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
}
+#endif
/*
* These are _only_ used during initialisation, therefore they
Index: devel-2.6.20-rc1-mm1/mm/Kconfig
===
--- devel-2.6.20-rc1-mm1.orig/mm/Kconfig2006-12-16 13:48:53.0
+0900
+++ devel-2.6.20-rc1-mm1/mm/Kconfig 2006-12-16 13:52:06.0 +0900
@@ -125,6 +125,10 @@
def_bool y
depends on ARCH_SPARSEMEM_VMEMMAP_STATIC
+config SPARSEMEM_VMEMMAP_OPT_PFNVALID
+ def_bool y
+ depends on SPARSEMEM_VMEMMAP && ARCH_SPARSEMEM_VMEMMAP_OPT_PFN_VALID
+
# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
Index: devel-2.6.20-rc1-mm1/mm/sparse.c
===========
--- devel-2.6.20-rc1-mm1.orig/mm/sparse.c 2006-12-16 13:48:53.000000000
+0900
+++ devel-2.6.20-rc1-mm1/mm/sparse.c2006-12-16 14:03:41.0 +0900
@@ -108,6 +108,13 @@
int nid;
};
+int vmemmap_test_valid(struct page *pg)
+{
+ char byte;
+ /* vmemmap per section is always aligned to PAGE_SIZE */
+ return (__get_user(byte, (char __user *)pg) == 0);
+}
+
/* call backs for memory map */
static int
__init pte_alloc_vmemmap_boot(pmd_t *pmd, unsigned long addr, void *data)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
This patch implements pfn_valid() micro optimization. This uses ia64_pfn_valid() idea to check mem_map is valid or not instead of sparsemem's logic. By this, we'll not access mem_section[] in usual ops. I attaches my easy test result with *micro* benchmark on SMP system. I'm glad if you give me an advice about testing. -Kame == AIM Independent Resource Benchmark - Suite IX "1.1" test on CPU: Itanium2(madison) 1.3GHz x2, SMP Memory: memory 8G 2.6.20-rc1-m1 / extreme means SPARSEMEM_VMEMMAP=n vmem_map means SPARSEMEM_VMEMMAP=y + optimze pfn_valid patch. == extreme vmem_map creat-clo 136322 136989 File Creations and Closes per second page_test 1042187 1076976 System Allocations & Pages per second brk_test2678559 2727286 System Memory Allocations per second signal_test 309525 321052 Signal Traps per second exec_test 803 801 Program Loads per second fork_test 93549679Task Creations per second disk_rr 103766 103970 Random Disk Reads (K) per second disk_rw 82978 80244 Random Disk Writes (K) per second disk_rd 802548 872983 Sequential Disk Reads (K) per second disk_wrt130342 131408 Sequential Disk Writes (K) per second disk_cp 107498 107823 Disk Copies (K) per second sync_disk_rw800 752 Sync Random Disk Writes (K) per second sync_disk_wrt 81 78 Sync Sequential Disk Writes (K) per second sync_disk_cp84 78 Sync Disk Copies (K) per second disk_src44417 44379 Directory Searches per second mem_rtns_1 3239352 3222140 Dynamic Memory Operations per second mem_rtns_2 1157321 1155260 Block Memory Operations per second misc_rtns_1 10799 10993 Auxiliary Loops per second dir_rtns_1 1276159 1373725 Directory Operations per second shell_rtns_1175 176 Shell Scripts per second shell_rtns_2174 175 Shell Scripts per second shell_rtns_3175 175 Shell Scripts per second shared_memory 646725 628769 Shared Memory Operations per second tcp_test93258 94928 TCP/IP Messages per second udp_test177984 177276 UDP/IP DataGrams per second fifo_test 362774 385434 FIFO Messages per second stream_pipe 320825 325931 Stream Pipe Messages per second dgram_pipe 300789 303339 DataGram Pipe Messages per second pipe_cpy410539 449521 Pipe Messages per second - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
This patch implements pfn_valid() micro optimization. This uses ia64_pfn_valid() idea to check mem_map is valid or not instead of sparsemem's logic. By this, we'll not access mem_section[] in usual ops. I attaches my easy test result with *micro* benchmark on SMP system. I'm glad if you give me an advice about testing. -Kame == AIM Independent Resource Benchmark - Suite IX 1.1 test on CPU: Itanium2(madison) 1.3GHz x2, SMP Memory: memory 8G 2.6.20-rc1-m1 / extreme means SPARSEMEM_VMEMMAP=n vmem_map means SPARSEMEM_VMEMMAP=y + optimze pfn_valid patch. == extreme vmem_map creat-clo 136322 136989 File Creations and Closes per second page_test 1042187 1076976 System Allocations Pages per second brk_test2678559 2727286 System Memory Allocations per second signal_test 309525 321052 Signal Traps per second exec_test 803 801 Program Loads per second fork_test 93549679Task Creations per second disk_rr 103766 103970 Random Disk Reads (K) per second disk_rw 82978 80244 Random Disk Writes (K) per second disk_rd 802548 872983 Sequential Disk Reads (K) per second disk_wrt130342 131408 Sequential Disk Writes (K) per second disk_cp 107498 107823 Disk Copies (K) per second sync_disk_rw800 752 Sync Random Disk Writes (K) per second sync_disk_wrt 81 78 Sync Sequential Disk Writes (K) per second sync_disk_cp84 78 Sync Disk Copies (K) per second disk_src44417 44379 Directory Searches per second mem_rtns_1 3239352 3222140 Dynamic Memory Operations per second mem_rtns_2 1157321 1155260 Block Memory Operations per second misc_rtns_1 10799 10993 Auxiliary Loops per second dir_rtns_1 1276159 1373725 Directory Operations per second shell_rtns_1175 176 Shell Scripts per second shell_rtns_2174 175 Shell Scripts per second shell_rtns_3175 175 Shell Scripts per second shared_memory 646725 628769 Shared Memory Operations per second tcp_test93258 94928 TCP/IP Messages per second udp_test177984 177276 UDP/IP DataGrams per second fifo_test 362774 385434 FIFO Messages per second stream_pipe 320825 325931 Stream Pipe Messages per second dgram_pipe 300789 303339 DataGram Pipe Messages per second pipe_cpy410539 449521 Pipe Messages per second - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [1/2] generic arch.
This patch is for implementing optimized pfn_valid() for sparsemem_vmemmap.
By this, we can avoid accessing mem_section[] in usual codes.
(memory hotplug will access it.)
This patch checks vmem_map is mapped or not by get_user().
If fault, pfn is not valid.
Because sparsemem_vmemmap's virtual mem_map per section is always aligned to
PAGE_SIZE, pfn_valid(pfn) can assume a whole struct page is fully mapped.
So it only access the first byte.
How to use:
1. set ARCH_SPARSEMEM_VMEMMAP_OPT_PFNVALID config in arch/Kconfig
2. modify page fault handler in each arch to handle fault in mem_map range.
Signed-Off-By: KAMEZAWA Hiroyuki [EMAIL PROTECTED]
include/linux/mmzone.h | 10 ++
mm/Kconfig |4
mm/sparse.c|7 +++
3 files changed, 21 insertions(+)
Index: devel-2.6.20-rc1-mm1/include/linux/mmzone.h
===
--- devel-2.6.20-rc1-mm1.orig/include/linux/mmzone.h2006-12-16
13:48:52.0 +0900
+++ devel-2.6.20-rc1-mm1/include/linux/mmzone.h 2006-12-16 14:43:08.0
+0900
@@ -752,12 +752,22 @@
return __nr_to_section(pfn_to_section_nr(pfn));
}
+#ifdef CONFIG_SPARSEMEM_VMEMMAP_OPT_PFNVALID
+extern int vmemmap_test_valid(struct page *pg);
+static inline int pfn_valid(unsigned long pfn)
+{
+ if (pfn_to_section_nr(pfn) = NR_MEM_SECTIONS)
+ return 0;
+ return vmemmap_test_valid(pfn_to_page(pfn));
+}
+#else
static inline int pfn_valid(unsigned long pfn)
{
if (pfn_to_section_nr(pfn) = NR_MEM_SECTIONS)
return 0;
return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
}
+#endif
/*
* These are _only_ used during initialisation, therefore they
Index: devel-2.6.20-rc1-mm1/mm/Kconfig
===
--- devel-2.6.20-rc1-mm1.orig/mm/Kconfig2006-12-16 13:48:53.0
+0900
+++ devel-2.6.20-rc1-mm1/mm/Kconfig 2006-12-16 13:52:06.0 +0900
@@ -125,6 +125,10 @@
def_bool y
depends on ARCH_SPARSEMEM_VMEMMAP_STATIC
+config SPARSEMEM_VMEMMAP_OPT_PFNVALID
+ def_bool y
+ depends on SPARSEMEM_VMEMMAP ARCH_SPARSEMEM_VMEMMAP_OPT_PFN_VALID
+
# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
bool Allow for memory hot-add
Index: devel-2.6.20-rc1-mm1/mm/sparse.c
===
--- devel-2.6.20-rc1-mm1.orig/mm/sparse.c 2006-12-16 13:48:53.0
+0900
+++ devel-2.6.20-rc1-mm1/mm/sparse.c2006-12-16 14:03:41.0 +0900
@@ -108,6 +108,13 @@
int nid;
};
+int vmemmap_test_valid(struct page *pg)
+{
+ char byte;
+ /* vmemmap per section is always aligned to PAGE_SIZE */
+ return (__get_user(byte, (char __user *)pg) == 0);
+}
+
/* call backs for memory map */
static int
__init pte_alloc_vmemmap_boot(pmd_t *pmd, unsigned long addr, void *data)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [2/2] for ia64
ia64 support for sparsemem vmem_map optimize pfn_valid() patch. Because ia64 has its own virtual mem_map, we can reuse the same code. So this patch is simple. To support optimized pfn_valid() in other arch, you (may) have to modify fault handler in kernel address space. Signed-Off-By: KAMEZAWA Hiroyuki [EMAIL PROTECTED] arch/ia64/Kconfig|4 arch/ia64/mm/fault.c |4 ++-- 2 files changed, 6 insertions(+), 2 deletions(-) Index: devel-2.6.20-rc1-mm1/arch/ia64/Kconfig === --- devel-2.6.20-rc1-mm1.orig/arch/ia64/Kconfig 2006-12-16 14:42:57.0 +0900 +++ devel-2.6.20-rc1-mm1/arch/ia64/Kconfig 2006-12-16 14:43:14.0 +0900 @@ -353,6 +353,10 @@ def_bool y depends on SPARSEMEM_VMEMMAP +config ARCH_SPARSEMEM_VMEMMAP_OPT_PFN_VALID + def_bool y + depends on SPARSEMEM_VMEMMAP + config ARCH_DISCONTIGMEM_DEFAULT def_bool y if (IA64_SGI_SN2 || IA64_GENERIC || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB) depends on ARCH_DISCONTIGMEM_ENABLE Index: devel-2.6.20-rc1-mm1/arch/ia64/mm/fault.c === --- devel-2.6.20-rc1-mm1.orig/arch/ia64/mm/fault.c 2006-12-16 14:42:57.0 +0900 +++ devel-2.6.20-rc1-mm1/arch/ia64/mm/fault.c 2006-12-16 14:43:40.0 +0900 @@ -103,7 +103,7 @@ if (in_atomic() || !mm) goto no_context; -#ifdef CONFIG_VIRTUAL_MEM_MAP +#if defined(CONFIG_VIRTUAL_MEM_MAP) || defined(CONFIG_SPARSEMEM_VMEMMAP_OPT_PFNVALID) /* * If fault is in region 5 and we are in the kernel, we may already * have the mmap_sem (pfn_valid macro is called during mmap). There @@ -211,7 +211,7 @@ bad_area: up_read(mm-mmap_sem); -#ifdef CONFIG_VIRTUAL_MEM_MAP +#if defined(CONFIG_VIRTUAL_MEM_MAP) || defined(CONFIG_SPARSEMEM_VMEMMAP_OPT_PFNVALID) bad_area_no_up: #endif if ((isr IA64_ISR_SP) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Cross) compiling fails on first try (was Re: 2.6.20-rc1-mm1)
Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc, sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs. 2.6.20-rc1 is also affected. # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um defconfig cut # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um GEN /tmp/tmp.abUIc11429/out/um/Makefile scripts/kconfig/conf -s arch/um/Kconfig MKDIR /tmp/tmp.abUIc11429/out/um/arch/um/include SYMLINK arch/um/include/kern_constants.h SYMLINK include/asm-um/arch SYMLINK arch/um/include/sysdep SYMLINK arch/um/os SYMLINK include/asm-um/archparam.h SYMLINK include/asm-um/system.h SYMLINK include/asm-um/sigcontext.h SYMLINK include/asm-um/processor.h SYMLINK include/asm-um/ptrace.h SYMLINK include/asm-um/module.h SYMLINK include/asm-um/vm-flags.h SYMLINK include/asm-um/elf.h SYMLINK include/asm-um/host_ldt.h CHK arch/um/include/uml-config.h UPD arch/um/include/uml-config.h CC arch/um/sys-x86_64/user-offsets.s CHK arch/um/include/user_constants.h UPD arch/um/include/user_constants.h Using /tmp/x as source for kernel GEN /tmp/tmp.abUIc11429/out/um/Makefile CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/compile.h UPD include/linux/compile.h CHK include/linux/utsrelease.h 2.6.20-rc1-mm1cat:include/config/kernel.release:Nosuchfileordirectory exceeds 64 characters make[1]: *** [include/linux/utsrelease.h] Error 1 make: *** [_all] Error 2 # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um SYMLINK arch/um/include/kern_constants.h SYMLINK arch/um/include/sysdep make[2]: `arch/um/sys-x86_64/user-offsets.s' is up to date. Using /tmp/x as source for kernel GEN /tmp/tmp.abUIc11429/out/um/Makefile CHK include/linux/version.h CHK include/linux/compile.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm - include/asm-um CC arch/um/kernel/asm-offsets.s GEN include/asm-um/asm-offsets.h CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/bin2c CC init/main.o CC init/version.o CC init/do_mounts.o LD init/mounts.o CC init/noinitramfs.o Thanks, Jan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote: By this, we'll not access mem_section[] in usual ops. Why do we need mem_section? We have a page table that fulfills the same role. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.20-rc1-mm1] sparsemem vmem_map optimzed pfn_valid() [0/2]
On Sat, 16 Dec 2006 10:38:53 -0800 (PST) Christoph Lameter [EMAIL PROTECTED] wrote: On Sat, 16 Dec 2006, KAMEZAWA Hiroyuki wrote: By this, we'll not access mem_section[] in usual ops. Why do we need mem_section? We have a page table that fulfills the same role. Basically, we don't need it. But I use mem_section[] in bootstrap and I want to keep patches small in this time. I think it's not too late that we'll consider removing it after implementing memory hot unplug.(and confirm we never use it.) -Kame - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING (1) at .../arch/i386/mm/highmem.c:49 [Was: 2.6.20-rc1-mm1]
On Sat, 16 Dec 2006 00:25:43 +0059 Jiri Slaby <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/ > > Ok, after fixing sata_promise, I got this 7 times: > [ 30.957539] WARNING (1) at /home/l/latest/xxx/arch/i386/mm/highmem.c:49 > kmap_atomic() > [ 30.957642] [] show_trace_log_lvl+0x1a/0x30 > [ 30.957748] [] show_trace+0x12/0x14 > [ 30.957846] [] dump_stack+0x16/0x18 > [ 30.957944] [] kmap_atomic+0x1f8/0x20d > [ 30.958041] [] ntfs_end_buffer_async_read+0x191/0x2ed > [ 30.958142] [] end_bio_bh_io_sync+0x26/0x3f > [ 30.958241] [] bio_endio+0x37/0x62 > [ 30.958338] [] __end_that_request_first+0x224/0x445 > [ 30.958441] [] end_that_request_chunk+0x8/0xa > [ 30.958541] [] scsi_end_request+0x1f/0xc6 > [ 30.958640] [] scsi_io_completion+0x1a1/0x336 > [ 30.958738] [] sd_rw_intr+0x23/0x1ab > [ 30.958835] [] scsi_finish_command+0x42/0x47 > [ 30.958935] [] scsi_softirq_done+0x64/0xca > [ 30.959032] [] blk_done_softirq+0x54/0x62 > [ 30.959132] [] __do_softirq+0x75/0xde > [ 30.959229] [] do_softirq+0x3b/0x3d > [ 30.959326] [] irq_exit+0x3b/0x3e > [ 30.959423] [] do_IRQ+0x45/0x7f > [ 30.959540] [] common_interrupt+0x23/0x28 > [ 30.959713] [] cpu_idle+0x7c/0xba > [ 30.959809] [] rest_init+0x23/0x37 > [ 30.959951] [] start_kernel+0x337/0x3e8 bah, that's a false positive. I'll teach kmap_atomic-debugging.patch about KM_BIO_SRC_IRQ and KM_BIO_DST_IRQ, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-mm1: unused sysrq_timer_list_show()
On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote: >... > Changes since 2.6.19-mm1: >... > +debugging-feature-proc-timer_list.patch > > Refreshed, refactored dynticks/hrtimer queue. >... I'd assume sysrq_timer_list_show() wasn't intended to be unused? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
On Fri, 15 Dec 2006 11:24:12 -0800, Andrew Morton wrote:
>On Fri, 15 Dec 2006 15:45:55 +0059
>Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>> > Temporarily at
>> >
>> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>> >
>> > Will appear later at
>> >
>> >
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>>
>> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
>> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>>
>> ATA port is not connected, only 2 SATA disks on my
>> # lspci -vvxs 02:01.0
>> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
>> TX2plus) (rev 02)
>> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> SERR- > Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: I/O ports at 8000 [size=128]
>> Region 2: I/O ports at 8400 [size=256]
>> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
>> Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at 5000 [disabled] [size=32K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
>> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
>> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
>> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>>
>
>Presumably
>
>void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
>
>gave us a null pointer.
Yes, it does look like pdc_port_start() is invoked with scr_addr
being zero for the port.
The -mm patch kit includes the Promise 2037x PATA support patch,
via libata-all. That patch is incomplete and actually breaks 2057x
chips: it leaves the SATA flag set for all ports on 2057x, which
makes sata_scr_valid() erroneously return true for the PATA port,
and that breaks many things including pdc_port_start().
Applying the trivial patch below on top of 2.6.20-rc1-mm1 should
fix the oops and even make the PATA port work on the 2057x.
With this patch -mm1's sata_promise.c will match what I've been
using recently to access both SATA and PATA devices on 2057x.
/Mikael
diff -rupN linux-2.6.20-rc1-mm1/drivers/ata/sata_promise.c
linux-2.6.20-rc1-mm1.sata_promise-2057x-pata-fix/drivers/ata/sata_promise.c
--- linux-2.6.20-rc1-mm1/drivers/ata/sata_promise.c 2006-12-15
23:33:17.0 +0100
+++ linux-2.6.20-rc1-mm1.sata_promise-2057x-pata-fix/drivers/ata/sata_promise.c
2006-12-15 23:58:09.0 +0100
@@ -213,7 +213,7 @@ static const struct ata_port_info pdc_po
/* board_2057x */
{
.sht= _ata_sht,
- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
+ .flags = PDC_COMMON_FLAGS /* | ATA_FLAG_SATA */,
.pio_mask = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask = 0x7f, /* udma0-6 ; FIXME */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
Mikael Pettersson wrote: > Applying the trivial patch below on top of 2.6.20-rc1-mm1 should Yup, Jeff fwd me this yet and it works. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING (1) at .../arch/i386/mm/highmem.c:49 [Was: 2.6.20-rc1-mm1]
Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/ Ok, after fixing sata_promise, I got this 7 times: [ 30.957539] WARNING (1) at /home/l/latest/xxx/arch/i386/mm/highmem.c:49 kmap_atomic() [ 30.957642] [] show_trace_log_lvl+0x1a/0x30 [ 30.957748] [] show_trace+0x12/0x14 [ 30.957846] [] dump_stack+0x16/0x18 [ 30.957944] [] kmap_atomic+0x1f8/0x20d [ 30.958041] [] ntfs_end_buffer_async_read+0x191/0x2ed [ 30.958142] [] end_bio_bh_io_sync+0x26/0x3f [ 30.958241] [] bio_endio+0x37/0x62 [ 30.958338] [] __end_that_request_first+0x224/0x445 [ 30.958441] [] end_that_request_chunk+0x8/0xa [ 30.958541] [] scsi_end_request+0x1f/0xc6 [ 30.958640] [] scsi_io_completion+0x1a1/0x336 [ 30.958738] [] sd_rw_intr+0x23/0x1ab [ 30.958835] [] scsi_finish_command+0x42/0x47 [ 30.958935] [] scsi_softirq_done+0x64/0xca [ 30.959032] [] blk_done_softirq+0x54/0x62 [ 30.959132] [] __do_softirq+0x75/0xde [ 30.959229] [] do_softirq+0x3b/0x3d [ 30.959326] [] irq_exit+0x3b/0x3e [ 30.959423] [] do_IRQ+0x45/0x7f [ 30.959540] [] common_interrupt+0x23/0x28 [ 30.959713] [] cpu_idle+0x7c/0xba [ 30.959809] [] rest_init+0x23/0x37 [ 30.959951] [] start_kernel+0x337/0x3e8 [ 30.960090] [<>] 0x0 regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
Andrew Morton wrote:
> On Fri, 15 Dec 2006 15:45:55 +0059
> Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>>>
>>> Will appear later at
>>>
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
>> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>>
>> ATA port is not connected, only 2 SATA disks on my
>> # lspci -vvxs 02:01.0
>> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
>> TX2plus) (rev 02)
>> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> SERR- > Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: I/O ports at 8000 [size=128]
>> Region 2: I/O ports at 8400 [size=256]
>> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
>> Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at 5000 [disabled] [size=32K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
>> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
>> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
>> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>>
>
> Presumably
>
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
>
> gave us a null pointer.
>
> Something like this:
>
> diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
> --- a/drivers/ata/sata_promise.c~a
> +++ a/drivers/ata/sata_promise.c
> @@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
> unsigned int tmp;
>
> + if (!mmio) {
> + rc = -EDOM;
> + goto out_kfree;
> + }
> tmp = readl(mmio + 0x014);
> tmp = (tmp & ~3) | 1; /* set bits 1:0 = 0:1 */
> writel(tmp, mmio + 0x014);
> _
>
> should perhaps let you wobble to a state where you can get us the full
> dmesg output, please.
>
> Actually, that should already be possible simply using netconsole.
I set it up and here it comes:
[6.779351] ACPI: PCI Interrupt :02:01.0[A] -> GSI 21 (level, low) ->
IRQ 19
[6.779483] sata_promise PATA port found
[6.779584] ata3: SATA max UDMA/133 cmd 0xF8816200 ctl 0xF8816238 bmdma 0x0
irq 19
[6.779708] ata4: SATA max UDMA/133 cmd 0xF8816280 ctl 0xF88162B8 bmdma 0x0
irq 19
[6.779831] BUG: unable to handle kernel NULL pointer dereference at virtual
address 0014
[6.779958] printing eip:
[6.780020] c02753b9
[6.780080] *pde =
[6.780142] Oops: [#1]
[6.780202] SMP
[6.780328] last sysfs file:
[6.780389] Modules linked in:
[6.780488] CPU:1
[6.780488] EIP:0060:[]Not tainted VLI
[6.780490] EFLAGS: 00010202 (2.6.20-rc1-mm1 #203)
[6.780680] EIP is at pdc_port_start+0x82/0xb0
[6.780742] eax: 0001 ebx: f7e3d9a0 ecx: edx:
[6.780808] esi: f7dcc2e8 edi: ebp: c193fe3c esp: c193fe24
[6.780873] ds: 007b es: 007b fs: 00d8 gs: ss: 0068
[6.780938] Process swapper (pid: 1, ti=c193e000 task=c1923a90
task.ti=c193e000)
[6.781004] Stack: 00d0 c1a59a80 c1adcc48 f7ea4000 f88162b8 f7dcc2e8
c193fe90 c026c724
[6.781398]0078 0004 0053 c043d998 f8816280 f88162b8
0013
[6.781789]f7ea4000 f7d91b00 f8816280 c1adcc48 0013 c1adcc00
0002 c01de64f
[6.782180] Call Trace:
[6.782298] [] show_trace_log_lvl+0x1a/0x30
[6.782396] [] show_stack_log_lvl+0xa5/0xca
[6.782494] [] show_registers+0x1d3/0x2b8
[6.782591] [] die+0x121/0x243
[6.782690] [] do_page_fault+0x2b8/0x5e8
[6.782788] [] error_code+0x7c/0x84
[6.782885] [] ata_device_add+0x1b1/0x516
[6.782983] [] pdc_ata_init_one+0x2a7/0x3e9
[6.783081] [] pci_device_probe+0x44/0x5f
[6.783180] [] driver_probe_device+0x75/0x12c
[6.783279] [] __driver_attach+0
Re: 2.6.20-rc1-mm1
On Fri, 15 Dec 2006 21:39:36 +0100 Damien Wyart <[EMAIL PROTECTED]> wrote: > With this new kernel, I notice two messages I do not have with > 2.6.19-rc6-mm2 : > > Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling barriers,trial > barrier write failed > Dec 15 20:00:47 brouette kernel: Filesystem "sda5": Disabling barriers,trial > barrier write failed > > Nothing changed in the config between the two, and going back to > 2.6.19-rc6-mm2 do not give the messages. I don't think anything has changed in this area in XFS. I'd expect that something got broken in sata, ata_piix or the block core which caused the "trial barrier write" to start failing. Various cc's hopefully added. > Also, I got panics when unmounting reiser4 filesystems with > 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 > being broken in 2.6.19-mm1 (even if it is not listed in notes for > 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did > not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. > For the moment, I mainly wanted to report the xfs messages which seems > a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trae, let the people at [EMAIL PROTECTED] know? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
On Fri, 15 Dec 2006 15:45:55 +0059
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>
> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>
> ATA port is not connected, only 2 SATA disks on my
> # lspci -vvxs 02:01.0
> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
> TX2plus) (rev 02)
> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR- Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: I/O ports at 8000 [size=128]
> Region 2: I/O ports at 8400 [size=256]
> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
> Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
> [virtual] Expansion ROM at 5000 [disabled] [size=32K]
> Capabilities: [60] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>
Presumably
void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
gave us a null pointer.
Something like this:
diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
--- a/drivers/ata/sata_promise.c~a
+++ a/drivers/ata/sata_promise.c
@@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
unsigned int tmp;
+ if (!mmio) {
+ rc = -EDOM;
+ goto out_kfree;
+ }
tmp = readl(mmio + 0x014);
tmp = (tmp & ~3) | 1; /* set bits 1:0 = 0:1 */
writel(tmp, mmio + 0x014);
_
should perhaps let you wobble to a state where you can get us the full
dmesg output, please.
Actually, that should already be possible simply using netconsole.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/ The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14: http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png ATA port is not connected, only 2 SATA disks on my # lspci -vvxs 02:01.0 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/ The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14: http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png ATA port is not connected, only 2 SATA disks on my # lspci -vvxs 02:01.0 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at 8000 [size=128] Region 2: I/O ports at 8400 [size=256] Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K] Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K] [virtual] Expansion ROM at 5000 [disabled] [size=32K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12 2.6.19-rc6-mm2 is OK (2.6.19-mm1 untested and won't be) regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
On Fri, 15 Dec 2006 15:45:55 +0059
Jiri Slaby [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
ATA port is not connected, only 2 SATA disks on my
# lspci -vvxs 02:01.0
02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 8000 [size=128]
Region 2: I/O ports at 8400 [size=256]
Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at 5000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
Presumably
void __iomem *mmio = (void __iomem *) ap-ioaddr.scr_addr;
gave us a null pointer.
Something like this:
diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
--- a/drivers/ata/sata_promise.c~a
+++ a/drivers/ata/sata_promise.c
@@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
void __iomem *mmio = (void __iomem *) ap-ioaddr.scr_addr;
unsigned int tmp;
+ if (!mmio) {
+ rc = -EDOM;
+ goto out_kfree;
+ }
tmp = readl(mmio + 0x014);
tmp = (tmp ~3) | 1; /* set bits 1:0 = 0:1 */
writel(tmp, mmio + 0x014);
_
should perhaps let you wobble to a state where you can get us the full
dmesg output, please.
Actually, that should already be possible simply using netconsole.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
