Prev: Financial aid from FDV,Contact Dr.Razaq Immediately.
Next: [GIT PULL] Please pull fix patches sitting in linux-next
From: Robert Hancock on 28 Jun 2010 17:40
On Mon, Jun 28, 2010 at 2:48 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Mon, Jun 28, 2010 at 10:12:53PM +0200, Jiri Slaby wrote:
>> On 06/28/2010 07:14 PM, Matthew Garrett wrote:
>> > http://www-07.ibm.com/hk/products/pos/300/specs.html indicates that
>> > Windows is supported on this hardware. It would be good to verify that
>> > it also fails before we try a model-specific quirk.
>>
>> It would be good for what? I don't see the point, DSDT is broken on that
>> machine and the patch works this around. Why do we need testruns from
>> Windows? And why you think Windows will fail anyway, they can very have
>> the pretty same quirk there.
>
> I can guarantee to you that a generic Windows install does not have a
> quirk for an IBM PoS system released years after that CD was pressed.
> The relevance is that if Windows works without a quirk, then somewhere
> our behaviour diverges from that of Windows and it's likely that other
> machines are also hit by the same issue. Users of those systems may not
> have a support contract with a commercial Linux vendor and may just
> decide to use Windows instead, so there's an incentive for us to
> determine if that's the case and fix Linux's behaviour to match Windows
> rather than to just quirk over it.

Exactly, this seems like a pretty obvious failure, so either IBM's
testing on this machine under Windows was hopelessly inadequate and it
is broken there too, or else Windows is doing something different and
maybe we should be doing the same thing..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 29 Jun 2010 14:50
On 06/28/2010 11:37 PM, Robert Hancock wrote:
> On Mon, Jun 28, 2010 at 2:48 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
>> I can guarantee to you that a generic Windows install does not have a
>> quirk for an IBM PoS system released years after that CD was pressed.

The system in question is very old, any current Windows release is newer
than that.

>> The relevance is that if Windows works without a quirk, then somewhere
>> our behaviour diverges from that of Windows and it's likely that other
>> machines are also hit by the same issue. Users of those systems may not
>> have a support contract with a commercial Linux vendor and may just
>> decide to use Windows instead, so there's an incentive for us to
>> determine if that's the case and fix Linux's behaviour to match Windows
>> rather than to just quirk over it.
>
> Exactly, this seems like a pretty obvious failure, so either IBM's
> testing on this machine under Windows was hopelessly inadequate and it
> is broken there too, or else Windows is doing something different and
> maybe we should be doing the same thing..

The answer I got is "it works there with a driver" whatever it means
(I'm no expert on windows drivers and have no idea what they can do and
what quirks can be implemented that way).

regards,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 29 Jun 2010 19:30
On Tue, Jun 29, 2010 at 12:40 PM, Jiri Slaby <jslaby(a)suse.cz> wrote:
> On 06/28/2010 11:37 PM, Robert Hancock wrote:
>> On Mon, Jun 28, 2010 at 2:48 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
>>> I can guarantee to you that a generic Windows install does not have a
>>> quirk for an IBM PoS system released years after that CD was pressed.
>
> The system in question is very old, any current Windows release is newer
> than that.
>
>>> The relevance is that if Windows works without a quirk, then somewhere
>>> our behaviour diverges from that of Windows and it's likely that other
>>> machines are also hit by the same issue. Users of those systems may not
>>> have a support contract with a commercial Linux vendor and may just
>>> decide to use Windows instead, so there's an incentive for us to
>>> determine if that's the case and fix Linux's behaviour to match Windows
>>> rather than to just quirk over it.
>>
>> Exactly, this seems like a pretty obvious failure, so either IBM's
>> testing on this machine under Windows was hopelessly inadequate and it
>> is broken there too, or else Windows is doing something different and
>> maybe we should be doing the same thing..
>
> The answer I got is "it works there with a driver" whatever it means
> (I'm no expert on windows drivers and have no idea what they can do and
> what quirks can be implemented that way).

What kind of slot is it, and what kind of device was being used,
something designed for this machine or just some random card? Can they
tell what IRQ the device is reportedly using in Windows and if it
matches what Linux reports?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 30 Jun 2010 05:30
On 06/30/2010 01:23 AM, Robert Hancock wrote:
> What kind of slot is it, and what kind of device was being used,
> something designed for this machine or just some random card?

It's a netmos 9835 serial card with 2 ports. PCI, there is no PCIe in
the machine as far as I can see.

> Can they
> tell what IRQ the device is reportedly using in Windows and if it
> matches what Linux reports?

I can ask them. What I know is that with acpi=noirq (or with the quirk)
the IRQ number is 10, with acpi without the quirk, it's 11:

PCI: setting IRQ 2 as level-triggered
serial 0000:00:09.0: found PCI INT A -> IRQ 2
0000:00:09.0: ttyS4 at I/O 0x1898 (irq = 10) is a 16550A
0000:00:09.0: ttyS5 at I/O 0x1890 (irq = 10) is a 16550A

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
serial 0000:00:09.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) ->
IRQ 11
0000:00:09.0: ttyS4 at I/O 0x1898 (irq = 11) is a 16550A
0000:00:09.0: ttyS5 at I/O 0x1890 (irq = 11) is a 16550A

I still no point in comparing this to Windows' setup. We can't find out
whether it is quirked or better (without some bug) handled there.

regards,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 30 Jun 2010 05:50
On 06/30/2010 11:20 AM, Jiri Slaby wrote:
> I still no point in comparing this to Windows' setup. We can't find out
> whether it is quirked or better (without some bug) handled there.

Whatever, how can one find the interrupt links setup on windows?
Something like
ACPI: PCI Interrupt Link [LNKA] (IRQs 5 7 9 10 *11 12)
etc.? Without that it doesn't make much sense.

regards,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Financial aid from FDV,Contact Dr.Razaq Immediately.
Next: [GIT PULL] Please pull fix patches sitting in linux-next