Re: [PATCH] hwmon: asus_atk0110.c fix uninitialized data access
On 23 March 2017 at 16:03, Arnd Bergmann <a...@arndb.de> wrote:
> The latest gcc-7 snapshot adds a warning to point out that when
> atk_read_value_old or atk_read_value_new fails, we copy
> uninitialized data into sensor->cached_value:
>
> drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
> drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
Ops, thanks for catching this.
>
> Adding an error check avoids this. All versions of the driver
> are affected.
>
> Fixes: 2c03d07ad54d ("hwmon: Add Asus ATK0110 support")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Luca Tettamanti <kronos...@gmail.com>
> ---
> drivers/hwmon/asus_atk0110.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
> index cccef87963e0..975c43d446f8 100644
> --- a/drivers/hwmon/asus_atk0110.c
> +++ b/drivers/hwmon/asus_atk0110.c
> @@ -646,6 +646,9 @@ static int atk_read_value(struct atk_sensor_data *sensor,
> u64 *value)
> else
> err = atk_read_value_new(sensor, value);
>
> + if (err)
> + return err;
> +
> sensor->is_valid = true;
> sensor->last_updated = jiffies;
> sensor->cached_value = *value;
> --
> 2.9.0
>
Re: [PATCH] hwmon: asus_atk0110.c fix uninitialized data access
On 23 March 2017 at 16:03, Arnd Bergmann wrote:
> The latest gcc-7 snapshot adds a warning to point out that when
> atk_read_value_old or atk_read_value_new fails, we copy
> uninitialized data into sensor->cached_value:
>
> drivers/hwmon/asus_atk0110.c: In function 'atk_input_show':
> drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
Ops, thanks for catching this.
>
> Adding an error check avoids this. All versions of the driver
> are affected.
>
> Fixes: 2c03d07ad54d ("hwmon: Add Asus ATK0110 support")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Luca Tettamanti
> ---
> drivers/hwmon/asus_atk0110.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
> index cccef87963e0..975c43d446f8 100644
> --- a/drivers/hwmon/asus_atk0110.c
> +++ b/drivers/hwmon/asus_atk0110.c
> @@ -646,6 +646,9 @@ static int atk_read_value(struct atk_sensor_data *sensor,
> u64 *value)
> else
> err = atk_read_value_new(sensor, value);
>
> + if (err)
> + return err;
> +
> sensor->is_valid = true;
> sensor->last_updated = jiffies;
> sensor->cached_value = *value;
> --
> 2.9.0
>
Re: [PATCH 4/4] fs: asus_atk0110: Fix DEFINE_SIMPLE_ATTRIBUTE semicolon definition and use
On Sun, Jun 29, 2014 at 1:20 AM, Joe Perches wrote:
> The DEFINE_SIMPLE_ATTRIBUTE macro should not end in a ;
> Fix the one use in the kernel tree that did not have a semicolon.
>
> Signed-off-by: Joe Perches
Acked-by: Luca Tettamanti
For my driver only ;-)
Luca
> ---
> drivers/hwmon/asus_atk0110.c | 2 +-
> include/linux/fs.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
> index ae208f6..cccef87 100644
> --- a/drivers/hwmon/asus_atk0110.c
> +++ b/drivers/hwmon/asus_atk0110.c
> @@ -688,7 +688,7 @@ static int atk_debugfs_gitm_get(void *p, u64 *val)
> DEFINE_SIMPLE_ATTRIBUTE(atk_debugfs_gitm,
> atk_debugfs_gitm_get,
> NULL,
> - "0x%08llx\n")
> + "0x%08llx\n");
>
> static int atk_acpi_print(char *buf, size_t sz, union acpi_object *obj)
> {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 8a9e7f8..e78e9ac 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2701,7 +2701,7 @@ static const struct file_operations __fops = {
> \
> .read= simple_attr_read,\
> .write = simple_attr_write, \
> .llseek = generic_file_llseek, \
> -};
> +}
>
> static inline __printf(1, 2)
> void __simple_attr_check_format(const char *fmt, ...)
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] fs: asus_atk0110: Fix DEFINE_SIMPLE_ATTRIBUTE semicolon definition and use
On Sun, Jun 29, 2014 at 1:20 AM, Joe Perches j...@perches.com wrote:
The DEFINE_SIMPLE_ATTRIBUTE macro should not end in a ;
Fix the one use in the kernel tree that did not have a semicolon.
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Luca Tettamanti kronos...@gmail.com
For my driver only ;-)
Luca
---
drivers/hwmon/asus_atk0110.c | 2 +-
include/linux/fs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
index ae208f6..cccef87 100644
--- a/drivers/hwmon/asus_atk0110.c
+++ b/drivers/hwmon/asus_atk0110.c
@@ -688,7 +688,7 @@ static int atk_debugfs_gitm_get(void *p, u64 *val)
DEFINE_SIMPLE_ATTRIBUTE(atk_debugfs_gitm,
atk_debugfs_gitm_get,
NULL,
- 0x%08llx\n)
+ 0x%08llx\n);
static int atk_acpi_print(char *buf, size_t sz, union acpi_object *obj)
{
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8a9e7f8..e78e9ac 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2701,7 +2701,7 @@ static const struct file_operations __fops = {
\
.read= simple_attr_read,\
.write = simple_attr_write, \
.llseek = generic_file_llseek, \
-};
+}
static inline __printf(1, 2)
void __simple_attr_check_format(const char *fmt, ...)
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata NCQ blacklist entry
On Nov 9, 2007 12:32 AM, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Luca Tettamanti wrote:
> > On Nov 7, 2007 1:55 PM, Tejun Heo <[EMAIL PROTECTED]> wrote:
> >> Florian La Roche wrote:
> >>> Hello all,
> >>>
> >>> I've taking email addresses from the last NCQ blacklist changes going
> >>> into the kernel.
> >>> This Fujitsu drive also gives me spurious command completions. Detailed
> >>> output also available at
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=366181.
> >>>
> >>> Let me know if you need more info or anything else.
> >>>
> >>> --- drivers/ata/libata-core.c
> >>> +++ drivers/ata/libata-core.c
> >>> @@ -4222,6 +4222,7 @@
> >>> { "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
> >>> { "WDC WD3200AAJS-00RYA0", "12.01B01", ATA_HORKAGE_NONCQ, },
> >>> { "FUJITSU MHV2080BH", "00840028", ATA_HORKAGE_NONCQ, },
> >>> + { "FUJITSU MHW2160BJ G2", NULL, ATA_HORKAGE_NONCQ },
> >>> { "ST9120822AS","3.CLF",ATA_HORKAGE_NONCQ, },
> >>> { "ST9160821AS","3.CLF",ATA_HORKAGE_NONCQ, },
> >>> { "ST9160821AS","3.ALD",ATA_HORKAGE_NONCQ, },
> >> Thanks. We're currently trying to find out what's actually going on
> >> with all these drives. At first, drives which got blacklisted aren't
> >> many and made sense (had other problems with NCQ, etc..) but with new
> >> generation drives from many vendors showing the same symptom, we aren't
> >> too sure now.
> >
> > Is there a way to tell whether Windows is using NCQ or not? I checked
> > the system log (or whatever it's called) on my notebook and is clean
> > but I'm not sure it's using NCQ (I don't even know if it'd log
> > spurious completions somewhere).
>
> Which driver is installed for the SATA controller in Windows, the
> chipset-manufacturer-provided AHCI driver or the default Microsoft
> driver? You'd need the AHCI driver installed for NCQ to be used.
I'm aware of this. I'm using the AHCI driver (from Intel). Still, I
don't know if it's really used or limited like under Linux.
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata NCQ blacklist entry
On Nov 7, 2007 1:55 PM, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Florian La Roche wrote:
> > Hello all,
> >
> > I've taking email addresses from the last NCQ blacklist changes going
> > into the kernel.
> > This Fujitsu drive also gives me spurious command completions. Detailed
> > output also available at https://bugzilla.redhat.com/show_bug.cgi?id=366181.
> >
> > Let me know if you need more info or anything else.
> >
> > --- drivers/ata/libata-core.c
> > +++ drivers/ata/libata-core.c
> > @@ -4222,6 +4222,7 @@
> > { "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
> > { "WDC WD3200AAJS-00RYA0", "12.01B01", ATA_HORKAGE_NONCQ, },
> > { "FUJITSU MHV2080BH", "00840028", ATA_HORKAGE_NONCQ, },
> > + { "FUJITSU MHW2160BJ G2", NULL, ATA_HORKAGE_NONCQ },
> > { "ST9120822AS","3.CLF",ATA_HORKAGE_NONCQ, },
> > { "ST9160821AS","3.CLF",ATA_HORKAGE_NONCQ, },
> > { "ST9160821AS","3.ALD",ATA_HORKAGE_NONCQ, },
>
> Thanks. We're currently trying to find out what's actually going on
> with all these drives. At first, drives which got blacklisted aren't
> many and made sense (had other problems with NCQ, etc..) but with new
> generation drives from many vendors showing the same symptom, we aren't
> too sure now.
Is there a way to tell whether Windows is using NCQ or not? I checked
the system log (or whatever it's called) on my notebook and is clean
but I'm not sure it's using NCQ (I don't even know if it'd log
spurious completions somewhere).
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata NCQ blacklist entry
On Nov 9, 2007 12:32 AM, Robert Hancock [EMAIL PROTECTED] wrote:
Luca Tettamanti wrote:
On Nov 7, 2007 1:55 PM, Tejun Heo [EMAIL PROTECTED] wrote:
Florian La Roche wrote:
Hello all,
I've taking email addresses from the last NCQ blacklist changes going
into the kernel.
This Fujitsu drive also gives me spurious command completions. Detailed
output also available at
https://bugzilla.redhat.com/show_bug.cgi?id=366181.
Let me know if you need more info or anything else.
--- drivers/ata/libata-core.c
+++ drivers/ata/libata-core.c
@@ -4222,6 +4222,7 @@
{ WDC WD740ADFD-00NLR1, NULL, ATA_HORKAGE_NONCQ, },
{ WDC WD3200AAJS-00RYA0, 12.01B01, ATA_HORKAGE_NONCQ, },
{ FUJITSU MHV2080BH, 00840028, ATA_HORKAGE_NONCQ, },
+ { FUJITSU MHW2160BJ G2, NULL, ATA_HORKAGE_NONCQ },
{ ST9120822AS,3.CLF,ATA_HORKAGE_NONCQ, },
{ ST9160821AS,3.CLF,ATA_HORKAGE_NONCQ, },
{ ST9160821AS,3.ALD,ATA_HORKAGE_NONCQ, },
Thanks. We're currently trying to find out what's actually going on
with all these drives. At first, drives which got blacklisted aren't
many and made sense (had other problems with NCQ, etc..) but with new
generation drives from many vendors showing the same symptom, we aren't
too sure now.
Is there a way to tell whether Windows is using NCQ or not? I checked
the system log (or whatever it's called) on my notebook and is clean
but I'm not sure it's using NCQ (I don't even know if it'd log
spurious completions somewhere).
Which driver is installed for the SATA controller in Windows, the
chipset-manufacturer-provided AHCI driver or the default Microsoft
driver? You'd need the AHCI driver installed for NCQ to be used.
I'm aware of this. I'm using the AHCI driver (from Intel). Still, I
don't know if it's really used or limited like under Linux.
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata NCQ blacklist entry
On Nov 7, 2007 1:55 PM, Tejun Heo [EMAIL PROTECTED] wrote:
Florian La Roche wrote:
Hello all,
I've taking email addresses from the last NCQ blacklist changes going
into the kernel.
This Fujitsu drive also gives me spurious command completions. Detailed
output also available at https://bugzilla.redhat.com/show_bug.cgi?id=366181.
Let me know if you need more info or anything else.
--- drivers/ata/libata-core.c
+++ drivers/ata/libata-core.c
@@ -4222,6 +4222,7 @@
{ WDC WD740ADFD-00NLR1, NULL, ATA_HORKAGE_NONCQ, },
{ WDC WD3200AAJS-00RYA0, 12.01B01, ATA_HORKAGE_NONCQ, },
{ FUJITSU MHV2080BH, 00840028, ATA_HORKAGE_NONCQ, },
+ { FUJITSU MHW2160BJ G2, NULL, ATA_HORKAGE_NONCQ },
{ ST9120822AS,3.CLF,ATA_HORKAGE_NONCQ, },
{ ST9160821AS,3.CLF,ATA_HORKAGE_NONCQ, },
{ ST9160821AS,3.ALD,ATA_HORKAGE_NONCQ, },
Thanks. We're currently trying to find out what's actually going on
with all these drives. At first, drives which got blacklisted aren't
many and made sense (had other problems with NCQ, etc..) but with new
generation drives from many vendors showing the same symptom, we aren't
too sure now.
Is there a way to tell whether Windows is using NCQ or not? I checked
the system log (or whatever it's called) on my notebook and is clean
but I'm not sure it's using NCQ (I don't even know if it'd log
spurious completions somewhere).
Luca
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Regression: libata: implement ata_wait_after_reset()
Hi, latest git causes my extra disk controller to die with screaming interrupts. Picture here: http://img113.imageshack.us/my.php?image=im000708vj7.jpg The controller card is this one (SATA port is not in use): 05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Date: Tue Oct 16 14:21:24 2007 -0700 libata: implement ata_wait_after_reset() On certain device/controller combination, 0xff status is asserted after reset and doesn't get cleared during 150ms post-reset wait. As 0xff status is interpreted as no device (for good reasons), this can lead to misdetection on such cases. This patch implements ata_wait_after_reset() which replaces the 150ms sleep and waits upto ATA_TMOUT_FF_WAIT if status is 0xff. ATA_TMOUT_FF_WAIT is currently 800ms which is enough for HHD424020F7SV00 to get detected but not enough for Quantum GoVault drive which is known to take upto 2s. Without parallel probing, spending 2s on 0xff port would incur too much delay on ata_piix's which use 0xff to indicate empty port and doesn't have SCR register, so GoVault needs to wait till parallel probing. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> :04 04 44a0d6b9b2b0e7d4721c013d90a7ccd9656dcd2c 8587bfcf26176f1286bfab26cd6d150712dfd5f8 M drivers :04 04 2775bec0948fd2306c750b3a215f449c8b3d13ba 8c0fdbb87154af8fc804918a29e72060a2c6939c M include I can set up a serial console if you need further debug output. Luca -- Non sempre quello che viene dopo e` progresso. Alessandro Manzoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression: libata: implement ata_wait_after_reset()
Hi, latest git causes my extra disk controller to die with screaming interrupts. Picture here: http://img113.imageshack.us/my.php?image=im000708vj7.jpg The controller card is this one (SATA port is not in use): 05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller 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: 128, Cache Line Size: 512 bytes Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at c000 [size=8] Region 1: I/O ports at bc00 [size=4] Region 2: I/O ports at b880 [size=8] Region 3: I/O ports at b800 [size=4] Region 4: I/O ports at b480 [size=16] Expansion ROM at ff7f [disabled] [size=64K] 05:02.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85) Subsystem: ALi Corporation Unknown device 5281 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: 128 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at c880 [size=8] Region 1: I/O ports at c800 [size=4] Region 2: I/O ports at c480 [size=8] Region 3: I/O ports at c400 [size=4] Region 4: I/O ports at c080 [size=16] The driver is pata_ali. I bisected it down to: kronos:~/src/linux-2.6.git$ git bisect bad 88ff6eafbb2a1c55f0f0e2e16d72e7b10d8ae8a5 is first bad commit commit 88ff6eafbb2a1c55f0f0e2e16d72e7b10d8ae8a5 Author: Tejun Heo [EMAIL PROTECTED] Date: Tue Oct 16 14:21:24 2007 -0700 libata: implement ata_wait_after_reset() On certain device/controller combination, 0xff status is asserted after reset and doesn't get cleared during 150ms post-reset wait. As 0xff status is interpreted as no device (for good reasons), this can lead to misdetection on such cases. This patch implements ata_wait_after_reset() which replaces the 150ms sleep and waits upto ATA_TMOUT_FF_WAIT if status is 0xff. ATA_TMOUT_FF_WAIT is currently 800ms which is enough for HHD424020F7SV00 to get detected but not enough for Quantum GoVault drive which is known to take upto 2s. Without parallel probing, spending 2s on 0xff port would incur too much delay on ata_piix's which use 0xff to indicate empty port and doesn't have SCR register, so GoVault needs to wait till parallel probing. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Jeff Garzik [EMAIL PROTECTED] :04 04 44a0d6b9b2b0e7d4721c013d90a7ccd9656dcd2c 8587bfcf26176f1286bfab26cd6d150712dfd5f8 M drivers :04 04 2775bec0948fd2306c750b3a215f449c8b3d13ba 8c0fdbb87154af8fc804918a29e72060a2c6939c M include I can set up a serial console if you need further debug output. Luca -- Non sempre quello che viene dopo e` progresso. Alessandro Manzoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] acpi4asus: add support for F3Sa
Add support for ASUS F3Sa notebook. Features:
- LCD on/off
- Brightness
- Wifi kill
- Bluetooth kill
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
---
There may be another method to read LCD status which doesn't require
ad-hoc code, but I'm unable to find it. I'm attaching the DSDT.
drivers/acpi/asus_acpi.c | 55 ++
1 file changed, 45 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
index d915fec..d25ef96 100644
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -142,6 +142,7 @@ struct asus_hotk {
xxN,//M2400N, M3700N, M5200N, M6800N, S1300N, S5200N
A4S,//Z81sp
//(Centrino)
+ F3Sa,
END_MODEL
} model;//Models currently supported
u16 event_count[128]; //count for each event TODO make this better
@@ -405,7 +406,20 @@ static struct model_data model_conf[END_MODEL] = {
.brightness_get= "GPLV",
.mt_bt_switch = "BLED",
.mt_wled = "WLED"
- }
+ },
+
+ {
+ .name = "F3Sa",
+ .mt_bt_switch = "BLED",
+ .mt_wled= "WLED",
+ .mt_mled= "MLED",
+ .brightness_get = "GPLV",
+ .brightness_set = "SPLV",
+ .mt_lcd_switch = "\\_SB.PCI0.SBRG.EC0._Q10",
+ .lcd_status = "\\_SB.PCI0.SBRG.EC0.RPIN",
+ .display_get= "\\ADVG",
+ .display_set= "SDSP",
+ },
};
@@ -710,15 +724,8 @@ static int get_lcd_state(void)
{
int lcd = 0;
- if (hotk->model != L3H) {
- /* We don't have to check anything if we are here */
- if (!read_acpi_int(NULL, hotk->methods->lcd_status, ))
- printk(KERN_WARNING
- "Asus ACPI: Error reading LCD status\n");
-
- if (hotk->model == L2D)
- lcd = ~lcd;
- } else {/* L3H and the like have to be handled
differently */
+ if (hotk->model == L3H) {
+ /* L3H and the like have to be handled differently */
acpi_status status = 0;
struct acpi_object_list input;
union acpi_object mt_params[2];
@@ -745,6 +752,32 @@ static int get_lcd_state(void)
if (out_obj.type == ACPI_TYPE_INTEGER)
/* That's what the AML code does */
lcd = out_obj.integer.value >> 8;
+ } else if (hotk->model == F3Sa) {
+ unsigned long tmp;
+ union acpi_object param;
+ struct acpi_object_list input;
+ acpi_status status;
+
+ /* Read pin 11 */
+ param.type = ACPI_TYPE_INTEGER;
+ param.integer.value = 0x11;
+ input.count = 1;
+ input.pointer =
+
+ status = acpi_evaluate_integer(NULL, hotk->methods->lcd_status,
+ , );
+ if (status != AE_OK)
+ return -1;
+
+ lcd = tmp;
+ } else {
+ /* We don't have to check anything if we are here */
+ if (!read_acpi_int(NULL, hotk->methods->lcd_status, ))
+ printk(KERN_WARNING
+ "Asus ACPI: Error reading LCD status\n");
+
+ if (hotk->model == L2D)
+ lcd = ~lcd;
}
return (lcd & 1);
@@ -1134,6 +1167,8 @@ static int asus_model_match(char *model)
return W5A;
else if (strncmp(model, "A4S", 3) == 0)
return A4S;
+ else if (strncmp(model, "F3Sa", 4) == 0)
+ return F3Sa;
else
return END_MODEL;
}
Luca
--
Pare che gli uomini facciano l'amore di continuo e le donne solo
raramente. Ci dev'essere qualcuno che bara.
f3sa-dsdt.dsl.bz2
Description: Binary data
[PATCH] acpi4asus: add support for F3Sa
Add support for ASUS F3Sa notebook. Features:
- LCD on/off
- Brightness
- Wifi kill
- Bluetooth kill
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
---
There may be another method to read LCD status which doesn't require
ad-hoc code, but I'm unable to find it. I'm attaching the DSDT.
drivers/acpi/asus_acpi.c | 55 ++
1 file changed, 45 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/asus_acpi.c b/drivers/acpi/asus_acpi.c
index d915fec..d25ef96 100644
--- a/drivers/acpi/asus_acpi.c
+++ b/drivers/acpi/asus_acpi.c
@@ -142,6 +142,7 @@ struct asus_hotk {
xxN,//M2400N, M3700N, M5200N, M6800N, S1300N, S5200N
A4S,//Z81sp
//(Centrino)
+ F3Sa,
END_MODEL
} model;//Models currently supported
u16 event_count[128]; //count for each event TODO make this better
@@ -405,7 +406,20 @@ static struct model_data model_conf[END_MODEL] = {
.brightness_get= GPLV,
.mt_bt_switch = BLED,
.mt_wled = WLED
- }
+ },
+
+ {
+ .name = F3Sa,
+ .mt_bt_switch = BLED,
+ .mt_wled= WLED,
+ .mt_mled= MLED,
+ .brightness_get = GPLV,
+ .brightness_set = SPLV,
+ .mt_lcd_switch = \\_SB.PCI0.SBRG.EC0._Q10,
+ .lcd_status = \\_SB.PCI0.SBRG.EC0.RPIN,
+ .display_get= \\ADVG,
+ .display_set= SDSP,
+ },
};
@@ -710,15 +724,8 @@ static int get_lcd_state(void)
{
int lcd = 0;
- if (hotk-model != L3H) {
- /* We don't have to check anything if we are here */
- if (!read_acpi_int(NULL, hotk-methods-lcd_status, lcd))
- printk(KERN_WARNING
- Asus ACPI: Error reading LCD status\n);
-
- if (hotk-model == L2D)
- lcd = ~lcd;
- } else {/* L3H and the like have to be handled
differently */
+ if (hotk-model == L3H) {
+ /* L3H and the like have to be handled differently */
acpi_status status = 0;
struct acpi_object_list input;
union acpi_object mt_params[2];
@@ -745,6 +752,32 @@ static int get_lcd_state(void)
if (out_obj.type == ACPI_TYPE_INTEGER)
/* That's what the AML code does */
lcd = out_obj.integer.value 8;
+ } else if (hotk-model == F3Sa) {
+ unsigned long tmp;
+ union acpi_object param;
+ struct acpi_object_list input;
+ acpi_status status;
+
+ /* Read pin 11 */
+ param.type = ACPI_TYPE_INTEGER;
+ param.integer.value = 0x11;
+ input.count = 1;
+ input.pointer = param;
+
+ status = acpi_evaluate_integer(NULL, hotk-methods-lcd_status,
+ input, tmp);
+ if (status != AE_OK)
+ return -1;
+
+ lcd = tmp;
+ } else {
+ /* We don't have to check anything if we are here */
+ if (!read_acpi_int(NULL, hotk-methods-lcd_status, lcd))
+ printk(KERN_WARNING
+ Asus ACPI: Error reading LCD status\n);
+
+ if (hotk-model == L2D)
+ lcd = ~lcd;
}
return (lcd 1);
@@ -1134,6 +1167,8 @@ static int asus_model_match(char *model)
return W5A;
else if (strncmp(model, A4S, 3) == 0)
return A4S;
+ else if (strncmp(model, F3Sa, 4) == 0)
+ return F3Sa;
else
return END_MODEL;
}
Luca
--
Pare che gli uomini facciano l'amore di continuo e le donne solo
raramente. Ci dev'essere qualcuno che bara.
f3sa-dsdt.dsl.bz2
Description: Binary data
Re: [kvm-devel] severe bug in 2.6.23+ kvm.git
On 10/19/07, Christian Borntraeger <[EMAIL PROTECTED]> wrote: > Am Freitag, 19. Oktober 2007 schrieb Laurent Vivier: > > Did you patch kvm.git with patch-2.6.23.1.bz2 or did you download > > linux-2.6.23.1.tar.bz2 ? > > > > 2.6.23.1 corrects nothing except sata_mv... > > Yes I know. The question we tried to answer was: is the bug in 2.6.23 or was > it introduced after 2.6.23, as kvm.git already contains lots of post 2. 6.23 > stuff. > Current state is: > > kvm.git with tag 2.6.23-rc6 works for days without a problem. > 2.6.23.1 vanilla has survived and is currently still under test. > kvm.git tag master killed our filesystem at least three times.since monday. linus-git has at least one bug with SG chaining, but usually it just hangs the machine. Patch is here: http://lkml.org/lkml/2007/10/17/269 Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [kvm-devel] severe bug in 2.6.23+ kvm.git
On 10/19/07, Christian Borntraeger [EMAIL PROTECTED] wrote: Am Freitag, 19. Oktober 2007 schrieb Laurent Vivier: Did you patch kvm.git with patch-2.6.23.1.bz2 or did you download linux-2.6.23.1.tar.bz2 ? 2.6.23.1 corrects nothing except sata_mv... Yes I know. The question we tried to answer was: is the bug in 2.6.23 or was it introduced after 2.6.23, as kvm.git already contains lots of post 2. 6.23 stuff. Current state is: kvm.git with tag 2.6.23-rc6 works for days without a problem. 2.6.23.1 vanilla has survived and is currently still under test. kvm.git tag master killed our filesystem at least three times.since monday. linus-git has at least one bug with SG chaining, but usually it just hangs the machine. Patch is here: http://lkml.org/lkml/2007/10/17/269 Luca - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] block subsystem related crash with latest -git
Il Wed, Oct 17, 2007 at 07:29:32PM +0200, Jens Axboe ha scritto:
> OK, it is fine, as long as the sglist is cleared initially. And I don't
> think there's anyway around that, clearly I didn't think long enough
> before including the memset() removal from Tomo.
>
> Ingo, please try this rolled up version.
>
> Linus, this should work. It would probably be best if you first did a
> git revert on f5c0dde4c66421a3a2d7d6fa604a712c9b0744e5 and then applied
> the ll_rw_blk.c bit alone. Do you want me to stuff that (revert + patch)
> into a branch for you to pull?
>
> diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
> index 9e3f3cc..3935469 100644
> --- a/block/ll_rw_blk.c
> +++ b/block/ll_rw_blk.c
> @@ -1322,8 +1322,8 @@ int blk_rq_map_sg(struct request_queue *q, struct
> request *rq,
> struct scatterlist *sglist)
> {
> struct bio_vec *bvec, *bvprv;
> - struct scatterlist *next_sg, *sg;
> struct req_iterator iter;
> + struct scatterlist *sg;
> int nsegs, cluster;
>
> nsegs = 0;
> @@ -1333,7 +1333,7 @@ int blk_rq_map_sg(struct request_queue *q, struct
> request *rq,
>* for each bio in rq
>*/
> bvprv = NULL;
> - sg = next_sg = [0];
> + sg = NULL;
> rq_for_each_segment(bvec, rq, iter) {
> int nbytes = bvec->bv_len;
>
> @@ -1349,8 +1349,10 @@ int blk_rq_map_sg(struct request_queue *q, struct
> request *rq,
> sg->length += nbytes;
> } else {
> new_segment:
> - sg = next_sg;
> - next_sg = sg_next(sg);
> + if (!sg)
> + sg = sglist;
> + else
> + sg = sg_next(sg);
>
> memset(sg, 0, sizeof(*sg));
> sg->page = bvec->bv_page;
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 0c86be7..aac8a02 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -764,6 +764,8 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd
> *cmd, gfp_t gfp_mask)
> if (unlikely(!sgl))
> goto enomem;
>
> + memset(sgl, 0, sizeof(*sgl) * sgp->size);
> +
> /*
>* first loop through, set initial index and return value
>*/
>
Hi Jens,
I just hit what I believe is the same bug, though with a slightly
different OOPS (I see a NULL pointer dereference, see below). The
patches fixes the bug, and - as Linus suggested - the piece touching
scsi_lib.c is enough.
The OOPS:
scsi4 : ata_piix
scsi5 : ata_piix
ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata5.00: ATAPI: MATSHITADVD-RAM UJ-850S, 1.22, max UDMA/33
Unable to handle kernel NULL pointer dereference at 0020 RIP:
[] blk_rq_map_sg+0xf6/0x16a
PGD 4711067 PUD 508c067 PMD 0
Oops: [1] PREEMPT SMP
CPU 0
Modules linked in: sd_mod ohci1394 ehci_hcd ata_piix ieee1394 ahci uhci_hcd
libata scsi_mod usbcore thermal processor fan
Pid: 0, comm: swapper Not tainted 2.6.23-ge6d5a11d #3
RIP: 0010:[] [] blk_rq_map_sg+0xf6/0x16a
RSP: 0018:804eccd8 EFLAGS: 00010087
RAX: 05331000 RBX: 810004740220 RCX: 81000100
RDX: RSI: 8100052d4f50 RDI: 05142c00
RBP: 1400 R08: R09: 8100052a3980
R10: 05143000 R11: 0400 R12: 8100047a4000
R13: R14: 0002 R15:
FS: () GS:8049a000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0020 CR3: 05118000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 0, threadinfo 804ac000, task 8046c340)
Stack: 88041834 00010314ba00 81000477fa80 81000503dd80
81000503dd80 81000517fc00 001e 1d4c
8804193c 15925849 81000473f800 81000503dd80
Call Trace:
[] :scsi_mod:scsi_alloc_sgtable+0xad/0x13c
[] :scsi_mod:scsi_init_io+0x79/0xd9
[] :sd_mod:sd_prep_fn+0x59/0x367
[] elv_next_request+0xc0/0x14a
[] :scsi_mod:scsi_request_fn+0x88/0x356
[] blk_run_queue+0x41/0x72
[] :scsi_mod:scsi_next_command+0x2d/0x39
[] :scsi_mod:scsi_end_request+0xbb/0xc9
[] :scsi_mod:scsi_io_completion+0xf8/0x2d3
[] blk_done_softirq+0x62/0x6f
[] __do_softirq+0x59/0xc3
[] call_softirq+0x1c/0x28
[] do_softirq+0x2c/0x7d
[] irq_exit+0x36/0x81
[] do_IRQ+0x13d/0x161
[] ret_from_intr+0x0/0xa
[] :processor:acpi_processor_idle+0x2cb/0x496
[] :processor:acpi_processor_idle+0x2c7/0x496
[] :processor:acpi_processor_idle+0x0/0x496
[]
Re: [bug] block subsystem related crash with latest -git
Il Wed, Oct 17, 2007 at 07:29:32PM +0200, Jens Axboe ha scritto:
OK, it is fine, as long as the sglist is cleared initially. And I don't
think there's anyway around that, clearly I didn't think long enough
before including the memset() removal from Tomo.
Ingo, please try this rolled up version.
Linus, this should work. It would probably be best if you first did a
git revert on f5c0dde4c66421a3a2d7d6fa604a712c9b0744e5 and then applied
the ll_rw_blk.c bit alone. Do you want me to stuff that (revert + patch)
into a branch for you to pull?
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 9e3f3cc..3935469 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1322,8 +1322,8 @@ int blk_rq_map_sg(struct request_queue *q, struct
request *rq,
struct scatterlist *sglist)
{
struct bio_vec *bvec, *bvprv;
- struct scatterlist *next_sg, *sg;
struct req_iterator iter;
+ struct scatterlist *sg;
int nsegs, cluster;
nsegs = 0;
@@ -1333,7 +1333,7 @@ int blk_rq_map_sg(struct request_queue *q, struct
request *rq,
* for each bio in rq
*/
bvprv = NULL;
- sg = next_sg = sglist[0];
+ sg = NULL;
rq_for_each_segment(bvec, rq, iter) {
int nbytes = bvec-bv_len;
@@ -1349,8 +1349,10 @@ int blk_rq_map_sg(struct request_queue *q, struct
request *rq,
sg-length += nbytes;
} else {
new_segment:
- sg = next_sg;
- next_sg = sg_next(sg);
+ if (!sg)
+ sg = sglist;
+ else
+ sg = sg_next(sg);
memset(sg, 0, sizeof(*sg));
sg-page = bvec-bv_page;
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0c86be7..aac8a02 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -764,6 +764,8 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd
*cmd, gfp_t gfp_mask)
if (unlikely(!sgl))
goto enomem;
+ memset(sgl, 0, sizeof(*sgl) * sgp-size);
+
/*
* first loop through, set initial index and return value
*/
Hi Jens,
I just hit what I believe is the same bug, though with a slightly
different OOPS (I see a NULL pointer dereference, see below). The
patches fixes the bug, and - as Linus suggested - the piece touching
scsi_lib.c is enough.
The OOPS:
scsi4 : ata_piix
scsi5 : ata_piix
ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
sda1 sda2 sda3 sda5 sda6
sd 0:0:0:0: [sda] Attached SCSI disk
ata5.00: ATAPI: MATSHITADVD-RAM UJ-850S, 1.22, max UDMA/33
Unable to handle kernel NULL pointer dereference at 0020 RIP:
[802d275e] blk_rq_map_sg+0xf6/0x16a
PGD 4711067 PUD 508c067 PMD 0
Oops: [1] PREEMPT SMP
CPU 0
Modules linked in: sd_mod ohci1394 ehci_hcd ata_piix ieee1394 ahci uhci_hcd
libata scsi_mod usbcore thermal processor fan
Pid: 0, comm: swapper Not tainted 2.6.23-ge6d5a11d #3
RIP: 0010:[802d275e] [802d275e] blk_rq_map_sg+0xf6/0x16a
RSP: 0018:804eccd8 EFLAGS: 00010087
RAX: 05331000 RBX: 810004740220 RCX: 81000100
RDX: RSI: 8100052d4f50 RDI: 05142c00
RBP: 1400 R08: R09: 8100052a3980
R10: 05143000 R11: 0400 R12: 8100047a4000
R13: R14: 0002 R15:
FS: () GS:8049a000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 0020 CR3: 05118000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process swapper (pid: 0, threadinfo 804ac000, task 8046c340)
Stack: 88041834 00010314ba00 81000477fa80 81000503dd80
81000503dd80 81000517fc00 001e 1d4c
8804193c 15925849 81000473f800 81000503dd80
Call Trace:
IRQ [88041834] :scsi_mod:scsi_alloc_sgtable+0xad/0x13c
[8804193c] :scsi_mod:scsi_init_io+0x79/0xd9
[880d1328] :sd_mod:sd_prep_fn+0x59/0x367
[802d07ff] elv_next_request+0xc0/0x14a
[88042367] :scsi_mod:scsi_request_fn+0x88/0x356
[802d46f7] blk_run_queue+0x41/0x72
[88041135] :scsi_mod:scsi_next_command+0x2d/0x39
[880412ae] :scsi_mod:scsi_end_request+0xbb/0xc9
[880415ac] :scsi_mod:scsi_io_completion+0xf8/0x2d3
[802d4a83] blk_done_softirq+0x62/0x6f
[80238f28] __do_softirq+0x59/0xc3
[8020d13c] call_softirq+0x1c/0x28
[8020ec26] do_softirq+0x2c/0x7d
[80238e30] irq_exit+0x36/0x81
Re: kexec: Cannot determine the file type of arch/x86/boot/bzImage
Sam, please take a look at this: Il Tue, Oct 16, 2007 at 09:51:13PM +0200, Thomas Meyer ha scritto: > Look at this: > > $ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1) > arch/x86/boot/bzImage: Linux kernel x86 boot executable zImage, version > 2.6.23 ([EMAIL PROTECTED]) #39, RO-rootFS, root_dev 0x803, swap_dev > 0x1, Prompt for Videomode I just noticed the same problem when grub refused to load that thing. The issue is that the build system created a zImage (and not a bzImage); even passing the target explicitly doesn't solve the problem. git bisect says: f77bf01425b11947eeb3b5b54685212c302741b8 is first bad commit commit f77bf01425b11947eeb3b5b54685212c302741b8 Author: Sam Ravnborg <[EMAIL PROTECTED](none)> --- (Ops, you have a problem on you git setup) Date: Mon Oct 15 22:25:06 2007 +0200 kbuild: introduce ccflags-y, asflags-y and ldflags-y Introduce ccflags-y, asflags-y and ldflags-y so we soon can deprecate use of EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. This patch does not touch any in-tree users - thats next round. Lets get this committed first and then fix the users of the soon to be deprecated variants next. The rationale behind this change is to introduce support for makefile fragments like: ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG As a replacement for the uglier: ifeq ($(CONFIG_WHATEVER_DEBUG),y) EXTRA_CFLAGS := -DDEBUG endif Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> :04 04 03915c7c738eefa31f2327521130df23b7dfe95e e2a1677df3709813ff793fdfa77d80fff9b838a7 M Documentation :04 04 ff4ad149975df39509a18782341f1f8f6a32f07a 663bce3c08a0f2e107cecb0b29edc4fe9d5735a0 M scripts I'm building a x86_64 image, using an external directory (O=...) in case it matters. Bisect log: git-bisect start # bad: [821f3eff7cdb9d6c7076effabd46c96c322daed1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild git-bisect bad 821f3eff7cdb9d6c7076effabd46c96c322daed1 # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23 git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1 # good: [4d5709a7b7d54fc5882d2943a14988a92d48c00a] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq git-bisect good 4d5709a7b7d54fc5882d2943a14988a92d48c00a # good: [b5869ce7f68b233ceb81465a7644be0d9a5f3dbb] Merge git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched git-bisect good b5869ce7f68b233ceb81465a7644be0d9a5f3dbb # good: [11370ee2c1c578a704f47d5513d57274c335db43] [ALSA] hda-codec: Add two new systems to ALC883 git-bisect good 11370ee2c1c578a704f47d5513d57274c335db43 # good: [05440dfcfcabde6fcf7297dfa5a29f0355b78ffb] rtc-cmos probe() cleanup git-bisect good 05440dfcfcabde6fcf7297dfa5a29f0355b78ffb # good: [f20bf6125605acbbc7eb8c9420d7221c91aa83eb] time: introduce xtime_seconds git-bisect good f20bf6125605acbbc7eb8c9420d7221c91aa83eb # good: [92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0] Merge branch 'for-linus' of git://git.kernel.dk/data/git/linux-2.6-block git-bisect good 92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0 # good: [fc8a327db6c46de783b1a4276d846841b9abc24c] Merge branch 'linus' of master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa git-bisect good fc8a327db6c46de783b1a4276d846841b9abc24c # good: [3b16cc2d4ccc3949455432241fe378448e77d911] kbuild: move Kai Germaschewski to CREDITS git-bisect good 3b16cc2d4ccc3949455432241fe378448e77d911 # good: [2f7055c5932ecc02159be375ebda1eee64665d17] [MIPS] MIPSsim: Fix booting from NFS root git-bisect good 2f7055c5932ecc02159be375ebda1eee64665d17 # good: [52bcc3308ae3344266f55bf98a22c1ac0201eda7] kbuild: enable use of AFLAGS and CFLAGS on commandline git-bisect good 52bcc3308ae3344266f55bf98a22c1ac0201eda7 # good: [8bb00d83d8fc2de5c0614f5d55780107e0c375fe] [MIPS] Increase cp0 compare clockevent min_delta_ns from 0x30 to 0x300. git-bisect good 8bb00d83d8fc2de5c0614f5d55780107e0c375fe # bad: [f77bf01425b11947eeb3b5b54685212c302741b8] kbuild: introduce ccflags-y, asflags-y and ldflags-y git-bisect bad f77bf01425b11947eeb3b5b54685212c302741b8 # good: [06c5040cdb13d27adad118f2fbfae905a1911b37] kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP git-bisect good 06c5040cdb13d27adad118f2fbfae905a1911b37 Luca -- The trouble with computers is that they do what you tell them, not what you want. D. Cohen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: kexec: Cannot determine the file type of arch/x86/boot/bzImage
Sam, please take a look at this: Il Tue, Oct 16, 2007 at 09:51:13PM +0200, Thomas Meyer ha scritto: Look at this: $ file arch/x86/boot/bzImage (tree 821f3eff7cdb9d6c7076effabd46c96c322daed1) arch/x86/boot/bzImage: Linux kernel x86 boot executable zImage, version 2.6.23 ([EMAIL PROTECTED]) #39, RO-rootFS, root_dev 0x803, swap_dev 0x1, Prompt for Videomode I just noticed the same problem when grub refused to load that thing. The issue is that the build system created a zImage (and not a bzImage); even passing the target explicitly doesn't solve the problem. git bisect says: f77bf01425b11947eeb3b5b54685212c302741b8 is first bad commit commit f77bf01425b11947eeb3b5b54685212c302741b8 Author: Sam Ravnborg [EMAIL PROTECTED](none) --- (Ops, you have a problem on you git setup) Date: Mon Oct 15 22:25:06 2007 +0200 kbuild: introduce ccflags-y, asflags-y and ldflags-y Introduce ccflags-y, asflags-y and ldflags-y so we soon can deprecate use of EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. This patch does not touch any in-tree users - thats next round. Lets get this committed first and then fix the users of the soon to be deprecated variants next. The rationale behind this change is to introduce support for makefile fragments like: ccflags-$(CONFIG_WHATEVER_DEBUG) := -DDEBUG As a replacement for the uglier: ifeq ($(CONFIG_WHATEVER_DEBUG),y) EXTRA_CFLAGS := -DDEBUG endif Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] :04 04 03915c7c738eefa31f2327521130df23b7dfe95e e2a1677df3709813ff793fdfa77d80fff9b838a7 M Documentation :04 04 ff4ad149975df39509a18782341f1f8f6a32f07a 663bce3c08a0f2e107cecb0b29edc4fe9d5735a0 M scripts I'm building a x86_64 image, using an external directory (O=...) in case it matters. Bisect log: git-bisect start # bad: [821f3eff7cdb9d6c7076effabd46c96c322daed1] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild git-bisect bad 821f3eff7cdb9d6c7076effabd46c96c322daed1 # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23 git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1 # good: [4d5709a7b7d54fc5882d2943a14988a92d48c00a] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq git-bisect good 4d5709a7b7d54fc5882d2943a14988a92d48c00a # good: [b5869ce7f68b233ceb81465a7644be0d9a5f3dbb] Merge git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched git-bisect good b5869ce7f68b233ceb81465a7644be0d9a5f3dbb # good: [11370ee2c1c578a704f47d5513d57274c335db43] [ALSA] hda-codec: Add two new systems to ALC883 git-bisect good 11370ee2c1c578a704f47d5513d57274c335db43 # good: [05440dfcfcabde6fcf7297dfa5a29f0355b78ffb] rtc-cmos probe() cleanup git-bisect good 05440dfcfcabde6fcf7297dfa5a29f0355b78ffb # good: [f20bf6125605acbbc7eb8c9420d7221c91aa83eb] time: introduce xtime_seconds git-bisect good f20bf6125605acbbc7eb8c9420d7221c91aa83eb # good: [92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0] Merge branch 'for-linus' of git://git.kernel.dk/data/git/linux-2.6-block git-bisect good 92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0 # good: [fc8a327db6c46de783b1a4276d846841b9abc24c] Merge branch 'linus' of master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa git-bisect good fc8a327db6c46de783b1a4276d846841b9abc24c # good: [3b16cc2d4ccc3949455432241fe378448e77d911] kbuild: move Kai Germaschewski to CREDITS git-bisect good 3b16cc2d4ccc3949455432241fe378448e77d911 # good: [2f7055c5932ecc02159be375ebda1eee64665d17] [MIPS] MIPSsim: Fix booting from NFS root git-bisect good 2f7055c5932ecc02159be375ebda1eee64665d17 # good: [52bcc3308ae3344266f55bf98a22c1ac0201eda7] kbuild: enable use of AFLAGS and CFLAGS on commandline git-bisect good 52bcc3308ae3344266f55bf98a22c1ac0201eda7 # good: [8bb00d83d8fc2de5c0614f5d55780107e0c375fe] [MIPS] Increase cp0 compare clockevent min_delta_ns from 0x30 to 0x300. git-bisect good 8bb00d83d8fc2de5c0614f5d55780107e0c375fe # bad: [f77bf01425b11947eeb3b5b54685212c302741b8] kbuild: introduce ccflags-y, asflags-y and ldflags-y git-bisect bad f77bf01425b11947eeb3b5b54685212c302741b8 # good: [06c5040cdb13d27adad118f2fbfae905a1911b37] kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP git-bisect good 06c5040cdb13d27adad118f2fbfae905a1911b37 Luca -- The trouble with computers is that they do what you tell them, not what you want. D. Cohen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hitachi disk: spurious completions during NCQ
Hello, sometimes kernel complains about spurious completions on my new notebook: ata3.00: exception Emask 0x2 SAct 0x407fd SErr 0x0 action 0x2 frozen ata3.00: spurious completions during NCQ issue=0x0 SAct=0x407fd FIS=005040a1:0002 ata3.00: cmd 61/08:00:c7:5a:82/00:00:1b:00:00/40 tag 0 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:10:3f:5b:fa/00:00:18:00:00/40 tag 2 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:18:5f:5b:fa/00:00:18:00:00/40 tag 3 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/18:20:6f:5b:fa/00:00:18:00:00/40 tag 4 cdb 0x0 data 12288 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:28:e7:19:fd/00:00:18:00:00/40 tag 5 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:30:df:59:ae/00:00:1a:00:00/40 tag 6 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:38:3f:5a:ae/00:00:1a:00:00/40 tag 7 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:40:6f:62:ae/00:00:1a:00:00/40 tag 8 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/28:48:d7:59:7e/00:00:1b:00:00/40 tag 9 cdb 0x0 data 20480 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/10:50:07:5b:82/00:00:1b:00:00/40 tag 10 cdb 0x0 data 8192 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/30:90:f7:5a:fa/00:00:18:00:00/40 tag 18 cdb 0x0 data 24576 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 ata3: EH complete sd 2:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA (this is a very recent 2.6.23-git, SMP, x86_64) The disk is: ATA device, with non-removable media Model Number: Hitachi HTS542525K9SA00 Firmware Revision: BBFOC31P The controller is: 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: ASUSTeK Computer Inc. Unknown device 14e7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hitachi disk: spurious completions during NCQ
Hello, sometimes kernel complains about spurious completions on my new notebook: ata3.00: exception Emask 0x2 SAct 0x407fd SErr 0x0 action 0x2 frozen ata3.00: spurious completions during NCQ issue=0x0 SAct=0x407fd FIS=005040a1:0002 ata3.00: cmd 61/08:00:c7:5a:82/00:00:1b:00:00/40 tag 0 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:10:3f:5b:fa/00:00:18:00:00/40 tag 2 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:18:5f:5b:fa/00:00:18:00:00/40 tag 3 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/18:20:6f:5b:fa/00:00:18:00:00/40 tag 4 cdb 0x0 data 12288 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:28:e7:19:fd/00:00:18:00:00/40 tag 5 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:30:df:59:ae/00:00:1a:00:00/40 tag 6 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:38:3f:5a:ae/00:00:1a:00:00/40 tag 7 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:40:6f:62:ae/00:00:1a:00:00/40 tag 8 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/28:48:d7:59:7e/00:00:1b:00:00/40 tag 9 cdb 0x0 data 20480 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/10:50:07:5b:82/00:00:1b:00:00/40 tag 10 cdb 0x0 data 8192 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/30:90:f7:5a:fa/00:00:18:00:00/40 tag 18 cdb 0x0 data 24576 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 ata3: EH complete sd 2:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA (this is a very recent 2.6.23-git, SMP, x86_64) The disk is: ATA device, with non-removable media Model Number: Hitachi HTS542525K9SA00 Firmware Revision: BBFOC31P The controller is: 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: ASUSTeK Computer Inc. Unknown device 14e7 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: 0 Interrupt: pin B routed to IRQ 1272 Region 0: I/O ports at ec00 [size=8] Region 1: I/O ports at e880 [size=4] Region 2: I/O ports at e800 [size=8] Region 3: I/O ports at e480 [size=4] Region 4: I/O ports at e400 [size=32] Region 5: Memory at febff800 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/2 Enable+ Address: fee0300c Data: 41b9 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] #12 [0010] and I'm using AHCI driver. I see that similar disks are already blacklisted, probably this one is bugged too - though the error is pretty rare :( Luca -- Di tutte le perversioni sessuali, la castita` e` la piu` strana. Anatole France - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)
Il Thu, Oct 04, 2007 at 01:32:44AM +0200, Frans Pop ha scritto: > On Wednesday 03 October 2007, you wrote: > > On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: > > > On Wednesday 03 October 2007, you wrote: > > > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > > > > On Wed, 3 Oct 2007, Frans Pop wrote: > > > > > > The only change is in 2 consecutive columns: "2911 502" -> "2912 > > > > > > 500". Is processor usage calculated from those? Can someone > > > > > > explain how? > > > > > > > > > > The latter seems to be utime ...decreasing. No wonder if > > > > > arithmetics will give strange results (probably top is using > > > > > unsigned delta?)... > > > > > > > > Hmm, minor miscounting from my side, stime seems more appropriate... > > > > > > So, is it normal that stime decreases sometimes or a kernel bug? > > > /me expects the last... > > > > Let me guess... Dual core AMD64 ? > > Nope: Intel(R) Pentium(R) D CPU 3.20GHz I just notice the same thing here, with a Core2 Duo (which is supposed to have synced TSCs) and working HPET. > The following may well be relevant. > With 2.6.22 and early 2.6.23-rc kernels (rc3-rc6) I often had this in my > kernel log (see http://lkml.org/lkml/2007/9/16/45): >checking TSC synchronization [CPU#0 -> CPU#1]: >Measured 248 cycles TSC warp between CPUs, turning off TSC clock. >Marking TSC unstable due to check_tsc_sync_source failed I don't see this though, TSCs are always syncronized between the 2 cores. Luca -- Ligabue canta: "Tutti vogliono viaggiare in prim..." Io ci ho provato e dopo un chilometro ho fuso il motore e bruciato la frizione... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)
Il Thu, Oct 04, 2007 at 01:32:44AM +0200, Frans Pop ha scritto: On Wednesday 03 October 2007, you wrote: On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: On Wednesday 03 October 2007, you wrote: On Wed, 3 Oct 2007, Ilpo Järvinen wrote: On Wed, 3 Oct 2007, Frans Pop wrote: The only change is in 2 consecutive columns: 2911 502 - 2912 500. Is processor usage calculated from those? Can someone explain how? The latter seems to be utime ...decreasing. No wonder if arithmetics will give strange results (probably top is using unsigned delta?)... Hmm, minor miscounting from my side, stime seems more appropriate... So, is it normal that stime decreases sometimes or a kernel bug? /me expects the last... Let me guess... Dual core AMD64 ? Nope: Intel(R) Pentium(R) D CPU 3.20GHz I just notice the same thing here, with a Core2 Duo (which is supposed to have synced TSCs) and working HPET. The following may well be relevant. With 2.6.22 and early 2.6.23-rc kernels (rc3-rc6) I often had this in my kernel log (see http://lkml.org/lkml/2007/9/16/45): checking TSC synchronization [CPU#0 - CPU#1]: Measured 248 cycles TSC warp between CPUs, turning off TSC clock. Marking TSC unstable due to check_tsc_sync_source failed I don't see this though, TSCs are always syncronized between the 2 cores. Luca -- Ligabue canta: Tutti vogliono viaggiare in prim... Io ci ho provato e dopo un chilometro ho fuso il motore e bruciato la frizione... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] pata_ali not working on a 64 bit system
Il Fri, Jul 06, 2007 at 10:01:36PM +0200, Luca Tettamanti ha scritto: > Il Fri, Jul 06, 2007 at 06:44:02PM +0100, Alan Cox ha scritto: > > On Fri, 6 Jul 2007 19:36:05 +0200 > > Luca Tettamanti <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > I found out that pata_ali is not working with a 64 bit kernel, while a > > > 32 bit kernel on the same machine works fine. I'm running a very recent > > > kernel (872aad45, somewhere after 2.6.22-rc7). I found out that 2.6.21 works fine. I'll start bisecting unless someone has some clue about this issue. I'm quoting the rest of my mail for reference: > > > The problem is that as soon as the module is loaded I get a screaming > > > interrupt: > > > > Can you report this with a full dmesg to the ACPI maintainers as that is > > where the IRQ routing is presumably coming from. > > Ok, adding linux-acpi to CC. > > > Are you using ACPI on both cases ? > > By default it's enabled, but I've also tried with pci=noacpi without > success. That's why I reported the issue on linux-ide ;) > > To recap, with ACPI enabled: > > 32bit: pata_ali gets IRQ 19, works > 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt 64bit 2.6.21 also gets IRQ 23, but no screaming interrupt. > > With pci=noacpi: > > 32bit: pata_ali gets IRQ 23, works > 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt > > (as a side note: in this case pata_jmicron stops working...) > > When ACPI is enabled IRQ mapping differs between 32 and 64 bit: > > -ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 19 > +ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 23 > > while with pci=noacpi the IRQ mapping for both 32 and 64 bit is the > following: > > PCI: Probing PCI hardware > PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO > PCI quirk: region 0480-04bf claimed by ICH6 GPIO > PCI: Firmware left :05:01.0 e100 interrupts enabled, disabling > PCI: Transparent bridge - :00:1e.0 > PCI: Using IRQ router PIIX/ICH [8086/2810] at :00:1f.0 > PCI->APIC IRQ transform: :00:01.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1a.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1a.1[B] -> IRQ 17 > PCI->APIC IRQ transform: :00:1a.7[C] -> IRQ 18 > PCI->APIC IRQ transform: :00:1b.0[A] -> IRQ 22 > PCI->APIC IRQ transform: :00:1c.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1c.3[D] -> IRQ 19 > PCI->APIC IRQ transform: :00:1c.4[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1d.0[A] -> IRQ 23 > PCI->APIC IRQ transform: :00:1d.1[B] -> IRQ 19 > PCI->APIC IRQ transform: :00:1d.2[C] -> IRQ 18 > PCI->APIC IRQ transform: :00:1d.7[A] -> IRQ 23 > PCI->APIC IRQ transform: :00:1f.2[B] -> IRQ 19 > PCI->APIC IRQ transform: :00:1f.3[C] -> IRQ 18 > PCI->APIC IRQ transform: :01:00.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :03:00.0[A] -> IRQ 19 > PCI->APIC IRQ transform: :02:00.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :02:00.1[B] -> IRQ 16 > PCI->APIC IRQ transform: :05:01.0[A] -> IRQ 22 > PCI->APIC IRQ transform: :05:02.0[A] -> IRQ 23 > PCI->APIC IRQ transform: :05:02.1[A] -> IRQ 23 > PCI->APIC IRQ transform: :05:03.0[A] -> IRQ 21 > > For reference the dmesg for 64 kernel with ACPI enabled is the > following: > > Linux version 2.6.22-rc7-64-g872aad45-dirty ([EMAIL PROTECTED]) (gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #14 SMP PREEMPT Tue Jul 3 > 21:18:19 CEST 2007 > Command line: BOOT_IMAGE=linux-2.6.22-64 ro video=radeonfb:[EMAIL PROTECTED] > lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 > console=ttyS0,57600n8 break=modules > BIOS-provided physical RAM map: > BIOS-e820: - 0009c800 (usable) > BIOS-e820: 0009c800 - 000a (reserved) > BIOS-e820: 000e4000 - 0010 (reserved) > BIOS-e820: 0010 - 3ff9 (usable) > BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) > BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) > BIOS-e820: 3ffe - 4000 (reserved) > BIOS-e820: fee0 - fee01000 (reserved) > BIOS-e820: ffb0 - 0001 (reserved) > end_pfn_map = 1048576 > DMI 2.4 present. > ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) > ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) > ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) > ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06
Re: [BUG] pata_ali not working on a 64 bit system
Il Fri, Jul 06, 2007 at 10:01:36PM +0200, Luca Tettamanti ha scritto: Il Fri, Jul 06, 2007 at 06:44:02PM +0100, Alan Cox ha scritto: On Fri, 6 Jul 2007 19:36:05 +0200 Luca Tettamanti [EMAIL PROTECTED] wrote: Hello, I found out that pata_ali is not working with a 64 bit kernel, while a 32 bit kernel on the same machine works fine. I'm running a very recent kernel (872aad45, somewhere after 2.6.22-rc7). I found out that 2.6.21 works fine. I'll start bisecting unless someone has some clue about this issue. I'm quoting the rest of my mail for reference: The problem is that as soon as the module is loaded I get a screaming interrupt: Can you report this with a full dmesg to the ACPI maintainers as that is where the IRQ routing is presumably coming from. Ok, adding linux-acpi to CC. Are you using ACPI on both cases ? By default it's enabled, but I've also tried with pci=noacpi without success. That's why I reported the issue on linux-ide ;) To recap, with ACPI enabled: 32bit: pata_ali gets IRQ 19, works 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt 64bit 2.6.21 also gets IRQ 23, but no screaming interrupt. With pci=noacpi: 32bit: pata_ali gets IRQ 23, works 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt (as a side note: in this case pata_jmicron stops working...) When ACPI is enabled IRQ mapping differs between 32 and 64 bit: -ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 19 +ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 23 while with pci=noacpi the IRQ mapping for both 32 and 64 bit is the following: PCI: Probing PCI hardware PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 0480-04bf claimed by ICH6 GPIO PCI: Firmware left :05:01.0 e100 interrupts enabled, disabling PCI: Transparent bridge - :00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2810] at :00:1f.0 PCI-APIC IRQ transform: :00:01.0[A] - IRQ 16 PCI-APIC IRQ transform: :00:1a.0[A] - IRQ 16 PCI-APIC IRQ transform: :00:1a.1[B] - IRQ 17 PCI-APIC IRQ transform: :00:1a.7[C] - IRQ 18 PCI-APIC IRQ transform: :00:1b.0[A] - IRQ 22 PCI-APIC IRQ transform: :00:1c.0[A] - IRQ 16 PCI-APIC IRQ transform: :00:1c.3[D] - IRQ 19 PCI-APIC IRQ transform: :00:1c.4[A] - IRQ 16 PCI-APIC IRQ transform: :00:1d.0[A] - IRQ 23 PCI-APIC IRQ transform: :00:1d.1[B] - IRQ 19 PCI-APIC IRQ transform: :00:1d.2[C] - IRQ 18 PCI-APIC IRQ transform: :00:1d.7[A] - IRQ 23 PCI-APIC IRQ transform: :00:1f.2[B] - IRQ 19 PCI-APIC IRQ transform: :00:1f.3[C] - IRQ 18 PCI-APIC IRQ transform: :01:00.0[A] - IRQ 16 PCI-APIC IRQ transform: :03:00.0[A] - IRQ 19 PCI-APIC IRQ transform: :02:00.0[A] - IRQ 16 PCI-APIC IRQ transform: :02:00.1[B] - IRQ 16 PCI-APIC IRQ transform: :05:01.0[A] - IRQ 22 PCI-APIC IRQ transform: :05:02.0[A] - IRQ 23 PCI-APIC IRQ transform: :05:02.1[A] - IRQ 23 PCI-APIC IRQ transform: :05:03.0[A] - IRQ 21 For reference the dmesg for 64 kernel with ACPI enabled is the following: Linux version 2.6.22-rc7-64-g872aad45-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #14 SMP PREEMPT Tue Jul 3 21:18:19 CEST 2007 Command line: BOOT_IMAGE=linux-2.6.22-64 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 break=modules BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 156 0: 256 - 262032 ACPI: PM-Timer IO Port: 0x808 ACPI
Re: Linux 2.6.23-rc4: BAD regression
Il Wed, Aug 29, 2007 at 01:29:56AM +0200, Daniel Ritz ha scritto: > tried that one on my old toshiba tecra 8000 laptop, almost killing it. > the fan doesn't work any more...type 'make' and see the box dying. > luckily my CPU doesn't commit suicide...bisected it to that one: > > cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b is first bad commit I've just bisected down to the same commit. In my case the fan is locked at maximum speed and the system is *extremly* slow (some kind of throttling?). Alexey, I've seen the patch, I'll test it tomorrow and report back. Luca -- Tentare e` il primo passo verso il fallimento. Homer J. Simpson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc4: BAD regression
Il Wed, Aug 29, 2007 at 01:29:56AM +0200, Daniel Ritz ha scritto: tried that one on my old toshiba tecra 8000 laptop, almost killing it. the fan doesn't work any more...type 'make' and see the box dying. luckily my CPU doesn't commit suicide...bisected it to that one: cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b is first bad commit I've just bisected down to the same commit. In my case the fan is locked at maximum speed and the system is *extremly* slow (some kind of throttling?). Alexey, I've seen the patch, I'll test it tomorrow and report back. Luca -- Tentare e` il primo passo verso il fallimento. Homer J. Simpson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/4] 2.6.23-rc3: known regressions
Michal Piotrowski ha scritto: > Hi all, > > Here is a list of some known regressions in 2.6.23-rc3. > > Feel free to add new regressions/remove fixed etc. > http://kernelnewbies.org/known_regressions [...] > > Subject : FATAL: drivers/acpi/video: sizeof(struct acpi_device_id)=20 > is not a modulo of the size of section __mod_acpi_device_table=48 > References : http://lkml.org/lkml/2007/8/13/584 > Last known good : ? > Submitter : Kamalesh Babulal <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : ? > Status : unknown Hi Michal, this is the same as: Modpost Subject : modpost bug breaks ia64 cross compilation References : http://lkml.org/lkml/2007/7/27/30 http://lkml.org/lkml/2007/7/27/418 Last known good : ? Submitter : Jan Dittmer <[EMAIL PROTECTED]> Caused-By : Thomas Renninger <[EMAIL PROTECTED]> commit 29b71a1ca74491fab9fed09e9d835d840d042690 Handled-By : ? Patch : http://lkml.org/lkml/2007/8/2/211 Status : patch was suggested It affects every cross-compilaton from 32 bit host (e.g. x86) to a 64 bit target (e.g. x86_64) and (AFAICS, I haven't tried) vice versa. Very annoying :| Luca -- "New processes are created by other processes, just like new humans. New humans are created by other humans, of course, not by processes." -- Unix System Administration Handbook - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/4] 2.6.23-rc3: known regressions
Michal Piotrowski ha scritto: Hi all, Here is a list of some known regressions in 2.6.23-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions [...] Subject : FATAL: drivers/acpi/video: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=48 References : http://lkml.org/lkml/2007/8/13/584 Last known good : ? Submitter : Kamalesh Babulal [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown Hi Michal, this is the same as: Modpost Subject : modpost bug breaks ia64 cross compilation References : http://lkml.org/lkml/2007/7/27/30 http://lkml.org/lkml/2007/7/27/418 Last known good : ? Submitter : Jan Dittmer [EMAIL PROTECTED] Caused-By : Thomas Renninger [EMAIL PROTECTED] commit 29b71a1ca74491fab9fed09e9d835d840d042690 Handled-By : ? Patch : http://lkml.org/lkml/2007/8/2/211 Status : patch was suggested It affects every cross-compilaton from 32 bit host (e.g. x86) to a 64 bit target (e.g. x86_64) and (AFAICS, I haven't tried) vice versa. Very annoying :| Luca -- New processes are created by other processes, just like new humans. New humans are created by other humans, of course, not by processes. -- Unix System Administration Handbook - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] UML - Simplify helper stack handling
Il Wed, Jun 27, 2007 at 11:37:01PM -0700, Andrew Morton ha scritto: > > So I'm running the generic version of this on i386 with 8k stacks (below), > with a quick LTP run. > > Holy cow, either we use a _lot_ of stack or these numbers are off: > > vmm:/home/akpm> dmesg -s 100|grep 'bytes left' > khelper used greatest stack depth: 7176 bytes left > khelper used greatest stack depth: 7064 bytes left > khelper used greatest stack depth: 6840 bytes left > khelper used greatest stack depth: 6812 bytes left > hostname used greatest stack depth: 6636 bytes left > uname used greatest stack depth: 6592 bytes left > uname used greatest stack depth: 6284 bytes left > hotplug used greatest stack depth: 5568 bytes left > rpc.nfsd used greatest stack depth: 5136 bytes left > chown02 used greatest stack depth: 4956 bytes left > fchown01 used greatest stack depth: 4892 bytes left > > That's the sum of process stack and interrupt stack, but I doubt if this > little box is using much interrupt stack space. > > No wonder people are still getting stack overflows with 4k stacks... Hi Andrew, I was a bit worried about stack usage on my setup and google found your mail :P FYI: khelper used greatest stack depth: 3228 bytes left khelper used greatest stack depth: 3124 bytes left busybox used greatest stack depth: 2808 bytes left modprobe used greatest stack depth: 2744 bytes left busybox used greatest stack depth: 2644 bytes left modprobe used greatest stack depth: 1836 bytes left modprobe used greatest stack depth: 1176 bytes left java used greatest stack depth: 932 bytes left java used greatest stack depth: 540 bytes left I'm running git-current, with 4KiB stacks; filesystems are ext3 and XFS on LVM (on libata devices). Does it make sense to raise STACK_WARN to get a stack trace in do_IRQ? Or is 540 bytes still "safe" taking into account the separate IRQ stack? Luca -- 42 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] UML - Simplify helper stack handling
Il Wed, Jun 27, 2007 at 11:37:01PM -0700, Andrew Morton ha scritto: So I'm running the generic version of this on i386 with 8k stacks (below), with a quick LTP run. Holy cow, either we use a _lot_ of stack or these numbers are off: vmm:/home/akpm dmesg -s 100|grep 'bytes left' khelper used greatest stack depth: 7176 bytes left khelper used greatest stack depth: 7064 bytes left khelper used greatest stack depth: 6840 bytes left khelper used greatest stack depth: 6812 bytes left hostname used greatest stack depth: 6636 bytes left uname used greatest stack depth: 6592 bytes left uname used greatest stack depth: 6284 bytes left hotplug used greatest stack depth: 5568 bytes left rpc.nfsd used greatest stack depth: 5136 bytes left chown02 used greatest stack depth: 4956 bytes left fchown01 used greatest stack depth: 4892 bytes left That's the sum of process stack and interrupt stack, but I doubt if this little box is using much interrupt stack space. No wonder people are still getting stack overflows with 4k stacks... Hi Andrew, I was a bit worried about stack usage on my setup and google found your mail :P FYI: khelper used greatest stack depth: 3228 bytes left khelper used greatest stack depth: 3124 bytes left busybox used greatest stack depth: 2808 bytes left modprobe used greatest stack depth: 2744 bytes left busybox used greatest stack depth: 2644 bytes left modprobe used greatest stack depth: 1836 bytes left modprobe used greatest stack depth: 1176 bytes left java used greatest stack depth: 932 bytes left java used greatest stack depth: 540 bytes left I'm running git-current, with 4KiB stacks; filesystems are ext3 and XFS on LVM (on libata devices). Does it make sense to raise STACK_WARN to get a stack trace in do_IRQ? Or is 540 bytes still safe taking into account the separate IRQ stack? Luca -- 42 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] - SN: Add support for CPU disable
Hi,
I've a couple of comments on the patch:
John Keller <[EMAIL PROTECTED]> ha scritto:
> Index: linux-2.6/arch/ia64/sn/kernel/huberror.c
> ===
> --- linux-2.6.orig/arch/ia64/sn/kernel/huberror.c 2007-07-31
> 09:09:55.414522005 -0500
> +++ linux-2.6/arch/ia64/sn/kernel/huberror.c2007-07-31 09:38:14.634045360
> -0500
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include "xtalk/xwidgetdev.h"
> #include "xtalk/hubdev.h"
> #include
> @@ -185,11 +186,22 @@ void hubiio_crb_error_handler(struct hub
> */
> void hub_error_init(struct hubdev_info *hubdev_info)
> {
> +
>if (request_irq(SGI_II_ERROR, hub_eint_handler, IRQF_SHARED,
> - "SN_hub_error", (void *)hubdev_info))
> + "SN_hub_error", (void *)hubdev_info)) {
>printk("hub_error_init: Failed to request_irq for 0x%p\n",
>hubdev_info);
> - return;
> + return;
> + }
> +
> +#ifdef CONFIG_SMP
> + /*
> +* On systems which support CPU disabling (SHub2), all error
> interrupts
> +* are targetted at the boot CPU.
> +*/
> + if (is_shub2() && sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
> + set_irq_affinity_info(SGI_II_ERROR, 0, 0);
> +#endif
This snippet is repeated many times. You may want to use an inline
helper (defined as no-op for !CONFIG_SMP), something like this:
#ifdef CONFIG_SMP
static inline void migrate_error_int(void)
{
/*
* On systems which support CPU disabling (SHub2), all error interrupts
* are targetted at the boot CPU.
*/
if (is_shub2() && sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
set_irq_affinity_info(SGI_II_ERROR, 0, 0);
}
#else
static inline void migrate_error_int(void) { }
#endif
As as bonus you remove the #ifdef from the main code.
> --- linux-2.6.orig/arch/ia64/sn/kernel/sn2/sn2_smp.c2007-07-31
> 09:09:55.418522496 -0500
> +++ linux-2.6/arch/ia64/sn/kernel/sn2/sn2_smp.c 2007-07-31 09:38:14.782063615
> -0500
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> DEFINE_PER_CPU(struct ptc_stats, ptcstats);
> DECLARE_PER_CPU(struct ptc_stats, ptcstats);
> @@ -429,6 +430,29 @@ void sn2_send_IPI(int cpuid, int vector,
>sn_send_IPI_phys(nasid, physid, vector, delivery_mode);
> }
>
> +#ifdef CONFIG_HOTPLUG_CPU
> +/**
> + * sn_cpu_disable_allowed - Determine if a CPU can be disabled.
> + * @cpu - CPU that is requested to be disabled.
> + *
> + * CPU disable is only allowed on SHub2 systems running with a PROM
> + * that supports CPU disable. It is not permitted to disable the boot
> processor.
> + */
> +bool sn_cpu_disable_allowed(int cpu)
> +{
> + if (is_shub2() && sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
> + if (cpu != 0)
> + return true;
> + else
> + printk("Disabling the boot processor is not
> allowed.\n");
> +
> + else
Hum, brackets around the inner if statement?
Luca
--
Let me make your mind, leave yourself behind
Be not afraid
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] - SN: Add support for CPU disable
Hi,
I've a couple of comments on the patch:
John Keller [EMAIL PROTECTED] ha scritto:
Index: linux-2.6/arch/ia64/sn/kernel/huberror.c
===
--- linux-2.6.orig/arch/ia64/sn/kernel/huberror.c 2007-07-31
09:09:55.414522005 -0500
+++ linux-2.6/arch/ia64/sn/kernel/huberror.c2007-07-31 09:38:14.634045360
-0500
@@ -14,6 +14,7 @@
#include asm/sn/addrs.h
#include asm/sn/shubio.h
#include asm/sn/geo.h
+#include asm/sn/sn_feature_sets.h
#include xtalk/xwidgetdev.h
#include xtalk/hubdev.h
#include asm/sn/bte.h
@@ -185,11 +186,22 @@ void hubiio_crb_error_handler(struct hub
*/
void hub_error_init(struct hubdev_info *hubdev_info)
{
+
if (request_irq(SGI_II_ERROR, hub_eint_handler, IRQF_SHARED,
- SN_hub_error, (void *)hubdev_info))
+ SN_hub_error, (void *)hubdev_info)) {
printk(hub_error_init: Failed to request_irq for 0x%p\n,
hubdev_info);
- return;
+ return;
+ }
+
+#ifdef CONFIG_SMP
+ /*
+* On systems which support CPU disabling (SHub2), all error
interrupts
+* are targetted at the boot CPU.
+*/
+ if (is_shub2() sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
+ set_irq_affinity_info(SGI_II_ERROR, 0, 0);
+#endif
This snippet is repeated many times. You may want to use an inline
helper (defined as no-op for !CONFIG_SMP), something like this:
#ifdef CONFIG_SMP
static inline void migrate_error_int(void)
{
/*
* On systems which support CPU disabling (SHub2), all error interrupts
* are targetted at the boot CPU.
*/
if (is_shub2() sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
set_irq_affinity_info(SGI_II_ERROR, 0, 0);
}
#else
static inline void migrate_error_int(void) { }
#endif
As as bonus you remove the #ifdef from the main code.
--- linux-2.6.orig/arch/ia64/sn/kernel/sn2/sn2_smp.c2007-07-31
09:09:55.418522496 -0500
+++ linux-2.6/arch/ia64/sn/kernel/sn2/sn2_smp.c 2007-07-31 09:38:14.782063615
-0500
@@ -40,6 +40,7 @@
#include asm/sn/shub_mmr.h
#include asm/sn/nodepda.h
#include asm/sn/rw_mmr.h
+#include asm/sn/sn_feature_sets.h
DEFINE_PER_CPU(struct ptc_stats, ptcstats);
DECLARE_PER_CPU(struct ptc_stats, ptcstats);
@@ -429,6 +430,29 @@ void sn2_send_IPI(int cpuid, int vector,
sn_send_IPI_phys(nasid, physid, vector, delivery_mode);
}
+#ifdef CONFIG_HOTPLUG_CPU
+/**
+ * sn_cpu_disable_allowed - Determine if a CPU can be disabled.
+ * @cpu - CPU that is requested to be disabled.
+ *
+ * CPU disable is only allowed on SHub2 systems running with a PROM
+ * that supports CPU disable. It is not permitted to disable the boot
processor.
+ */
+bool sn_cpu_disable_allowed(int cpu)
+{
+ if (is_shub2() sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
+ if (cpu != 0)
+ return true;
+ else
+ printk(Disabling the boot processor is not
allowed.\n);
+
+ else
Hum, brackets around the inner if statement?
Luca
--
Let me make your mind, leave yourself behind
Be not afraid
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6.22] edac: sleeping function called from invalid context
Hi, as soon as I enable parity check on PCI bus (with polling - EDAC_POLL), the following warning is triggered: EDAC MC: Ver: 2.0.1 Jul 13 2007 BUG: sleeping function called from invalid context at /home/kronos/src/linux-2.6.git/kernel/rwsem.c:20 in_atomic():0, irqs_disabled():1 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<>] 0x0 hardirqs last disabled at (0): [] copy_process+0x363/0x11e8 softirqs last enabled at (0): [] copy_process+0x363/0x11e8 softirqs last disabled at (0): [<>] 0x0 [] down_read+0x15/0x49 [] schedule_timeout+0x79/0x8d [] pci_get_subsys+0x68/0xea [] process_timeout+0x0/0x5 [] pci_get_device+0x16/0x19 [] edac_kernel_thread+0x94/0x10c [edac_mc] [] edac_kernel_thread+0x0/0x10c [edac_mc] [] kthread+0x38/0x60 [] kthread+0x0/0x60 [] kernel_thread_helper+0x7/0x10 === The warning is caused by the fact that do_pci_parity_check() calls edac_pci_dev_parity_iterator() with interrupts disabled and pci_get_device acquires pci_bus_sem (via pci_get_subsys). Luca -- "La mia teoria scientifica preferita e` quella secondo la quale gli anelli di Saturno sarebbero interamente composti dai bagagli andati persi nei viaggi aerei." -- Mark Russel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22] edac: sleeping function called from invalid context
Hi, as soon as I enable parity check on PCI bus (with polling - EDAC_POLL), the following warning is triggered: EDAC MC: Ver: 2.0.1 Jul 13 2007 BUG: sleeping function called from invalid context at /home/kronos/src/linux-2.6.git/kernel/rwsem.c:20 in_atomic():0, irqs_disabled():1 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [] 0x0 hardirqs last disabled at (0): [c0120063] copy_process+0x363/0x11e8 softirqs last enabled at (0): [c0120063] copy_process+0x363/0x11e8 softirqs last disabled at (0): [] 0x0 [c0134fb2] down_read+0x15/0x49 [c02f4669] schedule_timeout+0x79/0x8d [c01deef0] pci_get_subsys+0x68/0xea [c01298a4] process_timeout+0x0/0x5 [c01def88] pci_get_device+0x16/0x19 [fa4b98cd] edac_kernel_thread+0x94/0x10c [edac_mc] [fa4b9839] edac_kernel_thread+0x0/0x10c [edac_mc] [c0132264] kthread+0x38/0x60 [c013222c] kthread+0x0/0x60 [c0104ae7] kernel_thread_helper+0x7/0x10 === The warning is caused by the fact that do_pci_parity_check() calls edac_pci_dev_parity_iterator() with interrupts disabled and pci_get_device acquires pci_bus_sem (via pci_get_subsys). Luca -- La mia teoria scientifica preferita e` quella secondo la quale gli anelli di Saturno sarebbero interamente composti dai bagagli andati persi nei viaggi aerei. -- Mark Russel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] some kmalloc/memset ->kzalloc (tree wide)
Yoann Padioleau <[EMAIL PROTECTED]> ha scritto:
>
> Transform some calls to kmalloc/memset to a single kzalloc (or kcalloc).
[...]
> diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
> index bd03dc9..026ba9a 100644
> --- a/arch/alpha/kernel/module.c
> +++ b/arch/alpha/kernel/module.c
> @@ -119,8 +119,7 @@ module_frob_arch_sections(Elf64_Ehdr *hd
> }
>
> nsyms = symtab->sh_size / sizeof(Elf64_Sym);
> - chains = kmalloc(nsyms * sizeof(struct got_entry), GFP_KERNEL);
> - memset(chains, 0, nsyms * sizeof(struct got_entry));
> + chains = kcalloc(nsyms, sizeof(struct got_entry), GFP_KERNEL);
>
> got->sh_size = 0;
> got->sh_addralign = 8;
Unrelated to the conversion, but here Alpha module loader is
dereferencing 'chains' without checking the outcome of the kmalloc().
> diff --git a/drivers/char/rio/riotable.c b/drivers/char/rio/riotable.c
> index 7e98835..991119c 100644
> --- a/drivers/char/rio/riotable.c
> +++ b/drivers/char/rio/riotable.c
> @@ -863,8 +863,7 @@ int RIOReMapPorts(struct rio_info *p, st
> if (PortP->TxRingBuffer)
> memset(PortP->TxRingBuffer, 0, p->RIOBufferSize);
> else if (p->RIOBufferSize) {
> - PortP->TxRingBuffer = kmalloc(p->RIOBufferSize,
> GFP_KERNEL);
> - memset(PortP->TxRingBuffer, 0, p->RIOBufferSize);
> + PortP->TxRingBuffer = kzalloc(p->RIOBufferSize,
> GFP_KERNEL);
> }
> PortP->TxBufferOut = 0;
> PortP->TxBufferIn = 0;
Same here.
> diff --git a/drivers/char/synclinkmp.c b/drivers/char/synclinkmp.c
> index ef93d05..e2847bd 100644
> --- a/drivers/char/synclinkmp.c
> +++ b/drivers/char/synclinkmp.c
> @@ -3794,14 +3794,13 @@ static SLMP_INFO *alloc_dev(int adapter_
> {
> SLMP_INFO *info;
>
> - info = kmalloc(sizeof(SLMP_INFO),
> + info = kzalloc(sizeof(SLMP_INFO),
>GFP_KERNEL);
Funny indentation :)
> diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
> index f8e1a13..d409f67 100644
> --- a/drivers/macintosh/smu.c
> +++ b/drivers/macintosh/smu.c
> @@ -1053,10 +1053,9 @@ static int smu_open(struct inode *inode,
> struct smu_private *pp;
> unsigned long flags;
>
> - pp = kmalloc(sizeof(struct smu_private), GFP_KERNEL);
> + pp = kzalloc(sizeof(struct smu_private), GFP_KERNEL);
> if (pp == 0)
> return -ENOMEM;
s/0/NULL/
> - memset(pp, 0, sizeof(struct smu_private));
> spin_lock_init(>lock);
> pp->mode = smu_file_commands;
> init_waitqueue_head(>wait);
> diff --git a/drivers/macintosh/therm_windtunnel.c
> b/drivers/macintosh/therm_windtunnel.c
> index 3d0354e..5452da1 100644
> --- a/drivers/macintosh/therm_windtunnel.c
> +++ b/drivers/macintosh/therm_windtunnel.c
> @@ -431,9 +431,8 @@ do_probe( struct i2c_adapter *adapter, i
>| I2C_FUNC_SMBUS_WRITE_BYTE) )
> return 0;
>
> - if( !(cl=kmalloc(sizeof(*cl), GFP_KERNEL)) )
> + if( !(cl=kzalloc(sizeof(*cl), GFP_KERNEL)) )
> return -ENOMEM;
> - memset( cl, 0, sizeof(struct i2c_client) );
This - following the common style - should be:
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
return -ENOMEM;
> diff --git a/drivers/media/dvb/cinergyT2/cinergyT2.c
> b/drivers/media/dvb/cinergyT2/cinergyT2.c
> index b40af48..cff3468 100644
> --- a/drivers/media/dvb/cinergyT2/cinergyT2.c
> +++ b/drivers/media/dvb/cinergyT2/cinergyT2.c
> @@ -905,12 +905,11 @@ static int cinergyt2_probe (struct usb_i
> struct cinergyt2 *cinergyt2;
> int err;
>
> - if (!(cinergyt2 = kmalloc (sizeof(struct cinergyt2), GFP_KERNEL))) {
> + if (!(cinergyt2 = kzalloc (sizeof(struct cinergyt2), GFP_KERNEL))) {
> dprintk(1, "out of memory?!?\n");
> return -ENOMEM;
> }
Ditto.
> diff --git a/drivers/media/video/planb.c b/drivers/media/video/planb.c
> index 1455a8f..4ab1af7 100644
> --- a/drivers/media/video/planb.c
> +++ b/drivers/media/video/planb.c
> @@ -353,9 +353,8 @@ static int planb_prepare_open(struct pla
> * PLANB_DUMMY)*sizeof(struct dbdma_cmd)
> +(PLANB_MAXLINES*((PLANB_MAXPIXELS+7)& ~7))/8
> +MAX_GBUFFERS*sizeof(unsigned int);
> - if ((pb->priv_space = kmalloc (size, GFP_KERNEL)) == 0)
> + if ((pb->priv_space = kzalloc (size, GFP_KERNEL)) == 0)
> return -ENOMEM;
Ditto.
> - memset ((void *) pb->priv_space, 0, size);
> pb->overlay_last1 = pb->ch1_cmd = (volatile struct dbdma_cmd *)
> DBDMA_ALIGN (pb->priv_space);
> pb->overlay_last2 = pb->ch2_cmd = pb->ch1_cmd + pb->tab_size;
> diff --git a/drivers/media/video/usbvideo/vicam.c
> b/drivers/media/video/usbvideo/vicam.c
> index 982b115..40ee5e5 100644
> --- a/drivers/media/video/usbvideo/vicam.c
> +++ b/drivers/media/video/usbvideo/vicam.c
> @@
Re: [PATCH] some kmalloc/memset -kzalloc (tree wide)
Yoann Padioleau [EMAIL PROTECTED] ha scritto:
Transform some calls to kmalloc/memset to a single kzalloc (or kcalloc).
[...]
diff --git a/arch/alpha/kernel/module.c b/arch/alpha/kernel/module.c
index bd03dc9..026ba9a 100644
--- a/arch/alpha/kernel/module.c
+++ b/arch/alpha/kernel/module.c
@@ -119,8 +119,7 @@ module_frob_arch_sections(Elf64_Ehdr *hd
}
nsyms = symtab-sh_size / sizeof(Elf64_Sym);
- chains = kmalloc(nsyms * sizeof(struct got_entry), GFP_KERNEL);
- memset(chains, 0, nsyms * sizeof(struct got_entry));
+ chains = kcalloc(nsyms, sizeof(struct got_entry), GFP_KERNEL);
got-sh_size = 0;
got-sh_addralign = 8;
Unrelated to the conversion, but here Alpha module loader is
dereferencing 'chains' without checking the outcome of the kmalloc().
diff --git a/drivers/char/rio/riotable.c b/drivers/char/rio/riotable.c
index 7e98835..991119c 100644
--- a/drivers/char/rio/riotable.c
+++ b/drivers/char/rio/riotable.c
@@ -863,8 +863,7 @@ int RIOReMapPorts(struct rio_info *p, st
if (PortP-TxRingBuffer)
memset(PortP-TxRingBuffer, 0, p-RIOBufferSize);
else if (p-RIOBufferSize) {
- PortP-TxRingBuffer = kmalloc(p-RIOBufferSize,
GFP_KERNEL);
- memset(PortP-TxRingBuffer, 0, p-RIOBufferSize);
+ PortP-TxRingBuffer = kzalloc(p-RIOBufferSize,
GFP_KERNEL);
}
PortP-TxBufferOut = 0;
PortP-TxBufferIn = 0;
Same here.
diff --git a/drivers/char/synclinkmp.c b/drivers/char/synclinkmp.c
index ef93d05..e2847bd 100644
--- a/drivers/char/synclinkmp.c
+++ b/drivers/char/synclinkmp.c
@@ -3794,14 +3794,13 @@ static SLMP_INFO *alloc_dev(int adapter_
{
SLMP_INFO *info;
- info = kmalloc(sizeof(SLMP_INFO),
+ info = kzalloc(sizeof(SLMP_INFO),
GFP_KERNEL);
Funny indentation :)
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index f8e1a13..d409f67 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -1053,10 +1053,9 @@ static int smu_open(struct inode *inode,
struct smu_private *pp;
unsigned long flags;
- pp = kmalloc(sizeof(struct smu_private), GFP_KERNEL);
+ pp = kzalloc(sizeof(struct smu_private), GFP_KERNEL);
if (pp == 0)
return -ENOMEM;
s/0/NULL/
- memset(pp, 0, sizeof(struct smu_private));
spin_lock_init(pp-lock);
pp-mode = smu_file_commands;
init_waitqueue_head(pp-wait);
diff --git a/drivers/macintosh/therm_windtunnel.c
b/drivers/macintosh/therm_windtunnel.c
index 3d0354e..5452da1 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -431,9 +431,8 @@ do_probe( struct i2c_adapter *adapter, i
| I2C_FUNC_SMBUS_WRITE_BYTE) )
return 0;
- if( !(cl=kmalloc(sizeof(*cl), GFP_KERNEL)) )
+ if( !(cl=kzalloc(sizeof(*cl), GFP_KERNEL)) )
return -ENOMEM;
- memset( cl, 0, sizeof(struct i2c_client) );
This - following the common style - should be:
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
return -ENOMEM;
diff --git a/drivers/media/dvb/cinergyT2/cinergyT2.c
b/drivers/media/dvb/cinergyT2/cinergyT2.c
index b40af48..cff3468 100644
--- a/drivers/media/dvb/cinergyT2/cinergyT2.c
+++ b/drivers/media/dvb/cinergyT2/cinergyT2.c
@@ -905,12 +905,11 @@ static int cinergyt2_probe (struct usb_i
struct cinergyt2 *cinergyt2;
int err;
- if (!(cinergyt2 = kmalloc (sizeof(struct cinergyt2), GFP_KERNEL))) {
+ if (!(cinergyt2 = kzalloc (sizeof(struct cinergyt2), GFP_KERNEL))) {
dprintk(1, out of memory?!?\n);
return -ENOMEM;
}
Ditto.
diff --git a/drivers/media/video/planb.c b/drivers/media/video/planb.c
index 1455a8f..4ab1af7 100644
--- a/drivers/media/video/planb.c
+++ b/drivers/media/video/planb.c
@@ -353,9 +353,8 @@ static int planb_prepare_open(struct pla
* PLANB_DUMMY)*sizeof(struct dbdma_cmd)
+(PLANB_MAXLINES*((PLANB_MAXPIXELS+7) ~7))/8
+MAX_GBUFFERS*sizeof(unsigned int);
- if ((pb-priv_space = kmalloc (size, GFP_KERNEL)) == 0)
+ if ((pb-priv_space = kzalloc (size, GFP_KERNEL)) == 0)
return -ENOMEM;
Ditto.
- memset ((void *) pb-priv_space, 0, size);
pb-overlay_last1 = pb-ch1_cmd = (volatile struct dbdma_cmd *)
DBDMA_ALIGN (pb-priv_space);
pb-overlay_last2 = pb-ch2_cmd = pb-ch1_cmd + pb-tab_size;
diff --git a/drivers/media/video/usbvideo/vicam.c
b/drivers/media/video/usbvideo/vicam.c
index 982b115..40ee5e5 100644
--- a/drivers/media/video/usbvideo/vicam.c
+++ b/drivers/media/video/usbvideo/vicam.c
@@ -1305,13 +1305,12 @@ vicam_probe( struct usb_interface *intf,
}
if ((cam =
- kmalloc(sizeof (struct
[PATCH] Enable legacy support for serial ports when SERIAL_8250_PNP is disabled
Hi Bjorn,
your patch:
commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26
Author: Bjorn Helgaas <[EMAIL PROTECTED]>
Date: Tue May 8 00:36:07 2007 -0700
x86, serial: convert legacy COM ports to platform devices
disables probing using legacy code in favour of ACPI/PNP to avoid double
discovery.
However if SERIAL_8250_PNP is not enabled the user is left without
serial ports (been there, done that - my kernel config suddenly wasn't
working anymore). So:
Enable probing of serial ports using legacy code when PNP code
(SERIAL_8250_PNP) is not enabled.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
---
arch/i386/kernel/legacy_serial.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/i386/kernel/legacy_serial.c b/arch/i386/kernel/legacy_serial.c
index 2151011..457d307 100644
--- a/arch/i386/kernel/legacy_serial.c
+++ b/arch/i386/kernel/legacy_serial.c
@@ -48,7 +48,11 @@ static struct platform_device x86_com_device = {
},
};
+#ifndef CONFIG_SERIAL_8250_PNP
+static int force_legacy_probe = 1;
+#else
static int force_legacy_probe;
+#endif
module_param_named(force, force_legacy_probe, bool, 0);
MODULE_PARM_DESC(force, "Force legacy serial port probe");
Luca
--
La vispa candela bruciava l'erbetta
creando un'essenza alquanto sospetta;
sembrava l'odore di una sacrestia
ma presto mi accorsi che era maria.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Enable legacy support for serial ports when SERIAL_8250_PNP is disabled
Hi Bjorn,
your patch:
commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26
Author: Bjorn Helgaas [EMAIL PROTECTED]
Date: Tue May 8 00:36:07 2007 -0700
x86, serial: convert legacy COM ports to platform devices
disables probing using legacy code in favour of ACPI/PNP to avoid double
discovery.
However if SERIAL_8250_PNP is not enabled the user is left without
serial ports (been there, done that - my kernel config suddenly wasn't
working anymore). So:
Enable probing of serial ports using legacy code when PNP code
(SERIAL_8250_PNP) is not enabled.
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
---
arch/i386/kernel/legacy_serial.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/i386/kernel/legacy_serial.c b/arch/i386/kernel/legacy_serial.c
index 2151011..457d307 100644
--- a/arch/i386/kernel/legacy_serial.c
+++ b/arch/i386/kernel/legacy_serial.c
@@ -48,7 +48,11 @@ static struct platform_device x86_com_device = {
},
};
+#ifndef CONFIG_SERIAL_8250_PNP
+static int force_legacy_probe = 1;
+#else
static int force_legacy_probe;
+#endif
module_param_named(force, force_legacy_probe, bool, 0);
MODULE_PARM_DESC(force, Force legacy serial port probe);
Luca
--
La vispa candela bruciava l'erbetta
creando un'essenza alquanto sospetta;
sembrava l'odore di una sacrestia
ma presto mi accorsi che era maria.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] pata_ali not working on a 64 bit system
Il Fri, Jul 06, 2007 at 06:44:02PM +0100, Alan Cox ha scritto: > On Fri, 6 Jul 2007 19:36:05 +0200 > Luca Tettamanti <[EMAIL PROTECTED]> wrote: > > > Hello, > > I found out that pata_ali is not working with a 64 bit kernel, while a > > 32 bit kernel on the same machine works fine. I'm running a very recent > > kernel (872aad45, somewhere after 2.6.22-rc7). > > > > The problem is that as soon as the module is loaded I get a screaming > > interrupt: > > Can you report this with a full dmesg to the ACPI maintainers as that is > where the IRQ routing is presumably coming from. Ok, adding linux-acpi to CC. > Are you using ACPI on both cases ? By default it's enabled, but I've also tried with pci=noacpi without success. That's why I reported the issue on linux-ide ;) To recap, with ACPI enabled: 32bit: pata_ali gets IRQ 19, works 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt With pci=noacpi: 32bit: pata_ali gets IRQ 23, works 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt (as a side note: in this case pata_jmicron stops working...) When ACPI is enabled IRQ mapping differs between 32 and 64 bit: -ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 19 +ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 23 while with pci=noacpi the IRQ mapping for both 32 and 64 bit is the following: PCI: Probing PCI hardware PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 0480-04bf claimed by ICH6 GPIO PCI: Firmware left :05:01.0 e100 interrupts enabled, disabling PCI: Transparent bridge - :00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2810] at :00:1f.0 PCI->APIC IRQ transform: :00:01.0[A] -> IRQ 16 PCI->APIC IRQ transform: :00:1a.0[A] -> IRQ 16 PCI->APIC IRQ transform: :00:1a.1[B] -> IRQ 17 PCI->APIC IRQ transform: :00:1a.7[C] -> IRQ 18 PCI->APIC IRQ transform: :00:1b.0[A] -> IRQ 22 PCI->APIC IRQ transform: :00:1c.0[A] -> IRQ 16 PCI->APIC IRQ transform: :00:1c.3[D] -> IRQ 19 PCI->APIC IRQ transform: :00:1c.4[A] -> IRQ 16 PCI->APIC IRQ transform: :00:1d.0[A] -> IRQ 23 PCI->APIC IRQ transform: :00:1d.1[B] -> IRQ 19 PCI->APIC IRQ transform: :00:1d.2[C] -> IRQ 18 PCI->APIC IRQ transform: :00:1d.7[A] -> IRQ 23 PCI->APIC IRQ transform: :00:1f.2[B] -> IRQ 19 PCI->APIC IRQ transform: :00:1f.3[C] -> IRQ 18 PCI->APIC IRQ transform: :01:00.0[A] -> IRQ 16 PCI->APIC IRQ transform: :03:00.0[A] -> IRQ 19 PCI->APIC IRQ transform: :02:00.0[A] -> IRQ 16 PCI->APIC IRQ transform: :02:00.1[B] -> IRQ 16 PCI->APIC IRQ transform: :05:01.0[A] -> IRQ 22 PCI->APIC IRQ transform: :05:02.0[A] -> IRQ 23 PCI->APIC IRQ transform: :05:02.1[A] -> IRQ 23 PCI->APIC IRQ transform: :05:03.0[A] -> IRQ 21 For reference the dmesg for 64 kernel with ACPI enabled is the following: Linux version 2.6.22-rc7-64-g872aad45-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #14 SMP PREEMPT Tue Jul 3 21:18:19 CEST 2007 Command line: BOOT_IMAGE=linux-2.6.22-64 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 break=modules BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 156 0: 256 -> 262032 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acp
[BUG] pata_ali not working on a 64 bit system
Hello, I found out that pata_ali is not working with a 64 bit kernel, while a 32 bit kernel on the same machine works fine. I'm running a very recent kernel (872aad45, somewhere after 2.6.22-rc7). The problem is that as soon as the module is loaded I get a screaming interrupt: (initramfs) modprobe pata_ali ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 23 scsi10 : pata_ali scsi11 : pata_ali ata11: PATA max UDMA/133 cmd 0x0001c880 ctl 0x0001c802 bmdma 0x0001c080 irq 23 ata12: PATA max UDMA/133 cmd 0x0001c480 ctl 0x0001c402 bmdma 0x0001c088 irq 23 irq 23: nobody cared (try booting with the "irqpoll" option) Call Trace: [] __report_bad_irq+0x30/0x72 [] note_interrupt+0x1d7/0x21b [] handle_fasteoi_irq+0xaf/0xd8 [] do_IRQ+0xf4/0x164 [] mwait_idle+0x0/0x51 [] ret_from_intr+0x0/0xf [] mwait_idle+0x0/0x51 [] mwait_idle+0x46/0x51 [] cpu_idle+0x95/0xcc [] start_kernel+0x2d3/0x2df [] _sinittext+0x138/0x13c (with irqpoll it works, but probably the driver is expecting the interrupt on another line). The most interesting difference between 32 and 64 bit is probably this one: -ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 19 +ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 23 pata_ali is driving a PCI card with a PATA port and a SATA port (sata_uli, I also tried loading this one: it doesn't scream but the SATA port is currently not used). I also tried pci=nocpi but the card still gets IRQ 23 when using a 64 bit kernel. The card is this one (lspci on the 32 bit kernel). 05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- logs.tar.gz Description: Binary data
[BUG] pata_ali not working on a 64 bit system
Hello, I found out that pata_ali is not working with a 64 bit kernel, while a 32 bit kernel on the same machine works fine. I'm running a very recent kernel (872aad45, somewhere after 2.6.22-rc7). The problem is that as soon as the module is loaded I get a screaming interrupt: (initramfs) modprobe pata_ali ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 23 scsi10 : pata_ali scsi11 : pata_ali ata11: PATA max UDMA/133 cmd 0x0001c880 ctl 0x0001c802 bmdma 0x0001c080 irq 23 ata12: PATA max UDMA/133 cmd 0x0001c480 ctl 0x0001c402 bmdma 0x0001c088 irq 23 irq 23: nobody cared (try booting with the irqpoll option) Call Trace: IRQ [80258407] __report_bad_irq+0x30/0x72 [80258620] note_interrupt+0x1d7/0x21b [80258ccf] handle_fasteoi_irq+0xaf/0xd8 [8020c50c] do_IRQ+0xf4/0x164 [80208631] mwait_idle+0x0/0x51 [80209bc6] ret_from_intr+0x0/0xf EOI [80208631] mwait_idle+0x0/0x51 [80208677] mwait_idle+0x46/0x51 [802085b5] cpu_idle+0x95/0xcc [805bca4e] start_kernel+0x2d3/0x2df [805bc138] _sinittext+0x138/0x13c (with irqpoll it works, but probably the driver is expecting the interrupt on another line). The most interesting difference between 32 and 64 bit is probably this one: -ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 19 +ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 23 pata_ali is driving a PCI card with a PATA port and a SATA port (sata_uli, I also tried loading this one: it doesn't scream but the SATA port is currently not used). I also tried pci=nocpi but the card still gets IRQ 23 when using a 64 bit kernel. The card is this one (lspci on the 32 bit kernel). 05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85) Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller 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: 128, cache line size 80 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at c000 [size=8] Region 1: I/O ports at bc00 [size=4] Region 2: I/O ports at b880 [size=8] Region 3: I/O ports at b800 [size=4] Region 4: I/O ports at b480 [size=16] Expansion ROM at dfe0 [disabled] [size=64K] 00: b9 10 81 52 05 00 a0 02 a4 85 80 01 80 80 80 00 10: 01 c0 00 00 01 bc 00 00 81 b8 00 00 01 b8 00 00 20: 81 b4 00 00 00 00 00 00 00 00 00 00 b9 10 81 52 30: 00 00 7f ff 00 00 00 00 00 00 00 00 0e 01 00 00 40: 80 88 08 0f 00 00 55 b1 0a 00 b1 0e 68 00 68 00 50: 01 00 02 00 00 00 00 00 00 00 00 00 09 bc 44 00 60: 00 00 00 00 00 00 00 00 10 03 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 44 00 c0: 00 00 00 00 00 00 00 00 10 03 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05:02.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85) Subsystem: ALi Corporation: Unknown device 5281 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: 128 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at c880 [size=8] Region 1: I/O ports at c800 [size=4] Region 2: I/O ports at c480 [size=8] Region 3: I/O ports at c400 [size=4] Region 4: I/O ports at c080 [size=16] 00: b9 10 28 52 05 00 a0 02 c6 85 80 01 00 80 80 00 10: 81 c8 00 00 01 c8 00 00 81 c4 00 00 01 c4 00 00 20: 81 c0 00 00 00 00 00 00 a0 00 00 00 b9 10 81 52 30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00 40: 00 00 00 7f 00 00 00 00 00 10 64 c9 00 00 ba 1a 50: 00 00 00 81 00 88 44 ad 00 00 00 00 01 31 31 31 60: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (the SATA part - M5281 - is not used). The only difference with a 64 bit kernel is: - Interrupt: pin A routed to IRQ 19 +
Re: [BUG] pata_ali not working on a 64 bit system
Il Fri, Jul 06, 2007 at 06:44:02PM +0100, Alan Cox ha scritto: On Fri, 6 Jul 2007 19:36:05 +0200 Luca Tettamanti [EMAIL PROTECTED] wrote: Hello, I found out that pata_ali is not working with a 64 bit kernel, while a 32 bit kernel on the same machine works fine. I'm running a very recent kernel (872aad45, somewhere after 2.6.22-rc7). The problem is that as soon as the module is loaded I get a screaming interrupt: Can you report this with a full dmesg to the ACPI maintainers as that is where the IRQ routing is presumably coming from. Ok, adding linux-acpi to CC. Are you using ACPI on both cases ? By default it's enabled, but I've also tried with pci=noacpi without success. That's why I reported the issue on linux-ide ;) To recap, with ACPI enabled: 32bit: pata_ali gets IRQ 19, works 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt With pci=noacpi: 32bit: pata_ali gets IRQ 23, works 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt (as a side note: in this case pata_jmicron stops working...) When ACPI is enabled IRQ mapping differs between 32 and 64 bit: -ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 19 +ACPI: PCI Interrupt :05:02.1[A] - GSI 23 (level, low) - IRQ 23 while with pci=noacpi the IRQ mapping for both 32 and 64 bit is the following: PCI: Probing PCI hardware PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 0480-04bf claimed by ICH6 GPIO PCI: Firmware left :05:01.0 e100 interrupts enabled, disabling PCI: Transparent bridge - :00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2810] at :00:1f.0 PCI-APIC IRQ transform: :00:01.0[A] - IRQ 16 PCI-APIC IRQ transform: :00:1a.0[A] - IRQ 16 PCI-APIC IRQ transform: :00:1a.1[B] - IRQ 17 PCI-APIC IRQ transform: :00:1a.7[C] - IRQ 18 PCI-APIC IRQ transform: :00:1b.0[A] - IRQ 22 PCI-APIC IRQ transform: :00:1c.0[A] - IRQ 16 PCI-APIC IRQ transform: :00:1c.3[D] - IRQ 19 PCI-APIC IRQ transform: :00:1c.4[A] - IRQ 16 PCI-APIC IRQ transform: :00:1d.0[A] - IRQ 23 PCI-APIC IRQ transform: :00:1d.1[B] - IRQ 19 PCI-APIC IRQ transform: :00:1d.2[C] - IRQ 18 PCI-APIC IRQ transform: :00:1d.7[A] - IRQ 23 PCI-APIC IRQ transform: :00:1f.2[B] - IRQ 19 PCI-APIC IRQ transform: :00:1f.3[C] - IRQ 18 PCI-APIC IRQ transform: :01:00.0[A] - IRQ 16 PCI-APIC IRQ transform: :03:00.0[A] - IRQ 19 PCI-APIC IRQ transform: :02:00.0[A] - IRQ 16 PCI-APIC IRQ transform: :02:00.1[B] - IRQ 16 PCI-APIC IRQ transform: :05:01.0[A] - IRQ 22 PCI-APIC IRQ transform: :05:02.0[A] - IRQ 23 PCI-APIC IRQ transform: :05:02.1[A] - IRQ 23 PCI-APIC IRQ transform: :05:03.0[A] - IRQ 21 For reference the dmesg for 64 kernel with ACPI enabled is the following: Linux version 2.6.22-rc7-64-g872aad45-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #14 SMP PREEMPT Tue Jul 3 21:18:19 CEST 2007 Command line: BOOT_IMAGE=linux-2.6.22-64 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 break=modules BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 156 0: 256 - 262032 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq
Re: Does the kernel HPET support has problems or the hwclock from util-linux?
rae l <[EMAIL PROTECTED]> ha scritto: > from this address, I know util-linux-2.12r is the latest: > http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm > > My Dell OptiPlex 320 has 4 HPET timers and no RTC, so the execution of > hwclock has errors: > > [EMAIL PROTECTED] ~ $ /sbin/hwclock --show > select() to /dev/rtc to wait for clock tick timed out > [EMAIL PROTECTED] ~ $ /sbin/hwclock --version > hwclock from util-linux-2.12r I think that the problem is that HPET and the CMOS RTC (list in CC) share the same interrupt line. I suppose that you should enable CONFIG_HPET_RTC_IRQ (my hardware has the same "feature"); in this way /dev/rtc correcly reports that it cannot deliver the interrupt (when HPET is enabled) and hwclock uses direct ISA access. Luca -- Windows NT crashed. I'm the Blue Screen of Death. No one hears your screams. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Does the kernel HPET support has problems or the hwclock from util-linux?
rae l [EMAIL PROTECTED] ha scritto: from this address, I know util-linux-2.12r is the latest: http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm My Dell OptiPlex 320 has 4 HPET timers and no RTC, so the execution of hwclock has errors: [EMAIL PROTECTED] ~ $ /sbin/hwclock --show select() to /dev/rtc to wait for clock tick timed out [EMAIL PROTECTED] ~ $ /sbin/hwclock --version hwclock from util-linux-2.12r I think that the problem is that HPET and the CMOS RTC (list in CC) share the same interrupt line. I suppose that you should enable CONFIG_HPET_RTC_IRQ (my hardware has the same feature); in this way /dev/rtc correcly reports that it cannot deliver the interrupt (when HPET is enabled) and hwclock uses direct ISA access. Luca -- Windows NT crashed. I'm the Blue Screen of Death. No one hears your screams. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] atl1: disable 64bit DMA
Il Mon, Jun 25, 2007 at 07:42:44AM -0500, Jay Cliburn ha scritto:
> Jay L. T. Cornwall wrote:
> >Jay Cliburn wrote:
> >
> >>For reasons not yet clear to me, it appears the L1 driver has a bug or
> >>the device itself has trouble with DMA in high memory. This patch,
> >>drafted by Luca Tettamanti, is being explored as a workaround. I'd be
> >>interested to know if it fixes your problem.
> >
> >Yes, it certainly seems to. Now running with this patch and 4GB active,
> >I've transferred about 15GB with no problem so far. It usually oopses
> >after a GB or two.
> >
> >I guess it's not an ideal solution, architecturally speaking, but it's a
> >good deal better than an unstable driver. If there's any other patches
> >you'd like me to test or traces to capture, I'm happy to help out.
> >Otherwise I'll run with this one for now since it does the job!
>
> Okay Jay, thanks.
>
> Luca, would you please submit your patch to Jeff Garzik and netdev?
Hi Jeff,
a couple of users reported hard lockups when using L1 NICs on machines
with 4GB or more of RAM. We're still waiting official confirmation from
the vendor, but it seems that L1 has problems doing DMA to/from high
memory (physical address above the 4GB limit). Passing 32bit DMA mask
cures the problem.
Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
---
I think that the patch should be included in 2.6.22.
drivers/net/atl1/atl1_main.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 6862c11..a730f15 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2097,21 +2097,16 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
struct net_device *netdev;
struct atl1_adapter *adapter;
static int cards_found = 0;
- bool pci_using_64 = true;
int err;
err = pci_enable_device(pdev);
if (err)
return err;
- err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
+ err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
if (err) {
- err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
- if (err) {
- dev_err(>dev, "no usable DMA configuration\n");
- goto err_dma;
- }
- pci_using_64 = false;
+ dev_err(>dev, "no usable DMA configuration\n");
+ goto err_dma;
}
/* Mark all PCI regions associated with PCI device
* pdev as being reserved by owner atl1_driver_name
@@ -2176,7 +2171,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
netdev->ethtool_ops = _ethtool_ops;
adapter->bd_number = cards_found;
- adapter->pci_using_64 = pci_using_64;
/* setup the private structure */
err = atl1_sw_init(adapter);
@@ -2193,9 +2187,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
*/
/* netdev->features |= NETIF_F_TSO; */
- if (pci_using_64)
- netdev->features |= NETIF_F_HIGHDMA;
-
netdev->features |= NETIF_F_LLTX;
/*
Luca
--
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] atl1: disable 64bit DMA
Il Mon, Jun 25, 2007 at 07:42:44AM -0500, Jay Cliburn ha scritto:
Jay L. T. Cornwall wrote:
Jay Cliburn wrote:
For reasons not yet clear to me, it appears the L1 driver has a bug or
the device itself has trouble with DMA in high memory. This patch,
drafted by Luca Tettamanti, is being explored as a workaround. I'd be
interested to know if it fixes your problem.
Yes, it certainly seems to. Now running with this patch and 4GB active,
I've transferred about 15GB with no problem so far. It usually oopses
after a GB or two.
I guess it's not an ideal solution, architecturally speaking, but it's a
good deal better than an unstable driver. If there's any other patches
you'd like me to test or traces to capture, I'm happy to help out.
Otherwise I'll run with this one for now since it does the job!
Okay Jay, thanks.
Luca, would you please submit your patch to Jeff Garzik and netdev?
Hi Jeff,
a couple of users reported hard lockups when using L1 NICs on machines
with 4GB or more of RAM. We're still waiting official confirmation from
the vendor, but it seems that L1 has problems doing DMA to/from high
memory (physical address above the 4GB limit). Passing 32bit DMA mask
cures the problem.
Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED]
---
I think that the patch should be included in 2.6.22.
drivers/net/atl1/atl1_main.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 6862c11..a730f15 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2097,21 +2097,16 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
struct net_device *netdev;
struct atl1_adapter *adapter;
static int cards_found = 0;
- bool pci_using_64 = true;
int err;
err = pci_enable_device(pdev);
if (err)
return err;
- err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
+ err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
if (err) {
- err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
- if (err) {
- dev_err(pdev-dev, no usable DMA configuration\n);
- goto err_dma;
- }
- pci_using_64 = false;
+ dev_err(pdev-dev, no usable DMA configuration\n);
+ goto err_dma;
}
/* Mark all PCI regions associated with PCI device
* pdev as being reserved by owner atl1_driver_name
@@ -2176,7 +2171,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
netdev-ethtool_ops = atl1_ethtool_ops;
adapter-bd_number = cards_found;
- adapter-pci_using_64 = pci_using_64;
/* setup the private structure */
err = atl1_sw_init(adapter);
@@ -2193,9 +2187,6 @@ static int __devinit atl1_probe(struct pci_dev *pdev,
*/
/* netdev-features |= NETIF_F_TSO; */
- if (pci_using_64)
- netdev-features |= NETIF_F_HIGHDMA;
-
netdev-features |= NETIF_F_LLTX;
/*
Luca
--
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] kvm: Fix x86 emulator writeback
When the old value and new one are the same the emulator skips the
write; this is undesiderable when the destination is a MMIO area and the
write shall be performed regardless of the previous value. This
optimization breaks e.g. a Linux guest APIC compiled without
X86_GOOD_APIC.
Remove the check and perform the writeback stage in the emulation unless
it's explicitly disabled (currently push and some 2 bytes instructions
may disable the writeback).
Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
---
Tested with Fedora7, Solaris10 and WinXP on a 32 bit host with Intel
CPU.
drivers/kvm/x86_emulate.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a4a8481..eb10448 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -482,6 +482,7 @@ x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
int mode = ctxt->mode;
unsigned long modrm_ea;
int use_modrm_ea, index_reg = 0, base_reg = 0, scale, rip_relative = 0;
+ int no_wb = 0;
/* Shadow copy of register state. Committed on successful emulation. */
unsigned long _regs[NR_VCPU_REGS];
@@ -1048,7 +1049,7 @@ done_prefixes:
_regs[VCPU_REGS_RSP]),
, dst.bytes, ctxt)) != 0)
goto done;
- dst.val = dst.orig_val; /* skanky: disable writeback */
+ no_wb = 1; /* skanky: disable writeback */
break;
default:
goto cannot_emulate;
@@ -1057,7 +1058,7 @@ done_prefixes:
}
writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
+ if (!no_wb) {
switch (dst.type) {
case OP_REG:
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
@@ -1306,7 +1307,7 @@ twobyte_insn:
twobyte_special_insn:
/* Disable writeback. */
- dst.orig_val = dst.val;
+ no_wb = 1;
switch (b) {
case 0x09: /* wbinvd */
break;
Luca
--
Colui che sorride quando le cose vanno male ha pensato a qualcuno a cui
dare la colpa.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] kvm: avoid useless memory write when possible
When writing to normal memory and the memory area is unchanged the write
can be safely skipped, avoiding the costly kvm_mmu_pte_write.
Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
---
Tested with Fedora7, Solaris10 and WinXP on a 32 bit host with Intel
CPU.
drivers/kvm/kvm_main.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 633c2ed..9b7b0b9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1139,8 +1139,10 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
gpa_t gpa,
return 0;
mark_page_dirty(vcpu->kvm, gpa >> PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
+ memcpy(virt + offset_in_page(gpa), val, bytes);
+ }
kunmap_atomic(virt, KM_USER0);
return 1;
}
Luca
--
Regole per la felicit?:
1. Sii soddisfatto di quello che hai.
2. Assicurati di avere tutto.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] kvm: Fix x86 emulator writeback
Il Mon, Jun 18, 2007 at 02:32:39PM +0300, Avi Kivity ha scritto:
> >Unfortunately, this kills Windows XP (first run with a guest crash,
> >second with a host oops), so I reverted it. I'd guess some operation
> >which doesn't need writeback ends up in the modified code.
> >Previously, the check caused it to skip writeback, but now it writes
> >back random memory, causing a crash.
> >
>
> There are comments around like
>
> >/* Disable writeback. */
> >dst.orig_val = dst.val;
>
> Best option is probably to add an explicit disable_writeback flag and
> set it there.
I've tested this patch with linux, solaris and winxp, on a 32 bit guest.
So far everything is fine ;)
David, this patch should fix the lockup you're seeing.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 633c2ed..9b7b0b9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1139,8 +1139,10 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
gpa_t gpa,
return 0;
mark_page_dirty(vcpu->kvm, gpa >> PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
+ memcpy(virt + offset_in_page(gpa), val, bytes);
+ }
kunmap_atomic(virt, KM_USER0);
return 1;
}
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a4a8481..eb10448 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -482,6 +482,7 @@ x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
int mode = ctxt->mode;
unsigned long modrm_ea;
int use_modrm_ea, index_reg = 0, base_reg = 0, scale, rip_relative = 0;
+ int no_wb = 0;
/* Shadow copy of register state. Committed on successful emulation. */
unsigned long _regs[NR_VCPU_REGS];
@@ -1048,7 +1049,7 @@ done_prefixes:
_regs[VCPU_REGS_RSP]),
, dst.bytes, ctxt)) != 0)
goto done;
- dst.val = dst.orig_val; /* skanky: disable writeback */
+ no_wb = 1; /* skanky: disable writeback */
break;
default:
goto cannot_emulate;
@@ -1057,7 +1058,7 @@ done_prefixes:
}
writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
+ if (!no_wb) {
switch (dst.type) {
case OP_REG:
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
@@ -1306,7 +1307,7 @@ twobyte_insn:
twobyte_special_insn:
/* Disable writeback. */
- dst.orig_val = dst.val;
+ no_wb = 1;
switch (b) {
case 0x09: /* wbinvd */
break;
Luca
--
"Ci sono le balle, le megaballe e le statistiche".
Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] kvm: Fix x86 emulator writeback
Il Mon, Jun 18, 2007 at 02:32:39PM +0300, Avi Kivity ha scritto:
Unfortunately, this kills Windows XP (first run with a guest crash,
second with a host oops), so I reverted it. I'd guess some operation
which doesn't need writeback ends up in the modified code.
Previously, the check caused it to skip writeback, but now it writes
back random memory, causing a crash.
There are comments around like
/* Disable writeback. */
dst.orig_val = dst.val;
Best option is probably to add an explicit disable_writeback flag and
set it there.
I've tested this patch with linux, solaris and winxp, on a 32 bit guest.
So far everything is fine ;)
David, this patch should fix the lockup you're seeing.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 633c2ed..9b7b0b9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1139,8 +1139,10 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
gpa_t gpa,
return 0;
mark_page_dirty(vcpu-kvm, gpa PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
+ memcpy(virt + offset_in_page(gpa), val, bytes);
+ }
kunmap_atomic(virt, KM_USER0);
return 1;
}
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a4a8481..eb10448 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -482,6 +482,7 @@ x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
int mode = ctxt-mode;
unsigned long modrm_ea;
int use_modrm_ea, index_reg = 0, base_reg = 0, scale, rip_relative = 0;
+ int no_wb = 0;
/* Shadow copy of register state. Committed on successful emulation. */
unsigned long _regs[NR_VCPU_REGS];
@@ -1048,7 +1049,7 @@ done_prefixes:
_regs[VCPU_REGS_RSP]),
dst.val, dst.bytes, ctxt)) != 0)
goto done;
- dst.val = dst.orig_val; /* skanky: disable writeback */
+ no_wb = 1; /* skanky: disable writeback */
break;
default:
goto cannot_emulate;
@@ -1057,7 +1058,7 @@ done_prefixes:
}
writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
+ if (!no_wb) {
switch (dst.type) {
case OP_REG:
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
@@ -1306,7 +1307,7 @@ twobyte_insn:
twobyte_special_insn:
/* Disable writeback. */
- dst.orig_val = dst.val;
+ no_wb = 1;
switch (b) {
case 0x09: /* wbinvd */
break;
Luca
--
Ci sono le balle, le megaballe e le statistiche.
Mark Twain
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] kvm: Fix x86 emulator writeback
When the old value and new one are the same the emulator skips the
write; this is undesiderable when the destination is a MMIO area and the
write shall be performed regardless of the previous value. This
optimization breaks e.g. a Linux guest APIC compiled without
X86_GOOD_APIC.
Remove the check and perform the writeback stage in the emulation unless
it's explicitly disabled (currently push and some 2 bytes instructions
may disable the writeback).
Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED]
---
Tested with Fedora7, Solaris10 and WinXP on a 32 bit host with Intel
CPU.
drivers/kvm/x86_emulate.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a4a8481..eb10448 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -482,6 +482,7 @@ x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
int mode = ctxt-mode;
unsigned long modrm_ea;
int use_modrm_ea, index_reg = 0, base_reg = 0, scale, rip_relative = 0;
+ int no_wb = 0;
/* Shadow copy of register state. Committed on successful emulation. */
unsigned long _regs[NR_VCPU_REGS];
@@ -1048,7 +1049,7 @@ done_prefixes:
_regs[VCPU_REGS_RSP]),
dst.val, dst.bytes, ctxt)) != 0)
goto done;
- dst.val = dst.orig_val; /* skanky: disable writeback */
+ no_wb = 1; /* skanky: disable writeback */
break;
default:
goto cannot_emulate;
@@ -1057,7 +1058,7 @@ done_prefixes:
}
writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
+ if (!no_wb) {
switch (dst.type) {
case OP_REG:
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
@@ -1306,7 +1307,7 @@ twobyte_insn:
twobyte_special_insn:
/* Disable writeback. */
- dst.orig_val = dst.val;
+ no_wb = 1;
switch (b) {
case 0x09: /* wbinvd */
break;
Luca
--
Colui che sorride quando le cose vanno male ha pensato a qualcuno a cui
dare la colpa.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] kvm: avoid useless memory write when possible
When writing to normal memory and the memory area is unchanged the write
can be safely skipped, avoiding the costly kvm_mmu_pte_write.
Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED]
---
Tested with Fedora7, Solaris10 and WinXP on a 32 bit host with Intel
CPU.
drivers/kvm/kvm_main.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 633c2ed..9b7b0b9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1139,8 +1139,10 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
gpa_t gpa,
return 0;
mark_page_dirty(vcpu-kvm, gpa PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
+ memcpy(virt + offset_in_page(gpa), val, bytes);
+ }
kunmap_atomic(virt, KM_USER0);
return 1;
}
Luca
--
Regole per la felicit?:
1. Sii soddisfatto di quello che hai.
2. Assicurati di avere tutto.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] kvm: Fix x86 emulator writeback
When the old value and new one are the same the emulator skips the
write; this is undesiderable when the destination is a MMIO area and the
write shall be performed regardless of the previous value. This
optimization breaks e.g. a Linux guest APIC compiled without
X86_GOOD_APIC.
Remove the check and always perform the writeback stage in the
emulation.
Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c | 60 +++-
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a4a8481..cea9f3a 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1057,40 +1057,38 @@ done_prefixes:
}
writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
- switch (dst.type) {
- case OP_REG:
- /* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
- switch (dst.bytes) {
- case 1:
- *(u8 *)dst.ptr = (u8)dst.val;
- break;
- case 2:
- *(u16 *)dst.ptr = (u16)dst.val;
- break;
- case 4:
- *dst.ptr = (u32)dst.val;
- break; /* 64b: zero-ext */
- case 8:
- *dst.ptr = dst.val;
- break;
- }
+ switch (dst.type) {
+ case OP_REG:
+ /* The 4-byte case *is* correct: in 64-bit mode we zero-extend.
*/
+ switch (dst.bytes) {
+ case 1:
+ *(u8 *)dst.ptr = (u8)dst.val;
break;
- case OP_MEM:
- if (lock_prefix)
- rc = ops->cmpxchg_emulated((unsigned long)dst.
- ptr, _val,
- , dst.bytes,
- ctxt);
- else
- rc = ops->write_emulated((unsigned long)dst.ptr,
-, dst.bytes,
-ctxt);
- if (rc != 0)
- goto done;
- default:
+ case 2:
+ *(u16 *)dst.ptr = (u16)dst.val;
+ break;
+ case 4:
+ *dst.ptr = (u32)dst.val;
+ break; /* 64b: zero-ext */
+ case 8:
+ *dst.ptr = dst.val;
break;
}
+ break;
+ case OP_MEM:
+ if (lock_prefix)
+ rc = ops->cmpxchg_emulated((unsigned long)dst.
+ ptr, _val,
+ , dst.bytes,
+ ctxt);
+ else
+ rc = ops->write_emulated((unsigned long)dst.ptr,
+, dst.bytes,
+ctxt);
+ if (rc != 0)
+ goto done;
+ default:
+ break;
}
/* Commit shadow register state. */
Luca
--
Software is like sex; it's better when it's free.
Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] kvm: avoid useless memory write when possible
When writing to normal memory and the memory area is unchanged the write
can be safely skipped, avoiding the costly kvm_mmu_pte_write.
Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 633c2ed..9b7b0b9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1139,8 +1139,10 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
gpa_t gpa,
return 0;
mark_page_dirty(vcpu->kvm, gpa >> PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
+ memcpy(virt + offset_in_page(gpa), val, bytes);
+ }
kunmap_atomic(virt, KM_USER0);
return 1;
}
Luca
--
Se non puoi convincerli, confondili.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Sat, Jun 16, 2007 at 10:43:23AM +0300, Avi Kivity ha scritto:
> Luca Tettamanti wrote:
> > Il Fri, Jun 15, 2007 at 12:06:50PM +0300, Avi Kivity ha scritto:
> >
> >>> After a bit of thinking: it's correct but removes an optimization;
> >>> furthermore it may miss other instructions that write to memory mapped
> >>> areas.
> >>> A more proper fix should be "force the writeback if dst.ptr is in some
> >>> kind of mmio area".
> >>>
> >>>
> >> I think we can just disable the optimization, and (in a separate patch)
> >> add it back in emulator_write_phys(), where we know we're modifying
> >> memory and not hitting mmio.
> >>
> >
> > Problem is that in emulator_write_phys() we've already lost track of the
> > previous (dst.orig_val) value. I moved up the decision in
> >
>
> Actually we haven't; just before the memcpy(), we can put a memcmp() to
> guard the kvm_mmu_pte_write(), which is the really expensive operation,
> especially with guest smp.
Yup, but it seemed wasteful to map (at least when highmem is in use) a
page just to check for something that we already knew. That was a
preemptive optmization though, I haven't actually benchmarked the cost
of setting up the mapping ;-)
[...]
> I think we can simply remove the if (). For the register case, the
> check is more expensive that the write; for mmio, we don't want it; and
> for memory writes, we can put it in emulator_write_phys().
Ok, this way it's simpler. How does this look:
--- a/kernel/x86_emulate.c 2007-06-15 21:13:51.0 +0200
+++ b/kernel/x86_emulate.c 2007-06-17 16:57:50.0 +0200
@@ -1057,40 +1057,38 @@
}
writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
- switch (dst.type) {
- case OP_REG:
- /* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
- switch (dst.bytes) {
- case 1:
- *(u8 *)dst.ptr = (u8)dst.val;
- break;
- case 2:
- *(u16 *)dst.ptr = (u16)dst.val;
- break;
- case 4:
- *dst.ptr = (u32)dst.val;
- break; /* 64b: zero-ext */
- case 8:
- *dst.ptr = dst.val;
- break;
- }
+ switch (dst.type) {
+ case OP_REG:
+ /* The 4-byte case *is* correct: in 64-bit mode we zero-extend.
*/
+ switch (dst.bytes) {
+ case 1:
+ *(u8 *)dst.ptr = (u8)dst.val;
break;
- case OP_MEM:
- if (lock_prefix)
- rc = ops->cmpxchg_emulated((unsigned long)dst.
- ptr, _val,
- , dst.bytes,
- ctxt);
- else
- rc = ops->write_emulated((unsigned long)dst.ptr,
-, dst.bytes,
-ctxt);
- if (rc != 0)
- goto done;
- default:
+ case 2:
+ *(u16 *)dst.ptr = (u16)dst.val;
+ break;
+ case 4:
+ *dst.ptr = (u32)dst.val;
+ break; /* 64b: zero-ext */
+ case 8:
+ *dst.ptr = dst.val;
break;
}
+ break;
+ case OP_MEM:
+ if (lock_prefix)
+ rc = ops->cmpxchg_emulated((unsigned long)dst.
+ ptr, _val,
+ , dst.bytes,
+ ctxt);
+ else
+ rc = ops->write_emulated((unsigned long)dst.ptr,
+, dst.bytes,
+ctxt);
+ if (rc != 0)
+ goto done;
+ default:
+ break;
}
/* Commit shadow register state. */
--- a/kernel/kvm_main.c 2007-06-15 21:18:08.0 +0200
+++ b/kernel/kvm_main.c 2007-06-17 16:59:33.0 +0200
@@ -1139,8 +1139,10 @@
return 0;
mark_page_dirty(vcpu->kvm, gpa >> PAGE_SHIFT);
Re: [kvm-devel] [BUG] Oops with KVM-27
Il Sat, Jun 16, 2007 at 10:43:23AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
Il Fri, Jun 15, 2007 at 12:06:50PM +0300, Avi Kivity ha scritto:
After a bit of thinking: it's correct but removes an optimization;
furthermore it may miss other instructions that write to memory mapped
areas.
A more proper fix should be force the writeback if dst.ptr is in some
kind of mmio area.
I think we can just disable the optimization, and (in a separate patch)
add it back in emulator_write_phys(), where we know we're modifying
memory and not hitting mmio.
Problem is that in emulator_write_phys() we've already lost track of the
previous (dst.orig_val) value. I moved up the decision in
Actually we haven't; just before the memcpy(), we can put a memcmp() to
guard the kvm_mmu_pte_write(), which is the really expensive operation,
especially with guest smp.
Yup, but it seemed wasteful to map (at least when highmem is in use) a
page just to check for something that we already knew. That was a
preemptive optmization though, I haven't actually benchmarked the cost
of setting up the mapping ;-)
[...]
I think we can simply remove the if (). For the register case, the
check is more expensive that the write; for mmio, we don't want it; and
for memory writes, we can put it in emulator_write_phys().
Ok, this way it's simpler. How does this look:
--- a/kernel/x86_emulate.c 2007-06-15 21:13:51.0 +0200
+++ b/kernel/x86_emulate.c 2007-06-17 16:57:50.0 +0200
@@ -1057,40 +1057,38 @@
}
writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
- switch (dst.type) {
- case OP_REG:
- /* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
- switch (dst.bytes) {
- case 1:
- *(u8 *)dst.ptr = (u8)dst.val;
- break;
- case 2:
- *(u16 *)dst.ptr = (u16)dst.val;
- break;
- case 4:
- *dst.ptr = (u32)dst.val;
- break; /* 64b: zero-ext */
- case 8:
- *dst.ptr = dst.val;
- break;
- }
+ switch (dst.type) {
+ case OP_REG:
+ /* The 4-byte case *is* correct: in 64-bit mode we zero-extend.
*/
+ switch (dst.bytes) {
+ case 1:
+ *(u8 *)dst.ptr = (u8)dst.val;
break;
- case OP_MEM:
- if (lock_prefix)
- rc = ops-cmpxchg_emulated((unsigned long)dst.
- ptr, dst.orig_val,
- dst.val, dst.bytes,
- ctxt);
- else
- rc = ops-write_emulated((unsigned long)dst.ptr,
-dst.val, dst.bytes,
-ctxt);
- if (rc != 0)
- goto done;
- default:
+ case 2:
+ *(u16 *)dst.ptr = (u16)dst.val;
+ break;
+ case 4:
+ *dst.ptr = (u32)dst.val;
+ break; /* 64b: zero-ext */
+ case 8:
+ *dst.ptr = dst.val;
break;
}
+ break;
+ case OP_MEM:
+ if (lock_prefix)
+ rc = ops-cmpxchg_emulated((unsigned long)dst.
+ ptr, dst.orig_val,
+ dst.val, dst.bytes,
+ ctxt);
+ else
+ rc = ops-write_emulated((unsigned long)dst.ptr,
+dst.val, dst.bytes,
+ctxt);
+ if (rc != 0)
+ goto done;
+ default:
+ break;
}
/* Commit shadow register state. */
--- a/kernel/kvm_main.c 2007-06-15 21:18:08.0 +0200
+++ b/kernel/kvm_main.c 2007-06-17 16:59:33.0 +0200
@@ -1139,8 +1139,10 @@
return 0;
mark_page_dirty(vcpu-kvm, gpa PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa
[PATCH 1/2] kvm: Fix x86 emulator writeback
When the old value and new one are the same the emulator skips the
write; this is undesiderable when the destination is a MMIO area and the
write shall be performed regardless of the previous value. This
optimization breaks e.g. a Linux guest APIC compiled without
X86_GOOD_APIC.
Remove the check and always perform the writeback stage in the
emulation.
Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 60 +++-
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a4a8481..cea9f3a 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1057,40 +1057,38 @@ done_prefixes:
}
writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
- switch (dst.type) {
- case OP_REG:
- /* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
- switch (dst.bytes) {
- case 1:
- *(u8 *)dst.ptr = (u8)dst.val;
- break;
- case 2:
- *(u16 *)dst.ptr = (u16)dst.val;
- break;
- case 4:
- *dst.ptr = (u32)dst.val;
- break; /* 64b: zero-ext */
- case 8:
- *dst.ptr = dst.val;
- break;
- }
+ switch (dst.type) {
+ case OP_REG:
+ /* The 4-byte case *is* correct: in 64-bit mode we zero-extend.
*/
+ switch (dst.bytes) {
+ case 1:
+ *(u8 *)dst.ptr = (u8)dst.val;
break;
- case OP_MEM:
- if (lock_prefix)
- rc = ops-cmpxchg_emulated((unsigned long)dst.
- ptr, dst.orig_val,
- dst.val, dst.bytes,
- ctxt);
- else
- rc = ops-write_emulated((unsigned long)dst.ptr,
-dst.val, dst.bytes,
-ctxt);
- if (rc != 0)
- goto done;
- default:
+ case 2:
+ *(u16 *)dst.ptr = (u16)dst.val;
+ break;
+ case 4:
+ *dst.ptr = (u32)dst.val;
+ break; /* 64b: zero-ext */
+ case 8:
+ *dst.ptr = dst.val;
break;
}
+ break;
+ case OP_MEM:
+ if (lock_prefix)
+ rc = ops-cmpxchg_emulated((unsigned long)dst.
+ ptr, dst.orig_val,
+ dst.val, dst.bytes,
+ ctxt);
+ else
+ rc = ops-write_emulated((unsigned long)dst.ptr,
+dst.val, dst.bytes,
+ctxt);
+ if (rc != 0)
+ goto done;
+ default:
+ break;
}
/* Commit shadow register state. */
Luca
--
Software is like sex; it's better when it's free.
Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] kvm: avoid useless memory write when possible
When writing to normal memory and the memory area is unchanged the write
can be safely skipped, avoiding the costly kvm_mmu_pte_write.
Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 633c2ed..9b7b0b9 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1139,8 +1139,10 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu,
gpa_t gpa,
return 0;
mark_page_dirty(vcpu-kvm, gpa PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
- kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
- memcpy(virt + offset_in_page(gpa), val, bytes);
+ if (memcmp(virt + offset_in_page(gpa), val, bytes)) {
+ kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
+ memcpy(virt + offset_in_page(gpa), val, bytes);
+ }
kunmap_atomic(virt, KM_USER0);
return 1;
}
Luca
--
Se non puoi convincerli, confondili.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Fri, Jun 15, 2007 at 12:06:50PM +0300, Avi Kivity ha scritto:
> > After a bit of thinking: it's correct but removes an optimization;
> > furthermore it may miss other instructions that write to memory mapped
> > areas.
> > A more proper fix should be "force the writeback if dst.ptr is in some
> > kind of mmio area".
> >
>
> I think we can just disable the optimization, and (in a separate patch)
> add it back in emulator_write_phys(), where we know we're modifying
> memory and not hitting mmio.
Problem is that in emulator_write_phys() we've already lost track of the
previous (dst.orig_val) value. I moved up the decision in
cmpxchg_emulated; unfortunately this means that the non-locked write
path (write_emulated) can't do this optimization, unless I change its
signature to include the old value.
The first patch makes the writeback step uncoditional whenever we have a
destination operand (the mov check (d & Mov) may be superfluous, yes?).
The write-to-registry path still has the optimization that skips the
write if possible.
--- a/kernel/x86_emulate.c 2007-06-15 21:13:51.0 +0200
+++ b/kernel/x86_emulate.c 2007-06-15 22:12:15.0 +0200
@@ -1057,9 +1057,8 @@
}
writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
- switch (dst.type) {
- case OP_REG:
+ if ((d & Mov) || (d & DstMask) == DstMem || (d & DstMask) == DstReg ) {
+ if (dst.type == OP_REG && dst.orig_val != dst.val) {
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
switch (dst.bytes) {
case 1:
@@ -1075,8 +1074,10 @@
*dst.ptr = dst.val;
break;
}
- break;
- case OP_MEM:
+ } else if (dst.type == OP_MEM) {
+ /* Always dispatch the write, since it may hit a
+* MMIO area.
+*/
if (lock_prefix)
rc = ops->cmpxchg_emulated((unsigned long)dst.
ptr, _val,
@@ -1088,8 +1089,6 @@
ctxt);
if (rc != 0)
goto done;
- default:
- break;
}
}
Next one: I've splitted emulator_write_phys into emulator_write_phys_mem
(for normal RAM) and emulator_write_phys_mmio (for the rest). The
cmpxchg code path is roughly:
if (!mapped)
page_fault();
page = gfn_to_page(...)
if (page) {
if (!memcmp(old, new))
return X86EMUL_CONTINUE;
write_mem();
retrun X86EMUL_CONTINUE;
}
/* for mmio always do the write */
write_mmio();
I'm a bit confused about this test, found in emulator_write_phys
(original code):
if (((gpa + bytes - 1) >> PAGE_SHIFT) != (gpa >> PAGE_SHIFT))
return 0;
AFAICT is makes the emulator skip the write if the modified area spans
across two different (physical) pages. When this happens write_emulated
does a MMIO write. I'd expect the function to load the 2 pages and do the
memory write on both instead.
I've preserved this logic in the following patch, but I don't understand
why it's correct :|
--- a/kernel/kvm_main.c 2007-06-15 21:18:08.0 +0200
+++ b/kernel/kvm_main.c 2007-06-15 23:34:13.0 +0200
@@ -1125,26 +1125,39 @@
}
}
-static int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
- const void *val, int bytes)
+static int emulator_write_phys_mem(struct kvm_vcpu *vcpu, gpa_t gpa,
+ struct page *page, const void *val,
+ int bytes)
{
- struct page *page;
void *virt;
- unsigned offset = offset_in_page(gpa);
+ unsigned int offset;
+
+ offset = offset_in_page(gpa);
if (((gpa + bytes - 1) >> PAGE_SHIFT) != (gpa >> PAGE_SHIFT))
return 0;
- page = gfn_to_page(vcpu->kvm, gpa >> PAGE_SHIFT);
- if (!page)
- return 0;
+
mark_page_dirty(vcpu->kvm, gpa >> PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
memcpy(virt + offset_in_page(gpa), val, bytes);
kunmap_atomic(virt, KM_USER0);
+
return 1;
}
+static int emulator_write_phys_mmio(struct kvm_vcpu *vcpu, gpa_t gpa,
+ const void *val, int bytes)
+{
+ vcpu->mmio_needed = 1;
+ vcpu->mmio_phys_addr = gpa;
+ vcpu->mmio_size = bytes;
+ vcpu->mmio_is_write = 1;
+ memcpy(vcpu->mmio_data, val, bytes);
+
+ return 0;
+}
+
static int emulator_write_emulated(unsigned long addr,
const void *val,
Re: [kvm-devel] [BUG] Oops with KVM-27
Il Fri, Jun 15, 2007 at 12:06:50PM +0300, Avi Kivity ha scritto:
After a bit of thinking: it's correct but removes an optimization;
furthermore it may miss other instructions that write to memory mapped
areas.
A more proper fix should be force the writeback if dst.ptr is in some
kind of mmio area.
I think we can just disable the optimization, and (in a separate patch)
add it back in emulator_write_phys(), where we know we're modifying
memory and not hitting mmio.
Problem is that in emulator_write_phys() we've already lost track of the
previous (dst.orig_val) value. I moved up the decision in
cmpxchg_emulated; unfortunately this means that the non-locked write
path (write_emulated) can't do this optimization, unless I change its
signature to include the old value.
The first patch makes the writeback step uncoditional whenever we have a
destination operand (the mov check (d Mov) may be superfluous, yes?).
The write-to-registry path still has the optimization that skips the
write if possible.
--- a/kernel/x86_emulate.c 2007-06-15 21:13:51.0 +0200
+++ b/kernel/x86_emulate.c 2007-06-15 22:12:15.0 +0200
@@ -1057,9 +1057,8 @@
}
writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
- switch (dst.type) {
- case OP_REG:
+ if ((d Mov) || (d DstMask) == DstMem || (d DstMask) == DstReg ) {
+ if (dst.type == OP_REG dst.orig_val != dst.val) {
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
switch (dst.bytes) {
case 1:
@@ -1075,8 +1074,10 @@
*dst.ptr = dst.val;
break;
}
- break;
- case OP_MEM:
+ } else if (dst.type == OP_MEM) {
+ /* Always dispatch the write, since it may hit a
+* MMIO area.
+*/
if (lock_prefix)
rc = ops-cmpxchg_emulated((unsigned long)dst.
ptr, dst.orig_val,
@@ -1088,8 +1089,6 @@
ctxt);
if (rc != 0)
goto done;
- default:
- break;
}
}
Next one: I've splitted emulator_write_phys into emulator_write_phys_mem
(for normal RAM) and emulator_write_phys_mmio (for the rest). The
cmpxchg code path is roughly:
if (!mapped)
page_fault();
page = gfn_to_page(...)
if (page) {
if (!memcmp(old, new))
return X86EMUL_CONTINUE;
write_mem();
retrun X86EMUL_CONTINUE;
}
/* for mmio always do the write */
write_mmio();
I'm a bit confused about this test, found in emulator_write_phys
(original code):
if (((gpa + bytes - 1) PAGE_SHIFT) != (gpa PAGE_SHIFT))
return 0;
AFAICT is makes the emulator skip the write if the modified area spans
across two different (physical) pages. When this happens write_emulated
does a MMIO write. I'd expect the function to load the 2 pages and do the
memory write on both instead.
I've preserved this logic in the following patch, but I don't understand
why it's correct :|
--- a/kernel/kvm_main.c 2007-06-15 21:18:08.0 +0200
+++ b/kernel/kvm_main.c 2007-06-15 23:34:13.0 +0200
@@ -1125,26 +1125,39 @@
}
}
-static int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,
- const void *val, int bytes)
+static int emulator_write_phys_mem(struct kvm_vcpu *vcpu, gpa_t gpa,
+ struct page *page, const void *val,
+ int bytes)
{
- struct page *page;
void *virt;
- unsigned offset = offset_in_page(gpa);
+ unsigned int offset;
+
+ offset = offset_in_page(gpa);
if (((gpa + bytes - 1) PAGE_SHIFT) != (gpa PAGE_SHIFT))
return 0;
- page = gfn_to_page(vcpu-kvm, gpa PAGE_SHIFT);
- if (!page)
- return 0;
+
mark_page_dirty(vcpu-kvm, gpa PAGE_SHIFT);
virt = kmap_atomic(page, KM_USER0);
kvm_mmu_pte_write(vcpu, gpa, virt + offset, val, bytes);
memcpy(virt + offset_in_page(gpa), val, bytes);
kunmap_atomic(virt, KM_USER0);
+
return 1;
}
+static int emulator_write_phys_mmio(struct kvm_vcpu *vcpu, gpa_t gpa,
+ const void *val, int bytes)
+{
+ vcpu-mmio_needed = 1;
+ vcpu-mmio_phys_addr = gpa;
+ vcpu-mmio_size = bytes;
+ vcpu-mmio_is_write = 1;
+ memcpy(vcpu-mmio_data, val, bytes);
+
+ return 0;
+}
+
static int emulator_write_emulated(unsigned long addr,
const void *val,
Re: [kvm-devel] [BUG] Oops with KVM-27
Il Fri, Jun 15, 2007 at 12:53:24AM +0200, Luca Tettamanti ha scritto:
> Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
> > Luca Tettamanti wrote:
> > >With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
> > >normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
> > >using xchg. With !GOOD_APIC and this patch:
> > >
> > >--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
> > >+++ include/asm-i386/apic.h2007-06-13 22:35:00.0 +0200
> > >@@ -56,7 +56,8 @@
> > > static __inline fastcall void native_apic_write_atomic(unsigned long reg,
> > > unsigned long v)
> > > {
> > >- xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> > >+//xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> > >+ *((volatile unsigned long *)(APIC_BASE+reg)) = v;
> > > }
> > >
> > > static __inline fastcall unsigned long native_apic_read(unsigned long reg)
> > >
> > >The kernel boots fine.
> > >
> >
> > Looking at the xchg emulation code, it seems fine, but clearly it
> > isn't.
>
> Btw, I've put a printk in x86_emulate.c, where it prepares the operands
> for the xchg operations: all the write_atomic are hitting this point,
> so the write is lost somewhere in cmpxchg_emulated->write_emulated.
Got it!
The emulator skips the writeback if the old value is unchanged, so the
apic doesn't see the write.
Forcing the writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
- if ((d & Mov) || (dst.orig_val != dst.val) || isxchg) {
seems to fix the issue :D I'm not sure that fix is correct though. This
is the patch I'm using:
--- a/kernel/x86_emulate.c 2007-06-03 10:31:15.0 +0200
+++ b/kernel/x86_emulate.c 2007-06-15 01:12:12.0 +0200
@@ -486,6 +486,7 @@
unsigned long _regs[NR_VCPU_REGS];
unsigned long _eip = ctxt->vcpu->rip, _eflags = ctxt->eflags;
unsigned long modrm_val = 0;
+ int isxchg = 0;
memcpy(_regs, ctxt->vcpu->regs, sizeof _regs);
@@ -912,6 +913,7 @@
break;
case 0x86 ... 0x87: /* xchg */
/* Write back the register source. */
+ isxchg = 1;
switch (dst.bytes) {
case 1:
*(u8 *) src.ptr = (u8) dst.val;
@@ -1056,7 +1058,7 @@
}
writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
+ if ((d & Mov) || (dst.orig_val != dst.val) || isxchg) {
switch (dst.type) {
case OP_REG:
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
Luca
--
"Su cio` di cui non si puo` parlare e` bene tacere".
Ludwig Wittgenstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
> Luca Tettamanti wrote:
> >With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
> >normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
> >using xchg. With !GOOD_APIC and this patch:
> >
> >--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
> >+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
> >@@ -56,7 +56,8 @@
> > static __inline fastcall void native_apic_write_atomic(unsigned long reg,
> >unsigned long v)
> > {
> >-xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> >+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> >+*((volatile unsigned long *)(APIC_BASE+reg)) = v;
> > }
> >
> > static __inline fastcall unsigned long native_apic_read(unsigned long reg)
> >
> >The kernel boots fine.
> >
>
> Looking at the xchg emulation code, it seems fine, but clearly it
> isn't.
Btw, I've put a printk in x86_emulate.c, where it prepares the operands
for the xchg operations: all the write_atomic are hitting this point,
so the write is lost somewhere in cmpxchg_emulated->write_emulated.
Luca
--
Il dottore mi ha detto di smettere di fare cene intime per quattro.
A meno che non ci siamo altre tre persone.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
> Luca Tettamanti wrote:
> >With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
> >normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
> >using xchg. With !GOOD_APIC and this patch:
> >
> >--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
> >+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
> >@@ -56,7 +56,8 @@
> > static __inline fastcall void native_apic_write_atomic(unsigned long reg,
> >unsigned long v)
> > {
> >-xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> >+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> >+*((volatile unsigned long *)(APIC_BASE+reg)) = v;
> > }
> >
> > static __inline fastcall unsigned long native_apic_read(unsigned long reg)
> >
> >The kernel boots fine.
> >
>
> Looking at the xchg emulation code, it seems fine, but clearly it
> isn't. Can you add logging to the kernel apic driver and to the qemu
> device emulation (qemu/hw/apic.c, apic_mem_readl()/apic_mem_writel())
> and compare the results?
Done, but at this point I don't know what I'm looking at ;)
I'm attaching logs for working and non working kernels. I've made
apic_read_around() a nop in both cases since it doesn't influence the
outcome; the only difference is that working kernel writes directly to
the mapped APIC registers while the non-working one uses xchg.
As expected kernel side logs show zero differences (except for timer
calibration).
QEMU is a different story. The most obvious difference is that in
non-working case each write is preceded by a read at the same register
(due to xchg).
What is strange is that almost all the writes done using
apic_write_atomic are not hitting QEMU (see qemu.diff). In the log
there's only the read generated by the xchg.
For example, during timer calibration the kernel is doing:
write to 0x0b0
read from 0x390
but - in the non-working case - QEMU sees:
read from 0x0b0 (probably generated by xchg)
read from 0x390
but it doesn't see the write!
The write is not always lost:
apic_read: 0xd030 = 0x00050011
apic_write_atomic: 0xd370 = 0x000100fe
...
apic_read: fee00030 = 00050011
apic_read: fee00370 = 0001
apic_write: fee00370 = 000100fe
Luca
--
> While we're on all of this, are we going to change "tained" to some
> other less alarmist word?
"screwed" -- Alexander Viro
apic-logs.tar.bz2
Description: Binary data
Re: [kvm-devel] [BUG] Oops with KVM-27
Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
using xchg. With !GOOD_APIC and this patch:
--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
@@ -56,7 +56,8 @@
static __inline fastcall void native_apic_write_atomic(unsigned long reg,
unsigned long v)
{
-xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+*((volatile unsigned long *)(APIC_BASE+reg)) = v;
}
static __inline fastcall unsigned long native_apic_read(unsigned long reg)
The kernel boots fine.
Looking at the xchg emulation code, it seems fine, but clearly it
isn't. Can you add logging to the kernel apic driver and to the qemu
device emulation (qemu/hw/apic.c, apic_mem_readl()/apic_mem_writel())
and compare the results?
Done, but at this point I don't know what I'm looking at ;)
I'm attaching logs for working and non working kernels. I've made
apic_read_around() a nop in both cases since it doesn't influence the
outcome; the only difference is that working kernel writes directly to
the mapped APIC registers while the non-working one uses xchg.
As expected kernel side logs show zero differences (except for timer
calibration).
QEMU is a different story. The most obvious difference is that in
non-working case each write is preceded by a read at the same register
(due to xchg).
What is strange is that almost all the writes done using
apic_write_atomic are not hitting QEMU (see qemu.diff). In the log
there's only the read generated by the xchg.
For example, during timer calibration the kernel is doing:
write to 0x0b0
read from 0x390
but - in the non-working case - QEMU sees:
read from 0x0b0 (probably generated by xchg)
read from 0x390
but it doesn't see the write!
The write is not always lost:
apic_read: 0xd030 = 0x00050011
apic_write_atomic: 0xd370 = 0x000100fe
...
apic_read: fee00030 = 00050011
apic_read: fee00370 = 0001
apic_write: fee00370 = 000100fe
Luca
--
While we're on all of this, are we going to change tained to some
other less alarmist word?
screwed -- Alexander Viro
apic-logs.tar.bz2
Description: Binary data
Re: [kvm-devel] [BUG] Oops with KVM-27
Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
using xchg. With !GOOD_APIC and this patch:
--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
@@ -56,7 +56,8 @@
static __inline fastcall void native_apic_write_atomic(unsigned long reg,
unsigned long v)
{
-xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+*((volatile unsigned long *)(APIC_BASE+reg)) = v;
}
static __inline fastcall unsigned long native_apic_read(unsigned long reg)
The kernel boots fine.
Looking at the xchg emulation code, it seems fine, but clearly it
isn't.
Btw, I've put a printk in x86_emulate.c, where it prepares the operands
for the xchg operations: all the write_atomic are hitting this point,
so the write is lost somewhere in cmpxchg_emulated-write_emulated.
Luca
--
Il dottore mi ha detto di smettere di fare cene intime per quattro.
A meno che non ci siamo altre tre persone.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Fri, Jun 15, 2007 at 12:53:24AM +0200, Luca Tettamanti ha scritto:
Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
using xchg. With !GOOD_APIC and this patch:
--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
+++ include/asm-i386/apic.h2007-06-13 22:35:00.0 +0200
@@ -56,7 +56,8 @@
static __inline fastcall void native_apic_write_atomic(unsigned long reg,
unsigned long v)
{
- xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+//xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+ *((volatile unsigned long *)(APIC_BASE+reg)) = v;
}
static __inline fastcall unsigned long native_apic_read(unsigned long reg)
The kernel boots fine.
Looking at the xchg emulation code, it seems fine, but clearly it
isn't.
Btw, I've put a printk in x86_emulate.c, where it prepares the operands
for the xchg operations: all the write_atomic are hitting this point,
so the write is lost somewhere in cmpxchg_emulated-write_emulated.
Got it!
The emulator skips the writeback if the old value is unchanged, so the
apic doesn't see the write.
Forcing the writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
- if ((d Mov) || (dst.orig_val != dst.val) || isxchg) {
seems to fix the issue :D I'm not sure that fix is correct though. This
is the patch I'm using:
--- a/kernel/x86_emulate.c 2007-06-03 10:31:15.0 +0200
+++ b/kernel/x86_emulate.c 2007-06-15 01:12:12.0 +0200
@@ -486,6 +486,7 @@
unsigned long _regs[NR_VCPU_REGS];
unsigned long _eip = ctxt-vcpu-rip, _eflags = ctxt-eflags;
unsigned long modrm_val = 0;
+ int isxchg = 0;
memcpy(_regs, ctxt-vcpu-regs, sizeof _regs);
@@ -912,6 +913,7 @@
break;
case 0x86 ... 0x87: /* xchg */
/* Write back the register source. */
+ isxchg = 1;
switch (dst.bytes) {
case 1:
*(u8 *) src.ptr = (u8) dst.val;
@@ -1056,7 +1058,7 @@
}
writeback:
- if ((d Mov) || (dst.orig_val != dst.val)) {
+ if ((d Mov) || (dst.orig_val != dst.val) || isxchg) {
switch (dst.type) {
case OP_REG:
/* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
Luca
--
Su cio` di cui non si puo` parlare e` bene tacere.
Ludwig Wittgenstein
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Wed, Jun 13, 2007 at 11:59:25AM +0300, Avi Kivity ha scritto:
> Luca Tettamanti wrote:
> >Il Mon, Jun 11, 2007 at 10:44:45AM +0300, Avi Kivity ha scritto:
> >
> >>Luca wrote:
> >>
> >>>>I've managed to reproduce this on kvm-21 (it takes many boots for this
> >>>>to happen, but it does eventually).
> >>>>
> >>>Hum, any clue on the cause?
> >>>
> >>From what I've seen, it's the new Linux clocksource code.
> >>
> >>
> >>>Should I test older versions?
> >>>
> >>They're unlikely to be better. Instead, it would be best to see what
> >>the guest is doing.
> >>
> >
> >RCU is not working. Network initialization hangs because it happens to
> >be the first RCU user.
> >The guest is stuck waiting for RCU syncronization:
> >
> >[4.992207] [] synchronize_rcu+0x4e/0x80
> >[4.994379] [] wakeme_after_rcu+0x0/0x8
> >[4.996521] [] synchronize_net+0x64/0x8c
> >[4.998678] [] inet_register_protosw+0xef/0x151
> >[5.000984] [] inet_init+0x1cd/0x498
> >
> >wait_for_completion() in synchronize_rcu() calls schedule() and the
> >completion is never signaled (wakeme_after_rcu is never called).
> >The completion AFAICS would be signaled via rcu_process_callbacks(),
> >which is called in tasklet context.
> >Scheduler and completion are working fine since they're used in other
> >part of the kernel without problems.
> >
> >To recap:
> >
> >i686 F7 kernel: always works.
> >
> >i586 F7 kernel: sometime hangs due to RCU problems. When it does work
> >it's because the LAPIC is disabled on boot:
> >
> >Using local APIC timer interrupts.
> >calibrating APIC timer ...
> >... lapic delta = 25745109
> >... PM timer delta = 0
> >. delta 25745109
> >. mult: 1105912110
> >. calibration result: 4119217
> >. CPU clock speed is 8794.0417 MHz.
> >. host bus clock speed is 4119.0217 MHz.
> >... verify APIC timer
> >... jiffies delta = 103
> >APIC timer disabled due to verification failure.
> >
> >When it doesn't work LAPIC passes the test:
> >
> >[1.304717] Using local APIC timer interrupts.
> >[1.304719] calibrating APIC timer ...
> >[1.718823] ... lapic delta = 25251444
> >[1.720582] ... PM timer delta = 0
> >[1.722219] . delta 25251444
> >[1.723827] . mult: 1084706136
> >[1.725470] . calibration result: 4040231
> >[1.727374] . CPU clock speed is 8625.0780 MHz.
> >[1.729396] . host bus clock speed is 4040.0231 MHz.
> >[1.731540] ... verify APIC timer
> >[2.158342] ... jiffies delta = 102
> >[2.160035] ... jiffies result ok
> >
> >i586 F7 kernel, with 'nolapic': always works.
> >
>
> Can you check which .config option causes it (a special type of
> bisecting...)?
>
> This looks likely based on your findings:
>
> -CONFIG_X86_ALIGNMENT_16=y
> +CONFIG_X86_GOOD_APIC=y
> CONFIG_X86_INTEL_USERCOPY=y
> +CONFIG_X86_USE_PPRO_CHECKSUM=y
> +CONFIG_X86_TSC=y
>
> I expect it's not directly related to i586 vs i686.
And the winner is... CONFIG_X86_GOOD_APIC ;-)
I think that !GOOD_APIC is a workaround for "11AP erratum in Pentium
Processor Specification Update" aka read-before-write bug.
The config symbol is used in include/asm-i386/apic.h:
#ifdef CONFIG_X86_GOOD_APIC
# define FORCE_READ_AROUND_WRITE 0
# define apic_read_around(x)
# define apic_write_around(x,y) apic_write((x),(y))
#else
# define FORCE_READ_AROUND_WRITE 1
# define apic_read_around(x) apic_read(x)
# define apic_write_around(x,y) apic_write_atomic((x),(y))
#endif
With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
using xchg. With !GOOD_APIC and this patch:
--- include/asm-i386/apic.h~2007-04-26 05:08:32.0 +0200
+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
@@ -56,7 +56,8 @@
static __inline fastcall void native_apic_write_atomic(unsigned long reg,
unsigned long v)
{
- xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+ *((volatile unsigned long *)(APIC_BASE+reg)) = v;
}
static __inline fastcall unsigned long native_apic_read(unsigned long reg)
The kernel boots fine.
Luca
--
"Sei l'unica donna della mia vita".
(Adamo)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Wed, Jun 13, 2007 at 11:59:25AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
Il Mon, Jun 11, 2007 at 10:44:45AM +0300, Avi Kivity ha scritto:
Luca wrote:
I've managed to reproduce this on kvm-21 (it takes many boots for this
to happen, but it does eventually).
Hum, any clue on the cause?
From what I've seen, it's the new Linux clocksource code.
Should I test older versions?
They're unlikely to be better. Instead, it would be best to see what
the guest is doing.
RCU is not working. Network initialization hangs because it happens to
be the first RCU user.
The guest is stuck waiting for RCU syncronization:
[4.992207] [c04321c5] synchronize_rcu+0x4e/0x80
[4.994379] [c0431db5] wakeme_after_rcu+0x0/0x8
[4.996521] [c0599ad1] synchronize_net+0x64/0x8c
[4.998678] [c05d70e0] inet_register_protosw+0xef/0x151
[5.000984] [c072d79e] inet_init+0x1cd/0x498
wait_for_completion() in synchronize_rcu() calls schedule() and the
completion is never signaled (wakeme_after_rcu is never called).
The completion AFAICS would be signaled via rcu_process_callbacks(),
which is called in tasklet context.
Scheduler and completion are working fine since they're used in other
part of the kernel without problems.
To recap:
i686 F7 kernel: always works.
i586 F7 kernel: sometime hangs due to RCU problems. When it does work
it's because the LAPIC is disabled on boot:
Using local APIC timer interrupts.
calibrating APIC timer ...
... lapic delta = 25745109
... PM timer delta = 0
. delta 25745109
. mult: 1105912110
. calibration result: 4119217
. CPU clock speed is 8794.0417 MHz.
. host bus clock speed is 4119.0217 MHz.
... verify APIC timer
... jiffies delta = 103
APIC timer disabled due to verification failure.
When it doesn't work LAPIC passes the test:
[1.304717] Using local APIC timer interrupts.
[1.304719] calibrating APIC timer ...
[1.718823] ... lapic delta = 25251444
[1.720582] ... PM timer delta = 0
[1.722219] . delta 25251444
[1.723827] . mult: 1084706136
[1.725470] . calibration result: 4040231
[1.727374] . CPU clock speed is 8625.0780 MHz.
[1.729396] . host bus clock speed is 4040.0231 MHz.
[1.731540] ... verify APIC timer
[2.158342] ... jiffies delta = 102
[2.160035] ... jiffies result ok
i586 F7 kernel, with 'nolapic': always works.
Can you check which .config option causes it (a special type of
bisecting...)?
This looks likely based on your findings:
-CONFIG_X86_ALIGNMENT_16=y
+CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
+CONFIG_X86_USE_PPRO_CHECKSUM=y
+CONFIG_X86_TSC=y
I expect it's not directly related to i586 vs i686.
And the winner is... CONFIG_X86_GOOD_APIC ;-)
I think that !GOOD_APIC is a workaround for 11AP erratum in Pentium
Processor Specification Update aka read-before-write bug.
The config symbol is used in include/asm-i386/apic.h:
#ifdef CONFIG_X86_GOOD_APIC
# define FORCE_READ_AROUND_WRITE 0
# define apic_read_around(x)
# define apic_write_around(x,y) apic_write((x),(y))
#else
# define FORCE_READ_AROUND_WRITE 1
# define apic_read_around(x) apic_read(x)
# define apic_write_around(x,y) apic_write_atomic((x),(y))
#endif
With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
using xchg. With !GOOD_APIC and this patch:
--- include/asm-i386/apic.h~2007-04-26 05:08:32.0 +0200
+++ include/asm-i386/apic.h 2007-06-13 22:35:00.0 +0200
@@ -56,7 +56,8 @@
static __inline fastcall void native_apic_write_atomic(unsigned long reg,
unsigned long v)
{
- xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+// xchg((volatile unsigned long *)(APIC_BASE+reg), v);
+ *((volatile unsigned long *)(APIC_BASE+reg)) = v;
}
static __inline fastcall unsigned long native_apic_read(unsigned long reg)
The kernel boots fine.
Luca
--
Sei l'unica donna della mia vita.
(Adamo)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Mon, Jun 11, 2007 at 10:44:45AM +0300, Avi Kivity ha scritto: > Luca wrote: > >> > >>I've managed to reproduce this on kvm-21 (it takes many boots for this > >>to happen, but it does eventually). > > > >Hum, any clue on the cause? > > From what I've seen, it's the new Linux clocksource code. > > >Should I test older versions? > > They're unlikely to be better. Instead, it would be best to see what > the guest is doing. RCU is not working. Network initialization hangs because it happens to be the first RCU user. The guest is stuck waiting for RCU syncronization: [4.992207] [] synchronize_rcu+0x4e/0x80 [4.994379] [] wakeme_after_rcu+0x0/0x8 [4.996521] [] synchronize_net+0x64/0x8c [4.998678] [] inet_register_protosw+0xef/0x151 [5.000984] [] inet_init+0x1cd/0x498 wait_for_completion() in synchronize_rcu() calls schedule() and the completion is never signaled (wakeme_after_rcu is never called). The completion AFAICS would be signaled via rcu_process_callbacks(), which is called in tasklet context. Scheduler and completion are working fine since they're used in other part of the kernel without problems. To recap: i686 F7 kernel: always works. i586 F7 kernel: sometime hangs due to RCU problems. When it does work it's because the LAPIC is disabled on boot: Using local APIC timer interrupts. calibrating APIC timer ... ... lapic delta = 25745109 ... PM timer delta = 0 . delta 25745109 . mult: 1105912110 . calibration result: 4119217 . CPU clock speed is 8794.0417 MHz. . host bus clock speed is 4119.0217 MHz. ... verify APIC timer ... jiffies delta = 103 APIC timer disabled due to verification failure. When it doesn't work LAPIC passes the test: [1.304717] Using local APIC timer interrupts. [1.304719] calibrating APIC timer ... [1.718823] ... lapic delta = 25251444 [1.720582] ... PM timer delta = 0 [1.722219] . delta 25251444 [1.723827] . mult: 1084706136 [1.725470] . calibration result: 4040231 [1.727374] . CPU clock speed is 8625.0780 MHz. [1.729396] . host bus clock speed is 4040.0231 MHz. [1.731540] ... verify APIC timer [2.158342] ... jiffies delta = 102 [2.160035] ... jiffies result ok i586 F7 kernel, with 'nolapic': always works. Luca -- Sbagliare è umano, ma per incasinare davvero le cose serve un computer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Mon, Jun 11, 2007 at 10:44:45AM +0300, Avi Kivity ha scritto: Luca wrote: I've managed to reproduce this on kvm-21 (it takes many boots for this to happen, but it does eventually). Hum, any clue on the cause? From what I've seen, it's the new Linux clocksource code. Should I test older versions? They're unlikely to be better. Instead, it would be best to see what the guest is doing. RCU is not working. Network initialization hangs because it happens to be the first RCU user. The guest is stuck waiting for RCU syncronization: [4.992207] [c04321c5] synchronize_rcu+0x4e/0x80 [4.994379] [c0431db5] wakeme_after_rcu+0x0/0x8 [4.996521] [c0599ad1] synchronize_net+0x64/0x8c [4.998678] [c05d70e0] inet_register_protosw+0xef/0x151 [5.000984] [c072d79e] inet_init+0x1cd/0x498 wait_for_completion() in synchronize_rcu() calls schedule() and the completion is never signaled (wakeme_after_rcu is never called). The completion AFAICS would be signaled via rcu_process_callbacks(), which is called in tasklet context. Scheduler and completion are working fine since they're used in other part of the kernel without problems. To recap: i686 F7 kernel: always works. i586 F7 kernel: sometime hangs due to RCU problems. When it does work it's because the LAPIC is disabled on boot: Using local APIC timer interrupts. calibrating APIC timer ... ... lapic delta = 25745109 ... PM timer delta = 0 . delta 25745109 . mult: 1105912110 . calibration result: 4119217 . CPU clock speed is 8794.0417 MHz. . host bus clock speed is 4119.0217 MHz. ... verify APIC timer ... jiffies delta = 103 APIC timer disabled due to verification failure. When it doesn't work LAPIC passes the test: [1.304717] Using local APIC timer interrupts. [1.304719] calibrating APIC timer ... [1.718823] ... lapic delta = 25251444 [1.720582] ... PM timer delta = 0 [1.722219] . delta 25251444 [1.723827] . mult: 1084706136 [1.725470] . calibration result: 4040231 [1.727374] . CPU clock speed is 8625.0780 MHz. [1.729396] . host bus clock speed is 4040.0231 MHz. [1.731540] ... verify APIC timer [2.158342] ... jiffies delta = 102 [2.160035] ... jiffies result ok i586 F7 kernel, with 'nolapic': always works. Luca -- Sbagliare è umano, ma per incasinare davvero le cose serve un computer. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Il Mon, Jun 04, 2007 at 11:51:10PM +0300, Avi Kivity ha scritto: > > While doing repeated tests with the installer I ran into another > > (unrelated) problem. Sometimes the guest kernel hangs at boot at: > > > > NET: Registered protocol family 2 > > > > with any kind of networking options (except for -net none, which works). > > With -no-kvm it boots with any networking option. > > > > > > Can you try to pin the guest on a single core with taskset: > >taskset 1 qemu ... Doesn't help. What works is 'nolapic', i.e. disabling the local APIC on the guest kernel. I've also tried disabling TSC (notsc) and forcing PIT as the clocksource (clocksouce=pit clock=pit); neither of them helped. Luca -- Il dottore mi ha detto di smettere di fare cene intime per quattro. A meno che non ci siamo altre tre persone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Hi, Il Mon, Jun 04, 2007 at 12:35:37PM +0300, Avi Kivity ha scritto: > Luca Tettamanti wrote: > >Hello, > >my kernel just exploded :) > > > >The host is running 2.6-git-current, with KVM modules from KVM-27 > >package. kernel is 32bit, SMP, with PREEMPT enabled, no HIGHMEM (but I'm > >using CONFIG_VMSPLIT_3G_OPT=y). The CPU is a Core2 (hence I'm using > >kvm-intel). > >Guest was a Fedora7 setup DVD, which died somewhere during the > >installation (anaconda was already active at that point). Bad news is > >that I cannot reproduce the bug :| > > > Fortunately the trace clearly shows the problem (out of mmu working > memory on guest context switch). The attached patch should fix it. Let > me know if it works for you. It turned out that it was somewhat reproducible with fedora installer. With your patch it doesn't oops anymore. While doing repeated tests with the installer I ran into another (unrelated) problem. Sometimes the guest kernel hangs at boot at: NET: Registered protocol family 2 with any kind of networking options (except for -net none, which works). With -no-kvm it boots with any networking option. The only difference in dmesg is that when KVM is enable the guest uses the TSC: NetLabel: unlabeled traffic allowed by default -Time: tsc clocksource has been installed. PCI: Ignore bogus resource 6 [0:0] of :00:02.0 For reference this is the command line that I'm using: ./kvm-27/qemu/i386-softmmu/qemu -hda /home/kronos/tmp/fedora.img -cdrom /home/kronos/tmp/boot.iso -boot d -net tap -net nic -m 256 and boot.iso is the fedora7 net install image (you can find it on any mirror: fedora/linux/releases/7/Fedora/arch/os/images/boot.iso). The guest kernel doesn't respond to sysrq, so I don't known exactly where it's hanging. The stack trace on the host seems rather uninteresting: qemu S 0002 2404 18905 7312 (NOTLB) dca4db48 0086 0002 b0478900 eec4a0f0 b02f418b b0478900 000a eec4a0f0 ef31ca70 267db8c3 08c7 3ea3 eec4a1fc b1810980 efcc62a0 b0478900 b0129580 0292 dca4db58 0023935c Call Trace: [] _spin_unlock_irqrestore+0x34/0x58 [] __mod_timer+0x9d/0xa7 [] schedule_timeout+0x70/0x8d [] _spin_unlock_irqrestore+0x34/0x58 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x399/0x3e7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] free_poll_entry+0xe/0x16 [] poll_freewait+0x18/0x4c [] do_sys_poll+0x302/0x327 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] task_rq_lock+0x36/0x5d [] _spin_lock+0x33/0x3e [] _spin_unlock_irqrestore+0x40/0x58 [] try_to_wake_up+0x325/0x32f [] mark_held_locks+0x39/0x53 [] _spin_unlock_irqrestore+0x34/0x58 [] restore_nocheck+0x12/0x15 [] trace_hardirqs_on+0x11a/0x13d [] do_IRQ+0xc4/0xde [] restore_nocheck+0x12/0x15 [] core_sys_select+0x2ee/0x30f [] setup_sigcontext+0x105/0x189 [] _spin_unlock_irq+0x20/0x41 [] trace_hardirqs_on+0x11a/0x13d [] do_notify_resume+0x5d1/0x611 [] _spin_unlock_irq+0x2b/0x41 [] do_notify_resume+0x52f/0x611 [] restore_nocheck+0x12/0x15 [] convert_fxsr_from_user+0x26/0xe6 [] sys_select+0xa4/0x187 [] restore_nocheck+0x12/0x15 [] trace_hardirqs_on+0x11a/0x13d [] syscall_call+0x7/0xb === qemu S CF9E5DC0 2996 18911 7312 (NOTLB) cf9e5dd4 0082 0002 cf9e5dc0 cf9e5dbc b013b1ee cf9e5ea0 0007 0001 d252b4f0 b194c030 70a8bf29 08ac a554 d252b5fc b181a980 efcc62a0 00232330 0003 cf9e5ea0 efcc62d4 Call Trace: [] trace_hardirqs_on+0x11a/0x13d [] futex_wait+0x251/0x3ed [] hrtimer_wakeup+0x0/0x18 [] futex_wait+0x242/0x3ed [] default_wake_function+0x0/0xc [] do_futex+0x6c/0xaad [] sys_rt_sigqueueinfo+0x44/0x4e [] getnstimeofday+0x30/0xbe [] ktime_get_ts+0x16/0x44 [] sys_futex+0xc8/0xda [] syscall_call+0x7/0xb === I'm attaching the dmesg for both -kvm and -no-kvm cases. Luca -- "La teoria e` quando sappiamo come funzionano le cose ma non funzionano. La pratica e` quando le cose funzionano ma non sappiamo perche`. Abbiamo unito la teoria e la pratica: le cose non funzionano piu` e non sappiamo il perche`." -- A. Einstein Linux version 2.6.21-1.3194.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Wed May 23 22:11:19 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009fc00 size: 0400 end: 000a type: 2 copy_e820_map() start: 000e8000 size: 00018000 end: 0010 type: 2 copy_e820_map() start: 0010 size: 0ff0 end: 1000 type: 1 copy_e820_map() type is E820_RAM copy_
Re: [kvm-devel] [BUG] Oops with KVM-27
Hi, Il Mon, Jun 04, 2007 at 12:35:37PM +0300, Avi Kivity ha scritto: Luca Tettamanti wrote: Hello, my kernel just exploded :) The host is running 2.6-git-current, with KVM modules from KVM-27 package. kernel is 32bit, SMP, with PREEMPT enabled, no HIGHMEM (but I'm using CONFIG_VMSPLIT_3G_OPT=y). The CPU is a Core2 (hence I'm using kvm-intel). Guest was a Fedora7 setup DVD, which died somewhere during the installation (anaconda was already active at that point). Bad news is that I cannot reproduce the bug :| Fortunately the trace clearly shows the problem (out of mmu working memory on guest context switch). The attached patch should fix it. Let me know if it works for you. It turned out that it was somewhat reproducible with fedora installer. With your patch it doesn't oops anymore. While doing repeated tests with the installer I ran into another (unrelated) problem. Sometimes the guest kernel hangs at boot at: NET: Registered protocol family 2 with any kind of networking options (except for -net none, which works). With -no-kvm it boots with any networking option. The only difference in dmesg is that when KVM is enable the guest uses the TSC: NetLabel: unlabeled traffic allowed by default -Time: tsc clocksource has been installed. PCI: Ignore bogus resource 6 [0:0] of :00:02.0 For reference this is the command line that I'm using: ./kvm-27/qemu/i386-softmmu/qemu -hda /home/kronos/tmp/fedora.img -cdrom /home/kronos/tmp/boot.iso -boot d -net tap -net nic -m 256 and boot.iso is the fedora7 net install image (you can find it on any mirror: fedora/linux/releases/7/Fedora/arch/os/images/boot.iso). The guest kernel doesn't respond to sysrq, so I don't known exactly where it's hanging. The stack trace on the host seems rather uninteresting: qemu S 0002 2404 18905 7312 (NOTLB) dca4db48 0086 0002 b0478900 eec4a0f0 b02f418b b0478900 000a eec4a0f0 ef31ca70 267db8c3 08c7 3ea3 eec4a1fc b1810980 efcc62a0 b0478900 b0129580 0292 dca4db58 0023935c Call Trace: [b02f418b] _spin_unlock_irqrestore+0x34/0x58 [b0129580] __mod_timer+0x9d/0xa7 [b02f2258] schedule_timeout+0x70/0x8d [b02f418b] _spin_unlock_irqrestore+0x34/0x58 [b01291e0] process_timeout+0x0/0x5 [b02f2253] schedule_timeout+0x6b/0x8d [b0171eb1] do_select+0x399/0x3e7 [b0172496] __pollwait+0x0/0xac [b011c720] default_wake_function+0x0/0xc [b0171766] free_poll_entry+0xe/0x16 [b0171786] poll_freewait+0x18/0x4c [b0171abc] do_sys_poll+0x302/0x327 [b0172496] __pollwait+0x0/0xac [b011c720] default_wake_function+0x0/0xc [b011b26a] task_rq_lock+0x36/0x5d [b02f3c59] _spin_lock+0x33/0x3e [b02f4197] _spin_unlock_irqrestore+0x40/0x58 [b011c716] try_to_wake_up+0x325/0x32f [b013b017] mark_held_locks+0x39/0x53 [b02f418b] _spin_unlock_irqrestore+0x34/0x58 [b0103ec0] restore_nocheck+0x12/0x15 [b013b1ee] trace_hardirqs_on+0x11a/0x13d [b010679a] do_IRQ+0xc4/0xde [b0103ec0] restore_nocheck+0x12/0x15 [b01721ed] core_sys_select+0x2ee/0x30f [b0103189] setup_sigcontext+0x105/0x189 [b02f41cf] _spin_unlock_irq+0x20/0x41 [b013b1ee] trace_hardirqs_on+0x11a/0x13d [b0103a56] do_notify_resume+0x5d1/0x611 [b02f41da] _spin_unlock_irq+0x2b/0x41 [b01039b4] do_notify_resume+0x52f/0x611 [b0103ec0] restore_nocheck+0x12/0x15 [b010898b] convert_fxsr_from_user+0x26/0xe6 [b01725e6] sys_select+0xa4/0x187 [b0103ec0] restore_nocheck+0x12/0x15 [b013b1ee] trace_hardirqs_on+0x11a/0x13d [b0103e78] syscall_call+0x7/0xb === qemu S CF9E5DC0 2996 18911 7312 (NOTLB) cf9e5dd4 0082 0002 cf9e5dc0 cf9e5dbc b013b1ee cf9e5ea0 0007 0001 d252b4f0 b194c030 70a8bf29 08ac a554 d252b5fc b181a980 efcc62a0 00232330 0003 cf9e5ea0 efcc62d4 Call Trace: [b013b1ee] trace_hardirqs_on+0x11a/0x13d [b013de28] futex_wait+0x251/0x3ed [b0134156] hrtimer_wakeup+0x0/0x18 [b013de19] futex_wait+0x242/0x3ed [b011c720] default_wake_function+0x0/0xc [b013e906] do_futex+0x6c/0xaad [b012acf7] sys_rt_sigqueueinfo+0x44/0x4e [b0135a4e] getnstimeofday+0x30/0xbe [b0134627] ktime_get_ts+0x16/0x44 [b013f40f] sys_futex+0xc8/0xda [b0103e78] syscall_call+0x7/0xb === I'm attaching the dmesg for both -kvm and -no-kvm cases. Luca -- La teoria e` quando sappiamo come funzionano le cose ma non funzionano. La pratica e` quando le cose funzionano ma non sappiamo perche`. Abbiamo unito la teoria e la pratica: le cose non funzionano piu` e non sappiamo il perche`. -- A. Einstein Linux version 2.6.21-1.3194.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Wed May 23 22:11:19 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009fc00 size
Re: [kvm-devel] [BUG] Oops with KVM-27
Il Mon, Jun 04, 2007 at 11:51:10PM +0300, Avi Kivity ha scritto: While doing repeated tests with the installer I ran into another (unrelated) problem. Sometimes the guest kernel hangs at boot at: NET: Registered protocol family 2 with any kind of networking options (except for -net none, which works). With -no-kvm it boots with any networking option. Can you try to pin the guest on a single core with taskset: taskset 1 qemu ... Doesn't help. What works is 'nolapic', i.e. disabling the local APIC on the guest kernel. I've also tried disabling TSC (notsc) and forcing PIT as the clocksource (clocksouce=pit clock=pit); neither of them helped. Luca -- Il dottore mi ha detto di smettere di fare cene intime per quattro. A meno che non ci siamo altre tre persone. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] Oops with KVM-27
Hello,
my kernel just exploded :)
The host is running 2.6-git-current, with KVM modules from KVM-27
package. kernel is 32bit, SMP, with PREEMPT enabled, no HIGHMEM (but I'm
using CONFIG_VMSPLIT_3G_OPT=y). The CPU is a Core2 (hence I'm using
kvm-intel).
Guest was a Fedora7 setup DVD, which died somewhere during the
installation (anaconda was already active at that point). Bad news is
that I cannot reproduce the bug :|
This is the OOPS:
kvm: emulating exchange as write
[ cut here ]
kernel BUG at /root/kvm-27/kernel/mmu.c:276!
invalid opcode: [#1]
PREEMPT SMP
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack ip_tables x_tables rtc_core rtc_lib tun kvm_intel kvm radeon drm
binfmt_misc nfs button cpufreq_stats cpufreq_userspace cpufreq_powersave
cpufreq_conservative cls_u32 cls_route sch_sfq sch_cbq des cbc blkcipher sha1
md5 hmac crypto_hash cryptomgr crypto_algapi nfsd exportfs lockd sunrpc vfat
fat nls_base fuse cpufreq_ondemand acpi_cpufreq freq_table i2c_isa ipv6
snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ohci1394 snd
intel_agp ieee1394 parport_pc atl1 uhci_hcd ehci_hcd i2c_i801 agpgart soundcore
snd_page_alloc parport e100 usbcore mii dm_snapshot dm_mod thermal processor
fan pata_ali sata_uli reiserfs xfs
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.22-rc3-libata-gf285e3d3-dirty #67)
EIP is at mmu_memory_cache_alloc+0xd/0x36 [kvm]
eax: ebx: ecx: db19f2f4 edx: 002c
esi: 0322 edi: db19e528 ebp: 3d1d esp: ca73fc80
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process qemu (pid: 2680, ti=ca73f000 task=cc3160f0 task.ti=ca73f000)
Stack: f24aa0e2 db19e528 f24ae1eb db19f0b4 e21458e8 b129b4a0
db19f0b4 3d1d 0018 c000 f24ae3ea 0002
0003 db19f0b4 3d1d 0003 0003 f24ae4b6 db19f0b4
Call Trace:
[] gfn_to_page+0x14/0x27 [kvm]
[] kvm_mmu_get_page+0x1b2/0x31c [kvm]
[] mmu_alloc_roots+0x95/0xf0 [kvm]
[] paging_new_cr3+0x21/0x48 [kvm]
[] set_cr3+0x82/0x8c [kvm]
[] handle_cr+0xf8/0x253 [kvm_intel]
[] handle_exception+0x120/0x208 [kvm_intel]
[] vmx_vcpu_run+0x59d/0x6c6 [kvm_intel]
[] __mutex_lock_slowpath+0x259/0x261
[] vmx_vcpu_load+0x2a/0xcc [kvm_intel]
[] kvm_vcpu_ioctl+0x29a/0xcff [kvm]
[] sock_common_recvmsg+0x3e/0x54
[] sock_recvmsg+0xcf/0xe8
[] sock_sendmsg+0xbc/0xd4
[] autoremove_wake_function+0x0/0x35
[] core_sys_select+0x234/0x30f
[] setup_sigcontext+0x105/0x189
[] _spin_unlock_irq+0x20/0x41
[] trace_hardirqs_on+0x11a/0x13d
[] do_notify_resume+0x5d1/0x611
[] _spin_unlock_irq+0x2b/0x41
[] do_notify_resume+0x52f/0x611
[] convert_fxsr_from_user+0x26/0xe6
[] kvm_vcpu_ioctl+0x0/0xcff [kvm]
[] do_ioctl+0x1f/0x62
[] vfs_ioctl+0x237/0x249
[] sys_ioctl+0x33/0x4d
[] syscall_call+0x7/0xb
===
Code: 01 00 00 e8 ce ff ff ff 8d 83 ec 01 00 00 81 c3 40 02 00 00 e8 bd ff ff
ff 89 d8 5b eb b8 57 89 c1 53 83 ec 04 8b 00 85 c0 75 04 <0f> 0b eb fe 48 8b 5c
81 04 89 01 89 d1 31 c0 c1 e9 02 89 df f3
EIP: [] mmu_memory_cache_alloc+0xd/0x36 [kvm] SS:ESP 0068:ca73fc80
note: qemu[2680] exited with preempt_count 2
BUG: sleeping function called from invalid context at
/home/kronos/src/linux-2.6.git/kernel/rwsem.c:20
in_atomic():1, irqs_disabled():0
INFO: lockdep is turned off.
[] down_read+0x15/0x49
[] futex_wake+0x19/0xb3
[] do_futex+0x7f/0xaad
[] vsnprintf+0x450/0x48c
[] _spin_unlock_irqrestore+0x40/0x58
[] release_console_sem+0x1a0/0x1b9
[] vprintk+0x2b7/0x305
[] try_to_wake_up+0x325/0x32f
[] sys_futex+0xc8/0xda
[] mm_release+0x81/0x87
[] exit_mm+0x13/0xd6
[] do_exit+0x1bc/0x69b
[] die+0x1e5/0x211
[] do_invalid_op+0x0/0x8a
[] do_invalid_op+0x81/0x8a
[] mmu_memory_cache_alloc+0xd/0x36 [kvm]
[] page_header_update_slot+0x1e/0x4b [kvm]
[] paging32_set_pte_common+0x269/0x2a1 [kvm]
[] error_code+0x72/0x78
[] mmu_memory_cache_alloc+0xd/0x36 [kvm]
[] gfn_to_page+0x14/0x27 [kvm]
[] kvm_mmu_get_page+0x1b2/0x31c [kvm]
[] mmu_alloc_roots+0x95/0xf0 [kvm]
[] paging_new_cr3+0x21/0x48 [kvm]
[] set_cr3+0x82/0x8c [kvm]
[] handle_cr+0xf8/0x253 [kvm_intel]
[] handle_exception+0x120/0x208 [kvm_intel]
[] vmx_vcpu_run+0x59d/0x6c6 [kvm_intel]
[] __mutex_lock_slowpath+0x259/0x261
[] vmx_vcpu_load+0x2a/0xcc [kvm_intel]
[] kvm_vcpu_ioctl+0x29a/0xcff [kvm]
[] sock_common_recvmsg+0x3e/0x54
[] sock_recvmsg+0xcf/0xe8
[] sock_sendmsg+0xbc/0xd4
[] autoremove_wake_function+0x0/0x35
[] core_sys_select+0x234/0x30f
[] setup_sigcontext+0x105/0x189
[] _spin_unlock_irq+0x20/0x41
[] trace_hardirqs_on+0x11a/0x13d
[] do_notify_resume+0x5d1/0x611
[] _spin_unlock_irq+0x2b/0x41
[] do_notify_resume+0x52f/0x611
[] convert_fxsr_from_user+0x26/0xe6
[] kvm_vcpu_ioctl+0x0/0xcff [kvm]
[] do_ioctl+0x1f/0x62
[] vfs_ioctl+0x237/0x249
[] sys_ioctl+0x33/0x4d
[] syscall_call+0x7/0xb
===
Luca
--
Il coraggio non mi manca.
E` la
[BUG] Oops with KVM-27
Hello,
my kernel just exploded :)
The host is running 2.6-git-current, with KVM modules from KVM-27
package. kernel is 32bit, SMP, with PREEMPT enabled, no HIGHMEM (but I'm
using CONFIG_VMSPLIT_3G_OPT=y). The CPU is a Core2 (hence I'm using
kvm-intel).
Guest was a Fedora7 setup DVD, which died somewhere during the
installation (anaconda was already active at that point). Bad news is
that I cannot reproduce the bug :|
This is the OOPS:
kvm: emulating exchange as write
[ cut here ]
kernel BUG at /root/kvm-27/kernel/mmu.c:276!
invalid opcode: [#1]
PREEMPT SMP
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack ip_tables x_tables rtc_core rtc_lib tun kvm_intel kvm radeon drm
binfmt_misc nfs button cpufreq_stats cpufreq_userspace cpufreq_powersave
cpufreq_conservative cls_u32 cls_route sch_sfq sch_cbq des cbc blkcipher sha1
md5 hmac crypto_hash cryptomgr crypto_algapi nfsd exportfs lockd sunrpc vfat
fat nls_base fuse cpufreq_ondemand acpi_cpufreq freq_table i2c_isa ipv6
snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ohci1394 snd
intel_agp ieee1394 parport_pc atl1 uhci_hcd ehci_hcd i2c_i801 agpgart soundcore
snd_page_alloc parport e100 usbcore mii dm_snapshot dm_mod thermal processor
fan pata_ali sata_uli reiserfs xfs
CPU:0
EIP:0060:[f24ad9b6]Not tainted VLI
EFLAGS: 00010246 (2.6.22-rc3-libata-gf285e3d3-dirty #67)
EIP is at mmu_memory_cache_alloc+0xd/0x36 [kvm]
eax: ebx: ecx: db19f2f4 edx: 002c
esi: 0322 edi: db19e528 ebp: 3d1d esp: ca73fc80
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process qemu (pid: 2680, ti=ca73f000 task=cc3160f0 task.ti=ca73f000)
Stack: f24aa0e2 db19e528 f24ae1eb db19f0b4 e21458e8 b129b4a0
db19f0b4 3d1d 0018 c000 f24ae3ea 0002
0003 db19f0b4 3d1d 0003 0003 f24ae4b6 db19f0b4
Call Trace:
[f24aa0e2] gfn_to_page+0x14/0x27 [kvm]
[f24ae1eb] kvm_mmu_get_page+0x1b2/0x31c [kvm]
[f24ae3ea] mmu_alloc_roots+0x95/0xf0 [kvm]
[f24ae4b6] paging_new_cr3+0x21/0x48 [kvm]
[f24aab16] set_cr3+0x82/0x8c [kvm]
[f249b51d] handle_cr+0xf8/0x253 [kvm_intel]
[f249b1b5] handle_exception+0x120/0x208 [kvm_intel]
[f249af6c] vmx_vcpu_run+0x59d/0x6c6 [kvm_intel]
[b02f2bb6] __mutex_lock_slowpath+0x259/0x261
[f2499f34] vmx_vcpu_load+0x2a/0xcc [kvm_intel]
[f24ac7d1] kvm_vcpu_ioctl+0x29a/0xcff [kvm]
[b0294ea5] sock_common_recvmsg+0x3e/0x54
[b029396f] sock_recvmsg+0xcf/0xe8
[b0293a44] sock_sendmsg+0xbc/0xd4
[b0131c35] autoremove_wake_function+0x0/0x35
[b0172133] core_sys_select+0x234/0x30f
[b0103189] setup_sigcontext+0x105/0x189
[b02f41cf] _spin_unlock_irq+0x20/0x41
[b013b1ee] trace_hardirqs_on+0x11a/0x13d
[b0103a56] do_notify_resume+0x5d1/0x611
[b02f41da] _spin_unlock_irq+0x2b/0x41
[b01039b4] do_notify_resume+0x52f/0x611
[b010898b] convert_fxsr_from_user+0x26/0xe6
[f24ac537] kvm_vcpu_ioctl+0x0/0xcff [kvm]
[b0171007] do_ioctl+0x1f/0x62
[b0171281] vfs_ioctl+0x237/0x249
[b01712c6] sys_ioctl+0x33/0x4d
[b0103e78] syscall_call+0x7/0xb
===
Code: 01 00 00 e8 ce ff ff ff 8d 83 ec 01 00 00 81 c3 40 02 00 00 e8 bd ff ff
ff 89 d8 5b eb b8 57 89 c1 53 83 ec 04 8b 00 85 c0 75 04 0f 0b eb fe 48 8b 5c
81 04 89 01 89 d1 31 c0 c1 e9 02 89 df f3
EIP: [f24ad9b6] mmu_memory_cache_alloc+0xd/0x36 [kvm] SS:ESP 0068:ca73fc80
note: qemu[2680] exited with preempt_count 2
BUG: sleeping function called from invalid context at
/home/kronos/src/linux-2.6.git/kernel/rwsem.c:20
in_atomic():1, irqs_disabled():0
INFO: lockdep is turned off.
[b01348ca] down_read+0x15/0x49
[b013e800] futex_wake+0x19/0xb3
[b013e919] do_futex+0x7f/0xaad
[b01caa47] vsnprintf+0x450/0x48c
[b02f4197] _spin_unlock_irqrestore+0x40/0x58
[b01218f0] release_console_sem+0x1a0/0x1b9
[b0121d88] vprintk+0x2b7/0x305
[b011c716] try_to_wake_up+0x325/0x32f
[b013f40f] sys_futex+0xc8/0xda
[b011f578] mm_release+0x81/0x87
[b0122cf7] exit_mm+0x13/0xd6
[b012410a] do_exit+0x1bc/0x69b
[b01053f1] die+0x1e5/0x211
[b0105784] do_invalid_op+0x0/0x8a
[b0105805] do_invalid_op+0x81/0x8a
[f24ad9b6] mmu_memory_cache_alloc+0xd/0x36 [kvm]
[f24ae61f] page_header_update_slot+0x1e/0x4b [kvm]
[f24ae8b5] paging32_set_pte_common+0x269/0x2a1 [kvm]
[b02f4432] error_code+0x72/0x78
[f24ad9b6] mmu_memory_cache_alloc+0xd/0x36 [kvm]
[f24aa0e2] gfn_to_page+0x14/0x27 [kvm]
[f24ae1eb] kvm_mmu_get_page+0x1b2/0x31c [kvm]
[f24ae3ea] mmu_alloc_roots+0x95/0xf0 [kvm]
[f24ae4b6] paging_new_cr3+0x21/0x48 [kvm]
[f24aab16] set_cr3+0x82/0x8c [kvm]
[f249b51d] handle_cr+0xf8/0x253 [kvm_intel]
[f249b1b5] handle_exception+0x120/0x208 [kvm_intel]
[f249af6c] vmx_vcpu_run+0x59d/0x6c6 [kvm_intel]
[b02f2bb6] __mutex_lock_slowpath+0x259/0x261
[f2499f34] vmx_vcpu_load+0x2a/0xcc [kvm_intel]
[f24ac7d1] kvm_vcpu_ioctl+0x29a/0xcff [kvm]
[b0294ea5] sock_common_recvmsg+0x3e/0x54
[b029396f] sock_recvmsg+0xcf/0xe8
[b0293a44]
Re: [lm-sensors] [RFC] ACPI based hwmon driver for ASUS
Il Tue, May 22, 2007 at 08:19:27AM +0200, Rudolf Marek ha scritto:
> Hi,
>
> I have following readings:
>
> w83627ehf-isa-0290
> Adapter: ISA adapter
> VCore: +1.52 V (min = +0.00 V, max = +1.74 V)
> in1: +12.30 V (min = +13.46 V, max = +13.04 V) ALARM
> AVCC: +3.36 V (min = +4.08 V, max = +3.95 V) ALARM
> 3VCC: +3.36 V (min = +4.05 V, max = +3.06 V) ALARM
> in4: +2.04 V (min = +1.78 V, max = +2.04 V)
> in5: +1.60 V (min = +2.04 V, max = +2.02 V) ALARM
> in6: +5.12 V (min = +6.12 V, max = +6.53 V) ALARM
> VSB: +3.36 V (min = +4.08 V, max = +4.08 V) ALARM
> VBAT: +3.30 V (min = +4.08 V, max = +3.04 V) ALARM
> in9: +1.65 V (min = +0.98 V, max = +2.04 V)
> Case Fan:0 RPM (min =0 RPM, div = 8)
> CPU Fan: 1638 RPM (min =0 RPM, div = 4)
> Aux Fan: 1436 RPM (min = 4272 RPM, div = 4) ALARM
> fan5:0 RPM (min =0 RPM, div = 16)
> Sys Temp:+28°C (high = -65°C, hyst = -34°C) ALARM
> CPU Temp: +34.0°C (high = +80.0°C, hyst = +75.0°C)
> AUX Temp: +38.5°C (high = +80.0°C, hyst = +75.0°C)
>
> Fan4 is disabled in the chip. I think the board has 4 connectors. I dont
> have time right now to check the manual.
Ok, it makes sense :)
Name (FBUF, Package (0x06)
{
0x03,
CPUF,
CHAF,
PWRF,
CHPF,
CH2F
})
Clearly the first number is not the number of available readings (though
it matches the count in the other DSDTs I've seen); don't know what it
is :|
The last field of the individual fan packages is far more interesting: 0
means disabled, anything else means enabled. In your DSDT "CHIPSET FAN
Speed" is marked as disabled and there's no AML code to read the
rotation.
This may be true also for the other packages (temp and voltage), but for
now I've modified only the fan code.
Here's another iteration of the driver, please give it a try:
/*
* Copyright (C) 2007 Luca Tettamanti <[EMAIL PROTECTED]>
* Distribute under GPLv2.
*/
#define DEBUG
#include
#include
#include
#include
#include
#include
#include
#define ATK_HID "ATK0110"
#define ATK_DRV "atk-hwmon"
#define ASOC "_SB.PCI0.SBRG.ASOC"
struct atk_data {
struct class_device *class_dev;
acpi_handle atk_handle;
struct acpi_device *device;
acpi_handle rtmp_handle;
acpi_handle rvlt_handle;
acpi_handle rfan_handle;
} atk_data;
typedef ssize_t (*sysfs_show_func)(struct device *dev,
struct device_attribute *attr, char *buf);
typedef ssize_t (*sysfs_store_func)(struct device *dev,
struct device_attribute *attr, const char *buf,
size_t count);
static void atk_init_attribute(struct device_attribute *attr, char *name,
mode_t mode, sysfs_show_func show, sysfs_store_func store)
{
attr->attr.name = name;
attr->attr.mode = mode;
attr->show = show;
attr->store = store;
}
#define ATTR_NAME_SIZE 16 /* Worst case is "tempN_input" */
struct atk_temp {
struct device_attribute label_attr;
struct device_attribute input_attr;
struct device_attribute max_attr;
struct device_attribute crit_attr;
char label_attr_name[ATTR_NAME_SIZE];
char input_attr_name[ATTR_NAME_SIZE];
char max_attr_name[ATTR_NAME_SIZE];
char crit_attr_name[ATTR_NAME_SIZE];
u64 id;
acpi_handle handle;
char *acpi_name;
};
struct atk_temp_list {
int count;
struct atk_temp temp[];
};
#define input_to_atk_temp(attr) \
container_of(attr, struct atk_temp, input_attr)
static ssize_t atk_temp_input_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct atk_temp *a = input_to_atk_temp(attr);
unsigned long temp;
struct acpi_object_list params;
union acpi_object id;
acpi_status status;
ssize_t count;
id.type = ACPI_TYPE_INTEGER;
id.integer.value = a->id;
params.count = 1;
params.pointer =
status = acpi_evaluate_integer(atk_data.rtmp_handle, NULL, ,
);
if (status != AE_OK) {
dev_warn(dev, "%s: ACPI exception: %s\n", __func__,
acpi_format_exception(status));
return -EIO;
}
/* ACPI returns centidegree */
count = sprintf(buf, "%lu\n", temp * 10);
return count;
}
#define label_to_atk_temp(attr) \
container_of(attr, struct atk_temp, label_attr)
static ssize_t atk_temp_label_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct atk_temp *a = label_to_atk_temp(attr);
return sprintf(buf, "%s\n", a->acpi_name);
}
enum atk_
Re: [lm-sensors] [RFC] ACPI based hwmon driver for ASUS
Il Tue, May 22, 2007 at 08:19:27AM +0200, Rudolf Marek ha scritto:
Hi,
I have following readings:
w83627ehf-isa-0290
Adapter: ISA adapter
VCore: +1.52 V (min = +0.00 V, max = +1.74 V)
in1: +12.30 V (min = +13.46 V, max = +13.04 V) ALARM
AVCC: +3.36 V (min = +4.08 V, max = +3.95 V) ALARM
3VCC: +3.36 V (min = +4.05 V, max = +3.06 V) ALARM
in4: +2.04 V (min = +1.78 V, max = +2.04 V)
in5: +1.60 V (min = +2.04 V, max = +2.02 V) ALARM
in6: +5.12 V (min = +6.12 V, max = +6.53 V) ALARM
VSB: +3.36 V (min = +4.08 V, max = +4.08 V) ALARM
VBAT: +3.30 V (min = +4.08 V, max = +3.04 V) ALARM
in9: +1.65 V (min = +0.98 V, max = +2.04 V)
Case Fan:0 RPM (min =0 RPM, div = 8)
CPU Fan: 1638 RPM (min =0 RPM, div = 4)
Aux Fan: 1436 RPM (min = 4272 RPM, div = 4) ALARM
fan5:0 RPM (min =0 RPM, div = 16)
Sys Temp:+28°C (high = -65°C, hyst = -34°C) ALARM
CPU Temp: +34.0°C (high = +80.0°C, hyst = +75.0°C)
AUX Temp: +38.5°C (high = +80.0°C, hyst = +75.0°C)
Fan4 is disabled in the chip. I think the board has 4 connectors. I dont
have time right now to check the manual.
Ok, it makes sense :)
Name (FBUF, Package (0x06)
{
0x03,
CPUF,
CHAF,
PWRF,
CHPF,
CH2F
})
Clearly the first number is not the number of available readings (though
it matches the count in the other DSDTs I've seen); don't know what it
is :|
The last field of the individual fan packages is far more interesting: 0
means disabled, anything else means enabled. In your DSDT CHIPSET FAN
Speed is marked as disabled and there's no AML code to read the
rotation.
This may be true also for the other packages (temp and voltage), but for
now I've modified only the fan code.
Here's another iteration of the driver, please give it a try:
/*
* Copyright (C) 2007 Luca Tettamanti [EMAIL PROTECTED]
* Distribute under GPLv2.
*/
#define DEBUG
#include linux/module.h
#include linux/kernel.h
#include linux/hwmon.h
#include acpi/acpi.h
#include acpi/acnamesp.h
#include acpi/acpi_drivers.h
#include acpi/acpi_bus.h
#define ATK_HID ATK0110
#define ATK_DRV atk-hwmon
#define ASOC _SB.PCI0.SBRG.ASOC
struct atk_data {
struct class_device *class_dev;
acpi_handle atk_handle;
struct acpi_device *device;
acpi_handle rtmp_handle;
acpi_handle rvlt_handle;
acpi_handle rfan_handle;
} atk_data;
typedef ssize_t (*sysfs_show_func)(struct device *dev,
struct device_attribute *attr, char *buf);
typedef ssize_t (*sysfs_store_func)(struct device *dev,
struct device_attribute *attr, const char *buf,
size_t count);
static void atk_init_attribute(struct device_attribute *attr, char *name,
mode_t mode, sysfs_show_func show, sysfs_store_func store)
{
attr-attr.name = name;
attr-attr.mode = mode;
attr-show = show;
attr-store = store;
}
#define ATTR_NAME_SIZE 16 /* Worst case is tempN_input */
struct atk_temp {
struct device_attribute label_attr;
struct device_attribute input_attr;
struct device_attribute max_attr;
struct device_attribute crit_attr;
char label_attr_name[ATTR_NAME_SIZE];
char input_attr_name[ATTR_NAME_SIZE];
char max_attr_name[ATTR_NAME_SIZE];
char crit_attr_name[ATTR_NAME_SIZE];
u64 id;
acpi_handle handle;
char *acpi_name;
};
struct atk_temp_list {
int count;
struct atk_temp temp[];
};
#define input_to_atk_temp(attr) \
container_of(attr, struct atk_temp, input_attr)
static ssize_t atk_temp_input_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct atk_temp *a = input_to_atk_temp(attr);
unsigned long temp;
struct acpi_object_list params;
union acpi_object id;
acpi_status status;
ssize_t count;
id.type = ACPI_TYPE_INTEGER;
id.integer.value = a-id;
params.count = 1;
params.pointer = id;
status = acpi_evaluate_integer(atk_data.rtmp_handle, NULL, params,
temp);
if (status != AE_OK) {
dev_warn(dev, %s: ACPI exception: %s\n, __func__,
acpi_format_exception(status));
return -EIO;
}
/* ACPI returns centidegree */
count = sprintf(buf, %lu\n, temp * 10);
return count;
}
#define label_to_atk_temp(attr) \
container_of(attr, struct atk_temp, label_attr)
static ssize_t atk_temp_label_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct atk_temp *a = label_to_atk_temp(attr);
return sprintf(buf, %s\n, a-acpi_name);
}
enum atk_temp_pack_id {
ATK_TEMP_PACK_MAX = 2,
ATK_TEMP_PACK_CRIT = 3,
};
static int atk_temp_pack_read(acpi_handle
Re: radeonfb and X800 cards
Il Sun, May 20, 2007 at 02:54:20PM +0200, Jimmy Jazz ha scritto: > @Luca, if i remember well you have a X850, could you please try the > patch for me ? It does work - sort of; BIOS parsing code is correct. It lacks the proper connector detection though (esp. port sharing). ATOM BIOS has a different data layout, so this should be added (now radeonfb thinks that I've 2 monitors). I'll be away this weekend, so I'll try to come up with a patch as soon as I return home. Luca -- "L'abilita` politica e` l'abilita` di prevedere quello che accadra` domani, la prossima settimana, il prossimo mese e l'anno prossimo. E di essere cosi` abili, piu` tardi, da spiegare perche' non e` accaduto." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: radeonfb and X800 cards
Il Sun, May 20, 2007 at 02:54:20PM +0200, Jimmy Jazz ha scritto: @Luca, if i remember well you have a X850, could you please try the patch for me ? It does work - sort of; BIOS parsing code is correct. It lacks the proper connector detection though (esp. port sharing). ATOM BIOS has a different data layout, so this should be added (now radeonfb thinks that I've 2 monitors). I'll be away this weekend, so I'll try to come up with a patch as soon as I return home. Luca -- L'abilita` politica e` l'abilita` di prevedere quello che accadra` domani, la prossima settimana, il prossimo mese e l'anno prossimo. E di essere cosi` abili, piu` tardi, da spiegare perche' non e` accaduto. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [1/2] 2.6.22-rc2: known regressions with patches
Il Sun, May 20, 2007 at 12:06:42AM +0200, Michal Piotrowski ha scritto: > Hi all, > > Here is a list of some known regressions in 2.6.22-rc2 > with patches available. > > Cryptography > > Subject: cryptomgr oops > References : http://lkml.org/lkml/2007/5/14/283 > Submitter : Luca Tettamanti <[EMAIL PROTECTED]> > Handled-By : Herbert Xu <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/5/19/3 > Status : patch available Hello, I confirm that Herbert's patch fixes the OOPS. Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/2] 2.6.22-rc2: known regressions with patches
Il Sun, May 20, 2007 at 12:06:42AM +0200, Michal Piotrowski ha scritto: Hi all, Here is a list of some known regressions in 2.6.22-rc2 with patches available. Cryptography Subject: cryptomgr oops References : http://lkml.org/lkml/2007/5/14/283 Submitter : Luca Tettamanti [EMAIL PROTECTED] Handled-By : Herbert Xu [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/5/19/3 Status : patch available Hello, I confirm that Herbert's patch fixes the OOPS. Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/3] drm modesetting core
Il Thu, May 17, 2007 at 06:04:54PM -0700, Jesse Barnes ha scritto: > On Thursday, May 17, 2007, Luca Tettamanti wrote: > > Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto: > > > This patch adds the core of the new DRM based modesetting system. > > > > A couple of comments on drm_fb since I'm somewhat familiar with fb code: > > > new file mode 100644 > > > index 000..0d06792 > > > --- /dev/null > > > +++ b/linux-core/drm_edid.c > > > @@ -0,0 +1,467 @@ > > > +/* > > > + * Copyright (c) 2007 Intel Corporation > > > + * Jesse Barnes <[EMAIL PROTECTED]> > > > + * > > > + * DDC probing routines (drm_ddc_read & drm_do_probe_ddc_edid) > > > originally from > > > + * FB layer. > > > > Hum, why are you duplicating them here? fbmon.c has the > > infrastructure for parsing and even fixing known-broken EDIDs. > > Yeah, there's more sharing that could be done... though I don't think the > fb layer has the bits to actually grab EDIDs. There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I wrote them for the radeon driver, but now are available for general use) which will issue the read command; fbmon.c has the stuff for parsing the EDID; you usualy build a DB of supported modes which is then used to validate the mode requested by the user. Of course each driver has to implement the I2C adapter. > Also, DRM is shared with BSD... Your patch already uses 'struct i2c_adapter' in drm_edid.c, is it portable? Luca -- "Vorrei morire ucciso dagli agi. Vorrei che di me si dicesse: ``Com'è morto?'' ``Gli è scoppiato il portafogli''" -- Marcello Marchesi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto: > On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote: > > > > Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, > > git agrees and I've done a full rebuild. The .config is generated > > using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is > > coming from there? > > Sorry, my mistake. That bug only happens if you have padlock turned on. > > Anyway, if possible could you post the complete dmesg when it crashes? > I'd like to see what has happened up to the point where it crashes. Output from serial console is enlightening (sort of...): Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: b0141aef [oops] Problem is that: - /etc/ipsec-tools.conf is empty (everything is commented out), it's a leftover of previous experiments. - AH and ESP are disabled in the kernel since I don't use them anymore. Removing setkey script from init.d makes the OOPS disappear though; nothing happens if I manually run setkey after the boot... This is the full log: Linux version 2.6.22-rc1-libata-g705962cc-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #63 SMP PREEMPT Thu May 17 00:22:29 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 1023MB LOWMEM available. found SMP MP-table at 000ff780 Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 262032 early_node_map[1] active PFN ranges 0:0 -> 262032 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a202 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:bee0) Built 1 zonelists. Total pages: 259985 Kernel command line: BOOT_IMAGE=linux-2.6.22r1 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=b042e000 soft=b042c000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2135.141 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-D-D-A deadlock:
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto: On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote: Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, git agrees and I've done a full rebuild. The .config is generated using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is coming from there? Sorry, my mistake. That bug only happens if you have padlock turned on. Anyway, if possible could you post the complete dmesg when it crashes? I'd like to see what has happened up to the point where it crashes. Output from serial console is enlightening (sort of...): Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: b0141aef [oops] Problem is that: - /etc/ipsec-tools.conf is empty (everything is commented out), it's a leftover of previous experiments. - AH and ESP are disabled in the kernel since I don't use them anymore. Removing setkey script from init.d makes the OOPS disappear though; nothing happens if I manually run setkey after the boot... This is the full log: Linux version 2.6.22-rc1-libata-g705962cc-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #63 SMP PREEMPT Thu May 17 00:22:29 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 1023MB LOWMEM available. found SMP MP-table at 000ff780 Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 262032 early_node_map[1] active PFN ranges 0:0 - 262032 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a202 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:bee0) Built 1 zonelists. Total pages: 259985 Kernel command line: BOOT_IMAGE=linux-2.6.22r1 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=b042e000 soft=b042c000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2135.141 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-D-D-A deadlock: ok | ok | ok |
Re: [PATCH 2/3] drm modesetting core
Il Thu, May 17, 2007 at 06:04:54PM -0700, Jesse Barnes ha scritto: On Thursday, May 17, 2007, Luca Tettamanti wrote: Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto: This patch adds the core of the new DRM based modesetting system. A couple of comments on drm_fb since I'm somewhat familiar with fb code: new file mode 100644 index 000..0d06792 --- /dev/null +++ b/linux-core/drm_edid.c @@ -0,0 +1,467 @@ +/* + * Copyright (c) 2007 Intel Corporation + * Jesse Barnes [EMAIL PROTECTED] + * + * DDC probing routines (drm_ddc_read drm_do_probe_ddc_edid) originally from + * FB layer. Hum, why are you duplicating them here? fbmon.c has the infrastructure for parsing and even fixing known-broken EDIDs. Yeah, there's more sharing that could be done... though I don't think the fb layer has the bits to actually grab EDIDs. There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I wrote them for the radeon driver, but now are available for general use) which will issue the read command; fbmon.c has the stuff for parsing the EDID; you usualy build a DB of supported modes which is then used to validate the mode requested by the user. Of course each driver has to implement the I2C adapter. Also, DRM is shared with BSD... Your patch already uses 'struct i2c_adapter' in drm_edid.c, is it portable? Luca -- Vorrei morire ucciso dagli agi. Vorrei che di me si dicesse: ``Com'è morto?'' ``Gli è scoppiato il portafogli'' -- Marcello Marchesi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/3] drm modesetting core
Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
> This patch adds the core of the new DRM based modesetting system.
A couple of comments on drm_fb since I'm somewhat familiar with fb code:
> new file mode 100644
> index 000..0d06792
> --- /dev/null
> +++ b/linux-core/drm_edid.c
> @@ -0,0 +1,467 @@
> +/*
> + * Copyright (c) 2007 Intel Corporation
> + * Jesse Barnes <[EMAIL PROTECTED]>
> + *
> + * DDC probing routines (drm_ddc_read & drm_do_probe_ddc_edid)
> originally from
> + * FB layer.
Hum, why are you duplicating them here? fbmon.c has the
infrastructure for parsing and even fixing known-broken EDIDs.
> + * Copyright (C) 2006 Dennis Munsie <[EMAIL PROTECTED]>
> + */
> +#include
> +#include
> +#include "drmP.h"
> +#include "drm_edid.h"
> +
> +/* Valid EDID header has these bytes */
> +static u8 edid_header[] = { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> 0x00 };
> +
> +/**
> + * edid_valid - sanity check EDID data
> + * @edid: EDID data
> + *
> + * Sanity check the EDID block by looking at the header, the version
> number
> + * and the checksum. Return 0 if the EDID doesn't check out, or 1 if
> it's
> + * valid.
> + */
> +static bool edid_valid(struct edid *edid)
> +{
> + int i;
> + u8 csum = 0;
> + u8 *raw_edid = (u8 *)edid;
> +
> + if (memcmp(edid->header, edid_header, sizeof(edid_header)))
> + goto bad;
> + if (edid->version != 1)
> + goto bad;
> + if (edid->revision <= 0 || edid->revision > 3)
> + goto bad;
> +
> + for (i = 0; i < EDID_LENGTH; i++)
> + csum += raw_edid[i];
> + if (csum)
> + goto bad;
> +
> + return 1;
> +
> +bad:
> + return 0;
> +}
This is basically edid_check_header + edid_checksum.
> +
> +/**
> + * drm_mode_std - convert standard mode info (width, height, refresh)
> into mode
> + * @t: standard timing params
> + *
> + * Take the standard timing params (in this case width, aspect, and
> refresh)
> + * and convert them into a real mode using CVT.
> + *
> + * Punts for now, but should eventually use the FB layer's CVT based
> mode
> + * generation code.
> + */
> +struct drm_display_mode *drm_mode_std(struct drm_device *dev,
> + struct std_timing *t)
> +{
get_std_timing?
> +/**
> + * drm_mode_detailed - create a new mode from an EDID detailed timing
> section
> + * @timing: EDID detailed timing info
> + * @preferred: is this a preferred mode?
> + *
> + * An EDID detailed timing block contains enough info for us to create
> and
> + * return a new struct drm_display_mode. The @preferred flag will be
> set
> + * if this is the display's preferred timing, and we'll use it to
> indicate
> + * to the other layers that this mode is desired.
> + */
> +struct drm_display_mode *drm_mode_detailed(drm_device_t *dev,
> +struct detailed_timing *timing)
> +{
get_detailed_timing?
If you can't use 'struct fb_videomode' we may refactor code around a common
data structure instead of a copy
> +static unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter
> *adapter)
[...]
> +static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
[...]
Copy and paste from fb_dcc.c; furthermore a fix in drm_ddc_read hasn't
been backported to the original code.
> diff --git a/linux-core/drm_fb.c b/linux-core/drm_fb.c
> new file mode 100644
> index 000..ef05341
> --- /dev/null
> +++ b/linux-core/drm_fb.c
> @@ -0,0 +1,201 @@
> +/*
> + * Copyright © 2007 David Airlie
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files
> (the "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> next
> + * paragraph) shall be included in all copies or substantial portions
> of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * David Airlie
> + */
> +/*
> + * Modularization
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
>
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: > On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: > > I'm running git 705962cc (which is a commit after -rc1) and I still see > > the OOPS on boot. The patch above is already applied though. Note that > > I'm using the SLAB allocator: > > > > CONFIG_SLAB=y > > # CONFIG_SLUB is not set > > # CONFIG_SLOB is not set > > > > > > Ending clean XFS mount for filesystem: dm-4 > > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > > Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did "fix" the problem. Sorry for the noise... Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: I'm running git 705962cc (which is a commit after -rc1) and I still see the OOPS on boot. The patch above is already applied though. Note that I'm using the SLAB allocator: CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set Ending clean XFS mount for filesystem: dm-4 BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did fix the problem. Sorry for the noise... Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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/3] drm modesetting core
Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
This patch adds the core of the new DRM based modesetting system.
A couple of comments on drm_fb since I'm somewhat familiar with fb code:
new file mode 100644
index 000..0d06792
--- /dev/null
+++ b/linux-core/drm_edid.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright (c) 2007 Intel Corporation
+ * Jesse Barnes [EMAIL PROTECTED]
+ *
+ * DDC probing routines (drm_ddc_read drm_do_probe_ddc_edid)
originally from
+ * FB layer.
Hum, why are you duplicating them here? fbmon.c has the
infrastructure for parsing and even fixing known-broken EDIDs.
+ * Copyright (C) 2006 Dennis Munsie [EMAIL PROTECTED]
+ */
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include drmP.h
+#include drm_edid.h
+
+/* Valid EDID header has these bytes */
+static u8 edid_header[] = { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0x00 };
+
+/**
+ * edid_valid - sanity check EDID data
+ * @edid: EDID data
+ *
+ * Sanity check the EDID block by looking at the header, the version
number
+ * and the checksum. Return 0 if the EDID doesn't check out, or 1 if
it's
+ * valid.
+ */
+static bool edid_valid(struct edid *edid)
+{
+ int i;
+ u8 csum = 0;
+ u8 *raw_edid = (u8 *)edid;
+
+ if (memcmp(edid-header, edid_header, sizeof(edid_header)))
+ goto bad;
+ if (edid-version != 1)
+ goto bad;
+ if (edid-revision = 0 || edid-revision 3)
+ goto bad;
+
+ for (i = 0; i EDID_LENGTH; i++)
+ csum += raw_edid[i];
+ if (csum)
+ goto bad;
+
+ return 1;
+
+bad:
+ return 0;
+}
This is basically edid_check_header + edid_checksum.
+
+/**
+ * drm_mode_std - convert standard mode info (width, height, refresh)
into mode
+ * @t: standard timing params
+ *
+ * Take the standard timing params (in this case width, aspect, and
refresh)
+ * and convert them into a real mode using CVT.
+ *
+ * Punts for now, but should eventually use the FB layer's CVT based
mode
+ * generation code.
+ */
+struct drm_display_mode *drm_mode_std(struct drm_device *dev,
+ struct std_timing *t)
+{
get_std_timing?
+/**
+ * drm_mode_detailed - create a new mode from an EDID detailed timing
section
+ * @timing: EDID detailed timing info
+ * @preferred: is this a preferred mode?
+ *
+ * An EDID detailed timing block contains enough info for us to create
and
+ * return a new struct drm_display_mode. The @preferred flag will be
set
+ * if this is the display's preferred timing, and we'll use it to
indicate
+ * to the other layers that this mode is desired.
+ */
+struct drm_display_mode *drm_mode_detailed(drm_device_t *dev,
+struct detailed_timing *timing)
+{
get_detailed_timing?
If you can't use 'struct fb_videomode' we may refactor code around a common
data structure instead of a copypaste.
+static unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter
*adapter)
[...]
+static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
[...]
Copy and paste from fb_dcc.c; furthermore a fix in drm_ddc_read hasn't
been backported to the original code.
diff --git a/linux-core/drm_fb.c b/linux-core/drm_fb.c
new file mode 100644
index 000..ef05341
--- /dev/null
+++ b/linux-core/drm_fb.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright © 2007 David Airlie
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining a
+ * copy of this software and associated documentation files
(the Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom
the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions
of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * David Airlie
+ */
+/*
+ * Modularization
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/mm.h
+#include linux/tty.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/fb.h
+#include linux/init.h
+
+#include drmP.h
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: > On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: > > I'm running git 705962cc (which is a commit after -rc1) and I still see > > the OOPS on boot. The patch above is already applied though. Note that > > I'm using the SLAB allocator: > > > > CONFIG_SLAB=y > > # CONFIG_SLUB is not set > > # CONFIG_SLOB is not set > > > > > > Ending clean XFS mount for filesystem: dm-4 > > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > > Please send me your .config file. There it is: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc1 # Mon May 14 00:01:41 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-libata" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_MODEL=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXU
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: I'm running git 705962cc (which is a commit after -rc1) and I still see the OOPS on boot. The patch above is already applied though. Note that I'm using the SLAB allocator: CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set Ending clean XFS mount for filesystem: dm-4 BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Please send me your .config file. There it is: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc1 # Mon May 14 00:01:41 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-libata CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_MODEL=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Kevin Winchester <[EMAIL PROTECTED]> ha scritto:
> On 5/9/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
>> On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
>> >
>> > Not having any idea what I'm doing, I looked at cryptomgr_probe and
>> > cryptomgr_notify, and can't seem to see much, except for the following
>> > odd lines.
>> >
>> > From cryptomgr_schedule_probe, which is almost certainly inlined into
>> > crypto_notify:
>>
>> Thanks for reporting this. This patch should fix the problem.
>>
>> Cheers,
>> --
>> Visit Openswan at http://www.openswan.org/
>> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
>> Home Page: http://gondor.apana.org.au/~herbert/
>> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>> --
>> diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
>> --- a/crypto/cryptomgr.c~crypto-fix
>> +++ a/crypto/cryptomgr.c
>> @@ -24,8 +24,6 @@
>> #include "internal.h"
>>
>> struct cryptomgr_param {
>> - struct task_struct *thread;
>> -
>> struct rtattr *tb[CRYPTOA_MAX];
>>
>> struct {
>> @@ -81,6 +79,7 @@ err:
>>
>> static int cryptomgr_schedule_probe(struct crypto_larval *larval)
>> {
>> + struct task_struct *thread;
>> struct cryptomgr_param *param;
>> const char *name = larval->alg.cra_name;
>> const char *p;
>> @@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
>>
>> memcpy(param->larval.name, larval->alg.cra_name,
>> CRYPTO_MAX_ALG_NAME);
>>
>> - param->thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
>> - if (IS_ERR(param->thread))
>> + thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
>> + if (IS_ERR(thread))
>> goto err_free_param;
>>
>> return NOTIFY_STOP;
>> _
>>
>
> I see that this patch made it in to mainline, and latest -git now
> works for me, so I assume this was the correct solution. I thought I
> had tried this exact change without success when I was looking at the
> problem, but I guess I did something wrong along the way.
Hum,
I'm running git 705962cc (which is a commit after -rc1) and I still see
the OOPS on boot. The patch above is already applied though. Note that
I'm using the SLAB allocator:
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
Ending clean XFS mount for filesystem: dm-4
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
b0141aef
*pde =
Oops: 0002 [#1]
PREEMPT SMP
BUG: unable to handle kernel paging request at virtual address 6b6b6d6b
printing eip:
b0141aef
*pde =
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010256 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: ebx: 6b6b6b6b ecx: 0001 edx: ee5bb000
esi: edi: ee7b8a38 ebp: esp: ee5bbfa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4532, ti=ee5bb000 task=ef2fc070 task.ti=ee5bb000)
Stack: ee7b8a38 ee7b8a38 f0858235 0282 ef1a0bc0 ee7b8a38
f08581b3 b0131351 007b b0131316 b0104b3b
ef1a0bb4
Call Trace:
[] cryptomgr_probe+0x82/0x99 [cryptomgr]
[] cryptomgr_probe+0x0/0x99 [cryptomgr]
[] kthread+0x3b/0x62
[] kthread+0x0/0x62
[] kernel_thread_helper+0x7/0x10
===
Code: e8 fa 70 08 00 83 c4 0c 89 d8 5b 5e 5f 5d c3 53 89 c3 83 ec 08 85 c0 74
49 b8 01 00 00 00 e8 ba a4 fd ff e8 34 70 09 00 c1 e0 07 8c 18 80 01 00 00
83 3b 02 75 0b 8b 83 88 02 00 00 e8 18 9e
EIP: [] module_put+0x1c/0x57 SS:ESP 0068:ee5bbfa8
Oops: 0002 [#2]
note: cryptomgr[4532] exited with preempt_count 1
PREEMPT SMP
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010212 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: 0080 ebx: 6b6b6b6b ecx: 0001 edx: b1a0f000
esi: edi: ee20fd80 ebp: esp: b1a0ffa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4537, ti=b1a0f000 task=eecce0b0 task.ti=b1a0f000)
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Kevin Winchester [EMAIL PROTECTED] ha scritto:
On 5/9/07, Herbert Xu [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
Not having any idea what I'm doing, I looked at cryptomgr_probe and
cryptomgr_notify, and can't seem to see much, except for the following
odd lines.
From cryptomgr_schedule_probe, which is almost certainly inlined into
crypto_notify:
Thanks for reporting this. This patch should fix the problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
--- a/crypto/cryptomgr.c~crypto-fix
+++ a/crypto/cryptomgr.c
@@ -24,8 +24,6 @@
#include internal.h
struct cryptomgr_param {
- struct task_struct *thread;
-
struct rtattr *tb[CRYPTOA_MAX];
struct {
@@ -81,6 +79,7 @@ err:
static int cryptomgr_schedule_probe(struct crypto_larval *larval)
{
+ struct task_struct *thread;
struct cryptomgr_param *param;
const char *name = larval-alg.cra_name;
const char *p;
@@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
memcpy(param-larval.name, larval-alg.cra_name,
CRYPTO_MAX_ALG_NAME);
- param-thread = kthread_run(cryptomgr_probe, param, cryptomgr);
- if (IS_ERR(param-thread))
+ thread = kthread_run(cryptomgr_probe, param, cryptomgr);
+ if (IS_ERR(thread))
goto err_free_param;
return NOTIFY_STOP;
_
I see that this patch made it in to mainline, and latest -git now
works for me, so I assume this was the correct solution. I thought I
had tried this exact change without success when I was looking at the
problem, but I guess I did something wrong along the way.
Hum,
I'm running git 705962cc (which is a commit after -rc1) and I still see
the OOPS on boot. The patch above is already applied though. Note that
I'm using the SLAB allocator:
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
Ending clean XFS mount for filesystem: dm-4
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
b0141aef
*pde =
Oops: 0002 [#1]
PREEMPT SMP
BUG: unable to handle kernel paging request at virtual address 6b6b6d6b
printing eip:
b0141aef
*pde =
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:0
EIP:0060:[b0141aef]Not tainted VLI
EFLAGS: 00010256 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: ebx: 6b6b6b6b ecx: 0001 edx: ee5bb000
esi: edi: ee7b8a38 ebp: esp: ee5bbfa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4532, ti=ee5bb000 task=ef2fc070 task.ti=ee5bb000)
Stack: ee7b8a38 ee7b8a38 f0858235 0282 ef1a0bc0 ee7b8a38
f08581b3 b0131351 007b b0131316 b0104b3b
ef1a0bb4
Call Trace:
[f0858235] cryptomgr_probe+0x82/0x99 [cryptomgr]
[f08581b3] cryptomgr_probe+0x0/0x99 [cryptomgr]
[b0131351] kthread+0x3b/0x62
[b0131316] kthread+0x0/0x62
[b0104b3b] kernel_thread_helper+0x7/0x10
===
Code: e8 fa 70 08 00 83 c4 0c 89 d8 5b 5e 5f 5d c3 53 89 c3 83 ec 08 85 c0 74
49 b8 01 00 00 00 e8 ba a4 fd ff e8 34 70 09 00 c1 e0 07 ff 8c 18 80 01 00 00
83 3b 02 75 0b 8b 83 88 02 00 00 e8 18 9e
EIP: [b0141aef] module_put+0x1c/0x57 SS:ESP 0068:ee5bbfa8
Oops: 0002 [#2]
note: cryptomgr[4532] exited with preempt_count 1
PREEMPT SMP
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:1
EIP:0060:[b0141aef]Not tainted VLI
EFLAGS: 00010212 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: 0080 ebx: 6b6b6b6b ecx: 0001 edx: b1a0f000
esi: edi: ee20fd80 ebp: esp: b1a0ffa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4537, ti=b1a0f000 task=eecce0b0 task.ti=b1a0f000)
Stack: ee20fd80 ee20fd80 f0858235 0282 ef1a0bc0
[RFC] ACPI based hwmon driver for ASUS
Hi,
this is the first attempt to write a hwmon driver for ASUS motherboards
that uses ACPI methods instead of directly touching the sensor chip.
If you haven't followed the discussion[1] we want to avoid concurrent
access to the monitoring hw by ACPI and native driver, since it may
cause a malfunction.
A brief description of the driver:
- I've extended the hwmon userspace interface with *_name attributes;
since ACPI "knows" the wiring and provides a pretty description of
the reading I thought it's worth exposing it.
- all the attributes are read only: for some of them (voltage,
temperature) rw doesn't make sense; for FAN: it's not possible to
directly control the PWM (the native driver can do that) via ACPI;
ASUS provides "Q-FAN" which has 3 settings: "silent", "perfomance",
"auto"; so far I've been unable to make it work. The write path is
basically "write caller supplied magic number to a magic memory
location"...
- various ASUS stuff: my motherboard also has other features like
auto-overclock, PCI-E frequency readings, DRAM voltage and frequency,
CPU clock / ratio (some of the writable at runtime). I've ignored them
since I don't know how they work (magic numbers...)
- I exported a few ACPI functions: acpi_ns_map_handle_to_node,
acpi_ns_convert_entry_to_handle and acpi_ns_get_node for inspecting
ACPI methods and ensure that all the expected stuff is there;
acpi_evaluate_object_typed since it's very handy to let it do the
check on the returned data instead of open-coding it all over the
driver. Patch against 2.6.21:
diff --git a/drivers/acpi/namespace/nsutils.c b/drivers/acpi/namespace/nsutils.c
index 90fd059..97e1139 100644
--- a/drivers/acpi/namespace/nsutils.c
+++ b/drivers/acpi/namespace/nsutils.c
@@ -700,6 +700,7 @@ struct acpi_namespace_node
*acpi_ns_map_handle_to_node(acpi_handle handle)
return (ACPI_CAST_PTR(struct acpi_namespace_node, handle));
}
+EXPORT_SYMBOL(acpi_ns_map_handle_to_node);
/***
*
@@ -736,6 +737,7 @@ acpi_handle acpi_ns_convert_entry_to_handle(struct
acpi_namespace_node *node)
return ((acpi_handle) Node);
--*/
}
+EXPORT_SYMBOL(acpi_ns_convert_entry_to_handle);
/***
*
@@ -875,6 +877,7 @@ acpi_ns_get_node(struct acpi_namespace_node *prefix_node,
ACPI_FREE(internal_path);
return_ACPI_STATUS(status);
}
+EXPORT_SYMBOL(acpi_ns_get_node);
/***
*
diff --git a/drivers/acpi/namespace/nsxfeval.c
b/drivers/acpi/namespace/nsxfeval.c
index 8904d0f..1b81758 100644
--- a/drivers/acpi/namespace/nsxfeval.c
+++ b/drivers/acpi/namespace/nsxfeval.c
@@ -49,7 +49,6 @@
#define _COMPONENT ACPI_NAMESPACE
ACPI_MODULE_NAME("nsxfeval")
-#ifdef ACPI_FUTURE_USAGE
/***
*
* FUNCTION:acpi_evaluate_object_typed
@@ -142,7 +141,6 @@ acpi_evaluate_object_typed(acpi_handle handle,
}
ACPI_EXPORT_SYMBOL(acpi_evaluate_object_typed)
-#endif /* ACPI_FUTURE_USAGE */
/***
*
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index e08f7df..85da346 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -164,14 +164,12 @@ acpi_evaluate_object(acpi_handle object,
struct acpi_object_list *parameter_objects,
struct acpi_buffer *return_object_buffer);
-#ifdef ACPI_FUTURE_USAGE
acpi_status
acpi_evaluate_object_typed(acpi_handle object,
acpi_string pathname,
struct acpi_object_list *external_params,
struct acpi_buffer *return_buffer,
acpi_object_type return_type);
-#endif
acpi_status
acpi_get_object_info(acpi_handle handle, struct acpi_buffer *return_buffer);
I've asked for help to local LUG: the driver has been tested by a couple
of people; unfortunately the board were all very similar (a P5B, a P5B
delux and my P5B-E). If you have a recent ASUS mainboard and the driver
doesn't work you can send me a dump of your DSDT.
Now the driver itself:
/*
* Copyright (C) 2007 Luca Tettamanti <[EMAIL PROTECTED]>
* Distribute under GPLv2.
*/
#define DEBUG
#include
#include
#include
#include
#include
#include
#include
#define ATK_HID "ATK0110"
#define ATK_DRV "atk-hwmon"
#define ASOC "_SB.PCI0.SBRG.ASOC"
struct atk_data {
struct class_device *class_dev;
acpi_handle atk_handle;
struct acpi_device *device;
acpi_handle rtmp_handle;
[RFC] ACPI based hwmon driver for ASUS
Hi,
this is the first attempt to write a hwmon driver for ASUS motherboards
that uses ACPI methods instead of directly touching the sensor chip.
If you haven't followed the discussion[1] we want to avoid concurrent
access to the monitoring hw by ACPI and native driver, since it may
cause a malfunction.
A brief description of the driver:
- I've extended the hwmon userspace interface with *_name attributes;
since ACPI knows the wiring and provides a pretty description of
the reading I thought it's worth exposing it.
- all the attributes are read only: for some of them (voltage,
temperature) rw doesn't make sense; for FAN: it's not possible to
directly control the PWM (the native driver can do that) via ACPI;
ASUS provides Q-FAN which has 3 settings: silent, perfomance,
auto; so far I've been unable to make it work. The write path is
basically write caller supplied magic number to a magic memory
location...
- various ASUS stuff: my motherboard also has other features like
auto-overclock, PCI-E frequency readings, DRAM voltage and frequency,
CPU clock / ratio (some of the writable at runtime). I've ignored them
since I don't know how they work (magic numbers...)
- I exported a few ACPI functions: acpi_ns_map_handle_to_node,
acpi_ns_convert_entry_to_handle and acpi_ns_get_node for inspecting
ACPI methods and ensure that all the expected stuff is there;
acpi_evaluate_object_typed since it's very handy to let it do the
check on the returned data instead of open-coding it all over the
driver. Patch against 2.6.21:
diff --git a/drivers/acpi/namespace/nsutils.c b/drivers/acpi/namespace/nsutils.c
index 90fd059..97e1139 100644
--- a/drivers/acpi/namespace/nsutils.c
+++ b/drivers/acpi/namespace/nsutils.c
@@ -700,6 +700,7 @@ struct acpi_namespace_node
*acpi_ns_map_handle_to_node(acpi_handle handle)
return (ACPI_CAST_PTR(struct acpi_namespace_node, handle));
}
+EXPORT_SYMBOL(acpi_ns_map_handle_to_node);
/***
*
@@ -736,6 +737,7 @@ acpi_handle acpi_ns_convert_entry_to_handle(struct
acpi_namespace_node *node)
return ((acpi_handle) Node);
--*/
}
+EXPORT_SYMBOL(acpi_ns_convert_entry_to_handle);
/***
*
@@ -875,6 +877,7 @@ acpi_ns_get_node(struct acpi_namespace_node *prefix_node,
ACPI_FREE(internal_path);
return_ACPI_STATUS(status);
}
+EXPORT_SYMBOL(acpi_ns_get_node);
/***
*
diff --git a/drivers/acpi/namespace/nsxfeval.c
b/drivers/acpi/namespace/nsxfeval.c
index 8904d0f..1b81758 100644
--- a/drivers/acpi/namespace/nsxfeval.c
+++ b/drivers/acpi/namespace/nsxfeval.c
@@ -49,7 +49,6 @@
#define _COMPONENT ACPI_NAMESPACE
ACPI_MODULE_NAME(nsxfeval)
-#ifdef ACPI_FUTURE_USAGE
/***
*
* FUNCTION:acpi_evaluate_object_typed
@@ -142,7 +141,6 @@ acpi_evaluate_object_typed(acpi_handle handle,
}
ACPI_EXPORT_SYMBOL(acpi_evaluate_object_typed)
-#endif /* ACPI_FUTURE_USAGE */
/***
*
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index e08f7df..85da346 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -164,14 +164,12 @@ acpi_evaluate_object(acpi_handle object,
struct acpi_object_list *parameter_objects,
struct acpi_buffer *return_object_buffer);
-#ifdef ACPI_FUTURE_USAGE
acpi_status
acpi_evaluate_object_typed(acpi_handle object,
acpi_string pathname,
struct acpi_object_list *external_params,
struct acpi_buffer *return_buffer,
acpi_object_type return_type);
-#endif
acpi_status
acpi_get_object_info(acpi_handle handle, struct acpi_buffer *return_buffer);
I've asked for help to local LUG: the driver has been tested by a couple
of people; unfortunately the board were all very similar (a P5B, a P5B
delux and my P5B-E). If you have a recent ASUS mainboard and the driver
doesn't work you can send me a dump of your DSDT.
Now the driver itself:
/*
* Copyright (C) 2007 Luca Tettamanti [EMAIL PROTECTED]
* Distribute under GPLv2.
*/
#define DEBUG
#include linux/module.h
#include linux/kernel.h
#include linux/hwmon.h
#include acpi/acpi.h
#include acpi/acnamesp.h
#include acpi/acpi_drivers.h
#include acpi/acpi_bus.h
#define ATK_HID ATK0110
#define ATK_DRV atk-hwmon
#define ASOC _SB.PCI0.SBRG.ASOC
struct atk_data {
struct class_device *class_dev;
acpi_handle atk_handle;
struct acpi_device *device;
acpi_handle rtmp_handle;
acpi_handle rvlt_handle
Re: [RFC][PATCH] VM: per-user overcommit policy
Hi,
a few comments on the patch:
Andrea Righi <[EMAIL PROTECTED]> ha scritto:
> diff -urpN linux-2.6.21/include/linux/mman.h
> linux-2.6.21-vm-acct-user/include/linux/mman.h
> --- linux-2.6.21/include/linux/mman.h 2007-05-07 20:20:24.0 +0200
> +++ linux-2.6.21-vm-acct-user/include/linux/mman.h 2007-05-07
> 20:20:42.0 +0200
> @@ -18,6 +18,14 @@
> extern int sysctl_overcommit_memory;
> extern int sysctl_overcommit_ratio;
> extern atomic_t vm_committed_space;
> +#ifdef CONFIG_VM_ACCT_USER
> +struct vm_acct_values
> +{
> + int overcommit_memory;
> + int overcommit_ratio;
> +};
> +extern int vm_acct_get_config(struct vm_acct_values *v, uid_t uid);
> +#endif
>
> #ifdef CONFIG_SMP
> extern void vm_acct_memory(long pages);
> diff -urpN linux-2.6.21/ipc/shm.c linux-2.6.21-vm-acct-user/ipc/shm.c
> --- linux-2.6.21/ipc/shm.c 2007-05-07 20:20:24.0 +0200
> +++ linux-2.6.21-vm-acct-user/ipc/shm.c 2007-05-07 20:20:42.0 +0200
> @@ -370,12 +370,24 @@ static int newseg (struct ipc_namespace
>shp->mlock_user = current->user;
>} else {
>int acctflag = VM_ACCOUNT;
> +#ifdef CONFIG_VM_ACCT_USER
> + int overcommit_memory;
> + struct vm_acct_values v;
> +
> + if (!vm_acct_get_config(, current->uid)) {
> + overcommit_memory = v.overcommit_memory;
> + } else {
> + overcommit_memory = sysctl_overcommit_memory;
> + }
> +#else
> +#define overcommit_memory sysctl_overcommit_memory
> +#endif
>/*
> * Do not allow no accounting for OVERCOMMIT_NEVER, even
> * if it's asked for.
> */
>if ((shmflg & SHM_NORESERVE) &&
> - sysctl_overcommit_memory != OVERCOMMIT_NEVER)
> + overcommit_memory != OVERCOMMIT_NEVER)
Ugly... very ugly ;)
Don't hide 'overcommit_memory' inside the ifdef block. The compiler
should be smart enough to optimize away the extra var.
There's also a problem with the #ifdef scattered all over the code. You
need a static inline 'vm_acct_get_config' for the !CONFIG_VM_ACCT_USER
case:
static inline int vm_acct_get_config(struct vm_acct_values *v,
uid_t uid)
{
return 0;
}
in this way you can remove the #ifdef. Futhermore, I'd also move the
branch with the fallback to sysctl values inside the vm_acct_get_config.
So, for !CONFIG_VM_ACCT_USER:
static inline int vm_acct_get_config(struct vm_acct_values *v,
uid_t uid)
{
v->overcommit_memory = sysctl_overcommit_memory;
v->overcommit_ratio = sysctl_overcommit_ratio;
}
(Yes, gcc will optimize it)
and for CONFIG_VM_ACCT_USER:
int vm_acct_get_config(struct vm_acct_values *v, uid_t uid)
{
if (found uid) {
v->overcommit_memory = foo;
v->overcommit_ratio = bar;
} else {
v->overcommit_memory = sysctl_overcommit_memory;
v->overcommit_ratio = sysctl_overcommit_ratio;
}
}
> diff -urpN linux-2.6.21/mm/swap.c linux-2.6.21-vm-acct-user/mm/swap.c
> --- linux-2.6.21/mm/swap.c 2007-05-07 20:20:24.0 +0200
> +++ linux-2.6.21-vm-acct-user/mm/swap.c 2007-05-07 20:20:42.0 +0200
> @@ -30,6 +30,10 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
>
> /* How many pages do we try to swap or page in/out together? */
> int page_cluster;
> @@ -455,6 +459,196 @@ unsigned pagevec_lookup_tag(struct pagev
>
> EXPORT_SYMBOL(pagevec_lookup_tag);
>
> +#ifdef CONFIG_VM_ACCT_USER
> +
> +#define VM_ACCT_HASH_SHIFT 10
> +#define VM_ACCT_HASH_SIZE (1UL << VM_ACCT_HASH_SHIFT)
> +#define vm_acct_hashfn(uid) hash_long((unsigned long)uid, VM_ACCT_HASH_SHIFT)
> +
> +/* User VM overcommit configuration */
> +typedef struct vm_acct_hash_struct
> +{
> + uid_t uid;
> + struct vm_acct_values val;
> + struct hlist_node vm_acct_chain;
> +} vm_acct_hash_t;
> +
> +/* Hash list used to store per-user VM overcommit configurations */
> +static struct hlist_head *vm_acct_hash;
> +
> +/* VM overcommit hash table spinlock */
> +static __cacheline_aligned_in_smp DEFINE_SPINLOCK(vm_acct_lock);
> +
> +/*
> + * Get user VM configuration from the hash list.
> + */
> +int vm_acct_get_config(struct vm_acct_values *v, uid_t uid)
> +{
> + struct hlist_node *elem;
> + vm_acct_hash_t *p;
> +
> + spin_lock_irq(_acct_lock);
> + hlist_for_each_entry(p, elem, _acct_hash[vm_acct_hashfn(uid)],
> +vm_acct_chain) {
> + if (p->uid == uid) {
> + v->overcommit_memory = p->val.overcommit_memory;
> + v->overcommit_ratio = p->val.overcommit_ratio;
> + spin_unlock_irq(_acct_lock);
> + return 0;
> + }
> + }
> +
Re: [RFC][PATCH] VM: per-user overcommit policy
Hi,
a few comments on the patch:
Andrea Righi [EMAIL PROTECTED] ha scritto:
diff -urpN linux-2.6.21/include/linux/mman.h
linux-2.6.21-vm-acct-user/include/linux/mman.h
--- linux-2.6.21/include/linux/mman.h 2007-05-07 20:20:24.0 +0200
+++ linux-2.6.21-vm-acct-user/include/linux/mman.h 2007-05-07
20:20:42.0 +0200
@@ -18,6 +18,14 @@
extern int sysctl_overcommit_memory;
extern int sysctl_overcommit_ratio;
extern atomic_t vm_committed_space;
+#ifdef CONFIG_VM_ACCT_USER
+struct vm_acct_values
+{
+ int overcommit_memory;
+ int overcommit_ratio;
+};
+extern int vm_acct_get_config(struct vm_acct_values *v, uid_t uid);
+#endif
#ifdef CONFIG_SMP
extern void vm_acct_memory(long pages);
diff -urpN linux-2.6.21/ipc/shm.c linux-2.6.21-vm-acct-user/ipc/shm.c
--- linux-2.6.21/ipc/shm.c 2007-05-07 20:20:24.0 +0200
+++ linux-2.6.21-vm-acct-user/ipc/shm.c 2007-05-07 20:20:42.0 +0200
@@ -370,12 +370,24 @@ static int newseg (struct ipc_namespace
shp-mlock_user = current-user;
} else {
int acctflag = VM_ACCOUNT;
+#ifdef CONFIG_VM_ACCT_USER
+ int overcommit_memory;
+ struct vm_acct_values v;
+
+ if (!vm_acct_get_config(v, current-uid)) {
+ overcommit_memory = v.overcommit_memory;
+ } else {
+ overcommit_memory = sysctl_overcommit_memory;
+ }
+#else
+#define overcommit_memory sysctl_overcommit_memory
+#endif
/*
* Do not allow no accounting for OVERCOMMIT_NEVER, even
* if it's asked for.
*/
if ((shmflg SHM_NORESERVE)
- sysctl_overcommit_memory != OVERCOMMIT_NEVER)
+ overcommit_memory != OVERCOMMIT_NEVER)
Ugly... very ugly ;)
Don't hide 'overcommit_memory' inside the ifdef block. The compiler
should be smart enough to optimize away the extra var.
There's also a problem with the #ifdef scattered all over the code. You
need a static inline 'vm_acct_get_config' for the !CONFIG_VM_ACCT_USER
case:
static inline int vm_acct_get_config(struct vm_acct_values *v,
uid_t uid)
{
return 0;
}
in this way you can remove the #ifdef. Futhermore, I'd also move the
branch with the fallback to sysctl values inside the vm_acct_get_config.
So, for !CONFIG_VM_ACCT_USER:
static inline int vm_acct_get_config(struct vm_acct_values *v,
uid_t uid)
{
v-overcommit_memory = sysctl_overcommit_memory;
v-overcommit_ratio = sysctl_overcommit_ratio;
}
(Yes, gcc will optimize it)
and for CONFIG_VM_ACCT_USER:
int vm_acct_get_config(struct vm_acct_values *v, uid_t uid)
{
if (found uid) {
v-overcommit_memory = foo;
v-overcommit_ratio = bar;
} else {
v-overcommit_memory = sysctl_overcommit_memory;
v-overcommit_ratio = sysctl_overcommit_ratio;
}
}
diff -urpN linux-2.6.21/mm/swap.c linux-2.6.21-vm-acct-user/mm/swap.c
--- linux-2.6.21/mm/swap.c 2007-05-07 20:20:24.0 +0200
+++ linux-2.6.21-vm-acct-user/mm/swap.c 2007-05-07 20:20:42.0 +0200
@@ -30,6 +30,10 @@
#include linux/cpu.h
#include linux/notifier.h
#include linux/init.h
+#include linux/hash.h
+#include linux/seq_file.h
+#include linux/kernel.h
+#include linux/proc_fs.h
/* How many pages do we try to swap or page in/out together? */
int page_cluster;
@@ -455,6 +459,196 @@ unsigned pagevec_lookup_tag(struct pagev
EXPORT_SYMBOL(pagevec_lookup_tag);
+#ifdef CONFIG_VM_ACCT_USER
+
+#define VM_ACCT_HASH_SHIFT 10
+#define VM_ACCT_HASH_SIZE (1UL VM_ACCT_HASH_SHIFT)
+#define vm_acct_hashfn(uid) hash_long((unsigned long)uid, VM_ACCT_HASH_SHIFT)
+
+/* User VM overcommit configuration */
+typedef struct vm_acct_hash_struct
+{
+ uid_t uid;
+ struct vm_acct_values val;
+ struct hlist_node vm_acct_chain;
+} vm_acct_hash_t;
+
+/* Hash list used to store per-user VM overcommit configurations */
+static struct hlist_head *vm_acct_hash;
+
+/* VM overcommit hash table spinlock */
+static __cacheline_aligned_in_smp DEFINE_SPINLOCK(vm_acct_lock);
+
+/*
+ * Get user VM configuration from the hash list.
+ */
+int vm_acct_get_config(struct vm_acct_values *v, uid_t uid)
+{
+ struct hlist_node *elem;
+ vm_acct_hash_t *p;
+
+ spin_lock_irq(vm_acct_lock);
+ hlist_for_each_entry(p, elem, vm_acct_hash[vm_acct_hashfn(uid)],
+vm_acct_chain) {
+ if (p-uid == uid) {
+ v-overcommit_memory = p-val.overcommit_memory;
+ v-overcommit_ratio = p-val.overcommit_ratio;
+ spin_unlock_irq(vm_acct_lock);
+ return 0;
+ }
+ }
+
Re: [BUG? -rc7] SMP: Just one CPU activated: P4 3GHz HT
Il Mon, Apr 23, 2007 at 10:11:52AM +0200, Miguel Ojeda ha scritto: > On 4/22/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote: > >Probably the two siblings are enumerated only in ACPI tables. If you > >disable ACPI the kernel won't be aware of the second "core". > > > >Luca > >-- > >"Su cio` di cui non si puo` parlare e` bene tacere". > > Ludwig Wittgenstein > > > > On 4/23/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > > > >You didn't enable ACPI, it's needed for almost all systems to detect HT > >and also for many systems to detect multi-cores as well. > > > >Aside from that, in general I would say that on any modern x86 system > >ACPI should always be enabled. In many cases it seems the BIOS code is > >not tested much without ACPI anymore, so going without ACPI can be > >problematic. > > > >-- > >Robert Hancock Saskatoon, SK, Canada > >To email, remove "nospam" from [EMAIL PROTECTED] > >Home Page: http://www.roberthancock.com/ > > > > > > Thanks all of you. It seems the problem is ACPI, however, should not > it be noted in some way? Maybe at Documentation/smp.txt, maybe at the > help section at CONFIG_SMP, maybe a "depends on ..." > > Or maybe CONFIG_SMP should enable some bits of the ACPI code needed to > detect such additional cores. "depends on" is too strong. There exists architecture without ACPI but with SMP support; even in the x86 world a number of systems still support both MPS and ACPI. Mentioning it in the help text should be enough. Roman, are you in charge for the KConfig files? --- SMP support in modern systems often relies on ACPI being active; add a couple of lines in the help text for CONFIG_SMP Signed-Off-By: Luca Tettamanti <[EMAIL PROTECTED]> --- arch/i386/Kconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index 53d6237..48ef899 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -111,6 +111,9 @@ config SMP Y to "Enhanced Real Time Clock Support", below. The "Advanced Power Management" code will be disabled if you say Y here. + Note that ACPI is often required to support newer multi-core CPUs + and HT on Intel P4 processors. + See also the , , and the SMP-HOWTO available at Luca -- "Vorrei morire ucciso dagli agi. Vorrei che di me si dicesse: ``Com'� morto?'' ``Gli � scoppiato il portafogli''" -- Marcello Marchesi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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? -rc7] SMP: Just one CPU activated: P4 3GHz HT
Il Mon, Apr 23, 2007 at 10:11:52AM +0200, Miguel Ojeda ha scritto: On 4/22/07, Luca Tettamanti [EMAIL PROTECTED] wrote: Probably the two siblings are enumerated only in ACPI tables. If you disable ACPI the kernel won't be aware of the second core. Luca -- Su cio` di cui non si puo` parlare e` bene tacere. Ludwig Wittgenstein On 4/23/07, Robert Hancock [EMAIL PROTECTED] wrote: You didn't enable ACPI, it's needed for almost all systems to detect HT and also for many systems to detect multi-cores as well. Aside from that, in general I would say that on any modern x86 system ACPI should always be enabled. In many cases it seems the BIOS code is not tested much without ACPI anymore, so going without ACPI can be problematic. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ Thanks all of you. It seems the problem is ACPI, however, should not it be noted in some way? Maybe at Documentation/smp.txt, maybe at the help section at CONFIG_SMP, maybe a depends on ... Or maybe CONFIG_SMP should enable some bits of the ACPI code needed to detect such additional cores. depends on is too strong. There exists architecture without ACPI but with SMP support; even in the x86 world a number of systems still support both MPS and ACPI. Mentioning it in the help text should be enough. Roman, are you in charge for the KConfig files? --- SMP support in modern systems often relies on ACPI being active; add a couple of lines in the help text for CONFIG_SMP Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED] --- arch/i386/Kconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index 53d6237..48ef899 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -111,6 +111,9 @@ config SMP Y to Enhanced Real Time Clock Support, below. The Advanced Power Management code will be disabled if you say Y here. + Note that ACPI is often required to support newer multi-core CPUs + and HT on Intel P4 processors. + See also the file:Documentation/smp.txt, file:Documentation/i386/IO-APIC.txt, file:Documentation/nmi_watchdog.txt and the SMP-HOWTO available at Luca -- Vorrei morire ucciso dagli agi. Vorrei che di me si dicesse: ``Com'� morto?'' ``Gli � scoppiato il portafogli'' -- Marcello Marchesi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
