PCI Interrupt Problems Since Kernel-2.6.19
I'm writing a driver for DVB-C PCI receiving cards these days and I found a tricky problem of interrupts. Since kernel-2.6.19 the interrupt handlers get rid of "struct pt_regs*" argument and I think it will be easy for me to modify the driver to fit for the recent kernel. I simply delete the "struct pt_regs *" argument of my interrupt handler and compile the driver again. But then I met a rather tricky problem. I cann't get the PCI intterrupt now! I found that the chip on the card actually had generate an interrupt and it should not be the hardware problem. I'm get seriously confused. My driver works well under kernel-2.6.18 but not generates a single interrupt signal when works above kernel-2.6.19. Does anybody meet similar problems? Sincerely Yours, Lost Graden. 1,21. 2008 -- 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/
PCI Interrupt Problems Since Kernel-2.6.19
I'm writing a driver for DVB-C PCI receiving cards these days and I found a tricky problem of interrupts. Since kernel-2.6.19 the interrupt handlers get rid of struct pt_regs* argument and I think it will be easy for me to modify the driver to fit for the recent kernel. I simply delete the struct pt_regs * argument of my interrupt handler and compile the driver again. But then I met a rather tricky problem. I cann't get the PCI intterrupt now! I found that the chip on the card actually had generate an interrupt and it should not be the hardware problem. I'm get seriously confused. My driver works well under kernel-2.6.18 but not generates a single interrupt signal when works above kernel-2.6.19. Does anybody meet similar problems? Sincerely Yours, Lost Graden. 1,21. 2008 -- 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
On Sat, 2 Jun 2001, Jamie Lokier wrote: > [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. That would make sense. HOWEVER, you took my comment out of context. I had pointed out that since the zero return from select() is not an error condition, you can rely on the sets being zeroed out. The zero simply indicates that no descriptors had anything interesting occur and if the sets are not zeroed, the implementation is broken. Upon error, the values are undefined and the value of timeout is undefined. (In this case, doing nothing upon a zero return from select() is perfectly reasonable.) If I recall, the original posting was about whether the sets were zeroed upon an error condition which a timeout is not defined as in this case. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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
On Sat, 2 Jun 2001, Jamie Lokier wrote: [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. That would make sense. HOWEVER, you took my comment out of context. I had pointed out that since the zero return from select() is not an error condition, you can rely on the sets being zeroed out. The zero simply indicates that no descriptors had anything interesting occur and if the sets are not zeroed, the implementation is broken. Upon error, the values are undefined and the value of timeout is undefined. (In this case, doing nothing upon a zero return from select() is perfectly reasonable.) If I recall, the original posting was about whether the sets were zeroed upon an error condition which a timeout is not defined as in this case. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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
On Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote: > (ii) The Linux man page only says > > RETURN VALUE >On success, select and pselect return the number of >descriptors contained in the descriptor sets, which may be >zero if the timeout expires before anything interesting >happens. On error, -1 is returned, and errno is set >appropriately; the sets and timeout become undefined, so >do not rely on their contents after an error. > > That is, a wise programmer does not assume any particular value > for the bits after a timeout. So how does this say the value of the fdsets are undefined after a timeout? It says specifically that upon success it returns the number of descriptors in the sets, zero if the timeout expires. That is a success condition upon which select() sets the fdsets to contain the descriptors upon which something interesting happened. In the case of a timeout with no descriptor having anything interesting, the sets would, logically, be cleared. The man page does state that the value of "timeout" is effectively undefined upon return and that "timeout" and the fdsets are undefined after an error, however. Of course, not looking at the sets upon a zero return is a fairly obvious optimization as there is little point in doing so. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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
On Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote: (ii) The Linux man page only says RETURN VALUE On success, select and pselect return the number of descriptors contained in the descriptor sets, which may be zero if the timeout expires before anything interesting happens. On error, -1 is returned, and errno is set appropriately; the sets and timeout become undefined, so do not rely on their contents after an error. That is, a wise programmer does not assume any particular value for the bits after a timeout. So how does this say the value of the fdsets are undefined after a timeout? It says specifically that upon success it returns the number of descriptors in the sets, zero if the timeout expires. That is a success condition upon which select() sets the fdsets to contain the descriptors upon which something interesting happened. In the case of a timeout with no descriptor having anything interesting, the sets would, logically, be cleared. The man page does state that the value of timeout is effectively undefined upon return and that timeout and the fdsets are undefined after an error, however. Of course, not looking at the sets upon a zero return is a fairly obvious optimization as there is little point in doing so. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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
On Tue, 29 May 2001, Alan Cox wrote: > > 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 > > Nope. BSD manual pages (the authentic ones anyway) say that the timeout value > may well be written back but that this was a future enhancement and that users > shoulsnt rely on the value being unchanged. The reference was to the fdsets passed in if I read the original post correctly. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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
On Tue, 29 May 2001, Alan Cox wrote: 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 Nope. BSD manual pages (the authentic ones anyway) say that the timeout value may well be written back but that this was a future enhancement and that users shoulsnt rely on the value being unchanged. The reference was to the fdsets passed in if I read the original post correctly. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - 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: malloc(1/0) ??
> > > main()
> > > {
> > >char *s;
> > >s = (char*)malloc(0);
> > >strcpy(s,"f");
> > >printf("%s\n",s);
> > > }
I rather suspect that the strcpy() scribbled over malloc()s record keeping
data. However, that memory was in the processes allowed address space so
it didn't SIGSEGV. Now, when you call printf(), there is a very good
chance that printf() tried to allocate some sort of buffer space since it
is the first call to printf() in the program. Now, since malloc()s heap is
messed up from the strcpy(), it crashes. (Probably because
malloc() followed a pointer off into never-never land.) Hence, the crash
appears in printf() instead of strcpy() or malloc(). I won't repeat the
discussion about why malloc(0) succeeded.
William Astle
finger [EMAIL PROTECTED] for further information
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+
PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: malloc(1/0) ??
main()
{
char *s;
s = (char*)malloc(0);
strcpy(s,"f");
printf("%s\n",s);
}
I rather suspect that the strcpy() scribbled over malloc()s record keeping
data. However, that memory was in the processes allowed address space so
it didn't SIGSEGV. Now, when you call printf(), there is a very good
chance that printf() tried to allocate some sort of buffer space since it
is the first call to printf() in the program. Now, since malloc()s heap is
messed up from the strcpy(), it crashes. (Probably because
malloc() followed a pointer off into never-never land.) Hence, the crash
appears in printf() instead of strcpy() or malloc(). I won't repeat the
discussion about why malloc(0) succeeded.
William Astle
finger [EMAIL PROTECTED] for further information
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+
PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
