LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Manu Abraham" <abraham.manu@gmail.com>
To: "Grant Grundler" <grundler@parisc-linux.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
greg@kroah.com
Subject: Re: 2.6.20 PCI Cannot allocate resource region 2
Date: Tue, 6 Feb 2007 15:52:47 +0400 [thread overview]
Message-ID: <1a297b360702060352y3faa0f46i7c4a01499fae2eff@mail.gmail.com> (raw)
In-Reply-To: <1a297b360702060313n34a8f941oebf9f373630b070f@mail.gmail.com>
On 2/6/07, Manu Abraham <abraham.manu@gmail.com> wrote:
> On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
> > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@parisc-linux.org> wrote:
> > >
> > > > On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
> > > > ...
> > > > > > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> > > > > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+
> > > > > > Latency: 0, Cache Line Size 0c
> > > > > > BIST is running
> > > > >
> > > > > BIST is required to complete in 2 seconds. Either with success or failure.
> > > > > I expect BIOS to have complained before launching grub/lilo.
> > > >
> > > > Gregkh,
> > > > I just realized linux-pci bus scan should ignore devices (print a warning)
> > > > which have BIST set. Want a patch for this?
> > > >
> > > > Slight risk some previously "working" device which violates the
> > > > spec might get ignored...but I hope there aren't too many of those.
> > >
> > > Should we wait two seconds before declaring the device dead?
> > > To see whether it will come back?
> >
> > Hrm...my thought was BIOS should already be doing that...but I just
> > realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> > "BIST is running". I think the fact that BIST is not "running" in the
> > 2.6.20-rc7 lspci output is just coincidental. The config space for that
> > device is full of similar garbage in both cases regardless how long
> > it took.
> >
> > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> > register and BIOS is not being careful to clear or disable the other
> > bytes in that same 32-bit word?
> >
> > PCI is by nature a 32-bit wide config space and "byte enables"
> > are used to mask off bytes we want to ignore. If the chipset
> > or BIOS config access routines aren't careful, they could accidentally
> > modify other values in the same 32-bit word when only one byte was
> > intended to be changed.
> >
> > The code in pci_set_cacheline_size() uses byte enables but is only
> > called by pci_set_mwi(). 82 different .c files (124 instances) access
> > PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls.
> > But I really only care about the calls what would apply get invoked
> > for 1822:4e35. My guess is this one always gets invoked:
> > ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> >
> > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> > (http://pci-ids.ucw.cz/iii/?i=1822)
> > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
> >
> > Manu, can you add code to pci_enable_bridges() to dump information about
> > which bridges are getting enabled _before_ pci_set_master() is called?
> >
> > I'm interested in a hex dump of the first 8 32-bit words of
> > PCI config space for each device.
> >
>
> attaching a dump of the regs (on 2.6.17.7) as well as the diff
>
The device now works, used the demodulator driver alongwith the bridge driver.
inlined the log
regards,
manu
[17181623.040000] gpif status: 6000 irqcfg: 0000
[17181623.040000] irq: 18, latency: 64
[17181623.040000] memory: 0xefeff000, mmio: 0xe18f4000
[17181623.040000] found a UNKNOWN PCI UNKNOWN device on (02:0a.0),
[17181623.040000] Mantis Rev 1 [1822:0031], irq: 18, latency: 64
[17181623.040000] memory: 0xefeff000, mmio: 0xe18f4000
[17181623.040000] mantis_i2c_write: Address=[0x50] <W>[ 08 ]
[17181623.040000] mantis_i2c_read: Address=[0x50] <R>[ 00 00
00 00 00 00 ]
[17181623.044000] MAC Address=[00:00:00:00:00:00]
[17181623.044000] mantis_alloc_buffers (0): DMA=0x186b0000
cpu=0xd86b0000 size=65536
[17181623.044000] mantis_alloc_buffers (0): RISC=0x1c3af000
cpu=0xdc3af000 size=1000
[17181623.044000] DVB: registering new adapter (Mantis dvb adapter).
[17181623.564000] mantis_frontend_init (0): Probing for STB0899
(DVB-S/DSS/DVB-S2)
[17181623.564000] stb0899_write_regs [0xf1b6]: 02
[17181623.564000] mantis_i2c_write: Address=[0x68] <W>[ f1 b6 02 ]
[17181623.564000] stb0899_write_regs [0xf1c2]: 00
[17181623.564000] mantis_i2c_write: Address=[0x68] <W>[ f1 c2 00 ]
[17181623.568000] stb0899_write_regs [0xf1c3]: 00
[17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f1 c3 00 ]
[17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f0 00 ]
[17181623.568000] mantis_i2c_read: Address=[0x68] <R>[ 82 ]
[17181623.568000] stb0899_read_reg: Reg=[0xf000], data=82
[17181623.568000] stb0899_get_dev_id: Device ID=[8], Release=[2]
[17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f3 fc
00 04 00 00 ]
[17181623.572000] mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
[17181623.572000] mantis_i2c_read: Address=[0x68] <R>[ 31 44 4d 44 ]
[17181623.572000] mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
[17181623.572000] mantis_i2c_read: Address=[0x68] <R>[ 31 44 4d 44 ]
[17181623.576000] stb0899_read_s2reg Device=[0xf3fc], Base
address=[0x00000400], Offset=[0xf334], Data=[0x444d4431]
[17181623.576000] mantis_i2c_write: Address=[0x68] <W>[ f3 fc
00 04 00 00 ]
[17181623.576000] mantis_i2c_write: Address=[0x68] <W>[ f3 00 ]
[17181623.576000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.580000] mantis_i2c_write: Address=[0x68] <W>[ f3 3c ]
[17181623.580000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.580000] stb0899_read_s2reg Device=[0xf3fc], Base
address=[0x00000400], Offset=[0xf33c], Data=[0x00000001]
[17181623.580000] stb0899_get_dev_id: Demodulator Core ID=[DMD1], Version=[1]
[17181623.580000] mantis_i2c_write: Address=[0x68] <W>[ fa fc
00 08 00 00 ]
[17181623.584000] mantis_i2c_write: Address=[0x68] <W>[ fa 00 ]
[17181623.584000] mantis_i2c_read: Address=[0x68] <R>[ 4c 00 00 00 ]
[17181623.588000] mantis_i2c_write: Address=[0x68] <W>[ fa 2c ]
[17181623.588000] mantis_i2c_read: Address=[0x68] <R>[ 31 43 45 46 ]
[17181623.588000] stb0899_read_s2reg Device=[0xfafc], Base
address=[0x00000800], Offset=[0xfa2c], Data=[0x46454331]
[17181623.588000] mantis_i2c_write: Address=[0x68] <W>[ fa fc
00 08 00 00 ]
[17181623.592000] mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
[17181623.592000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.592000] mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
[17181623.592000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.596000] stb0899_read_s2reg Device=[0xfafc], Base
address=[0x00000800], Offset=[0xfa34], Data=[0x00000001]
[17181623.596000] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1]
[17181623.596000] stb0899_attach: Attaching STB0899
[17181623.596000] mantis_frontend_init (0): found STB0899
DVB-S/DSS/DVB-S2 frontend @0x68
[17181623.596000] mantis_frontend_init (0): Probing for STB6100 tuner
[17181623.596000] stb6100_attach: Attaching
[17181623.596000] mantis_frontend_init (0): found STB6100 tuner @0x60
[17181623.596000] mantis_frontend_init (0): Probing for LNBP21 SEC
[17181623.596000] mantis_i2c_write: Address=[0x08] <W>[ 40 ]
[17181623.596000] DVB: registering frontend 0 (STB0899 Multistandard)...
next prev parent reply other threads:[~2007-02-06 11:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-05 1:09 Manu Abraham
2007-02-05 3:04 ` Luming Yu
2007-02-05 4:16 ` H. Peter Anvin
2007-02-05 17:20 ` Manu Abraham
2007-02-06 4:55 ` Grant Grundler
2007-02-06 5:03 ` Grant Grundler
2007-02-06 5:33 ` Andrew Morton
2007-02-06 6:28 ` Manu Abraham
2007-02-06 7:04 ` Grant Grundler
2007-02-06 7:13 ` Manu Abraham
2007-02-06 8:46 ` Grant Grundler
2007-02-06 9:06 ` Manu Abraham
2007-02-06 9:29 ` Manu Abraham
2007-02-06 12:21 ` Luming Yu
2007-02-06 12:24 ` Manu Abraham
2007-02-06 12:56 ` Manu Abraham
2007-02-06 12:56 ` Manu Abraham
2007-02-07 4:19 ` Luming Yu
2007-02-07 5:25 ` Manu Abraham
2007-02-06 11:13 ` Manu Abraham
2007-02-06 11:52 ` Manu Abraham [this message]
2007-02-07 6:58 ` Grant Grundler
2007-02-08 5:26 ` Manu Abraham
2007-02-08 5:46 ` Manu Abraham
2007-02-06 6:24 ` Greg KH
2007-02-06 5:20 ` Manu Abraham
2007-02-06 8:25 ` Grant Grundler
2007-02-06 8:48 ` Manu Abraham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a297b360702060352y3faa0f46i7c4a01499fae2eff@mail.gmail.com \
--to=abraham.manu@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=grundler@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--subject='Re: 2.6.20 PCI Cannot allocate resource region 2' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).