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
> Co-developed-by:
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:
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
> Co-developed-by:
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:
ic int cht_int33fe_probe(struct i2c_client
>>> *client)
>>> struct device *dev = &client->dev;
>>> struct i2c_board_info board_info;
>>> struct cht_int33fe_data *data;
>>> + struct i2c_client *max17047;
>>>
));
- strlcpy(board_info.type, "max17047", I2C_NAME_SIZE);
- board_info.properties = max17047_props;
-
- data->max17047 = i2c_acpi_new_device(dev, 1, &board_info);
- if (!data->max17047)
- return -EPROBE_DEFER; /* Wait for the i2c-adapter t
I_FAILURE(status)) {
> @@ -75,13 +112,25 @@ static int cht_int33fe_probe(struct i2c_client
> *client)
> if (!data)
> return -ENOMEM;
>
> - memset(&board_info, 0, sizeof(board_info));
> - strlcpy(board_info.type, "max17047", I2C_NAME_SIZE);
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 enumer
s;
-
- data->max17047 = i2c_acpi_new_device(dev, 1, &board_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
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 check
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 cht_int33fe_che
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 *dev,
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 *
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);
>>> +
47)
- 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-existing i2c-client for the max17047, add device-props
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
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 thr
board_info.properties = max17047_props;
-
- data->max17047 = i2c_acpi_new_device(dev, 1, &board_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
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
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
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
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
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
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
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 :-)
>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 w
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,
> c
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
> 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 conn
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
>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.
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 co
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 ht
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:
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 secon
>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 sam
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
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
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 unsu
right now 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
now 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 resou
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
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 explicitl
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 ad
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 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
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,
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 can
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, b
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
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 bi
4096 (order: 2, 16384 bytes)
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 time
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.
I
>>>-Original Message-
>>>From: [EMAIL PROTECTED]
>>>[mailto:[EMAIL PROTECTED] On Behalf Of
>Enrico Bartky
>>>Sent: Monday, February 07, 2005 7:12 AM
>>>To: linux-kernel@vger.kernel.org
>>>Subject: BIOS Bug
>>>
>>>
Aleksey Gorelov schrieb:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Enrico Bartky
Sent: Monday, February 07, 2005 7:12 AM
To: linux-kernel@vger.kernel.org
Subject: BIOS Bug
Hello,
on my notebook, when I plugged in my USB keyboard the kernel
doesnt
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Enrico Bartky
>Sent: Monday, February 07, 2005 7:12 AM
>To: linux-kernel@vger.kernel.org
>Subject: BIOS Bug
>
>Hello,
>
>on my notebook, when I plugged in my USB key
Hello,
on my notebook, when I plugged in my USB keyboard the kernel doesnt boot
correctly, ...
...
BIOS hangoff failed ( 112, 1010001 )
continuing after BIOS bug
irq 192, pci mem 0xfebff000
new usb device registered, assigned bus number 1
...
then the notebook hangs. If I boot without the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This weekend I've been installing Debian 2.2 on an HP Pavilion 8756C,
and I haven't been able to get sound working. The machine has an
Intel 810e multifunction contoller onboard. The i810_audio module
seems to be able to find the right device, but c
58 matches
Mail list logo
