Re: ancient portmap segfault
Andi, thanks for the response. The code forks immediately and the new process segfaults immediately. From an inspection of 'strace -f' on a working version, the next call would have been setsid() . (The library call in the code is daemon(0,0)). The original Makefile has an LDFLAG of -N (OMAGIC: make text secion writable, don't page-align the data section No idea why). If I compile with ancient gcc/ld, it works after compiling without -N and segfaults when compiling with -N. If I compile with a recent gcc/ld, it works fine. here's an objump of the segfaulting portmap objdump -x /usr/sbin/portmap /usr/sbin/portmap: file format a.out-i386-linux /usr/sbin/portmap architecture: i386, flags 0x0002: EXEC_P start address 0x Sections: Idx Name Size VMA LMA File off Algn 0 .text 0f7c 0020 2**2 CONTENTS, ALLOC, LOAD, CODE 1 .data 0110 0f7c 0f7c 0f9c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0018 108c 108c 2**2 ALLOC SYMBOL TABLE: no symbols --- and here's the objdump of the test without -N objdump -h a.out a.out: file format a.out-i386-linux Sections: Idx Name Size VMA LMA File off Algn 0 .text 1fe0 1020 1020 0020 2**3 CONTENTS, ALLOC, LOAD, CODE 1 .data 1000 3000 3000 2000 2**3 CONTENTS, ALLOC, LOAD, DATA 2 .bss 4000 4000 2**3 ALLOC -- so maybe the alignment difference is the problem? as I said before, I have things working, only reporting this on the possibility that it's a bug worth investigating. thanks mds Andi Kleen wrote: Mark Studebaker <[EMAIL PROTECTED]> writes: I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap from 1994 that's been running without complaint on kernels for 11 years now consistently segfaults. I upgraded to a version 4 RPM (circa 2002) and that fixed it. If some compatibility was broken on purpose, that's fine, although I couldn't find anything in the kernel docs. I know, I should upgrade everything, but that can break a lot of things too... Thought I'd mention it though in case it's a bug or somebody else has the same problem. It's probably a bug, but your bug report doesn't have enough details to track it down. Do you have a a.out strace and could send an strace log with the segfault and the last tens of system calls before it? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ancient portmap segfault
I upgraded from 2.6.5 to 2.6.11.2 and my ancient (libc4 a.out) /sbin/portmap from 1994 that's been running without complaint on kernels for 11 years now consistently segfaults. I upgraded to a version 4 RPM (circa 2002) and that fixed it. If some compatibility was broken on purpose, that's fine, although I couldn't find anything in the kernel docs. I know, I should upgrade everything, but that can break a lot of things too... Thought I'd mention it though in case it's a bug or somebody else has the same problem. mds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Adding an async I2C interface
is there a way to do this solely in i2c-core without having to add support to all the drivers? Corey Minyard wrote: I have an IPMI interface driver that sits on top of the I2C code. I'd like to get it into the mainstream kernel, but I have a few problems to solve first before I can do that. The I2C code is synchronous and must run from a task context. The IPMI driver has certain operations that occur at panic time, including: * Storing panic information in IPMI's system event log * Extending the watchdog timer so it doesn't go off during panic operations (like kernel coredumps). * Powering the system off I can't really put the IPMI SMB interface into the kernel until I can do those operations. Also, I understand that some vendors put RTC chips onto the I2C bus and this must be accessed outside task context, too. I would really like add asynchronous interface to the I2C bus drivers. I propose: * Adding an async send interface to the busses that does a callback when the operation is complete. * Adding a poll interface to the busses. The I2C core code could call this if a synchronous call is made from task context (much like all the current drivers do right now). For asyncronous operation, the I2C core code would call it from a timer interrupt. If the driver supported interrupts, polling from the timer interrupt would not be necessary. * Add async operations for the user to call, including access to the polling code. * If the driver didn't support an async send, it would work as it does today and the async calls would return ENOSYS. This way, the bus drivers on I2C could be converted on a driver-by-driver basis. The IPMI code could query to see if the driver supported async operations. And the RTC code could use it, too. Is this ok with the I2C community? I would do the base work and convert over a few drivers. Thanks, -Corey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
