similar to: reboot from com32

On Sun, Sep 20, 2015 at 8:33 AM, syslinux-bot for Gene Cumm <gene.cumm at gmail.com> wrote: > Commit-ID: e0ac1d2fdf7d7c58457f3796a12561cce95ca29f > Gitweb: http://www.syslinux.org/commit/e0ac1d2fdf7d7c58457f3796a12561cce95ca29f > Author: Gene Cumm <gene.cumm at gmail.com> > AuthorDate: Sun, 20 Sep 2015 08:30:55 -0400 > Committer: Gene Cumm <gene.cumm at

Hi! It's indeed better to open a new thread for this. So, here's my test session: $ qemu -fda extlinux.144 -s -S Then in another terminal: $ gdb extlinux.elf (gdb) set architecture i8086 (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000fff0 in ?? () at localboot.inc:68 68 jmp kaboom ; If we returned, oh boy... How does "jmp kaboom" get

Gene Cumm said on Wed, Oct 28, 2015 at 05:58:59AM -0400: >> Ok, I tried to modify mk/devel.mk to put: >> GCCWARN += -Wno-clobbered -DCORE_DEBUG=1 -DDEBUG_MALLOC -DDEBUG_THREAD >> And removing the -DDYNAMIC_DEBUG but now syslinux doesn't want to build: > >MALLOC and THREAD are two debugs you probably don't want. Ok I can drop them, but that doesn't change the

On Tue, Oct 27, 2015 at 10:15 PM, Bruno Cornec via Syslinux <syslinux at zytor.com> wrote: > Bruno Cornec via Syslinux said on Wed, Oct 28, 2015 at 01:45:22AM +0100: >> >> Is there a way to increase the debug level of syslinux.efi in order to >> check what it tries to do and diagnose more precisely what happens ? > > > Ok, I tried to modify mk/devel.mk to put:

On Thu, Oct 08, 2015 at 01:24:26AM +0200, Geert Stappers via Syslinux wrote: > On Wed, Oct 07, 2015 at 05:58:51PM -0500, Clements, James wrote: > > > Correct me if I am wrong but if I understand correctly, syslinux.efi is > > what drives the request for ldlinux.e64. Is there a way we can enable > > some debug somehow to see why the request for ldlinux.e64 includes >

It's out of date. We're using MCJIT on ARM to implement an OpenCL on CPU implementation. It works! On Tue, Nov 25, 2014 at 3:46 PM, Yichao Yu <yyc1992 at gmail.com> wrote: > On Tue, Nov 25, 2014 at 4:22 PM, Yichao Yu <yyc1992 at gmail.com> wrote: >> Hi, >> >> I am sorry if this question have been brought up too many times but >> the document does

Hi 2 all ! I want to implement a new option into version 2.11 of syslinux: The feature should do the following: Ask the user if he really wants to boot from dvd. If no keyboard key is pressed in an amount of time it should boot from the next device configured in BIOS (INT 18h). I looked up the isolinux.asm and tried 2 entry points for my code: 1. entry point: label

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around

> On Apr 25, 2020, at 12:10 PM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: >> shift_ist is gross. What's it for? If it's not needed, I'd rather >> not use it, and I eventually want to get rid of it for #DB as well. > > The #VC handler needs to be able to nest, there is no way around

Hi Fraser, it looks to me like you are smashing the stack. > define void @main() nounwind { > allocas: > %0 = alloca { i32, [0 x i32] }, align 8 ^ this allocates 4 bytes on the stack. > %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1 ^ this gets a pointer to the byte after the 4 allocated bytes. > %3 = bitcast [0 x i32]* %2 to i8* > call void

So far I tested PXELINUX from 4.10-pre12, 4.10-pre9 and 4.10-pre6. The first two take a long time with a TFTP file not found and eventually find my file but error out (presumably to kaboom). The last takes a long time, does a lot of retransmitted packets (didn't watch the first two), then eventually loads the file but continues this behavior for TFTP and HTTP transfers. This is on VMware

Hi Duncan, Duncan Sands wrote: > > Hi Fraser, it looks to me like you are smashing the stack. > >> define void @main() nounwind { >> allocas: >> %0 = alloca { i32, [0 x i32] }, align 8 > > ^ this allocates 4 bytes on the stack. > >> %2 = getelementptr inbounds { i32, [0 x i32] }* %0, i64 0, i32 1 > > ^ this gets a pointer to the byte

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote: > Hi list, > > in our LLVM-based-project we are writing a backend for our > processor. The > architecture is a quite straight-forward RISC, but it does not have > hardware interlocks, i.e. data hazards involving memory access must be > resolved by the compiler, either by scheduling unrelated > instructions or >

On Wed, Oct 07, 2015 at 05:58:51PM -0500, Clements, James wrote: > James Clement > > Geert Stappers > > > On Wed, Oct 07, 2015 at 05:06:41PM -0500, Clements, James wrote: > > > > The screen displays the following: > > > > > > > > PXE Network Boot using IPv4 > > > > .... > > > > Station IP address is 192.168.205.50

I am sending a patch that makes the debugging output of PXELINUX slightly more concise, without (intentionally) affecting its completeness at all. Additionally, I am proposing that the debugging output of PXELINUX -- specifically the messages that appear after the copyright statement, but before the menu is loaded -- only be shown in response to keyboard input (such as holding Shift or Alt, or

Hi Fraser, Is there anything preventing you from using a pointer for the second part of the structure and allocating memory for it later? Thanks, Gavin On Mar 12, 2012, at 10:35 AM, Fraser Cormack wrote: > > Hi Duncan, > > > Duncan Sands wrote: >> >> Hi Fraser, it looks to me like you are smashing the stack. >> >>> define void @main() nounwind {

On Wed, May 6, 2015 at 5:30 PM, Daniel Dilts <diltsman at gmail.com> wrote: > > > On Wed, May 6, 2015 at 12:51 AM, Will Newton <will.newton at gmail.com> wrote: >> >> On Wed, May 6, 2015 at 6:22 AM, Chris Lattner <clattner at apple.com> wrote: >> > On May 5, 2015, at 6:47 PM, Daniel Dilts <diltsman at gmail.com> wrote: >> > >>

This just started happening this evening. a little history: way back last year, or thereabouts, I posted about a weird problem I was having. over the course of 2 or 3 days I figured out how to fix it, but not what the cause was. the fix amounts to navigating to my user's .local/share/mime directory and removing the file named "globs". So, back in the present: this evening that

Hi Andy, Thanks for checking! I do see an issue on Tesla as well (at least G92, and I believe someone else reported on a GT215 or GT218). However I haven't confirmed that it's the identical issue to what I see on Fermi with quite as much certainty as what I've checked on a GF108. (For the G92, the texture buffer object test fails in the same way it does on Fermi, but there could be