RE: SIS 962 chipset, problems ...
> Good year everybody > > Luigi, I converted your patch to CURRENT, there were only > minor changes to do and it seems to work ! > > sis0: port 0x2000-0x20ff mem > 0xec005000-0xec005fff irq 1$ > at device 4.0 on pci0 > sis0: Ethernet address: 00:00:e2:94:66:99 > miibus0: on sis0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > http://people.freebsd.org/~mbr/patches/ifsis-luigi.diff > > and added the Linux way of reading the eeprom. I guess > we should make this the default for accessing the eeprom (for > this chipset), > since it is not only the mac address which gets read. > > Luigi: Or isn't this neccessary ? > > http://people.freebsd.org/~mbr/patches/ifsis-mbr.diff > > Martin > Yes, I think it is neccesary, but all my machines have 0x90 revisions. I've discovered another issue with the integrated device, the dma burst size should be limited to 64 bytes. This is in the Linux driver, search for EDB_MASTER_EN, if this bit is set in config register, dma burst size can be no larger than 64, otherwise data errors would sometimes appear at 64 byte data boundaries. There's also a bug exists in almost all Bill's network drivers: when reading PHY regs over the i2c bus, the turnaround ACK bit is read one clock edge too late. This bit is driven low by slave (as any other input data bits from slave) when the clock is LOW. The current code reads the bit after the clock is driven high again. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: SIS 962 chipset, problems ...
Good year everybody Luigi, I converted your patch to CURRENT, there were only minor changes to do and it seems to work ! sis0: port 0x2000-0x20ff mem 0xec005000-0xec005fff irq 1$ at device 4.0 on pci0 sis0: Ethernet address: 00:00:e2:94:66:99 miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto http://people.freebsd.org/~mbr/patches/ifsis-luigi.diff and added the Linux way of reading the eeprom. I guess we should make this the default for accessing the eeprom (for this chipset), since it is not only the mac address which gets read. Luigi: Or isn't this neccessary ? http://people.freebsd.org/~mbr/patches/ifsis-mbr.diff Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: SIS 962 chipset, problems ...
> Hi, > > > > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff > > > Dec 23 15:17:03 kernel: sis0: MII without any PHY! > > > Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach > returned 6 > > > Dec 23 15:17:03 kernel: sis0: port > 0x2000-0x20ff mem > > > 0xec005000-0xec005fff irq 11 at device 4.0 on pci0 > > > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff > > > Dec 23 15:17:03 kernel: sis0: MII without any PHY! > > The linux driver tells me : > > /** > * sis96x_get_mac_addr: - Get MAC address for SiS962 or SiS963 model > * @pci_dev: the sis900 pci device > * @net_dev: the net device to get address for > * > * SiS962 or SiS963 model, use EEPROM to store MAC address. > And EEPROM > * is shared by > * LAN and 1394. When access EEPROM, send EEREQ signal to > hardware first > * and wait for EEGNT. If EEGNT is ON, EEPROM is permitted > to be access > * by LAN, otherwise is not. After MAC address is read from > EEPROM, send > * EEDONE signal to refuse EEPROM access by LAN. > * The EEPROM map of SiS962 or SiS963 is different to SiS900. > * The signature field in SiS962 or SiS963 spec is meaningless. > * MAC address is read into @net_dev->dev_addr. > */ > > So we definitly are missing the support for the SiS 962/963 southbridge. > > Martin > This is just one part of the problem. The other half is PHY couldn't be detected. It seems that sis no longer implementes the enhanced phy control register, and phy has to be directly accessed via mdio. I have a patch (-stable only) for this problem, http://www.freebsd.org/~luoqi/sis.diff . I've also notice some other quirks of the chip our driver should be dealing with. Among them, the multicast address filter and DMA burst size. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SIS 962 chipset, problems ...
Hi Soeren, > This does not work correctly, your ATA timings are way out of wack > since botht ATA100 and ATA133 SiS chips uses different register > layouts... I know. This is just a workaround. At least my box does not hang during boot and ATA100 seems to work. No crash since then. Do you have a more correct fix for the ATA133 chipset in work, or already ready so I could test it ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SIS 962 chipset, problems ...
It seems Martin Blapp wrote: > --- sys/dev/ata/ata-dma.c.origMon Dec 23 14:44:39 2002 > +++ sys/dev/ata/ata-dma.c Mon Dec 23 15:49:20 2002 > @@ -632,7 +632,9 @@ > ata_find_dev(parent, 0x06351039, 0) || /* SiS 635 */ > ata_find_dev(parent, 0x06401039, 0) || /* SiS 640 */ > ata_find_dev(parent, 0x06451039, 0) || /* SiS 645 */ > + ata_find_dev(parent, 0x06461039, 0) || /* SiS 646 */ > ata_find_dev(parent, 0x06501039, 0) || /* SiS 650 */ > + ata_find_dev(parent, 0x06511039, 0) || /* SiS 651 */ > ata_find_dev(parent, 0x07301039, 0) || /* SiS 730 */ > ata_find_dev(parent, 0x07331039, 0) || /* SiS 733 */ > ata_find_dev(parent, 0x07351039, 0) || /* SiS 735 */ > --- sys/dev/ata/ata-pci.c.origMon Dec 23 16:40:04 2002 > +++ sys/dev/ata/ata-pci.c Mon Dec 23 16:39:27 2002 > @@ -188,7 +188,9 @@ > ata_find_dev(dev, 0x06351039, 0) || > ata_find_dev(dev, 0x06401039, 0) || > ata_find_dev(dev, 0x06451039, 0) || > + ata_find_dev(dev, 0x06461039, 0) || > ata_find_dev(dev, 0x06501039, 0) || > + ata_find_dev(dev, 0x06511039, 0) || > ata_find_dev(dev, 0x07301039, 0) || > ata_find_dev(dev, 0x07331039, 0) || > ata_find_dev(dev, 0x07351039, 0) || This does not work correctly, your ATA timings are way out of wack since botht ATA100 and ATA133 SiS chips uses different register layouts... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SIS 962 chipset, problems ...
Hi, > > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff > > Dec 23 15:17:03 kernel: sis0: MII without any PHY! > > Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach returned 6 > > Dec 23 15:17:03 kernel: sis0: port 0x2000-0x20ff mem > > 0xec005000-0xec005fff irq 11 at device 4.0 on pci0 > > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff > > Dec 23 15:17:03 kernel: sis0: MII without any PHY! The linux driver tells me : /** * sis96x_get_mac_addr: - Get MAC address for SiS962 or SiS963 model * @pci_dev: the sis900 pci device * @net_dev: the net device to get address for * * SiS962 or SiS963 model, use EEPROM to store MAC address. And EEPROM * is shared by * LAN and 1394. When access EEPROM, send EEREQ signal to hardware first * and wait for EEGNT. If EEGNT is ON, EEPROM is permitted to be access * by LAN, otherwise is not. After MAC address is read from EEPROM, send * EEDONE signal to refuse EEPROM access by LAN. * The EEPROM map of SiS962 or SiS963 is different to SiS900. * The signature field in SiS962 or SiS963 spec is meaningless. * MAC address is read into @net_dev->dev_addr. */ So we definitly are missing the support for the SiS 962/963 southbridge. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SIS 962 chipset, problems ...
On Mon, Dec 23, 2002 at 04:22:22PM +0100, Martin Blapp wrote the words in effect of: > > Hi all, > > I'm trying to get my laptop running, with some success, but the > network card is not very friendly to me. > > none3@pci0:4:0: class=0x02 card=0x105517c0 chip=0x09001039 rev=0x91 hdr=0x00 > vendor = 'Silicon Integrated Systems (SiS)' > device = 'SiS900 Fast Ethernet/Home Networking Ctrlr' > class= network > subclass = ethernet > > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff > Dec 23 15:17:03 kernel: sis0: MII without any PHY! > Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach returned 6 > Dec 23 15:17:03 kernel: sis0: port 0x2000-0x20ff mem > 0xec005000-0xec005fff irq 11 at device 4.0 on pci0 > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff > Dec 23 15:17:03 kernel: sis0: MII without any PHY! > > I thought first that this is a similar problem to the one where > the physical is at id 1, not 0. But it still doesn't work. IIRC, this is the same problem, that was posted on -hackers -- something to do with the Card not reading the MAC address from the EEPROM. I may be wrong. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SIS 962 chipset, problems ...
Hi all,
I'm trying to get my laptop running, with some success, but the
network card is not very friendly to me.
none3@pci0:4:0: class=0x02 card=0x105517c0 chip=0x09001039 rev=0x91 hdr=0x00
vendor = 'Silicon Integrated Systems (SiS)'
device = 'SiS900 Fast Ethernet/Home Networking Ctrlr'
class= network
subclass = ethernet
Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff
Dec 23 15:17:03 kernel: sis0: MII without any PHY!
Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach returned 6
Dec 23 15:17:03 kernel: sis0: port 0x2000-0x20ff mem
0xec005000-0xec005fff irq 11 at device 4.0 on pci0
Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff
Dec 23 15:17:03 kernel: sis0: MII without any PHY!
I thought first that this is a similar problem to the one where
the physical is at id 1, not 0. But it still doesn't work.
http://www.freebsd.org/cgi/query-pr.cgi?pr=30836
Then I tried another tip from google:
http://www.geocrawler.com/archives/3/152/2002/6/0/9065467/
No way ... I'll try some other tricks now ...
Other things I got running, like the ATA UDMA support. It seems
that many new chipsets are unsupported in FreeBSD ...
--- sys/pci/agp_sis.c.orig Mon Dec 23 14:34:30 2002
+++ sys/pci/agp_sis.c Mon Dec 23 14:34:32 2002
@@ -66,6 +66,8 @@
switch (pci_get_devid(dev)) {
case 0x00011039:
return ("SiS 5591 host to AGP bridge");
+ case 0x06461039:
+ return ("SiS 645DX host to AGP bridge");
};
if (pci_get_vendor(dev) == 0x1039)
--- sys/dev/ata/ata-dma.c.orig Mon Dec 23 14:44:39 2002
+++ sys/dev/ata/ata-dma.c Mon Dec 23 15:49:20 2002
@@ -632,7 +632,9 @@
ata_find_dev(parent, 0x06351039, 0) || /* SiS 635 */
ata_find_dev(parent, 0x06401039, 0) || /* SiS 640 */
ata_find_dev(parent, 0x06451039, 0) || /* SiS 645 */
+ ata_find_dev(parent, 0x06461039, 0) || /* SiS 646 */
ata_find_dev(parent, 0x06501039, 0) || /* SiS 650 */
+ ata_find_dev(parent, 0x06511039, 0) || /* SiS 651 */
ata_find_dev(parent, 0x07301039, 0) || /* SiS 730 */
ata_find_dev(parent, 0x07331039, 0) || /* SiS 733 */
ata_find_dev(parent, 0x07351039, 0) || /* SiS 735 */
--- sys/dev/ata/ata-pci.c.orig Mon Dec 23 16:40:04 2002
+++ sys/dev/ata/ata-pci.c Mon Dec 23 16:39:27 2002
@@ -188,7 +188,9 @@
ata_find_dev(dev, 0x06351039, 0) ||
ata_find_dev(dev, 0x06401039, 0) ||
ata_find_dev(dev, 0x06451039, 0) ||
+ ata_find_dev(dev, 0x06461039, 0) ||
ata_find_dev(dev, 0x06501039, 0) ||
+ ata_find_dev(dev, 0x06511039, 0) ||
ata_find_dev(dev, 0x07301039, 0) ||
ata_find_dev(dev, 0x07331039, 0) ||
ata_find_dev(dev, 0x07351039, 0) ||
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
