> It might make sense to filter non-shared edge triggered interrupts out
> of irqpoll for that reason. Anything that supports a level triggered
> interrupt should be fine.
That would also break some platforms that use it today 8(. We'd need
another irqpoll mode - at which point being able to forc
Max Staudt writes:
> On 07/29/2016 11:23 AM, One Thousand Gnomes wrote:
>>> Serial consoles are already polled for output. So nothing should
>>> care until userspace starts, and the full serial driver initializes.
>>
>> At which point it hangs
>
> Yep, because the IRQ is never firing. It isn't
On 07/29/2016 11:23 AM, One Thousand Gnomes wrote:
>> Serial consoles are already polled for output. So nothing should
>> care until userspace starts, and the full serial driver initializes.
>
> At which point it hangs
Yep, because the IRQ is never firing. It isn't screaming at all. :)
>> So I
> Serial consoles are already polled for output. So nothing should
> care until userspace starts, and the full serial driver initializes.
At which point it hangs
> So I suspect either "irqfixup" or "irqpoll" would handle this for you.
> If not I am certain a small tweak to some of that code woul
Max Staudt writes:
> On 07/27/2016 03:33 PM, Theodore Ts'o wrote:
>
>> I wonder if it would just be simpler to make it be a CONFIG option
>> which causes the irq value to zero in arch/x86/include/asm/serial.h?
>
> Alan hit the nail on the head in his reply to your email: I can't set the IRQ
> in
On Thu, Jul 28, 2016 at 07:47:04AM -0700, Greg KH wrote:
> > I agree, and I thought about it, but since this is meant for a very limited
> > audience, I think a catch-all is the easiest solution - both in terms of
> > implementation as well as ease of use.
> >
> > It's not meant for general consum
On Thu, Jul 28, 2016 at 11:59:20AM +0200, Max Staudt wrote:
> On 07/27/2016 03:33 PM, Theodore Ts'o wrote:
> > On Wed, Jul 27, 2016 at 02:14:24PM +0200, Max Staudt wrote:
> >>> If you set the IRQ to 0 it should poll anyway (0 means 'no IRQ') so I
> >>> don't think the option is needed. At least it
On 07/27/2016 03:33 PM, Theodore Ts'o wrote:
> On Wed, Jul 27, 2016 at 02:14:24PM +0200, Max Staudt wrote:
>>> If you set the IRQ to 0 it should poll anyway (0 means 'no IRQ') so I
>>> don't think the option is needed. At least it seems sufficient to get me
>>> by when I meet buggy PC BIOSes and th
> I wonder if it would just be simpler to make it be a CONFIG option
> which causes the irq value to zero in arch/x86/include/asm/serial.h?
That assumes x86 and legacy ports.
For modern boxes its data from elsewhere Devicetree folks can just set
up their devicetree that way, the ACPI afflicted ca
On Wed, Jul 27, 2016 at 02:14:24PM +0200, Max Staudt wrote:
> > If you set the IRQ to 0 it should poll anyway (0 means 'no IRQ') so I
> > don't think the option is needed. At least it seems sufficient to get me
> > by when I meet buggy PC BIOSes and the like
>
> That's exactly what the patch does
On 07/27/2016 02:09 PM, One Thousand Gnomes wrote:
>> I simply thought this patch may be useful for other people as well, that's
>> why I sent it upstream.
>
> If you set the IRQ to 0 it should poll anyway (0 means 'no IRQ') so I
> don't think the option is needed. At least it seems sufficient to
> I simply thought this patch may be useful for other people as well, that's
> why I sent it upstream.
If you set the IRQ to 0 it should poll anyway (0 means 'no IRQ') so I
don't think the option is needed. At least it seems sufficient to get me
by when I meet buggy PC BIOSes and the like
Alan
On 07/26/2016 05:08 PM, Greg KH wrote:
> On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote:
>> On 07/25/2016 07:47 PM, Greg KH wrote:
>>> Ick, don't add new module parameters if at all possible.
>>
>> I agree, I'd rather not add a parameter either, but...
>>
>> - It's a hardware issue
>> -
On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote:
> On 07/25/2016 07:47 PM, Greg KH wrote:
> > On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote:
> >> Some serial ports may not emit IRQs properly, or there may be a defect
> >> in their routing on the motherboard.
> >>
> >> This p
On 07/25/2016 07:47 PM, Greg KH wrote:
> On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote:
>> Some serial ports may not emit IRQs properly, or there may be a defect
>> in their routing on the motherboard.
>>
>> This patch allows these ports to be used anyway (or until a better
>> workarou
Hi,
[auto build test ERROR on tty/tty-testing]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Max-Staudt/8250-option-force_polling-for-buggy-IRQs/20160726-013812
base: https://git.kernel.org/p
On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote:
> Some serial ports may not emit IRQs properly, or there may be a defect
> in their routing on the motherboard.
>
> This patch allows these ports to be used anyway (or until a better
> workaround is known for a specific platform), though
Some serial ports may not emit IRQs properly, or there may be a defect
in their routing on the motherboard.
This patch allows these ports to be used anyway (or until a better
workaround is known for a specific platform), though with no guarantees.
If you have such a buggy UART, boot Linux with 82
18 matches
Mail list logo
