I am still seeing the warning in 2.6.23-rc3, but it makes no difference
if I specify pci=assign-busses ... everything seems fine either way.
Cheers,
Mathis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
I am still seeing the warning in 2.6.23-rc3, but it makes no difference
if I specify pci=assign-busses ... everything seems fine either way.
Cheers,
Mathis
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
gt; not seen a report where this would have been the case so I think we can
> spare the kernel of that check (removes ~300 lines of asm) unless debugging
> is done.
>
> History: The whole check was added in the days before we had the fixup
> for this in Yenta and pci=assign-busses was
) ?
> > + "wholly " : " partially",
> >bus->self->transparent ? " transparent" : " ",
> > - bus->number, bus->subordinate,
&g
(bus->number > child->subordinate &&
> + bus->subordinate < child->number) ?
> + "wholly " : " partially",
> bus-&g
Adrian Bunk wrote:
Alois Nešpor wrote
PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently"
dmesg:
"Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e"
wit
:41:06 dalpdw2 kernel: PCI: Bus #03 (-#06) is hidden behind
transparent bridge #02 (-#03) (try 'pci=assign-busses')
Jul 23 11:41:06 dalpdw2 kernel: Please report the result to <[EMAIL PROTECTED]>
to fix this permanently
Jul 23 11:41:06 dalpdw2 kernel: ACPI: PCI Interrupt Routing Table
[\_SB_
Bernhard?
cu
Adrian
On Mon, Jul 30, 2007 at 10:29:07AM +0200, Alois Nešpor wrote:
> Hello,
>
>
> I view dmesg and find: "PCI: Bus #0b (-#0e) is hidden behind
> transparent bridge #0a (-#0b) (try 'pci=assign-busses')
> Please report the result to linux-kernel
Bernhard?
cu
Adrian
On Mon, Jul 30, 2007 at 10:29:07AM +0200, Alois Nešpor wrote:
Hello,
I view dmesg and find: PCI: Bus #0b (-#0e) is hidden behind
transparent bridge #0a (-#0b) (try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
First, i have
: Bus #03 (-#06) is hidden behind
transparent bridge #02 (-#03) (try 'pci=assign-busses')
Jul 23 11:41:06 dalpdw2 kernel: Please report the result to [EMAIL PROTECTED]
to fix this permanently
Jul 23 11:41:06 dalpdw2 kernel: ACPI: PCI Interrupt Routing Table
[\_SB_.C002._PRT]
Jul 23 11:41:06 dalpdw2
Adrian Bunk wrote:
Alois Nešpor wrote
PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0b) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
dmesg:
Yenta: Raising subordinate bus# of parent bus (#0a) from #0b to #0e
without pci=assign
-transparent ? transparent : ,
-bus-number, bus-subordinate,
-pcibios_assign_all_busses() ? :
- (try 'pci=assign-busses'));
- printk(KERN_WARNING Please report the result
: partially,
bus-self-transparent ? transparent : ,
- bus-number, bus-subordinate,
- pcibios_assign_all_busses() ? :
- (try 'pci=assign-busses'));
- printk(KERN_WARNING
a report where this would have been the case so I think we can
spare the kernel of that check (removes ~300 lines of asm) unless debugging
is done.
History: The whole check was added in the days before we had the fixup
for this in Yenta and pci=assign-busses was the only way to get CardBus
158] PCI: Scanning behind PCI bridge :02:09.0, config
> 00, pass 1
> [0.215184] PCI: Bus #03 (-#06) is hidden behind transparent bridge
> #02 (-#02) (try 'pci=assign-busses')
> [0.215187] Please report the result to linux-kernel to fix this
permanently
> [0.215192]
On Thu, 7 Jun 2007 11:33:12 -0700
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> Andrew, is it okay to debug this with the MM tree? I see this with
> Linus' kernels as well. It's a long-standing issue, but I have always
> just used pci=assign-busses in the past.
>
Andrew, is it okay to debug this with the MM tree? I see this with
Linus' kernels as well. It's a long-standing issue, but I have always
just used pci=assign-busses in the past.
[0.00] Linux version 2.6.22-rc4-mm2 ([EMAIL PROTECTED]) (gcc
version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #14 SMP
Andrew, is it okay to debug this with the MM tree? I see this with
Linus' kernels as well. It's a long-standing issue, but I have always
just used pci=assign-busses in the past.
[0.00] Linux version 2.6.22-rc4-mm2 ([EMAIL PROTECTED]) (gcc
version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #14 SMP
On Thu, 7 Jun 2007 11:33:12 -0700
Miles Lane [EMAIL PROTECTED] wrote:
Andrew, is it okay to debug this with the MM tree? I see this with
Linus' kernels as well. It's a long-standing issue, but I have always
just used pci=assign-busses in the past.
Dunno, but let's not miss an opportunity
On 6/7/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 7 Jun 2007 11:33:12 -0700
Miles Lane [EMAIL PROTECTED] wrote:
Andrew, is it okay to debug this with the MM tree? I see this with
Linus' kernels as well. It's a long-standing issue, but I have always
just used pci=assign-busses
Tjenarvi Tjenarvi wrote:
> When WITHOUT ATA/ATAPi/MFM/RLL support, but I couldn't boot it, I got
> kernel panic. Here is the last 10 lines messages:
>
> VFS : Mounted root (ext2 filesystem)
> No kernel modules found for Linux.2.6.22-rc1
> VFS: Cannot open root device "301" or unknown-block (3,1)
l .config?
> The machine seems nothing wrong whether I used "pci=assign-busses" or
> not. But, I found another message that I don't understand in the dmesg
> whether I use "pci=assign-busses" or not, the message still occur, I
> don't know this is related or n
I used pci=assign-busses or
not. But, I found another message that I don't understand in the dmesg
whether I use pci=assign-busses or not, the message still occur, I
don't know this is related or not. The message is PCI: If a device
doesn't work, try pci=routeirq. If it helps, post a report
Tjenarvi Tjenarvi wrote:
When WITHOUT ATA/ATAPi/MFM/RLL support, but I couldn't boot it, I got
kernel panic. Here is the last 10 lines messages:
VFS : Mounted root (ext2 filesystem)
No kernel modules found for Linux.2.6.22-rc1
VFS: Cannot open root device 301 or unknown-block (3,1)
Please
Linus Torvalds wrote:
>> Someone got this link to patch this bug,
>> http://www.spinics.net/lists/linux-ide/msg04810.html. Then I post
>> another thread in
>> http://www.linuxquestions.org/questions/showthread.php?t=551630
>
> Have you tried it, and does that patch actually fix things for
Linus Torvalds wrote:
Someone got this link to patch this bug,
http://www.spinics.net/lists/linux-ide/msg04810.html. Then I post
another thread in
http://www.linuxquestions.org/questions/showthread.php?t=551630
Have you tried it, and does that patch actually fix things for you?
That
On Tue, 15 May 2007, Tjenarvi Tjenarvi wrote:
>
> "PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try
> 'pci=assign-busses') Please report the result to linux-kernel to fix
> this permanently"
This one is most likely totally harmless, bu
On Tue, 15 May 2007, Tjenarvi Tjenarvi wrote:
PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try
'pci=assign-busses') Please report the result to linux-kernel to fix
this permanently
This one is most likely totally harmless, but you might try to see if that
pci
On Wednesday 09 May 2007, Mihai Donțu wrote:
>On Sunday 01 April 2007 19:18, you wrote:
>> > Hi,
>> >
>> > dmesg told me to report this to LKML.
>>
>> And here is my report.
>>
>> > Have a nice day..
>>
>> x 2 ;)
>
>And again, from a different email address.
>
>I would also like to
On Wednesday 09 May 2007, Mihai Donțu wrote:
On Sunday 01 April 2007 19:18, you wrote:
Hi,
dmesg told me to report this to LKML.
And here is my report.
Have a nice day..
x 2 ;)
And again, from a different email address.
I would also like to take the opportunity to
:26 localhost kernel: [17179570.272000] PCI: Transparent bridge -
> :00:1e.0
> Feb 1 13:10:26 localhost kernel: [17179570.272000] PCI: Bus #0b (-#0e) is
> hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses')
> Feb 1 13:10:26 localhost kernel: [17179570.272000] Please repor
-
:00:1e.0
Feb 1 13:10:26 localhost kernel: [17179570.272000] PCI: Bus #0b (-#0e) is
hidden behind transparent bridge #0a (-#0b) (try 'pci=assign-busses')
Feb 1 13:10:26 localhost kernel: [17179570.272000] Please report the result
to linux-kernel to fix this permanently
Feb 1 13:10:26
Following is the bug report according to the bullets in
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html.
I hope it can help:
[1]PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06
(-#06) (try 'pci=assign-busses')
[2]I do not see an immediate problem with my system
Following is the bug report according to the bullets in
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html.
I hope it can help:
[1]PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06
(-#06) (try 'pci=assign-busses')
[2]I do not see an immediate problem with my system
Hi!
I've had to use the kernel parameter pci=assign-busses to enable a Realtek
ethernet chip.
The chip does not show up in lspci without this kernel option.
Attached are 4 files:
-klog.txt & lspci.txt for the case that pci=assign-busses are enabled
-klog2.txt & lspci2.txt for
Hi!
I've had to use the kernel parameter pci=assign-busses to enable a Realtek
ethernet chip.
The chip does not show up in lspci without this kernel option.
Attached are 4 files:
-klog.txt lspci.txt for the case that pci=assign-busses are enabled
-klog2.txt lspci2.txt for the case
I have an AdvanTech PCM-9381 board and noticed in dmesg that I should add
"pci=assign-busses" and report this to linux-kernel. Knowing nothing about
the underlying problem (and not even sure that there is a problem), I'm
just concur :-)
"lspci -t" show the same output with and
I have an AdvanTech PCM-9381 board and noticed in dmesg that I should add
pci=assign-busses and report this to linux-kernel. Knowing nothing about
the underlying problem (and not even sure that there is a problem), I'm
just concur :-)
lspci -t show the same output with and without pci=assign
38 matches
Mail list logo
