Bochs cvs + SeaBIOS git master + FreeDOS = slow load + invalid opcode
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
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
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
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
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
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
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
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
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
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
<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:kevin@koconnor.net] Sent: Tuesday, January 12, 2010 6:13 AM To: Sebastian Herbszt Cc: bochs-developers@lists.sourceforge.net; seabios@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bochs-developers
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
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;
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
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
participants (3)
-
Kevin O'Connor -
Sebastian Herbszt -
Stanislav Shwartsman