netdev - Re: Regression on VIA C3 motherboard, commit: 66f2173e2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 06 Feb 2009 11:20:08 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	Len Brown <lenb@...nel.org>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>, linux-acpi@...r.kernel.org
Subject: Re: Regression on VIA C3 motherboard, commit: 66f2173e2

Len Brown wrote:
> Thanks for the bisect, Ben.
> 
> Please test the patch below.
> 
> I assume even without the patch, booting with "acpi=off" on your
> BIOS-ACPI-disabled box works?  (if no, this patch will not solve
> all your problems, for you have additional trouble elsewhere)
> 
> I am curious why you're running a CONFIG_ACPI=y kernel
> for a box with ACPI disabled. (though yes, it is supposed to work)
> 
> I'm even more curious what bad things happen when
> you enable ACPI in the BIOS -- can you let me know
> and we can try to fix them so the machine can run as shipped?

At one time, these boxes would actually burn out their power
supply if you did an 'init 0' with the BIOS configured to
shut down the system.  It would just suck more and more power
(we measured) until the brick smoked, and the motherboard components
got very hot as well.  I think we were just lucky that the PS died
before the MB did.

This was a while back, but I believe part of the fix was to disable
ACPI so the system couldn't possibly try to power itself down
in this manner.

I will try your patch, but I'm about to go off for a ~2week vacation,
so I probably won't have time to test enabling ACPI and/or compiling
a kernel w/out it to see what shakes out.

I re-worked my previous patch per Ingo's suggestion and am
about to send it off..but please feel free to NAK it if you
think it's wrong.  I don't really know enough about this area
to argue one way or another.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html