Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Sebastian Herbszt]

      I have tried SeaBIOS 0.5.1 on Bochs cvs with FreeDOS 1.0 Final boot floppy.
Loading from floppy was utterly slow and then FreeDOS dumped 

Invalid Opcode at 0013 0000 0202 800F 01F3 20F4 10AA 10AA 109A 0000 0000 0000 00
00
Bad or missing Command Interpreter: A:\COMMAND.COM A:\ /E:2048 /F /MSG /P=A:\FRE
EDOS\FDAUTO.BAT
 Enter the full shell command line:

Bochs log has
00477945139i[BIOS ] Booting from Floppy...
00510608951i[BIOS ] Booting from 0000:7c00
05264161428i[FDD  ] controller reset in software
05445136148i[FDD  ] controller reset in software
05625186768i[FDD  ] controller reset in software
05803824012i[FDD  ] controller reset in software
05985259728i[FDD  ] controller reset in software
05985285461i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)

Same floppy and Bochs version work fine and fast with Bochs BIOS.

Any clues?

- Sebastian

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Sat, Jan 09, 2010 at 07:48:51PM +0100, Sebastian Herbszt wrote:
  I have tried SeaBIOS 0.5.1 on Bochs cvs with FreeDOS
1.0 Final boot floppy.
 Loading from floppy was utterly slow and then FreeDOS dumped
 
 Invalid Opcode at 0013 0000 0202 800F 01F3 20F4 10AA 10AA 109A 0000 0000 0000 00
I saw this as well.  I bisected it to this commit:

ee2efa7303077ce98a745f637e213ba9a0965811

and if I apply the following change, it fixes the problem on bochs:

--- a/src/util.h
+++ b/src/util.h
@@ -39,7 +39,7 @@ static inline void cpu_relax(void)
 // Atomically enable irqs and sleep until an irq; then re-disable irqs.
 static inline void wait_irq(void)
 {
-    asm volatile("sti ; hlt ; cli ; cld": : :"memory");
+    asm volatile("sti ; rep ; nop ; cli ; cld": : :"memory");
 }
 
 static inline void nop(void)

However, I didn't think there was anything wrong with the original
code.  Am I missing something?

-Kevin

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Sebastian Herbszt]

      Kevin O'Connor wrote:
  On Sat, Jan 09, 2010 at 07:48:51PM +0100, Sebastian
Herbszt wrote:
> I have tried SeaBIOS 0.5.1 on Bochs cvs with FreeDOS 1.0 Final boot floppy.
> Loading from floppy was utterly slow and then FreeDOS dumped
> 
> Invalid Opcode at 0013 0000 0202 800F 01F3 20F4 10AA 10AA 109A 0000 0000 0000 00
(0) Breakpoint 2, 0x0000000000000010 in ?? ()
Next at t=4522611939
(0) [0x00000010] 0000:0010 (unk. ctxt): push bx                   ; 53
<bochs:12> disasm /5
00000010: (                    ): push bx                   ; 53
00000011: (                    ): inc word ptr ds:[bx+si]   ; ff00
00000013: (                    ): lock push bx              ; f053
00000015: (                    ): inc word ptr ds:[bx+si]   ; ff00
00000017: (                    ): lock ret 0xd110           ; f0c210d1

(0) [0x0002112e] 20f4:01ee (unk. ctxt): call far 0000:0010        ; 9a10000000

and 0x20f4 is SS

  I saw this as well.  I bisected it to this commit:
 
 ee2efa7303077ce98a745f637e213ba9a0965811
 
 and if I apply the following change, it fixes the problem on bochs:
 
 --- a/src/util.h
 +++ b/src/util.h
 @@ -39,7 +39,7 @@ static inline void cpu_relax(void)
 // Atomically enable irqs and sleep until an irq; then re-disable irqs.
 static inline void wait_irq(void)
 {
 -    asm volatile("sti ; hlt ; cli ; cld": : :"memory");
 +    asm volatile("sti ; rep ; nop ; cli ; cld": : :"memory");
 }
 
 static inline void nop(void)
 
 However, I didn't think there was anything wrong with the original
 code.  Am I missing something?
It should be ok. Your replacement uses PAUSE which can cause VM exits.

- Sebastian

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Sun, Jan 10, 2010 at 03:59:22PM +0100, Sebastian Herbszt wrote:
  Kevin O'Connor wrote:
 >and if I apply the following change, it fixes the problem on bochs:
[...]
  >-    asm volatile("sti ; hlt ; cli ;
cld": : :"memory");
 >+    asm volatile("sti ; rep ; nop ; cli ; cld": : :"memory");
[...]
 However, I
didn't think there was anything wrong with the original
code.  Am I missing something?
 
 It should be ok. Your replacement uses PAUSE which can cause VM exits.
Yes, but I'd rather not make the change as it causes more cpu load on
the host.  Is there a reason why Bochs doesn't work with the original
code?

-Kevin

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Sebastian Herbszt]

      Kevin O'Connor wrote:
  On Sun, Jan 10, 2010 at 03:59:22PM +0100, Sebastian
Herbszt wrote:
  Kevin O'Connor wrote:
 >and if I apply the following change, it fixes the problem on bochs:
 [...]
  >-    asm volatile("sti ; hlt ; cli ;
cld": : :"memory");
 >+    asm volatile("sti ; rep ; nop ; cli ; cld": : :"memory");
 [...]
 However, I
didn't think there was anything wrong with the original
code.  Am I missing something?
 
 It should be ok. Your replacement uses PAUSE which can cause VM exits.
 
 Yes, but I'd rather not make the change as it causes more cpu load on
 the host.  Is there a reason why Bochs doesn't work with the original
 code?
I did some tracing and noticed the following:

Bochs BIOS
(0) Breakpoint 1, 0x0000000000010ad4 in ?? ()
Next at t=158212338
(0) [0x00010ad4] 10aa:0034 (unk. ctxt): retf                      ; cb
<bochs:3> p
Next at t=158212339
(0) [0x00020f41] 20f4:0001 (unk. ctxt): add bh, bh                ; 00ff

SeaBIOS
(0) Breakpoint 1, 0x0000000000010ad4 in ?? ()
Next at t=7729552430
(0) [0x00010ad4] 10aa:0034 (unk. ctxt): retf                      ; cb
<bochs:9> p
Next at t=7729552431
(0) [0x00020f41] 20f4:0001 (unk. ctxt): add byte ptr ds:[bx+si], al ; 0000

Modified SeaBIOS
(0) Breakpoint 1, 0x0000000000010ad4 in ?? ()
Next at t=394287951
(0) [0x00010ad4] 10aa:0034 (unk. ctxt): retf                      ; cb
<bochs:4> p
Next at t=394287952
(0) [0x00020f41] 20f4:0001 (unk. ctxt): add bh, bh                ; 00ff

So with Bochs BIOS and modified SeaBIOS we got the correct code
at 20f4:0001. With not modified SeaBIOS we got zeros there.
Still no clue why.

- Sebastian

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Sun, Jan 10, 2010 at 11:12:11PM +0100, Sebastian Herbszt wrote:
  Kevin O'Connor wrote:
 On Sun, Jan 10, 2010 at 03:59:22PM +0100,
Sebastian Herbszt wrote:
 Kevin O'Connor wrote:
>and if I apply the following change, it fixes the problem on bochs:
[...]
 >-    asm volatile("sti ; hlt ; cli ;
cld": : :"memory");
>+    asm volatile("sti ; rep ; nop ; cli ; cld": : :"memory");
[...]
 However, I
didn't think there was anything wrong with the original
code.  Am I missing something?
It should be ok. Your replacement uses PAUSE which can cause VM exits.
Yes, but I'd rather not make the change as it causes more cpu load on
the host.  Is there a reason why Bochs doesn't work with the original
code?
 
 I did some tracing and noticed the following:
 From your original mail:
05264161428i[FDD  ] controller reset in software
05445136148i[FDD  ] controller reset in software
05625186768i[FDD  ] controller reset in software
05803824012i[FDD  ] controller reset in software
05985259728i[FDD  ] controller reset in software

SeaBIOS makes a call to wait_irq() in the wait_floppy_irq() function
in src/floppy.c.  My guess is that the floppy irq was lost, and
SeaBIOS went into recovery mode.  It's just a guess, but maybe
0x00020f41 isn't populated because the floppy read failed (because of
lost irq?).

-Kevin

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Sebastian Herbszt]

      Kevin O'Connor wrote:
  On Sun, Jan 10, 2010 at 11:12:11PM +0100, Sebastian
Herbszt wrote:
  Kevin O'Connor wrote:
 On Sun, Jan 10, 2010 at 03:59:22PM +0100,
Sebastian Herbszt wrote:
 Kevin O'Connor wrote:
>and if I apply the following change, it fixes the problem on bochs:
[...]
 >-    asm volatile("sti ; hlt ; cli ;
cld": : :"memory");
>+    asm volatile("sti ; rep ; nop ; cli ; cld": : :"memory");
[...]
 >However, I didn't think there was anything
wrong with the original
>code.  Am I missing something?

It should be ok. Your replacement uses PAUSE which can cause VM exits.
Yes, but I'd rather not make the change as it causes more cpu load on
the host.  Is there a reason why Bochs doesn't work with the original
code?
 
 I did some tracing and noticed the following:
 
 From your original mail:
 
 05264161428i[FDD  ] controller reset in software
 05445136148i[FDD  ] controller reset in software
 05625186768i[FDD  ] controller reset in software
 05803824012i[FDD  ] controller reset in software
 05985259728i[FDD  ] controller reset in software
 
 SeaBIOS makes a call to wait_irq() in the wait_floppy_irq() function
 in src/floppy.c.  My guess is that the floppy irq was lost, and
 SeaBIOS went into recovery mode.  It's just a guess, but maybe
 0x00020f41 isn't populated because the floppy read failed (because of
 lost irq?).
It is indeed related to floppy. Booting FreeDOS from cd works.

- Sebastian

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Sun, Jan 10, 2010 at 11:46:50PM +0100, Sebastian Herbszt wrote:
  Kevin O'Connor wrote:
 05264161428i[FDD  ] controller reset in software
05445136148i[FDD  ] controller reset in software
05625186768i[FDD  ] controller reset in software
05803824012i[FDD  ] controller reset in software
05985259728i[FDD  ] controller reset in software

SeaBIOS makes a call to wait_irq() in the wait_floppy_irq() function
in src/floppy.c.  My guess is that the floppy irq was lost, and
SeaBIOS went into recovery mode.  It's just a guess, but maybe
0x00020f41 isn't populated because the floppy read failed (because of
lost irq?).
 
 It is indeed related to floppy. Booting FreeDOS from cd works.
Yeah - this patch also fixes the problem:

--- a/src/floppy.c
+++ b/src/floppy.c
@@ -182,7 +182,8 @@ wait_floppy_irq(void)
         v = GET_BDA(floppy_recalibration_status);
         if (v & FRS_TIMEOUT)
             break;
-        wait_irq();
+        //wait_irq();
+        yield();
     }
 
     v &= ~FRS_TIMEOUT;

I still don't think it should be necessary though.  Maybe Bochs is
dropping floppy irqs when halted?

-Kevin

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Sebastian Herbszt]

      Kevin O'Connor wrote:
  On Sun, Jan 10, 2010 at 11:46:50PM +0100, Sebastian
Herbszt wrote:
  Kevin O'Connor wrote:
 05264161428i[FDD  ] controller reset in software
05445136148i[FDD  ] controller reset in software
05625186768i[FDD  ] controller reset in software
05803824012i[FDD  ] controller reset in software
05985259728i[FDD  ] controller reset in software

SeaBIOS makes a call to wait_irq() in the wait_floppy_irq() function
in src/floppy.c.  My guess is that the floppy irq was lost, and
SeaBIOS went into recovery mode.  It's just a guess, but maybe
0x00020f41 isn't populated because the floppy read failed (because of
lost irq?).
 It is indeed related to floppy. Booting FreeDOS from cd works.
 Yeah - this patch also fixes the problem:

 --- a/src/floppy.c
 +++ b/src/floppy.c
 @@ -182,7 +182,8 @@ wait_floppy_irq(void)
         v = GET_BDA(floppy_recalibration_status);
         if (v & FRS_TIMEOUT)
             break;
 -        wait_irq();
 +        //wait_irq();
 +        yield();
     }

     v &= ~FRS_TIMEOUT;

 I still don't think it should be necessary though.  Maybe Bochs is
 dropping floppy irqs when halted?
The problem occurs on
COMMAND: [e6] [04] [03] [01] [01] [02] [12] [00] [ff]

Debug output with Bochs BIOS

00131978879d[FDD  ] read/write normal data
00131978879d[FDD  ] BEFORE
00131978879d[FDD  ]   drive    = 0
00131978879d[FDD  ]   head     = 1
00131978879d[FDD  ]   cylinder = 3
00131978879d[FDD  ]   sector   = 1
00131978879d[FDD  ]   eot      = 18
00131978879d[FDD  ] read!
00131978879d[FDD  ] floppy_xfer: drive=0, offset=64512, bytes=512, direction=from floppy
00131978879d[FDD  ] io_write: diskette controller data
00132201610d[FDD  ] floppy_xfer: drive=0, offset=65024, bytes=512, direction=from floppy
00132424341d[FDD  ] floppy_xfer: drive=0, offset=65536, bytes=512, direction=from floppy
00132647072d[FDD  ] floppy_xfer: drive=0, offset=66048, bytes=512, direction=from floppy
00132869803d[FDD  ] floppy_xfer: drive=0, offset=66560, bytes=512, direction=from floppy
00133092534d[FDD  ] floppy_xfer: drive=0, offset=67072, bytes=512, direction=from floppy
00133315265d[FDD  ] floppy_xfer: drive=0, offset=67584, bytes=512, direction=from floppy
00133537996d[FDD  ] floppy_xfer: drive=0, offset=68096, bytes=512, direction=from floppy
00133760727d[FDD  ] floppy_xfer: drive=0, offset=68608, bytes=512, direction=from floppy
00133983458d[FDD  ] floppy_xfer: drive=0, offset=69120, bytes=512, direction=from floppy
00134206189d[FDD  ] floppy_xfer: drive=0, offset=69632, bytes=512, direction=from floppy
00134428920d[FDD  ] floppy_xfer: drive=0, offset=70144, bytes=512, direction=from floppy
00134651651d[FDD  ] floppy_xfer: drive=0, offset=70656, bytes=512, direction=from floppy
00134874382d[FDD  ] floppy_xfer: drive=0, offset=71168, bytes=512, direction=from floppy
00135097113d[FDD  ] floppy_xfer: drive=0, offset=71680, bytes=512, direction=from floppy
00135319844d[FDD  ] floppy_xfer: drive=0, offset=72192, bytes=512, direction=from floppy
00135542575d[FDD  ] floppy_xfer: drive=0, offset=72704, bytes=512, direction=from floppy
00135765306d[FDD  ] floppy_xfer: drive=0, offset=73216, bytes=512, direction=from floppy
00135988037d[FDD  ] <<READ DONE>>
00135988037d[FDD  ] AFTER
00135988037d[FDD  ]   drive    = 0
00135988037d[FDD  ]   head     = 0
00135988037d[FDD  ]   cylinder = 4
00135988037d[FDD  ]   sector   = 1
00135988037d[FDD  ] raise_interrupt
00135988037d[FDD  ] RESULT: [00] [00] [00] [04] [00] [01] [02]

18 sectors read and INT raised

Debug output with SeaBIOS

01484895591d[FDD  ] read/write normal data
01484895591d[FDD  ] BEFORE
01484895591d[FDD  ]   drive    = 0
01484895591d[FDD  ]   head     = 1
01484895591d[FDD  ]   cylinder = 3
01484895591d[FDD  ]   sector   = 1
01484895591d[FDD  ]   eot      = 18
01484895591d[FDD  ] read!
01484895591d[FDD  ] floppy_xfer: drive=0, offset=64512, bytes=512, direction=from floppy
01484895591d[FDD  ] io_write: diskette controller data
01484895738i[BIOS ] wait_floppy_irq
01484895804i[BIOS ] loop
01489702451i[BIOS ] loop
01494447511i[BIOS ] loop
01499057671i[BIOS ] loop
01499057689d[FDD  ] floppy_xfer: drive=0, offset=65024, bytes=512, direction=from floppy
01502531391i[BIOS ] loop
01507211711i[BIOS ] loop
01512251591i[BIOS ] loop
01512251609d[FDD  ] floppy_xfer: drive=0, offset=65536, bytes=512, direction=from floppy
01516144951i[BIOS ] loop
01520033811i[BIOS ] loop
01525074171i[BIOS ] loop
01525074189d[FDD  ] floppy_xfer: drive=0, offset=66048, bytes=512, direction=from floppy
01529576831i[BIOS ] loop
01533488331i[BIOS ] loop
01537715651i[BIOS ] loop
01537715669d[FDD  ] floppy_xfer: drive=0, offset=66560, bytes=512, direction=from floppy
01542568211i[BIOS ] loop
01546724771i[BIOS ] loop
01550561771i[BIOS ] loop
01550561789d[FDD  ] floppy_xfer: drive=0, offset=67072, bytes=512, direction=from floppy
01555519611i[BIOS ] loop
01560268911i[BIOS ] loop
01563912291i[BIOS ] loop
01563912309d[FDD  ] floppy_xfer: drive=0, offset=67584, bytes=512, direction=from floppy
01568386751i[BIOS ] loop
01573060051i[BIOS ] loop
01578036231i[BIOS ] loop
01578036249d[FDD  ] floppy_xfer: drive=0, offset=68096, bytes=512, direction=from floppy
01580926271i[BIOS ] loop
01585943311i[BIOS ] loop
01590928071i[BIOS ] loop
01590928089d[FDD  ] floppy_xfer: drive=0, offset=68608, bytes=512, direction=from floppy
01595412451i[BIOS ] loop
01598790831i[BIOS ] loop
01603770011i[BIOS ] loop
01603770029d[FDD  ] floppy_xfer: drive=0, offset=69120, bytes=512, direction=from floppy
01608437351i[BIOS ] loop
01612548071i[BIOS ] loop
01616476651i[BIOS ] loop
01616476669d[FDD  ] floppy_xfer: drive=0, offset=69632, bytes=512, direction=from floppy
01621418291i[BIOS ] loop
01626062131i[BIOS ] loop
01629802031i[BIOS ] loop
01629802049d[FDD  ] floppy_xfer: drive=0, offset=70144, bytes=512, direction=from floppy
01634074311i[BIOS ] loop
01638668771i[BIOS ] loop
01643752491i[BIOS ] loop
01643752509d[FDD  ] floppy_xfer: drive=0, offset=70656, bytes=512, direction=from floppy
01646422786d[FDD  ] read(): during command 0xe6, port 0x03f2 returns 0x1c
01646422788d[FDD  ] write access to port 0x03f2, value=0x0c
01646422788d[FDD  ] io_write: digital output register
01646422788d[FDD  ]   motor on, drive1 = 0
01646422788d[FDD  ]   motor on, drive0 = 0
01646422788d[FDD  ]   dma_and_interrupt_enable=08
01646422788d[FDD  ]   normal_operation=04
01646422788d[FDD  ]   drive_select=00
01646422895i[BIOS ] loop
01646423091i[BIOS ] floppy_motor_counter
01646423116d[FDD  ] read(): during command 0xe6, port 0x03f2 returns 0x0c
01646423120d[FDD  ] write access to port 0x03f2, value=0x08
01646423120d[FDD  ] io_write: digital output register
01646423120d[FDD  ]   motor on, drive1 = 0
01646423120d[FDD  ]   motor on, drive0 = 0
01646423120d[FDD  ]   dma_and_interrupt_enable=08
01646423120d[FDD  ]   normal_operation=00
01646423120d[FDD  ]   drive_select=00
01646423123d[FDD  ] write access to port 0x03f2, value=0x0c
01646423123d[FDD  ] io_write: digital output register
01646423123d[FDD  ]   motor on, drive1 = 0
01646423123d[FDD  ]   motor on, drive0 = 0
01646423123d[FDD  ]   dma_and_interrupt_enable=08
01646423123d[FDD  ]   normal_operation=04
01646423123d[FDD  ]   drive_select=00
01646423125d[FDD  ] read(): during command 0xfe, port 0x03f4 returns 0x00

wait_floppy_irq() gets called, for () loop, 13 sectors read, wait_floppy_irq() returns
with -1.

So we have

01616476651i[BIOS ] loop
01616476669d[FDD  ] floppy_xfer: drive=0, offset=69632, bytes=512, direction=from floppy  
 <- normal transfer
01621418291i[BIOS ] loop
01626062131i[BIOS ] loop
01629802031i[BIOS ] loop
01629802049d[FDD  ] floppy_xfer: drive=0, offset=70144, bytes=512, direction=from floppy  
 <- normal transfer
01634074311i[BIOS ] loop
01638668771i[BIOS ] loop
01643752491i[BIOS ] loop
01643752509d[FDD  ] floppy_xfer: drive=0, offset=70656, bytes=512, direction=from floppy  
 <- normal transfer
01646422786d[FDD  ] read(): during command 0xe6, port 0x03f2 returns 0x1c        <- INT
08h calls floppy_tick()
01646422788d[FDD  ] write access to port 0x03f2, value=0x0c
01646422788d[FDD  ] io_write: digital output register
01646422788d[FDD  ]   motor on, drive1 = 0
01646422788d[FDD  ]   motor on, drive0 = 0
01646422788d[FDD  ]   dma_and_interrupt_enable=08
01646422788d[FDD  ]   normal_operation=04
01646422788d[FDD  ]   drive_select=00
01646422895i[BIOS ] loop                                              <-
wait_floppy_irq() for() loop continues...
01646423091i[BIOS ] floppy_motor_counter                  <- ... and exits

- Sebastian

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Mon, Jan 11, 2010 at 10:28:49PM +0100, Sebastian Herbszt wrote:
  The problem occurs on
 COMMAND: [e6] [04] [03] [01] [01] [02] [12] [00] [ff]
 
 Debug output with Bochs BIOS
[...]
  00131978879d[FDD  ] read!
 00131978879d[FDD  ] floppy_xfer: drive=0, offset=64512, bytes=512, direction=from floppy
[...]
  00135765306d[FDD  ] floppy_xfer: drive=0,
offset=73216, bytes=512, direction=from floppy
 00135988037d[FDD  ] <<READ DONE>>
I'm guessing the first column is a timer - it shows a delta of 4009158
from floppy start to end.

  Debug output with SeaBIOS
 
 01484895591d[FDD  ] read!
[...]
  01484895591d[FDD  ] floppy_xfer: drive=0,
offset=64512, bytes=512, direction=from floppy
[...]
  01643752509d[FDD  ] floppy_xfer: drive=0,
offset=70656, bytes=512, direction=from floppy
 01646422786d[FDD  ] read(): during command 0xe6, port 0x03f2 returns 0x1c
The delta here is 161527195.

Also, if you count the "loop" reports you'll see there are 37 of them
- the same number as FLOPPY_MOTOR_TICKS in src/floppy.c.

So, at first glance it looks like Bochs isn't doing floppy DMA when
the cpu is in the "hlt" state.  This causes SeaBIOS to timeout the
transfer.

-Kevin

[Bochs-developers] Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Stanislav Shwartsman]

      <So, at first glance it looks like Bochs isn't doing floppy DMA when
<the cpu is in the "hlt" state.  This causes SeaBIOS to timeout the
<transfer.

Right, Bochs CPU won't handle floppy DMA when halted.
The CPU is just running busy loop until it finds pending INIT/NMI/SMI or
INTR with EFLAGS.IF set.
Should HRQ to take CPU out of halt state ?
Or just handle the DEV_dma_raise_hlda and stay in halt state ?

Stanislav


-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Tuesday, January 12, 2010 6:13 AM
To: Sebastian Herbszt
Cc: bochs-developers(a)lists.sourceforge.net; seabios(a)seabios.org
Subject: Re: [Bochs-developers] [SeaBIOS] Bochs cvs + SeaBIOS git master +
FreeDOS = slow load + invalid opcode

On Mon, Jan 11, 2010 at 10:28:49PM +0100, Sebastian Herbszt wrote:
  The problem occurs on
 COMMAND: [e6] [04] [03] [01] [01] [02] [12] [00] [ff]
 
 Debug output with Bochs BIOS
[...]
  00131978879d[FDD  ] read!
 00131978879d[FDD  ] floppy_xfer: drive=0, offset=64512, bytes=512,
direction=from
floppy
[...]
  00135765306d[FDD  ] floppy_xfer: drive=0,
offset=73216, bytes=512,
direction=from floppy
  00135988037d[FDD  ] <<READ DONE>>
I'm guessing the first column is a timer - it shows a delta of 4009158
from floppy start to end.

  Debug output with SeaBIOS
 
 01484895591d[FDD  ] read!
[...]
  01484895591d[FDD  ] floppy_xfer: drive=0,
offset=64512, bytes=512,
direction=from floppy
[...]
  01643752509d[FDD  ] floppy_xfer: drive=0,
offset=70656, bytes=512,
direction=from floppy
  01646422786d[FDD  ] read(): during command 0xe6, port
0x03f2 returns 0x1c
The delta here is 161527195.

Also, if you count the "loop" reports you'll see there are 37 of them
- the same number as FLOPPY_MOTOR_TICKS in src/floppy.c.

So, at first glance it looks like Bochs isn't doing floppy DMA when
the cpu is in the "hlt" state.  This causes SeaBIOS to timeout the
transfer.

-Kevin

----------------------------------------------------------------------------
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
bochs-developers mailing list
bochs-developers(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bochs-developers

[Bochs-developers] Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Tue, Jan 12, 2010 at 10:19:58PM +0200, Stanislav Shwartsman wrote:
  <So, at first glance it looks like Bochs isn't
doing floppy DMA when
 <the cpu is in the "hlt" state.  This causes SeaBIOS to timeout the
 <transfer.
 
 Right, Bochs CPU won't handle floppy DMA when halted.
 The CPU is just running busy loop until it finds pending INIT/NMI/SMI or
 INTR with EFLAGS.IF set.
 Should HRQ to take CPU out of halt state ?
 Or just handle the DEV_dma_raise_hlda and stay in halt state ?
Hi Stanislav,

In general, I think DMA should continue even if the cpu is in the halt
state.  I don't know enough about Bochs to say what the implications
of HRQ/DEV_dma_raise_hlda are.

For SeaBIOS, we can add a workaround, but I do think it would be
worthwhile to fix this in Bochs as I imagine other applications have
similar behavior.

-Kevin

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Sat, Jan 09, 2010 at 07:48:51PM +0100, Sebastian Herbszt wrote:
  I have tried SeaBIOS 0.5.1 on Bochs cvs with FreeDOS
1.0 Final boot floppy.
 Loading from floppy was utterly slow and then FreeDOS dumped
FYI.  Hopefully this will be fixed in Bochs, but in the meantime I've
committed the following change to SeaBIOS:

--- a/src/floppy.c
+++ b/src/floppy.c
@@ -182,7 +182,9 @@ wait_floppy_irq(void)
         v = GET_BDA(floppy_recalibration_status);
         if (v & FRS_TIMEOUT)
             break;
-        wait_irq();
+        // Could use wait_irq() here, but that causes issues on
+        // bochs, so use yield() instead.
+        yield();
     }
 
     v &= ~FRS_TIMEOUT;

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Sebastian Herbszt]

      Kevin O'Connor wrote:
  On Sat, Jan 09, 2010 at 07:48:51PM +0100, Sebastian
Herbszt wrote:
  I have tried SeaBIOS 0.5.1 on Bochs cvs with
FreeDOS 1.0 Final boot floppy.
 Loading from floppy was utterly slow and then FreeDOS dumped
 
 FYI.  Hopefully this will be fixed in Bochs, but in the meantime I've
 committed the following change to SeaBIOS:
 
 --- a/src/floppy.c
 +++ b/src/floppy.c
 @@ -182,7 +182,9 @@ wait_floppy_irq(void)
         v = GET_BDA(floppy_recalibration_status);
         if (v & FRS_TIMEOUT)
             break;
 -        wait_irq();
 +        // Could use wait_irq() here, but that causes issues on
 +        // bochs, so use yield() instead.
 +        yield();
     }
 
     v &= ~FRS_TIMEOUT;
Fixed in Bochs 2.4.5.

Sebastian

Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode

[Kevin O'Connor]

      On Sat, May 15, 2010 at 02:17:01PM +0200, Sebastian Herbszt wrote:
  Kevin O'Connor wrote:
 On Sat, Jan 09, 2010 at 07:48:51PM +0100,
Sebastian Herbszt wrote:
 I have tried SeaBIOS 0.5.1 on Bochs cvs with
FreeDOS 1.0 Final boot floppy.
Loading from floppy was utterly slow and then FreeDOS dumped
FYI.  Hopefully this will be fixed in Bochs, but in the meantime I've
committed the following change to SeaBIOS:
 
 Fixed in Bochs 2.4.5.
Thanks!  I'll wait a few months for 2.4.5 to be in wide distribution
and then remove the work around.

-Kevin