Re: no DRQ after issuing MULTWRITE_EXT AND PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses')

Re: no DRQ after issuing MULTWRITE_EXT AND PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses')

[Tejun Heo]

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 append a correct "root=" boot option; here are the available
> partitions:
> 0800   117220824   sda1
>   0801     34178256   sda2
>   0802                   1   sda3
>   0803      43720897  sda5
>   0806      39062016  sda6
> 0b00       1048575   sr0   driver : sr
> kernel panic - not syncing : VFS : Unable to mount root fs on
> unknown-block(3,1)
> 
> 1. My .config with ATA/ATAPi/MFM/RLL support in
> http://www.mydatabus.com/public/Tje/config
> 2. My .config WITHOUT ATA/ATAPi/MFM/RLL support in
> http://www.mydatabus.com/public/Tje/config2
> 
> Why I got kernel panic, it is should work only libata drivers. Thx. 

Because your harddrive changed from /dev/hda to /dev/sda.  You need to
update the root= kernel parameter.

-- 
tejun

Re: no DRQ after issuing MULTWRITE_EXT AND PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses')

[Tejun Heo]

Tjenarvi Tjenarvi wrote:
> These dmesg if not as Tejun said, Which he said should only libata
> drivers used to get more information.  Frankly, I don't know which one I
> have to take off in kernel configuration to comply this.  I guess the
> libata is in:
> 
> Device Drivers  --->
>  SCSI device support  --->
> 
> But,  don't know which one to take off, so that only libata driver
> compiled. Please tell me.

Please turn off Device Drivers -> ATA/ATAPi/MFM/RLL support.  I'm not
sure which ide driver is grabbing the first port.  Can you post the
original .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 not.  The message is "PCI: If a device
> doesn't work, try "pci=routeirq".  If it helps, post a report".  Should
> I try this kernel option?

I don't think you need to pay attention to the message.

-- 
tejun

Re: no DRQ after issuing MULTWRITE_EXT AND PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses')

[Linus Torvalds]

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=assign-busses" makes any difference. Do a "lspci" with and without 
that, and send them to me and the kernel mailing list.

But I assume that everything still *works*? The thing about a transparent 
bridge is that it doesn't act as a normal PCI bridge - it just passes 
everything through, so anything that is "hidden" behind one really is 
quite visible, even if the setup of the bridging registers is odd.

So the reason for that report is most likely just that the BIOS set up the 
bridge bus numbers in a really odd (and technically incorrect) way - but 
it probably all still works perfectly fine. You can see all the devices in 
the machine, right?

We migth have to just change the error message - the case is interesting, 
but the "to fix this permanently" part is misleading. There's probably 
nothing to fix (except for a firmware update, and I doubt the BIOS will 
really be fixed either - BIOS vendors wouldn't care, as long as things 
work).

> I just a few days ago found this bug. In, 
> http://lkml.org/lkml/2007/2/28/297 got the same problem, and tells that 
> had to pass combined_mode=libata as kernel option, otherwise DMA does 
> not work and the hard disk is terribly slow.  My DMA also can't work 
> properly on my /dev/hda and my /dev/cdrom,furthermore, now, my dmesg is 
> full of these messages:
> 
> hda: status timeout: status=0xd0 { Busy }
> ide: failed opcode was: unknown
> hda: no DRQ after issuing MULTWRITE_EXT
> ide0: reset: success
> 
> My opinion is that PCI bus bug and DMA problem and then the 
> MULTWRITE_EXT error might be somehow related

I suspect they are unrelated, although they certainly *could* be related 
(where "related" is possibly something indirect like "the firmware set up 
something _else_ strangely too").

> I have tried Slackware default kernel 2.4.33.3, and the dmesg is a little different with 2.6.x.
> 
> hda: no DRQ after issuing WRITE

Ok, so the exact same thing basically happens with a 2.4.x kernel, the 
message is just different. So this is not a new issue, it's really 
somethgn about your machine.

> 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 patch has not been merged, possibly because it got forgotten, but 
possibly because it had other problems. So if you can test it and send the 
results back to Tejun and Jeff (both Cc'd), please do.

		Linus

Re: no DRQ after issuing MULTWRITE_EXT AND PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses')

[Tejun Heo]

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 patch has not been merged, possibly because it got forgotten, but 
> possibly because it had other problems. So if you can test it and send the 
> results back to Tejun and Jeff (both Cc'd), please do.

Those patch actually is merged.  It just looks different because the
table got merged back into ich6m table after finding out ich6m has the
same issue.  Also, the patch deals only with detection.

Can you boot 2.6.21.1 with only libata drivers compiled in and report
the dmesg?  libata usually dumps more info than ide drivers so it's
easier to find out what's going on.

-- 
tejun