search for: 0xef

...rqrestore+0x3b/0x5c > kernel: [<ffffffff81d32edc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > kernel: [<ffffffff81110ffc>] ? finish_wait+0x1a4/0x1b0 > kernel: [<ffffffff8128f73a>] khugepaged+0x1d4/0x484f > kernel: [<ffffffff8128f566>] ? hugepage_vma_revalidate+0xef/0xef > kernel: [<ffffffff810d5bcc>] ? finish_task_switch+0x3de/0x484 > kernel: [<ffffffff81d32f18>] ? _raw_spin_unlock_irq+0x27/0x45 > kernel: [<ffffffff8111d13f>] ? trace_hardirqs_on_caller+0x3d2/0x492 > kernel: [<ffffffff81111487>] ? prepare_to_wait_event+0...

...rqrestore+0x3b/0x5c > kernel: [<ffffffff81d32edc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > kernel: [<ffffffff81110ffc>] ? finish_wait+0x1a4/0x1b0 > kernel: [<ffffffff8128f73a>] khugepaged+0x1d4/0x484f > kernel: [<ffffffff8128f566>] ? hugepage_vma_revalidate+0xef/0xef > kernel: [<ffffffff810d5bcc>] ? finish_task_switch+0x3de/0x484 > kernel: [<ffffffff81d32f18>] ? _raw_spin_unlock_irq+0x27/0x45 > kernel: [<ffffffff8111d13f>] ? trace_hardirqs_on_caller+0x3d2/0x492 > kernel: [<ffffffff81111487>] ? prepare_to_wait_event+0...

...o specs: 0=x86 , 1=PowerPC , 2=Mac. Shrug.) Regardless whether this is the right number for the purpose of booting some Mac from CD/DVD, it is not what isohybrid.c expects. This program expects to find the UEFI image as second boot image and the Mac image as third boot image. Both with Platform Id 0xef. This composition would be achieved by mkisofs options: -no-emul-boot -boot-load-size 4 -boot-info-table \ -b isolinux/isolinux.bin \ -c isolinux/isolinux.boot \ -eltorito-alt-boot -no-emul-boot -eltorito-platform 0xEF \ -eltorito-boot isolinux/efiboot.img \ -eltorito-alt-boot -no-...

...l says. Where I see some kind of source for potential confusion (at least for some users) is (quoting Thomas, but he is not the source of the potential confusion): "This program expects to find the UEFI image as second boot image and the Mac image as third boot image. Both with Platform Id 0xef." My understanding is that: 0=x86 , 1=PowerPC , 2=Mac are all non-EFI systems, which leaves "0xef" for "every" (U)EFI system, whether such (U)EFI system is EFI 1.0, UEFI 2.x, a Mac-EFI system, or some mix/non-standard firmware. So, users should be more specific (or cl...

...t;] ? wake_up_q+0x89/0xa7 [ 315.153539] [<ffffffff81128b6f>] ? rwsem_wake+0x131/0x15c [ 315.155007] [<ffffffff812922e7>] ? khugepaged+0x4072/0x484f [ 315.156471] [<ffffffff8128e449>] khugepaged+0x1d4/0x484f [ 315.157940] [<ffffffff8128e275>] ? hugepage_vma_revalidate+0xef/0xef [ 315.159402] [<ffffffff810d58d1>] ? finish_task_switch+0x3de/0x484 [ 315.160870] [<ffffffff81d31df8>] ? _raw_spin_unlock_irq+0x27/0x45 [ 315.162341] [<ffffffff8111cde6>] ? trace_hardirqs_on_caller+0x3d2/0x492 [ 315.163814] [<ffffffff8111112e>] ? prepare_to_wait...

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

HI, In http://slint.fr/misc/MacBoot/ you'll find all context information. All files referenced here are stored there. Long story short: once dd-ed on an USB stick the ISO image can boot on a BIOS or EFI machine, but I want it to be able to boot on most x86_64 Macs with an EFI firmware. Unfortunately I get the error message: isohybrid: slint64-14.1.iso: unable to find mac efi image The

...> > kernel: [<ffffffff81d32edc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > > kernel: [<ffffffff81110ffc>] ? finish_wait+0x1a4/0x1b0 > > kernel: [<ffffffff8128f73a>] khugepaged+0x1d4/0x484f > > kernel: [<ffffffff8128f566>] ? hugepage_vma_revalidate+0xef/0xef > > kernel: [<ffffffff810d5bcc>] ? finish_task_switch+0x3de/0x484 > > kernel: [<ffffffff81d32f18>] ? _raw_spin_unlock_irq+0x27/0x45 > > kernel: [<ffffffff8111d13f>] ? trace_hardirqs_on_caller+0x3d2/0x492 > > kernel: [<ffffffff81111487>] ? pre...

...? _raw_spin_unlock_irqrestore+0x3b/0x5c kernel: [<ffffffff81d32edc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c kernel: [<ffffffff81110ffc>] ? finish_wait+0x1a4/0x1b0 kernel: [<ffffffff8128f73a>] khugepaged+0x1d4/0x484f kernel: [<ffffffff8128f566>] ? hugepage_vma_revalidate+0xef/0xef kernel: [<ffffffff810d5bcc>] ? finish_task_switch+0x3de/0x484 kernel: [<ffffffff81d32f18>] ? _raw_spin_unlock_irq+0x27/0x45 kernel: [<ffffffff8111d13f>] ? trace_hardirqs_on_caller+0x3d2/0x492 kernel: [<ffffffff81111487>] ? prepare_to_wait_event+0x3f7/0x3f7 kernel:...

...=Mac. Shrug.) > > Regardless whether this is the right number for the purpose of > booting some Mac from CD/DVD, it is not what isohybrid.c > expects. > This program expects to find the UEFI image as second boot image > and the Mac image as third boot image. Both with Platform Id 0xef. > >From cdrtools.sourceforge.net/private/man/cdrtools-3.01axx/mkisofs.8.html Look at the "-eltorito-platform id" option: [quote] x86 This is the default platform id value and speci- fies entries for the PC platform. If no -eltorito-platform optio...

...] lib/util.c:smb_panic(1400) PANIC: internal error [2004/02/29 08:35:45, 0] lib/util.c:smb_panic(1407) BACKTRACE: 22 stack frames: #0 smbd(smb_panic+0x14e) [0x819055e] #1 smbd [0x81805c7] #2 smbd [0x42029188] #3 smbd(print_queue_status+0x146) [0x81aa706] #4 smbd(_spoolss_enumjobs+0xef) [0x810c56f] #5 smbd [0x80fdc5c] #6 smbd(api_rpcTNP+0x213) [0x812a333] #7 smbd(api_pipe_request+0xcf) [0x812a08f] #8 smbd [0x8124468] #9 smbd [0x812464f] #10 smbd [0x81248ec] #11 smbd [0x8124ac9] #12 smbd(write_to_pipe+0xe4) [0x8124a44] #13 smbd [0x8088011] #14 smbd(re...

...ttp://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf Page 9, Figure 2, Offset 1 of Validation Entry. The ISO image slint64-14.1.iso exposed by Didier, shows in the Validation Entry of the boot catalog: platform Id = 0. The Section Header of the next section shows platform id = 0xef. The next section header bears platform id = 1. This is what isohybrid.c does dislike. It's not incidential but explicitely written in its code. Some background is told in http://mjg59.dreamwidth.org/11285.html More adventures of Matthew Garrett get shown by googling "mjg59 mac boot&qu...

...e got a Junghanns ZapHFC E1 PRI Card (cwain) and this driver writes very much messages into /var/log/messages like the following: --- snip --- Aug 2 17:58:02 asterisk1 kernel: cwain: card 1 RX [ 0x2 0x1 0x1 0x37 0x90 0xc3 ] 6 bytes Aug 2 17:58:02 asterisk1 kernel: cwain: card 1 TX [ 0x2 0x1 0x1 0xef ] Aug 2 17:58:02 asterisk1 kernel: ztx 4 bytes Aug 2 17:58:12 asterisk1 kernel: cwain: card 1 RX [ 0x2 0x1 0x1 0x37 0x90 0xc3 ] 6 bytes Aug 2 17:58:12 asterisk1 kernel: cwain: card 1 TX [ 0x2 0x1 0x1 0xef ] Aug 2 17:58:12 asterisk1 kernel: ztx 4 bytes Aug 2 17:58:22 asterisk1 kernel: cwain: ca...

...to specs say "Platform ID 0 = 80x86 1=Power PC 2=Mac". In the sum this does not match. A bug in mkisofs would be the simplest explanation. > My understanding is that: 0=x86 , 1=PowerPC , 2=Mac > are all non-EFI systems Yes. EFI is younger than this specification. The Platform Id 0xef was obviously introduced later. > So, users should be more specific (or clear) when they refer to a > "Mac" system, as the firmware could be non-EFI, or (some variant of) > (U)EFI. The El Torito Platform Id 2 refers to non-EFI Macs. Possibly with MC68000 processors although...

I posted this on the bugzilla page but I figured that on the mailing list it would get more attention. Please see http://bugzilla.syslinux.org/show_bug.cgi?id=49 for a description of my current issue. -- Thank you, Fernando Reyes GPG BDD75DD7 Mission Accomplish, Inc. http://missionaccomplish.com Email:design at missionaccomplish.com Tel: 7187100008 Cell: 3479275477

...l: [<ffffffff81d32edc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > > > kernel: [<ffffffff81110ffc>] ? finish_wait+0x1a4/0x1b0 > > > kernel: [<ffffffff8128f73a>] khugepaged+0x1d4/0x484f > > > kernel: [<ffffffff8128f566>] ? hugepage_vma_revalidate+0xef/0xef > > > kernel: [<ffffffff810d5bcc>] ? finish_task_switch+0x3de/0x484 > > > kernel: [<ffffffff81d32f18>] ? _raw_spin_unlock_irq+0x27/0x45 > > > kernel: [<ffffffff8111d13f>] ? trace_hardirqs_on_caller+0x3d2/0x492 > > > kernel: [<fffffff...

...l: [<ffffffff81d32edc>] ? _raw_spin_unlock_irqrestore+0x47/0x5c > > > kernel: [<ffffffff81110ffc>] ? finish_wait+0x1a4/0x1b0 > > > kernel: [<ffffffff8128f73a>] khugepaged+0x1d4/0x484f > > > kernel: [<ffffffff8128f566>] ? hugepage_vma_revalidate+0xef/0xef > > > kernel: [<ffffffff810d5bcc>] ? finish_task_switch+0x3de/0x484 > > > kernel: [<ffffffff81d32f18>] ? _raw_spin_unlock_irq+0x27/0x45 > > > kernel: [<ffffffff8111d13f>] ? trace_hardirqs_on_caller+0x3d2/0x492 > > > kernel: [<fffffff...

...0x89, 0xff, 0x90, 0xff, 0x66, 0xff, 0x81, 0xff, 0x6e, 0xff, 0x7f, 0xff, 0x64, 0xff, 0x87, 0xff, 0x5b, 0xff, 0x71, 0xff, 0x4c, 0xff, 0x76, 0xff, 0x58, 0xff, 0x90, 0xff, 0x7a, 0xff, 0xa2, 0xff, 0xa7, 0xff, 0xd3, 0xff, 0xe3, 0xff, 0xf7, 0xff, 0xfb, 0xff, 0x04, 0x00, 0xe2, 0xff, 0xef, 0xff, 0xc2, 0xff, 0xbc, 0xff, 0xcd, 0xff, 0xc9, 0xff, 0xc8, 0xff, 0xbc, 0xff, 0x8f, 0xff, 0x7d, 0xff, 0x51, 0xff, 0x42, 0xff, 0x72, 0xff, 0x5a, 0xff, 0xb9, 0xff, 0x9f, 0xff, 0xea, 0xff, 0xc3, 0xff, 0xea, 0xff, 0xca, 0xff, 0xf9, 0xff, 0xc8, 0xff, 0x20, 0x00, 0xf3, 0xff, 0x26...

...its GPT entry: "Legacy BIOS Bootable". That's the main goal of gptmbr.bin: to be able to boot a GPT scheme in _BIOS_ mode. > So indeed, EFI on hard disk does not need more of an MBR than the magic > number at bytes 510, 511 and an MBR partition entry of type 0xEE or > 0xEF. Well, for booting in UEFI mode, the (0xEE and/or 0xEF and/or any other) "legacy" partition(s) in the so-called "msdos partition table scheme" (aka "protective MBR partition table) in the first sector is/are not really essential but rather a UEFI "feature";...