Open woodalgo opened 1 year ago
First step would be to run though the What to try first troubleshooting steps. Sometimes a simple full overwrite format of the SD card can help many odd issues. Looking at the logs (70k lines) nothing sticks out to me. Looks like you're running a custom build - could you ensure you're on a release just so we're looking at the same code?
hi. Thanks. I will try a full overwrite format as suggested. There's no custom code in there. I was just seeing if I could flash the controller . I will reflash with the latest release and let you know if the error persists. Thankyou
I have low-level reformatted the SD card (mkfs.exfat) and reflashed the firmware to the latest release. However the issue remains. log.txt I notice that the renegotiation always takes place shortly after the log - "Total IN: 0 OUT: 0 CHECKSUM: 0" not sure if that is relevant. Please let me know if there is anything more tests I can perform.
Thanks
Have you tried setting Quirks = 0?
It appears to be set for VMS which does a subtle change around the DATA IN phase that could be causing your problem
HI
Are you looking at the log I attached most recently. I thought I had set Quirks back to 0.. am I missing a setting ?
Anyway, I get the same error with No Quirks set .
1806ms] === Configured SCSI Devices ===
[1807ms] ID: 1, BlockSize: 512, Type: Fixed, Quirks: None, Size: 12582912kB
[1808ms] ID: 3, BlockSize: 512, Type: Fixed, Quirks: None, Size: 12582912kB
[1909ms]
Many thanks for looking into this.
I am seeing the same issue. Qurks set to 0, System set to Generic. I am seeing scsi bus parity error reported from within netbsd. Note that I can boot netbsd from the cd but the mount command in the installer fails. I dunno if this is a clue... I also made sure to reformat the exFAT SD.
Here is the log.txt:
[10ms] Platform: BlueSCSI Pico [10ms] FW Version: 2023.04.10-release Apr 10 2023 19:08:58 Flash chip size: 2048 kB
=== SD Card Info === SD card detected, exFAT volume size: 59608 MB SD Name: SD64G, MID: 0x9F, OID: 0x54 0x49
=== Global Config === Reading configuration from bluescsi.ini Active configuration (using system preset "Generic"):
=== Finding images in / === == Opening /HD1.img for ID: 1 LUN: 0 ---- Image ready == Opening /CD6_512.iso for ID: 6 LUN: 0 ---- Configuring as CD-ROM drive based on image name ---- Image ready
=== ROM Drive === Platform supports ROM drive up to 1692 kB ---- ROM drive image not detected
=== Configured SCSI Devices ===
Initialization complete! WARNING: Host used command 0x1A which is affected by drive geometry. Current settings are 63 sectors x 255 heads = 16065 but image size of 4194304 sectors is not divisible. This can cause error messages in diagnostics tools. SCSI ID 1 negotiated synchronous mode 10 MB/s (period 4x25 ns, offset 15 bytes) SCSI ID 6 negotiated synchronous mode 10 MB/s (period 4x25 ns, offset 15 bytes)
Here is the logfile with Debug=1: log.txt. I tried it both with and without internal termination jumper. This debug log is with internal termination turned off. I am pretty sure this is the correct setting since the SS10 has internal termination for both the internal disks. The BlueSCSIv2 is mounted directly as the first internal disk and powered off of the internal 5/12 v power molex. I am getting parity errors when trying to mount the cdrom.
having spent a few days on this it seems clear that sparcstation 10 simply doesn't work with bluescsi2
We've recently got a few users saying that sparcstation "just works" - but I'm sure there's a lot of variation in hardware, OS, etc. Looking at the logs I don't see any parity errors. Parity errors you're seeing are on the host side? It could be an actual hardware issue or cable issue. To rule this in or out I'd try a different cable or a different computer just to see.
I've had a BlueSCSI 1.1a chugging away happily in my SPARCstation 10 for a while now. No issues at all with that one.
I recently got a BlueSCSI v2 2023.10a and gave it a try. Upon Solaris boot, it gave me a couple of SCSI bus errors, but continued to boot up. Looking at the BlueSCSI debug log, it seems like it originally negotiated the sync speed at 10MB/s, then renegotiated to 5MB/s around when the errors occurred.
So I tried MaxSyncSpeed=5
in bluescsi.ini and that seems to get the Sun to boot up without any error messages.
I'd still like to figure out why it throws errors when using the default of MaxSyncSpeed=10
.
log.txt - no MaxSyncSpeed specified in bluescsi.ini
log.txt - MaxSyncSpeed=5 in bluescsi.ini
Other than the variation in MaxSyncSpeed, the rest of my bluescsi.ini is:
[SCSI]
System=Generic
Quirks=0
I too have a BlueSCSI v2 2023.10a that doesn't work properly with a Sparccalssic or a Sparcstation 5.
When installing Solaris 2.6 from the CDROM image I get the following warnings in the console:
WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@3,0 (sd3):
Error for Command: write Error Level: Retryable Requested Block: 146336 Error Block: 146336 Vendor: SEAGATE Serial Number: BlueSCSI v20 Sense Key: Media Error ASC: 0xc (<vendor unique code 0xc>), ASCQ: 0x2, FRU: 0x0
With a corresponding CRC error in the log file:
SDIO card reports write CRC error, status 0xAC7FFFFF SdioCard::writeSectors(0x002274ED,...,19) failed: 7 SD card write failed: 0x00
The read only Solaris CDROM ISO image file seems to work without issue. Its only when writing to the disk image file (SCSI ID3) that I occasionally get these errors. I have tried reformatting with the SD Card Formatter, termination on and off, MaxSyncSpeed=5, etc.
I have managed to image 3 SCSI drives with the BlueSCSI v2, 1 Mac and 2 Solaris formatted drives. The BlueSCSI v2 seems to work fine on a Macintosh plus computer although I did not do a lot of testing. The same Sparcclassic and Sparcstation 5 work perfectly with a ZuluSCSI v6.4 Rev 2024a. I have tried so many SD cards with the BlueSCSI v2, Verbatim 16GB V30, Samsung EVO plus V30, Kingston 32GB V90 (300MB/s) with the same results.
If you know of users that have a sparcstation that "just works", any of them using a BlueSCSI v2 2023.10a and a Sparcstation 5, 10 or classic? Are they using it internally or externally? What SD card are they using?
Did you try setting the MaxSynxSpeed=5 in the ini? I mean it's not ideal in the Sparc 5 context but a Sparc 1 was never going to get much more than 5MB/sec if that
Yes, I did try that. I mentioned that in the comments. I also tried
Quirks=0 ; Standard EnableSCSI2=0 ; Off EnableSelLatch=1 ; On SelectionDelay=1000
I also tried connecting the BlueSCSI v2 externally with a physical termination. Whatever I do, I get the SCSI write errors. But, if I configure the BlueSCSI v2 to emulate the CDROM only and a ZuluSCSI v6.4 Rev 2024a to emulate the disk as pictured below that works perfectly.
Apologies if I missed it, there is definitely something afoot with certain eras of Sparc and the write operation failing. I have a Sparc 10 now that I'm getting ready to run hopefully I can track down the problem.
So just to comment here for anyone currently you can use this release 2023.07.03 with devices that are experiences SDIO errors during writes. It doesn't experience the issue being displayed here and was tested on my Sparcstation 10.
With that firmware my Sparcstation won't even respond to the probe-scsi command.
Wow that's quite unexpected are you still using the settings in the ini file you spoke of earlier?
The 2023.07.03 firmware doesn't work at all on my SS10, either. The Sun can't even detect any SCSI devices.
2024.05.21 works flawlessly for me, aside from the fact that I have to use MaxSyncSpeed=5
to avoid Solaris 2.7 boot errors.
It's possible that different system boards and ROM revisions are working differently with BlueSCSI. That might explain why it works to varying degrees for different folks.
I don't know if it'll help anyone, but my SS10 board is part number 501-1938, 07 rev 57, FRU 501-2259, ROM is 2.25.
BlueSCSI termination power is set to off per the Sun service manual. First drive is configured as SCSI ID 3, also per the Sun manual.
Fascinating! Certainly could be the case. I'll have to try some further combinations of OS and see if anything works differently. As it stands there is definitely something afoot that needs fixing. These other issues may be a symptom or possibly something new to investigate afterwards.
I have the Bluescsiv2 working on SS10 however it throws a few SCSI Bus DATA IN phase parity Error.s on the console. and the transfer speed is lowered to 5MB/S .. apart from that the drives work fine. I have parity enabled as per the SpacSS10 documentation.
bluescsiv2ss10.txt