Regression: After commit 1c2f541 (2024/02/04) CH357 driver doesn't work anymore (UPDATE)

[bocke]

Hi. Ch357 is a USB to ISA controller that is somewhat popular in retro community. It's also built-in into Book8088, a hobbyist retro computer from China.

I tried the CH357 drivers on a last nights build of 2043 dev kernel (both 8086 and 80186 with FAT32) and it got stuck after displaying the driver info and if the USB stick is inserted or not (it gets stuck in both cases).

I than tried one of the drivers on 2042 kernel (8086 with FAT32) from Sourceforge and it actually worked without problems. The version released as 2.43 on GitHub also works. By further testing I isolated the problem to the changes from the last 2 days (4th and 5th of february 2024). By building and trying the commits from the past two days, I identified that the problem first appear with the commit 1c2f541.

[bocke]

This seems to be a bug from a recent build. I tried to revert to commit d027c79 from 19 of december of 2023 and the driver works. So problem was created in the next few commits.

Luckily only 3 days after that have commits so it wouldn't be that hard to isolate what change created the problem.

[bocke]

I also tried building commit 9a7d227 from yesterday and it also works. So the problem was introduced in one of commits yesterday or today.

[bocke]

The commit 431be02 from yesterday has this problem. The driver gets stucked. I'll go back a few commits to try to indentify which one created the problem.

[bocke]

I got it! The problem was introduced with the commit 1c2f541.

The previous commit 3ef6d61 works as expected.

[ecm-pushbx]

That's mine, I'm afraid. Try inserting the line sti before int 0

[bocke]

IF you meant it like this (intr.asm):

83 		push	ax
84		mov	ax, [bx]
85		mov	cx, [bx+4]
86		mov	bx, [bx+2]
87		popf				; set live FL
88		pop	ds
89		sti
90		int	0

That didn't help.

[ecm-pushbx]

IF you meant it like this (intr.asm):

83 		push	ax
84		mov	ax, [bx]
85		mov	cx, [bx+4]
86		mov	bx, [bx+2]
87		popf				; set live FL
88		pop	ds
89		sti
90		int	0

That didn't help.

Yes, that's what I meant. I will prepare a different patch later today for you to try.

[ecm-pushbx]

Try the file in https://pushbx.org/ecm/test/20240205/intr.asm

[bocke]

No luck.

As you noticed I do use a Watcom compiler (OpenWatcom 1.9). I didn't mention that before. I'm using the DOS version under DOSEmu.

[ecm-pushbx]

Okay, thanks. Does the gcc build in https://pushbx.org/ecm/download/old/fdkernel/20240204.zip work?

[ecm-pushbx]

Next, you can try https://pushbx.org/ecm/test/20240205/sahfgcc.sys (rename to kernel.sys) which is my gcc build with the intr.asm file in the same server directory.

[bocke]

I'll test them out and get back to you.

[bocke]

The first one acts strange. It goes blank after dislaying FreeDOS copyright.

The second one gets stuck after loading the driver. No change.

[PerditionC]

it might be the update_dcb change as well, I have to revisit the case of numdrives=0 initialization of lol->dpb tonight. I'm on my phone so going. mostly on memory. github currently having issue installing package due to gpg issue, at least as best I can tell that's why most recent build failed.

…

On Mon, Feb 5, 2024, 10:50 AM Bocke ***@***.***> wrote: The first one acts strange. It goes blank after dislaying FreeDOS copyright. The second one gets stuck after loading the driver. No change. — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD3LQJZMV2H4JH4GIH7O2DYSD5VHAVCNFSM6AAAAABCZ7LIL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRXGMYDKMZUGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ecm-pushbx]

The first one acts strange. It goes blank after dislaying FreeDOS copyright.

The second one gets stuck after loading the driver. No change.

Did you remember to configure these kernels to disable LBA?

[bocke]

The first one acts strange. It goes blank after dislaying FreeDOS copyright.
The second one gets stuck after loading the driver. No change.

Did you remember to configure these kernels to disable LBA?

Yes.

[ecm-pushbx]

Can you try https://pushbx.org/ecm/download/old/fdkernel/20231220.zip please?

[bocke]

I just want to remind you that the commits before 1c2f541 (04. Feb. 2024) should work as per my testing.

The problem only occurs at commit 1c2f541 and after.

If you haven't done any custom patching it was likely to work. But I still tested it for completeness sake and it did work.

[bocke]

Oh, I see the difference: it's compiled with GCC. It does work, but it's before the problematic commit, so I was expecting it to work.

Unless you think the bug has something to do with a compiler it was compiled against?

[ecm-pushbx]

I received your screenshot in https://www.bttr-software.de/forum/forum_entry.php?id=21289

Oh, I see the difference: it's compiled with GCC. It does work, but it's before the problematic commit, so I was expecting it to work.

Yes, my builds are gcc builds. I wanted to figure out whether the different crash you had was more likely to be something that's specific to gcc builds or more likely a recent bug.

Unless you think the bug has something to do with a compiler it was compiled against?

Could be, it's difficult to tell. Do you want to try debugging the kernel? You would need to download two zipballs:

https://pushbx.org/ecm/download/ldebug.zip - Extract ldebug.com and instsect.com

https://pushbx.org/ecm/download/ldosboot.zip - Extract patch.sld

Place the files in the root directory of the file system you want to boot. Then you run the following in a DOS:

ldebug /f+ /e+ ldebug.com
r ve7 = 100
r ve8 = 8181
y patch.sld :query_patch_iniload
w
q

Then run instsect C: /L none and it will install the lDOS loader into the partition boot sector. The /L switch with the parameter "none" patches the loader so it won't use any LBA detection nor read access, which should enable to run on the system with the ROM-BIOS bug. The 8181h query patch likewise instructs the initial loader and debugger to not attempt to use LBA functions.

For completeness, you can enter the following lines into the file "ldebug.sld" also placed in the root directory:

:bootstartup
@r v10 = 0
@:loop
@r bootunitfl(v10) or= 1
@r v10 += 1
@if (v10 < 100) then goto :loop

This will tell the debugger to access all disk units using only CHS access, and to never call LBA functions. (However, the query patch with 8181h is sufficient to have the debugger access specifically the load partition using only CHS.)

In DOS run sys config checkdebugger=1 to enable the kernel's debugger support.

Next, boot the debugger. Depacking may take a few seconds. Once the prompt (a dash -) is displayed, enter the command boot protocol freedos. Optional: Specify a filename after, as in boot protocol freedos kernel2.sys. Once the kernel is loaded, run g. It should stop early in the kernel's load at a jc instruction with flags = NC. Run r f CY to toggle the branch. This instructs the kernel not to overwrite the int 0, 1, and 3 handlers so the debugger can regain control. Then trace or run the kernel. Here's what it looks like:

-boot protocol freedos
-g
Unexpected breakpoint interrupt
AX=7301 BX=0000 CX=0000 DX=0BC0 SP=251C BP=251C SI=0017 DI=0152
DS=73AD ES=73AD SS=73AD CS=6F2D IP=00DF NV UP EI PL ZR NA PE NC
6F2D:00DF 7202              jb      00E3                            not jumping
-r f CY
-

If you want to only boot DOS without the debugger, enter boot protocol freedos and then q to unload the debugger.

[PerditionC]

[unrelated to issue] do you mind if I incorporate/copy your "how to debug" into the kernel documentation?

[ecm-pushbx]

[unrelated to issue] do you mind if I incorporate/copy your "how to debug" into the kernel documentation?

You're welcome to do that! The instsect /L switch, query patch, and setting the low bit of BOOTUNITFLxx are of course only needed when LBA detection would fail or cause problems like on this device. Everything else is more generally applicable. If you want any more details or have any questions feel free to ask.

I also described some techniques for debugging in the forum:

https://www.bttr-software.de/forum/forum_entry.php?id=21270&page=0&category=all&order=last_answer

https://www.bttr-software.de/forum/forum_entry.php?id=21271&page=0&category=all&order=last_answer

If you want to discuss this more, we could use a github discussion? Or a new thread in the forum?

[bocke]

Do you want to try debugging the kernel?

Sure. But not right now. In a few days.

[ecm-pushbx]

Do you want to try debugging the kernel?

Sure. But not right now. In a few days.

Allright, just wanted to provide you with the basics so you can get started when you have the time.

[bocke]

No problem. Thank you. Will get back to you.

[PerditionC]

[loading driver without device, so ultimately errors loading] without the sti I get the hang attempting to load the driver in 86box, but driver doesn't hang in bochs; adding the sti I get same result of failed loading but no hang in both. I am going to see if I can find another driver that runs under emulation that fails to load. I have a usb2isa card (ch375 based) on order - not sure if any of my ISA compatible computers still boot... and my book8088 is en-route from China, so for now I can't reproduce to help debug.

[bocke]

I'm sorry. I was thinking of dedicating a day or two to debugging this over a weekend. Haven't had time and will to mess with it these days.

It would certainly help if you don't have to rely on my spare time for debugging. But I just wanted to say I didn't forget about this and still intend to help.

[PerditionC]

no worries and no hurry, I just didn't want anyone to think I was ignoring this. I understand having limited time. :-)

[ecm-pushbx]

You added the sti in 795c1df

Can you try the kernel/source file in https://pushbx.org/ecm/test/20240205/ as well please?

Like @tkchia mentioned this uses sahf which also is much shorter than my original attempt: #81 (comment)

[bocke]

I'm sorry. It didn't turn out how I planned. I worked the saturday so I was too tired and lazy to test it out over the rest of the weekend. After that I got hit with some virus this monday and am still recovering.

[boeckmann]

After that I got hit with some virus this monday and am still recovering.

Good recovery! I am currently also down by a virus infection.

[ecm-pushbx]

Wishing you both all the best too. If you want I can soon prepare a few more kernel builds to test.