Bug#683826: glibc pointer
See this glibc bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=10339
Bug#771441: [syslinux] tftpd: don't use AI_ADDRCONFIG to resolve addresses to bind(2)
Okay, let me chime in here. AI_ADDRCONFIG seems to be the Wrong Thing[TM]. AI_PASSIVE seems to be the Right Thing[TM]. Part of the problem is that the fallback code for the case of getaddrinfo() not being there is braindead, and of course the original code used to use gethostbyname() directly. I already have a much better fallback version of getaddrinfo() written which would let us make much better use of the getaddrinfo() interface, Now, what I want to know is why you are specifying the accept-all address explicitly as 0.0.0.0 instead of an empty string. -hpa
Bug#797378: dosemu: DPMI errors in same DOS programs
Please provide an strace of the failing dosemu process: strace -o dosemu.log dosemu ... -hpa
Bug#793921: [syslinux] Bug#793921: tftpd-hpa: IPv6 address cannonization breaks IPv4
On 07/29/2015 01:45 AM, Ron via Syslinux wrote:
Take 2 at bouncing this to the rest of the original recipients through a
different MTA, since mail.zytor.com refused to accept it the first time.
Please re-add Jason Gunthorpe j...@obsidianresearch.com and
793...@bugs.debian.org to the CC for replies.
On Wed, Jul 29, 2015 at 05:34:00PM +0930, Ron wrote:
Hi Jason,
On Tue, Jul 28, 2015 at 03:45:30PM -0600, Jason Gunthorpe wrote:
Package: tftpd-hpa
Version: 5.2+20140608-3
Severity: important
This commit:
tftp: convert IPv6-mapped IPv4 addresses to IPv4
If we receive IPv4 addresses mapped to IPv6, convert them back to IPv4
so that mapping scripts which use \i behave sanely.
Signed-off-by: H. Peter Anvin h...@zytor.com
Totally breaks IPv4 support when tftpd is used with an IPv6 listening socket
(eg when invoked from systemd)
The issue is that the tftpd caller assumes that 'from' and 'myaddr' have the
same AF, however the above patch only cannonizes 'myaddr'. Ultimately this
results in the daemon attempting to use a socket with two address families
and
fails:
recvmsg(0, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(34500),
inet_pton(AF_INET6, :::10.0.0.192, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, msg_iov(1)=[{\0\1pxelinux.0\0netascii\0, 65468}],
msg_controllen=40, {cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=, ...},
msg_flags=0}, 0) = 22
[..]
[pid 3757] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 0
[..]
[pid 3757] bind(0, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(10.0.0.2)}, 16) = 0
[pid 3757] connect(0, {sa_family=AF_INET6, sin6_port=htons(34500),
inet_pton(AF_INET6, :::10.0.0.192, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 EAFNOSUPPORT (Address family not supported by
protocol)
[pid 3757] sendto(3, 27Jul 28 15:32:20 tftpd[3757]: connect: Address
family not supported by protocol, 82, MSG_NOSIGNAL, NULL, 0) = 82
This makes the daemon utterly unusable.
Suggest this tested patch:
--- ../x/tftp-hpa-5.2+20140608/tftpd/recvfrom.c 2014-07-29
20:31:34.0 -0600
+++ tftpd/recvfrom.c2015-07-28 15:42:12.533074001 -0600
@@ -24,6 +24,8 @@
#include machine/param.h /* Needed on some versions of FreeBSD */
#endif
+#include assert.h
+
#if defined(HAVE_RECVMSG) defined(HAVE_MSGHDR_MSG_CONTROL)
#include sys/uio.h
@@ -253,6 +255,8 @@
}
#endif
normalize_ip6_compat(myaddr);
+ normalize_ip6_compat((union sock_addr *)from);
+ assert(from-sa_family == myaddr-sa.sa_family);
}
#endif
}
I have applied the solution of canonicalizing all the addresses into git
for now. I would appreciate if someone could try to test it.
I ended up going for canonicalize everywhere because I found other
places in the code which probably would fail to operate correctly on
IPv6-mapped IPv4 addresses.
-hpa
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672520: syslinux-common: spins on boot, never shows the boot menu
Interesting... I will need to look into this unless you want to... Michael Tokarev m...@tls.msk.ru wrote: On 11.05.2012 22:19, Julien Cristau wrote: Package: syslinux-common Version: 2:4.05+dfsg-3 Severity: grave Tags: d-i Justification: renders package unusable Steps to reproduce: - in a d-i checkout, run make -C build build_netboot - boot the resulting build/dest/netboot/mini.iso With 2:4.05+dfsg-2 I get the expected boot menu. With -3 nothing happens, with the CPU apparently spinning without making progress. This badly affects the d-i dailies. This happens when syslinux is compiled using gcc-4.7. The same code compiled using 4.6 works fine. 4.7 produces non-working pxelinux and regular ldlinux. When pxelinux.0 is run inside qemu-kvm virtual machine, i see the following: ... !PXE entry point found (we hope) at 9BE2:0456 via plan A UNDI code segment at 9BE2 len 08A8 UNDI data segment at 9C6D len 2D28 Getting cached packet 01 02 03 My IP address seems to be C0A8583C 192.168.88.60 ip=192.168.88.60:192.168.88.4:192.168.88.4:255.255.255.0 BOOTIF=01-52-54-00-12-34-56 SYSUUID=---- TFTP prefix: Trying to load: pxelinux.cfg/defaultok _ And the machine stays at this place eating 100% CPU - most of the time. Sometimes qemu-kvm produces the following: KVM internal error. Suberror: 1 emulation failure EAX=00016b40 EBX=00016b40 ECX= EDX=00016b30 ESI=00015e30 EDI=00016b40 EBP=c006fd4c ESP=0002 EIP=0008 EFL=0007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =9c6d 0009c6d0 00809300 CS = 00809b00 SS =9c6d 0009c6d0 00809300 DS =9c6d 0009c6d0 00809300 FS =9c6d 0009c6d0 00809300 GS =9c6d 0009c6d0 00809300 LDT= TR =0008 0580 0067 8b00 GDT= 0009c730 0037 IDT= CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 00 00 00 00 00 00 ff ff ff 80 00 00 00 00 02 00 00 00 51 c2 16 00 00 00 00 00 00 00 00 40 00 00 00 00 02 00 00 00 42 bf 16 00 00 00 00 00 f0 90 FWIW. Thanks, /mjt -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
On 11/24/2010 07:34 AM, Ferenc Wagner wrote: Syslinux certainly used to work partitionless. Maybe this feature was inadvertently lost during the major version change... Peter? It's possible... it's also possible there is something in memory which looks like a partition handover table. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
On 11/21/2010 12:31 PM, Ferenc Wagner wrote: Hi, Does this report ring a bell here? I didn't check, but the image should carry an isohybridized 4.02 version of isolinux. The working (lenny) version is 3.71. Thanks, Feri. This often happens when the BIOS doesn't have USB legacy enabled to do USB keyboard support from the boot environment; another possibility is that the USB keyboard driver and the USB storage driver in the BIOS conflict with each other. Not very specific, I'm afraid... -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604245: [syslinux] Debian bug#604245: Syslinux fails (does not receive key presses on Sony vaio Z12C5E)
On 11/22/2010 09:24 AM, Ferenc Wagner wrote: H. Peter Anvin h...@zytor.com writes: On 11/21/2010 12:31 PM, Ferenc Wagner wrote: Does this report ring a bell here? I didn't check, but the image should carry an isohybridized 4.02 version of isolinux. The working (lenny) version is 3.71. This often happens when the BIOS doesn't have USB legacy enabled to do USB keyboard support from the boot environment; another possibility is that the USB keyboard driver and the USB storage driver in the BIOS conflict with each other. But earlier isolinux works on the very same hardware, that is, it's a regression, which is hard to explain with BIOS issues... Or do I miss something? For a regression... I really need it narrowed down... 3.71 to 4.02 is a huge change. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591934: [syslinux] Bug#592875: pxelinux: incompatible with qemu with kvm enabled
On 08/24/2010 12:15 PM, Vagrant Cascadian wrote: it seems versions of pxelinux 4.00 and later hangs qemu (0.12.x, 0.13.x) when network booting using etherboot or gPXE and qemu's kvm support is enabled. pxelinux 3.86 and earlier do not appear to trigger the problem. i also didn't experience the problem with qemu-kvm (formerly known as kvm). qemu without kvm support enabled also seems to work fine. for more details, please see: http://bugs.debian.org/592875 http://bugs.debian.org/591934 Any way you can do a git bisect on this one? -hpa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#335152: This is an mtools bug, not a syslinux bug
The problem is that mtools (mcopy) returns 0 despite failure. syslinux does handle an error code from mtools if one is provided, thus if mtools is fixed this problem goes away in syslinux. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587150: Info received ([syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation)
I believe this bug has been fixed in checkin c126c28095caf13d164b21f4c7cb25a44af859b0, which is included in the Syslinux 4.00 final release. -hpa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
On 06/27/2010 05:08 AM, Steve McIntyre wrote: It's on my todo list to use it, but really we need to integrate it into genisoimage or similar - see my post to the list a few weeks back. We generate jigdo images on the fly as we make the ISO images, so post-processing isn't really an option. It has been integrated into xorriso; the libisofs/xorriso author and I have agreed on the technical details (after some initial friction.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
On 06/26/2010 01:08 PM, Ferenc Wagner wrote: Holger Wansing li...@wansing-online.de writes: I found, that this not only a problem of the netinst cd, but also hardware dependent. I can boot my old 486 Toshiba Satellite laptop with this cd, but on my IBM Thinkpad T23 the cd produces the isolinux error: Error: no configuration file found. What does it say *before* that? (The T23 does not contain the original optical drive, I changed the drive myself years ago to an NEC ND-7551A. I had no problems in the past years with this drive). I checked the md5sum of the downloaded iso, it was correct. I burned the iso to three different discs (from different vendors), all showed the same problem. So this should not be a problem of a bad disc. I have a netinst iso lying around here from 13.06.2010, it boots fine on my T23. It contains Isolinux 3.86 Is there some regression brought in by the Isolinux 4.0 version? That's possible, 4.0 isn't released just yet. I'm Cc-ing the Syslinux developer list to make them aware of this issue. I guess the CD image you tested had isolinux 4.00pre58 or pre59 on it; now pre60 was also uploaded to unstable, so newer dailies will switch to that at least. Fixes are continuously getting into these prereleases, so it would be very useful if you could test the newest possible in your T23 and report back success or failure. Stable links to tested images under http://cdimage.debian.org/cdimage/daily-builds/daily.old/ may also prove useful. It would obviously be useful to know which exact image this was, so that I have a hope of knowing if I can reproduce the bug. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
On 06/26/2010 05:13 PM, Holger Wansing wrote: 3. Next day. Next try. I downloaded a new iso from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/ (btw: default procedure for me is: go to development site of debian-installer http://www.debian.org/devel/debian-installer/ and then click on daily build for i386. Then I come to http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/. There I find netinst and businesscard images, which I use for testing from time to time.) On that URL I read at the time now: This build finished at Sat Jun 26 16:49:47 UTC 2010. I downloaded the netinst image with this md5sum: 7f9b92a8f41da4ef60054aacb83845a6 debian-testing-i386-netinst.iso - I checked the md5sum of this iso: it matches ok. - I booted this iso via qemu: it booted correctly. - I burned this iso to cd and tried to boot it on my Thinkpad T23: the error is still there. Output on screen is EXACTLY the same as under 2. You can also download this iso from my pc if you want. Feel free to ask. OK, got this image. Will try it in a bit. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
On 06/26/2010 06:49 PM, H. Peter Anvin wrote: OK, got this image. Will try it in a bit. I have been unable to reproduce this on any hardware available to me. Anyone who happens to own a T23 and lives in the SF Bay Area? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587150: [syslinux] Bug#587150: #587150: d-i netinst cd doesn't boot, isolinux error: further investigation
By the way, is there any reason Debian isn't using isohybrid? -hpa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/24/2010 12:27 AM, Josh Triplett wrote: The following patch fixes GRUB; with this patch, I can reserve memory (such as with drivemap), boot 2.6.35-rc3 successfully, and it detects all of my RAM. Congratulations! You have just committed the single most common BIOS implementation bug. (Sorry for the sarcasm, but this seems to be a bug that almost everyone who tries to implement BIOS makes at one point or another... even the original IBM BIOS had it in at least one place.) You *must not* use lret $2 to return to the caller, because the INT instruction will have cleared IF after pushing the registers to the stack. You have to restore the original IF, which lret $2 will not do. The best way to do this is to clobber the low byte of the flags register on the stack. Since CF is bit 0, and the low byte only contains arithmetic flags anyway, you can simply overwrite the low byte with 0 for CF=0 and 1 for CF=1. This will zero SF, ZF, AF and PF as side effect, which is OK for almost all uses (including e820/e801/88.) If you don't already have a pointer to the stack, you have to make one, since it is not possible in 16-bit mode to access the stack directly. One option is to replace each iret with a jump to the following common code: carry_cf_iret: pushw %bp movw%sp, %bp setc6(%bp) /* Set CF on stack based on EFLAGS */ popw%bp iret I don't see any trivial way Linux could work around this bug. If the e820 call left CF=0 on entry, then the error case would get incorrectly treated as a valid e820 entry (albeit a final one, since bx=0). More importantly, it makes the error direction the wrong one. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/24/2010 12:01 PM, Josh Triplett wrote: On Thu, Jun 24, 2010 at 07:18:34AM -0700, H. Peter Anvin wrote: On 06/24/2010 12:27 AM, Josh Triplett wrote: The following patch fixes GRUB; with this patch, I can reserve memory (such as with drivemap), boot 2.6.35-rc3 successfully, and it detects all of my RAM. Congratulations! You have just committed the single most common BIOS implementation bug. (Sorry for the sarcasm, but this seems to be a bug that almost everyone who tries to implement BIOS makes at one point or another... even the original IBM BIOS had it in at least one place.) And a rather large number of sample interrupt code found on the web, including the e820 hook from the version of gPXE/Etherboot that I used as an example. :) Given that I just tested against Linux, which very carefully works around that particular BIOS bug, I didn't run into any issue. So, how high does GRUB's bug (stc ; iret/clc ; iret) rank on the list of common BIOS implementation bugs? Less common, since that one is apparently more obvious to people (you only have to think one step ahead instead of two steps ahead.) There is a reason Linux works around this and similar bugs... it truly is extremely common (and does cause real problems in real code.) -hpa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/21/2010 10:22 PM, Josh Triplett wrote: How might I diagnose this further? What might cause Linux to refuse to use the e820 and e801 results provided by GRUB, but accept the ones provided by the BIOS? This is interesting... you apparently have a ACPI 3-style e820 BIOS as evidenced by the [1] markers, but Grub presents it as legacy style. Now, the kernel shouldn't care, but this at least gives a clue. Something that might be worthwhile is to add printf's to the kernel's e820-parsing routine (in arch/x86/boot/e820.c) and figure out why it doesn't like the output. It's a bit strange that meminfo would produce sensible-looking output (well, legal, at least; presenting a two-byte range is rather beyond crazy, and so forth) and the kernel wouldn't accept it, as the code is intentionally very similar. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/12/2010 06:58 AM, Ben Hutchings wrote: Josh Triplett reported this problem with memory sizing: A kernel built from c549e71d073a6e9a4847497344db28a784061455 finds 64MB of RAM; a kernel built from c549e71d073a6e9a4847497344db28a784061455^ successfully finds all 4GB of RAM. Also note that newer upstream kernels, including v2.6.35-rc3, fail as well. Since later kernels revert part of the above commit, the issue must lie with the parts of the commit not reverted. And, again, I can reproduce this using the stock upstream GRUB2 1.98 release built from source, by booting it from a USB key, and then booting the disk MBR via: set root=(hd1) drivemap (hd1) (hd0) chainloader +1 boot Nothing special about drivemap here; anything that uses grub's mmap module to reserve memory via e820 (GRUB_MACHINE_MEMORY_RESERVED) will cause grub to hook e820 and trigger this bug. However, in stock grub, only drivemap does this. It's kind of hard to know what is involved, since clearly it relates to Grub2, which -- how do I say this politely -- seems to excel at doing things in the most inferior way possible. This is a great example of that. The most likely reason it fails is because Grub2 uses ACPI 3-style reads of the board memory map, gets wrong results for the same reasons the kernel do, and then pass then downstream to the kernel. As such, there is absolutely nothing the kernel can do about it. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/12/2010 11:55 AM, Josh Triplett wrote: It's kind of hard to know what is involved, since clearly it relates to Grub2, which -- how do I say this politely -- seems to excel at doing things in the most inferior way possible. This is a great example of that. The most likely reason it fails is because Grub2 uses ACPI 3-style reads of the board memory map, gets wrong results for the same reasons the kernel do, and then pass then downstream to the kernel. As such, there is absolutely nothing the kernel can do about it. grub2 doesn't do ACPI 3 reads; it always asks for 20 bytes, not 24. Also, note that it works with older Linux kernels (before the commit in question) and fails with newer ones. That doesn't rule out the possibility of a grub bug instead of a Linux bug, but since older Linux somehow coped with the situation, it seems like a regression that newer Linux cannot cope. It's a regression of sorts, sure; but the new Linux code also boots on real hardware which it didn't boot before. Since this requires Grub2 plus specific hardware, it is hard for me to track down what the problem might be, but a good step on the way might be to use the Grub2 boot procedure (with the drive remapping) to chainboot Syslinux, and run meminfo.c32 which is a memory report debugging tool; it might be able to give some answers at least. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/12/2010 03:26 PM, Josh Triplett wrote: Done. I've attached the output of meminfo with the e820 hook as meminfo-grub-hooked.jpg, and without the e820 hook as meminfo-unhooked.jpg. Everything looks identical except for the region GRUB hooked right below the first reserved region; the unhooked version has available memory from 0-0x9cbf0, and the hooked version has available memory from 0-0x9cba0, then reserved from 0x9cba0-0x9cbec, then 4 bytes of available memory, and then the same reserved region as before. The new reserved area that Grub hooks is located inside a FBM (DOS RAM) reserved area, so Grub is somehow using memory that someone else has already reserved! The normal thing is to reserve something in FBM and not in INT 15h if it is to be reserved only until the protected-mode operating system starts, but in this case Grub puts something in there which is a real-mode hook. It *will* have overwritten something at this point, the question is just what (and I have no idea how to find that out.) Note that the unmodified entry conditions (unhooked) has FBM quite a bit lower than the reserved area. Something else that really confuses me is that although the memory map has changed, the INT 15h vector itself is still the same, so I'm really confused about how the actual hooking happens in the first place... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/12/2010 03:26 PM, Josh Triplett wrote: Everything looks identical except for the region GRUB hooked right below the first reserved region; the unhooked version has available memory from 0-0x9cbf0, and the hooked version has available memory from 0-0x9cba0, then reserved from 0x9cba0-0x9cbec, then 4 bytes of available memory, and then the same reserved region as before. Actually... are both these done by chainloading Grub (with and without mapping), or is the unhooked done without chainloading Grub at all? To me it looks like something is chaining INT 15h even in the unchained case... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
On 06/12/2010 05:07 PM, Josh Triplett wrote: On Sat, Jun 12, 2010 at 04:02:44PM -0700, H. Peter Anvin wrote: On 06/12/2010 03:26 PM, Josh Triplett wrote: Everything looks identical except for the region GRUB hooked right below the first reserved region; the unhooked version has available memory from 0-0x9cbf0, and the hooked version has available memory from 0-0x9cba0, then reserved from 0x9cba0-0x9cbec, then 4 bytes of available memory, and then the same reserved region as before. Actually... are both these done by chainloading Grub (with and without mapping), or is the unhooked done without chainloading Grub at all? To me it looks like something is chaining INT 15h even in the unchained case... The unhooked case still chainloaded from GRUB, just without calling drivemap and thus without hooking anything. I can test without chainloading from GRUB, though to the best of my knowledge GRUB doesn't hook int 15 unless it needs to intercept e820 (and e801 and 88). - Josh Triplett Well *something* is... and it might not be Grub but one of the expansion ROMs. If so, the problem is probably Grub stepping on the expansion ROM by not honoring FBM. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504495: [syslinux] Domain-specific HLT when idle
Geert Stappers wrote: Probably should 'halt_on_idle' be default and is a 'no_halt_on_idle' or a 'active_poll' needed. 'active_poll' has to be mentioned in de section 'serial port' of the docs. I really don't like this. Chicken flags are hopeless; one way the feature doesn't get used, the other way it still has all the downsides. That doesn't mean that there isn't a possibility of going to a low-power mode after a timeout or something like that. This isn't just a virtualization issue, either; modern hardware can easily burn *massively* more power without idle support. However, doing it at the cost of reliability simply isn't an option... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496869: Regression identified; patch in upstream
I just pushed a patch for this as part of Syslinux-3.72-pre1. The problem is triggered by a zero-length configuration file on the CD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: Do AMD K7 family CPUs support long noops?
Graham wrote:
Hello,
I am wondering whether anyone has looked into which AMD CPUs support
these instructions. I would think that installing a 486 kernel on an
AthlonXP, for example, would be quite sub-optimal.
i.e. can you safely enable X86_P6_NOP for other CPUs, such as AMD
K7/K8, VIA C3/C7, or Efficeon? If not, would it be more sensible to
avoid using these instructions?
It appears that at least some VIA C3 CPUs do not support these opcodes:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463606#45
Attached is a C program which tests this.
#include stdio.h
#include signal.h
#include setjmp.h
static sigjmp_buf out;
void sigill(int signal)
{
siglongjmp(out, 1);
}
int main(void)
{
int died;
signal(SIGILL, sigill);
died = sigsetjmp(out, 1);
if (!died)
asm volatile(nopl 0(%eax));
printf(Long NOPs supported: %s\n, died ? no : yes);
return died;
}
Bug#464962: immediate crash on boot on TM5800
maximilian attems wrote: sure, ack. so i'll circumvent bugzilla and add the new x86 maintainers on cc to let them know about the 2.6.24 and 2.6.25-rc1 boot error on shiny fujitsu p700 lifebook, with a Crusoe processor. http://bugs.debian.org/464962 686 config attached. INT 6 is #UD, undefined instruction. If you could send me a copy of your vmlinux file (not bzImage), it would speed things up. I happen to have an old TM5800-based machine sitting around, so I can probably reproduce it. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: immediate crash on boot on TM5800
Thought some more about this, and since this probably means gcc will generate this for userspace code as well nowadays, tm5800 should probably be downgraded to a 586-class machine. Hence the Linux policy of promoting it to a 686-class machine for having CMOV is actually incorrect, it doesn't have all the userspace-visible features of a 686-class machine, lacking long NOP. -hpa diff --git a/arch/x86/kernel/cpu/transmeta.c b/arch/x86/kernel/cpu/transmeta.c index 200fb3f..e8b422c 100644 --- a/arch/x86/kernel/cpu/transmeta.c +++ b/arch/x86/kernel/cpu/transmeta.c @@ -76,13 +76,6 @@ static void __cpuinit init_transmeta(struct cpuinfo_x86 *c) /* All Transmeta CPUs have a constant TSC */ set_bit(X86_FEATURE_CONSTANT_TSC, c-x86_capability); - /* If we can run i686 user-space code, call us an i686 */ -#define USER686 ((1 X86_FEATURE_TSC)|\ -(1 X86_FEATURE_CX8)|\ -(1 X86_FEATURE_CMOV)) -if (c-x86 == 5 (c-x86_capability[0] USER686) == USER686) - c-x86 = 6; - #ifdef CONFIG_SYSCTL /* randomize_va_space slows us down enormously; it probably triggers retranslation of x86-native bytecode */
Bug#464962: immediate crash on boot on TM5800
maximilian attems wrote: On Tue, Feb 12, 2008 at 01:14:04PM -0800, H. Peter Anvin wrote: Are you sure that build matches the bug report? urrgs right sorry, the posted vmlinux is a newer 2.6.24-git22 and not Version: 2.6.24-3 The EIP given falls inside the .data segment of that kernel, specifically inside the symbol init_task. -hpa will rebuild aboves. Okay, the faulting instruction is the following: c0383360: 0f 1f 40 00 nopl 0x0(%eax) The Crusoe code morphing software apparently doesn't recognize these long noops, and (presumably) the rest of the hinting NOOP group. gcc didn't use to generate them, and Crusoe/Efficeon generally do not benefit from code alignment anyway. I suspect the best thing to do is to use either a 586 kernel or build a dedicated Crusoe kernel without code alignment. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: immediate crash on boot on TM5800
Bastian Blank wrote: On Tue, Feb 12, 2008 at 01:42:50PM -0800, H. Peter Anvin wrote: The Crusoe code morphing software apparently doesn't recognize these long noops, and (presumably) the rest of the hinting NOOP group. gcc didn't use to generate them, and Crusoe/Efficeon generally do not benefit from code alignment anyway. I suspect the best thing to do is to use either a 586 kernel or build a dedicated Crusoe kernel without code alignment. Crusoe is explicitely marked as 586 with TSC in the kernel config. Yes, but the kernel in question wasn't compiled as a Crusoe kernel, but a generic 686 kernel. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: immediate crash on boot on TM5800
Bastian Blank wrote: On Tue, Feb 12, 2008 at 01:42:50PM -0800, H. Peter Anvin wrote: Okay, the faulting instruction is the following: c0383360: 0f 1f 40 00 nopl 0x0(%eax) include/asm-x86/nops.h: | /* P6 nops */ | /* uses eax dependencies (Intel-recommended choice) */ [...] | #define P6_NOP4 .byte 0x0f,0x1f,0x40,0\n Yes, which requires a 686-class machine; gcc is also free to use these for -m686, so there is a userspace-visible difference, and thus the hack to call Crusoe a 686-class machine is not correct. Unfortunately there is no CPUID flag for these, only the CPU level. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: immediate crash on boot on TM5800
http://www.kernel.org/pub/linux/kernel/people/hpa/0001-x86-do-not-promote-TM3x00-TM5x00-to-i686-class.patch -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: immediate crash on boot on TM5800
maximilian attems wrote: On Tue, Feb 12, 2008 at 12:32:27PM -0800, H. Peter Anvin wrote: INT 6 is #UD, undefined instruction. If you could send me a copy of your vmlinux file (not bzImage), it would speed things up. cp -l src/linux-2.6-2.6.24/debian/build/build_i386_none_686/vmlinux ~/public_html/ http://charm.itp.tuwien.ac.at/~mattems/ Are you sure that build matches the bug report? The EIP given falls inside the .data segment of that kernel, specifically inside the symbol init_task. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: immediate crash on boot on TM5800
maximilian attems wrote: On Tue, Feb 12, 2008 at 01:14:04PM -0800, H. Peter Anvin wrote: Are you sure that build matches the bug report? urrgs right sorry, the posted vmlinux is a newer 2.6.24-git22 and not Version: 2.6.24-3 The EIP given falls inside the .data segment of that kernel, specifically inside the symbol init_task. -hpa will rebuild aboves. Don't worry about it, already have reproduced it. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409271: [klibc] Bug#409271: initramfs-tools: NFSv4 not supported for root fs
maximilian attems wrote: [ adding klibc ml to cc ] On Thu, Feb 01, 2007 at 09:29:52AM -0600, John Goerzen wrote: It appears to be largely undocumented, but a review of /usr/share/initramfs/scripts/nfs shows that this package supports NFSv2 and v3 only. I don't know why v4 isn't supported. yup, this needs nfs v4 support in klibc nfsmount. would be could to get that soon postetch, but someone will have to implement it ;-) NFSv4 and NFS over IPv6 would both be Very Good Things to have in klibc, partially because it might actually satisfy Linus' requirement of must add new features above what the kernel already has. I'm not an NFS expert, but I'd be willing to work with someone who is as necessary to deal with the NFSv4 mount protocol. I understand NFSv4 gets rid of mountd, so it should be simpler? -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374290: FTBFS on sarge
Norbert Tretkowski wrote: Package: klibc Severity: wishlist Tags: patch I get this error when building klibc 1.3.35-1 on sarge: usr/klibc/SYSCALLS.def:18:20: missing terminating ' character Already fixed; current upstream is 1.3.40. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344446: [klibc] Don't hardcode paths in klcc
Martin Michlmayr wrote: * H. Peter Anvin [EMAIL PROTECTED] [2006-01-25 20:46]: In this case, though, it's probably required, since otherwise you could end up with some very strange results when cross-compiling. I'm not sure what the ideal answer is, but I think this is wrong. klcc is a installation-specific, generated Perl script, so portability is not an issue. It would be nice if people could specify whether they want this during build time. Perhaps you could clarify why you *wouldn't*. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344446: [klibc] Don't hardcode paths in klcc
Martin Michlmayr wrote: Stop makeklcc.pl from hardcoding paths of cc, ld and strip in the klcc script it generates. Using hardcoded paths is generally a bad idea. First, the whole idea of $PATH is that you don't need to hardcode paths. Second, klcc is a Perl script but my hardcoding the paths you make it less portable. In this case, though, it's probably required, since otherwise you could end up with some very strange results when cross-compiling. I'm not sure what the ideal answer is, but I think this is wrong. klcc is a installation-specific, generated Perl script, so portability is not an issue. -hpa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
