On Sat, 11 Nov 2000, Ivan Kokshaysky wrote:
> On Fri, Nov 10, 2000 at 07:35:41PM +0100, Gerard Roudier wrote:
> > I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
> > still exist bridges that have been designed prior to spec. 1.1.
>
> Yes, DEC 2105x bridges, for
On Fri, Nov 10, 2000 at 07:35:41PM +0100, Gerard Roudier wrote:
> I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
> still exist bridges that have been designed prior to spec. 1.1.
Yes, DEC 2105x bridges, for example.
The only update listed in revision history is "Update
On Fri, 10 Nov 2000, Ivan Kokshaysky wrote:
> On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
> > Hmmm...
> > The PCI spec. says that Limit registers define the top addresses
> > _inclusive_.
>
> Correct.
>
> > The spec. does not seem to imagine that a Limit register lower
On Thu, Nov 09, 2000 at 04:31:24PM -0700, Michal Jaegermann wrote:
> On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
> > > It was posted to lkml, so no link (except if you want to dig through
> > > lkml mail archives).
> >
> > It booted but then it oops'ed before userland I belive.
On Thu, Nov 09, 2000 at 04:31:24PM -0700, Michal Jaegermann wrote:
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
It was posted to lkml, so no link (except if you want to dig through
lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried
On Fri, 10 Nov 2000, Ivan Kokshaysky wrote:
On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.
Correct.
The spec. does not seem to imagine that a Limit register lower than the
On Sat, 11 Nov 2000, Ivan Kokshaysky wrote:
On Fri, Nov 10, 2000 at 07:35:41PM +0100, Gerard Roudier wrote:
I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
still exist bridges that have been designed prior to spec. 1.1.
Yes, DEC 2105x bridges, for example.
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
> > It was posted to lkml, so no link (except if you want to dig through
> > lkml mail archives).
>
> It booted but then it oops'ed before userland I belive. I tried it this
> morning and didn't have much time. It did find the scsi
On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
> Hmmm...
> The PCI spec. says that Limit registers define the top addresses
> _inclusive_.
Correct.
> The spec. does not seem to imagine that a Limit register lower than the
> corresponding Base register will ever exist anywhere,
On Thu, 9 Nov 2000, Ivan Kokshaysky wrote:
Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.
The spec. does not seem to imagine that a Limit register lower than the
corresponding Base register will ever exist anywhere, in my opinion. :-)
This let me think
> It was posted to lkml, so no link (except if you want to dig through
> lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried it this
morning and didn't have much time. It did find the scsi controller (which
is across the bridge) and the drives attached so it
> It was posted to lkml, so no link (except if you want to dig through
> lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried it this
morning and didn't have much time. It did find the scsi controller (which
is across the bridge) and the drives attached so it
On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
> I am still worried that the conditions which generate the following
> message indicate a problem still exists. (this message exists w/out
> your patch..)
> Unknown bridge resource 0: assuming transparent
Well, I believe that
On Wed, Nov 08, 2000 at 03:48:11PM -0800, Richard Henderson wrote:
> Whee! We're back in Bootsville.
Cool!
Meanwhile this base/limit stuff got confirmation :-)
Here is a patch against bridges-2.4.0t11-rth.
Ivan.
--- 2.4.0t11p1/drivers/pci/setup-bus.c Wed Nov 8 19:44:42 2000
+++
On Wed, Nov 08, 2000 at 03:48:11PM -0800, Richard Henderson wrote:
Whee! We're back in Bootsville.
Cool!
Meanwhile this base/limit stuff got confirmation :-)
Here is a patch against bridges-2.4.0t11-rth.
Ivan.
--- 2.4.0t11p1/drivers/pci/setup-bus.c Wed Nov 8 19:44:42 2000
+++
On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
I am still worried that the conditions which generate the following
message indicate a problem still exists. (this message exists w/out
your patch..)
Unknown bridge resource 0: assuming transparent
Well, I believe that transparent
It was posted to lkml, so no link (except if you want to dig through
lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried it this
morning and didn't have much time. It did find the scsi controller (which
is across the bridge) and the drives attached so it does
It was posted to lkml, so no link (except if you want to dig through
lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried it this
morning and didn't have much time. It did find the scsi controller (which
is across the bridge) and the drives attached so it does
On Thu, 9 Nov 2000, Ivan Kokshaysky wrote:
Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.
The spec. does not seem to imagine that a Limit register lower than the
corresponding Base register will ever exist anywhere, in my opinion. :-)
This let me think
On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.
Correct.
The spec. does not seem to imagine that a Limit register lower than the
corresponding Base register will ever exist anywhere, in my
On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
It was posted to lkml, so no link (except if you want to dig through
lkml mail archives).
It booted but then it oops'ed before userland I belive. I tried it this
morning and didn't have much time. It did find the scsi
On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
> FWIW, I just tested rth's update of your path on my x86 SMP box, and a
> laptop with two CardBus bridges (two CardBus slots). Both worked
> fine...
x86 doesn't use this code at all. Only alpha, arm, and mips.
r~
-
To unsubscribe
On Thu, Nov 09, 2000 at 01:03:36AM +0300, Ivan Kokshaysky wrote:
> But actually I'm concerned that all this code doesn't work at all -
> see reports from Michal Jaegermann (the bridge acts as if it drops
> config space transactions randomly).
I have no idea what Michal is seeing. It does,
Ivan Kokshaysky wrote:
> But actually I'm concerned that all this code doesn't work at all -
> see reports from Michal Jaegermann (the bridge acts as if it drops
> config space transactions randomly). I have a lot of suggestions, but
> it's a pain to debug something without access to real
On Wed, Nov 08, 2000 at 09:37:44AM -0800, Richard Henderson wrote:
> Interesting. I hadn't known that. It didn't actually fail with
> the ALI bridge, I just assumed it was a mistake. Can anyone with
> docs on non-DEC bridges confirm that this is a common thing?
It would be better if someone
Hi Jeff-
> Also, should we be setting PCI_CACHE_LINE_SIZE for PCI devices as well
> as bridges?
If/when we do set PCI_CACHE_LINE_SIZE, please don't
set it to a hard-coded, inline constant, like 8 (e.g.),
like some drivers do.
Please use something like (PCI_CACHE_LINE_SIZE / 4)
instead. ["/ 4"
On Wed, Nov 08, 2000 at 02:25:13PM +0300, Ivan Kokshaysky wrote:
> I relied on DEC^WIntel 21153 datasheet which says that to turn off
> io/mem window this bridge must be programmed with base > limit
> values (and the code actually did that).
Interesting. I hadn't known that. It didn't actually
On Wed, Nov 08, 2000 at 10:56:23AM -0500, Jeff Garzik wrote:
> Setting bit 1 in dev->resource[x].start, below, seems incorrect. Should
> you be programming the PCI BAR directly, instead?
No, that's the reason this is a quirk. The hardware is already
only responding to one and only one address.
Setting bit 1 in dev->resource[x].start, below, seems incorrect. Should
you be programming the PCI BAR directly, instead?
> +static void __init
> +quirk_cypress_ide_ports(struct pci_dev *dev)
> +{
> + if (dev->class >> 8 != PCI_CLASS_STORAGE_IDE)
> + return;
> +
On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
> * Replace cropped found_vga detection code.
I wonder where could I lose this, it was in place initially :-)
> + /* ??? How to turn off a bus from responding to, say, I/O at
> +all if there are no I/O ports behind
Hi Richard.
I'm _very_ keen to try this (my Alpha won't boot 2.4 at the mo), however I
think the attachments faery has been playing tricks again.
Do you have a patch relative to 2.4.0-test10?
Sean
On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
> [ For l-k, the issue is
[ For l-k, the issue is that pci-pci bridges and the devices behind
them are not initialized properly. There are a number of Alphas
whose built-in scsi controlers are behind such a bridge preventing
these machines from booting at all. Ivan provided an initial
patch to solve this issue.
[ For l-k, the issue is that pci-pci bridges and the devices behind
them are not initialized properly. There are a number of Alphas
whose built-in scsi controlers are behind such a bridge preventing
these machines from booting at all. Ivan provided an initial
patch to solve this issue.
Hi Richard.
I'm _very_ keen to try this (my Alpha won't boot 2.4 at the mo), however I
think the attachments faery has been playing tricks again.
Do you have a patch relative to 2.4.0-test10?
Sean
On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
[ For l-k, the issue is that
On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
* Replace cropped found_vga detection code.
I wonder where could I lose this, it was in place initially :-)
+ /* ??? How to turn off a bus from responding to, say, I/O at
+all if there are no I/O ports behind
Setting bit 1 in dev-resource[x].start, below, seems incorrect. Should
you be programming the PCI BAR directly, instead?
+static void __init
+quirk_cypress_ide_ports(struct pci_dev *dev)
+{
+ if (dev-class 8 != PCI_CLASS_STORAGE_IDE)
+ return;
+
On Wed, Nov 08, 2000 at 10:56:23AM -0500, Jeff Garzik wrote:
Setting bit 1 in dev-resource[x].start, below, seems incorrect. Should
you be programming the PCI BAR directly, instead?
No, that's the reason this is a quirk. The hardware is already
only responding to one and only one address.
On Wed, Nov 08, 2000 at 02:25:13PM +0300, Ivan Kokshaysky wrote:
I relied on DEC^WIntel 21153 datasheet which says that to turn off
io/mem window this bridge must be programmed with base limit
values (and the code actually did that).
Interesting. I hadn't known that. It didn't actually
Hi Jeff-
Also, should we be setting PCI_CACHE_LINE_SIZE for PCI devices as well
as bridges?
If/when we do set PCI_CACHE_LINE_SIZE, please don't
set it to a hard-coded, inline constant, like 8 (e.g.),
like some drivers do.
Please use something like (PCI_CACHE_LINE_SIZE / 4)
instead. ["/ 4"
On Wed, Nov 08, 2000 at 09:37:44AM -0800, Richard Henderson wrote:
Interesting. I hadn't known that. It didn't actually fail with
the ALI bridge, I just assumed it was a mistake. Can anyone with
docs on non-DEC bridges confirm that this is a common thing?
It would be better if someone who
Ivan Kokshaysky wrote:
But actually I'm concerned that all this code doesn't work at all -
see reports from Michal Jaegermann (the bridge acts as if it drops
config space transactions randomly). I have a lot of suggestions, but
it's a pain to debug something without access to real hardware -
On Thu, Nov 09, 2000 at 01:03:36AM +0300, Ivan Kokshaysky wrote:
But actually I'm concerned that all this code doesn't work at all -
see reports from Michal Jaegermann (the bridge acts as if it drops
config space transactions randomly).
I have no idea what Michal is seeing. It does, however,
On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
FWIW, I just tested rth's update of your path on my x86 SMP box, and a
laptop with two CardBus bridges (two CardBus slots). Both worked
fine...
x86 doesn't use this code at all. Only alpha, arm, and mips.
r~
-
To unsubscribe
43 matches
Mail list logo
