Question about signal handling
Hopefully I'm not asking a really stupid question here, but...
When setting up a signal handler, using sa_handler, there is a
quasi-documented 2nd parameter of 'struct context ctx' passed to the signal
handler. This seems to work on 2.2.12, 2.2.18, and 2.4.5-ac2. According to
various documents, when using sa_siginfo (and setting SA_SIGINFO), the third
parameter to the handler is defined as a 'void *', but actually passes a
'ucontext_t' data type. Which is not defined in any kernel code, except for
the sparc64 branch. Casting this to a 'struct context' or a 'struct context
*' doesn't seem to achieve the desired results on any of the three kernels I
tested.
Google searches indicate different things. POSIX 1 compliance says it
should be a 'ucontext_t *'
(www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html+sigcontext+siginf
o_t+sigaction=en=lang_en) (I realize that's the Open standard, but the
comments at the bottom talk about POSIX compliance). Other searches say it
returns as a 'struct context *'.
I tried following the code through the kernel, but I'm not familiar enough
with yet to really understand how it's getting scheduled, and exactly which
parameters are getting passed back.
What is the correct behavior supposed to be? And if using sa_siginfo, how
does one get at the context parameters to find the EIP the fault occurred
at?
Here's a sample bit of code I used for testing. Leaving #define SIGACTION
demonstrates the third parameter not (seemingly) being passed as a context
pointer, #undef demonstrates the sa_handler 2 paramter handler, which
returns a correct context.
#include
#include
#include
#include
#define SIGACTION
#ifdef SIGACTION
void fSegvHandler (int sigNo, siginfo_t *si, void *p)
{
struct sigcontext *context = (struct sigcontext *) p;
#else
void fSegvHandler (int sigNo, void *p)
{
struct sigcontext *context = (struct sigcontext *)
#endif
printf ("\nContext: %08X\n",context);
fflush (stdout);
printf ("gs: %04X\tfs: %04X\tes: %04X\tds: %04X\n"
"edi: %08X\tesi: %08X\tebp: %04X\tesp: %04X\n"
"ebx: %08X\tedx: %08X\tecx: %08X\teax: %08X\n"
"trap: %d\terr: %d\teip: %08X\tcs: %04X\n"
"flag: %08X\tSP: %08X\tss: %04X\tcr2: %08X\n",
context->gs, context->fs, context->es, context->ds,
context->edi, context->esi, context->ebp, context->esp,
context->ebx, context->edx, context->ecx, context->eax,
context->trapno, context->err, context->eip, context->cs,
context->eflags, context->esp_at_signal, context->ss,
context->cr2);
fflush (stdout);
exit (0);
}
int main (int argc, char **argv)
{
struct sigaction sSegvHdl;
sigemptyset (_mask);
sigaddset (_mask, SIGSEGV);
#ifdef SIGACTION
sSegvHdl.sa_flags = SA_SIGINFO | SA_ONESHOT;
sSegvHdl.sa_sigaction = fSegvHandler;
#else
sSegvHdl.sa_flags = SA_ONESHOT;
sSegvHdl.sa_handler = fSegvHandler;
#endif
if (sigaction (SIGSEGV, , NULL))
perror ("sigaction");
else
*(char *) 0x0 = 0x01;
}
-- John
-
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: obsolete code must die
As an end user who uses cheap laptops for firewalls, I'm pretty much against this. I've got 2.2.18, 2.4.4-ac8, and 2.4.4-ac12 installed as firewall machines on 486 laptops. Why should we (the collective Linux world, not me personnally, since I'm not a kernel developer) limit the class of machines people can run? In fact, this seems to be one of the appealing features of Linux, that it runs on any x86 hardware class with a MMU. It allows people to get involved in Linux without making a committment to buying a new PC until they know they like it, or buying a new HD to do a dual boot install to experiment. Laptops are a particular issue here, because many of the laptops people can obtain inexpensively ARE 386/486 class machines. I'm all for cleaning up the kernel code, but I think it would be better served by documentation, not by limiting the hardware that can be run. I can't speak authoritively on how much of the kernel code is processor specific, since GCC takes care of most of that. I do know there are sections that are affected by the processor selection, but I can't believe that it's a significantly large enough portion to justify ripping it out in the name of cleaning it up. I do agree with deleting obsolete code, but not obsoleting hardware so we CAN delete code. --John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel > Sent: Wednesday, June 13, 2001 20:44 PM > To: Linux kernel > Subject: obsolete code must die > > > Anyone concerned about the current size of the kernel source > code? I am, and > I propose to start cleaning house on the x86 platform. I mean > it's all very > well and good to keep adding features, but stuff needs to go if kernel > development is to move forward. Before listing the gunk I want to get rid > of, here's my justification for doing so: > -- Getting rid of old code can help simplify the kernel. This means less > chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. > -- If someone really needs support for this junk, they will > always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? > > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting > devices for > these buses. > > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. > > MFM/RLL/XT/ESDI hard drive support > Does anyone still *have* an RLL drive that works? At the very > least get rid > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. > > a.out > Who needs it anymore. I love ELF. > > I really think doing a clean up is worthwhile. Maybe while > looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or > suggestions? > I'd love to start a good discussion about this going so please > send me your > 2 cents. > > Daniel > > - > 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/ - 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: obsolete code must die
As an end user who uses cheap laptops for firewalls, I'm pretty much against this. I've got 2.2.18, 2.4.4-ac8, and 2.4.4-ac12 installed as firewall machines on 486 laptops. Why should we (the collective Linux world, not me personnally, since I'm not a kernel developer) limit the class of machines people can run? In fact, this seems to be one of the appealing features of Linux, that it runs on any x86 hardware class with a MMU. It allows people to get involved in Linux without making a committment to buying a new PC until they know they like it, or buying a new HD to do a dual boot install to experiment. Laptops are a particular issue here, because many of the laptops people can obtain inexpensively ARE 386/486 class machines. I'm all for cleaning up the kernel code, but I think it would be better served by documentation, not by limiting the hardware that can be run. I can't speak authoritively on how much of the kernel code is processor specific, since GCC takes care of most of that. I do know there are sections that are affected by the processor selection, but I can't believe that it's a significantly large enough portion to justify ripping it out in the name of cleaning it up. I do agree with deleting obsolete code, but not obsoleting hardware so we CAN delete code. --John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Sent: Wednesday, June 13, 2001 20:44 PM To: Linux kernel Subject: obsolete code must die Anyone concerned about the current size of the kernel source code? I am, and I propose to start cleaning house on the x86 platform. I mean it's all very well and good to keep adding features, but stuff needs to go if kernel development is to move forward. Before listing the gunk I want to get rid of, here's my justification for doing so: -- Getting rid of old code can help simplify the kernel. This means less chance of bugs. -- Simplifying the kernel means that it will be easier for newbies to understand and perhaps contribute. -- a simpler, cleaner kernel will also be of more use in an academic environment. -- a smaller kernel is easier to maintain and is easier to re-architect should the need arise. -- If someone really needs support for this junk, they will always have the option of using the 2.0.x, 2.2.x or 2.4.x series. So without further ado here're the features I want to get rid of: i386, i486 The Pentium processor has been around since 1995. Support for these older processors should go so we can focus on optimizations for the pentium and better processors. math-emu If support for i386 and i486 is going away, then so should math emulation. Every intel processor since the 486DX has an FPU unit built in. In fact shouldn't FPU support be a userspace responsibility anyway? ISA bus, MCA bus, EISA bus PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, CONFIG_ISAPNP, etc ISA, MCA, EISA device drivers If support for the buses is gone, there's no point in supporting devices for these buses. all code marked as CONFIG_OBSOLETE Since we're cleaning house we may as well get rid of this stuff. MFM/RLL/XT/ESDI hard drive support Does anyone still *have* an RLL drive that works? At the very least get rid of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) parallel/serial/game ports More controversial to remove this, since they are *still* in pretty wide use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. a.out Who needs it anymore. I love ELF. I really think doing a clean up is worthwhile. Maybe while looking for stuff to clean up we'll even be able to better comment the existing code. Any other features people would like to get rid of? Any comments or suggestions? I'd love to start a good discussion about this going so please send me your 2 cents. Daniel - 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/ - 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/
Question about signal handling
Hopefully I'm not asking a really stupid question here, but...
When setting up a signal handler, using sa_handler, there is a
quasi-documented 2nd parameter of 'struct context ctx' passed to the signal
handler. This seems to work on 2.2.12, 2.2.18, and 2.4.5-ac2. According to
various documents, when using sa_siginfo (and setting SA_SIGINFO), the third
parameter to the handler is defined as a 'void *', but actually passes a
'ucontext_t' data type. Which is not defined in any kernel code, except for
the sparc64 branch. Casting this to a 'struct context' or a 'struct context
*' doesn't seem to achieve the desired results on any of the three kernels I
tested.
Google searches indicate different things. POSIX 1 compliance says it
should be a 'ucontext_t *'
(www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html+sigcontext+siginf
o_t+sigactionhl=enlr=lang_en) (I realize that's the Open standard, but the
comments at the bottom talk about POSIX compliance). Other searches say it
returns as a 'struct context *'.
I tried following the code through the kernel, but I'm not familiar enough
with yet to really understand how it's getting scheduled, and exactly which
parameters are getting passed back.
What is the correct behavior supposed to be? And if using sa_siginfo, how
does one get at the context parameters to find the EIP the fault occurred
at?
Here's a sample bit of code I used for testing. Leaving #define SIGACTION
demonstrates the third parameter not (seemingly) being passed as a context
pointer, #undef demonstrates the sa_handler 2 paramter handler, which
returns a correct context.
#include stdio.h
#include signal.h
#include errno.h
#include string.h
#define SIGACTION
#ifdef SIGACTION
void fSegvHandler (int sigNo, siginfo_t *si, void *p)
{
struct sigcontext *context = (struct sigcontext *) p;
#else
void fSegvHandler (int sigNo, void *p)
{
struct sigcontext *context = (struct sigcontext *) p;
#endif
printf (\nContext: %08X\n,context);
fflush (stdout);
printf (gs: %04X\tfs: %04X\tes: %04X\tds: %04X\n
edi: %08X\tesi: %08X\tebp: %04X\tesp: %04X\n
ebx: %08X\tedx: %08X\tecx: %08X\teax: %08X\n
trap: %d\terr: %d\teip: %08X\tcs: %04X\n
flag: %08X\tSP: %08X\tss: %04X\tcr2: %08X\n,
context-gs, context-fs, context-es, context-ds,
context-edi, context-esi, context-ebp, context-esp,
context-ebx, context-edx, context-ecx, context-eax,
context-trapno, context-err, context-eip, context-cs,
context-eflags, context-esp_at_signal, context-ss,
context-cr2);
fflush (stdout);
exit (0);
}
int main (int argc, char **argv)
{
struct sigaction sSegvHdl;
sigemptyset (sSegvHdl.sa_mask);
sigaddset (sSegvHdl.sa_mask, SIGSEGV);
#ifdef SIGACTION
sSegvHdl.sa_flags = SA_SIGINFO | SA_ONESHOT;
sSegvHdl.sa_sigaction = fSegvHandler;
#else
sSegvHdl.sa_flags = SA_ONESHOT;
sSegvHdl.sa_handler = fSegvHandler;
#endif
if (sigaction (SIGSEGV, sSegvHdl, NULL))
perror (sigaction);
else
*(char *) 0x0 = 0x01;
}
-- John
-
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: [CHECKER] 15 probable security holes in 2.4.5-ac8
[snip] > > I gravely hope that nobody gets the idea to design a PCI card > for the Z8530 without bus master DMA... > [snip] What someone *really* needs to do is design a Z8530 adapter with a USB interface. The amateur radio community (well, the 56K'ers, at any rate), would love such a device. The PI2 card is a flakey beast, at best. --John - 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: [CHECKER] 15 probable security holes in 2.4.5-ac8
[snip] I gravely hope that nobody gets the idea to design a PCI card for the Z8530 without bus master DMA... [snip] What someone *really* needs to do is design a Z8530 adapter with a USB interface. The amateur radio community (well, the 56K'ers, at any rate), would love such a device. The PI2 card is a flakey beast, at best. --John - 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: temperature standard - global config option?
[Snip] (Mike writes a bunch a good stuff) > Yes, bits are free, sort of... That's why an extra decimal > place is "ok". Keeping precision within an order of magnitude of > accuracy is within the realm of reasonable. Running out to two decimal > places for this particular application is just silly. If it were for > calibrated lab equipment, fine. But not for CPU temperatures. > > Yes, APIs are difficult to change. But can you honestly say > that, even if we magically get off the shelf economical > temperature sensors > that are two orders of magnitude more accurate (without need of constant > tracible recalibration - these things DO drift), that this level of > precision would have any real meaning at all? I would expect the > CPU temperature to vary by a few hundreths of a degree just by how > many people were sweating in the cube next to me. > [snip] > > Now... That I can agree with and it would make absolute sense. > Especially if we were discussing lab grade or scientific grade measure > equipment and measurements. In fact, that would be a requirement for > any validity to be attached to measurements of that level of precision. > But that's not what we are talking about here, is it? We're not talking > about a lab grade instrumentation API here, are we? If we are, then > everything changes. > > Mike As someone who has been intimately involved in temperature measurement of electronics, Mike has pretty much thoroughly addressed the issue. Allow me to add this: You can go buy 12 "calibrated" temperature sensors (commercial, not lab quality), and you will get 12 different temperatures. When sampling the sensor (usually a thermocouple) in a motherboard, you have at best 1% resistors being used in the surrounding support components, +20%/-10% capacitors, A/Ds with +-1 LSB resolution, and worst of all, a coupling to the CPU that is about as bad as it can get. You've got an epoxy housing of an inconsistent shape in contact with ceramic. The actual contact point is miniscule. There's no thermal paste, and often, I've seen the sensors not quite raised high enough to contact the chip (you should be able to rack a business card across the empty socket and feel a slight "bump" as you touch the sensor. If not, you need to bend it up slightly, to give better physical contact to the CPU). But in spite of all this, you're not really measure the critical temperature, which is junction tempature. Yes, case tempature has *some* correlation, but it's not ratiometric. It can be affected by the mounting of the motherboard (believe it or not, you can see over 1C different in temperature between a vertical and horizontally mounted motherboard just because of convection out from under the socket. Yea, we would all love to truly know the CPU tempature down to a fraction of a degree. But it's useless information. Kinda of like knowing your fan speed to less than 100 RPM. Voltages fluctuations of .1 volts can cause a 100+ RPM change in the fan speed. All you really need to know that it's turning a lot less than when it first was. But I digress. Temperature measurement is an art. It requires having good sensors, good conversion electronics, and good mechanical coupling (if you really doubt this, look at the networks required to properly compensate any standard JK thermocouple). On top of ALL this mess, you have values being passed back from the hardware that are improperly converted. Ever wonder why the BIOS never exactly matches what you see from the 'sensors' program? It's because the adjustment factors in the config file are a best guess. For the record, in the course of a normal day, I see my temperatures fluctuate from 48C with the house A/C set to 73, to 56C when I open the doors, and let it get up to 76 in the house. That's 8C (14.4F) over a 3F change in ambient. --John - 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: temperature standard - global config option?
[Snip] (Mike writes a bunch a good stuff) Yes, bits are free, sort of... That's why an extra decimal place is ok. Keeping precision within an order of magnitude of accuracy is within the realm of reasonable. Running out to two decimal places for this particular application is just silly. If it were for calibrated lab equipment, fine. But not for CPU temperatures. Yes, APIs are difficult to change. But can you honestly say that, even if we magically get off the shelf economical temperature sensors that are two orders of magnitude more accurate (without need of constant tracible recalibration - these things DO drift), that this level of precision would have any real meaning at all? I would expect the CPU temperature to vary by a few hundreths of a degree just by how many people were sweating in the cube next to me. [snip] Now... That I can agree with and it would make absolute sense. Especially if we were discussing lab grade or scientific grade measure equipment and measurements. In fact, that would be a requirement for any validity to be attached to measurements of that level of precision. But that's not what we are talking about here, is it? We're not talking about a lab grade instrumentation API here, are we? If we are, then everything changes. Mike As someone who has been intimately involved in temperature measurement of electronics, Mike has pretty much thoroughly addressed the issue. Allow me to add this: You can go buy 12 calibrated temperature sensors (commercial, not lab quality), and you will get 12 different temperatures. When sampling the sensor (usually a thermocouple) in a motherboard, you have at best 1% resistors being used in the surrounding support components, +20%/-10% capacitors, A/Ds with +-1 LSB resolution, and worst of all, a coupling to the CPU that is about as bad as it can get. You've got an epoxy housing of an inconsistent shape in contact with ceramic. The actual contact point is miniscule. There's no thermal paste, and often, I've seen the sensors not quite raised high enough to contact the chip (you should be able to rack a business card across the empty socket and feel a slight bump as you touch the sensor. If not, you need to bend it up slightly, to give better physical contact to the CPU). But in spite of all this, you're not really measure the critical temperature, which is junction tempature. Yes, case tempature has *some* correlation, but it's not ratiometric. It can be affected by the mounting of the motherboard (believe it or not, you can see over 1C different in temperature between a vertical and horizontally mounted motherboard just because of convection out from under the socket. Yea, we would all love to truly know the CPU tempature down to a fraction of a degree. But it's useless information. Kinda of like knowing your fan speed to less than 100 RPM. Voltages fluctuations of .1 volts can cause a 100+ RPM change in the fan speed. All you really need to know that it's turning a lot less than when it first was. But I digress. Temperature measurement is an art. It requires having good sensors, good conversion electronics, and good mechanical coupling (if you really doubt this, look at the networks required to properly compensate any standard JK thermocouple). On top of ALL this mess, you have values being passed back from the hardware that are improperly converted. Ever wonder why the BIOS never exactly matches what you see from the 'sensors' program? It's because the adjustment factors in the config file are a best guess. For the record, in the course of a normal day, I see my temperatures fluctuate from 48C with the house A/C set to 73, to 56C when I open the doors, and let it get up to 76 in the house. That's 8C (14.4F) over a 3F change in ambient. --John - 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: USBDEVFS_URB_TYPE_INTERRUPT
Sigh. What do half the answers always show up seconds after clicking 'Send'? I see there is a FILL_URB_INT macro in linux/usb.h, but the only things using it seem to be drivers (as opposed to usbstress, libusb, etc). The ioctl call supports USBDEVFS_SUBMITURB, but passing a type USBDEVFS_URB_TYPE_INTERRUPT returns EINVAL. If the ioctl calls are the 'proper' way to talk to the USB drivers, should my code be calling usb_submit_urb directly if I want to pass interrupt type messages? I don't really want to write a full-up kernel mode driver for this device, but interrupt type messages are the preferred method for communicating, since once a message needs to be sent, it should be timely (whereas control messages could be delayed a significant amount on a busy USB channel). -- John - 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/
USBDEVFS_URB_TYPE_INTERRUPT
I was designing a USB based device and was looking through the 2.4.5 kernel code, and noticed that while it supports bulk, iso, and control types, there is no support for interrupt types. A grep through the entire kernel source code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in linux/usbdevice_fs.h, but no where is it used. Any thoughts as to why that might be? A google search didn't seem to turn up any answers either. -- John - 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/
USBDEVFS_URB_TYPE_INTERRUPT
I was designing a USB based device and was looking through the 2.4.5 kernel code, and noticed that while it supports bulk, iso, and control types, there is no support for interrupt types. A grep through the entire kernel source code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in linux/usbdevice_fs.h, but no where is it used. Any thoughts as to why that might be? A google search didn't seem to turn up any answers either. -- John - 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: USBDEVFS_URB_TYPE_INTERRUPT
Sigh. What do half the answers always show up seconds after clicking 'Send'? I see there is a FILL_URB_INT macro in linux/usb.h, but the only things using it seem to be drivers (as opposed to usbstress, libusb, etc). The ioctl call supports USBDEVFS_SUBMITURB, but passing a type USBDEVFS_URB_TYPE_INTERRUPT returns EINVAL. If the ioctl calls are the 'proper' way to talk to the USB drivers, should my code be calling usb_submit_urb directly if I want to pass interrupt type messages? I don't really want to write a full-up kernel mode driver for this device, but interrupt type messages are the preferred method for communicating, since once a message needs to be sent, it should be timely (whereas control messages could be delayed a significant amount on a busy USB channel). -- John - 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: select() - Linux vs. BSD
> > [EMAIL PROTECTED] wrote: > > Of course, not looking at the sets upon a zero return is a > fairly obvious > > optimization as there is little point in doing so. > > No; a fairly obvious optimisation is to avoid calling FD_ZERO if you > can clear the bits individually when you test them. > > When you examine the sets, you can clear each bit that you examine and > then you know you have a zero set. Then you can set only the relevant > bits for the next call to select(). > > If you can't rely on the sets being cleared on a timeout, then you > will have to call FD_ZERO in that case, or you will have to go through > the list of descriptors and clear them individually. (This can be > avoided but it means keeping track of state between successive calls > to select()). This is contrary to the non-timeout case, where you > stop checking bits when you have counted N of them set. > > So you see, there is a handy optimisation if you can assume the sets > are zeroed on timeout. > I would have said just the opposite. That if it you have a large number of handles you're waiting on, and you have to go back through and set the bits everytime you timeout that you would incur a larger overhead. From the perspective of my application, it would have been more efficient to not zero them (I was waiting on a number of serial channels, and the timeout was used to periodically pump more data to the serial channel. When I received data, I buffered it, and another thread took care of processing it). It all really depends on the coding style of your program, and what you need to do on a timeout. Certain types of applications would benefit from non-zero'ing, others from zeroing. All what is *most* important is that the behavior is clearly understood and well documented. A google search made it pretty clear that it was a source of confusion. --John - 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: select() - Linux vs. BSD
[EMAIL PROTECTED] wrote: Of course, not looking at the sets upon a zero return is a fairly obvious optimization as there is little point in doing so. No; a fairly obvious optimisation is to avoid calling FD_ZERO if you can clear the bits individually when you test them. When you examine the sets, you can clear each bit that you examine and then you know you have a zero set. Then you can set only the relevant bits for the next call to select(). If you can't rely on the sets being cleared on a timeout, then you will have to call FD_ZERO in that case, or you will have to go through the list of descriptors and clear them individually. (This can be avoided but it means keeping track of state between successive calls to select()). This is contrary to the non-timeout case, where you stop checking bits when you have counted N of them set. So you see, there is a handy optimisation if you can assume the sets are zeroed on timeout. I would have said just the opposite. That if it you have a large number of handles you're waiting on, and you have to go back through and set the bits everytime you timeout that you would incur a larger overhead. From the perspective of my application, it would have been more efficient to not zero them (I was waiting on a number of serial channels, and the timeout was used to periodically pump more data to the serial channel. When I received data, I buffered it, and another thread took care of processing it). It all really depends on the coding style of your program, and what you need to do on a timeout. Certain types of applications would benefit from non-zero'ing, others from zeroing. All what is *most* important is that the behavior is clearly understood and well documented. A google search made it pretty clear that it was a source of confusion. --John - 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/
select() - Linux vs. BSD
I hope I'm not rehashing anything discussed before, but I couldn't find any references to this: In BSD, select() states that when a time out occurs, the bits passed to select will not be altered. In Linux, which claims BSD compliancy for this in the man page (but does not state either way what will happen to the bits), zeros the users bit masks when a timeout occurs. I have written a test case, and run on both systems; BSD behaves as stated, Linux does not act like BSD. Should the man pages be changed to reflect reality, or select() fixed to act like BSD? -- John - 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/
select() - Linux vs. BSD
I hope I'm not rehashing anything discussed before, but I couldn't find any references to this: In BSD, select() states that when a time out occurs, the bits passed to select will not be altered. In Linux, which claims BSD compliancy for this in the man page (but does not state either way what will happen to the bits), zeros the users bit masks when a timeout occurs. I have written a test case, and run on both systems; BSD behaves as stated, Linux does not act like BSD. Should the man pages be changed to reflect reality, or select() fixed to act like BSD? -- John - 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: Problems with ac12 kernels and up
>> I looked at the root_mountflags usage and it looks ok, so I put it in >> the "figure out later" pile. >> >> Haven't yet verified if this 'ac' only problem > >Think I have it sussed. Time for -ac2 I took down my Jerry Garcia poster, and put up an Alan Cox poster. 2.4.5-ac2 boots like a champ. Thanks! (will this make it into a 2.4.4-ac19 patch?) -- John - 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: problems with ac12 kernels and up
>> http://jcwren.com/linux/ac18.txt - ac18 dmesg dump >> http://jcwren.com/linux/build.txt - sequence I'm using to build >> >> The apparent interleaved garbage closer to the bottom is exactly what came >> out on the console. (Is linking to the dumps perferred over including it in >> the mail, or would folks prefer to have the text included? Since I'm not a > >The link is fine.. > >> I also rebuilt the ac12 kernel, and tried again. Same results as the quoted >> text above. > >This looks a lot like the superblock changes not only broke reiserfs but also >initd usage. > >Al ? If it's of any help, here's the System.map around that EIP: c017f0d0 T floppy_eject c017f100 t get_dma_residue c017f150 t rd_make_request c017f280 t rd_ioctl c017f380 t initrd_read c017f3d0 t initrd_release c017f420 t rd_open c017f4b0 t rd_release --John - 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: Problems with ac12 kernels and up
> >> Checking root filesystem. /dev/hde13 is mounted. >> Cannot continue, aboorting. >> *** An error occurred during the file system check. >> *** Dropping you to a shell; the system will reboot >> *** when you leave the shell. > >That means the file system was mounted read/write at boot time. That normally >indicates a lilo misconfiguration however your lilo.conf looks >correct. > >Alan I've built the ac18 kernel with the serial console enabled, and dumped the results (this is the one that kernel panics). http://jcwren.com/linux/ac18.txt - ac18 dmesg dump http://jcwren.com/linux/build.txt - sequence I'm using to build The apparent interleaved garbage closer to the bottom is exactly what came out on the console. (Is linking to the dumps perferred over including it in the mail, or would folks prefer to have the text included? Since I'm not a judge of exactly what you need to see, I'm not sure if 200 lines of dump would be appropriate or not). Just for good measure, I've installed the latest RH 7.1 LILO, mkinitrd, and associated tools. I also rebuilt the ac12 kernel, and tried again. Same results as the quoted text above. --John - 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/
Problems with ac12 kernels and up
I have been running 2.4.4-ac11 for a few weeks, and decided to upgrade to 2.4.4-ac18. I applied the patches, compiled, and installed (all per usual), and when booting, get a kernel panic at the point VFS is trying to mount the root file system. I started working backwards to find the last kernel that would boot. I got down to ac13, and the panics stopped, but I get the following message: Checking root filesystem. /dev/hde13 is mounted. Cannot continue, aboorting. *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Same for ac12. I used the same config file I used for ac11 and previous ac kernels. I then decided to try the 2.4.5 kernel, which worked fine. I then applied the 2.4.5-ac1 patches, and got the above message, again. The system is an Abit KT7A-RAID w/ a 1Ghz Athlon. The dmesg output link below describes the drive configuration. The BIOS is configured to boot from the HPT-370. As part of the test, I completely reinstalled the 2.4.4 kernel source, applied the ac11 patch, and my config file, rebuilt and reinstalled. All worked fine. Any thoughts on why this might be occurring? I can provide any additional information as necessary. Here are the various files: http://jcwren.com/linux/config.txt - config file http://jcwren.com/linux/dmesg.txt - ac11 dmesg log http://jcwren.com/linux/lilo.txt - lilo.conf I'm not smart enough to know how to capture the output for a kernel that panics and halts. If I can provide any additional information for resolving the problem, I would be happy to. Oh, and as best as I can tell before it all scrolls by, the kernel reporting looks to be the same between all kernels, with only the version being different. --John - 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/
Problems with ac12 kernels and up
I have been running 2.4.4-ac11 for a few weeks, and decided to upgrade to 2.4.4-ac18. I applied the patches, compiled, and installed (all per usual), and when booting, get a kernel panic at the point VFS is trying to mount the root file system. I started working backwards to find the last kernel that would boot. I got down to ac13, and the panics stopped, but I get the following message: Checking root filesystem. /dev/hde13 is mounted. Cannot continue, aboorting. *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Same for ac12. I used the same config file I used for ac11 and previous ac kernels. I then decided to try the 2.4.5 kernel, which worked fine. I then applied the 2.4.5-ac1 patches, and got the above message, again. The system is an Abit KT7A-RAID w/ a 1Ghz Athlon. The dmesg output link below describes the drive configuration. The BIOS is configured to boot from the HPT-370. As part of the test, I completely reinstalled the 2.4.4 kernel source, applied the ac11 patch, and my config file, rebuilt and reinstalled. All worked fine. Any thoughts on why this might be occurring? I can provide any additional information as necessary. Here are the various files: http://jcwren.com/linux/config.txt - config file http://jcwren.com/linux/dmesg.txt - ac11 dmesg log http://jcwren.com/linux/lilo.txt - lilo.conf I'm not smart enough to know how to capture the output for a kernel that panics and halts. If I can provide any additional information for resolving the problem, I would be happy to. Oh, and as best as I can tell before it all scrolls by, the kernel reporting looks to be the same between all kernels, with only the version being different. --John - 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: Problems with ac12 kernels and up
Checking root filesystem. /dev/hde13 is mounted. Cannot continue, aboorting. *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. That means the file system was mounted read/write at boot time. That normally indicates a lilo misconfiguration however your lilo.conf looks correct. Alan I've built the ac18 kernel with the serial console enabled, and dumped the results (this is the one that kernel panics). http://jcwren.com/linux/ac18.txt - ac18 dmesg dump http://jcwren.com/linux/build.txt - sequence I'm using to build The apparent interleaved garbage closer to the bottom is exactly what came out on the console. (Is linking to the dumps perferred over including it in the mail, or would folks prefer to have the text included? Since I'm not a judge of exactly what you need to see, I'm not sure if 200 lines of dump would be appropriate or not). Just for good measure, I've installed the latest RH 7.1 LILO, mkinitrd, and associated tools. I also rebuilt the ac12 kernel, and tried again. Same results as the quoted text above. --John - 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: problems with ac12 kernels and up
http://jcwren.com/linux/ac18.txt - ac18 dmesg dump http://jcwren.com/linux/build.txt - sequence I'm using to build The apparent interleaved garbage closer to the bottom is exactly what came out on the console. (Is linking to the dumps perferred over including it in the mail, or would folks prefer to have the text included? Since I'm not a The link is fine.. I also rebuilt the ac12 kernel, and tried again. Same results as the quoted text above. This looks a lot like the superblock changes not only broke reiserfs but also initd usage. Al ? If it's of any help, here's the System.map around that EIP: c017f0d0 T floppy_eject c017f100 t get_dma_residue c017f150 t rd_make_request c017f280 t rd_ioctl c017f380 t initrd_read c017f3d0 t initrd_release c017f420 t rd_open c017f4b0 t rd_release --John - 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: Problems with ac12 kernels and up
I looked at the root_mountflags usage and it looks ok, so I put it in the figure out later pile. Haven't yet verified if this 'ac' only problem Think I have it sussed. Time for -ac2 I took down my Jerry Garcia poster, and put up an Alan Cox poster. 2.4.5-ac2 boots like a champ. Thanks! (will this make it into a 2.4.4-ac19 patch?) -- John - 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/
