search for: bios_tim

On 03/01/16 21:11, H. Peter Anvin via Syslinux wrote: > On 03/01/16 07:21, Patrick Masotta via Syslinux wrote: >> >> At the moment I'm seeing timing issues on TFTP transfers (lwIP depends >> on the new interrupt based timer). I have consistently detected >> >> multiple Requests, double ACKs, etc. All these problems seem to be >> >> sourced on the

...9;m finding most of the problems on lpxelinux.0 > >Now, tickful timekeeping is wasteful, but this is a bootloader, and >functionality is the main concern. The "tickless" version still >depended on the BIOS tick. > Not really, a virtual environment can easily emulate the BIOS_timer at 0x046C but it has problems emulating a "real" timer interrupt to be hooked... That's the real problem. Just testing I have replaced the timing functions #define BIOS_timer 0x046C // Timer ticks typedef uint32_t jiffies_t; extern volatile jiffies_t __jiffies, __ms_timer; stat...

On 02/03/16 22:47, Patrick Masotta via Syslinux wrote: > Not really, a virtual environment can easily emulate the BIOS_timer at 0x046C > but it has problems emulating a "real" timer interrupt to be hooked... > That's the real problem. The timer interrupt works fine in at least KVM, Xen, VMware, and Hyper-V. (I've tested iPXE in all of those virtual environments, and iPXE relies on the timer...

...IGNED MESSAGE----- Hash: SHA1 I have a BIOS that has a broken timer. I think tho that the user tick interrupt 1ch works. I was trying to write four functions in assembler to fix the problem. new_timer check_timer install_timer uninstall_timer The check timer was going to simply get the value of BIOS_timer use int 15h function 86h to sleep 1 tick then compare the two values. If they were different then the timer is OK. the new_timer was simply going to increment a variable. the install function was going to install the new_timer into the vector table and change the value of BIOS_timer to point...

Tim Legge has passed the following message on to me: hpa wrote: > Quinn wrote: > > Now it seems I have found a bug in PXELINUX with regards to etherboot. > > Up until 2.07 pxelinux was responsive to the keyboard. From 2.08 and > > up the keyboard is locked at the boot prompt when pxelinux is loaded > > via etherboot 5.3.14. > > That would not be a PXELINUX bug,

>>> > Not really, a virtual environment can easily emulate the BIOS_timer at 0x046C > but it has problems emulating a "real" timer interrupt to be hooked... > That's the real problem. The timer interrupt works fine in at least KVM, Xen, VMware, and Hyper-V. (I've tested iPXE in all of those virtual environments, and iPXE relies on the tim...