linux-kernel - Re: Possible bug in via-velocity on 3.0+

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:	Wed, 19 Oct 2011 16:47:05 +0100
From:	n00b <n00b@...bsys0p.co.uk>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Possible bug in via-velocity on 3.0+

On 19/10/11 16:14, Bjorn Helgaas wrote:
> On Wed, Oct 19, 2011 at 4:14 AM, n00b<n00b@...bsys0p.co.uk>  wrote:
>> On 18/10/11 17:15, Bjorn Helgaas wrote:
>>> On Tue, Oct 18, 2011 at 10:01 AM, n00bsys0p<n00b@...bsys0p.co.uk>    wrote:
>>>> Hi,
>>>>
>>>> I've been trying to get a custom 3.0 kernel to boot via PXE on a VIA EPIA
>>>> EN15000G, and have run into a problem where once the thin client starts
>>>> to
>>>> load the kernel, the entire screen turns into a mosaic of random colours
>>>> and
>>>> characters.
>>>>
>>>> I've tested this serving a 2.6.35.8 kernel (configured identically to the
>>>> 3.0) to the thin client where the master and client are both fitted with
>>>> EPIA EN1500G, and it works perfectly. Also, I tried swapping the master's
>>>> motherboard to a Gigabyte GA-D525TUD (Realtek LAN chip), and it succeeded
>>>> in
>>>> serving the 3.0 kernel to an EN15000G without a fault.
>>>>
>>>> In all test cases, the master was using a 3.0 kernel.
>>>>
>>>> Through this testing, I surmise that it is something to do with the LAN
>>>> driver which is used, as this is the only thing I can see to have changed
>>>> between the two running systems. Could it be accidentally overwriting the
>>>> video RAM or something along those lines?
>>>>
>>>> Here's a link to a photo of what the screen looks like when it goes
>>>> wrong:
>>>>
>>>> https://lh3.googleusercontent.com/-sXFP41oaF9U/TpyMFg89CqI/AAAAAAAAA-I/PBrltIm0cB4/s720/PXEFail.jpg
>>> Let me see if I understand this correctly:
>>>
>>>    - The problem is on the EN15000G client.
>>>    - It occurs when the client boots 3.0 from a EN1500G server, but not
>>> when booting the same 3.0 kernel image from a GA-D525TUD server.
>>>    - It doesn't occur when booting 2.6.35.8 from a EN1500G server.
>>>    - The client boots successfully and is usable, i.e., the only
>>> problem is the temporary garbage on the screen during boot.
>>>
>>> It would be useful to see the complete dmesg log from 2.6.35.8 on the
>>> client.  If 3.0 actually does boot on the client, a dmesg log from 3.0
>>> would also be useful.  There might be a clue if we can compare them.
>>>
>>> Bjorn
>> In answer:
>>   - Yes, the problem is a client machine with an EN15000G board
>>   - Correct, the 3.0 kernel image booted the client using a GA-D525TUD
>> server, but not when using an EN15000G
>>   - Correct again, the 2.6.35.8 image booted correctly from an EN15000G
>> server
>>   - Not correct. The problem is permanent when it occurs. The client machine
>> has been left for hours, and all that is visible is the garbage on screen.
> Good.  That's what I suspected, just wanted to make sure.
>
>> I'm not sure if it was a one-off, but I can't appear to get it to serve the
>> 3.0 kernel from the Gigabyte motherboard now. Exactly the same thing is
>> happening as with the EN15000G (garbage mosaic).
> Also good, that's what I would expect.  It would be very strange if
> the same bits worked differently, depending on what server they came
> from.
>
>> I've attached the dmesg log from the client for the 2.6.35.8 kernel. If I
>> manage to get the 3.0 kernel to boot again, I'll send over the dmesg log for
>> that.
> That makes this a regression between 2.6.35.8 and 3.0.  The easiest
> (though tedious) way to find the problem is to bisect between those
> versions (http://www.landley.net/writing/git-bisect-howto.html).
>
> I don't see many interesting via-velocity changes since 2.6.35.  I'd
> suspect some sort of video mode problem, given the screen issue.
> Maybe you could learn something by turning off vesafb and the
> bootsplash stuff.
>
> Bjorn
Ok, thanks. I'll try that, and see where I get. I'll recompile the 
kernel without bootsplash, and see if I
see any different behaviour.

I'll let you know where I get, should I find anything useful out.

Thanks for your help!

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/