On Wed, 3 Sep 2008, Andrew Morton wrote:
> On Wed, 3 Sep 2008 22:21:54 -0700 (PDT) Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Can you apply this patch, just to see if it fixes things.
>
> Below..
>
> > And do you know when this started happening? It shouldn't have been all
> > that recent. Maybe you haven't tried your Vaio in a while?
>
> Yes, the Vaio had a vacation in New York. Last kernel it booted was
> 2.6.26-rc8-mm1.
>
> --- x 2008-09-03 21:38:24.000000000 -0700
> +++ y 2008-09-03 22:29:04.000000000 -0700
> ...
> @@ -503,15 +503,15 @@
> calling init_acpi_pm_clocksource+0x0/0x14a
> initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> calling pcibios_assign_resources+0x0/0x70
> -pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
Ok, it fixed that particular thing, and now the mem windows look fine:
> pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> pci 0000:06:05.0: IO window: 0x002400-0x0024ff
> pci 0000:06:05.0: IO window: 0x002800-0x0028ff
> -pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
> +pci 0000:06:05.0: PREFETCH window: 0x50000000-0x53ffffff
> +pci 0000:06:05.0: MEM window: 0x58000000-0x5bffffff
so it fixed _one_ issue.
This also then changes the parent bus bridge:
> pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
> pci 0000:00:1e.0: IO window: 0x2000-0x2fff
> pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
> -pci 0000:00:1e.0: PREFETCH window: disabled
> +pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x00000053ffffff
ie it has now allocated a prefetch window in the parent PCI bridge too
in order to fit that cardbus bridge in.
So this all looks ok. I'd be happier if you also actually had some actual
_device_ in the Cardbus slot and reported that that works, but the patch
clearly
- fixes a very bogus alignment calculation
- actually fixes a Cardbus setup issue for you.
so I'll commit it.
> also...
>
> calling yenta_socket_init+0x0/0x16
> yenta_cardbus 0000:06:05.0: CardBus bridge found [104d:818f]
> -yenta_cardbus 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> -yenta_cardbus 0000:06:05.0: IO window: 0x002400-0x0024ff
> -yenta_cardbus 0000:06:05.0: IO window: 0x002800-0x0028ff
> -yenta_cardbus 0000:06:05.0: PREFETCH window: 0x50400000-0x507fffff
> -yenta_cardbus 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
these went away, because yenta_allocate_resources() will not try to
reprogram the controller if it's already been fully set up. So because
yenta_alloc_resources() is happy with the resource setup and leaves it
alone, there's no more noise about it.
So I would say that the PCI resource issue is fixed.
[ Side note: I actually suspect that your cardbus slot actually worked
fine _despite_ the problems, because
(a) the whole yenta_allocate_resources() -> pci_setup_cardbus() sequence
did end up setting things up correctly int he end, even if the
prefetchable memory resource ended up being in a non-prefetchable
area
(b) Very few cardbus cards would have any prefetchable resources, much
less care about the theoretical performance difference even if they
did.
but that allocation issue was still a bug ]
And you seem to have found your non-console problem separately.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
