Re: Print long messages to console from kernel module
On Mon, 25 Feb 2008, Arvid Brodin wrote: > I need to write messages > 1023 characters long to the console from a > module*. printk() is limited to 1023 characters, and splitting the message > over several printk()'s results in a line break and "Month hh:mm:ss host > kernel:" being inserted in my text. > > I tried including and using the console_drivers declared > there, but get > "WARNING: "console_drivers" [/log.ko] undefined!" when compiling and > "insmod: error inserting 'log.ko': -1 Unknown symbol in module" when > insmodding. > > I guess this is because non EXPORT_SYMBOL'd symbols are only accessible to > statically linked code, and not to modules? I see in printk.c that > console_drivers is set up there, and I haven't been able to find any other > interface to console_drivers. > > In short: is there any way to print messages to the console from a kernel > module, except printk()? Is opening /dev/tty and writing to it the way to go? > > > * I'm writing an in-memory logger to be included in a module. The log can be > several megabytes. The idea is to use SysRq to print the contents of the log > to console after a kernel panic or otherwise when writing to disk might not > work. > > -- > Arvid Brodin > Enea LCC Write the data to a kernel buffer. Impliment read() or ioctl() and poll(). Have a user-mode task sleep in poll, waiting for data to become available. That user-mode task can do anything it wants, unrestricted, with the data including writing it to files or any tty it wants to open. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Print long messages to console from kernel module
On Mon, 25 Feb 2008, Arvid Brodin wrote: I need to write messages 1023 characters long to the console from a module*. printk() is limited to 1023 characters, and splitting the message over several printk()'s results in a line break and Month hh:mm:ss host kernel: being inserted in my text. I tried including linux/console.h and using the console_drivers declared there, but get WARNING: console_drivers [path/log.ko] undefined! when compiling and insmod: error inserting 'log.ko': -1 Unknown symbol in module when insmodding. I guess this is because non EXPORT_SYMBOL'd symbols are only accessible to statically linked code, and not to modules? I see in printk.c that console_drivers is set up there, and I haven't been able to find any other interface to console_drivers. In short: is there any way to print messages to the console from a kernel module, except printk()? Is opening /dev/tty and writing to it the way to go? * I'm writing an in-memory logger to be included in a module. The log can be several megabytes. The idea is to use SysRq to print the contents of the log to console after a kernel panic or otherwise when writing to disk might not work. -- Arvid Brodin Enea LCC Write the data to a kernel buffer. Impliment read() or ioctl() and poll(). Have a user-mode task sleep in poll, waiting for data to become available. That user-mode task can do anything it wants, unrestricted, with the data including writing it to files or any tty it wants to open. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is there a "blackhole" /dev/null directory?
On Thu, 14 Feb 2008, Mika Lawando wrote: > Jasper Bryant-Greene schrieb: >> On Thu, 2008-02-14 at 10:30 +0100, rzryyvzy wrote: >> >>> /dev/null is often very useful, specially if programs force to save data in >>> some file. But some programs like to creates different temporary file >>> names, so /dev/null could no more work. >>> >>> What is with a "/dev/null"-directory? >>> I mean a "blackhole pseudo directory" which eats every write to null. >>> >>> Here is how it could work: >>> mount -t nulldir nulldir /dev/nulldir >>> >>> Now if a program does a create(2), >>> it creates in the memory the file with its fd. >>> Then if a program does a write(2) to the fd, it eats the writes and give >>> out fakely it has written the number of bytes. >>> When the program calls does a close(2) of the fd, then the complete inode >>> is deleted in the memory. >>> >>> The directory should be permanently empty except for the inodes with open >>> file descriptors. So only inode information would be temporary saved in >>> this "nulldir tmpfs" directory. >>> >>> Is there already existing a possibility to create a null directory? >>> >> >> This could be done fairly trivially with FUSE, and IMHO is a good use >> for FUSE because since you're just throwing most data away, performance >> is not a concern. >> > Unfortunately performance is a concern because if not I would write on > the hard disk the files, and then remove them with a cronjob. > But from the point of view of the time of developpment, FUSE is a good > idea, because its possible to write a filesystem quickly in Perl. > > -- > Best regards, > Mika > -- Creating a null directory wouldn't work because a directory is just a link to find a file. The actual file gets written using the file-descriptor, without any reference whosoever to the path. If you have root privileges, you can use `mknod tempfile c 1 3` to create a null file with any name you want. Unfortunately, somebody decided that you need root privileges to execute mknod so ordinary users can not do this. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is there a blackhole /dev/null directory?
On Thu, 14 Feb 2008, Mika Lawando wrote: Jasper Bryant-Greene schrieb: On Thu, 2008-02-14 at 10:30 +0100, rzryyvzy wrote: /dev/null is often very useful, specially if programs force to save data in some file. But some programs like to creates different temporary file names, so /dev/null could no more work. What is with a /dev/null-directory? I mean a blackhole pseudo directory which eats every write to null. Here is how it could work: mount -t nulldir nulldir /dev/nulldir Now if a program does a create(2), it creates in the memory the file with its fd. Then if a program does a write(2) to the fd, it eats the writes and give out fakely it has written the number of bytes. When the program calls does a close(2) of the fd, then the complete inode is deleted in the memory. The directory should be permanently empty except for the inodes with open file descriptors. So only inode information would be temporary saved in this nulldir tmpfs directory. Is there already existing a possibility to create a null directory? This could be done fairly trivially with FUSE, and IMHO is a good use for FUSE because since you're just throwing most data away, performance is not a concern. Unfortunately performance is a concern because if not I would write on the hard disk the files, and then remove them with a cronjob. But from the point of view of the time of developpment, FUSE is a good idea, because its possible to write a filesystem quickly in Perl. -- Best regards, Mika -- Creating a null directory wouldn't work because a directory is just a link to find a file. The actual file gets written using the file-descriptor, without any reference whosoever to the path. If you have root privileges, you can use `mknod tempfile c 1 3` to create a null file with any name you want. Unfortunately, somebody decided that you need root privileges to execute mknod so ordinary users can not do this. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] fs/coda: remove static inline forward declarations
On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote: > On Wed, 13 Feb 2008, linux-os (Dick Johnson) wrote: >> >> On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote: >> >>> They're defined later on in the same file with bodies and >>> nothingin between needs them. >>> >>> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> >>> --- >>> include/linux/coda_linux.h |3 --- >>> 1 files changed, 0 insertions(+), 3 deletions(-) >>> >>> diff --git a/include/linux/coda_linux.h b/include/linux/coda_linux.h >>> index 1c47a34..31b7531 100644 >>> --- a/include/linux/coda_linux.h >>> +++ b/include/linux/coda_linux.h >>> @@ -43,9 +43,6 @@ int coda_getattr(struct vfsmount *, struct dentry *, >>> struct kstat *); >>> int coda_setattr(struct dentry *, struct iattr *); >>> >>> /* this file: heloers */ >>> -static __inline__ struct CodaFid *coda_i2f(struct inode *); >>> -static __inline__ char *coda_i2s(struct inode *); >>> -static __inline__ void coda_flag_inode(struct inode *, int flag); >>> char *coda_f2s(struct CodaFid *f); >>> int coda_isroot(struct inode *i); >>> int coda_iscontrol(const char *name, size_t length); >>> -- >>> 1.5.2.2 >>> >> >> I was taught formally that all procedures must be declared >> before they are encountered in a file. This constitutes what >> is generally known as "good standards of engineering practice." >> It also guarantees a compiler diagnostic if the declaration and >> the function doesn't match. > > They still are declared before they are used (the other two functions are > similar to this randomly picked example): > > $ grep "coda_i2f" include/linux/coda_linux.h > static __inline__ struct CodaFid *coda_i2f(struct inode *); > static __inline__ struct CodaFid *coda_i2f(struct inode *inode) > > I removed the first one of these. The latter is followed by the body of > the function. > > By using some fuzzy word like "encountered" you just make your point > obscure enough so that I cannot follow what you're trying to say. If you > refer to use of the function by "encountering", then that property is > still maintained and we still get all the type-checking and so on (even > after this removal). > >> You should not remove things just because you don't think they >> are necessary. They do no harm and removing them can cause >> code checking tools to issue diagnostic messages. > > Do you really think so? I mean in this specific case, did you even > bothered to check the file before hitting the send button? ...I just fail > to see what is your point in keeping these three because they're declared > later on in the same file, though with the body at that time. Do you also > claim that all the other ~5000+ static inlines with body in kernel headers > (but not forward declared) are not following those "good standards" you're > asking for (they certainly won't issue extra diagnostic messages)? > > > -- > i. > Have you EVER seen the diagnostic message, "function is not a prototype?" It's rhetorical. You don't have to answer. Furthermore "encountered" is not fuzzy. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] fs/coda: remove static inline forward declarations
On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote: > They're defined later on in the same file with bodies and > nothingin between needs them. > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> > --- > include/linux/coda_linux.h |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/include/linux/coda_linux.h b/include/linux/coda_linux.h > index 1c47a34..31b7531 100644 > --- a/include/linux/coda_linux.h > +++ b/include/linux/coda_linux.h > @@ -43,9 +43,6 @@ int coda_getattr(struct vfsmount *, struct dentry *, struct > kstat *); > int coda_setattr(struct dentry *, struct iattr *); > > /* this file: heloers */ > -static __inline__ struct CodaFid *coda_i2f(struct inode *); > -static __inline__ char *coda_i2s(struct inode *); > -static __inline__ void coda_flag_inode(struct inode *, int flag); > char *coda_f2s(struct CodaFid *f); > int coda_isroot(struct inode *i); > int coda_iscontrol(const char *name, size_t length); > -- > 1.5.2.2 > I was taught formally that all procedures must be declared before they are encountered in a file. This constitutes what is generally known as "good standards of engineering practice." It also guarantees a compiler diagnostic if the declaration and the function doesn't match. You should not remove things just because you don't think they are necessary. They do no harm and removing them can cause code checking tools to issue diagnostic messages. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] fs/coda: remove static inline forward declarations
On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote: They're defined later on in the same file with bodies and nothingin between needs them. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- include/linux/coda_linux.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/include/linux/coda_linux.h b/include/linux/coda_linux.h index 1c47a34..31b7531 100644 --- a/include/linux/coda_linux.h +++ b/include/linux/coda_linux.h @@ -43,9 +43,6 @@ int coda_getattr(struct vfsmount *, struct dentry *, struct kstat *); int coda_setattr(struct dentry *, struct iattr *); /* this file: heloers */ -static __inline__ struct CodaFid *coda_i2f(struct inode *); -static __inline__ char *coda_i2s(struct inode *); -static __inline__ void coda_flag_inode(struct inode *, int flag); char *coda_f2s(struct CodaFid *f); int coda_isroot(struct inode *i); int coda_iscontrol(const char *name, size_t length); -- 1.5.2.2 I was taught formally that all procedures must be declared before they are encountered in a file. This constitutes what is generally known as good standards of engineering practice. It also guarantees a compiler diagnostic if the declaration and the function doesn't match. You should not remove things just because you don't think they are necessary. They do no harm and removing them can cause code checking tools to issue diagnostic messages. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] fs/coda: remove static inline forward declarations
On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote: On Wed, 13 Feb 2008, linux-os (Dick Johnson) wrote: On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote: They're defined later on in the same file with bodies and nothingin between needs them. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- include/linux/coda_linux.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/include/linux/coda_linux.h b/include/linux/coda_linux.h index 1c47a34..31b7531 100644 --- a/include/linux/coda_linux.h +++ b/include/linux/coda_linux.h @@ -43,9 +43,6 @@ int coda_getattr(struct vfsmount *, struct dentry *, struct kstat *); int coda_setattr(struct dentry *, struct iattr *); /* this file: heloers */ -static __inline__ struct CodaFid *coda_i2f(struct inode *); -static __inline__ char *coda_i2s(struct inode *); -static __inline__ void coda_flag_inode(struct inode *, int flag); char *coda_f2s(struct CodaFid *f); int coda_isroot(struct inode *i); int coda_iscontrol(const char *name, size_t length); -- 1.5.2.2 I was taught formally that all procedures must be declared before they are encountered in a file. This constitutes what is generally known as good standards of engineering practice. It also guarantees a compiler diagnostic if the declaration and the function doesn't match. They still are declared before they are used (the other two functions are similar to this randomly picked example): $ grep coda_i2f include/linux/coda_linux.h static __inline__ struct CodaFid *coda_i2f(struct inode *); static __inline__ struct CodaFid *coda_i2f(struct inode *inode) I removed the first one of these. The latter is followed by the body of the function. By using some fuzzy word like encountered you just make your point obscure enough so that I cannot follow what you're trying to say. If you refer to use of the function by encountering, then that property is still maintained and we still get all the type-checking and so on (even after this removal). You should not remove things just because you don't think they are necessary. They do no harm and removing them can cause code checking tools to issue diagnostic messages. Do you really think so? I mean in this specific case, did you even bothered to check the file before hitting the send button? ...I just fail to see what is your point in keeping these three because they're declared later on in the same file, though with the body at that time. Do you also claim that all the other ~5000+ static inlines with body in kernel headers (but not forward declared) are not following those good standards you're asking for (they certainly won't issue extra diagnostic messages)? -- i. Have you EVER seen the diagnostic message, function is not a prototype? It's rhetorical. You don't have to answer. Furthermore encountered is not fuzzy. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] scsi_error: Fix language abuse.
On Fri, 8 Feb 2008, Mark Hounschell wrote: > linux-os (Dick Johnson) wrote: >> >> The correct word should be "invalid," in spite of >> the fact that the SCSI committee used invalid syntax. >> >> Alan is right. There is nothing illegal in the kernel >> and if there is, it must be removed as soon as it >> is discovered! >> > > il·le·gal (-lgl) > adj. > 1. Prohibited by law. > *2. Prohibited by official rules: an illegal pass in football. > *3. Unacceptable to or not performable by a computer: an illegal operation. > > Mark Many early computer programmers including myself, while writing error messages in early software, did not understand that computer programmers do not make law so we called bad operations "illegal." Once you are called to testify in a court of law, about some message your code wrote to the screen just before a factory burned down, you start to be much more careful about the syntax. I advise that, regardless of the rewrite of dictionaries and, in fact, the rewrite of history, whenever possible we use the correct message syntax. Dictionaries pick up "common usage" in spite of the fact that it is wrong. See "irregardless" and other abortions which now exist in the dictionary. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] scsi_error: Fix language abuse.
On Fri, 8 Feb 2008, Mark Hounschell wrote: linux-os (Dick Johnson) wrote: The correct word should be invalid, in spite of the fact that the SCSI committee used invalid syntax. Alan is right. There is nothing illegal in the kernel and if there is, it must be removed as soon as it is discovered! il·le·gal (-lgl) adj. 1. Prohibited by law. *2. Prohibited by official rules: an illegal pass in football. *3. Unacceptable to or not performable by a computer: an illegal operation. Mark Many early computer programmers including myself, while writing error messages in early software, did not understand that computer programmers do not make law so we called bad operations illegal. Once you are called to testify in a court of law, about some message your code wrote to the screen just before a factory burned down, you start to be much more careful about the syntax. I advise that, regardless of the rewrite of dictionaries and, in fact, the rewrite of history, whenever possible we use the correct message syntax. Dictionaries pick up common usage in spite of the fact that it is wrong. See irregardless and other abortions which now exist in the dictionary. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] scsi_error: Fix language abuse.
The correct word should be "invalid," in spite of the fact that the SCSI committee used invalid syntax. Alan is right. There is nothing illegal in the kernel and if there is, it must be removed as soon as it is discovered! On Fri, 8 Feb 2008, James Bottomley wrote: > > On Fri, 2008-02-08 at 15:32 +, Alan Cox wrote: >> The word "illegal" has a precise dictionary meaning of "prohibited by >> law". The error messages are therefore incorrect as so far nobody has >> made SCSI violations a criminal offence. > > Um, I'm really reluctant to do this without an incredibly good reason. > Illegal is a defined term under the SCSI standards, and the messages you > are changing actually appear with the word Illegal in the actual > ASC/ASCQ definition. If I accept this patch, you'll no longer be able > to look the messages up in the relevant standard: > > http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf > > By a simple text search. > > I don't think the pedantry is worth the confusion ... > > James > Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] scsi_error: Fix language abuse.
The correct word should be invalid, in spite of the fact that the SCSI committee used invalid syntax. Alan is right. There is nothing illegal in the kernel and if there is, it must be removed as soon as it is discovered! On Fri, 8 Feb 2008, James Bottomley wrote: On Fri, 2008-02-08 at 15:32 +, Alan Cox wrote: The word illegal has a precise dictionary meaning of prohibited by law. The error messages are therefore incorrect as so far nobody has made SCSI violations a criminal offence. Um, I'm really reluctant to do this without an incredibly good reason. Illegal is a defined term under the SCSI standards, and the messages you are changing actually appear with the word Illegal in the actual ASC/ASCQ definition. If I accept this patch, you'll no longer be able to look the messages up in the relevant standard: http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf By a simple text search. I don't think the pedantry is worth the confusion ... James Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Q: linux failed to execute /init?
-14 is EFAULT. This means that there was some access to memory that was not mapped. In the future, check /usr/include/asm/errno.h for exit codes. Of course in user-space they are positive with -1 being return from the function-call and errno being set to this code. In the kernel, they are combined with 'error' being the negative of the return code. On Fri, 25 Jan 2008, Jack Harvard wrote: > Hi, > > I'm trying to boot Linux, but the /init process failed. Here is the > info: > > =FF<6>/init exit code: -14 > /init exit code: -14 > <4>Failed to execute /init > Failed to execute /init > <6>/sbin/init exit code: -14 > > Just wondering what do those different exit codes mean? > > Thanks, -J > -- Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Q: linux failed to execute /init?
-14 is EFAULT. This means that there was some access to memory that was not mapped. In the future, check /usr/include/asm/errno.h for exit codes. Of course in user-space they are positive with -1 being return from the function-call and errno being set to this code. In the kernel, they are combined with 'error' being the negative of the return code. On Fri, 25 Jan 2008, Jack Harvard wrote: Hi, I'm trying to boot Linux, but the /init process failed. Here is the info: =FF6/init exit code: -14 /init exit code: -14 4Failed to execute /init Failed to execute /init 6/sbin/init exit code: -14 Just wondering what do those different exit codes mean? Thanks, -J -- Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [Patch] document ext3 requirements (was Re: [RFD] Incrementalfsck)
On Fri, 18 Jan 2008, Theodore Tso wrote: > On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote: >> But I heard some years ago from a disk drive engineer that that is a myth >> just like the rotational energy thing. I added that to the discussion, >> but admitted that I haven't actually seen a disk drive write a partial >> sector. > > Well, it would be impossible or at least very hard to see that in > practice, right? My understanding is that drives do sector-level > checksums, so if there was a partially written sector, the checksum > would be bogus and the drive would return an error when you tried to > read from it. > >> Ted brought up the separate issue of the host sending garbage to the disk >> device because its own power is failing at the same time, which makes the >> integrity at the disk level moot (or even undesirable, as you'd rather >> write a bad sector than a good one with the wrong data). > > Yep, exactly. It would be interesting to see if this happens on > modern hardware; all of the evidence I've had for this is years old at > this point. > > - Ted I have a Seagate Barracuda 7200.9 80 Gbyte SATA drive that I use for experiments. I can permanently destroy a EXT3 file-system at least 50% of the time by disconnecting the data cable while a `dd` write to a file is in progress. Something bad happens making partition information invalid. I have to re-partition to reuse the drive. If I try the same experiment by disconnecting power to the drive the file is no good (naturally), but the rest of the file-system is fine. My theory is that the destination offset is present in every SATA access and some optimization code within the drive sets the heads to track zero and writes before any CRC or checksum is done to find out if it was the correct offset with the correct data! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Communication between user process and kernel modules
On Fri, 18 Jan 2008, mokhtar wrote: > > Hi > > What are the different solution to make a user process communicate with a > kernel modules? > > Whatis the the advantages and disadvanteges of each solutions ? > ioctl() is the universal Unix mechanism for control of drivers (modules). open(), close(), read(), write(), mmap() are the other common methods. Some drivers may use sockets for communications. I such a case, you use setsockopt() to change things. Drivers can signal user-space processes as well. Such programs use select() and poll(). > > -- Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [Patch] document ext3 requirements (was Re: [RFD] Incrementalfsck)
On Fri, 18 Jan 2008, Theodore Tso wrote: On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote: But I heard some years ago from a disk drive engineer that that is a myth just like the rotational energy thing. I added that to the discussion, but admitted that I haven't actually seen a disk drive write a partial sector. Well, it would be impossible or at least very hard to see that in practice, right? My understanding is that drives do sector-level checksums, so if there was a partially written sector, the checksum would be bogus and the drive would return an error when you tried to read from it. Ted brought up the separate issue of the host sending garbage to the disk device because its own power is failing at the same time, which makes the integrity at the disk level moot (or even undesirable, as you'd rather write a bad sector than a good one with the wrong data). Yep, exactly. It would be interesting to see if this happens on modern hardware; all of the evidence I've had for this is years old at this point. - Ted I have a Seagate Barracuda 7200.9 80 Gbyte SATA drive that I use for experiments. I can permanently destroy a EXT3 file-system at least 50% of the time by disconnecting the data cable while a `dd` write to a file is in progress. Something bad happens making partition information invalid. I have to re-partition to reuse the drive. If I try the same experiment by disconnecting power to the drive the file is no good (naturally), but the rest of the file-system is fine. My theory is that the destination offset is present in every SATA access and some optimization code within the drive sets the heads to track zero and writes before any CRC or checksum is done to find out if it was the correct offset with the correct data! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Communication between user process and kernel modules
On Fri, 18 Jan 2008, mokhtar wrote: Hi What are the different solution to make a user process communicate with a kernel modules? Whatis the the advantages and disadvanteges of each solutions ? ioctl() is the universal Unix mechanism for control of drivers (modules). open(), close(), read(), write(), mmap() are the other common methods. Some drivers may use sockets for communications. I such a case, you use setsockopt() to change things. Drivers can signal user-space processes as well. Such programs use select() and poll(). -- Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is it possible to change IRQ for certain device?
On Thu, 10 Jan 2008, Jan Marek wrote: > Hello lkml, > > I have problem with my computer: I have motherboard with AMD690G chipset > and nVidia VGA card. But I cannot set BIOS, to assign for VGA unique > IRQ. VGA card is sharing IRQ with two ohci_hcd (USB 1.1 controllers). > But when I want use for X proprietary nvidia driver, X didn't work with > this errors: > > In dmesg: > > NVRM: RmInitAdapter failed! (0x23:0x:678) > NVRM: rm_init_adapter(0) failed > > and in /var/log/Xorg.0.log: > > (II) Setting vga for screen 0. > (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 > (==) NVIDIA(0): RGB weight 888 > (==) NVIDIA(0): Default visual is TrueColor > (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) > (**) NVIDIA(0): Enabling RENDER acceleration > (II) NVIDIA(0): Support for GLX with the Damage and Composite X > extensions is > (II) NVIDIA(0): enabled. > (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device > PCI:1:0:0. > (EE) NVIDIA(0): Please see the COMMON PROBLEMS section in the > README for > (EE) NVIDIA(0): additional information. > (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! > (EE) NVIDIA(0): *** Aborting *** > (II) UnloadModule: "nvidia" > (II) UnloadModule: "fb" > (EE) Screen(s) found, but none have a usable configuration. > > Fatal server error: > no screens found > > I've found in README for NVIDIA, that VGA has to have unique IRQ. I've > tried to set INTERRUPT_LINE and INTERRUPT_PIN with setpci tool, set > pci=routeirq, pci=noacpi as the kernel boot parameters, but IRQ > is still the same. > > Is there a way to change IRQ for VGA (or for ohci_hcd instead of VGA) > directly in Linux? > > Thanks a lot. > > Sincerely > Jan Marek The interrupt lines are set by the traces on the PC board and the contents of various "glue" chips and FPGAs. Many lap-tops, for instance, only have one IRQ serving any PCI devices. If your screen card can't share the only IRQ you have, it is broken. Contact the vendor of both your motherboard (they may have a BIOS upgrade) and the screen card (they may have a fix). Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is it possible to change IRQ for certain device?
On Thu, 10 Jan 2008, Jan Marek wrote: Hello lkml, I have problem with my computer: I have motherboard with AMD690G chipset and nVidia VGA card. But I cannot set BIOS, to assign for VGA unique IRQ. VGA card is sharing IRQ with two ohci_hcd (USB 1.1 controllers). But when I want use for X proprietary nvidia driver, X didn't work with this errors: In dmesg: NVRM: RmInitAdapter failed! (0x23:0x:678) NVRM: rm_init_adapter(0) failed and in /var/log/Xorg.0.log: (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (**) NVIDIA(0): Enabling RENDER acceleration (II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is (II) NVIDIA(0): enabled. (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device PCI:1:0:0. (EE) NVIDIA(0): Please see the COMMON PROBLEMS section in the README for (EE) NVIDIA(0): additional information. (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: nvidia (II) UnloadModule: fb (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found I've found in README for NVIDIA, that VGA has to have unique IRQ. I've tried to set INTERRUPT_LINE and INTERRUPT_PIN with setpci tool, set pci=routeirq, pci=noacpi as the kernel boot parameters, but IRQ is still the same. Is there a way to change IRQ for VGA (or for ohci_hcd instead of VGA) directly in Linux? Thanks a lot. Sincerely Jan Marek The interrupt lines are set by the traces on the PC board and the contents of various glue chips and FPGAs. Many lap-tops, for instance, only have one IRQ serving any PCI devices. If your screen card can't share the only IRQ you have, it is broken. Contact the vendor of both your motherboard (they may have a BIOS upgrade) and the screen card (they may have a fix). Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: uml and -regparm=3
On Wed, 9 Jan 2008, Miklos Szeredi wrote: > FASTCALL is defined empty in -mm, but UML is not compiled with > -mregparm=3 and so this breaks things (I noticed problems with > rwsem_down_write_failed). > > Tried recompiling UML with -mregparm=3, but that resulted in a strange > failure immediately after startup: > > |%Gÿÿ%@: Invalid argument > > What's up? > > Miklos > -- UML gets linked with the 'C' runtime library. It doesn't pass parameters in registers unless you get the source and recompile the whole thing --and then you would have to recompile all your applications, too. Yikes! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: uml and -regparm=3
On Wed, 9 Jan 2008, Miklos Szeredi wrote: FASTCALL is defined empty in -mm, but UML is not compiled with -mregparm=3 and so this breaks things (I noticed problems with rwsem_down_write_failed). Tried recompiling UML with -mregparm=3, but that resulted in a strange failure immediately after startup: |%Gÿÿ%@: Invalid argument What's up? Miklos -- UML gets linked with the 'C' runtime library. It doesn't pass parameters in registers unless you get the source and recompile the whole thing --and then you would have to recompile all your applications, too. Yikes! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: >> I need to get rid of -mregparm=3 on gcc's command line. It >> is completely incompatible with the standard calling conventions >> used in all our assembly-language files in our drivers. We make >> very high-speed number-crunching drivers that munge high-speed >> data into images. We need to do that in assembly as we have >> always done. > > Well I guess you can either fix the assembly once and for all to handle > the current linux way of doing things, or you can patch to kernel back > to the old ways of doing things when using your driver. > > I suppose you could just add some wrapper functions to your assembly > that uses the new regparm calling method and then calls your methods the > old way and selectively enable those when regparm is used by the kernel > if you want to support all kernel versions. Or you could use inline > assembly in C functions to handle the calling convention for you. > > -- > Len Sorensen > It's easier that that, just declare the assembly-language functions to be of type __attribute((regparm=0))__ or however you spell it (I'm not at my usual machine)! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote: >> Okay. Thanks! I need to do that. > > On the (now somewhat old) 2.6.18 kernel I use it is an option under > "Processor type and features" called "Use register arguments", but yeah > it isn't an option anymore in new kernels. > > As for your argument that it isn't a good idea, well most of the time > the arguments you want to pass to a function are already values you were > just working with to get them ready for the function, so quite likely > they are already in the registers you are worried about having to clear > first. Add to that the ability of modern x86 CPUs to use rename > registers to fake stack accesses in some cases and the clearing of the > registers become pretty much a non issue, at least that's my > understanding of how things work. > > -- > Len Sorensen > If the procedures in different files or are in libraries, there is no way for the compiler to "know." Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Bodo Eggert wrote: > linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: >> On Thu, 20 Dec 2007, Sam Ravnborg wrote: > >>>> It never gets to the printk(). You were right about the >>>> compilation. Somebody changed the kernel to compile with >>>> parameter passing in REGISTERS! This means that EVERYTHING >>>> needs to be compiled the same way, 'C' calling conventions >>>> were not good enough! >>> >>> How did you build the module. It reads like you failed to use >>> kbuild to build your module which is why you did not pass >>> correct options to gcc - correct? >>> >>> If you did not use kbuild - why not? >>> Is there anything missing you need? > >> I need to get rid of -mregparm=3 on gcc's command line. It >> is completely incompatible with the standard calling conventions >> used in all our assembly-language files in our drivers. We make >> very high-speed number-crunching drivers that munge high-speed >> data into images. We need to do that in assembly as we have >> always done. > > According to my quick googling, "__attribute__((regparm,0))" is what you need. > Yes, thanks! I don't need to change anything except the declarations of the assembly-language stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Bodo Eggert wrote: linux-os (Dick Johnson) [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. According to my quick googling, __attribute__((regparm,0)) is what you need. Yes, thanks! I don't need to change anything except the declarations of the assembly-language stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 05:56:19PM -0500, linux-os (Dick Johnson) wrote: Okay. Thanks! I need to do that. On the (now somewhat old) 2.6.18 kernel I use it is an option under Processor type and features called Use register arguments, but yeah it isn't an option anymore in new kernels. As for your argument that it isn't a good idea, well most of the time the arguments you want to pass to a function are already values you were just working with to get them ready for the function, so quite likely they are already in the registers you are worried about having to clear first. Add to that the ability of modern x86 CPUs to use rename registers to fake stack accesses in some cases and the clearing of the registers become pretty much a non issue, at least that's my understanding of how things work. -- Len Sorensen If the procedures in different files or are in libraries, there is no way for the compiler to know. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Fri, 21 Dec 2007, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. -- Len Sorensen It's easier that that, just declare the assembly-language functions to be of type __attribute((regparm=0))__ or however you spell it (I'm not at my usual machine)! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: >> >> On Thu, 20 Dec 2007, Sam Ravnborg wrote: >> >>>> >>>> It never gets to the printk(). You were right about the >>>> compilation. Somebody changed the kernel to compile with >>>> parameter passing in REGISTERS! This means that EVERYTHING >>>> needs to be compiled the same way, 'C' calling conventions >>>> were not good enough! >>> >>> How did you build the module. It reads like you failed to use >>> kbuild to build your module which is why you did not pass >>> correct options to gcc - correct? >>> >>> If you did not use kbuild - why not? >>> Is there anything missing you need? >>> >>> Sam >>> >> >> I need to get rid of -mregparm=3 on gcc's command line. It >> is completely incompatible with the standard calling conventions >> used in all our assembly-language files in our drivers. We make >> very high-speed number-crunching drivers that munge high-speed >> data into images. We need to do that in assembly as we have >> always done. > That I understand. So you need a CONFIG_ option to switch off > -regparm=3 and pray that the kernel assembly supports it. > > And then I assume you avoided kbuild because it added -regparm=3 > which is why your simple module broke. > > As you are well aware there is not any testing of a kernel without > -regparm=3 these days so you should strongly consider making your > assembly module comply with -regparm=3. > > And no - I dunno how much work that is and what impact it has > on your number chrunching stuff. > But it looks like the only sane long-term solution to me. > > Sam > I may be able to make a file full of "adapters" if I can figure out how to have a procedure that gets called with parameters in registers, with it calling conventional stuff. There used to be a macro, "asmlinkage" that corrected the calling conventions for assembly-language procedures. I will try to see what it did in some older kernels. It got taken out of newer ones. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Roland Dreier wrote:
> > It doesn't seem to be something in .config. Do you know how to
> > reconfigure to get parameter passing put back like it was? Our
> > production applications have lots of assembly-language files
> > and I'm sure we are not going to be able to change all those!
>
> 32-bit x86 uses regparm=3 by default now since commit a1a70c25 ("i386:
> always enable regparm"), which went in about a year ago. To go back
> to the old way, you'll just have to edit arch/x86/Makefile_32 (and
> rebuild your whole kernel from a clean tree, obviously).
Okay. Thanks! I need to do that.
>
> - R.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote: > On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: >> It never gets to the printk(). You were right about the >> compilation. Somebody changed the kernel to compile with >> parameter passing in REGISTERS! This means that EVERYTHING >> needs to be compiled the same way, 'C' calling conventions >> were not good enough! >> >> FYI, it has been previously shown that passing parameters >> in registers on register-starved ix86 machines is always >> a loss, because the registers need to be freed up, either >> by saving them on the stack or as dummy memory variables. >> >> Now, they've done it to the entire kernel! > > It's a config option. I think redhat was the first to actually start > using it on their distributions. Many distributions don't use it. > Debian does not use it on their kernels. > > -- > Len Sorensen > -- It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: >> >> It never gets to the printk(). You were right about the >> compilation. Somebody changed the kernel to compile with >> parameter passing in REGISTERS! This means that EVERYTHING >> needs to be compiled the same way, 'C' calling conventions >> were not good enough! > > How did you build the module. It reads like you failed to use > kbuild to build your module which is why you did not pass > correct options to gcc - correct? > > If you did not use kbuild - why not? > Is there anything missing you need? > > Sam > I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
>>
>> On Wed, 19 Dec 2007, Lennart Sorensen wrote:
>>
>>> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>>>>
>>>>
>>>> Here is a so-called BUG when trying to insert the following
>>>> module into the kernel (2.6.22.1).
>>>>
>>>>
>>>> BUG: unable to handle kernel paging request at virtual address 6814ec83
>>>> printing eip:
>>>> c016d013
>>>> *pde =
>>>> Oops: [#1]
>>>> PREEMPT SMP
>>>> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
>>>> iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat
>>>> dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery
>>>> ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod
>>>> scsi_mod
>>>> CPU:0
>>>> EIP:0060:[]Not tainted VLI
>>>> EFLAGS: 00010046 (2.6.22.1 #2)
>>>> EIP is at kmem_cache_alloc+0x23/0x80
>>>> eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
>>>> esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
>>>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>>>> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
>>>> Stack: f8913300 f8913013 f7fff880 00d0
>>>> ef27e000
>>>> c012b907 c0140279 bffedc07 bffedc08 0807a018
>>>>
>>>> c0102b82 0807a018 18c9 0807a008 bffeabc8
>>>> 0080
>>>> Call Trace:
>>>> [] init_module+0x13/0x48 [MemDev]
>>>> [] blocking_notifier_call_chain+0x17/0x20
>>>> [] sys_init_module+0xd9/0x140
>>>> [] sysenter_past_esp+0x5f/0x85
>>>> ===
>>>> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
>>>> 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0
>>>> 74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
>>>> EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>>>>
>>>>
>>>>
>>>> Here is the code that causes the crash.
>>>>
>>>>
>>>> #include
>>>> #include
>>>> #include
>>>> #include
>>>> #include
>>>> #include
>>>> static const char devname[]="Device";
>>>> #define NR_PAGES 0x10
>>>>
>>>> struct DMA {
>>>> void *ptr;
>>>> unsigned long addr;
>>>> size_t len;
>>>> };
>>>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>> //
>>>> // The top-level object that gets allocated once, when the module is
>>>> // installed.
>>>> //
>>>> struct INFO {
>>>> struct file_operations fa; // Kernel connection
>>>> struct semaphore dev_sem;
>>>> struct DMA dma[NR_PAGES]; // Can map one megabyte
>>>> uint32_t vm_start; // Where mmap() starts
>>>> uint32_t pages; // Number of pages mapped
>>>> atomic_t open; // Number of opens
>>>> };
>>>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>> static struct INFO *info;
>>>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>> //
>>>> // Initialize the module and return 0 if everything is okay.
>>>> // Return a negative error-code if not.
>>>> //
>>>> static int32_t startup()
>>>> {
>>>> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
>>>> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
>>>
>>> Missing space after KERN_ALERT?
>>
>> I certainly hope that it's not the problem! That would
>> invalidate both the kernel and the compiler!
>
> It was the only thing that looked a bit odd. Although white space
> generally shouldn't matter in C.
>
> Well maybe the module was just compiled against a different source tree
> than the running kernel it was loaded into.
>
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:56:45PM -0500, linux-os (Dick Johnson) wrote:
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat
dm_mod usbhid ff_memless uhci_hcd ehci_hcd video container button battery
ac rtc ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod
scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0
ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0
74 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
It was the only thing that looked a bit odd. Although white space
generally shouldn't matter in C.
Well maybe the module was just compiled against a different source tree
than the running kernel it was loaded into.
I suppose comment out the printk and see if it's breaking on that line
or somewhere else. Or just make it a printk with no variables.
--
Len Sorensen
It never gets to the printk(). You were right about the
compilation. Somebody changed the kernel to compile with
parameter passing in REGISTERS! This means that EVERYTHING
needs to be compiled the same way, 'C' calling conventions
were not good enough!
FYI, it has been previously shown that passing parameters
in registers on register-starved ix86 machines is always
a loss, because the registers need to be freed up, either
by saving them on the stack or as dummy memory variables.
Now, they've done it to the entire kernel!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! FYI, it has been previously shown that passing parameters in registers on register-starved ix86 machines is always a loss, because the registers need to be freed up, either by saving them on the stack or as dummy memory variables. Now, they've done it to the entire kernel! It's a config option. I think redhat was the first to actually start using it on their distributions. Many distributions don't use it. Debian does not use it on their kernels. -- Len Sorensen -- It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Roland Dreier wrote: It doesn't seem to be something in .config. Do you know how to reconfigure to get parameter passing put back like it was? Our production applications have lots of assembly-language files and I'm sure we are not going to be able to change all those! 32-bit x86 uses regparm=3 by default now since commit a1a70c25 (i386: always enable regparm), which went in about a year ago. To go back to the old way, you'll just have to edit arch/x86/Makefile_32 (and rebuild your whole kernel from a clean tree, obviously). Okay. Thanks! I need to do that. - R. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007, Sam Ravnborg wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? Sam I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. That I understand. So you need a CONFIG_ option to switch off -regparm=3 and pray that the kernel assembly supports it. And then I assume you avoided kbuild because it added -regparm=3 which is why your simple module broke. As you are well aware there is not any testing of a kernel without -regparm=3 these days so you should strongly consider making your assembly module comply with -regparm=3. And no - I dunno how much work that is and what impact it has on your number chrunching stuff. But it looks like the only sane long-term solution to me. Sam I may be able to make a file full of adapters if I can figure out how to have a procedure that gets called with parameters in registers, with it calling conventional stuff. There used to be a macro, asmlinkage that corrected the calling conventions for assembly-language procedures. I will try to see what it did in some older kernels. It got taken out of newer ones. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Jan Engelhardt wrote: > > On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote: > > >> I got rid of __init and anything else that I thought could cause the fault, > > I anticipate the day removing __init causes a breakage, heh. > I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it? > >> plus got rid of all the code! >> static int32_t startup() > > I noticed that. Where's your "void" gone? :-) What void??? Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
> On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
>>
>>
>> Here is a so-called BUG when trying to insert the following
>> module into the kernel (2.6.22.1).
>>
>>
>> BUG: unable to handle kernel paging request at virtual address 6814ec83
>> printing eip:
>> c016d013
>> *pde =
>> Oops: [#1]
>> PREEMPT SMP
>> Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
>> iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
>> usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc
>> ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
>> CPU:0
>> EIP:0060:[]Not tainted VLI
>> EFLAGS: 00010046 (2.6.22.1 #2)
>> EIP is at kmem_cache_alloc+0x23/0x80
>> eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
>> esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
>> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
>> Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
>> Stack: f8913300 f8913013 f7fff880 00d0
>> ef27e000
>> c012b907 c0140279 bffedc07 bffedc08 0807a018
>>
>> c0102b82 0807a018 18c9 0807a008 bffeabc8
>> 0080
>> Call Trace:
>> [] init_module+0x13/0x48 [MemDev]
>> [] blocking_notifier_call_chain+0x17/0x20
>> [] sys_init_module+0xd9/0x140
>> [] sysenter_past_esp+0x5f/0x85
>> ===
>> Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
>> 08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74
>> 25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
>> EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
>>
>>
>>
>> Here is the code that causes the crash.
>>
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> static const char devname[]="Device";
>> #define NR_PAGES 0x10
>>
>> struct DMA {
>> void *ptr;
>> unsigned long addr;
>> size_t len;
>> };
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> //
>> // The top-level object that gets allocated once, when the module is
>> // installed.
>> //
>> struct INFO {
>> struct file_operations fa; // Kernel connection
>> struct semaphore dev_sem;
>> struct DMA dma[NR_PAGES]; // Can map one megabyte
>> uint32_t vm_start; // Where mmap() starts
>> uint32_t pages; // Number of pages mapped
>> atomic_t open; // Number of opens
>> };
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> static struct INFO *info;
>> //-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> //
>> // Initialize the module and return 0 if everything is okay.
>> // Return a negative error-code if not.
>> //
>> static int32_t startup()
>> {
>> if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
>> printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
>
> Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
>
> --
> Len Sorensen
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
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/
Trying to convert old modules to newer kernels
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6
ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0 ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8 0080
Call Trace:
[] init_module+0x13/0x48 [MemDev]
[] blocking_notifier_call_chain+0x17/0x20
[] sys_init_module+0xd9/0x140
[] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08
89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 <8b> 02 85 c0 74 25 c7
42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include
#include
#include
#include
#include
#include
static const char devname[]="Device";
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT"%s : Can't allocate memory\n", devname);
return -ENOMEM;
}
return 0;
}
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Cleanup the module in preparation for removal.
//
static void quit() {
kfree(info);
printk(KERN_INFO"%s : Module removed\n", devname);
}
MODULE_LICENSE("GPL");
MODULE_ALIAS("MemDev");
module_init(startup);
module_exit(quit);
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Anybody have a clue why this should error out? Am I using
some reserved names??? I got rid of __init and anything
else that I thought could cause the fault, plus got rid
of all the code!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
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: Memory Read Error
On Tue, 18 Dec 2007, Robert Hancock wrote: > shashi59 wrote: >> I am newbie for Linux Kernel.How can I read the memory area like the range >> between to .Directly i read that area it shows some error >> like this "unable to handle kernel paging request at virtual address >> ". So,I don't know, how to solve this error .Please anyone help >> me > > First off, why are you trying to do this and how. Without such details > it's impossible to answer this question. > > -- > Robert Hancock Saskatoon, SK, Canada > To email, remove "nospam" from [EMAIL PROTECTED] > Home Page: http://www.roberthancock.com/ > A possible hint to the newbie, with possibly English as his last language, check out ioremap() and ioremap_nocache(). Within the kernel, these calls should allow any address to be read, even if nothing exists at that address. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Memory Read Error
On Tue, 18 Dec 2007, Robert Hancock wrote: shashi59 wrote: I am newbie for Linux Kernel.How can I read the memory area like the range between to .Directly i read that area it shows some error like this unable to handle kernel paging request at virtual address . So,I don't know, how to solve this error .Please anyone help me First off, why are you trying to do this and how. Without such details it's impossible to answer this question. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ A possible hint to the newbie, with possibly English as his last language, check out ioremap() and ioremap_nocache(). Within the kernel, these calls should allow any address to be read, even if nothing exists at that address. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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/
Trying to convert old modules to newer kernels
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc ipv6
ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0 ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8 0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24 08
89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0 74 25 c7
42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
return -ENOMEM;
}
return 0;
}
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Cleanup the module in preparation for removal.
//
static void quit() {
kfree(info);
printk(KERN_INFO%s : Module removed\n, devname);
}
MODULE_LICENSE(GPL);
MODULE_ALIAS(MemDev);
module_init(startup);
module_exit(quit);
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Anybody have a clue why this should error out? Am I using
some reserved names??? I got rid of __init and anything
else that I thought could cause the fault, plus got rid
of all the code!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
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: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Lennart Sorensen wrote:
On Wed, Dec 19, 2007 at 03:10:28PM -0500, linux-os (Dick Johnson) wrote:
Here is a so-called BUG when trying to insert the following
module into the kernel (2.6.22.1).
BUG: unable to handle kernel paging request at virtual address 6814ec83
printing eip:
c016d013
*pde =
Oops: [#1]
PREEMPT SMP
Modules linked in: MemDev parport_pc lp parport nfsd exportfs lockd sunrpc
iptable_filter ip_tables x_tables e1000 e100 mii nls_cp437 msdos fat dm_mod
usbhid ff_memless uhci_hcd ehci_hcd video container button battery ac rtc
ipv6 ext3 jbd ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod
CPU:0
EIP:0060:[c016d013]Not tainted VLI
EFLAGS: 00010046 (2.6.22.1 #2)
EIP is at kmem_cache_alloc+0x23/0x80
eax: ebx: 0246 ecx: f8913300 edx: 6814ec83
esi: edi: f8913000 ebp: ef27e000 esp: ef27ff74
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process insmod (pid: 4593, ti=ef27e000 task=f614f550 task.ti=ef27e000)
Stack: f8913300 f8913013 f7fff880 00d0
ef27e000
c012b907 c0140279 bffedc07 bffedc08 0807a018
c0102b82 0807a018 18c9 0807a008 bffeabc8
0080
Call Trace:
[f8913013] init_module+0x13/0x48 [MemDev]
[c012b907] blocking_notifier_call_chain+0x17/0x20
[c0140279] sys_init_module+0xd9/0x140
[c0102b82] sysenter_past_esp+0x5f/0x85
===
Code: 90 8d b4 26 00 00 00 00 83 ec 0c f6 c2 10 89 74 24 04 89 d6 89 7c 24
08 89 c7 89 1c 24 75 49 9c 5b fa 64 a1 04 20 47 c0 8b 14 87 8b 02 85 c0 74
25 c7 42 0c 01 00 00 00 48 89 02 8b 54 82 18 53
EIP: [c016d013] kmem_cache_alloc+0x23/0x80 SS:ESP 0068:ef27ff74
Here is the code that causes the crash.
#include linux/autoconf.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
#include linux/poll.h
#include linux/mm.h
static const char devname[]=Device;
#define NR_PAGES 0x10
struct DMA {
void *ptr;
unsigned long addr;
size_t len;
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// The top-level object that gets allocated once, when the module is
// installed.
//
struct INFO {
struct file_operations fa; // Kernel connection
struct semaphore dev_sem;
struct DMA dma[NR_PAGES]; // Can map one megabyte
uint32_t vm_start; // Where mmap() starts
uint32_t pages; // Number of pages mapped
atomic_t open; // Number of opens
};
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
static struct INFO *info;
//-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
//
// Initialize the module and return 0 if everything is okay.
// Return a negative error-code if not.
//
static int32_t startup()
{
if((info = kmalloc(sizeof(struct INFO), GFP_KERNEL)) == NULL) {
printk(KERN_ALERT%s : Can't allocate memory\n, devname);
Missing space after KERN_ALERT?
I certainly hope that it's not the problem! That would
invalidate both the kernel and the compiler!
--
Len Sorensen
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
--
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: Trying to convert old modules to newer kernels
On Wed, 19 Dec 2007, Jan Engelhardt wrote: On Dec 19 2007 15:10, linux-os (Dick Johnson) wrote: I got rid of __init and anything else that I thought could cause the fault, I anticipate the day removing __init causes a breakage, heh. I mean, if all in-tree modules and LDD3 use it, it can't be wrong, can it? plus got rid of all the code! static int32_t startup() I noticed that. Where's your void gone? :-) What void??? Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.28 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Fri, 14 Dec 2007, David P. Reed wrote:
> Avi Kivity wrote:
>> kvm will forward a virtual machine's writes to port 0x80 to the real
>> port. The reason is that the write is much faster than exiting and
>> emulating it; the difference is measurable when compiling kernels.
>>
>> Now if the cause is simply writing to port 0x80, then we must stop
>> doing that. But if the reason is the back-to-back writes, when we can
>> keep it, since the other writes will be trapped by kvm and emulated.
>> Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that. Is
> there a test you'd like me to try?
>
> I think you are also asking if the crash on these laptops is caused only
> by back-to-back writes. Actually, it doesn't seem to matter if they are
> back to back. I can cause the crash if the writes to 80 are very much
> spread out in time - it seems only to matter how many of them get
> executed - almost as if there is a buffer overflow. (And of course if
> you do back to back writes to other ports that are apparently fully
> unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from the
> chipset or motherboard vendor) that port 80 is actually functional for
> some unknown function on these machines. (They do respond to "in"
> instructions faster than a bus cycle abort does - more evidence).
>
> I searched the DSDT to see if there is any evidence of an ACPI use for
> this port, but found nothing.
>
>
Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.
The code works and is running here. I also patched a very early
version (2.4.26) running on a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.
David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.--- linux-2.6.22.1/include/asm-i386/io.h.orig 2007-07-10 14:56:30.0
-0400
+++ linux-2.6.22.1/include/asm-i386/io.h2007-12-17 12:06:10.0
-0500
@@ -252,7 +252,10 @@
static inline void native_io_delay(void)
{
- asm volatile("outb %%al,$0x80" : : : "memory");
+ asm volatile( "pushl %%eax\n\t"
+ "inb $0x80, %%al\n\t"
+ "popl %%eax\n\t"
+: : : "memory");
}
#if defined(CONFIG_PARAVIRT)
Re: [PATCH] x86_64: fix problems due to use of outb to port 80 on some AMD64x2 laptops, etc.
On Fri, 14 Dec 2007, David P. Reed wrote:
Avi Kivity wrote:
kvm will forward a virtual machine's writes to port 0x80 to the real
port. The reason is that the write is much faster than exiting and
emulating it; the difference is measurable when compiling kernels.
Now if the cause is simply writing to port 0x80, then we must stop
doing that. But if the reason is the back-to-back writes, when we can
keep it, since the other writes will be trapped by kvm and emulated.
Do you which is the case?
As for kvm, I don't have enough info to know anything about that. Is
there a test you'd like me to try?
I think you are also asking if the crash on these laptops is caused only
by back-to-back writes. Actually, it doesn't seem to matter if they are
back to back. I can cause the crash if the writes to 80 are very much
spread out in time - it seems only to matter how many of them get
executed - almost as if there is a buffer overflow. (And of course if
you do back to back writes to other ports that are apparently fully
unused, such as 0xED on my machine, no crash occurs).
I believe (though no one seems to have confirming documentation from the
chipset or motherboard vendor) that port 80 is actually functional for
some unknown function on these machines. (They do respond to in
instructions faster than a bus cycle abort does - more evidence).
I searched the DSDT to see if there is any evidence of an ACPI use for
this port, but found nothing.
Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.
The code works and is running here. I also patched a very early
version (2.4.26) running on a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.
David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.--- linux-2.6.22.1/include/asm-i386/io.h.orig 2007-07-10 14:56:30.0
-0400
+++ linux-2.6.22.1/include/asm-i386/io.h2007-12-17 12:06:10.0
-0500
@@ -252,7 +252,10 @@
static inline void native_io_delay(void)
{
- asm volatile(outb %%al,$0x80 : : : memory);
+ asm volatile( pushl %%eax\n\t
+ inb $0x80, %%al\n\t
+ popl %%eax\n\t
+: : : memory);
}
#if defined(CONFIG_PARAVIRT)
Re: Attitude problems.
On Wed, 12 Dec 2007, linux-os (Dick Johnson) wrote: > > On Wed, 12 Dec 2007, David P. Reed wrote: > >> Who has attitude problems here? I have indeed learned a lot about assholes. I hastily responded to this with some invective of my own. I wish to publicly apologize because I was just a bit hasty. Dr. Reed is a principle contributer to networking as we know it now, in particular, UDP. He is also known for "Reed's Law," which points out a problem with the scalability of large networks. Of course, none of this means that he is right or wrong about port 0x80 on these crappy Wintel machines. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Attitude problems.
On Wed, 12 Dec 2007, linux-os (Dick Johnson) wrote: On Wed, 12 Dec 2007, David P. Reed wrote: Who has attitude problems here? I have indeed learned a lot about assholes. I hastily responded to this with some invective of my own. I wish to publicly apologize because I was just a bit hasty. Dr. Reed is a principle contributer to networking as we know it now, in particular, UDP. He is also known for Reed's Law, which points out a problem with the scalability of large networks. Of course, none of this means that he is right or wrong about port 0x80 on these crappy Wintel machines. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Attitude problems.
On Wed, 12 Dec 2007, David P. Reed wrote: > Who has attitude problems here? I have indeed learned a lot about assholes. > > linux-os (Dick Johnson) wrote: >> Yep. We are all wrong. You come out of nowhere and claim to >> be right. Goodbye. >> Hmmm, I gave you every opportunity to back off your pretense of writing code for the IBM/PC before it existed. You insisted upon continuing your diatribe. You are the one with the attitude problem. FYI, the last COMPLETE BIOS I wrote is on-line at: http://www.AbominableFirebug.com/Sources/pbios.zip It was written seven years ago. The first one I helped write was written 36 years ago. I do know something about this stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [RESULTS] Port 0x80 I/O speed
On Wed, 12 Dec 2007, Rene Herman wrote: > Hi everyone. > > That was a succesful request, thanks to all who responded. This message also > just now went out with all the respondents in CC but I believe that copy > isn't making the list, so here's one without... > > In total you provided 60 reports which are listed below in increasing order > of time spent for an outb to port 0x0. Let's face it, these things are > competitions, and Chris has won! > > Time varies between 0.54 microseconds and 2.50 microseconds, with most > around 1.3/1.4 microseconds. Numbers 58, 59 and 60 (the ones at > 2 us) I > dont completely trust since similar machines are among the fastest as well. > > Note also that ISA isn't applicable to those 3... > > Most machines need no delays anywhere, and those that do would probably be > served with a udelay(1) as well but I believe this sampling is showing that > a udelay(2) would be the conservative choice. > > Thanks again to all those that responded. There's probably a few cut & paste > and/or math errors in the below. The jury can not be held accountable for > any missed prestige! > > Congrats to Chris... ;-) > > Cheers, > Rene But there are some things that get set up long before udelay() is calibrated! The interrupt controllers, the timer, etc. You can't just substitute or you will end up with machines that won't boot! grep /usr/src/linux-`uname -r`/arch/i386/kernel/*.c for lots of outb_p()'s! That's why the manufacturing port, 0x80, really needs to be used for I/O timing! If it kills that one machine, then that one machine is broken and needs to be fixed. It's probably an undetected error in a FPGA that once reported will get fixed. In fact, it might just be one motherboard and if that motherboard was replaced, the problem goes away. We have been there before. We can't "fix" stuff that's not broken without running the risk of breaking a lot more stuff. [Snipped...] Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [RFT] Port 0x80 I/O speed
On Wed, 12 Dec 2007, Rene Herman wrote: > On 12-12-07 13:59, linux-os (Dick Johnson) wrote: > >> On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote: > >>> On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get: >>> >>> cycles: out 1844674407370808, in 1844674407369087 >>> >>> It is not constant but variations are not significant afaics >>> >> >> It looks as though this hardware does not have a port 0x80 >> and its access is trapped by the hardware with a long time-out! >> This may be the reason when the _p was called "harmful" on this >> platform! >> >> I'm not sure the "rules" for port access allow for this kind of >> behavior. This design may be defective, needing to be brought >> to the attention of the vendor. A decent vendor would update >> a FPGA and provide code to burn a new BIOS. > > I'm afraid it's just the test that is "defective" as 64-bit code. For some > reason "=A" doesn't mean edx:eax on amd64 even though it's a useful register > pair to be able to name there as well. Didn't catch that being without amd64 > machines myself. > > Oh well. gcc -m32 fixes it... > > Rene. > Yep. By bad. I actually believed the returned value! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: > 1) I found in a book, the Undocumented PC, that I have lying around that > the "pause" recommended for some old adapter chips on the ISA bus was 1 > usec. The book carefully points out on various models of PCs how many > short jumps are required to implement 1 usec, and suggests that for > faster machines, 1 usec loops be calibrated. That seems like a good > heuristic. > > 2) Also, Dick, you got me interested in doing more historical research > into electrical specs and circuit diagrams (which did come with the IBM > 5150). The bus in the original IBM PC had no problem with "bus capacity > being charged" as you put it. Perhaps you don't remember that the I/O > bus had the same electrical characteristics as the memory bus. Thus > there is no issue with the bus being "charged". The issue of delays > between i/o instructions was entirely a problem of whether the adapter > card could clock data into its buffers and handle the clocked in data in > time for another bus cycle. This had nothing to do with "charging" - > buses in those days happily handled edges that were much faster than 1 usec. Wrong: the bus is not a clocked bus. Read a book. There is a "clock" trace provided, but it has nothing to do with the bus or its timing. The bus is not impedance-controlled, nor is it clocked. It relies upon certain established states. Look in the back of the IBM/PC book or read about the bus in http://www.techfest.com/hardware/nis/isa.htm and observe the bus-timing with no clock involved at all. > > We at Software Arts did what we did based on direct measurements and > testing. We found that the early BIOS listings were usually fine, but > in fact were misleading. After all, the guys who built the machine and > wrote the BIOS were in a hurry. There were errata. > Yep. We are all wrong. You come out of nowhere and claim to be right. Goodbye. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [RFT] Port 0x80 I/O speed
On Wed, 12 Dec 2007, Rene Herman wrote: On 12-12-07 13:59, linux-os (Dick Johnson) wrote: On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote: On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get: cycles: out 1844674407370808, in 1844674407369087 It is not constant but variations are not significant afaics It looks as though this hardware does not have a port 0x80 and its access is trapped by the hardware with a long time-out! This may be the reason when the _p was called harmful on this platform! I'm not sure the rules for port access allow for this kind of behavior. This design may be defective, needing to be brought to the attention of the vendor. A decent vendor would update a FPGA and provide code to burn a new BIOS. I'm afraid it's just the test that is defective as 64-bit code. For some reason =A doesn't mean edx:eax on amd64 even though it's a useful register pair to be able to name there as well. Didn't catch that being without amd64 machines myself. Oh well. gcc -m32 fixes it... Rene. Yep. By bad. I actually believed the returned value! Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: 1) I found in a book, the Undocumented PC, that I have lying around that the pause recommended for some old adapter chips on the ISA bus was 1 usec. The book carefully points out on various models of PCs how many short jumps are required to implement 1 usec, and suggests that for faster machines, 1 usec loops be calibrated. That seems like a good heuristic. 2) Also, Dick, you got me interested in doing more historical research into electrical specs and circuit diagrams (which did come with the IBM 5150). The bus in the original IBM PC had no problem with bus capacity being charged as you put it. Perhaps you don't remember that the I/O bus had the same electrical characteristics as the memory bus. Thus there is no issue with the bus being charged. The issue of delays between i/o instructions was entirely a problem of whether the adapter card could clock data into its buffers and handle the clocked in data in time for another bus cycle. This had nothing to do with charging - buses in those days happily handled edges that were much faster than 1 usec. Wrong: the bus is not a clocked bus. Read a book. There is a clock trace provided, but it has nothing to do with the bus or its timing. The bus is not impedance-controlled, nor is it clocked. It relies upon certain established states. Look in the back of the IBM/PC book or read about the bus in http://www.techfest.com/hardware/nis/isa.htm and observe the bus-timing with no clock involved at all. We at Software Arts did what we did based on direct measurements and testing. We found that the early BIOS listings were usually fine, but in fact were misleading. After all, the guys who built the machine and wrote the BIOS were in a hurry. There were errata. Yep. We are all wrong. You come out of nowhere and claim to be right. Goodbye. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [RESULTS] Port 0x80 I/O speed
On Wed, 12 Dec 2007, Rene Herman wrote: Hi everyone. That was a succesful request, thanks to all who responded. This message also just now went out with all the respondents in CC but I believe that copy isn't making the list, so here's one without... In total you provided 60 reports which are listed below in increasing order of time spent for an outb to port 0x0. Let's face it, these things are competitions, and Chris has won! Time varies between 0.54 microseconds and 2.50 microseconds, with most around 1.3/1.4 microseconds. Numbers 58, 59 and 60 (the ones at 2 us) I dont completely trust since similar machines are among the fastest as well. Note also that ISA isn't applicable to those 3... Most machines need no delays anywhere, and those that do would probably be served with a udelay(1) as well but I believe this sampling is showing that a udelay(2) would be the conservative choice. Thanks again to all those that responded. There's probably a few cut paste and/or math errors in the below. The jury can not be held accountable for any missed prestige! Congrats to Chris... ;-) Cheers, Rene But there are some things that get set up long before udelay() is calibrated! The interrupt controllers, the timer, etc. You can't just substitute or you will end up with machines that won't boot! grep /usr/src/linux-`uname -r`/arch/i386/kernel/*.c for lots of outb_p()'s! That's why the manufacturing port, 0x80, really needs to be used for I/O timing! If it kills that one machine, then that one machine is broken and needs to be fixed. It's probably an undetected error in a FPGA that once reported will get fixed. In fact, it might just be one motherboard and if that motherboard was replaced, the problem goes away. We have been there before. We can't fix stuff that's not broken without running the risk of breaking a lot more stuff. [Snipped...] Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Attitude problems.
On Wed, 12 Dec 2007, David P. Reed wrote: Who has attitude problems here? I have indeed learned a lot about assholes. linux-os (Dick Johnson) wrote: Yep. We are all wrong. You come out of nowhere and claim to be right. Goodbye. Hmmm, I gave you every opportunity to back off your pretense of writing code for the IBM/PC before it existed. You insisted upon continuing your diatribe. You are the one with the attitude problem. FYI, the last COMPLETE BIOS I wrote is on-line at: http://www.AbominableFirebug.com/Sources/pbios.zip It was written seven years ago. The first one I helped write was written 36 years ago. I do know something about this stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: > > > Alan Cox wrote: >> >> The vga driver is somewhat misnamed. In console mode we handle everything >> back to MDA/HGA and some HGA adapters do need delays. >> >> > No they don't. I really, really, really know this for a fact. I wrote > ASM drivers for every early video adapter and ran them all through Lotus > QA and Software Arts QA. Personally. The only delay needed is caused > by not having dual-ported video frame buffers on the original CGA in > high res character mode. This caused "snow" when a memory write was done > concurrently with the read being done by the scanline character > generator. And that delay was done by waiting for a bit in the I/O port > space to change. There was NO reason to do waits between I/O > instructions. Produce a spec sheet, or even better a machine. I may > have an original PC-XT still lying around in the attic, don't know if I > can fire it up, but it had such graphics cards. I also have several > early high-speed clones that were "overclocked". > >>> I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - >>> other ports have been used in the history of the IBM PC family by some >>> vendors, and some machines have used it for DMA port mapping!! And >>> >> >> All do -thats why it is suitable. >> > Not true. Again, I can produce machines that don't use 0x80. Perhaps > that is because I am many years older than you are, and have been > writing code for PC compatibles since 1981. (not a typo - this was > before the first IBM PC was released to the public). Hmmm, I didn't know you worked in Boca Raton for Don Estrage on the IBM 5150. I must have missed you --somehow. [Snipped...] You do remember that the X86 can do back-to-back port instructions faster than the ISA bus capacity can be charged, don't you? You do remember the admonishment about: intel asm mov dx, port; One of two adjacent ports mov al,ffh ; All bits set out dx,al ; Output to port, bits start charging bus inc al ; Al becomes 0 inc dx ; Next port out dx,al ; Write 0 there, data bits discharged When the port at 'port' gets its data, it will likely be 0, not 0xff, because the intervening instructions can execute faster than a heavily-loaded ISA bus. So, with a true ISA/EISA bus, not an emulated one off a bridge, you have to worry about this. In the IBM/PC BIOS listing, supplied with every early real PC, it was called "bus settle time." Remember? If not, you never wrote code for that platform. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David Newall wrote: > Rene Herman wrote: >> This particular discussion isn't about anything in general but solely >> about the delay an outb_p gives you on x86 since what is under >> discussion is not using an output to port 0x80 on that platform to >> generate it. > > That could be true if outb_p were used only in architecture dependent > code, but it's not. It's used in drivers that are supposed to run on > all sorts of platforms. Why does a megaraid controller need delays on > i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most > platforms, or just unnecessarily slow on Intel? > >>> is needed, wouldn't you use a real delay; one that says how long it >>> should be? >> Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay >> >> Because any possible outb_p delay should be synced to the bus-clock, >> not to any wall-clock. > > You misunderstand. A delay can be counted in bus cycles. > >> In the real world, driver authors aren't perfect and will have used >> outb_p as a wall-clock delay which they have gotten away with since >> it's a nicely specified delay in terms of the ISA/LPC clock and the >> ISA/LPC clock being fairly (old) to very (new) constant. > > It's most commonly a zero delay. Only in the minority of architectures > is it otherwise. If a delay is needed, then put one in, but don't put > in a paper promise that's more likely to be ignored than observed. > > Plenty of doubt has been expressed as to whether _p is widely used > without need. Not surprising since it has such a vague specific > meaning. One could say, Linux on i386 is liberally sprinkled with > needless delays. I suppose it has the advantage that Microsoft will be > hard pressed to catch up when finally we remove them. :-) > > I really prefer accurate code, but I'm also pragmatic and realise that > it's far too much work to fix this any time soon. But if it were to be > fixed, then perhaps _p would take an additional parameter, measured in > cycles of delay. > -- Most, probably most-all, of the delays to port operations on modern ix86 machines are not needed at all. Certainly machines that use bridges to expand port I/O to the ISA bus do need any such delays. There are exactly two (and only two) problems with removing the delays. (1) Older machines which have an actual ISA bus with its attendent capacity that needs to be charged long enough for the data to become valid --before being overwritten by new data. (2) I/O operations that have two ports, one an index port and the other a data port, like the CMOS RTC. Once you set the index port, it takes about 300 ns for it to propigate to the hardware, so there needs to be some delay between the back-to-back CPU operations which can occur much faster than that. On this machine, I have changed all the _p macros so they don't do anything. Since it is a modern machine with N/S bridges, which provide their own delays, everything works. Such would not be the case if I was using a machine that had an actual ISA (or PC-104) bus. Those are not terminated busses, but open-ended capacitors made up of connectors and PC traces. It takes about 300 ns to charge one of those (so 1us is a good dalay). BYW, there are no "transactions" on the ISA or EISA bus. It works by using a sequence of operations with minimum setup and hold times. It's very primative. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David Newall wrote: Rene Herman wrote: This particular discussion isn't about anything in general but solely about the delay an outb_p gives you on x86 since what is under discussion is not using an output to port 0x80 on that platform to generate it. That could be true if outb_p were used only in architecture dependent code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? is needed, wouldn't you use a real delay; one that says how long it should be? Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay Because any possible outb_p delay should be synced to the bus-clock, not to any wall-clock. You misunderstand. A delay can be counted in bus cycles. In the real world, driver authors aren't perfect and will have used outb_p as a wall-clock delay which they have gotten away with since it's a nicely specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being fairly (old) to very (new) constant. It's most commonly a zero delay. Only in the minority of architectures is it otherwise. If a delay is needed, then put one in, but don't put in a paper promise that's more likely to be ignored than observed. Plenty of doubt has been expressed as to whether _p is widely used without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with needless delays. I suppose it has the advantage that Microsoft will be hard pressed to catch up when finally we remove them. :-) I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. -- Most, probably most-all, of the delays to port operations on modern ix86 machines are not needed at all. Certainly machines that use bridges to expand port I/O to the ISA bus do need any such delays. There are exactly two (and only two) problems with removing the delays. (1) Older machines which have an actual ISA bus with its attendent capacity that needs to be charged long enough for the data to become valid --before being overwritten by new data. (2) I/O operations that have two ports, one an index port and the other a data port, like the CMOS RTC. Once you set the index port, it takes about 300 ns for it to propigate to the hardware, so there needs to be some delay between the back-to-back CPU operations which can occur much faster than that. On this machine, I have changed all the _p macros so they don't do anything. Since it is a modern machine with N/S bridges, which provide their own delays, everything works. Such would not be the case if I was using a machine that had an actual ISA (or PC-104) bus. Those are not terminated busses, but open-ended capacitors made up of connectors and PC traces. It takes about 300 ns to charge one of those (so 1us is a good dalay). BYW, there are no transactions on the ISA or EISA bus. It works by using a sequence of operations with minimum setup and hold times. It's very primative. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: Alan Cox wrote: The vga driver is somewhat misnamed. In console mode we handle everything back to MDA/HGA and some HGA adapters do need delays. No they don't. I really, really, really know this for a fact. I wrote ASM drivers for every early video adapter and ran them all through Lotus QA and Software Arts QA. Personally. The only delay needed is caused by not having dual-ported video frame buffers on the original CGA in high res character mode. This caused snow when a memory write was done concurrently with the read being done by the scanline character generator. And that delay was done by waiting for a bit in the I/O port space to change. There was NO reason to do waits between I/O instructions. Produce a spec sheet, or even better a machine. I may have an original PC-XT still lying around in the attic, don't know if I can fire it up, but it had such graphics cards. I also have several early high-speed clones that were overclocked. I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - other ports have been used in the history of the IBM PC family by some vendors, and some machines have used it for DMA port mapping!! And All do -thats why it is suitable. Not true. Again, I can produce machines that don't use 0x80. Perhaps that is because I am many years older than you are, and have been writing code for PC compatibles since 1981. (not a typo - this was before the first IBM PC was released to the public). Hmmm, I didn't know you worked in Boca Raton for Don Estrage on the IBM 5150. I must have missed you --somehow. [Snipped...] You do remember that the X86 can do back-to-back port instructions faster than the ISA bus capacity can be charged, don't you? You do remember the admonishment about: intel asm mov dx, port; One of two adjacent ports mov al,ffh ; All bits set out dx,al ; Output to port, bits start charging bus inc al ; Al becomes 0 inc dx ; Next port out dx,al ; Write 0 there, data bits discharged When the port at 'port' gets its data, it will likely be 0, not 0xff, because the intervening instructions can execute faster than a heavily-loaded ISA bus. So, with a true ISA/EISA bus, not an emulated one off a bridge, you have to worry about this. In the IBM/PC BIOS listing, supplied with every early real PC, it was called bus settle time. Remember? If not, you never wrote code for that platform. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Possible EXT2 race
On Fri, 7 Dec 2007, Dave Jones wrote: > On Fri, Dec 07, 2007 at 08:15:42AM -0500, linux-os (Dick Johnson) wrote: > > > Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Add. Sense: Peripheral > > device write fault > > This sounds more like a hardware problem. > > Dave > There was an attempt to write beyond the end of the device because everything in the file-system was getting trashed. I can read/write the 5 year-old SCSI physical drive with no errors from both within linux and through the Adaptec BIOS. This problem only occurs when I attempt to truncate a file that is being written by another task. > -- > http://www.codemonkey.org.uk > Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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/
Possible EXT2 race
On linux-2.6.22.1, executing the following script while the mailer is writing to /var/spool/mail/linux-os. #!/bin/bash while true ; do >/var/spool/mail/linux-os; sleep 1; done ...will cause the following errors to occur. Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Sense Key : No Sense [deferred] Dec 7 04:05:55 chaos kernel: Info fld=0x1980240 Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Add. Sense: Peripheral device write fault Dec 7 04:08:13 chaos kernel: attempt to access beyond end of device Dec 7 04:08:13 chaos kernel: sdb1: rw=0, want=29687515944, limit=33736437 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_xattr_delete_inode: inode 656387: block -584027804 read error Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710940964, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 4294967295, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 4294967295, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710940980, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710940980, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: bit already cleared for block 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710941012, count = 1 Dec 7 04:08:13 chaos kernel: attempt to access beyond end of device Dec 7 04:08:13 chaos kernel: sdb1: rw=0, want=29687528104, limit=33736437 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_branches: Read failure, inode=656399, block=-584026284 Dec 7 04:08:13 chaos kernel: attempt to access beyond end of device Dec 7 04:08:13 chaos kernel: sdb1: rw=0, want=29687529288, limit=33736437 Dec 7 04:08:15 chaos kernel: EXT2-fs error (device sdb1): ext2_xattr_delete_inode: inode 656400: block -584026136 read error Dec 7 04:08:18 chaos kernel: EXT2-fs error (device sdb1): ext2_xattr_delete_inode: inode 656403: bad block 30188 Caution is advised when testing because this destroyed a filesystem, making it unfixable by `fsck`. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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/
Possible EXT2 race
On linux-2.6.22.1, executing the following script while the mailer is writing to /var/spool/mail/linux-os. #!/bin/bash while true ; do /var/spool/mail/linux-os; sleep 1; done ...will cause the following errors to occur. Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Sense Key : No Sense [deferred] Dec 7 04:05:55 chaos kernel: Info fld=0x1980240 Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Add. Sense: Peripheral device write fault Dec 7 04:08:13 chaos kernel: attempt to access beyond end of device Dec 7 04:08:13 chaos kernel: sdb1: rw=0, want=29687515944, limit=33736437 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_xattr_delete_inode: inode 656387: block -584027804 read error Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710940964, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 4294967295, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 4294967295, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710940980, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710940980, count = 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: bit already cleared for block 1 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_blocks: Freeing blocks not in datazone - block = 3710941012, count = 1 Dec 7 04:08:13 chaos kernel: attempt to access beyond end of device Dec 7 04:08:13 chaos kernel: sdb1: rw=0, want=29687528104, limit=33736437 Dec 7 04:08:13 chaos kernel: EXT2-fs error (device sdb1): ext2_free_branches: Read failure, inode=656399, block=-584026284 Dec 7 04:08:13 chaos kernel: attempt to access beyond end of device Dec 7 04:08:13 chaos kernel: sdb1: rw=0, want=29687529288, limit=33736437 Dec 7 04:08:15 chaos kernel: EXT2-fs error (device sdb1): ext2_xattr_delete_inode: inode 656400: block -584026136 read error Dec 7 04:08:18 chaos kernel: EXT2-fs error (device sdb1): ext2_xattr_delete_inode: inode 656403: bad block 30188 Caution is advised when testing because this destroyed a filesystem, making it unfixable by `fsck`. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Possible EXT2 race
On Fri, 7 Dec 2007, Dave Jones wrote: On Fri, Dec 07, 2007 at 08:15:42AM -0500, linux-os (Dick Johnson) wrote: Dec 7 04:05:55 chaos kernel: sd 0:0:1:0: [sdb] Add. Sense: Peripheral device write fault This sounds more like a hardware problem. Dave There was an attempt to write beyond the end of the device because everything in the file-system was getting trashed. I can read/write the 5 year-old SCSI physical drive with no errors from both within linux and through the Adaptec BIOS. This problem only occurs when I attempt to truncate a file that is being written by another task. -- http://www.codemonkey.org.uk Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is the PCI clock within the spec?
On Tue, 4 Dec 2007, John Sigler wrote: > Dick Johnson wrote: > >> You can't just touch a scope-probe to the PCI >> clock pin and clip the scope-probe grounding >> lead to a convenient "ground" to make these >> measurements! You need a special fixture that >> will make a low-inductance connection to the >> PCI bus in the same manner as the interface chip. > > (This is waaay over my head.) > > Why do you think the two plots (at least the second one) > were not obtained as you describe? > They didn't describe the test setup, simply supplied a "go away and don't bother me" picture of something that means nothing. > > Why would the system manufacturer botch the measurements > when I asked them to show me evidence that their system > was compliant? > I think they just sent you a picture, thinking it would make you go away. It is a common ploy. >> A scope probe will allow you to see if there is >> a clock signal. That's all. You can't determine >> its quality. A 4-inch ground lead on the scope >> probe will result in 10-20% overshoot and undershoot >> being observed. > > I don't understand this 10-20% figure. > (0V + 10-20% is still 0V.) > There is a definition of overshoot and undershoot. 10 percent undershoot will show a 0->3.3 volt signal going 0.33 volts below "ground," i.e., -0.33 V on peaks. 10 percent overshoot will show a 0->3.3 volt signal going to 3.63 volts above ground on peaks, i.e., +3.63 volts. > AFAIU, the nominal peak-to-peak voltage is 3.3V. The observed > peak-to-peak voltage is 6.08V (3.3V + 84%). > This may be a "5 volt" bus. 3.3 volt devices are supposedly 5 volt tolerant. For instance, the PLX, PCI 9656BA, probably the most common PCI interface chip in use, will handle those voltages fine. The actual logic-level switch occurs at about 1.5 volts. Since the PCI bus is clocked, it is unlikely that a "lockup" you describe is caused by the bus, more likely a hung DMA operation caused by a failure to handle errors (hardware or software, cause unknown). With the chip I describe, it can be programmed so that it will not hold the bus "forever," with a hung DMA operation. However, some cooperation with the stuff in your FPGA as well as the software in the driver is necessary. > Regards. > Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is the PCI clock within the spec?
On Tue, 4 Dec 2007, John Sigler wrote: > Hello Sébastien, > > Sébastien Dugué wrote: > >> John Sigler wrote: >> >>> I have an x86 system, running Linux 2.6.22.1-rt9, in which I plug one >>> or two PCI I/O boards. I had been experiencing complete system lock-ups >>> until I sent the system to the board manufacturer, and he fixed the >>> problem. However, he told me that the PCI clock seemed out of spec, >>> as far as voltage is concerned. >>> >>> (Disclaimer: my knowledge of PCI is 0.) >>> >>> The board manufacturer sent me the plot of (what appears to be) voltage >>> versus time for the PCI clock. >>> >>> http://linux.kernel.free.fr/plot1.jpg >>> >>> The system manufacturer sent me a similar plot. >>> >>> http://linux.kernel.free.fr/plot2.jpg >> >> Why did they send you those plots? What was their point? > > The board manufacturer originally thought that the voltage under- > and overshot might be responsible for the system lock-ups we were > experiencing. They sent us the first plot to document the problem. > (In the end, the lock-up was linked to a bug in their DMA engine.) > I asked the system manufacturer whether they could reproduce the > voltage issue, and they sent me the second plot. > >>> As far as my understanding goes, the signal should alternate between >>> 0 V and 3.3 V (??). >> >> Yep, that's the idealized 3.3V signaling case. However, it looks like >> the signal is overshooting a bit (-0.8V below 0 and +0.8V over 3.3V from >> looking >> at the 1st plot) which may be due to incorrect impedance matching on the bus, >> probes artifacts, ... >> >>> In the second plot, it looks like Vmax ~ 4.6V >>> and Vmin ~ -1.4V (Pk-Pk(C1)=6.08V might mean peak-to-peak voltage?) >> >> This one looks a bit high (if they measured the same voltages I wonder >> where they got their scopes calibrated ;-) ) > > The first plot was obtained on my system. The second plot was obtained > on a different system, presumably identical to mine, but I don't know > for sure. > >>> 0) What is this C1 both plots mention? >> >> Scope Channel 1 >> >>> 1) Am I reading the plot correctly? >> >> Yep >> >>> 2) Is -1.4V in DC even possible? >> >> Why not! > > Errr... I need to think about it :-) > >>> 3) 4.6V is 1.3V above 3.3V and -1.4V is -1.4V below 0. (Assuming I read >>> the numbers correctly) Are these values within the PCI spec? Or are >>> these voltages dangerous and / or might cause some problems with some >>> PCI boards? >> >> Well it depends on which of the plot is lying. Looking at the PCI spec >> (4.2.2.1) the Vih max for a device is Vcc-max+0.5 = 3.6 + 0.5 = 4.1V >> the Vil min is -0.5V so in this case it looks a bit high. But I would not >> worry too much, those are only the overshoots, and the circuits have >> clamping diodes on their inputs. >> >> The test waveform voltages for the maximum ratings (4.2.2.3) against which >> every PCI device should be qualified are higher than what you have here: 7.1V >> peak-to-peak. > > OK. I suppose I should not worry then :-) > >> Hope this helps. > > Very much! Thanks. > > Regards. > You can't just touch a scope-probe to the PCI clock pin and clip the scope-probe grounding lead to a convenient "ground" to make these measurements! You need a special fixture that will make a low-inductance connection to the PCI bus in the same manner as the interface chip. A scope probe will allow you to see if there is a clock signal. That's all. You can't determine its quality. A 4-inch ground lead on the scope probe will result in 10-20% overshoot and undershoot being observed. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is the PCI clock within the spec?
On Tue, 4 Dec 2007, John Sigler wrote: Hello Sébastien, Sébastien Dugué wrote: John Sigler wrote: I have an x86 system, running Linux 2.6.22.1-rt9, in which I plug one or two PCI I/O boards. I had been experiencing complete system lock-ups until I sent the system to the board manufacturer, and he fixed the problem. However, he told me that the PCI clock seemed out of spec, as far as voltage is concerned. (Disclaimer: my knowledge of PCI is 0.) The board manufacturer sent me the plot of (what appears to be) voltage versus time for the PCI clock. http://linux.kernel.free.fr/plot1.jpg The system manufacturer sent me a similar plot. http://linux.kernel.free.fr/plot2.jpg Why did they send you those plots? What was their point? The board manufacturer originally thought that the voltage under- and overshot might be responsible for the system lock-ups we were experiencing. They sent us the first plot to document the problem. (In the end, the lock-up was linked to a bug in their DMA engine.) I asked the system manufacturer whether they could reproduce the voltage issue, and they sent me the second plot. As far as my understanding goes, the signal should alternate between 0 V and 3.3 V (??). Yep, that's the idealized 3.3V signaling case. However, it looks like the signal is overshooting a bit (-0.8V below 0 and +0.8V over 3.3V from looking at the 1st plot) which may be due to incorrect impedance matching on the bus, probes artifacts, ... In the second plot, it looks like Vmax ~ 4.6V and Vmin ~ -1.4V (Pk-Pk(C1)=6.08V might mean peak-to-peak voltage?) This one looks a bit high (if they measured the same voltages I wonder where they got their scopes calibrated ;-) ) The first plot was obtained on my system. The second plot was obtained on a different system, presumably identical to mine, but I don't know for sure. 0) What is this C1 both plots mention? Scope Channel 1 1) Am I reading the plot correctly? Yep 2) Is -1.4V in DC even possible? Why not! Errr... I need to think about it :-) 3) 4.6V is 1.3V above 3.3V and -1.4V is -1.4V below 0. (Assuming I read the numbers correctly) Are these values within the PCI spec? Or are these voltages dangerous and / or might cause some problems with some PCI boards? Well it depends on which of the plot is lying. Looking at the PCI spec (4.2.2.1) the Vih max for a device is Vcc-max+0.5 = 3.6 + 0.5 = 4.1V the Vil min is -0.5V so in this case it looks a bit high. But I would not worry too much, those are only the overshoots, and the circuits have clamping diodes on their inputs. The test waveform voltages for the maximum ratings (4.2.2.3) against which every PCI device should be qualified are higher than what you have here: 7.1V peak-to-peak. OK. I suppose I should not worry then :-) Hope this helps. Very much! Thanks. Regards. You can't just touch a scope-probe to the PCI clock pin and clip the scope-probe grounding lead to a convenient ground to make these measurements! You need a special fixture that will make a low-inductance connection to the PCI bus in the same manner as the interface chip. A scope probe will allow you to see if there is a clock signal. That's all. You can't determine its quality. A 4-inch ground lead on the scope probe will result in 10-20% overshoot and undershoot being observed. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: Is the PCI clock within the spec?
On Tue, 4 Dec 2007, John Sigler wrote: Dick Johnson wrote: You can't just touch a scope-probe to the PCI clock pin and clip the scope-probe grounding lead to a convenient ground to make these measurements! You need a special fixture that will make a low-inductance connection to the PCI bus in the same manner as the interface chip. (This is waaay over my head.) Why do you think the two plots (at least the second one) were not obtained as you describe? They didn't describe the test setup, simply supplied a go away and don't bother me picture of something that means nothing. Why would the system manufacturer botch the measurements when I asked them to show me evidence that their system was compliant? I think they just sent you a picture, thinking it would make you go away. It is a common ploy. A scope probe will allow you to see if there is a clock signal. That's all. You can't determine its quality. A 4-inch ground lead on the scope probe will result in 10-20% overshoot and undershoot being observed. I don't understand this 10-20% figure. (0V + 10-20% is still 0V.) There is a definition of overshoot and undershoot. 10 percent undershoot will show a 0-3.3 volt signal going 0.33 volts below ground, i.e., -0.33 V on peaks. 10 percent overshoot will show a 0-3.3 volt signal going to 3.63 volts above ground on peaks, i.e., +3.63 volts. AFAIU, the nominal peak-to-peak voltage is 3.3V. The observed peak-to-peak voltage is 6.08V (3.3V + 84%). This may be a 5 volt bus. 3.3 volt devices are supposedly 5 volt tolerant. For instance, the PLX, PCI 9656BA, probably the most common PCI interface chip in use, will handle those voltages fine. The actual logic-level switch occurs at about 1.5 volts. Since the PCI bus is clocked, it is unlikely that a lockup you describe is caused by the bus, more likely a hung DMA operation caused by a failure to handle errors (hardware or software, cause unknown). With the chip I describe, it can be programmed so that it will not hold the bus forever, with a hung DMA operation. However, some cooperation with the stuff in your FPGA as well as the software in the driver is necessary. Regards. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- 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: [KERNEL]: Avoid divide in IS_ALIGN
On Tue, 20 Nov 2007, Richard B. Johnson wrote:
> On Tue, 20 Nov 2007, Herbert Xu wrote:
>
>> Hi:
>>
>> [KERNEL]: Avoid divide in IS_ALIGN
>>
>> I was happy to discover the brand new IS_ALIGN macro and quickly
>> used it in my code. To my dismay I found that the generated code
>> used division to perform the test.
>>
>> This patch fixes it by changing the % test to an &. This avoids
>> the division.
>>
>> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>>
>> Cheers,
>> --
>> Visit Openswan at http://www.openswan.org/
>> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
>> Home Page: http://gondor.apana.org.au/~herbert/
>> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>> --
>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>> index 94bc996..39b3fa6 100644
>> --- a/include/linux/kernel.h
>> +++ b/include/linux/kernel.h
>> @@ -35,7 +35,7 @@ extern const char linux_proc_banner[];
>> #define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1)
>> #define __ALIGN_MASK(x,mask) (((x)+(mask))&~(mask))
>> #define PTR_ALIGN(p, a) ((typeof(p))ALIGN((unsigned long)(p),
>> (a)))
>> -#define IS_ALIGNED(x,a) (((x) % ((typeof(x))(a))) == 0)
>> +#define IS_ALIGNED(x, a)(((x) & ((typeof(x))(a) - 1)) == 0)
>>
>
> Your macro modification is wrong.
There was a brain fart on the explaination of why it's wrong.
Here is a better explaination.
Executing this script.
cat
Re: [KERNEL]: Avoid divide in IS_ALIGN
On Tue, 20 Nov 2007, Richard B. Johnson wrote:
On Tue, 20 Nov 2007, Herbert Xu wrote:
Hi:
[KERNEL]: Avoid divide in IS_ALIGN
I was happy to discover the brand new IS_ALIGN macro and quickly
used it in my code. To my dismay I found that the generated code
used division to perform the test.
This patch fixes it by changing the % test to an . This avoids
the division.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 94bc996..39b3fa6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -35,7 +35,7 @@ extern const char linux_proc_banner[];
#define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1)
#define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask))
#define PTR_ALIGN(p, a) ((typeof(p))ALIGN((unsigned long)(p),
(a)))
-#define IS_ALIGNED(x,a) (((x) % ((typeof(x))(a))) == 0)
+#define IS_ALIGNED(x, a)(((x) ((typeof(x))(a) - 1)) == 0)
Your macro modification is wrong.
There was a brain fart on the explaination of why it's wrong.
Here is a better explaination.
Executing this script.
cat EOF /tmp/xxx.c
#include stdio.h
#define IS_ALIGNED(x,a) (((x) % ((typeof(x))(a))) == 0)
#define _IS_ALIGNED(x, a) (((x) ((typeof(x))(a) - 1)) == 0)
int main()
{
int i;
long p = 0x12345678;
for(i=1; i 0x11; i++)
printf(Old = %d, new = %d\n, IS_ALIGNED(p, i), _IS_ALIGNED(p, i));
return 0;
}
EOF
gcc -Wall -o /tmp/xxx /tmp/xxx.c
/tmp/xxx
... produces:
Old = 1, new = 1
Old = 1, new = 1
Old = 1, new = 1
Old = 1, new = 1
Old = 0, new = 1
Old = 1, new = 1
Old = 0, new = 1
Old = 1, new = 1
Old = 1, new = 0
Old = 0, new = 0
Old = 0, new = 0
Old = 1, new = 0
Old = 0, new = 0
Old = 0, new = 0
Old = 0, new = 0
Old = 0, new = 0
Which is clearly different.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
-
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: [KERNEL]: Avoid divide in IS_ALIGN
On Tue, 20 Nov 2007, Herbert Xu wrote:
> Hi:
>
> [KERNEL]: Avoid divide in IS_ALIGN
>
> I was happy to discover the brand new IS_ALIGN macro and quickly
> used it in my code. To my dismay I found that the generated code
> used division to perform the test.
>
> This patch fixes it by changing the % test to an &. This avoids
> the division.
>
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 94bc996..39b3fa6 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -35,7 +35,7 @@ extern const char linux_proc_banner[];
> #define ALIGN(x,a)__ALIGN_MASK(x,(typeof(x))(a)-1)
> #define __ALIGN_MASK(x,mask) (((x)+(mask))&~(mask))
> #define PTR_ALIGN(p, a) ((typeof(p))ALIGN((unsigned long)(p),
> (a)))
> -#define IS_ALIGNED(x,a) (((x) % ((typeof(x))(a))) == 0)
> +#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
>
Your macro modification is wrong.
Take 0x12345600, which is aligned on a 16-byte boundary.
Now, with your macro, we have for a 0x10 alignment:
(0x12345600 & 0x0f) = (0x00 == 0) == TRUE (correct)
For an 0x20 alignment:
(0x12345600 & 0x1f) = (0x00 == 0) == TRUE (incorrect)
In other words, the macro may work for some alignments, but
not all. It is therefore wrong. You need the modulus, the
remainder after division. Anything else is broken.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
-
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: [KERNEL]: Avoid divide in IS_ALIGN
On Tue, 20 Nov 2007, Herbert Xu wrote:
Hi:
[KERNEL]: Avoid divide in IS_ALIGN
I was happy to discover the brand new IS_ALIGN macro and quickly
used it in my code. To my dismay I found that the generated code
used division to perform the test.
This patch fixes it by changing the % test to an . This avoids
the division.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 94bc996..39b3fa6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -35,7 +35,7 @@ extern const char linux_proc_banner[];
#define ALIGN(x,a)__ALIGN_MASK(x,(typeof(x))(a)-1)
#define __ALIGN_MASK(x,mask) (((x)+(mask))~(mask))
#define PTR_ALIGN(p, a) ((typeof(p))ALIGN((unsigned long)(p),
(a)))
-#define IS_ALIGNED(x,a) (((x) % ((typeof(x))(a))) == 0)
+#define IS_ALIGNED(x, a) (((x) ((typeof(x))(a) - 1)) == 0)
Your macro modification is wrong.
Take 0x12345600, which is aligned on a 16-byte boundary.
Now, with your macro, we have for a 0x10 alignment:
(0x12345600 0x0f) = (0x00 == 0) == TRUE (correct)
For an 0x20 alignment:
(0x12345600 0x1f) = (0x00 == 0) == TRUE (incorrect)
In other words, the macro may work for some alignments, but
not all. It is therefore wrong. You need the modulus, the
remainder after division. Anything else is broken.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 BogoMips).
My book : http://www.AbominableFirebug.com/
_
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email to
[EMAIL PROTECTED] - and destroy all copies of this information, including any
attachments, without reading or disclosing them.
Thank you.
-
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: eradicating out of tree modules
On Mon, 29 Oct 2007, Tilman Schmidt wrote: > Am 28.10.2007 20:25 schrieb Adrian Bunk: >> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote: >>> Am 28.10.2007 02:55 schrieb Adrian Bunk: Justifying anything with code with not GPL compatible licences has zero relevance here. And there's value in making life harder for such modules with questionable legality. As an example, consider people who experienced crashes of "the Linux kernel" caused by some binary-only driver. Not that uncommon e.g. with some graphics drivers. This harms the reputation of Linux as being stable. >>> You are mixing up several distinct categories here: "out of tree" >>> != "non-GPL" != "proprietary" != "of questionable legality" != >>> "binary-only" != "causing kernel crashes". >> >> "binary-only non-GPL out-of-tree module causes kernel crashes" is a >> quite common pattern for some popular binary-only modules. > > Common, yes. Popular, maybe. The only one, not. Taking that as reason > for breaking out-of-tree open source modules is throwing out the baby > with the bathwater. > The solution is not to support proprietary drivers, the solution is to get open source replacements. >>> So how do you propose to "get" those replacements? And what shall >>> users do during the time this "getting" may take? >> >> They should swamp the hardware vendors with requests for releasing >> hardware specifications. > > They are doing that already. But somehow it fails to magically cause > open source drivers to spring into existence immediately. The crucial > word here is *time*. > >> Or even better buy their hardware from a competitor. > > Hmmm. "Your existing hardware isn't supported anymore, buy new one?" > I thought that was a Microsoft line. (SCNR) > If it's low quality code doing something useful - well, how many hundred people are on Greg's list only waiting for some driver they could write? >>> No idea. Obviously not enough to actually solve the problem. >> >> Greg has just begins with getting this started. > > Exactly. Again, the problem is time. Deliberately breaking external > modules now and promising an in-tree alternative for later leaves > users out in the cold. That won't do much to improve the reputation > of Linux. > >>> What solution do you propose? >> >> You list the drivers you currently have in mind at the Linux Driver >> Project [1]. > > They are all there already. > >> Noone proposed to make the existance of out-of-tree modules completely >> impossible - but it is a fact that derives directly from the Linux >> kernel development model that thre's no stable API for out-of-tree >> modules, and therefore each new kernel breaks many of them. > > Granted. > >> Once you accept this fundamental fact there's not much point in arguing >> that changes that break out-of-tree modules should be fewer. > > Granted. But that's not the point I was arguing anyway. > > There is still a point in arguing that breaking out-of-tree modules > is not a goal. It's acceptable collateral damage if there is a good > reason for a change, but it doesn't by and in itself constitute such > a reason. That's why I'm taking exception with your statement in > <[EMAIL PROTECTED]>: >> [...] even though it might sound harsh breaking >> external modules and thereby making people aware that their code should >> get into the kernel is IMHO a positive point. > > Breaking external modules is *not* positive. It's acceptable, but > everything else being equal it's still better to avoid it. > Let me repeat that Greg has said he has hundreds of volunteers for such tasks. >>> Even with hundreds of volunteers, your proposed solution of just >>> rewriting *all* external code in a way fit for inclusion into the >>> kernel is an unachievable goal. Just look at the list on >>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers >>> and try to answer why each of them is still out of tree. >>> Hint: In most cases it's neither out of malice nor stupidity on >>> the authors' part. >> >> There are different problems why different drivers are not (yet) >> included in the kernel, but which ones don't have any possible solution? > > I'm convinced all of them have possible solutions. The challenge > is to turn a possible solution into an actual one. And again, the > problem is time. > >> And if you compare the numbers you'll see that Greg has on average a >> handful of volunteers for one driver. > > Not every problem can be solved faster by throwing more people at > it. Take mISDN as an example. Its developers have stated the goal > of inclusion in the main kernel tree years ago and it's still not > there. Deliberately breaking this external module "to make people > aware that their code should get into the kernel" would only delay > this goal even more. But sending them a handful of new volunteers > now would probably constitute the proverbial "adding manpower to a > late project". > >> The
Re: eradicating out of tree modules
On Mon, 29 Oct 2007, Tilman Schmidt wrote: Am 28.10.2007 20:25 schrieb Adrian Bunk: On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote: Am 28.10.2007 02:55 schrieb Adrian Bunk: Justifying anything with code with not GPL compatible licences has zero relevance here. And there's value in making life harder for such modules with questionable legality. As an example, consider people who experienced crashes of the Linux kernel caused by some binary-only driver. Not that uncommon e.g. with some graphics drivers. This harms the reputation of Linux as being stable. You are mixing up several distinct categories here: out of tree != non-GPL != proprietary != of questionable legality != binary-only != causing kernel crashes. binary-only non-GPL out-of-tree module causes kernel crashes is a quite common pattern for some popular binary-only modules. Common, yes. Popular, maybe. The only one, not. Taking that as reason for breaking out-of-tree open source modules is throwing out the baby with the bathwater. The solution is not to support proprietary drivers, the solution is to get open source replacements. So how do you propose to get those replacements? And what shall users do during the time this getting may take? They should swamp the hardware vendors with requests for releasing hardware specifications. They are doing that already. But somehow it fails to magically cause open source drivers to spring into existence immediately. The crucial word here is *time*. Or even better buy their hardware from a competitor. Hmmm. Your existing hardware isn't supported anymore, buy new one? I thought that was a Microsoft line. (SCNR) If it's low quality code doing something useful - well, how many hundred people are on Greg's list only waiting for some driver they could write? No idea. Obviously not enough to actually solve the problem. Greg has just begins with getting this started. Exactly. Again, the problem is time. Deliberately breaking external modules now and promising an in-tree alternative for later leaves users out in the cold. That won't do much to improve the reputation of Linux. What solution do you propose? You list the drivers you currently have in mind at the Linux Driver Project [1]. They are all there already. Noone proposed to make the existance of out-of-tree modules completely impossible - but it is a fact that derives directly from the Linux kernel development model that thre's no stable API for out-of-tree modules, and therefore each new kernel breaks many of them. Granted. Once you accept this fundamental fact there's not much point in arguing that changes that break out-of-tree modules should be fewer. Granted. But that's not the point I was arguing anyway. There is still a point in arguing that breaking out-of-tree modules is not a goal. It's acceptable collateral damage if there is a good reason for a change, but it doesn't by and in itself constitute such a reason. That's why I'm taking exception with your statement in [EMAIL PROTECTED]: [...] even though it might sound harsh breaking external modules and thereby making people aware that their code should get into the kernel is IMHO a positive point. Breaking external modules is *not* positive. It's acceptable, but everything else being equal it's still better to avoid it. Let me repeat that Greg has said he has hundreds of volunteers for such tasks. Even with hundreds of volunteers, your proposed solution of just rewriting *all* external code in a way fit for inclusion into the kernel is an unachievable goal. Just look at the list on http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers and try to answer why each of them is still out of tree. Hint: In most cases it's neither out of malice nor stupidity on the authors' part. There are different problems why different drivers are not (yet) included in the kernel, but which ones don't have any possible solution? I'm convinced all of them have possible solutions. The challenge is to turn a possible solution into an actual one. And again, the problem is time. And if you compare the numbers you'll see that Greg has on average a handful of volunteers for one driver. Not every problem can be solved faster by throwing more people at it. Take mISDN as an example. Its developers have stated the goal of inclusion in the main kernel tree years ago and it's still not there. Deliberately breaking this external module to make people aware that their code should get into the kernel would only delay this goal even more. But sending them a handful of new volunteers now would probably constitute the proverbial adding manpower to a late project. The most important question is still: Why should there always be out-of-tree code that fills a real need not satisfied by any in-tree code? Because every in-tree code starts as out-of-tree code, so as long as there's development at all
Re: Is gcc thread-unsafe?
On Thu, 25 Oct 2007, Andi Kleen wrote: > On Thursday 25 October 2007 05:24, Nick Piggin wrote: > >> Basically, what the gcc developers are saying is that gcc is >> free to load and store to any memory location, so long as it >> behaves as if the instructions were executed in sequence. > > This case is clearly a bug, a very likely code pessimization. > I guess it wasn't intentional, just an optimization that is useful > for local register values doing too much. I don't think it is a BUG, but one should certainly be able to turn it off. Gcc is correct in that the 'C' language allows a lot of implimentation details that are not covered by the language. In other words, 'C' is not assembly-language. > >> I guess that dynamically allocated memory and computed pointers >> are more difficult for gcc to do anything unsafe with, because >> it is harder to tell if a given function has deallocated the >> memory. > > Often accesses happen without function calls inbetween. > Also I think newer gcc (not 3.x) can determine if a pointer > "escapes" or not so that might not protect against it. > >> Any thoughts? > > We don't have much choice: If such a case is found it has to be marked > volatile or that particular compiler version be unsupported. > > It might be useful to come up with some kind of assembler pattern > matcher to check if any such code is generated for the kernel > and try it with different compiler versions. > > -Andi Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Is gcc thread-unsafe?
On Thu, 25 Oct 2007, Andi Kleen wrote: On Thursday 25 October 2007 05:24, Nick Piggin wrote: Basically, what the gcc developers are saying is that gcc is free to load and store to any memory location, so long as it behaves as if the instructions were executed in sequence. This case is clearly a bug, a very likely code pessimization. I guess it wasn't intentional, just an optimization that is useful for local register values doing too much. I don't think it is a BUG, but one should certainly be able to turn it off. Gcc is correct in that the 'C' language allows a lot of implimentation details that are not covered by the language. In other words, 'C' is not assembly-language. I guess that dynamically allocated memory and computed pointers are more difficult for gcc to do anything unsafe with, because it is harder to tell if a given function has deallocated the memory. Often accesses happen without function calls inbetween. Also I think newer gcc (not 3.x) can determine if a pointer escapes or not so that might not protect against it. Any thoughts? We don't have much choice: If such a case is found it has to be marked volatile or that particular compiler version be unsupported. It might be useful to come up with some kind of assembler pattern matcher to check if any such code is generated for the kernel and try it with different compiler versions. -Andi Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: [PATCH] fix "passing argument # of '__memcpy' discards qualifiers from pointer target type" warnings
On Wed, 24 Oct 2007, Bodo Eggert wrote: > Miguel Botón <[EMAIL PROTECTED]> wrote: > >> This patch fixes the warnings "passing argument 1 of '__memcpy' discards >> qualifiers from pointer target type" and "passing argument 2 of '__memcpy' >> discards qualifiers from pointer target type" when compiling some files. >> >> I don't really know if this is the best way but at least I don't get more >> warnings. > >> +++ linux-2.6.24-rc1/fs/cifs/dir.c2007-10-24 15:49:44.0 +0200 >> @@ -585,6 +585,7 @@ > >> + unsigned char *dstname = (unsigned char *)a->name; > >> @@ -593,7 +594,7 @@ > >> - memcpy((unsigned char *)a->name, b->name, a->len); >> + memcpy(dstname, b->name, a->len); > > This looks like a compiler bug. Get the gcc people to fix it. > -- > Top 100 things you don't want the sysadmin to say: > 20. ...and if we just swap these two disc controllers like _this_... > > Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] > - According to the header, the pointer is a (const struct qstr *). Not a gcc bug if somebody is writing there. Probably the header needs fixing. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: kernel processes - are they really needed?
On Wed, 24 Oct 2007, Ram wrote: > Hi, >When i do ps -l. i see the following processes which are obviously > started by kernel. > > Could any one tell me what each of these processes do and can > anyone of them can be removed.? > > PID Uid VmSize Stat Command >1 root584 S init >2 rootSWN [ksoftirqd/0] >3 rootSW [watchdog/0] >4 rootSW< [events/0] >5 rootSW< [khelper] >6 rootSW< [kthread] > 23 rootSW< [kblockd/0] > 38 rootSW [pdflush] > 39 rootSW [pdflush] > 40 rootSW< [kswapd0] > 41 rootSW< [aio/0] > 85 rootSW [mtdblockd] > 116 rootSWN [jffs2_gcd_mtd9] > Regards, > ram > - Init is the 'mother' of all processes. It sleeps using no resources until some other process terminates. At that time,...learn about Unix somewhere else. Other tasks are essential as well. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: kernel processes - are they really needed?
On Wed, 24 Oct 2007, Ram wrote: Hi, When i do ps -l. i see the following processes which are obviously started by kernel. Could any one tell me what each of these processes do and can anyone of them can be removed.? PID Uid VmSize Stat Command 1 root584 S init 2 rootSWN [ksoftirqd/0] 3 rootSW [watchdog/0] 4 rootSW [events/0] 5 rootSW [khelper] 6 rootSW [kthread] 23 rootSW [kblockd/0] 38 rootSW [pdflush] 39 rootSW [pdflush] 40 rootSW [kswapd0] 41 rootSW [aio/0] 85 rootSW [mtdblockd] 116 rootSWN [jffs2_gcd_mtd9] Regards, ram - Init is the 'mother' of all processes. It sleeps using no resources until some other process terminates. At that time,...learn about Unix somewhere else. Other tasks are essential as well. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: [PATCH] fix passing argument # of '__memcpy' discards qualifiers from pointer target type warnings
On Wed, 24 Oct 2007, Bodo Eggert wrote: Miguel Botón [EMAIL PROTECTED] wrote: This patch fixes the warnings passing argument 1 of '__memcpy' discards qualifiers from pointer target type and passing argument 2 of '__memcpy' discards qualifiers from pointer target type when compiling some files. I don't really know if this is the best way but at least I don't get more warnings. +++ linux-2.6.24-rc1/fs/cifs/dir.c2007-10-24 15:49:44.0 +0200 @@ -585,6 +585,7 @@ + unsigned char *dstname = (unsigned char *)a-name; @@ -593,7 +594,7 @@ - memcpy((unsigned char *)a-name, b-name, a-len); + memcpy(dstname, b-name, a-len); This looks like a compiler bug. Get the gcc people to fix it. -- Top 100 things you don't want the sysadmin to say: 20. ...and if we just swap these two disc controllers like _this_... Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - According to the header, the pointer is a (const struct qstr *). Not a gcc bug if somebody is writing there. Probably the header needs fixing. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Question about free/used memory on Linux
On Sun, 21 Oct 2007, Ravinandan Arakali (rarakali) wrote: > Hi Vaidy, > Thanks for clarifying several of my doubts. > > To answer your question about my intention, we currently have a > system with 2 GB RAM and I need to find out the actual used and > free memory so that we can decide if the same setup(applications, > tmpfs etc.) can run on another system with lesser memory. > > Is it correct to say that the "used" field "free -m" excluding > buffers/caches would give the correct idea of used memory > (I mean does it take care of shared memory, shared copies of > libraries etc.) ? I assume it does not include /dev/shm usage > since that's also a tmpfs partition ? > > If so, then I can add the memory used by tmpfs partitions to > the above and get the total memory used ? > > For eg. if my "free -m" appears as below: > Linux(debug)# free -m > total used free sharedbuffers > cached > Mem: 2014984 1030 0 80 > 594 > -/+ buffers/cache:309 1705 > > Can I say that 309MB + 350 MB(size of tmpfs partitions including > /dev/shm) > is the used memory on my system ? > > Thanks, > Ravi > [Snipped...] Just boot your present system with MEM=nnn on the command-line, where nnn is the amount of memory you would like to use in the new system (like this). title Fedora Core (2.6.16.24) root (hd0,0) kernel /boot/vmlinuz-2.6.16.24 ro root=LABEL=/ mem=768m nmi_watchdog=0 rhgb reboot=cb initrd /boot/initrd-2.6.16.24.img Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Question about free/used memory on Linux
On Sun, 21 Oct 2007, Ravinandan Arakali (rarakali) wrote: Hi Vaidy, Thanks for clarifying several of my doubts. To answer your question about my intention, we currently have a system with 2 GB RAM and I need to find out the actual used and free memory so that we can decide if the same setup(applications, tmpfs etc.) can run on another system with lesser memory. Is it correct to say that the used field free -m excluding buffers/caches would give the correct idea of used memory (I mean does it take care of shared memory, shared copies of libraries etc.) ? I assume it does not include /dev/shm usage since that's also a tmpfs partition ? If so, then I can add the memory used by tmpfs partitions to the above and get the total memory used ? For eg. if my free -m appears as below: Linux(debug)# free -m total used free sharedbuffers cached Mem: 2014984 1030 0 80 594 -/+ buffers/cache:309 1705 Can I say that 309MB + 350 MB(size of tmpfs partitions including /dev/shm) is the used memory on my system ? Thanks, Ravi [Snipped...] Just boot your present system with MEM=nnn on the command-line, where nnn is the amount of memory you would like to use in the new system (like this). title Fedora Core (2.6.16.24) root (hd0,0) kernel /boot/vmlinuz-2.6.16.24 ro root=LABEL=/ mem=768m nmi_watchdog=0 rhgb reboot=cb initrd /boot/initrd-2.6.16.24.img Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: how to use TLB to prevent Linux accessing a particular memory region
On Tue, 16 Oct 2007, veerasena reddy wrote: > Hi, > > I have a board, which has two processors ( one is MIPS > on which Linux-2.6.18 kernel runs and another is DSP > based processor) and 32MB DDR. > > Out of 32MB of DDR 8MB is reserved for use by DSP > processor. But the MIPS processor downloads firmware > into this reserved memory for the DSP. > > Now, is it possible to use the TLB to prevent Linux > from accessing the reserved memory after the firmware > has been downloaded? > > Also we'd need to remove those TLB entries if the > firmware would ever need to be reloaded to the DSP' > memory region. > > What are the APIs to be used to achieve the above? > > > Thanks in advance. > > Regards, > Veerasena. > > > 5, 50, 500, 5000 - Store N number of mails in your inbox. Go to > http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html > - Can't you just memory-map the area you need? That reserves it until it's unmapped. You don't need to directly touch the TLB. If you need a physical location, use ioremap_nocache() in your driver. If you can't get your physical location because the kernel already uses it, boot the kernel with mem=xxx on the command-line to prevent the kernel from using memory you want to reserve for your DSP. You can use num_physpages (an integer) to find out the last page the kernel uses. BTW, if this is a new design, most DSP devices put their RAM on their own board so you don't have these problems. That RAM gets mmaped to user-space as needed for access, that address being set asside in PCI space. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: halt does not shut the system down
On Tue, 16 Oct 2007, John Sigler wrote: > John Sigler wrote: > >> Alexey Starikovskiy wrote: >> >>> Could you please open bug at bugzilla.kernel.org and put all these >>> files there? >> >> http://bugzilla.kernel.org/show_bug.cgi?id=9148 >> >> Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to >> hang my system in acpi_os_write_port(). What can I do about that? > > Another observation: if I connect a screen to the system's VGA port, > when I call 'poweroff' the screen goes into power saving mode. This > seems to indicate that the integrated video card is properly shut down. > > So the fans keep spinning, the LEDs keep shining, the LCD keeps > displaying, but the video card is shut down? > > Might this help pinpoint the problem? > > Regards. > - Check the BIOS to see if the "Power Button" is configured to shut the system down. Some BIOS configure APM to do what the power button does! Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: halt does not shut the system down
On Tue, 16 Oct 2007, John Sigler wrote: John Sigler wrote: Alexey Starikovskiy wrote: Could you please open bug at bugzilla.kernel.org and put all these files there? http://bugzilla.kernel.org/show_bug.cgi?id=9148 Writing 15361 (i.e. 0x3C01) to ACPI_REGISTER_PM1A_CONTROL appears to hang my system in acpi_os_write_port(). What can I do about that? Another observation: if I connect a screen to the system's VGA port, when I call 'poweroff' the screen goes into power saving mode. This seems to indicate that the integrated video card is properly shut down. So the fans keep spinning, the LEDs keep shining, the LCD keeps displaying, but the video card is shut down? Might this help pinpoint the problem? Regards. - Check the BIOS to see if the Power Button is configured to shut the system down. Some BIOS configure APM to do what the power button does! Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: how to use TLB to prevent Linux accessing a particular memory region
On Tue, 16 Oct 2007, veerasena reddy wrote: Hi, I have a board, which has two processors ( one is MIPS on which Linux-2.6.18 kernel runs and another is DSP based processor) and 32MB DDR. Out of 32MB of DDR 8MB is reserved for use by DSP processor. But the MIPS processor downloads firmware into this reserved memory for the DSP. Now, is it possible to use the TLB to prevent Linux from accessing the reserved memory after the firmware has been downloaded? Also we'd need to remove those TLB entries if the firmware would ever need to be reloaded to the DSP' memory region. What are the APIs to be used to achieve the above? Thanks in advance. Regards, Veerasena. 5, 50, 500, 5000 - Store N number of mails in your inbox. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html - Can't you just memory-map the area you need? That reserves it until it's unmapped. You don't need to directly touch the TLB. If you need a physical location, use ioremap_nocache() in your driver. If you can't get your physical location because the kernel already uses it, boot the kernel with mem=xxx on the command-line to prevent the kernel from using memory you want to reserve for your DSP. You can use num_physpages (an integer) to find out the last page the kernel uses. BTW, if this is a new design, most DSP devices put their RAM on their own board so you don't have these problems. That RAM gets mmaped to user-space as needed for access, that address being set asside in PCI space. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Ethernet driver problem
On Wed, 10 Oct 2007, Jupe wrote: > Hi, > > I have written an ethernet driver for an ARM based board. > Linux version: 2.6.20.1 > > Ping is working fine. > > I have written a test server/client application using socket programming > (TCP). > After the connection is setup the server sends a file to the client. > > When I run server on PC and client on ARM board it works without any > problem. > > BUT if I run server on ARM board and client on PC, it works for some > time and > then the speed is drastically reduced. (I am sending 4k of data each > time. > after 50 sends it reduces its speed. This happens always.) > > I did some debugging and found that after 50 sends, tcp_sendmsg() is not > being > called at the same frequency before slowdown. Also when my driver > ether_tx seems to > be working fine. > > But still i am not able to get the reason for this behaviour. Can > anyone give hints as to > why this is happening? > > > Regards > Jupe > > -- > Jupe > [EMAIL PROTECTED] > > -- > http://www.fastmail.fm - mmm... Fastmail... First, does your TCP/IP test application work okay on a Linux machine that does not use your new driver? That's the first thing to test. Next, is auto-negotiation working correctly in your driver? If you don't have auto-negotiation, have you set the Ethernet parameters correctly so that BOTH the server and the client use either full-duplex, or half-duplex, without mixing them up? Next, make sure that you are properly handling transmit retries (handling all possible errors) in your driver. The transmitter does not want to drop packets if there is no room in the device, only the receiver should drop packets if there are no buffers. You do not want the TCP/IP replacement algorithm to request missing packets because this slows everything down. Again, in the transmitter section of your driver, consider data precious. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
On Tue, 9 Oct 2007, Krzysztof Halasa wrote: > Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes: > >> but the gist is that IBM has >> traditionally bit 0 for MSB and x for LSB. It's a pain to work with: >> for one, bits in the same place in a word (say, control register) are >> renumbered in 32 vs 64. > > I wasn't aware of that, but it doesn't really change the bit order, > only bit names (numbers actually). Extremely weird BTW but I guess > these things weren't that obvious to everyone some 50 years ago. > >> And I've worked on at least one piece of >> hardware in which the hardware designer had a brain-fart and first board >> had bit 0 on the CPU wired to bit 0 on the northbridge - should have >> been 31 -> 0, 30 -> 1, etc... > > I suspect the board wasn't able to run any OS, was it? :-) > Would make a real example of the different order of bits, though. > -- > Krzysztof Halasa > - There are several chips in which bit 0 is the MSB. For instance, a National Instruments chip used to interface with a GPIB bus, TNT--something. Nevertheless, if I write 0x12 to an 8-bit read/write register, I will read back 0x12, and if I write 0x1234 to an 16-bit read/write register, I will read back 0x1234. Regardless of any endian. So, even though the internal 'value' seem by the chip might not actually be 0x1234, for bit-mapped registers it doesn't care because you define the function of each bit. The only time one would care is if one was setting a particular value to a divisor of a timer or something that needed a particular binary value, rather than bits. In many cases, the value isn't 'pure' anyway. It might be in BCD or offset-binary or some other perversion that requires manipulation anyway so, again it is important --only to the extent the resulting "number" seen by the chip needs to be correct. It is instructive to note that RAM is just a bunch of bits that are uniquely addressable. Often the CPU can't address one individual bit, but the interface hardware does and, in particular, modern RAM makes sure that bits that are adjacent in words are never adjacent in the physical devices. This is so that ECC has a chance of working! A nuclear event that might upset a bit will 'splash' across an area, upsetting many bits. If they all belonged to the same few words, the single-bit correction wouldn't work. The idea in the architecture it to have nuclear events cause single-bit errors only, so the bits of a word are never adjacent in physical space. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
On Tue, 9 Oct 2007, Krzysztof Halasa wrote: Jeremy Fitzhardinge [EMAIL PROTECTED] writes: but the gist is that IBM has traditionally bit 0 for MSB and x for LSB. It's a pain to work with: for one, bits in the same place in a word (say, control register) are renumbered in 32 vs 64. I wasn't aware of that, but it doesn't really change the bit order, only bit names (numbers actually). Extremely weird BTW but I guess these things weren't that obvious to everyone some 50 years ago. And I've worked on at least one piece of hardware in which the hardware designer had a brain-fart and first board had bit 0 on the CPU wired to bit 0 on the northbridge - should have been 31 - 0, 30 - 1, etc... I suspect the board wasn't able to run any OS, was it? :-) Would make a real example of the different order of bits, though. -- Krzysztof Halasa - There are several chips in which bit 0 is the MSB. For instance, a National Instruments chip used to interface with a GPIB bus, TNT--something. Nevertheless, if I write 0x12 to an 8-bit read/write register, I will read back 0x12, and if I write 0x1234 to an 16-bit read/write register, I will read back 0x1234. Regardless of any endian. So, even though the internal 'value' seem by the chip might not actually be 0x1234, for bit-mapped registers it doesn't care because you define the function of each bit. The only time one would care is if one was setting a particular value to a divisor of a timer or something that needed a particular binary value, rather than bits. In many cases, the value isn't 'pure' anyway. It might be in BCD or offset-binary or some other perversion that requires manipulation anyway so, again it is important --only to the extent the resulting number seen by the chip needs to be correct. It is instructive to note that RAM is just a bunch of bits that are uniquely addressable. Often the CPU can't address one individual bit, but the interface hardware does and, in particular, modern RAM makes sure that bits that are adjacent in words are never adjacent in the physical devices. This is so that ECC has a chance of working! A nuclear event that might upset a bit will 'splash' across an area, upsetting many bits. If they all belonged to the same few words, the single-bit correction wouldn't work. The idea in the architecture it to have nuclear events cause single-bit errors only, so the bits of a word are never adjacent in physical space. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Ethernet driver problem
On Wed, 10 Oct 2007, Jupe wrote: Hi, I have written an ethernet driver for an ARM based board. Linux version: 2.6.20.1 Ping is working fine. I have written a test server/client application using socket programming (TCP). After the connection is setup the server sends a file to the client. When I run server on PC and client on ARM board it works without any problem. BUT if I run server on ARM board and client on PC, it works for some time and then the speed is drastically reduced. (I am sending 4k of data each time. after 50 sends it reduces its speed. This happens always.) I did some debugging and found that after 50 sends, tcp_sendmsg() is not being called at the same frequency before slowdown. Also when my driver ether_tx seems to be working fine. But still i am not able to get the reason for this behaviour. Can anyone give hints as to why this is happening? Regards Jupe -- Jupe [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail... First, does your TCP/IP test application work okay on a Linux machine that does not use your new driver? That's the first thing to test. Next, is auto-negotiation working correctly in your driver? If you don't have auto-negotiation, have you set the Ethernet parameters correctly so that BOTH the server and the client use either full-duplex, or half-duplex, without mixing them up? Next, make sure that you are properly handling transmit retries (handling all possible errors) in your driver. The transmitter does not want to drop packets if there is no room in the device, only the receiver should drop packets if there are no buffers. You do not want the TCP/IP replacement algorithm to request missing packets because this slows everything down. Again, in the transmitter section of your driver, consider data precious. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
On Fri, 5 Oct 2007, Timur Tabi wrote: > Andreas Schwab wrote: > >> The bit mapping on your device is strictly internal to the device and >> has nothing to do with bit order on the C level. > > Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD. What does it mean for a C-level bitfield ordering to be little-endian if the processor is BIG_ENDIAN? > > -- > Timur Tabi > Linux Kernel Developer @ Freescale > - It makes no sense because a bitfield is something having to do with a 'C' compiler and it must NEVER be used as a template to address hardware! 'C' gives no guarantee of the ordering within machine words. The only way you can access them is using 'C'. They don't have addresses like other objects (of course they do exist --somewhere). They are put into "storage units," according to the standard, and these storage units are otherwise undefined although you can align them (don't go there). If you want to call machine-control bits by name, just define them as hexadecimal numbers (unsigned ints) and, if your hardware is for both little/big endian, use a macro that resolves the issue between the number and the hardware. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: __LITTLE_ENDIAN vs. __LITTLE_ENDIAN_BITFIELD
On Fri, 5 Oct 2007, Timur Tabi wrote: Andreas Schwab wrote: The bit mapping on your device is strictly internal to the device and has nothing to do with bit order on the C level. Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD. What does it mean for a C-level bitfield ordering to be little-endian if the processor is BIG_ENDIAN? -- Timur Tabi Linux Kernel Developer @ Freescale - It makes no sense because a bitfield is something having to do with a 'C' compiler and it must NEVER be used as a template to address hardware! 'C' gives no guarantee of the ordering within machine words. The only way you can access them is using 'C'. They don't have addresses like other objects (of course they do exist --somewhere). They are put into storage units, according to the standard, and these storage units are otherwise undefined although you can align them (don't go there). If you want to call machine-control bits by name, just define them as hexadecimal numbers (unsigned ints) and, if your hardware is for both little/big endian, use a macro that resolves the issue between the number and the hardware. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Point of gpl-only modules (flame)
On Tue, 2 Oct 2007, Jan Engelhardt wrote: > > On Oct 2 2007 23:49, Jimmy wrote: >> >> Anyway, I've been trying to figure out what purpose the gpl-only code serves. >> What good comes out of disabling people from probing modules that do not >> have a >> gpl-compatible license? > > find /lib/modules/`uname -r` -iname '*.ko' | wc -l: > > 2021 > > Proprietary modules that I can think of: > > 5 to 10 > > It's not even 1/2 a !#$ percent. (Though knowing that many modules are for > not-so-common hw.) > >> It seems pretty childish to try and force some license on people, imagine >> trying to install firefox on Windows Vista, an error-dialog box appears: >> "This application has been denied access to the Windows API as its license >> are >> compatible with the Microsoft Philosophy" ? > > Not a kernel problem. > > (That said, MS would probably face yet another antitrust charge if it did > that. > Or better yet, people would just thankfully stop using it.) > >> Now, i don't want to waste clock cycles on executing code that serves no >> purpose but restraining me from using my $1500 gfx card as intended, > > Perhaps you intended to buy a game console instead? > > That said, no one is restraining you. You can edit the kernel source > and rip out all the GPL checks. On top, it's not like the ati or > nvidia blob-ola would not load in today's kernel. > > 01:00 ichi:~ > lsmod | grep nv > nvidia 4717076 22 > > Oh yeah, my kernel (unpatched, btw) really tries to stop me hard > from loading it. > >> so will me >> removing that crap from the source result in somebody trying to obfuscate it >> to >> a point where neither of us know what is what? >> >> Also, how about a list of PROS, explain to me whats so cool about it? >> >> - Jimmy > - Jimmy, a simple script can generate a link object that will resolve any kernel symbols for your module without any "export symbol" stuff at all. This was previously demonstrated to the enraged few who considered it immoral. Nevertheless, it's just as moral as bypassing RIAA copy protection. Just don't expect the kernel developers to authorize its use, or show you how to do it! Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Point of gpl-only modules (flame)
On Tue, 2 Oct 2007, Jan Engelhardt wrote: On Oct 2 2007 23:49, Jimmy wrote: Anyway, I've been trying to figure out what purpose the gpl-only code serves. What good comes out of disabling people from probing modules that do not have a gpl-compatible license? find /lib/modules/`uname -r` -iname '*.ko' | wc -l: 2021 Proprietary modules that I can think of: 5 to 10 It's not even 1/2 a !#$ percent. (Though knowing that many modules are for not-so-common hw.) It seems pretty childish to try and force some license on people, imagine trying to install firefox on Windows Vista, an error-dialog box appears: This application has been denied access to the Windows API as its license are compatible with the Microsoft Philosophy ? Not a kernel problem. (That said, MS would probably face yet another antitrust charge if it did that. Or better yet, people would just thankfully stop using it.) Now, i don't want to waste clock cycles on executing code that serves no purpose but restraining me from using my $1500 gfx card as intended, Perhaps you intended to buy a game console instead? That said, no one is restraining you. You can edit the kernel source and rip out all the GPL checks. On top, it's not like the ati or nvidia blob-ola would not load in today's kernel. 01:00 ichi:~ lsmod | grep nv nvidia 4717076 22 Oh yeah, my kernel (unpatched, btw) really tries to stop me hard from loading it. so will me removing that crap from the source result in somebody trying to obfuscate it to a point where neither of us know what is what? Also, how about a list of PROS, explain to me whats so cool about it? - Jimmy - Jimmy, a simple script can generate a link object that will resolve any kernel symbols for your module without any export symbol stuff at all. This was previously demonstrated to the enraged few who considered it immoral. Nevertheless, it's just as moral as bypassing RIAA copy protection. Just don't expect the kernel developers to authorize its use, or show you how to do it! Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: yield API
On Tue, 2 Oct 2007, Ingo Molnar wrote: > > * David Schwartz <[EMAIL PROTECTED]> wrote: > >>> These are generic statements, but i'm _really_ interested in the >>> specifics. Real, specific code that i can look at. The typical Linux >>> distro consists of in execess of 500 millions of lines of code, in >>> tens of thousands of apps, so there really must be some good, valid >>> and "right" use of sched_yield() somewhere in there, in some >>> mainstream app, right? (because, as you might have guessed it, in >>> the past decade of sched_yield() existence i _have_ seen my share of >>> sched_yield() utilizing user-space code, and at the moment i'm not >>> really impressed by those examples.) >> >> Maybe, maybe not. Even if so, it would be very difficult to find. >> Simply grepping for sched_yield is not going to help because >> determining whether a given use of sched_yield is smart is not going >> to be easy. > > sched_yield() has been around for a decade (about three times longer > than futexes were around), so if it's useful, it sure should have grown > some 'crown jewel' app that uses it and shows off its advantages, > compared to other locking approaches, right? > > For example, if you asked me whether pipes are the best thing for > certain apps, i could immediately show you tons of examples where they > are. Same for sockets. Or RT priorities. Or nice levels. Or futexes. Or > just about any other core kernel concept or API. Your notion that > showing a good example of an API would be "difficult" because it's hard > to determine "smart" use is not tenable i believe and does not > adequately refute my pretty plain-meaning "it does not exist" assertion. > > If then this is one more supporting proof for the fundamental weakness > of the sched_yield() API. Rarely are we able to so universally condemn > an API: real-life is usually more varied and even for theoretically > poorly defined APIs _some_ sort of legitimate use does grow up. > > APIs that are not in any real, meaningful use, despite a decade of > presence are not really interesting to me personally. (especially in > this case where we know exactly _why_ the API is used so rarely.) Sure > we'll continue to support it in the best possible way, with the usual > kernel maintainance policy: without hurting other, more commonly used > APIs. That was the principle we followed in previous schedulers too. And > if anyone has a patch to make sched_yield() better than it is today, i'm > of course interested in it. > > Ingo But sched_yield() on Linux never did what the majority of programmers assumed it would do (give up the CPU to some runnable processes for the rest of the time-slice). Instead, it just appeared to spin in the kernel. Therefore, those who needed a sched_yield(), just used usleep(). Whether or not there is a POSIX definition of sched_yield(), there is a need for something that will give up the CPU and not busy-wait. There are many control applications where state-machines are kept in user-mode code. The code waits for an event. It shouldn't be spinning, wasting CPU time, when the kernel can be doing file and network I/O with the wasted CPU cycles. So, just because sched_yield() doesn't work as expected, is not the reason to get rid of it. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: yield API
On Tue, 2 Oct 2007, Ingo Molnar wrote: * David Schwartz [EMAIL PROTECTED] wrote: These are generic statements, but i'm _really_ interested in the specifics. Real, specific code that i can look at. The typical Linux distro consists of in execess of 500 millions of lines of code, in tens of thousands of apps, so there really must be some good, valid and right use of sched_yield() somewhere in there, in some mainstream app, right? (because, as you might have guessed it, in the past decade of sched_yield() existence i _have_ seen my share of sched_yield() utilizing user-space code, and at the moment i'm not really impressed by those examples.) Maybe, maybe not. Even if so, it would be very difficult to find. Simply grepping for sched_yield is not going to help because determining whether a given use of sched_yield is smart is not going to be easy. sched_yield() has been around for a decade (about three times longer than futexes were around), so if it's useful, it sure should have grown some 'crown jewel' app that uses it and shows off its advantages, compared to other locking approaches, right? For example, if you asked me whether pipes are the best thing for certain apps, i could immediately show you tons of examples where they are. Same for sockets. Or RT priorities. Or nice levels. Or futexes. Or just about any other core kernel concept or API. Your notion that showing a good example of an API would be difficult because it's hard to determine smart use is not tenable i believe and does not adequately refute my pretty plain-meaning it does not exist assertion. If then this is one more supporting proof for the fundamental weakness of the sched_yield() API. Rarely are we able to so universally condemn an API: real-life is usually more varied and even for theoretically poorly defined APIs _some_ sort of legitimate use does grow up. APIs that are not in any real, meaningful use, despite a decade of presence are not really interesting to me personally. (especially in this case where we know exactly _why_ the API is used so rarely.) Sure we'll continue to support it in the best possible way, with the usual kernel maintainance policy: without hurting other, more commonly used APIs. That was the principle we followed in previous schedulers too. And if anyone has a patch to make sched_yield() better than it is today, i'm of course interested in it. Ingo But sched_yield() on Linux never did what the majority of programmers assumed it would do (give up the CPU to some runnable processes for the rest of the time-slice). Instead, it just appeared to spin in the kernel. Therefore, those who needed a sched_yield(), just used usleep(). Whether or not there is a POSIX definition of sched_yield(), there is a need for something that will give up the CPU and not busy-wait. There are many control applications where state-machines are kept in user-mode code. The code waits for an event. It shouldn't be spinning, wasting CPU time, when the kernel can be doing file and network I/O with the wasted CPU cycles. So, just because sched_yield() doesn't work as expected, is not the reason to get rid of it. Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Out of memory management in embedded systems
On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote: > On 9/28/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: >> >> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote: >> >>> On 9/28/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: >>>> >>>> But an embedded system contains all the software that will >>>> ever be executed on that system! If it is properly designed, >>>> it can never run out of memory because everything it will >>>> ever do is known at design time. >>> >>> Not if its input is not known beforehand. Take a browser in a mobile >>> phone as an example, it does not know at design time how big the web >>> pages are. On the other hand we want to use as much memory as >>> possible, for cache etc., a method that involves the kernel would >>> simplify this and avoids setting manual limits. >>> >>> Daniel >>> >> >> Any networked appliance can (will) throw data away if there are >> no resources available. >> >> The length of a web-page is not relevent, nor is the length >> of any external data. Your example will buffer whatever it >> can and not read anything more from the external source until >> it has resources available unless it is broken. > > And how do you determine when no resources are availabe? We are using > overcommit here so malloc() will always return non null. > A networked appliance using embedded software is not your daddy's Chevrolet. Any task that is permanent needs to allocate all its resources when it starts. That's how it knows how much there are, and incidentally, it doesn't do it blindly. The system designer must know how much memory is available in the system and how much is allocated to the kernel. The fact that you can give a fictitious value to malloc() is not relevant. If you don't provide resources for malloc(), like (ultimately) a swap file, then you can't assume that it can do any design work for you. An embedded system is NOT an ordinary system that happens to boot from flash. An embedded system requires intelligent design. It is important to understand how a virtual memory system operates. The basics are that the kernel only "knows" that a new page needs to be allocated when it encounters a trap called a "page fault." If you don't have any memory resources to free up (read no swap file to write a seldom-used task's working set), then you are screwed --pure and simple. So, if you don't provide any resources to actually use virtual memory, then you need to make certain that virtual memory and physical memory are, for all practical purposes, the same. With embedded servers, it's usually very easy to limit the number of connections allowed, therefore the amount of dynamic resources that must be provided. With clients it should be equally easy, but generic software won't work because, for instance, Mozilla doesn't keep track of the number of "windows" you have up and the number of connections you have. HOWEVER, remember that malloc() is a library call. You can substitute your own using LD_PRELOAD, they keeps track of everything if you must use generic software. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Out of memory management in embedded systems
On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote: > On 9/28/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote: >> >> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote: >> >>> Applications with dynamic input and dynamic memory usage have some >>> issues with the current overcommitting kernel. A high memory usage >>> situation eventually results in that a process is killed by the OOM >>> killer. This is especially evident in swapless embedded systems with >>> limited memory and no swap available. >>> >>> Some kind of notification to the application that the available memory >>> is scarce and let the application free up some memory (e.g., by >>> flushing caches), could be used to improve the situation and avoid the >>> OOM killer. I am currently not aware of any general solution to this >>> problem, but I have found some approaches that might (or might not) >>> work: >>> >>> o Turn off overcommit. Results in a waste of memory. >>> >>> o Nokia uses a lowmem security module to signal on predetermined >>> thresholds. Currently available in the -omap tree. But this requires >>> manual tuning of the thresholds. >>> http://www.linuxjournal.com/article/8502 >>> >>> o Using madvise() with MADV_FREE to get the kernel to free mmaped >>> memory, typically application caches, when the kernel needs the >>> memory. >>> >>> o A OOM handler that the application registers with the kernel, and >>> that the kernel executes before the OOM-killer steps in. >>> >>> Does it exist any other solutions to this problem? >>> >>> Daniel >>> - >> >> But an embedded system contains all the software that will >> ever be executed on that system! If it is properly designed, >> it can never run out of memory because everything it will >> ever do is known at design time. > > Not if its input is not known beforehand. Take a browser in a mobile > phone as an example, it does not know at design time how big the web > pages are. On the other hand we want to use as much memory as > possible, for cache etc., a method that involves the kernel would > simplify this and avoids setting manual limits. > > Daniel > Any networked appliance can (will) throw data away if there are no resources available. The length of a web-page is not relevent, nor is the length of any external data. Your example will buffer whatever it can and not read anything more from the external source until it has resources available unless it is broken. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/
