PROCESSOR SPECIFIC CLOCK GENERATOR, 80MHZ, CMOS, PDSO28

still nothing

Christian Holzapfel wrote:
> Wolfgang Gehl schrieb am Mittwoch, 6. Dezember 2023 um 23:48:51 UTC+1:
>> My guess is a timing problem in the PCI-to-MCA bridge. May I ask you for
>> another test run? The PC 750 supports a PCI bus clock of 50MHz. I could
>> imagine that the MCA bus would cope much better with this than with the
>> 66MHz bus clock.
>
> With a 50 MHz base clock instead of 66, the adapter tops out at ~6700 k/sec:
>
> NETIO - Network Throughput Benchmark, Version 1.7
> (C) 1997-1999 Kai Uwe Rommel
>
> TCP/IP connection established.
> 1k packets: 5326 k/sec
> 2k packets: 6079 k/sec
> 4k packets: 6273 k/sec
> 8k packets: 6648 k/sec
> 16k packets: 6755 k/sec
> 32k packets: 6680 k/sec
>
> I guess the PCI clock is always BaseClock/2 on my system.
> Wish I had a datasheet for the PC 750 clock chip, IMI SC471...
>

On 07-12-2023 15:19, Louis Ohland wrote:
> https://web.archive.org/web/19970409051608/http://www.imicorp.com/products/prodlit/sfds/sc471.htm
>
> crappy...
>
> Louis Ohland wrote:
>> ftp://ftp.best.com/pub.i/imiweb8/ds/sc471.pdf
>>
>> Louis Ohland wrote:
>>> www.imicorp.com
>>>
>>> Louis Ohland wrote:
>>>> https://ardent-tool.com/datasheets/IMI_SC425.pdf
>>>>
>>>> Louis Ohland wrote:
>>>>> https://www.ic72.com/pdf_file/i/26693.pdf
>>>>>
>>>>> Still haven't got the website yet.
>>>>>
>>>>> Not the SC471, but it's something
>>>>>
>>>>> Louis Ohland wrote:
>>>>>> In 2000, Cypress acquired IMI. After the acquisition, Refioglu ran the timing technology division for Cypress. Then, he left the company and started SpectraLinear in 2006. The startup then acquired Cypress' PC clock-chip division in October of 2006.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Louis Ohland wrote:
>>>>>>> International Microcircuits Inc. (IMI)
>>>>>>>
>>>>>>> Louis Ohland wrote:
>>>>>>>> Let's play the name game.
>>>>>>>>
>>>>>>>> IMI is who? Perhaps we can findt who bought them.
>>>>>>>>
>>>>>>>> Christian Holzapfel wrote:
>>>>>>>>> IMI SC471

Would this help?:

https://www.digchip.com/datasheets/search.php?pn=IMISC471

--
Jelte,
Admirer of the letter of IBM with blue Ishiki

Brilliant, thank you two!
By unsoldering pin 11 (S0) from CPU clock chip U1 and tying it to GND I should be able to achieve 80 MHz on the CPU and 40 on the PCI bus. Quite risky with that much overclocking, but worth a try, generally.
But it's getting off topic. If I ever try it and things get a 9-K-ish twist or smell again, I will post here :-)

Am 21.11.23 um 22:00 schrieb Wolfgang Gehl:
> Cool stuff, will definitely try it out on a 9595 or server 520 and
> report back. If only I had a little more time to play around with MCA ...

I finally found time to install a larger hard drive (16GB) in my 9595
and install Slackware 11 (kernel 2.4.33.3).

Unfortunately I have a problem with the sanremo.patch. This is what
happened:

/usr/src/linux# patch -p0 < sanremo.patch
patching file Documentation/Configure.help
Hunk #1 succeeded at 12863 with fuzz 2 (offset 6340 lines).
patching file drivers/net/Config.in
Hunk #1 FAILED at 121.
1 out of 1 hunk FAILED -- saving rejects to file drivers/net/Config.in.rej
patching file drivers/net/Makefile
Hunk #1 FAILED at 410.
1 out of 1 hunk FAILED -- saving rejects to file drivers/net/Makefile.rej
patching file drivers/net/Space.c
Hunk #1 FAILED at 50.
Hunk #2 succeeded at 205 (offset -105 lines).
1 out of 2 hunks FAILED -- saving rejects to file drivers/net/Space.c.rej

file Config.in.rej

***************
*** 121,126 ****
if [ "$CONFIG_MCA" = "y" ]; then
tristate 'NE/2 (ne2000 MCA version) support' CONFIG_NE2_MCA
tristate 'SKnet MCA support' CONFIG_SKMC
fi
bool 'EISA, VLB, PCI and on board controllers' CONFIG_NET_EISA
if [ "$CONFIG_NET_EISA" = "y" ]; then
--- 121,127 ----
if [ "$CONFIG_MCA" = "y" ]; then
tristate 'NE/2 (ne2000 MCA version) support' CONFIG_NE2_MCA
tristate 'SKnet MCA support' CONFIG_SKMC
+ tristate 'IBM MCA 10/100 Mbps Ethernet (9-K)' CONFIG_SANREMO
fi
bool 'EISA, VLB, PCI and on board controllers' CONFIG_NET_EISA
if [ "$CONFIG_NET_EISA" = "y" ]; then

file Makefile.rej

***************
*** 410,415 ****
endif
endif

ifeq ($(CONFIG_DEFXX),y)
L_OBJS += defxx.o
endif
--- 410,423 ----
endif
endif

+ ifeq ($(CONFIG_SANREMO),y)
+ L_OBJS += sanremo.o
+ else
+ ifeq ($(CONFIG_SANREMO),m)
+ M_OBJS += sanremo.o
+ endif
+ endif
+ ifeq ($(CONFIG_DEFXX),y)
L_OBJS += defxx.o
endif

file Space.c.rej

***************
*** 58,63 ****
extern int el3_probe(struct device *);
extern int at1500_probe(struct device *);
extern int pcnet32_probe(struct device *);
extern int at1700_probe(struct device *);
extern int fmv18x_probe(struct device *);
extern int eth16i_probe(struct device *);
--- 58,64 ----
extern int el3_probe(struct device *);
extern int at1500_probe(struct device *);
extern int pcnet32_probe(struct device *);
+ extern int sanremo_probe(struct device *);
extern int at1700_probe(struct device *);
extern int fmv18x_probe(struct device *);
extern int eth16i_probe(struct device *);

Looks like I need help. Is there a solution to this or do I have to go
back to Slackware 8 (Kernel 2.2.19)?

Wolfgang

Wolfgang Gehl schrieb am Dienstag, 16. Januar 2024 um 00:26:09 UTC+1:
> Looks like I need help. Is there a solution to this or do I have to go
> back to Slackware 8 (Kernel 2.2.19)?
>
> Wolfgang

The patch and C-file won't work with a 2.4 Kernel out of the box.
I already started porting the sanremo.c to 2.4, but it's not final yet, I have no patch and corrupted my 2.4 Linux partition >.<
I can send it to you for further testing. It's not fully cleaned up, but should compile and give a connection.

Interestingly, the 2.4 Kernel seems to tackle some performance issues: It now seems to hand the network subsystem buffers straight down to the card for DMA.
Seems to only profit in one direction, and degrade in the other.

This is what I measured on an 8595 with Pentium 200, Kernel 2.2:

NETIO - Network Throughput Benchmark, Version 1.7
(C) 1997-1999 Kai Uwe Rommel

TCP/IP connection established.
1k packets: 6726 k/sec
2k packets: 8456 k/sec
4k packets: 8741 k/sec
8k packets: 8680 k/sec
16k packets: 8586 k/sec
32k packets: 7974 k/sec

NETIO - Network Throughput Benchmark, Version 1.7
(C) 1997-1999 Kai Uwe Rommel

TCP/IP connection established.
1k packets: 6196 k/sec
2k packets: 6175 k/sec
4k packets: 6237 k/sec
8k packets: 6250 k/sec
16k packets: 6240 k/sec
32k packets: 6172 k/sec

And on the same system with a Kernel 2.4:

NETIO - Network Throughput Benchmark, Version 1.7
(C) 1997-1999 Kai Uwe Rommel

TCP/IP connection established.
1k packets: 7415 k/sec
2k packets: 7485 k/sec
4k packets: 7809 k/sec
8k packets: 7793 k/sec
16k packets: 7689 k/sec
32k packets: 7199 k/sec

NETIO - Network Throughput Benchmark, Version 1.7
(C) 1997-1999 Kai Uwe Rommel

TCP/IP connection established.
1k packets: 6949 k/sec
2k packets: 6900 k/sec
4k packets: 6903 k/sec
8k packets: 6900 k/sec
16k packets: 6910 k/sec
32k packets: 6886 k/sec

Hmmm, very silent here. I hope I'm not the last man standing.

After a lot of fiddling with the kernel source code I have found a way
to establish a reliable and persistent network connection under
Slackware 11, Kernel 2.4.33.3. The solution to the puzzle here was to
build the network driver as a module, to load the module via
/etc/rc.d/rc.netdevice and assign a static ip configuration via
/etc/rc.d/rc.inet1.conf, /etc/resolv.conf and /etc/hosts, ymmv.

Involved was a 9595A, P90, 256MB RAM, now with a 10/100 network link. A
big thank you to all who were involved in the driver development and
especially to Christian, who sent driver patches and was patient with me.

Here are the netio 1.30 client results.

KB/s Tx KB/s Rx
1KB Paket 6567,01 5229,21
2KB Paket 7499,88 5307,07
4KB Paket 7623,93 5288,49
8KB Paket 7545,33 5315,38
16KB Paket 7151,32 5326,32
32KB Paket 7668,42 5256,43

Wolfgang

Am 16.01.24 um 09:20 schrieb Christian Holzapfel:
> Wolfgang Gehl schrieb am Dienstag, 16. Januar 2024 um 00:26:09 UTC+1:
>> Looks like I need help. Is there a solution to this or do I have to go
>> back to Slackware 8 (Kernel 2.2.19)?
>>
>> Wolfgang
>
> The patch and C-file won't work with a 2.4 Kernel out of the box.
> I already started porting the sanremo.c to 2.4, but it's not final yet, I have no patch and corrupted my 2.4 Linux partition >.<
> I can send it to you for further testing. It's not fully cleaned up, but should compile and give a connection.
>
> Interestingly, the 2.4 Kernel seems to tackle some performance issues: It now seems to hand the network subsystem buffers straight down to the card for DMA.
> Seems to only profit in one direction, and degrade in the other.
>
> This is what I measured on an 8595 with Pentium 200, Kernel 2.2:
>
> NETIO - Network Throughput Benchmark, Version 1.7
> (C) 1997-1999 Kai Uwe Rommel
>
> TCP/IP connection established.
> 1k packets: 6726 k/sec
> 2k packets: 8456 k/sec
> 4k packets: 8741 k/sec
> 8k packets: 8680 k/sec
> 16k packets: 8586 k/sec
> 32k packets: 7974 k/sec
>
> NETIO - Network Throughput Benchmark, Version 1.7
> (C) 1997-1999 Kai Uwe Rommel
>
> TCP/IP connection established.
> 1k packets: 6196 k/sec
> 2k packets: 6175 k/sec
> 4k packets: 6237 k/sec
> 8k packets: 6250 k/sec
> 16k packets: 6240 k/sec
> 32k packets: 6172 k/sec
>
> And on the same system with a Kernel 2.4:
>
> NETIO - Network Throughput Benchmark, Version 1.7
> (C) 1997-1999 Kai Uwe Rommel
>
> TCP/IP connection established.
> 1k packets: 7415 k/sec
> 2k packets: 7485 k/sec
> 4k packets: 7809 k/sec
> 8k packets: 7793 k/sec
> 16k packets: 7689 k/sec
> 32k packets: 7199 k/sec
>
> NETIO - Network Throughput Benchmark, Version 1.7
> (C) 1997-1999 Kai Uwe Rommel
>
> TCP/IP connection established.
> 1k packets: 6949 k/sec
> 2k packets: 6900 k/sec
> 4k packets: 6903 k/sec
> 8k packets: 6900 k/sec
> 16k packets: 6910 k/sec
> 32k packets: 6886 k/sec
>

Still reading and working on it, slowly but thoroughly ;-)

Thank you for your time and testing - glad it finally works.

I added the kernel 2.4 files to my GitHub repo:
https://github.com/holzachr/sanremo-linux/tree/Kernel-2.4.18

Tomas received a separate copy too.