Re: [PATCH] platform/x86: dell-wmi-sysman: work around for BIOS bug

Hi, On 12/2/20 2:19 PM, Divya Bharathi wrote: > BIOS sets incorrect value (zero) when SET value passed for integer attribute > with + sign. Added workaround to remove + sign before passing input to BIOS > > Co-developed-by: Mario Limonciello > Signed-off-by: Mario Limonciello >

[PATCH] platform/x86: dell-wmi-sysman: work around for BIOS bug

BIOS sets incorrect value (zero) when SET value passed for integer attribute with + sign. Added workaround to remove + sign before passing input to BIOS Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Co-developed-by: Prasanth KSR Signed-off-by: Prasanth KSR Signed-off-by:

Re: [PATCH] platform/x86: dell-wmi-sysman: work around for BIOS bug

Hi, On 12/2/20 7:56 AM, Divya Bharathi wrote: > BIOS sets incorrect value (zero) when SET value passed for integer attribute > with + sign. Added workaround to remove + sign before passing input to BIOS > > Co-developed-by: Mario Limonciello > Signed-off-by: Mario Limonciello >

[PATCH] platform/x86: dell-wmi-sysman: work around for BIOS bug

BIOS sets incorrect value (zero) when SET value passed for integer attribute with + sign. Added workaround to remove + sign before passing input to BIOS Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Co-developed-by: Prasanth KSR Signed-off-by: Prasanth KSR Signed-off-by:

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

{ >>> @@ -46,9 +82,10 @@ static int cht_int33fe_probe(struct i2c_client >>> *client) >>> struct device *dev = >dev; >>> struct i2c_board_info board_info; >>> struct cht_int33fe_data *data; >>> + struct

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

t_int33fe_probe(struct i2c_client >>> *client) >>> struct device *dev = >dev; >>> struct i2c_board_info board_info; >>> struct cht_int33fe_data *data; >>> + struct i2c_client *max17047; >>> unsigned long long ptyp; &g

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

(board_info.type, "max17047", I2C_NAME_SIZE); - board_info.properties = max17047_props; - - data->max17047 = i2c_acpi_new_device(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, s

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

, I2C_NAME_SIZE); - board_info.properties = max17047_props; - - data->max17047 = i2c_acpi_new_device(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, see comment on cht_int33fe_find_max

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

-75,13 +112,25 @@ static int cht_int33fe_probe(struct i2c_client > *client) >   if (!data) >   return -ENOMEM; >   > - memset(_info, 0, sizeof(board_info)); > - strlcpy(board_info.type, "max17047", I2C_NAME_SIZE); > - bo

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

@@ static int cht_int33fe_probe(struct i2c_client > *client) >   if (!data) >   return -ENOMEM; >   > - memset(_info, 0, sizeof(board_info)); > - strlcpy(board_info.type, "max17047", I2C_NAME_SIZE); > - board_info.properties = max17047

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Sat, Sep 02, 2017 at 06:20:40PM +0200, Hans de Goede wrote: > At least one BIOS enumerates the max17047 both through the INT33FE ACPI > device (it is right there in the resources table) as well as through a > separate MAX17047 device. > > This commit checks for the max17047 already being

Re: [PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Sat, Sep 02, 2017 at 06:20:40PM +0200, Hans de Goede wrote: > At least one BIOS enumerates the max17047 both through the INT33FE ACPI > device (it is right there in the resources table) as well as through a > separate MAX17047 device. > > This commit checks for the max17047 already being

[PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

ata->max17047 = i2c_acpi_new_device(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, see comment on cht_int33fe_find_max17047 */ + max17047 = cht_int33fe_find_max17047(); + if

[PATCH v2] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

ce(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, see comment on cht_int33fe_find_max17047 */ + max17047 = cht_int33fe_find_max17047(); + if (max17047) { + /* Pre

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Fri, Sep 01, 2017 at 11:58:55PM +0200, Hans de Goede wrote: > Given that on the device in question where we need this workaround there > is only ever 1 max17047, including the instance number in the check really > is a non-problem, but if there is a strong preference for me to change > the

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Fri, Sep 01, 2017 at 11:58:55PM +0200, Hans de Goede wrote: > Given that on the device in question where we need this workaround there > is only ever 1 max17047, including the instance number in the check really > is a non-problem, but if there is a strong preference for me to change > the

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

Hi, On 09/01/2017 11:19 AM, Mika Westerberg wrote: On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

Hi, On 09/01/2017 11:19 AM, Mika Westerberg wrote: On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: +int

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: > On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: > > On 14-08-17 22:45, Andy Shevchenko wrote: > >> On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede > >> wrote: > > >>> +int

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: > On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: > > On 14-08-17 22:45, Andy Shevchenko wrote: > >> On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede > >> wrote: > > >>> +int cht_int33fe_check_for_max17047(struct device

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On 08/31/2017 07:04 PM, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: +int cht_int33fe_check_for_max17047(struct

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On 08/31/2017 07:04 PM, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: +int cht_int33fe_check_for_max17047(struct device *dev, void *data) +{ + const char

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: > On 14-08-17 22:45, Andy Shevchenko wrote: >> On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede >> wrote: >>> +int cht_int33fe_check_for_max17047(struct device *dev, void *data) >>> +{ >>> +

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: > On 14-08-17 22:45, Andy Shevchenko wrote: >> On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede >> wrote: >>> +int cht_int33fe_check_for_max17047(struct device *dev, void *data) >>> +{ >>> + const char *name = dev_name(dev); >>> +

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, see comment on cht_int33fe_find_max17047 */ + max17047 = cht_int33fe_find_max17047(); + if (max17047) { + /* Pre-existing i2c-client for the max17047, add device-props */ + ret = devic

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

0, sizeof(board_info)); - strlcpy(board_info.type, "max17047", I2C_NAME_SIZE); - board_info.properties = max17047_props; - - data->max17047 = i2c_acpi_new_device(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapte

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

Hi, On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: At least one BIOS enumerates the max17047 both through the INT33FE ACPI device (it is right there in the resources table) as well as through a separate MAX17047 device.

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

Hi, On 14-08-17 22:45, Andy Shevchenko wrote: On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: At least one BIOS enumerates the max17047 both through the INT33FE ACPI device (it is right there in the resources table) as well as through a separate MAX17047 device. This commit checks for

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: > At least one BIOS enumerates the max17047 both through the INT33FE ACPI > device (it is right there in the resources table) as well as through a > separate MAX17047 device. > > This commit checks for the max17047

Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede wrote: > At least one BIOS enumerates the max17047 both through the INT33FE ACPI > device (it is right there in the resources table) as well as through a > separate MAX17047 device. > > This commit checks for the max17047 already being enumerated

[PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

nfo.properties = max17047_props; - - data->max17047 = i2c_acpi_new_device(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, see comment on cht_int33fe_find_max17047 */ + max17047 = cht_int33fe_

[PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices

data->max17047 = i2c_acpi_new_device(dev, 1, _info); - if (!data->max17047) - return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ + /* Work around BIOS bug, see comment on cht_int33fe_find_max17047 */ + max17047 = cht_int33fe_find_max17047(); + i

Re: FW/BIOS Bug category for oops.kernel.org

On Mon, Nov 03, 2014 at 10:34:43PM +0100, Borislav Petkov wrote: > On Mon, Nov 03, 2014 at 10:26:10PM +0100, Peter Zijlstra wrote: > > Hi oops.kernel.org folks, > > > > I'm wanting to collect information on FW/BIOS bugs, and I figured that > > we could use the oops.kernel.org infrastructure to do

Re: FW/BIOS Bug category for oops.kernel.org

On Mon, Nov 03, 2014 at 10:26:10PM +0100, Peter Zijlstra wrote: > Hi oops.kernel.org folks, > > I'm wanting to collect information on FW/BIOS bugs, and I figured that > we could use the oops.kernel.org infrastructure to do this. > > Now, I'd prefer to not use the regular BUG/WARN because it

FW/BIOS Bug category for oops.kernel.org

Hi oops.kernel.org folks, I'm wanting to collect information on FW/BIOS bugs, and I figured that we could use the oops.kernel.org infrastructure to do this. Now, I'd prefer to not use the regular BUG/WARN because it might confuse users and the stacktrace is entirely pointless -- we know were/why

FW/BIOS Bug category for oops.kernel.org

Hi oops.kernel.org folks, I'm wanting to collect information on FW/BIOS bugs, and I figured that we could use the oops.kernel.org infrastructure to do this. Now, I'd prefer to not use the regular BUG/WARN because it might confuse users and the stacktrace is entirely pointless -- we know were/why

Re: FW/BIOS Bug category for oops.kernel.org

On Mon, Nov 03, 2014 at 10:26:10PM +0100, Peter Zijlstra wrote: Hi oops.kernel.org folks, I'm wanting to collect information on FW/BIOS bugs, and I figured that we could use the oops.kernel.org infrastructure to do this. Now, I'd prefer to not use the regular BUG/WARN because it might

Re: FW/BIOS Bug category for oops.kernel.org

On Mon, Nov 03, 2014 at 10:34:43PM +0100, Borislav Petkov wrote: On Mon, Nov 03, 2014 at 10:26:10PM +0100, Peter Zijlstra wrote: Hi oops.kernel.org folks, I'm wanting to collect information on FW/BIOS bugs, and I figured that we could use the oops.kernel.org infrastructure to do this.

[PATCH 48/49] ACPI: Harden acpi_table_parse_entries() against BIOS bug

From: Fenghua Yu Parsing acpi table entries may fall into an infinite loop on a buggy BIOS which has entry length=0 in acpi table. Instead of kernel hang with few failure clue which leads to heavy lifting debug effort, this patch hardens kernel boot by booting into non NUMA mode. The debug info

[PATCH 48/49] ACPI: Harden acpi_table_parse_entries() against BIOS bug

From: Fenghua Yu fenghua...@intel.com Parsing acpi table entries may fall into an infinite loop on a buggy BIOS which has entry length=0 in acpi table. Instead of kernel hang with few failure clue which leads to heavy lifting debug effort, this patch hardens kernel boot by booting into non NUMA

Re: HDD problem, software bug, bios bug, or hardware ?

Mikael writes: >Please try the patch below, which implements the fix I described a >week ago. It's for 3.6-rc4 but should work in any recent kernel. >Without this patch one of my test machines always throws a lockdep >warning involving pdc_sata_hardreset and pdc_interrupt during bootup, >but

Re: HDD problem, software bug, bios bug, or hardware ?

Mikael writes: Please try the patch below, which implements the fix I described a week ago. It's for 3.6-rc4 but should work in any recent kernel. Without this patch one of my test machines always throws a lockdep warning involving pdc_sata_hardreset and pdc_interrupt during bootup, but with the

Re: HDD problem, software bug, bios bug, or hardware ?

On Sun, Sep 02, 2012 at 10:04:53PM +0200, Mikael Pettersson wrote: > pdc_hard_reset_port needs to serialize because hard reset has to flip > a port-specific bit in a controller register that's shared by all > ports, so it takes the host lock. But now an interrupt occurs during > the hard reset,

Re: HDD problem, software bug, bios bug, or hardware ?

On Fri, Sep 07, 2012 at 04:32:56AM -0700, Adko Branil wrote: > After updating bios no more crashes happened, i tested it many times > on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT > kernels). Alriiight, one of the most seldom times where a BIOS update actually fixes things

Re: HDD problem, software bug, bios bug, or hardware ?

On Fri, Sep 07, 2012 at 04:32:56AM -0700, Adko Branil wrote: After updating bios no more crashes happened, i tested it many times on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT kernels). Alriiight, one of the most seldom times where a BIOS update actually fixes things :-).

Re: HDD problem, software bug, bios bug, or hardware ?

On Sun, Sep 02, 2012 at 10:04:53PM +0200, Mikael Pettersson wrote: pdc_hard_reset_port needs to serialize because hard reset has to flip a port-specific bit in a controller register that's shared by all ports, so it takes the host lock. But now an interrupt occurs during the hard reset, and

Re: HDD problem, software bug, bios bug, or hardware ?

>Please try the patch below, which implements the fix I described a >week ago. It's for 3.6-rc4 but should work in any recent kernel. >Without this patch one of my test machines always throws a lockdep >warning involving pdc_sata_hardreset and pdc_interrupt during bootup, >but with the patch the

Re: HDD problem, software bug, bios bug, or hardware ?

Adko Branil writes: > After updating bios no more crashes happened, i tested it many times > on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT > kernels). But now if enable "Cool'n' Quiet" option in bios,  > CONFIG_PREEMPT_VOLUNTARY kernel with passed "nosmp" at boot time, >

Re: HDD problem, software bug, bios bug, or hardware ?

Adko Branil writes: After updating bios no more crashes happened, i tested it many times on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT kernels). But now if enable Cool'n' Quiet option in bios,  CONFIG_PREEMPT_VOLUNTARY kernel with passed nosmp at boot time, crashes

Re: HDD problem, software bug, bios bug, or hardware ?

Please try the patch below, which implements the fix I described a week ago. It's for 3.6-rc4 but should work in any recent kernel. Without this patch one of my test machines always throws a lockdep warning involving pdc_sata_hardreset and pdc_interrupt during bootup, but with the patch the

Re: HDD problem, software bug, bios bug, or hardware ?

After updating bios no more crashes happened, i tested it many times on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT kernels). But now if enable "Cool'n' Quiet" option in bios,  CONFIG_PREEMPT_VOLUNTARY kernel with passed "nosmp" at boot time, crashes during boot process with

Re: HDD problem, software bug, bios bug, or hardware ?

After updating bios no more crashes happened, i tested it many times on heavy HDD IO loads, with many kernels (including CONFIG_PREEMPT kernels). But now if enable Cool'n' Quiet option in bios,  CONFIG_PREEMPT_VOLUNTARY kernel with passed nosmp at boot time, crashes during boot process with

Re: HDD problem, software bug, bios bug, or hardware ?

> But now an interrupt occurs during the hard >reset, and pdc_interrupt also has to take the host lock. I have 4 sata connectors on the motherboard - http://www.hardwareheaven.com/reviews/asusA8V/ If i understand right, just 2 of them are linked to promise controller. Well i changed the

Re: HDD problem, software bug, bios bug, or hardware ?

But now an interrupt occurs during the hard reset, and pdc_interrupt also has to take the host lock. I have 4 sata connectors on the motherboard - http://www.hardwareheaven.com/reviews/asusA8V/ If i understand right, just 2 of them are linked to promise controller. Well i changed the

Re: HDD problem, software bug, bios bug, or hardware ?

Adko Branil writes: > >Right near the end there's a lockdep warning about a deadlock > > >between sata_promise's hardreset thing and the machine getting a > >ata_bmdma_interrupt. > > >But since I don't know this code, it would be nice if you could take a > >look at it. > > I picked up

Re: HDD problem, software bug, bios bug, or hardware ?

Adko Branil writes: Right near the end there's a lockdep warning about a deadlock between sata_promise's hardreset thing and the machine getting a ata_bmdma_interrupt. But since I don't know this code, it would be nice if you could take a look at it. I picked up 3 more dmesg

Re: HDD problem, software bug, bios bug, or hardware ?

>Right near the end there's a lockdep warning about a deadlock >between sata_promise's hardreset thing and the machine getting a >ata_bmdma_interrupt. >But since I don't know this code, it would be nice if you could take a >look at it. I picked up 3 more dmesg after rebooting, and 2 more

Re: HDD problem, software bug, bios bug, or hardware ?

On Wed, Aug 29, 2012 at 10:31:43AM -0700, Adko Branil wrote: > And one more thing i forgot - during kernel compilation i noticed this: > > WARNING: modpost: Found 1 section mismatch(es). > To see full details build your kernel with: > 'make CONFIG_DEBUG_SECTION_MISMATCH=y' > > > > And when i

Re: HDD problem, software bug, bios bug, or hardware ?

On Thu, Aug 30, 2012 at 11:58:08AM +0200, Borislav Petkov wrote: > Kernel is 3.5.2, 32-bit. Correction: 64-bit. -- Regards/Gruss, Boris. -- 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

Re: HDD problem, software bug, bios bug, or hardware ?

On Thu, Aug 30, 2012 at 11:58:08AM +0200, Borislav Petkov wrote: Kernel is 3.5.2, 32-bit. Correction: 64-bit. -- Regards/Gruss, Boris. -- 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

Re: HDD problem, software bug, bios bug, or hardware ?

On Wed, Aug 29, 2012 at 10:31:43AM -0700, Adko Branil wrote: And one more thing i forgot - during kernel compilation i noticed this: WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' And when i compiled

Re: HDD problem, software bug, bios bug, or hardware ?

Right near the end there's a lockdep warning about a deadlock between sata_promise's hardreset thing and the machine getting a ata_bmdma_interrupt. But since I don't know this code, it would be nice if you could take a look at it. I picked up 3 more dmesg after rebooting, and 2 more oopses.  I

Re: HDD problem, software bug, bios bug, or hardware ?

And one more thing i forgot - during kernel compilation i noticed this: WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' And when i compiled with "make CONFIG_DEBUG_SECTION_MISMATCH=y", somewhere at the end was:

Re: HDD problem, software bug, bios bug, or hardware ?

And one more thing i forgot - during kernel compilation i noticed this: WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' And when i compiled with make CONFIG_DEBUG_SECTION_MISMATCH=y, somewhere at the end was:

Re: HDD problem, software bug, bios bug, or hardware ?

On Mon, Aug 27, 2012 at 10:01:12AM -0700, Adko Branil wrote: > >Stupid question: have you tried replacing your DIMMs to see whether this > >can be caused by a faulty DRAM? > > I just tried it - i have 2 banks memory each of 1 Mb - i replaced You mean 1 Gb each, right? > the first , then the

Re: HDD problem, software bug, bios bug, or hardware ?

>Stupid question: have you tried replacing your DIMMs to see whether this >can be caused by a faulty DRAM? I just tried it - i have 2 banks memory each of 1 Mb - i replaced the first , then the second, then replaced both and put memory from another computer, tried another slots as well - the

Re: HDD problem, software bug, bios bug, or hardware ?

Stupid question: have you tried replacing your DIMMs to see whether this can be caused by a faulty DRAM? I just tried it - i have 2 banks memory each of 1 Mb - i replaced the first , then the second, then replaced both and put memory from another computer, tried another slots as well - the same

Re: HDD problem, software bug, bios bug, or hardware ?

On Mon, Aug 27, 2012 at 10:01:12AM -0700, Adko Branil wrote: Stupid question: have you tried replacing your DIMMs to see whether this can be caused by a faulty DRAM? I just tried it - i have 2 banks memory each of 1 Mb - i replaced You mean 1 Gb each, right? the first , then the second,

Re: HDD problem, software bug, bios bug, or hardware ?

Adding linux-kernel to CC. On Sat, Aug 25, 2012 at 06:36:11AM -0700, Adko Branil wrote: > Here i post few more panics, the last 3-4 or 5 of them are with boot > option "nosmp". I will take a look at the motherboard to see is there > any visual sign for this plague after 2 days probably, as i am

Re: HDD problem, software bug, bios bug, or hardware ?

Adding linux-kernel to CC. On Sat, Aug 25, 2012 at 06:36:11AM -0700, Adko Branil wrote: Here i post few more panics, the last 3-4 or 5 of them are with boot option nosmp. I will take a look at the motherboard to see is there any visual sign for this plague after 2 days probably, as i am no

Re: PCI Express MMCONFIG and BIOS Bug messages..

Jesse Barnes wrote: On Sunday, April 29, 2007, Robert Hancock wrote: Problem is that even if we read the MMCONFIG table location from the hardware registers, that doesn't mean we can trust the result. It could be that the BIOS hasn't lied about where it put the table, it just stuck it someplace

Re: PCI Express MMCONFIG and BIOS Bug messages..

On Sunday, April 29, 2007, Robert Hancock wrote: > Problem is that even if we read the MMCONFIG table location from the > hardware registers, that doesn't mean we can trust the result. It could > be that the BIOS hasn't lied about where it put the table, it just stuck > it someplace completely

Re: PCI Express MMCONFIG and BIOS Bug messages..

to handle a common i965 BIOS bug. Also there is the nasty case of the Apple EFI boxes where only mmconfig works which has to be handled too. I expect eventually the logic to be: - If we know the hardware: read it from hw registers; trust them; ignore BIOS. - Otherwise check e820 and ACPI resources

Re: PCI Express MMCONFIG and BIOS Bug messages..

handle a common i965 BIOS bug. Also there is the nasty case of the Apple EFI boxes where only mmconfig works which has to be handled too. I expect eventually the logic to be: - If we know the hardware: read it from hw registers; trust them; ignore BIOS. - Otherwise check e820 and ACPI resources and b

Re: PCI Express MMCONFIG and BIOS Bug messages..

i965 BIOS bug. Also there is the nasty case of the Apple EFI boxes where only mmconfig works which has to be handled too. I expect eventually the logic to be: - If we know the hardware: read it from hw registers; trust them; ignore BIOS. - Otherwise check e820 and ACPI resources and be very

Re: PCI Express MMCONFIG and BIOS Bug messages..

to handle a common i965 BIOS bug. Also there is the nasty case of the Apple EFI boxes where only mmconfig works which has to be handled too. I expect eventually the logic to be: - If we know the hardware: read it from hw registers; trust them; ignore BIOS. - Otherwise check e820 and ACPI resources

Re: PCI Express MMCONFIG and BIOS Bug messages..

On Sunday, April 29, 2007, Robert Hancock wrote: Problem is that even if we read the MMCONFIG table location from the hardware registers, that doesn't mean we can trust the result. It could be that the BIOS hasn't lied about where it put the table, it just stuck it someplace completely

Re: PCI Express MMCONFIG and BIOS Bug messages..

Jesse Barnes wrote: On Sunday, April 29, 2007, Robert Hancock wrote: Problem is that even if we read the MMCONFIG table location from the hardware registers, that doesn't mean we can trust the result. It could be that the BIOS hasn't lied about where it put the table, it just stuck it someplace

Re: PCI Express MMCONFIG and BIOS Bug messages..

Chuck Ebbert wrote: Robert Hancock wrote: I've seen a lot of systems (including brand new Xeon-based servers from IBM and HP) that output messages on boot like: PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. So Microsoft is explicitly telling the BIOS

Re: PCI Express MMCONFIG and BIOS Bug messages..

Chuck Ebbert wrote: Robert Hancock wrote: I've seen a lot of systems (including brand new Xeon-based servers from IBM and HP) that output messages on boot like: PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. So Microsoft is explicitly telling the BIOS

Re: PCI Express MMCONFIG and BIOS Bug messages..

Robert Hancock wrote: > I've seen a lot of systems (including brand new Xeon-based servers from > IBM and HP) that output messages on boot like: > > PCI: BIOS Bug: MCFG area at f000 is not E820-reserved > PCI: Not using MMCONFIG. > > > So Microsoft is explicitly tel

Re: PCI Express MMCONFIG and BIOS Bug messages..

Robert Hancock wrote: I've seen a lot of systems (including brand new Xeon-based servers from IBM and HP) that output messages on boot like: PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. So Microsoft is explicitly telling the BIOS developers

PCI Express MMCONFIG and BIOS Bug messages..

I've seen a lot of systems (including brand new Xeon-based servers from IBM and HP) that output messages on boot like: PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. As I understand it, this is sort of a sanity check mechanism to make sure the MCFG address

PCI Express MMCONFIG and BIOS Bug messages..

I've seen a lot of systems (including brand new Xeon-based servers from IBM and HP) that output messages on boot like: PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. As I understand it, this is sort of a sanity check mechanism to make sure the MCFG address

Re: PCI BIOS Bug messages

Vasudevan S wrote: I run Fedora Core 6 on the 'compaq nc6320' laptop. I am using the '2.6.19.1' kernel. While booting the kernel, I noticed the following error message: PCI: BIOS Bug: MCFG area at f800 is not E820-reserved PCI: Not using MMCONFIG. After some search, I commented out

PCI BIOS Bug messages

I run Fedora Core 6 on the 'compaq nc6320' laptop. I am using the '2.6.19.1' kernel. While booting the kernel, I noticed the following error message: PCI: BIOS Bug: MCFG area at f800 is not E820-reserved PCI: Not using MMCONFIG. After some search, I commented out the 'e820_all_mapped

PCI BIOS Bug messages

I run Fedora Core 6 on the 'compaq nc6320' laptop. I am using the '2.6.19.1' kernel. While booting the kernel, I noticed the following error message: PCI: BIOS Bug: MCFG area at f800 is not E820-reserved PCI: Not using MMCONFIG. After some search, I commented out the 'e820_all_mapped

Re: PCI BIOS Bug messages

Vasudevan S wrote: I run Fedora Core 6 on the 'compaq nc6320' laptop. I am using the '2.6.19.1' kernel. While booting the kernel, I noticed the following error message: PCI: BIOS Bug: MCFG area at f800 is not E820-reserved PCI: Not using MMCONFIG. After some search, I commented out

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, Dec 01, 2006 at 03:32:47PM -0800, [EMAIL PROTECTED] wrote: > On Fri, Dec 01, 2006 at 03:29:22PM -0800, Pete Zaitcev wrote: > > On Fri, 1 Dec 2006 15:23:39 -0800, [EMAIL PROTECTED] wrote: > > > > > BIOS handoff assumes an SMI, right? Could SMI be masked? > > > > That might be a bad idea,

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, Dec 01, 2006 at 03:29:22PM -0800, Pete Zaitcev wrote: > On Fri, 1 Dec 2006 15:23:39 -0800, [EMAIL PROTECTED] wrote: > > > BIOS handoff assumes an SMI, right? Could SMI be masked? > > That might be a bad idea, because things like fans may be controlled > by SMM BIOS. The best thing we

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, Dec 01, 2006 at 03:02:01PM -0800, Pete Zaitcev wrote: > On Fri, 1 Dec 2006 19:28:55 +0100, Sebastian Kemper <[EMAIL PROTECTED]> wrote: > > > I also increased the wait time from 5 seconds to 20 in > > drivers/usb/host/pci-quirks.c but that didn't change anything. > > That was a good try,

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, 1 Dec 2006 15:23:39 -0800, [EMAIL PROTECTED] wrote: > BIOS handoff assumes an SMI, right? Could SMI be masked? That might be a bad idea, because things like fans may be controlled by SMM BIOS. The best thing we can do is to follow the published procedure, and maybe insert a workaround

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, 1 Dec 2006 19:28:55 +0100, Sebastian Kemper <[EMAIL PROTECTED]> wrote: > I also increased the wait time from 5 seconds to 20 in > drivers/usb/host/pci-quirks.c but that didn't change anything. That was a good try, but I thought maybe it needs doing something twice, or having some extra

Re: [OHCI] BIOS handoff failed (BIOS bug?)

TCP established hash table entries: 16384 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 16384 bind 8192) TCP reno registered Machine check exception polling timer started. io scheduler noop r

[OHCI] BIOS handoff failed (BIOS bug?)

Hello all, I sometimes get this message when I boot kernel 2.6.19. Could this be related to the BIOS option "USB keyboard support"? When I turn it off I never get the "handoff failed" message afaik. But I need it to access lilo. Now I use an USB->PS2 adapter and turn "USB keyboard support" off.

[OHCI] BIOS handoff failed (BIOS bug?)

Hello all, I sometimes get this message when I boot kernel 2.6.19. Could this be related to the BIOS option USB keyboard support? When I turn it off I never get the handoff failed message afaik. But I need it to access lilo. Now I use an USB-PS2 adapter and turn USB keyboard support off. If

Re: [OHCI] BIOS handoff failed (BIOS bug?)

tables configured (established 16384 bind 8192) TCP reno registered Machine check exception polling timer started. io scheduler noop registered io scheduler cfq registered (default) :00:02.0 OHCI: BIOS handoff failed (BIOS bug ?) 0784

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, 1 Dec 2006 19:28:55 +0100, Sebastian Kemper [EMAIL PROTECTED] wrote: I also increased the wait time from 5 seconds to 20 in drivers/usb/host/pci-quirks.c but that didn't change anything. That was a good try, but I thought maybe it needs doing something twice, or having some extra bits

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, 1 Dec 2006 15:23:39 -0800, [EMAIL PROTECTED] wrote: BIOS handoff assumes an SMI, right? Could SMI be masked? That might be a bad idea, because things like fans may be controlled by SMM BIOS. The best thing we can do is to follow the published procedure, and maybe insert a workaround if

Re: [OHCI] BIOS handoff failed (BIOS bug?)

On Fri, Dec 01, 2006 at 03:02:01PM -0800, Pete Zaitcev wrote: On Fri, 1 Dec 2006 19:28:55 +0100, Sebastian Kemper [EMAIL PROTECTED] wrote: I also increased the wait time from 5 seconds to 20 in drivers/usb/host/pci-quirks.c but that didn't change anything. That was a good try, but I

  1   2   >