search

FDOS / kernel

FreeDOS kernel - implements the core MS-DOS/PC-DOS (R) compatible operating system. It is derived from Pat Villani's DOS-C kernel and released under the GPL v2 or later. Please see http://www.freedos.org/ for more details about the FreeDOS (TM) Project.
http://kernel.fdos.org/
GNU General Public License v2.0
811 stars 144 forks source link

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

Open bocke opened 9 months ago

bocke commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

The previous commit 3ef6d61 works as expected.

ecm-pushbx commented 9 months ago

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

bocke commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

bocke commented 9 months ago

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 commented 9 months ago

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

ecm-pushbx commented 9 months ago

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 commented 9 months ago

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

bocke commented 9 months ago

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

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

PerditionC commented 9 months ago

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 https://github.com/FDOS/kernel/issues/130#issuecomment-1927305340, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD3LQJZMV2H4JH4GIH7O2DYSD5VHAVCNFSM6AAAAABCZ7LIL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRXGMYDKMZUGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

ecm-pushbx commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

bocke commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

ecm-pushbx commented 9 months ago

[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 commented 9 months ago

Do you want to try debugging the kernel?

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

ecm-pushbx commented 9 months ago

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 commented 9 months ago

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

PerditionC commented 9 months ago

[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 commented 9 months ago

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 commented 9 months ago

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

ecm-pushbx commented 9 months ago

You added the sti in https://github.com/FDOS/kernel/commit/795c1df7429a20321f6c2aaeeada1f282f32f056

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: https://github.com/FDOS/kernel/pull/81#issuecomment-1146649323

bocke commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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