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] [day] [month] [year] [list]
Date:	Thu, 31 Jul 2008 21:43:50 -0400
From:	"Paul Gortmaker" <paul.gortmaker@...il.com>
To:	"Kumar Gala" <galak@...nel.crashing.org>
Cc:	"Paul Gortmaker" <paul.gortmaker@...driver.com>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] suggested fix for 83xx/85xx PowerPC UART break bug

On Thu, Jul 31, 2008 at 4:31 PM, Kumar Gala <galak@...nel.crashing.org> wrote:
>
> On Jul 31, 2008, at 10:26 AM, Paul Gortmaker wrote:
>
>>
>> This is something I'd tripped over earlier, and wanted to follow up on
>> to get an acceptable fix in for everyone's benefit before it falls through
>> the cracks again.
>>
>> There seems to be an issue with recent 83xx/85xx SOC UARTs, in which a
>> break
>> triggers a short lived IRQ storm (hence killing any hope of using SysRQ).
>> The only fix I found to work was to just ignore the bogus events that
>> had the associated signature bit set.
>>
>> This fix is what I was using against earlier kernels, but I hate to add
>> more
>> board/arch specific ifdefs to files like 8250.c, so I'm wondering if
>> anyone has any other suggestions before I simply end up cleaning up the
>> boardlist (now ppc is dead) and respinning the patch much as it is now
>> and resending.
>
> How did you test this or generate it?  I was thinking about this the other
> day and figured we need to try and track this down with the HW guys.  If we
> can generate a simple test I can try and run it through the various
> boards/parts we have and see which ones show the issue and which dont.

Actually, it is dead easy to reproduce.  The obvious symptom is that you'll
get a random complaint that SysRQ doesn't work.  You send the break via
whatever comm program you use, and 9 out of 10 times, you get the SysRQ
help menu pop up immediately, before you've even entered another character.

Once you dig a bit deeper, then you see that simply sending the break via
the comm program (and nothing else) will result in roughly 300 to 2000 events
as reported via "cat /proc/interrupts" on the UART in question.

I've tested with at least 5 different boards, with minicom, ckermit and even
with a commercial digiport in the path, and in all cases it came up the same.

Paul.

>
> - k
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ