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

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

from kernel.

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.

from kernel.

from kernel.

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

from kernel.

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.

from kernel.

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

from kernel.

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.

from kernel.

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

The previous commit 3ef6d61 works as expected.

from kernel.

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.

from kernel.

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

from kernel.

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.

from kernel.

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

from kernel.

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.

from kernel.

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

from kernel.

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

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

from kernel.

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?

from kernel.

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.

from kernel.

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

from kernel.

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.

from kernel.

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?

from kernel.

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.

from kernel.

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

from kernel.

[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?

from kernel.

Do you want to try debugging the kernel?

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

from kernel.

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.

from kernel.

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

from kernel.

[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.

from kernel.

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.

from kernel.

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)

from kernel.

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.

from kernel.

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.

from kernel.

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

from kernel.