Prev: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
Next: find_exported_dentry: npd != pd -> stale NFS file handle
From: Manu Abraham on 7 Feb 2007 00:30
On 2/7/07, Luming Yu <luming.yu(a)gmail.com> wrote:
> > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> > vendor information, that's all
>
> Ok, sounds like windows driver can fix the broken EEPROM on you card.
> Otherwise, I can not explain how windows driver can fix the problem for linux.


I have the windows driver sources for the device, it does _not_ write
anything to the EEPROM under any circumstance.

moreover the EEPROM is write protected in hardware by a jumper. So no
application can write to it, AFAICS

> Anyway, this issue is NOT linux problem. right?
>

I am not very sure about that.

really i am thinking this way .. On booting up windows, it could have
changed some BIOS stuff (written something to NVRAM or something like
that ?).. that's the only possibility that i can see here.

really lost on this one.

regards,
manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Grant Grundler on 7 Feb 2007 02:00
On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> >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.

Ok - thanks for the dmesg output and log. I suspect you've already
tried cycling power on the machine (If not, please do).
I have no idea what M$ XP was doing that might "fix" the problem.

I was just suspicious of our byte accesses to the same dword.
To answer you previous question, it's possible that M$ only
uses dword accesses. I don't know.

> inlined the log

excellent - sounds like you are making forward progress even
if we can not reproduce the problem...worst case other users
(or customers) have a "work around" :^/

thanks,
grant

ps. I'll be unavailable until this weekend when I want to look at
the old and new logs a bit more.

>
> 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)...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Manu Abraham on 8 Feb 2007 00:30
On 2/7/07, Grant Grundler <grundler(a)parisc-linux.org> wrote:
> On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> > >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.
>
> Ok - thanks for the dmesg output and log. I suspect you've already
> tried cycling power on the machine (If not, please do).

I did power cycling on the machine .. did try pulling out the power
cord out for a while as well, to check whether it is some "fix that
just evaporated"


> I have no idea what M$ XP was doing that might "fix" the problem.
>
> I was just suspicious of our byte accesses to the same dword.
> To answer you previous question, it's possible that M$ only
> uses dword accesses. I don't know.
>


someone who has access to NT HAL inside ideas (maybe a too far deam) ,
could probably explain ?


> > inlined the log
>
> excellent - sounds like you are making forward progress even
> if we can not reproduce the problem...worst case other users
> (or customers) have a "work around" :^/

Sounds like a horrible workaround . :-)

I am thinking more in the direction of something wrong in the BIOS, as
that is the only dark area, where i can't see/understand anything.


regards,
manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Manu Abraham on 8 Feb 2007 00:50
On 2/7/07, Grant Grundler <grundler(a)parisc-linux.org> wrote:
> On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> > >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.
>
> Ok - thanks for the dmesg output and log. I suspect you've already
> tried cycling power on the machine (If not, please do).
> I have no idea what M$ XP was doing that might "fix" the problem.
>
> I was just suspicious of our byte accesses to the same dword.
> To answer you previous question, it's possible that M$ only
> uses dword accesses. I don't know.

Does it sound too weird, if our PCI accesses could accidentally
overwrite EEPROM contents on cards that have the EEPROM, R/W ?

we came across with lot of issues on the same unfortunately under
Linux only this issues comes up, we used to sling mud at each other,
probably for bad I2C communications on a BT878 based chip.

Recently, somebody came across a strange case where, booting into
Windows , fixed his EEPROM contents. Since i have the driver sources
for the described card from the vendor for windows, i don't see how
any way in which the Windows driver does rewriting the EEPROM.

http://thread.gmane.org/gmane.linux.drivers.dvb/23911/focus=31185

Does this have any relation to the current situation ?

regards,
manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
Next: find_exported_dentry: npd != pd -> stale NFS file handle