Re: epoll and shared fd's
Michael Kerrisk <[EMAIL PROTECTED]> wrote: > a) I did a > > s/internal kernel handle/open file description/ > > since that is the POSIX term for the internal handle. > > b) It seems to me that you text doesn't quite make the point explicit > enough. I've tried to rewrite it; could you please check: > >A6 Yes, but be aware of the following point. A file > descriptor is a reference to an open file descrip- > tion (see open(2)). Whenever a descriptor is > duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, > or fork(2), a new file descriptor referring to the > same open file description is created. An open > file description continues to exist until all file > descriptors referring to it have been closed. The > epoll interface automatically removes a file > descriptor from an epoll set only after all the > file descriptors referring to the underlying open > file handle have been closed. This means that > even after a file descriptor that is part of an > epoll set has been closed, events may be reported > for that file descriptor if other file descriptors > referring to the same underlying file description > remain open. > > Does that seem okay? I plan to include the text in man-pages-2.79. It's hard to read for me, and probably very hard to read for others. -- 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: epoll and shared fd's
Michael Kerrisk [EMAIL PROTECTED] wrote: a) I did a s/internal kernel handle/open file description/ since that is the POSIX term for the internal handle. b) It seems to me that you text doesn't quite make the point explicit enough. I've tried to rewrite it; could you please check: A6 Yes, but be aware of the following point. A file descriptor is a reference to an open file descrip- tion (see open(2)). Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor referring to the same open file description is created. An open file description continues to exist until all file descriptors referring to it have been closed. The epoll interface automatically removes a file descriptor from an epoll set only after all the file descriptors referring to the underlying open file handle have been closed. This means that even after a file descriptor that is part of an epoll set has been closed, events may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open. Does that seem okay? I plan to include the text in man-pages-2.79. It's hard to read for me, and probably very hard to read for others. -- 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: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Andi Kleen <[EMAIL PROTECTED]> wrote:
>> we were talking about the load order. This will solve the load order,
>> but if we have races like the kind you described, then the whole mISDN
>> design is broken.
>
> It's more a generic problem of the module code.
It's a problem of not enough synchronisation before a module load completes.
If a module provides an interface, but needs some time after being load to
initialize, it obviously MUST provide a way to wait for it. Since you'll
need some i-need-module-foo functions anyway, why not: (bar needs foo)
-foo.c---
DECLARE_COMPLETION(init_complete); /* static? */
module_foo_init_async() {
...
void complete_all(_complete);
}
void usemod_foo()
{
wait_for_completion(_complete);
}
EXPORT_SYMBOL(usemod_foo)
-bar.c---
DECLARE_COMPLETION(init_complete);
module_bar_init_async() {
usemod_foo();
...
void complete_all(_complete);
}
void usemod_bar()
{
wait_for_completion(_complete);
}
EXPORT_SYMBOL(usemod_bar)
--
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: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Andi Kleen [EMAIL PROTECTED] wrote:
we were talking about the load order. This will solve the load order,
but if we have races like the kind you described, then the whole mISDN
design is broken.
It's more a generic problem of the module code.
It's a problem of not enough synchronisation before a module load completes.
If a module provides an interface, but needs some time after being load to
initialize, it obviously MUST provide a way to wait for it. Since you'll
need some i-need-module-foo functions anyway, why not: (bar needs foo)
-foo.c---
DECLARE_COMPLETION(init_complete); /* static? */
module_foo_init_async() {
...
void complete_all(init_complete);
}
void usemod_foo()
{
wait_for_completion(init_complete);
}
EXPORT_SYMBOL(usemod_foo)
-bar.c---
DECLARE_COMPLETION(init_complete);
module_bar_init_async() {
usemod_foo();
...
void complete_all(init_complete);
}
void usemod_bar()
{
wait_for_completion(init_complete);
}
EXPORT_SYMBOL(usemod_bar)
--
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: Handshaking on USB serial devices
Gene Heskett <[EMAIL PROTECTED]> wrote: ['cat /dev/hideaw0 | hexdump -v'] > Or some way to ship the > $00's to /dev/null so hexdump ignores them? .. | perl -pe 's/\00//g/' | ... -- 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: Handshaking on USB serial devices
Gene Heskett [EMAIL PROTECTED] wrote: ['cat /dev/hideaw0 | hexdump -v'] Or some way to ship the $00's to /dev/null so hexdump ignores them? .. | perl -pe 's/\00//g/' | ... -- 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?
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote: > schrieb Jan Engelhardt <[EMAIL PROTECTED]>: >> There is a much more interesting 'problem' with a "/dev/null >> directory". >> >> Q: Why would you need such a directory? >> A: To temporarily fool a program into believing it wrote something. >> >> Q: Should all files disappear? (e.g. "unlink after open") >> A: Maybe not, programs may stat() the file right afterwards and >>get confused by the "inexistence". >> >> Q: What if a program attempts to mkdir /dev/nullmnt/foo to just >>create a file /dev/nullmnt/foo/barfile? >> A: /dev/nullmnt/foo must continue to exist or be accepted for a while, >>or perhaps for eternity. > > Well, the problem seems to be that a "directory" is not just data but > also contains metadata. While it's easy to write data to /dev/null, you > cannot simply discard metadata associated with a directory. So, such a > "/dev/null-directory" would have to remember metadata (at least all > created filenames including subdirectories) in the same way as other > filesystems do. Only file _content_ can be discarded. > To be honest, I still cannot see many sensible usecases for that... Since both of you seem to know about the (possible) problems, maybe you can take a look at my patch. http://7eggert.dyndns.org:8080/tmp/autounlink.patch (Not inline, because it would be duplicate in this thread.) (Yes, this patch needs some cleanup. I just did checkpatch.) First I thought I'd modify tmpfs to delete the file on O_CREAT, but it turned out tmpfs will increase the dentry count in order to prevent the delete-on-close effect. Skipping this step was allmost enough, I had to prevent link() from pinning these files, too. Some loops creating files or linking them did not show any decrease in available memory, and to the best of my knowlege, I did not introduce new memory leaks. And the best thing is: It's only 150 bytes of code. Not bad for an additional mount flag, is it? -- 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?
rzryyvzy <[EMAIL PROTECTED]> 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?
Please try the patch below. It will add an autounlink option to
tmpfs, which should automatically get rid of non-referenced files.
diff -X dontdiff -dpruN linux-2.6.24.pure/include/linux/shmem_fs.h
linux-2.6.24.autounlink/include/linux/shmem_fs.h
--- linux-2.6.24.pure/include/linux/shmem_fs.h 2006-11-29 22:57:37.0
+0100
+++ linux-2.6.24.autounlink/include/linux/shmem_fs.h2008-02-14
15:35:01.0 +0100
@@ -30,11 +30,14 @@ struct shmem_sb_info {
unsigned long free_blocks; /* How many are left for allocation */
unsigned long max_inodes; /* How many inodes are allowed */
unsigned long free_inodes; /* How many are left for allocation */
- int policy; /* Default NUMA memory alloc policy */
- nodemask_t policy_nodes;/* nodemask for preferred and bind */
+ unsigned int flags;
+ int policy; /* Default NUMA memory alloc policy */
+ nodemask_tpolicy_nodes; /* nodemask for preferred and bind */
spinlock_tstat_lock;
};
+#define TMPFS_FL_AUTOREMOVE 1
+
static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
{
return container_of(inode, struct shmem_inode_info, vfs_inode);
diff -X dontdiff -dpruN linux-2.6.24.pure/mm/shmem.c
linux-2.6.24.autounlink/mm/shmem.c
--- linux-2.6.24.pure/mm/shmem.c2008-01-25 15:09:39.0 +0100
+++ linux-2.6.24.autounlink/mm/shmem.c 2008-02-14 18:00:54.0 +0100
@@ -1747,31 +1747,41 @@ static int
shmem_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
{
struct inode *inode = shmem_get_inode(dir->i_sb, mode, dev);
+ struct shmem_sb_info *sbinfo = SHMEM_SB(dir->i_sb);
int error = -ENOSPC;
- if (inode) {
- error = security_inode_init_security(inode, dir, NULL, NULL,
-NULL);
- if (error) {
- if (error != -EOPNOTSUPP) {
- iput(inode);
- return error;
- }
- }
- error = shmem_acl_init(inode, dir);
- if (error) {
+ if (!inode)
+ return error;
+
+ error = security_inode_init_security(inode, dir, NULL, NULL,
+NULL);
+ if (error) {
+ if (error != -EOPNOTSUPP) {
iput(inode);
return error;
}
- if (dir->i_mode & S_ISGID) {
- inode->i_gid = dir->i_gid;
- if (S_ISDIR(mode))
- inode->i_mode |= S_ISGID;
- }
- dir->i_size += BOGO_DIRENT_SIZE;
- dir->i_ctime = dir->i_mtime = CURRENT_TIME;
- d_instantiate(dentry, inode);
+ }
+ error = shmem_acl_init(inode, dir);
+ if (error) {
+ iput(inode);
+ return error;
+ }
+ if (dir->i_mode & S_ISGID) {
+ inode->i_gid = dir->i_gid;
+ if (S_ISDIR(mode))
+ inode->i_mode |= S_ISGID;
+ }
+
+ dir->i_size += BOGO_DIRENT_SIZE;
+ dir->i_ctime = dir->i_mtime = CURRENT_TIME;
+ d_instantiate(dentry, inode);
+ if ( S_ISDIR(mode)
+ || !(sbinfo->flags & TMPFS_FL_AUTOREMOVE))
+ {
dget(dentry); /* Extra count - pin the dentry in core */
+ } else {
+ dir->i_size -= BOGO_DIRENT_SIZE;
+ drop_nlink(inode);
}
return error;
}
@@ -1800,6 +1810,11 @@ static int shmem_link(struct dentry *old
struct inode *inode = old_dentry->d_inode;
struct shmem_sb_info *sbinfo = SHMEM_SB(inode->i_sb);
+ /* In auto-unlink mode, the newly created link would be unlinked
+ immediately. We don't need to do anything here. */
+ if (sbinfo->flags &
Re: Is there a blackhole /dev/null directory?
rzryyvzy [EMAIL PROTECTED] 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?
Please try the patch below. It will add an autounlink option to
tmpfs, which should automatically get rid of non-referenced files.
diff -X dontdiff -dpruN linux-2.6.24.pure/include/linux/shmem_fs.h
linux-2.6.24.autounlink/include/linux/shmem_fs.h
--- linux-2.6.24.pure/include/linux/shmem_fs.h 2006-11-29 22:57:37.0
+0100
+++ linux-2.6.24.autounlink/include/linux/shmem_fs.h2008-02-14
15:35:01.0 +0100
@@ -30,11 +30,14 @@ struct shmem_sb_info {
unsigned long free_blocks; /* How many are left for allocation */
unsigned long max_inodes; /* How many inodes are allowed */
unsigned long free_inodes; /* How many are left for allocation */
- int policy; /* Default NUMA memory alloc policy */
- nodemask_t policy_nodes;/* nodemask for preferred and bind */
+ unsigned int flags;
+ int policy; /* Default NUMA memory alloc policy */
+ nodemask_tpolicy_nodes; /* nodemask for preferred and bind */
spinlock_tstat_lock;
};
+#define TMPFS_FL_AUTOREMOVE 1
+
static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
{
return container_of(inode, struct shmem_inode_info, vfs_inode);
diff -X dontdiff -dpruN linux-2.6.24.pure/mm/shmem.c
linux-2.6.24.autounlink/mm/shmem.c
--- linux-2.6.24.pure/mm/shmem.c2008-01-25 15:09:39.0 +0100
+++ linux-2.6.24.autounlink/mm/shmem.c 2008-02-14 18:00:54.0 +0100
@@ -1747,31 +1747,41 @@ static int
shmem_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
{
struct inode *inode = shmem_get_inode(dir-i_sb, mode, dev);
+ struct shmem_sb_info *sbinfo = SHMEM_SB(dir-i_sb);
int error = -ENOSPC;
- if (inode) {
- error = security_inode_init_security(inode, dir, NULL, NULL,
-NULL);
- if (error) {
- if (error != -EOPNOTSUPP) {
- iput(inode);
- return error;
- }
- }
- error = shmem_acl_init(inode, dir);
- if (error) {
+ if (!inode)
+ return error;
+
+ error = security_inode_init_security(inode, dir, NULL, NULL,
+NULL);
+ if (error) {
+ if (error != -EOPNOTSUPP) {
iput(inode);
return error;
}
- if (dir-i_mode S_ISGID) {
- inode-i_gid = dir-i_gid;
- if (S_ISDIR(mode))
- inode-i_mode |= S_ISGID;
- }
- dir-i_size += BOGO_DIRENT_SIZE;
- dir-i_ctime = dir-i_mtime = CURRENT_TIME;
- d_instantiate(dentry, inode);
+ }
+ error = shmem_acl_init(inode, dir);
+ if (error) {
+ iput(inode);
+ return error;
+ }
+ if (dir-i_mode S_ISGID) {
+ inode-i_gid = dir-i_gid;
+ if (S_ISDIR(mode))
+ inode-i_mode |= S_ISGID;
+ }
+
+ dir-i_size += BOGO_DIRENT_SIZE;
+ dir-i_ctime = dir-i_mtime = CURRENT_TIME;
+ d_instantiate(dentry, inode);
+ if ( S_ISDIR(mode)
+ || !(sbinfo-flags TMPFS_FL_AUTOREMOVE))
+ {
dget(dentry); /* Extra count - pin the dentry in core */
+ } else {
+ dir-i_size -= BOGO_DIRENT_SIZE;
+ drop_nlink(inode);
}
return error;
}
@@ -1800,6 +1810,11 @@ static int shmem_link(struct dentry *old
struct inode *inode = old_dentry-d_inode;
struct shmem_sb_info *sbinfo = SHMEM_SB(inode-i_sb);
+ /* In auto-unlink mode, the newly created link would be unlinked
+ immediately. We don't need to do anything here. */
+ if (sbinfo-flags TMPFS_FL_AUTOREMOVE)
+ return 0;
+
/*
Re: Is there a blackhole /dev/null directory?
Hans-Jürgen Koch [EMAIL PROTECTED] wrote: schrieb Jan Engelhardt [EMAIL PROTECTED]: There is a much more interesting 'problem' with a /dev/null directory. Q: Why would you need such a directory? A: To temporarily fool a program into believing it wrote something. Q: Should all files disappear? (e.g. unlink after open) A: Maybe not, programs may stat() the file right afterwards and get confused by the inexistence. Q: What if a program attempts to mkdir /dev/nullmnt/foo to just create a file /dev/nullmnt/foo/barfile? A: /dev/nullmnt/foo must continue to exist or be accepted for a while, or perhaps for eternity. Well, the problem seems to be that a directory is not just data but also contains metadata. While it's easy to write data to /dev/null, you cannot simply discard metadata associated with a directory. So, such a /dev/null-directory would have to remember metadata (at least all created filenames including subdirectories) in the same way as other filesystems do. Only file _content_ can be discarded. To be honest, I still cannot see many sensible usecases for that... Since both of you seem to know about the (possible) problems, maybe you can take a look at my patch. http://7eggert.dyndns.org:8080/tmp/autounlink.patch (Not inline, because it would be duplicate in this thread.) (Yes, this patch needs some cleanup. I just did checkpatch.) First I thought I'd modify tmpfs to delete the file on O_CREAT, but it turned out tmpfs will increase the dentry count in order to prevent the delete-on-close effect. Skipping this step was allmost enough, I had to prevent link() from pinning these files, too. Some loops creating files or linking them did not show any decrease in available memory, and to the best of my knowlege, I did not introduce new memory leaks. And the best thing is: It's only 150 bytes of code. Not bad for an additional mount flag, is it? -- 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] Avoid buffer overflows in get_user_pages()
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Feb 2008 16:17:33 -0700 Jonathan Corbet <[EMAIL PROTECTED]> wrote:
>> Avoid buffer overflows in get_user_pages()
>>
>> So I spent a while pounding my head against my monitor trying to figure
>> out the vmsplice() vulnerability - how could a failure to check for
>> *read* access turn into a root exploit? It turns out that it's a buffer
>> overflow problem which is made easy by the way get_user_pages() is
>> coded.
>>
>> In particular, "len" is a signed int, and it is only checked at the
>> *end* of a do {} while() loop. So, if it is passed in as zero, the loop
>> will execute once and decrement len to -1. At that point, the loop will
>> proceed until the next invalid address is found; in the process, it will
>> likely overflow the pages array passed in to get_user_pages().
[...]
> Can we just convert
>
> do {
> ...
> } while (len);
>
> into
>
> while (len) {
while (len > 0), if I understand this patch correctly.
--
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] Avoid buffer overflows in get_user_pages()
Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 11 Feb 2008 16:17:33 -0700 Jonathan Corbet [EMAIL PROTECTED] wrote:
Avoid buffer overflows in get_user_pages()
So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how could a failure to check for
*read* access turn into a root exploit? It turns out that it's a buffer
overflow problem which is made easy by the way get_user_pages() is
coded.
In particular, len is a signed int, and it is only checked at the
*end* of a do {} while() loop. So, if it is passed in as zero, the loop
will execute once and decrement len to -1. At that point, the loop will
proceed until the next invalid address is found; in the process, it will
likely overflow the pages array passed in to get_user_pages().
[...]
Can we just convert
do {
...
} while (len);
into
while (len) {
while (len 0), if I understand this patch correctly.
--
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] ide-core: remove conditional compiling with MODULE in ide-core.c
Denis Cheng <[EMAIL PROTECTED]> wrote:
> use module_init/module_exit to replace the original cond-compiling, these
> macros were well designed to deal module/built-in compiling.
>
> the original __setup with null string was invalid and not executed,
> __setup("", ide_setup);
>
> however, with the current module_param mechanics, module parameters also can
> be input on the kernel command line, with this style:
>
> ide-core.options="ide=nodma hdd=cdrom idebus=..."
>
> so Documentation/kernel-parameters.txt also updated.
> --- a/Documentation/kernel-parameters.txt
> - ide=[HW] (E)IDE subsystem
> - Format: ide=nodma or ide=doubler or ide=reverse
> - See Documentation/ide.txt.
> -
> - ide?= [HW] (E)IDE subsystem
> - Format: ide?=noprobe or chipset specific parameters.
> - See Documentation/ide.txt.
> -
> - idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
> + ide-core.options= [HW] (E)IDE subsystem
> + Format: ide-core.options="ide=nodma hdd=cdrom
> idebus=..."
IMO you should use separate options for things like nodma while you're at it.
¢¢
--
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] ide-core: remove conditional compiling with MODULE in ide-core.c
Denis Cheng [EMAIL PROTECTED] wrote: use module_init/module_exit to replace the original cond-compiling, these macros were well designed to deal module/built-in compiling. the original __setup with null string was invalid and not executed, __setup(, ide_setup); however, with the current module_param mechanics, module parameters also can be input on the kernel command line, with this style: ide-core.options=ide=nodma hdd=cdrom idebus=... so Documentation/kernel-parameters.txt also updated. --- a/Documentation/kernel-parameters.txt - ide=[HW] (E)IDE subsystem - Format: ide=nodma or ide=doubler or ide=reverse - See Documentation/ide.txt. - - ide?= [HW] (E)IDE subsystem - Format: ide?=noprobe or chipset specific parameters. - See Documentation/ide.txt. - - idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed + ide-core.options= [HW] (E)IDE subsystem + Format: ide-core.options=ide=nodma hdd=cdrom idebus=... IMO you should use separate options for things like nodma while you're at it. ¢¢ -- 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/
[PATCH] Introduce softpanic V.2
Enabling this option changes a hard panic on boot errors to a
soft panic, which does not stop the system completely.
You can still scroll the screen and read the messages.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
---
Fixed: s/SOFTPANIC/CONFIG_SOFTPANIC/
I did not implement shutting down the network on panic, which was requested
to let the watchdog reboot the machine. For this purpose, you should use
"panic=$n".
diff -pruN -X dontdiff linux-2.6.24.pure/include/linux/kernel.h
linux-2.6.24.softpanic/include/linux/kernel.h
--- linux-2.6.24.pure/include/linux/kernel.h2008-01-25 15:09:36.0
+0100
+++ linux-2.6.24.softpanic/include/linux/kernel.h 2008-01-25
15:31:26.0 +0100
@@ -130,6 +130,12 @@ extern struct atomic_notifier_head panic
extern long (*panic_blink)(long time);
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+ __attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#else
+# define softpanic(...) do { panic(__VA_ARGS__); } while (0)
+#endif
extern void oops_enter(void);
extern void oops_exit(void);
extern int oops_may_print(void);
diff -pruN -X dontdiff linux-2.6.24.pure/init/Kconfig
linux-2.6.24.softpanic/init/Kconfig
--- linux-2.6.24.pure/init/Kconfig 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/Kconfig 2008-01-25 15:15:08.0 +0100
@@ -526,6 +526,14 @@ config BUG
option for embedded systems with no facilities for reporting errors.
Just say Y.
+config SOFTPANIC
+ bool "Enable softpanic for boot errors" if EMBEDDED
+ default y
+ help
+ Enabling this option changes a hard panic on boot errors to a
+ soft panic, which does not stop the system completely.
+ You can still scroll the screen and read the messages.
+
config ELF_CORE
default y
bool "Enable ELF core dumps" if EMBEDDED
diff -pruN -X dontdiff linux-2.6.24.pure/init/do_mounts.c
linux-2.6.24.softpanic/init/do_mounts.c
--- linux-2.6.24.pure/init/do_mounts.c 2008-01-25 15:08:31.0 +0100
+++ linux-2.6.24.softpanic/init/do_mounts.c 2008-01-25 15:15:08.0
+0100
@@ -330,7 +330,7 @@ retry:
printk("Please append a correct \"root=\" boot option; here are
the available partitions:\n");
printk_all_partitions();
- panic("VFS: Unable to mount root fs on %s", b);
+ softpanic("VFS: Unable to mount root fs on %s", b);
}
printk("List of all partitions:\n");
@@ -342,7 +342,7 @@ retry:
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
- panic("VFS: Unable to mount root fs on %s", b);
+ softpanic("VFS: Unable to mount root fs on %s", b);
out:
putname(fs_names);
}
diff -pruN -X dontdiff linux-2.6.24.pure/init/main.c
linux-2.6.24.softpanic/init/main.c
--- linux-2.6.24.pure/init/main.c 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/main.c 2008-01-25 15:15:08.0 +0100
@@ -585,7 +585,7 @@ asmlinkage void __init start_kernel(void
*/
console_init();
if (panic_later)
- panic(panic_later, panic_param);
+ softpanic(panic_later, panic_param);
lockdep_info();
@@ -800,7 +800,7 @@ static int noinline init_post(void)
run_init_process("/bin/init");
run_init_process("/bin/sh");
- panic("No init found. Try passing init= option to kernel.");
+ softpanic("No init found. Try passing init= option to kernel.");
}
static int __init kernel_init(void * unused)
diff -pruN -X dontdiff linux-2.6.24.pure/kernel/panic.c
linux-2.6.24.softpanic/kernel/panic.c
--- linux-2.6.24.pure/kernel/panic.c2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/kernel/panic.c 2008-01-25 18:37:59.0
+0100
@@ -142,6 +142,66 @@ NORET_TYPE void panic(const char * fmt,
EXPORT_SYMBOL(panic);
+#ifdef CONFIG_SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+{
+ long i;
+ static char buf[1024];
+ va_list args;
+#if defined(CONFIG_S390)
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+#endif
+
+ va_start(args, fmt);
+ vsnprintf(buf, sizeof(buf), fmt, args);
+ va_end(args);
+ printk(KERN_EMERG "Kernel panic - not syncing: %s\n", buf);
+
+ atomic_notifier_call_chain(_notifier_list, 0, buf);
+
+ if (!panic_blink)
+ panic_blink = no_blink;
+
+ if (panic_timeout > 0) {
+ /*
+* Delay timeout seconds before rebooting the machine.
+* We can't use the "normal" timers since
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
Trond Myklebust <[EMAIL PROTECTED]> wrote: > On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote: >> On Monday 28 January 2008 05:13:09 Trond Myklebust wrote: >> > On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote: >> > > The problem is that it's not a race in who gets to do its thing first, >> > > but a parallel reader can actually see a corrupted value from the two >> > > independent words on 32bit (e.g. during a 4GB). And this could actually >> > > completely corrupt f_pos when it happens with two racing relative seeks >> > > or read/write()s >> > > >> > > I would consider that a bug. >> > >> > I disagree. The corruption occurs because this isn't a situation that is >> > allowed by either POSIX or SUSv2/v3. Exactly what spec are you referring >> > to here? >> >> No specific spec, just general quality of implementation. We normally don't >> have non thread safe system calls even if it was in theory allowed by some >> specification. > > We've had the existing implementation for quite some time. The arguments > against changing it have been the same all along: if your application > wants to share files between threads, the portability argument implies > that you should either use pread/pwrite or use a mutex or some other > form of synchronisation primitive in order to ensure that > lseek()/read()/write() do not overlap. Does anything in the kernel depend on f_pos being valid? E.g. is it possible to read beyond the EOF using this race, or to have files larger than the ulimit? If not, update the manpage and be done. ¢¢ -- 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/
[PATCH] Introduce softpanic V.2
Enabling this option changes a hard panic on boot errors to a
soft panic, which does not stop the system completely.
You can still scroll the screen and read the messages.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
---
Fixed: s/SOFTPANIC/CONFIG_SOFTPANIC/
I did not implement shutting down the network on panic, which was requested
to let the watchdog reboot the machine. For this purpose, you should use
panic=$n.
diff -pruN -X dontdiff linux-2.6.24.pure/include/linux/kernel.h
linux-2.6.24.softpanic/include/linux/kernel.h
--- linux-2.6.24.pure/include/linux/kernel.h2008-01-25 15:09:36.0
+0100
+++ linux-2.6.24.softpanic/include/linux/kernel.h 2008-01-25
15:31:26.0 +0100
@@ -130,6 +130,12 @@ extern struct atomic_notifier_head panic
extern long (*panic_blink)(long time);
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+ __attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#else
+# define softpanic(...) do { panic(__VA_ARGS__); } while (0)
+#endif
extern void oops_enter(void);
extern void oops_exit(void);
extern int oops_may_print(void);
diff -pruN -X dontdiff linux-2.6.24.pure/init/Kconfig
linux-2.6.24.softpanic/init/Kconfig
--- linux-2.6.24.pure/init/Kconfig 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/Kconfig 2008-01-25 15:15:08.0 +0100
@@ -526,6 +526,14 @@ config BUG
option for embedded systems with no facilities for reporting errors.
Just say Y.
+config SOFTPANIC
+ bool Enable softpanic for boot errors if EMBEDDED
+ default y
+ help
+ Enabling this option changes a hard panic on boot errors to a
+ soft panic, which does not stop the system completely.
+ You can still scroll the screen and read the messages.
+
config ELF_CORE
default y
bool Enable ELF core dumps if EMBEDDED
diff -pruN -X dontdiff linux-2.6.24.pure/init/do_mounts.c
linux-2.6.24.softpanic/init/do_mounts.c
--- linux-2.6.24.pure/init/do_mounts.c 2008-01-25 15:08:31.0 +0100
+++ linux-2.6.24.softpanic/init/do_mounts.c 2008-01-25 15:15:08.0
+0100
@@ -330,7 +330,7 @@ retry:
printk(Please append a correct \root=\ boot option; here are
the available partitions:\n);
printk_all_partitions();
- panic(VFS: Unable to mount root fs on %s, b);
+ softpanic(VFS: Unable to mount root fs on %s, b);
}
printk(List of all partitions:\n);
@@ -342,7 +342,7 @@ retry:
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
- panic(VFS: Unable to mount root fs on %s, b);
+ softpanic(VFS: Unable to mount root fs on %s, b);
out:
putname(fs_names);
}
diff -pruN -X dontdiff linux-2.6.24.pure/init/main.c
linux-2.6.24.softpanic/init/main.c
--- linux-2.6.24.pure/init/main.c 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/main.c 2008-01-25 15:15:08.0 +0100
@@ -585,7 +585,7 @@ asmlinkage void __init start_kernel(void
*/
console_init();
if (panic_later)
- panic(panic_later, panic_param);
+ softpanic(panic_later, panic_param);
lockdep_info();
@@ -800,7 +800,7 @@ static int noinline init_post(void)
run_init_process(/bin/init);
run_init_process(/bin/sh);
- panic(No init found. Try passing init= option to kernel.);
+ softpanic(No init found. Try passing init= option to kernel.);
}
static int __init kernel_init(void * unused)
diff -pruN -X dontdiff linux-2.6.24.pure/kernel/panic.c
linux-2.6.24.softpanic/kernel/panic.c
--- linux-2.6.24.pure/kernel/panic.c2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/kernel/panic.c 2008-01-25 18:37:59.0
+0100
@@ -142,6 +142,66 @@ NORET_TYPE void panic(const char * fmt,
EXPORT_SYMBOL(panic);
+#ifdef CONFIG_SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+{
+ long i;
+ static char buf[1024];
+ va_list args;
+#if defined(CONFIG_S390)
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+#endif
+
+ va_start(args, fmt);
+ vsnprintf(buf, sizeof(buf), fmt, args);
+ va_end(args);
+ printk(KERN_EMERG Kernel panic - not syncing: %s\n, buf);
+
+ atomic_notifier_call_chain(panic_notifier_list, 0, buf);
+
+ if (!panic_blink)
+ panic_blink = no_blink;
+
+ if (panic_timeout 0) {
+ /*
+* Delay timeout seconds before rebooting the machine.
+* We can't use the normal timers since we just panicked..
+*/
+ printk(KERN_EMERG Rebooting in %d seconds.., panic_timeout);
+ for (i = 0; i panic_timeout*1000; ) {
+ touch_nmi_watchdog
Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
Trond Myklebust [EMAIL PROTECTED] wrote: On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote: On Monday 28 January 2008 05:13:09 Trond Myklebust wrote: On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote: The problem is that it's not a race in who gets to do its thing first, but a parallel reader can actually see a corrupted value from the two independent words on 32bit (e.g. during a 4GB). And this could actually completely corrupt f_pos when it happens with two racing relative seeks or read/write()s I would consider that a bug. I disagree. The corruption occurs because this isn't a situation that is allowed by either POSIX or SUSv2/v3. Exactly what spec are you referring to here? No specific spec, just general quality of implementation. We normally don't have non thread safe system calls even if it was in theory allowed by some specification. We've had the existing implementation for quite some time. The arguments against changing it have been the same all along: if your application wants to share files between threads, the portability argument implies that you should either use pread/pwrite or use a mutex or some other form of synchronisation primitive in order to ensure that lseek()/read()/write() do not overlap. Does anything in the kernel depend on f_pos being valid? E.g. is it possible to read beyond the EOF using this race, or to have files larger than the ulimit? If not, update the manpage and be done. ¢¢ -- 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] [14/18] BKL-removal: Add unlocked_fasync
> +++ linux/fs/fcntl.c
> @@ -240,11 +240,15 @@ static int setfl(int fd, struct file * f
>
> lock_kernel();
> if ((arg ^ filp->f_flags) & FASYNC) {
> - if (filp->f_op && filp->f_op->fasync) {
> + if (filp->f_op && filp->f_op->unlocked_fasync)
> + error = filp->f_op->unlocked_fasync(fd, filp,
> + !!(arg & FASYNC));
> + else if (filp->f_op && filp->f_op->fasync) {
> error = filp->f_op->fasync(fd, filp, (arg & FASYNC) !=
0);
> if (error < 0)
> goto out;
No goto if you use unlocked_fasync?
> }
> + /* AK: no else error = -EINVAL here? */
> }
>
> filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
> --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [14/18] BKL-removal: Add unlocked_fasync
+++ linux/fs/fcntl.c
@@ -240,11 +240,15 @@ static int setfl(int fd, struct file * f
lock_kernel();
if ((arg ^ filp-f_flags) FASYNC) {
- if (filp-f_op filp-f_op-fasync) {
+ if (filp-f_op filp-f_op-unlocked_fasync)
+ error = filp-f_op-unlocked_fasync(fd, filp,
+ !!(arg FASYNC));
+ else if (filp-f_op filp-f_op-fasync) {
error = filp-f_op-fasync(fd, filp, (arg FASYNC) !=
0);
if (error 0)
goto out;
No goto if you use unlocked_fasync?
}
+ /* AK: no else error = -EINVAL here? */
}
filp-f_flags = (arg SETFL_MASK) | (filp-f_flags ~SETFL_MASK);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Introduce softpanic
On Fri, 25 Jan 2008, Jan Engelhardt wrote: > On Jan 25 2008 15:54, Bodo Eggert wrote: > >+#ifdef SOFTPANIC > > #ifdef CONFIG_SOFTPANIC? Thanks. I remember having fixed it ... -- Professionals are predictable, it's the amateurs that are dangerous. -- 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] Introduce softpanic
On Fri, 25 Jan 2008, Andi Kleen wrote: > Bodo Eggert <[EMAIL PROTECTED]> writes: > > Enabling this option changes a hard panic on boot errors to a > > soft panic, which does not stop the system completely. > > You can still scroll the screen and read the messages. > > I don't think it's a good idea to keep the network running in the > soft panic. A lot of people have set ups that use ping was a watchdog > and with nfsroot/ip=dhcp ping does work quite well before > mounting root and then the watchdog might not pick up the > soft panic. > Using a polled keyboard driver after panic seems to be the better > option to me, but if you want softpanic you should probably > at least add a suitable panic notifier to the network stack > to shut it all down. I have no idea on how to do it. If somebody has a big red arrow pointing to a HOWTO, I can give it a try. OTOH, I think the panic timeout should do the job nicely. -- If you talk about race, it does not make you a racist. If you see distinctions between the genders, it does not make you a sexist. If you think critically about a denomination, it does not make you anti-religion. If you accept but don't celebrate homosexuality, it does not make you a homophobe.Charlton Heston -- 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/
[PATCH] Introduce softpanic
Enabling this option changes a hard panic on boot errors to a
soft panic, which does not stop the system completely.
You can still scroll the screen and read the messages.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -pruN -X dontdiff linux-2.6.24.pure/include/linux/kernel.h
linux-2.6.24.softpanic/include/linux/kernel.h
--- linux-2.6.24.pure/include/linux/kernel.h2008-01-25 15:09:36.0
+0100
+++ linux-2.6.24.softpanic/include/linux/kernel.h 2008-01-25
15:31:26.0 +0100
@@ -130,6 +130,12 @@ extern struct atomic_notifier_head panic
extern long (*panic_blink)(long time);
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+ __attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#else
+# define softpanic(...) do { panic(__VA_ARGS__); } while (0)
+#endif
extern void oops_enter(void);
extern void oops_exit(void);
extern int oops_may_print(void);
diff -pruN -X dontdiff linux-2.6.24.pure/init/Kconfig
linux-2.6.24.softpanic/init/Kconfig
--- linux-2.6.24.pure/init/Kconfig 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/Kconfig 2008-01-25 15:15:08.0 +0100
@@ -526,6 +526,14 @@ config BUG
option for embedded systems with no facilities for reporting errors.
Just say Y.
+config SOFTPANIC
+ bool "Enable softpanic for boot errors" if EMBEDDED
+ default y
+ help
+ Enabling this option changes a hard panic on boot errors to a
+ soft panic, which does not stop the system completely.
+ You can still scroll the screen and read the messages.
+
config ELF_CORE
default y
bool "Enable ELF core dumps" if EMBEDDED
diff -pruN -X dontdiff linux-2.6.24.pure/init/do_mounts.c
linux-2.6.24.softpanic/init/do_mounts.c
--- linux-2.6.24.pure/init/do_mounts.c 2008-01-25 15:08:31.0 +0100
+++ linux-2.6.24.softpanic/init/do_mounts.c 2008-01-25 15:15:08.0
+0100
@@ -330,7 +330,7 @@ retry:
printk("Please append a correct \"root=\" boot option; here are
the available partitions:\n");
printk_all_partitions();
- panic("VFS: Unable to mount root fs on %s", b);
+ softpanic("VFS: Unable to mount root fs on %s", b);
}
printk("List of all partitions:\n");
@@ -342,7 +342,7 @@ retry:
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
- panic("VFS: Unable to mount root fs on %s", b);
+ softpanic("VFS: Unable to mount root fs on %s", b);
out:
putname(fs_names);
}
diff -pruN -X dontdiff linux-2.6.24.pure/init/main.c
linux-2.6.24.softpanic/init/main.c
--- linux-2.6.24.pure/init/main.c 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/main.c 2008-01-25 15:15:08.0 +0100
@@ -585,7 +585,7 @@ asmlinkage void __init start_kernel(void
*/
console_init();
if (panic_later)
- panic(panic_later, panic_param);
+ softpanic(panic_later, panic_param);
lockdep_info();
@@ -800,7 +800,7 @@ static int noinline init_post(void)
run_init_process("/bin/init");
run_init_process("/bin/sh");
- panic("No init found. Try passing init= option to kernel.");
+ softpanic("No init found. Try passing init= option to kernel.");
}
static int __init kernel_init(void * unused)
diff -pruN -X dontdiff linux-2.6.24.pure/kernel/panic.c
linux-2.6.24.softpanic/kernel/panic.c
--- linux-2.6.24.pure/kernel/panic.c2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/kernel/panic.c 2008-01-25 15:38:52.0
+0100
@@ -142,6 +142,66 @@ NORET_TYPE void panic(const char * fmt,
EXPORT_SYMBOL(panic);
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+{
+ long i;
+ static char buf[1024];
+ va_list args;
+#if defined(CONFIG_S390)
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+#endif
+
+ va_start(args, fmt);
+ vsnprintf(buf, sizeof(buf), fmt, args);
+ va_end(args);
+ printk(KERN_EMERG "Kernel panic - not syncing: %s\n", buf);
+
+ atomic_notifier_call_chain(_notifier_list, 0, buf);
+
+ if (!panic_blink)
+ panic_blink = no_blink;
+
+ if (panic_timeout > 0) {
+ /*
+* Delay timeout seconds before rebooting the machine.
+* We can't use the "normal" timers since we just panicked..
+*/
+ printk(KERN_EMERG "Rebooting in %d seconds..", panic_timeout);
+ for (i = 0; i < panic_timeout*1000; ) {
+ touch_nmi_watchdog();
+
Re: [PATCH] Introduce softpanic
On Fri, 25 Jan 2008, Jan Engelhardt wrote: On Jan 25 2008 15:54, Bodo Eggert wrote: +#ifdef SOFTPANIC #ifdef CONFIG_SOFTPANIC? Thanks. I remember having fixed it ... -- Professionals are predictable, it's the amateurs that are dangerous. -- 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/
[PATCH] Introduce softpanic
Enabling this option changes a hard panic on boot errors to a
soft panic, which does not stop the system completely.
You can still scroll the screen and read the messages.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
diff -pruN -X dontdiff linux-2.6.24.pure/include/linux/kernel.h
linux-2.6.24.softpanic/include/linux/kernel.h
--- linux-2.6.24.pure/include/linux/kernel.h2008-01-25 15:09:36.0
+0100
+++ linux-2.6.24.softpanic/include/linux/kernel.h 2008-01-25
15:31:26.0 +0100
@@ -130,6 +130,12 @@ extern struct atomic_notifier_head panic
extern long (*panic_blink)(long time);
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+ __attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#else
+# define softpanic(...) do { panic(__VA_ARGS__); } while (0)
+#endif
extern void oops_enter(void);
extern void oops_exit(void);
extern int oops_may_print(void);
diff -pruN -X dontdiff linux-2.6.24.pure/init/Kconfig
linux-2.6.24.softpanic/init/Kconfig
--- linux-2.6.24.pure/init/Kconfig 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/Kconfig 2008-01-25 15:15:08.0 +0100
@@ -526,6 +526,14 @@ config BUG
option for embedded systems with no facilities for reporting errors.
Just say Y.
+config SOFTPANIC
+ bool Enable softpanic for boot errors if EMBEDDED
+ default y
+ help
+ Enabling this option changes a hard panic on boot errors to a
+ soft panic, which does not stop the system completely.
+ You can still scroll the screen and read the messages.
+
config ELF_CORE
default y
bool Enable ELF core dumps if EMBEDDED
diff -pruN -X dontdiff linux-2.6.24.pure/init/do_mounts.c
linux-2.6.24.softpanic/init/do_mounts.c
--- linux-2.6.24.pure/init/do_mounts.c 2008-01-25 15:08:31.0 +0100
+++ linux-2.6.24.softpanic/init/do_mounts.c 2008-01-25 15:15:08.0
+0100
@@ -330,7 +330,7 @@ retry:
printk(Please append a correct \root=\ boot option; here are
the available partitions:\n);
printk_all_partitions();
- panic(VFS: Unable to mount root fs on %s, b);
+ softpanic(VFS: Unable to mount root fs on %s, b);
}
printk(List of all partitions:\n);
@@ -342,7 +342,7 @@ retry:
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
- panic(VFS: Unable to mount root fs on %s, b);
+ softpanic(VFS: Unable to mount root fs on %s, b);
out:
putname(fs_names);
}
diff -pruN -X dontdiff linux-2.6.24.pure/init/main.c
linux-2.6.24.softpanic/init/main.c
--- linux-2.6.24.pure/init/main.c 2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/init/main.c 2008-01-25 15:15:08.0 +0100
@@ -585,7 +585,7 @@ asmlinkage void __init start_kernel(void
*/
console_init();
if (panic_later)
- panic(panic_later, panic_param);
+ softpanic(panic_later, panic_param);
lockdep_info();
@@ -800,7 +800,7 @@ static int noinline init_post(void)
run_init_process(/bin/init);
run_init_process(/bin/sh);
- panic(No init found. Try passing init= option to kernel.);
+ softpanic(No init found. Try passing init= option to kernel.);
}
static int __init kernel_init(void * unused)
diff -pruN -X dontdiff linux-2.6.24.pure/kernel/panic.c
linux-2.6.24.softpanic/kernel/panic.c
--- linux-2.6.24.pure/kernel/panic.c2008-01-25 15:09:38.0 +0100
+++ linux-2.6.24.softpanic/kernel/panic.c 2008-01-25 15:38:52.0
+0100
@@ -142,6 +142,66 @@ NORET_TYPE void panic(const char * fmt,
EXPORT_SYMBOL(panic);
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char *fmt, ...)
+{
+ long i;
+ static char buf[1024];
+ va_list args;
+#if defined(CONFIG_S390)
+ unsigned long caller = (unsigned long) __builtin_return_address(0);
+#endif
+
+ va_start(args, fmt);
+ vsnprintf(buf, sizeof(buf), fmt, args);
+ va_end(args);
+ printk(KERN_EMERG Kernel panic - not syncing: %s\n, buf);
+
+ atomic_notifier_call_chain(panic_notifier_list, 0, buf);
+
+ if (!panic_blink)
+ panic_blink = no_blink;
+
+ if (panic_timeout 0) {
+ /*
+* Delay timeout seconds before rebooting the machine.
+* We can't use the normal timers since we just panicked..
+*/
+ printk(KERN_EMERG Rebooting in %d seconds.., panic_timeout);
+ for (i = 0; i panic_timeout*1000; ) {
+ touch_nmi_watchdog();
+ i += panic_blink(i);
+ mdelay(1);
+ i++;
+ }
+ /* This will not be a clean reboot, with everything
Re: [PATCH] Introduce softpanic
On Fri, 25 Jan 2008, Andi Kleen wrote: Bodo Eggert [EMAIL PROTECTED] writes: Enabling this option changes a hard panic on boot errors to a soft panic, which does not stop the system completely. You can still scroll the screen and read the messages. I don't think it's a good idea to keep the network running in the soft panic. A lot of people have set ups that use ping was a watchdog and with nfsroot/ip=dhcp ping does work quite well before mounting root and then the watchdog might not pick up the soft panic. Using a polled keyboard driver after panic seems to be the better option to me, but if you want softpanic you should probably at least add a suitable panic notifier to the network stack to shut it all down. I have no idea on how to do it. If somebody has a big red arrow pointing to a HOWTO, I can give it a try. OTOH, I think the panic timeout should do the job nicely. -- If you talk about race, it does not make you a racist. If you see distinctions between the genders, it does not make you a sexist. If you think critically about a denomination, it does not make you anti-religion. If you accept but don't celebrate homosexuality, it does not make you a homophobe.Charlton Heston -- 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] Parallelize IO for e2fsck
Alan Cox <[EMAIL PROTECTED]> wrote: >> I'd tried to advocate SIGDANGER some years ago as well, but none of >> the kernel maintainers were interested. It definitely makes sense >> to have some sort of mechanism like this. At the time I first brought >> it up it was in conjunction with Netscape using too much cache on some >> system, but it would be just as useful for all kinds of other memory- >> hungry applications. > > There is an early thread for a /proc file which you can add to your > poll() set and it will wake people when memory is low. Very elegant and > if async support is added it will also give you the signal variant for > free. IMO you'll need a userspace daemon. The kernel does only know about the amount of memory available / recommended for a system (or container), while the user knows which program's cache is most precious today. (Off cause the userspace daemon will in turn need the /proc file.) I think a single, system-wide signal is the second-to worst solution: All applications (or the wrong one, if you select one) would free their caches and start to crawl, and either stay in this state or slowly increase their caches again until they get signaled again. And the signal would either come too early or too late. The userspace daemon could collect the weighted demand of memory from all applications and tell them how much to use. -- 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] Parallelize IO for e2fsck
Alan Cox [EMAIL PROTECTED] wrote: I'd tried to advocate SIGDANGER some years ago as well, but none of the kernel maintainers were interested. It definitely makes sense to have some sort of mechanism like this. At the time I first brought it up it was in conjunction with Netscape using too much cache on some system, but it would be just as useful for all kinds of other memory- hungry applications. There is an early thread for a /proc file which you can add to your poll() set and it will wake people when memory is low. Very elegant and if async support is added it will also give you the signal variant for free. IMO you'll need a userspace daemon. The kernel does only know about the amount of memory available / recommended for a system (or container), while the user knows which program's cache is most precious today. (Off cause the userspace daemon will in turn need the /proc file.) I think a single, system-wide signal is the second-to worst solution: All applications (or the wrong one, if you select one) would free their caches and start to crawl, and either stay in this state or slowly increase their caches again until they get signaled again. And the signal would either come too early or too late. The userspace daemon could collect the weighted demand of memory from all applications and tell them how much to use. -- 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 2/2] 8250_pnp: register x86 COM ports at the conventional ttyS names
Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> On Wednesday 16 January 2008 11:44:37 am H. Peter Anvin wrote:
>> Bjorn Helgaas wrote:
>> > +#ifdef CONFIG_X86
>> > + switch (port->iobase) {
>> > + case 0x3f8: return 0; /* COM1 -> ttyS0 */
>> > + case 0x2f8: return 1; /* COM2 -> ttyS1 */
>> > + case 0x3e8: return 2; /* COM3 -> ttyS2 */
>> > + case 0x2e8: return 3; /* COM4 -> ttyS3 */
>> > + }
>> > +#endif
>> > +
>>
>> Arguably, the right thing is to use the addresses present in the array
>> at address 0x400. In particular, COM3 and COM4 aren't always at those
>> addresses.
>
> Wow. I bow before your storehouse of x86 arcana :-)
>
> I guess you're referring to the "BIOS data area," which I'd never
> heard of before (but fortunately, Google knows).
You'll want to google for Ralph Brown ...
if your back allowes bowing that much.
> What would you think about doing this only for COM1 and COM2? The
> only real value for doing this in the first place is so "console=ttyS0"
> always goes to COM1, even if we don't have SERIAL_PORT_DFNS. User-
> space ought to use some sort of udev magic if it cares about persistent
> naming.
Since the first four COM ports are magic, and since using the BIOS port
numbers will move the non-legacy ports anyway, you should use all up to
four stored port numbers.
BTW1: These addresses may be used to detect ports on non-standard addresses,
but unfortunately they don't tell the IRQ.
BTW2: When I submitted a patch using the BIOS data area, I was told that it
might not exist on systems booting from non-PC firmware. This claim was not
yet backed with any knowledge, nor did anybody suggest a way to detect this
situation.
--
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 2/2] 8250_pnp: register x86 COM ports at the conventional ttyS names
Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Wednesday 16 January 2008 11:44:37 am H. Peter Anvin wrote:
Bjorn Helgaas wrote:
+#ifdef CONFIG_X86
+ switch (port-iobase) {
+ case 0x3f8: return 0; /* COM1 - ttyS0 */
+ case 0x2f8: return 1; /* COM2 - ttyS1 */
+ case 0x3e8: return 2; /* COM3 - ttyS2 */
+ case 0x2e8: return 3; /* COM4 - ttyS3 */
+ }
+#endif
+
Arguably, the right thing is to use the addresses present in the array
at address 0x400. In particular, COM3 and COM4 aren't always at those
addresses.
Wow. I bow before your storehouse of x86 arcana :-)
I guess you're referring to the BIOS data area, which I'd never
heard of before (but fortunately, Google knows).
You'll want to google for Ralph Brown ...
if your back allowes bowing that much.
What would you think about doing this only for COM1 and COM2? The
only real value for doing this in the first place is so console=ttyS0
always goes to COM1, even if we don't have SERIAL_PORT_DFNS. User-
space ought to use some sort of udev magic if it cares about persistent
naming.
Since the first four COM ports are magic, and since using the BIOS port
numbers will move the non-legacy ports anyway, you should use all up to
four stored port numbers.
BTW1: These addresses may be used to detect ports on non-standard addresses,
but unfortunately they don't tell the IRQ.
BTW2: When I submitted a patch using the BIOS data area, I was told that it
might not exist on systems booting from non-PC firmware. This claim was not
yet backed with any knowledge, nor did anybody suggest a way to detect this
situation.
--
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: The ext3 way of journalling
On Fri, 11 Jan 2008, Lennart Sorensen wrote: > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: > > What can happen if someone does tune2fs -Lroot /dev/usbstick > > and puts that stick into this system? > > Don't know. I use UUIDs rather than LABELs. Having duplicated labels > just means being careless. Having duplicate UUIDs should require being > malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. -- Fun things to slip into your budget Not in a budget, but in an annual report: An employee stole 500,000+. They accounted for it on the annual report as 'involountary employee relations expense' -- 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: The ext3 way of journalling
Matthias Schniedermeyer <[EMAIL PROTECTED]> wrote: >> > Don't use udev then. Good old static dev works fine if you have a fixed >> > set of devices. >> >> It doesn't, with the unpredictable SCSI mapping insanity. > > That what LABEL und UUID-Support in mount is for. > > You label the filesystems (e2label for ext2 and ext3) and use that label to > mount them > > - fstab - > LABEL=root /xfs defaults,noatime 0 1 > LABEL=boot /bootext2defaults,noatime 0 2 What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? -- 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: [RFD] Incremental fsck
Al Boldi <[EMAIL PROTECTED]> wrote: > Even after a black-out shutdown, the corruption is pretty minimal, using > ext3fs at least. So let's take advantage of this fact and do an optimistic > fsck, to assure integrity per-dir, and assume no external corruption. Then > we release this checked dir to the wild (optionally ro), and check the next. > Once we find external inconsistencies we either fix it unconditionally, > based on some preconfigured actions, or present the user with options. Maybe we can know the changes that need to be done in order to fix the filesystem. Let's record this information in - eh - let's call it a journal! -- 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] Clustering indirect blocks in Ext3
Abhishek Rai <[EMAIL PROTECTED]> wrote: > Putting metacluster at the end of the block group gives slightly > inferior sequential read throughput compared to putting it in the > beginning or the middle, but the difference is very tiny and exists > only for large files that span multiple block groups. Just an idea: What about putting it into the end of the previous block group (except for the first group, off cause) and starting to read the block group a little earlier (readahead/~before)? I imagine it might be about as good as placing it at the beginning while avoiding the fragmentation. -- 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: [RFD] Incremental fsck
Al Boldi [EMAIL PROTECTED] wrote: Even after a black-out shutdown, the corruption is pretty minimal, using ext3fs at least. So let's take advantage of this fact and do an optimistic fsck, to assure integrity per-dir, and assume no external corruption. Then we release this checked dir to the wild (optionally ro), and check the next. Once we find external inconsistencies we either fix it unconditionally, based on some preconfigured actions, or present the user with options. Maybe we can know the changes that need to be done in order to fix the filesystem. Let's record this information in - eh - let's call it a journal! -- 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] Clustering indirect blocks in Ext3
Abhishek Rai [EMAIL PROTECTED] wrote: Putting metacluster at the end of the block group gives slightly inferior sequential read throughput compared to putting it in the beginning or the middle, but the difference is very tiny and exists only for large files that span multiple block groups. Just an idea: What about putting it into the end of the previous block group (except for the first group, off cause) and starting to read the block group a little earlier (readahead/~before)? I imagine it might be about as good as placing it at the beginning while avoiding the fragmentation. -- 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: The ext3 way of journalling
Matthias Schniedermeyer [EMAIL PROTECTED] wrote: Don't use udev then. Good old static dev works fine if you have a fixed set of devices. It doesn't, with the unpredictable SCSI mapping insanity. That what LABEL und UUID-Support in mount is for. You label the filesystems (e2label for ext2 and ext3) and use that label to mount them - fstab - LABEL=root /xfs defaults,noatime 0 1 LABEL=boot /bootext2defaults,noatime 0 2 What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? -- 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: The ext3 way of journalling
On Fri, 11 Jan 2008, Lennart Sorensen wrote: On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote: What can happen if someone does tune2fs -Lroot /dev/usbstick and puts that stick into this system? Don't know. I use UUIDs rather than LABELs. Having duplicated labels just means being careless. Having duplicate UUIDs should require being malicous. That's exactly what you have to assume for your users. Otherwise, you could remove any security feature from the system. -- Fun things to slip into your budget Not in a budget, but in an annual report: An employee stole 500,000+. They accounted for it on the annual report as 'involountary employee relations expense' -- 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: The ext3 way of journalling
Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > On 2008-01-08, Jan Engelhardt <[EMAIL PROTECTED]> wrote: >> "Power users" may still >> use the index= option of sound card modules and wire it up in >> /etc/modprobe.d if they prefer. > > Another very cryptic directory whose contents say nothing to me. > Configuration files should be self-documenting and editable, > instead having to be created based on long documentation. > The simple /etc/modules -- which at least Debian's stock kernels > do not use -- qualifies, but few other files these days do. > >> You can guess my answer: udev will fix it. > > And break everything else, such as my symlinks, permissions, etc. > I'm not going to learn its cryptic special-case config files for > such trivial tasks as creating a fucking symlink or change the > permissions of a file, for which exist general purpose methods: > chmod, chown, ln -s. Edit the start script, append your commands to create the links. Or edit the correct file in /etc/udev/rules.d to include the links. >> Well what do you expect of it? The kernel does not keep USB port <-> >> SCSI device mappings. Neither USB device <-> SCSI device mapping, >> because not all USB ports or USB devices are mass-storage devices. >> It just is not the kernel's job. > > Mapping everything to scsi nodes is brain damaged. The old hda, hdb, > etc. mappings had somewhat clear correspondence between to physical > evice addresses, and were easy to use without such complicated crap > as udev. Of course, I'd prefer just device unique IDs being used, > where possible... but I'm not going to suffer udev for that. If you wire your devices to a named/numbered port, you can use one device node for each port. Therefore it's sane to create hda to hdd, fd0 to fd3, etc. But if you don't have a fixed mapping (USB), or if you'd have too many possible (and mostly unused) ports for the available amount of devices (SCSI), you can not create fixed numbers. Even for hde ..., you have no native ordering, you can only tell the first controller from the rest. When the SCSI naming was created, there were at most 256 SCSI devices of each kind. Since each partition is a SCSI device, too, you had at most 16 disks of up to 15 partitions! This was later extended to 128 disks. If you'd hardcode the controller, linux would have been unable to support more than 8 SCSI controllers. The result was the semi-random enumeration of the SCSI devices, and all the hacks trying to work around that. (google for Joerg Schilling lkml) Udev provides a clean way of naming the devices, using the static information from the devices or the path. I agree that the current udev documentation makes it hard to even find the settings you'd like to change. That's because the documentation is meant for developers, while the configuration is themed by the distribution. The udev files itself are as simple as possible. Imagine them to be XML, like the pile of HAL, DBUS and KDE automatically mounting my disks using the wrong settings into the wrong directory and forcing me to su in order to umount them! I temporarily beat that beast, but the kill is still on the TODO list. Maybe as soon as I find more^W usable^W documentation ... >> May I remind you that the kernel also "loses" all your network interface >> configuration, routes, firewalling rules and all sysctl settings at >> boot (sic: reboot & powerdown). > > But traditional /dev does not lose permissions and symlinks. udev > tmpfs shadow brain damage does. You have to illogically and > inconveniently edit udev's cryptic config files instead, and yet > it in no way stops /dev from being modified. You aren't stopped from directly poking the memory and crashing the systems either - if you are root. Or from deleting all nodes on a classic /dev. Don't do that then. >> Nonsense. The kernel notices udev about all available hardware and udev >> will load modules. It has nothing to do with initrd, in fact, this very >> step of loading a gazillion of modules is done after initrd has passed >> control on to /sbin/init. At least, in opensuse. > > I've never seen a system that would do so. And I won't use udev. No system can load modules that are not on initrd, and only needed-for-boot modules are usually put on the initrd. The bulk of modules must be loaded from the real root. This seems to work quite well (except not here because I prefer to include all necessary drivers in the kernel.) I've debugged hotplug, too, and I found it was a wrapper around a wrapper around ... a script that would be supposed to load the required firmware, except it did neither load it nor provide a way to find out why it didn't. Each HOWTO mentioned a different directory to use, and a different filename. I'd have settled for manually loading the firmware, but hacking the scripts to pieces was finally easier than finding out how I was supposed to do that. I did not need to install a firmware after this, therefore I don't know if udev is better, but
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 8 Jan 2008, Ondrej Zary wrote: > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote: > > Windows these days does delays with timing loops or the scheduler. It > > doesn't use a "port". Also, Windows XP only supports machines that tend > > not to have timing problems that use delays. Instead, if a device takes > > a while to respond, it has a "busy bit" in some port or memory slot that > > can be tested. > > Windows XP can run on a machine with ISA slot(s) and has built-in drivers for > some plug ISA cards - e.g. the famous 3Com EtherLink III. I think that > there's a driver for NE2000-compatible cards too and it probably works. The NE2K-driver went missing in W2K. BTDT. -- Anyone can speak Troll. All you have to do is point and grunt. -- Fred Weasley -- 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: sleep before boot panic
On Mon, 7 Jan 2008, Pavel Machek wrote: > > Introduce config CONFIG_SOFTPANIC > > Enabling this option changes a hard panic on boot errors to a > > soft panic, which does not stop the system completely. > > You can still scroll the screen and read the messages. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > Looks good to me... but should this be configurable? IMO we should > just do the right thing. Having it configurable doesn't cost much, and the embedded folks without a screen certainly don't need this code. -- Funny quotes: 23. If at first you don't succeed, destroy all evidence that you tried. -- 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: provide a DMI based port 0x80 I/O delay override.
On Mon, 7 Jan 2008, Alan Cox wrote: > > But overclocking is not the problem for udelay, it would err to the safe > > side. The problem would be a BUS having < 8 MHz, and since the days of > > 80286, they are hard to find. IMO having an option to set the bus speed > > for those systems should be enough. > > If you get it wrong you risk data corruption. Not good, not clever, not > appropriate. Basically the use of port 0x80 is the right thing to do for > ISA devices and as 15 odd years of use has shown works reliably and > solidly for ISA systems. As long as there is no port 80 card or a similar device using it. If there is a port 80 card, ISA acess needing the delay does break, cause the data corruption you fear and does cause this thread to be started. Pest, Cholera ... OTOH, maybe the 6-MHz-delay is the same as the 8-MHz-delay, and the kernel parameter is not needed. -- Fun things to slip into your budget A Romulan Cloaking device: The PHB won't know what it is but will be to chicken to ask -- 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: provide a DMI based port 0x80 I/O delay override.
On Tue, 8 Jan 2008, Rene Herman wrote: > On 08-01-08 00:24, H. Peter Anvin wrote: > > Rene Herman wrote: > > > Is this only about the ones then left for things like legacy PIC and PIT? > > > Does anyone care about just sticking in a udelay(2) (or 1) there as a > > > replacement and call it a day? > > > > > > > PIT is problematic because the PIT may be necessary for udelay setup. > > Yes, can initialise loops_per_jiffy conservatively. Just didn't quite get why > you guys are talking about an ISA bus speed parameter. If the ISA bus is below 8 MHz, we might need a longer delay. If we default to the longer delay, the delay will be too long for more than 99,99 % of all systems, not counting i586+. Especially if the driver is fine-tuned to give maximum throughput, this may be bad. OTOH, the DOS drivers I heared about use delays and would break on underclocked ISA busses if the n * ISA_HZ delay was needed. Maybe somebody having a configurable ISA bus speed and some problematic chips can test it ... -- Fun things to slip into your budget "I [Meow Cat] sliped in 'Legal fees for firing Jim (Jim's my [his] boss).' Jim approved the budget and was fired when upper management saw the budget." -- 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: provide a DMI based port 0x80 I/O delay override.
On Tue, 8 Jan 2008, Rene Herman wrote: On 08-01-08 00:24, H. Peter Anvin wrote: Rene Herman wrote: Is this only about the ones then left for things like legacy PIC and PIT? Does anyone care about just sticking in a udelay(2) (or 1) there as a replacement and call it a day? PIT is problematic because the PIT may be necessary for udelay setup. Yes, can initialise loops_per_jiffy conservatively. Just didn't quite get why you guys are talking about an ISA bus speed parameter. If the ISA bus is below 8 MHz, we might need a longer delay. If we default to the longer delay, the delay will be too long for more than 99,99 % of all systems, not counting i586+. Especially if the driver is fine-tuned to give maximum throughput, this may be bad. OTOH, the DOS drivers I heared about use delays and would break on underclocked ISA busses if the n * ISA_HZ delay was needed. Maybe somebody having a configurable ISA bus speed and some problematic chips can test it ... -- Fun things to slip into your budget I [Meow Cat] sliped in 'Legal fees for firing Jim (Jim's my [his] boss).' Jim approved the budget and was fired when upper management saw the budget. -- 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: provide a DMI based port 0x80 I/O delay override.
On Mon, 7 Jan 2008, Alan Cox wrote: But overclocking is not the problem for udelay, it would err to the safe side. The problem would be a BUS having 8 MHz, and since the days of 80286, they are hard to find. IMO having an option to set the bus speed for those systems should be enough. If you get it wrong you risk data corruption. Not good, not clever, not appropriate. Basically the use of port 0x80 is the right thing to do for ISA devices and as 15 odd years of use has shown works reliably and solidly for ISA systems. As long as there is no port 80 card or a similar device using it. If there is a port 80 card, ISA acess needing the delay does break, cause the data corruption you fear and does cause this thread to be started. Pest, Cholera ... OTOH, maybe the 6-MHz-delay is the same as the 8-MHz-delay, and the kernel parameter is not needed. -- Fun things to slip into your budget A Romulan Cloaking device: The PHB won't know what it is but will be to chicken to ask -- 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: sleep before boot panic
On Mon, 7 Jan 2008, Pavel Machek wrote: Introduce config CONFIG_SOFTPANIC Enabling this option changes a hard panic on boot errors to a soft panic, which does not stop the system completely. You can still scroll the screen and read the messages. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] Looks good to me... but should this be configurable? IMO we should just do the right thing. Having it configurable doesn't cost much, and the embedded folks without a screen certainly don't need this code. -- Funny quotes: 23. If at first you don't succeed, destroy all evidence that you tried. -- 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: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 8 Jan 2008, Ondrej Zary wrote: On Tuesday 08 January 2008 18:24:02 David P. Reed wrote: Windows these days does delays with timing loops or the scheduler. It doesn't use a port. Also, Windows XP only supports machines that tend not to have timing problems that use delays. Instead, if a device takes a while to respond, it has a busy bit in some port or memory slot that can be tested. Windows XP can run on a machine with ISA slot(s) and has built-in drivers for some plugplay ISA cards - e.g. the famous 3Com EtherLink III. I think that there's a driver for NE2000-compatible cards too and it probably works. The NE2K-driver went missing in W2K. BTDT. -- Anyone can speak Troll. All you have to do is point and grunt. -- Fred Weasley -- 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: The ext3 way of journalling
Tuomo Valkonen [EMAIL PROTECTED] wrote: On 2008-01-08, Jan Engelhardt [EMAIL PROTECTED] wrote: Power users may still use the index= option of sound card modules and wire it up in /etc/modprobe.d if they prefer. Another very cryptic directory whose contents say nothing to me. Configuration files should be self-documenting and editable, instead having to be created based on long documentation. The simple /etc/modules -- which at least Debian's stock kernels do not use -- qualifies, but few other files these days do. You can guess my answer: udev will fix it. And break everything else, such as my symlinks, permissions, etc. I'm not going to learn its cryptic special-case config files for such trivial tasks as creating a fucking symlink or change the permissions of a file, for which exist general purpose methods: chmod, chown, ln -s. Edit the start script, append your commands to create the links. Or edit the correct file in /etc/udev/rules.d to include the links. Well what do you expect of it? The kernel does not keep USB port - SCSI device mappings. Neither USB device - SCSI device mapping, because not all USB ports or USB devices are mass-storage devices. It just is not the kernel's job. Mapping everything to scsi nodes is brain damaged. The old hda, hdb, etc. mappings had somewhat clear correspondence between to physical evice addresses, and were easy to use without such complicated crap as udev. Of course, I'd prefer just device unique IDs being used, where possible... but I'm not going to suffer udev for that. If you wire your devices to a named/numbered port, you can use one device node for each port. Therefore it's sane to create hda to hdd, fd0 to fd3, etc. But if you don't have a fixed mapping (USB), or if you'd have too many possible (and mostly unused) ports for the available amount of devices (SCSI), you can not create fixed numbers. Even for hde ..., you have no native ordering, you can only tell the first controller from the rest. When the SCSI naming was created, there were at most 256 SCSI devices of each kind. Since each partition is a SCSI device, too, you had at most 16 disks of up to 15 partitions! This was later extended to 128 disks. If you'd hardcode the controller, linux would have been unable to support more than 8 SCSI controllers. The result was the semi-random enumeration of the SCSI devices, and all the hacks trying to work around that. (google for Joerg Schilling lkml) Udev provides a clean way of naming the devices, using the static information from the devices or the path. I agree that the current udev documentation makes it hard to even find the settings you'd like to change. That's because the documentation is meant for developers, while the configuration is themed by the distribution. The udev files itself are as simple as possible. Imagine them to be bloatXML/bloat, like the pile of HAL, DBUS and KDE automatically mounting my disks using the wrong settings into the wrong directory and forcing me to su in order to umount them! I temporarily beat that beast, but the kill is still on the TODO list. Maybe as soon as I find more^W usable^W documentation ... May I remind you that the kernel also loses all your network interface configuration, routes, firewalling rules and all sysctl settings at boot (sic: reboot powerdown). But traditional /dev does not lose permissions and symlinks. udev tmpfs shadow brain damage does. You have to illogically and inconveniently edit udev's cryptic config files instead, and yet it in no way stops /dev from being modified. You aren't stopped from directly poking the memory and crashing the systems either - if you are root. Or from deleting all nodes on a classic /dev. Don't do that then. Nonsense. The kernel notices udev about all available hardware and udev will load modules. It has nothing to do with initrd, in fact, this very step of loading a gazillion of modules is done after initrd has passed control on to /sbin/init. At least, in opensuse. I've never seen a system that would do so. And I won't use udev. No system can load modules that are not on initrd, and only needed-for-boot modules are usually put on the initrd. The bulk of modules must be loaded from the real root. This seems to work quite well (except not here because I prefer to include all necessary drivers in the kernel.) I've debugged hotplug, too, and I found it was a wrapper around a wrapper around ... a script that would be supposed to load the required firmware, except it did neither load it nor provide a way to find out why it didn't. Each HOWTO mentioned a different directory to use, and a different filename. I'd have settled for manually loading the firmware, but hacking the scripts to pieces was finally easier than finding out how I was supposed to do that. I did not need to install a firmware after this, therefore I don't know if udev is better, but it CAN'T be worse. -- To unsubscribe from this list: send
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Mon, 7 Jan 2008, H. Peter Anvin wrote: > Bodo Eggert wrote: > > But overclocking is not the problem for udelay, it would err to the safe > > side. The problem would be a BUS having < 8 MHz, and since the days of > > 80286, they are hard to find. IMO having an option to set the bus speed > > for those systems should be enough. > > > > There might have been a few 386/20's clocking the ISA bus at ÷3 > (6.67 MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz). Yes, and the remaining users should set the kernel option. Both of them. The question is: How will they be told about the new kernel option? -- A man inserted an advertisement in the classified: Wife Wanted." The next day he received a hundred letters. They all said the same thing: "You can have mine."
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Mon, 7 Jan 2008, H. Peter Anvin wrote: > Bodo Eggert wrote: > > Christer Weinigel <[EMAIL PROTECTED]> wrote: > > > How do you find out the speed of the ISA bus? AFAIK there is no > > > standardized way to do that. On the Geode SC2200 the ISA bus speed is > > > usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or > > > 30/4=7.5MHz, but with no external ISA devices it's possible to > > > overclock the ISA bus to /3 to run it at 11MHz or so. But without > > > poking at some CPU and southbridge specific registers to find out the > > > PCI bus speed and the ISA bus divisor you can't really tell. > > > > If you overclock, you are on your own. IIRC I've used 13,3 MHz for some time > > and used a lower PIO mode to compensate. > > > > > So if you do udelay based on a 6MHz clock (I think you can safely > > > assume that any 386 based system runs the ISA bus at least that fast) > > > you'll waste at least 30% and maybe even 100% more time for the delay > > > after every _p call. > > > > Defaulting to 8 MHz and offering an option to set another clock speed > > (like idebus=) should be OK. > > > > The formalization of the ISA bus which was part of the EISA specification > settled on 8.33 MHz maximum nominal frequency. There were, however, some > earlier designs which used up to 12 MHz nominal; I'm not sure if that applied > to 386s though. I've used up to 13,3 MHz on my 386DX40, but it was way out of spec and I had to use a lower PIO mode to compensate. IIRC, one of my cards forced me to settle for 10 MHz. Wikipedia claims there were systems having 16 MHz ISA bus, and systems underclocking themselves when accessing ISA. I remember having optional and mandatory waitstates, too, but I'm not 100 % sure it was on ISA. I think they were ... But overclocking is not the problem for udelay, it would err to the safe side. The problem would be a BUS having < 8 MHz, and since the days of 80286, they are hard to find. IMO having an option to set the bus speed for those systems should be enough. -- knghtbrd: AIX - the Unix from the universe where Spock has a beard. -- 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: provide a DMI based port 0x80 I/O delay override.
Christer Weinigel <[EMAIL PROTECTED]> wrote: > How do you find out the speed of the ISA bus? AFAIK there is no > standardized way to do that. On the Geode SC2200 the ISA bus speed is > usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or > 30/4=7.5MHz, but with no external ISA devices it's possible to > overclock the ISA bus to /3 to run it at 11MHz or so. But without > poking at some CPU and southbridge specific registers to find out the > PCI bus speed and the ISA bus divisor you can't really tell. If you overclock, you are on your own. IIRC I've used 13,3 MHz for some time and used a lower PIO mode to compensate. > So if you do udelay based on a 6MHz clock (I think you can safely > assume that any 386 based system runs the ISA bus at least that fast) > you'll waste at least 30% and maybe even 100% more time for the delay > after every _p call. Defaulting to 8 MHz and offering an option to set another clock speed (like idebus=) should be OK. -- 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: sleep before boot panic
Ingo Oeser <[EMAIL PROTECTED]> wrote:
> CC'ed hpa, since I'm sure he can give useful advise on that :-)
>
> On Sunday 06 January 2008, Bernd Schubert wrote:
>> On Sunday 06 January 2008, Ingo Oeser wrote:
>> > On Sunday 06 January 2008, you wrote:
>> > > Index: zd1211rw.git.beno/init/do_mounts.c
>> > > ===
>> > > --- zd1211rw.git.beno.orig/init/do_mounts.c 2008-01-06
>> > > 18:44:23.0
>> > > +0100
>> > > +++ zd1211rw.git.beno/init/do_mounts.c 2008-01-06 18:45:44.0
>> > > +0100 @@ -330,6 +330,7 @@
>> > > printk("Please append a correct \"root=\" boot option; here are the
>> > > available partitions:\n");
>> > >
>> > > printk_all_partitions();
>> > > +msleep(60 * 1000);
>> >
>> > ssleep(60);
>>
>> feel free to replace it replace it :)
>
> Not that urgent, but if you resubmit please do it :-)
You don't need to, because ...
>> There is no dump_stack() here, but disc detection is relatively early in boot
>> process and on all these information are already scrolled off screen when the
>> panic is done. For this and any other panic it would be optimal if scrolling
>> still would work, but scrolling also requires kernel code, so I see there's a
>> reason not to this for all panics. However, for this boot problem I tend to
>> say there's no need to panic at all...
>
> But the kernel cannot continue from that position. You would need a "soft"
> panic, which allows behavior of panic=X, but let the kernel continue.
Ingo is right, and I've done the work. The latest version is included below.
If it does not apply cleanly and there is a chance of including it, I'll
port the patch to any version you name.
> Even better is to continue with the init in the builtin ramfs. That should
> always be available and can implement any behavior desired (like droping into
> a dash).
ACK, but that's your part.
Introduce config CONFIG_SOFTPANIC
Enabling this option changes a hard panic on boot errors to a
soft panic, which does not stop the system completely.
You can still scroll the screen and read the messages.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -pruN linux-2.6.23.base/include/linux/kernel.h
linux-2.6.23.softpanic/include/linux/kernel.h
--- linux-2.6.23.base/include/linux/kernel.h2007-10-11 14:15:39.0
+0200
+++ linux-2.6.23.softpanic/include/linux/kernel.h 2007-10-11
14:45:15.0
+0200
@@ -108,6 +108,12 @@ extern struct atomic_notifier_head panic
extern long (*panic_blink)(long time);
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char * fmt, ...)
+ __attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#else
+# define softpanic(...) do { panic(__VA_ARGS__); } while (0)
+#endif
extern void oops_enter(void);
extern void oops_exit(void);
extern int oops_may_print(void);
diff -pruN linux-2.6.23.base/init/Kconfig linux-2.6.23.softpanic/init/Kconfig
--- linux-2.6.23.base/init/Kconfig 2007-10-11 14:15:42.0 +0200
+++ linux-2.6.23.softpanic/init/Kconfig 2007-10-11 15:19:07.0 +0200
@@ -441,6 +441,14 @@ config BUG
option for embedded systems with no facilities for reporting errors.
Just say Y.
+config SOFTPANIC
+ bool "Enable softpanic for boot errors" if EMBEDDED
+ default y
+ help
+ Enabling this option changes a hard panic on boot errors to a
+ soft panic, which does not stop the system completely.
+ You can still scroll the screen and read the messages.
+
config ELF_CORE
default y
bool "Enable ELF core dumps" if EMBEDDED
diff -pruN linux-2.6.23.base/init/do_mounts.c
linux-2.6.23.softpanic/init/do_mounts.c
--- linux-2.6.23.base/init/do_mounts.c 2007-10-11 14:15:42.0 +0200
+++ linux-2.6.23.softpanic/init/do_mounts.c 2007-10-11 14:48:51.0
+0200
@@ -330,7 +330,7 @@ retry:
printk("Please append a correct \"root=\" boot option; here are
the available
partitions:\n");
printk_all_partitions();
- panic("VFS: Unable to mount root fs on %s", b);
+ softpanic("VFS: Unable to mount root fs on %s", b);
}
printk("List of all partitions:\n");
@@ -342,7 +342,7 @@ retry:
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
- panic("VFS: Unable to mount root fs on %s", b);
+ softpanic("VFS: Unable to mount root fs on %s", b);
out:
put
Re: sleep before boot panic
Ingo Oeser [EMAIL PROTECTED] wrote:
CC'ed hpa, since I'm sure he can give useful advise on that :-)
On Sunday 06 January 2008, Bernd Schubert wrote:
On Sunday 06 January 2008, Ingo Oeser wrote:
On Sunday 06 January 2008, you wrote:
Index: zd1211rw.git.beno/init/do_mounts.c
===
--- zd1211rw.git.beno.orig/init/do_mounts.c 2008-01-06
18:44:23.0
+0100
+++ zd1211rw.git.beno/init/do_mounts.c 2008-01-06 18:45:44.0
+0100 @@ -330,6 +330,7 @@
printk(Please append a correct \root=\ boot option; here are the
available partitions:\n);
printk_all_partitions();
+msleep(60 * 1000);
ssleep(60);
feel free to replace it replace it :)
Not that urgent, but if you resubmit please do it :-)
You don't need to, because ...
There is no dump_stack() here, but disc detection is relatively early in boot
process and on all these information are already scrolled off screen when the
panic is done. For this and any other panic it would be optimal if scrolling
still would work, but scrolling also requires kernel code, so I see there's a
reason not to this for all panics. However, for this boot problem I tend to
say there's no need to panic at all...
But the kernel cannot continue from that position. You would need a soft
panic, which allows behavior of panic=X, but let the kernel continue.
Ingo is right, and I've done the work. The latest version is included below.
If it does not apply cleanly and there is a chance of including it, I'll
port the patch to any version you name.
Even better is to continue with the init in the builtin ramfs. That should
always be available and can implement any behavior desired (like droping into
a dash).
ACK, but that's your part.
snip
Introduce config CONFIG_SOFTPANIC
Enabling this option changes a hard panic on boot errors to a
soft panic, which does not stop the system completely.
You can still scroll the screen and read the messages.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
diff -pruN linux-2.6.23.base/include/linux/kernel.h
linux-2.6.23.softpanic/include/linux/kernel.h
--- linux-2.6.23.base/include/linux/kernel.h2007-10-11 14:15:39.0
+0200
+++ linux-2.6.23.softpanic/include/linux/kernel.h 2007-10-11
14:45:15.0
+0200
@@ -108,6 +108,12 @@ extern struct atomic_notifier_head panic
extern long (*panic_blink)(long time);
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#ifdef SOFTPANIC
+NORET_TYPE void softpanic(const char * fmt, ...)
+ __attribute__ ((NORET_AND format (printf, 1, 2))) __cold;
+#else
+# define softpanic(...) do { panic(__VA_ARGS__); } while (0)
+#endif
extern void oops_enter(void);
extern void oops_exit(void);
extern int oops_may_print(void);
diff -pruN linux-2.6.23.base/init/Kconfig linux-2.6.23.softpanic/init/Kconfig
--- linux-2.6.23.base/init/Kconfig 2007-10-11 14:15:42.0 +0200
+++ linux-2.6.23.softpanic/init/Kconfig 2007-10-11 15:19:07.0 +0200
@@ -441,6 +441,14 @@ config BUG
option for embedded systems with no facilities for reporting errors.
Just say Y.
+config SOFTPANIC
+ bool Enable softpanic for boot errors if EMBEDDED
+ default y
+ help
+ Enabling this option changes a hard panic on boot errors to a
+ soft panic, which does not stop the system completely.
+ You can still scroll the screen and read the messages.
+
config ELF_CORE
default y
bool Enable ELF core dumps if EMBEDDED
diff -pruN linux-2.6.23.base/init/do_mounts.c
linux-2.6.23.softpanic/init/do_mounts.c
--- linux-2.6.23.base/init/do_mounts.c 2007-10-11 14:15:42.0 +0200
+++ linux-2.6.23.softpanic/init/do_mounts.c 2007-10-11 14:48:51.0
+0200
@@ -330,7 +330,7 @@ retry:
printk(Please append a correct \root=\ boot option; here are
the available
partitions:\n);
printk_all_partitions();
- panic(VFS: Unable to mount root fs on %s, b);
+ softpanic(VFS: Unable to mount root fs on %s, b);
}
printk(List of all partitions:\n);
@@ -342,7 +342,7 @@ retry:
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
- panic(VFS: Unable to mount root fs on %s, b);
+ softpanic(VFS: Unable to mount root fs on %s, b);
out:
putname(fs_names);
}
diff -pruN linux-2.6.23.base/init/main.c linux-2.6.23.softpanic/init/main.c
--- linux-2.6.23.base/init/main.c 2007-10-11 14:15:42.0 +0200
+++ linux-2.6.23.softpanic/init/main.c 2007-10-11 14:40:06.0 +0200
@@ -590,7 +590,7 @@ asmlinkage void __init start_kernel(void
*/
console_init();
if (panic_later)
- panic(panic_later, panic_param);
+ softpanic(panic_later, panic_param);
lockdep_info
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
Christer Weinigel [EMAIL PROTECTED] wrote: How do you find out the speed of the ISA bus? AFAIK there is no standardized way to do that. On the Geode SC2200 the ISA bus speed is usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or 30/4=7.5MHz, but with no external ISA devices it's possible to overclock the ISA bus to /3 to run it at 11MHz or so. But without poking at some CPU and southbridge specific registers to find out the PCI bus speed and the ISA bus divisor you can't really tell. If you overclock, you are on your own. IIRC I've used 13,3 MHz for some time and used a lower PIO mode to compensate. So if you do udelay based on a 6MHz clock (I think you can safely assume that any 386 based system runs the ISA bus at least that fast) you'll waste at least 30% and maybe even 100% more time for the delay after every _p call. Defaulting to 8 MHz and offering an option to set another clock speed (like idebus=) should be OK. -- 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: provide a DMI based port 0x80 I/O delay override.
On Mon, 7 Jan 2008, H. Peter Anvin wrote: Bodo Eggert wrote: Christer Weinigel [EMAIL PROTECTED] wrote: How do you find out the speed of the ISA bus? AFAIK there is no standardized way to do that. On the Geode SC2200 the ISA bus speed is usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or 30/4=7.5MHz, but with no external ISA devices it's possible to overclock the ISA bus to /3 to run it at 11MHz or so. But without poking at some CPU and southbridge specific registers to find out the PCI bus speed and the ISA bus divisor you can't really tell. If you overclock, you are on your own. IIRC I've used 13,3 MHz for some time and used a lower PIO mode to compensate. So if you do udelay based on a 6MHz clock (I think you can safely assume that any 386 based system runs the ISA bus at least that fast) you'll waste at least 30% and maybe even 100% more time for the delay after every _p call. Defaulting to 8 MHz and offering an option to set another clock speed (like idebus=) should be OK. The formalization of the ISA bus which was part of the EISA specification settled on 8.33 MHz maximum nominal frequency. There were, however, some earlier designs which used up to 12 MHz nominal; I'm not sure if that applied to 386s though. I've used up to 13,3 MHz on my 386DX40, but it was way out of spec and I had to use a lower PIO mode to compensate. IIRC, one of my cards forced me to settle for 10 MHz. Wikipedia claims there were systems having 16 MHz ISA bus, and systems underclocking themselves when accessing ISA. I remember having optional and mandatory waitstates, too, but I'm not 100 % sure it was on ISA. I think they were ... But overclocking is not the problem for udelay, it would err to the safe side. The problem would be a BUS having 8 MHz, and since the days of 80286, they are hard to find. IMO having an option to set the bus speed for those systems should be enough. -- knghtbrd:JHM AIX - the Unix from the universe where Spock has a beard. -- 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: provide a DMI based port 0x80 I/O delay override.
On Mon, 7 Jan 2008, H. Peter Anvin wrote: Bodo Eggert wrote: But overclocking is not the problem for udelay, it would err to the safe side. The problem would be a BUS having 8 MHz, and since the days of 80286, they are hard to find. IMO having an option to set the bus speed for those systems should be enough. There might have been a few 386/20's clocking the ISA bus at ÷3 (6.67 MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz). Yes, and the remaining users should set the kernel option. Both of them. The question is: How will they be told about the new kernel option? -- A man inserted an advertisement in the classified: Wife Wanted. The next day he received a hundred letters. They all said the same thing: You can have mine.
Re: RAID timeout parameter accessibility request
Thanasis <[EMAIL PROTECTED]> wrote: > on 12/31/2007 11:54 AM Jose de la Mancha wrote the following: >> --> All RAID edition drives are more expensive that their equivalent >> "desktop edition" drives (same model on "desktop edition"). Just take a look >> at newegg for instance. >> >http://www.newegg.com/Product/Product.aspx?Item=N82E16822136055=WD%2b2500YS Not available here, and my local store offers a 250 GB drive for 7 % less. -- 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] Force UNIX domain sockets to be built in
On Wed, 2 Jan 2008, Herbert Xu wrote: > Theodore Tso <[EMAIL PROTECTED]> wrote: > > The question is whether the size of the Unix domain sockets support is > > worth the complexity of yet another config option that we expose to > > the user. For the embedded world, OK, maybe they want to save 14k of > > non-swappable memory. But for the non-embedded world, given the 117k > > mandatory memory usage of sysfs, or the 124k memory usage of the core > > networking stack, never mind the 3 megabytes of memory used by objects > > in the kernel subdirectory, it's not clear that it's worth worrying > > over 14k of memory, especially when many Unix programs assume > > that Unix Domain Sockets are present. > > That would make sense if we were proposing to get rid of the CONFIG_UNIX > question altogether for !CONFIG_EMBEDDED. Exactly this is what my patch does: The question is not to be displayed unless EMBEDDED, and the default is changed to y. > However, the proposal here is > merely to eliminate the modular option but the CONFIG_UNIX prompt itself > will remain even without CONFIG_EMBEDDED. > > This I think is quite pointless. That's what another patch would do. I decided that s/tristate/bool/ is something completely different from adding the default and hiding the option, and that I'd avoid this discussion by not eliminating UNIX=m. -- Top 100 things you don't want the sysadmin to say: 96. That's SO bizarre. -- 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: macro _set_base - "do - while(0)" question
Abdel <[EMAIL PROTECTED]> wrote: > In file include/asm-i386/system.h, _set_base and _set_limit use an > useless do ... while(0) > > Why is this needed ? http://kernelnewbies.org/FAQ/DoWhile0 -- 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: macro _set_base - do - while(0) question
Abdel [EMAIL PROTECTED] wrote: In file include/asm-i386/system.h, _set_base and _set_limit use an useless do ... while(0) Why is this needed ? http://kernelnewbies.org/FAQ/DoWhile0 -- 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] Force UNIX domain sockets to be built in
On Wed, 2 Jan 2008, Herbert Xu wrote: Theodore Tso [EMAIL PROTECTED] wrote: The question is whether the size of the Unix domain sockets support is worth the complexity of yet another config option that we expose to the user. For the embedded world, OK, maybe they want to save 14k of non-swappable memory. But for the non-embedded world, given the 117k mandatory memory usage of sysfs, or the 124k memory usage of the core networking stack, never mind the 3 megabytes of memory used by objects in the kernel subdirectory, it's not clear that it's worth worrying over 14k of memory, especially when many Unix programs assume that Unix Domain Sockets are present. That would make sense if we were proposing to get rid of the CONFIG_UNIX question altogether for !CONFIG_EMBEDDED. Exactly this is what my patch does: The question is not to be displayed unless EMBEDDED, and the default is changed to y. However, the proposal here is merely to eliminate the modular option but the CONFIG_UNIX prompt itself will remain even without CONFIG_EMBEDDED. This I think is quite pointless. That's what another patch would do. I decided that s/tristate/bool/ is something completely different from adding the default and hiding the option, and that I'd avoid this discussion by not eliminating UNIX=m. -- Top 100 things you don't want the sysadmin to say: 96. That's SO bizarre. -- 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: RAID timeout parameter accessibility request
Thanasis [EMAIL PROTECTED] wrote: on 12/31/2007 11:54 AM Jose de la Mancha wrote the following: -- All RAID edition drives are more expensive that their equivalent desktop edition drives (same model on desktop edition). Just take a look at newegg for instance. http://www.newegg.com/Product/Product.aspx?Item=N82E16822136055Tpk=WD%2b2500YS Not available here, and my local store offers a 250 GB drive for 7 % less. -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, David Miller wrote: > From: Bodo Eggert <[EMAIL PROTECTED]> > > The big question is: Is there any non-embedded system where you have > > to aim for a small kernel image? > > One some platforms, due to bootloader restrictions or whatever, > there are hard limits on how large the main kernel image can be. > > On sparc64 for example the limit is around 6.5MB That would be about the size of a complete rescue system. I don't think we need to worry about unix sockets there, do we? > But this "big question" isn't the important issue, in fact it's > tangental and has no bearing on the final decision we make > here. > > Rather, choice is, and taking choice away is bad. I may have a reason > to make AF_UNIX modular, I might not, but either way taking that > option away from me is not the right thing to do. _You_'ll still have the option, because you have selected EMBEDDED=y (otherwise, you'd miss all other valuable options to cripple your kernel), while the folks that just care for a working systems will have what they'd select anyway without being bothered with useless questions. -- Top 100 things you don't want the sysadmin to say: 5. Just add yourself to the password file and make a directory... -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Al Viro wrote: > On Mon, Dec 31, 2007 at 03:03:20PM +0100, Bodo Eggert wrote: > > On Mon, 31 Dec 2007, David Miller wrote: > > > From: Bodo Eggert <[EMAIL PROTECTED]> > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built > > > > in > > > > on normal systems. This is especially true since udev needs these > > > > sockets > > > > and fails to run if UNIX=m. > > > > > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > > > People who use udev can make sure they have it built into their kernel > > > if they have such a dependency. > > > > > > Not everyone uses udev, and therefore needs AF_UNIX non-modular. > > > > That's why I kept this option for embedded folks. > > > > Is there any benefit for non-embedded systems from having UNIX=m? > > udev-free != embedded. But UNIX=m == waste RAM and have an effectively b0rken system until the module is loaded. It would be silly to do this unless you have a very small space for the kernel image and some free space for storing the needed modules. The big question is: Is there any non-embedded system where you have to aim for a small kernel image? -- Fun things to slip into your budget Half a million dollars for consultants to design a web site that was being done by an intern in his spare time. -- 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: Bad escriptions in Kconfig
On Mon, 31 Dec 2007, Douglas Gilbert wrote: > Matthew Wilcox wrote: > > On Mon, Dec 31, 2007 at 10:16:43AM -0500, Douglas Gilbert wrote: > >> Bodo Eggert wrote: (Kicking netdev from CC) > >>> --- > >>> SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? > >>> > >>> If you want to use SCSI target mode drivers enable this option. > >>> If you choose M, the module will be called scsi_tgt. > >>> --- > >>> > >>> What TF is a SCSI target mode, what is a target mode driver? > >> Heard of google :-) > >> > >> For explanations of SCSI (and other storage) terminology > >> reference could be made to SAM-3 or SAM-4 drafts (because > >> the real standards cost money) at www.t10.org . > >> > >> Perhaps many other subsections in the kernel could have > >> similar references. > > > > I think that's an appalling idea. Someone's trying to configure their > > kernel, not research hundreds of new ideas on the internet. Here's a > > better description: > > > > help > > The SCSI target code allows your computer to appear as a SCSI > > device. This is useful in a SAN or NAS environment where you > > want other computers to be able to treat this computer as a disc. > > > > To compile this driver as a module, choose M here: the module > > will be called scsi_tgt. > > Appalling or not, it is more accurate to define a SCSI target > properly than equate it to a direct access logical unit (i.e. > a disk). Yes, but calling the current text a "help text" would be even less accurate. Can you create a helpfull text without being incorrect? -- Field experience is something you don't get until just after you need it. -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Adrian Bunk wrote: > On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote: > > On Mon, 31 Dec 2007, Adrian Bunk wrote: > > > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built > > > > in > > > > on normal systems. This is especially true since udev needs these > > > > sockets > > > > and fails to run if UNIX=m. > > > > > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > > > > > --- > > > > Last minute change: I decided against making it a bool because embedded > > > > folks might depend on a small kernel image. Edited in the patch below. > > > >... > > > > > > Is this just a purely theoretical thought or is this a reasonable use > > > case people actually use in practice? > > > > For now, it's a theoretical thought, but having an embedded device, I can > > see the reason for $EVERYTHING=m there. > > The only advantage I see is that the kernel image you have to flash > can be made smaller - with the disadvantage that the running kernel > is bigger by more than 10%. > > If you don't believe me, try it yourself: > Build all drivers statically into your kernel, and then compare the > vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. If you'd aim for a small kernel image, you would build anything as a module that is not requred for booting. > > > After all, changing it to a bool will allow us to make the kernel image > > > for nearly everyone smaller by a few hundred bytes... > > > > I can't see why optionally building it as a module would force us to make > > the kernel bigger. It may be a little more ugly to support =m, but thats it, > > isn't it? > > On architectures like x86 where __exit code is freed at runtime > af_unix_exit() makes your kernel image (but not the running kernel) > bigger. > > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes > of memory. #define m='m' #if CONIG_UNIX=='m' #define EXPORT_SYMBOL_AF_UNIX EXPORT_SYMBOL #else #define EXPORT_SYMBOL_AF_UNIX() #endif #undef m You could also use "#if defined(C_U) && (C_U == m)". -- Funny quotes: 36. You never really learn to swear until you learn to drive. -- 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: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007, Alan Cox wrote: > On Sun, 30 Dec 2007 12:53:02 -0800 > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > > Bodo Eggert wrote: > > > I've never seen code which would do that, and it was not suggested by any > > > tutorial I ever saw. I'd expect any machine to break on all kinds of > > > software > > > if it required this. The only thing I remember being warned about is > > > writing > > > the index and the data register at the same time using outw, because that > > > would write both registers at the same time on 16-bit-cards. > > > > > > > And we use that, and have been for 15 years. I haven't seen any screams > > of pain about it. > > Actually there were, and I sent numerous people patches for that back in > ISA days. Are you talking about VGA cards requiring a delay between outb index/outb data, VGA cards barfing on outw or systems barfing on outb(0x80,42)? -- Programming is an art form that fights back. -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, David Miller wrote: > From: Bodo Eggert <[EMAIL PROTECTED]> > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > > on normal systems. This is especially true since udev needs these sockets > > and fails to run if UNIX=m. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > People who use udev can make sure they have it built into their kernel > if they have such a dependency. > > Not everyone uses udev, and therefore needs AF_UNIX non-modular. That's why I kept this option for embedded folks. Is there any benefit for non-embedded systems from having UNIX=m? -- Top 100 things you don't want the sysadmin to say: 89. I got a better job at Lockheed... -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Adrian Bunk wrote: > On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: > > As suggested by Adrian Bunk, UNIX domain sockets should always be built in > > on normal systems. This is especially true since udev needs these sockets > > and fails to run if UNIX=m. > > > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > > > > --- > > Last minute change: I decided against making it a bool because embedded > > folks might depend on a small kernel image. Edited in the patch below. > >... > > Is this just a purely theoretical thought or is this a reasonable use > case people actually use in practice? For now, it's a theoretical thought, but having an embedded device, I can see the reason for $EVERYTHING=m there. > After all, changing it to a bool will allow us to make the kernel image > for nearly everyone smaller by a few hundred bytes... I can't see why optionally building it as a module would force us to make the kernel bigger. It may be a little more ugly to support =m, but thats it, isn't it? -- Logic: The art of being wrong with confidence... -- 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/
Bad escriptions in Kconfig
In some of the Kconfig files, the options are not adequately decribed. I collected a few of the bad descriptions I found: --- Lowlevel video output switch controls (VIDEO_OUTPUT_CONTROL) [M/n/y/?] (NEW) ? This framework adds support for low-level control of the video output switch. --- - What is THE video output switch and why would I need low level control? - Frameworks should be auto-selected like libraries, shouldn't they? - WTF is this a module? - --- Auxiliary Display support (AUXDISPLAY) [N/y/?] (NEW) ? Say Y here to get to see options for auxiliary display drivers. This option alone does not add any kernel code. --- - If I knw what an axilary display was, I would not read this help text! - After digging some time, I discovered that all Auxdisplays are parallel port devices. Rename to "Parallel port display device support"? - --- Transformation user configuration interface (XFRM_USER) [N/m/y/?] (NEW) Support for Transformation(XFRM) user configuration interface like IPsec used by native Linux tools. If unsure, say Y. --- - I'm not sure if these words combine to a sentence. - I can't tell if IPSEC is the only user or if I'd break other parts by not saying 'Y'. OTOH, I don't want to bloat my kernel ... - What's a native linux tool? - --- SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? If you want to use SCSI target mode drivers enable this option. If you choose M, the module will be called scsi_tgt. --- What TF is a SCSI target mode, what is a target mode driver? -- I'm a member of DNA (National Assocciation of Dyslexics). -- Storm in <[EMAIL PROTECTED]> -- 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/
[PATCH] Force UNIX domain sockets to be built in
As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> --- Last minute change: I decided against making it a bool because embedded folks might depend on a small kernel image. Edited in the patch below. diff -X dontdiff -pruN linux-2.6.23.base/net/unix/Kconfig linux-2.6.23.socket-y/net/unix/Kconfig --- linux-2.6.23.base/net/unix/Kconfig 2006-11-29 22:57:37.0 +0100 +++ linux-2.6.23.socket-y/net/unix/Kconfig 2007-12-31 12:57:44.0 +0100 @@ -3,7 +3,8 @@ # config UNIX - tristate "Unix domain sockets" + tristate "Unix domain sockets" if EMBEDDED + default y ---help--- If you say Y here, you will include support for Unix domain sockets; sockets are the standard Unix mechanism for establishing and -- A. Top posters Q. What's the most annoying thing on Usenet? -- 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: Get physical MAC address
Theewara Vorakosit <[EMAIL PROTECTED]> wrote: > I get MAC address from ioctl. However, ifconfig can change this MAC > address. Can I get a real physical MAC address of the NIC? First, get a network card having a physical MAC. Most cards have only a (currently configured) default MAC address, maybe you'll be lucky with some old ISA cards ... Then, don't worry about sb changing it, since these cards don't support that. -- 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: Get physical MAC address
Theewara Vorakosit [EMAIL PROTECTED] wrote: I get MAC address from ioctl. However, ifconfig can change this MAC address. Can I get a real physical MAC address of the NIC? First, get a network card having a physical MAC. Most cards have only a (currently configured) default MAC address, maybe you'll be lucky with some old ISA cards ... Then, don't worry about sb changing it, since these cards don't support that. -- 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/
[PATCH] Force UNIX domain sockets to be built in
As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] --- Last minute change: I decided against making it a bool because embedded folks might depend on a small kernel image. Edited in the patch below. diff -X dontdiff -pruN linux-2.6.23.base/net/unix/Kconfig linux-2.6.23.socket-y/net/unix/Kconfig --- linux-2.6.23.base/net/unix/Kconfig 2006-11-29 22:57:37.0 +0100 +++ linux-2.6.23.socket-y/net/unix/Kconfig 2007-12-31 12:57:44.0 +0100 @@ -3,7 +3,8 @@ # config UNIX - tristate Unix domain sockets + tristate Unix domain sockets if EMBEDDED + default y ---help--- If you say Y here, you will include support for Unix domain sockets; sockets are the standard Unix mechanism for establishing and -- A. Top posters Q. What's the most annoying thing on Usenet? -- 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/
Bad escriptions in Kconfig
In some of the Kconfig files, the options are not adequately decribed. I collected a few of the bad descriptions I found: --- Lowlevel video output switch controls (VIDEO_OUTPUT_CONTROL) [M/n/y/?] (NEW) ? This framework adds support for low-level control of the video output switch. --- - What is THE video output switch and why would I need low level control? - Frameworks should be auto-selected like libraries, shouldn't they? - WTF is this a module? - --- Auxiliary Display support (AUXDISPLAY) [N/y/?] (NEW) ? Say Y here to get to see options for auxiliary display drivers. This option alone does not add any kernel code. --- - If I knw what an axilary display was, I would not read this help text! - After digging some time, I discovered that all Auxdisplays are parallel port devices. Rename to Parallel port display device support? - --- Transformation user configuration interface (XFRM_USER) [N/m/y/?] (NEW) Support for Transformation(XFRM) user configuration interface like IPsec used by native Linux tools. If unsure, say Y. --- - I'm not sure if these words combine to a sentence. - I can't tell if IPSEC is the only user or if I'd break other parts by not saying 'Y'. OTOH, I don't want to bloat my kernel ... - What's a native linux tool? - --- SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? If you want to use SCSI target mode drivers enable this option. If you choose M, the module will be called scsi_tgt. --- What TF is a SCSI target mode, what is a target mode driver? -- I'm a member of DNA (National Assocciation of Dyslexics). -- Storm in [EMAIL PROTECTED] -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Adrian Bunk wrote: On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] --- Last minute change: I decided against making it a bool because embedded folks might depend on a small kernel image. Edited in the patch below. ... Is this just a purely theoretical thought or is this a reasonable use case people actually use in practice? For now, it's a theoretical thought, but having an embedded device, I can see the reason for $EVERYTHING=m there. After all, changing it to a bool will allow us to make the kernel image for nearly everyone smaller by a few hundred bytes... I can't see why optionally building it as a module would force us to make the kernel bigger. It may be a little more ugly to support =m, but thats it, isn't it? -- Logic: The art of being wrong with confidence... -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, David Miller wrote: From: Bodo Eggert [EMAIL PROTECTED] As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] People who use udev can make sure they have it built into their kernel if they have such a dependency. Not everyone uses udev, and therefore needs AF_UNIX non-modular. That's why I kept this option for embedded folks. Is there any benefit for non-embedded systems from having UNIX=m? -- Top 100 things you don't want the sysadmin to say: 89. I got a better job at Lockheed... -- 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: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007, Alan Cox wrote: On Sun, 30 Dec 2007 12:53:02 -0800 H. Peter Anvin [EMAIL PROTECTED] wrote: Bodo Eggert wrote: I've never seen code which would do that, and it was not suggested by any tutorial I ever saw. I'd expect any machine to break on all kinds of software if it required this. The only thing I remember being warned about is writing the index and the data register at the same time using outw, because that would write both registers at the same time on 16-bit-cards. And we use that, and have been for 15 years. I haven't seen any screams of pain about it. Actually there were, and I sent numerous people patches for that back in ISA days. Are you talking about VGA cards requiring a delay between outb index/outb data, VGA cards barfing on outw or systems barfing on outb(0x80,42)? -- Programming is an art form that fights back. -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Adrian Bunk wrote: On Mon, Dec 31, 2007 at 02:26:42PM +0100, Bodo Eggert wrote: On Mon, 31 Dec 2007, Adrian Bunk wrote: On Mon, Dec 31, 2007 at 01:09:43PM +0100, Bodo Eggert wrote: As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] --- Last minute change: I decided against making it a bool because embedded folks might depend on a small kernel image. Edited in the patch below. ... Is this just a purely theoretical thought or is this a reasonable use case people actually use in practice? For now, it's a theoretical thought, but having an embedded device, I can see the reason for $EVERYTHING=m there. The only advantage I see is that the kernel image you have to flash can be made smaller - with the disadvantage that the running kernel is bigger by more than 10%. If you don't believe me, try it yourself: Build all drivers statically into your kernel, and then compare the vmlinux sizes with CONFIG_MODULES=n and CONFIG_MODULES=y. If you'd aim for a small kernel image, you would build anything as a module that is not requred for booting. After all, changing it to a bool will allow us to make the kernel image for nearly everyone smaller by a few hundred bytes... I can't see why optionally building it as a module would force us to make the kernel bigger. It may be a little more ugly to support =m, but thats it, isn't it? On architectures like x86 where __exit code is freed at runtime af_unix_exit() makes your kernel image (but not the running kernel) bigger. With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the theoretical possibility of CONIG_UNIX=m waste a few hundred bytes of memory. #define m='m' #if CONIG_UNIX=='m' #define EXPORT_SYMBOL_AF_UNIX EXPORT_SYMBOL #else #define EXPORT_SYMBOL_AF_UNIX() #endif #undef m You could also use #if defined(C_U) (C_U == m). -- Funny quotes: 36. You never really learn to swear until you learn to drive. -- 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: Bad escriptions in Kconfig
On Mon, 31 Dec 2007, Douglas Gilbert wrote: Matthew Wilcox wrote: On Mon, Dec 31, 2007 at 10:16:43AM -0500, Douglas Gilbert wrote: Bodo Eggert wrote: (Kicking netdev from CC) --- SCSI target support (SCSI_TGT) [N/m/y/?] (NEW) ? If you want to use SCSI target mode drivers enable this option. If you choose M, the module will be called scsi_tgt. --- What TF is a SCSI target mode, what is a target mode driver? Heard of google :-) For explanations of SCSI (and other storage) terminology reference could be made to SAM-3 or SAM-4 drafts (because the real standards cost money) at www.t10.org . Perhaps many other subsections in the kernel could have similar references. I think that's an appalling idea. Someone's trying to configure their kernel, not research hundreds of new ideas on the internet. Here's a better description: help The SCSI target code allows your computer to appear as a SCSI device. This is useful in a SAN or NAS environment where you want other computers to be able to treat this computer as a disc. To compile this driver as a module, choose M here: the module will be called scsi_tgt. Appalling or not, it is more accurate to define a SCSI target properly than equate it to a direct access logical unit (i.e. a disk). Yes, but calling the current text a help text would be even less accurate. Can you create a helpfull text without being incorrect? -- Field experience is something you don't get until just after you need it. -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, Al Viro wrote: On Mon, Dec 31, 2007 at 03:03:20PM +0100, Bodo Eggert wrote: On Mon, 31 Dec 2007, David Miller wrote: From: Bodo Eggert [EMAIL PROTECTED] As suggested by Adrian Bunk, UNIX domain sockets should always be built in on normal systems. This is especially true since udev needs these sockets and fails to run if UNIX=m. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] People who use udev can make sure they have it built into their kernel if they have such a dependency. Not everyone uses udev, and therefore needs AF_UNIX non-modular. That's why I kept this option for embedded folks. Is there any benefit for non-embedded systems from having UNIX=m? udev-free != embedded. But UNIX=m == waste RAM and have an effectively b0rken system until the module is loaded. It would be silly to do this unless you have a very small space for the kernel image and some free space for storing the needed modules. The big question is: Is there any non-embedded system where you have to aim for a small kernel image? -- Fun things to slip into your budget Half a million dollars for consultants to design a web site that was being done by an intern in his spare time. -- 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] Force UNIX domain sockets to be built in
On Mon, 31 Dec 2007, David Miller wrote: From: Bodo Eggert [EMAIL PROTECTED] The big question is: Is there any non-embedded system where you have to aim for a small kernel image? One some platforms, due to bootloader restrictions or whatever, there are hard limits on how large the main kernel image can be. On sparc64 for example the limit is around 6.5MB That would be about the size of a complete rescue system. I don't think we need to worry about unix sockets there, do we? But this big question isn't the important issue, in fact it's tangental and has no bearing on the final decision we make here. Rather, choice is, and taking choice away is bad. I may have a reason to make AF_UNIX modular, I might not, but either way taking that option away from me is not the right thing to do. _You_'ll still have the option, because you have selected EMBEDDED=y (otherwise, you'd miss all other valuable options to cripple your kernel), while the folks that just care for a working systems will have what they'd select anyway without being bothered with useless questions. -- Top 100 things you don't want the sysadmin to say: 5. Just add yourself to the password file and make a directory... -- 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: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Ingo Molnar wrote:
> >> * Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >>> BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c
> >>> uses while(1) without cpu_relax() in order to halt the machine. Is this
> >>> fixed? Should it be fixed?
> >>
> >> this is early bootup so there's no need to be "nice" to other cores or
> >> sockets - none of them are really running.
> >>
> >
> > It probably should actually HLT, to avoid sucking power, and stressing
> > the thermal system. We're dead at this point, and the early 486's
> > which had problems with HLT will lock up - we don't care.
>
> ok. Like the patch below?
>
> - while(1); /* Halt */
> + asm("cli; hlt");/* Halt */
The other users would loop around the hlt. Cargo Cult?
--
Top 100 things you don't want the sysadmin to say:
97. Go get your backup tape. (You _do_ have a backup tape?)
--
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: provide a DMI based port 0x80 I/O delay override
Ingo Molnar <[EMAIL PROTECTED]> wrote: > do you have any memories about the outb_p() use of misc_32.c: > > pos = (x + cols * y) * 2; /* Update cursor position */ > outb_p(14, vidport); > outb_p(0xff & (pos >> 9), vidport+1); > outb_p(15, vidport); > outb_p(0xff & (pos >> 1), vidport+1); > > was this ever needed? This is so early in the bootup that can we cannot > do any sensible delay. Perhaps we could try a natural delay sequence via > inb from 0x3cc: > > outb(14, vidport); > inb(0x3cc); /* delay */ > outb(0xff & (pos >> 9), vidport+1); I've never seen code which would do that, and it was not suggested by any tutorial I ever saw. I'd expect any machine to break on all kinds of software if it required this. The only thing I remember being warned about is writing the index and the data register at the same time using outw, because that would write both registers at the same time on 16-bit-cards. BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c uses while(1) without cpu_relax() in order to halt the machine. Is this fixed? Should it be fixed? -- 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/
[PATCH] Get NUMLOCK from PC BIOS
This patch enables reading the default NUMLOCK status from the BIOS data
area as defined for IBM PCs (1981). Using this area has been a reliable way
to detect (or set) the NUMLOCK status for about 27 years, and it will
continue to work on any IBM-compatible system that might run DOS.
Especially, the NUMLOCK status on Linus' famous laptop should be usable.
---
I'd like some information about how this patch works non non-IBM-compatible
x86 PCs. For now, I've documented the wordt possible outcome I can imagine.
Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>
diff -pruN -X dontdiff linux-2.6.23.pure/drivers/char/keyboard.c
linux-2.6.23.base/drivers/char/keyboard.c
--- linux-2.6.23.pure/drivers/char/keyboard.c 2007-10-11 14:15:18.0
+0200
+++ linux-2.6.23.base/drivers/char/keyboard.c 2007-12-30 12:12:11.0
+0100
@@ -24,6 +24,7 @@
* 21-08-02: Converted to input API, major cleanup. (Vojtech Pavlik)
*/
+#include
#include
#include
#include
@@ -57,7 +58,10 @@ extern void ctrl_alt_del(void);
* to be used for numbers.
*/
-#if defined(CONFIG_PARISC) && (defined(CONFIG_KEYBOARD_HIL) ||
defined(CONFIG_KEYBOARD_HIL_OLD))
+#ifdef CONFIG_KBD_DEFLEDS_PCBIOS
+/* KBD_DEFLEDS is a variable */
+#undef KBD_DEFLEDS
+#elif defined(CONFIG_PARISC) && (defined(CONFIG_KEYBOARD_HIL) ||
defined(CONFIG_KEYBOARD_HIL_OLD))
#define KBD_DEFLEDS (1 << VC_NUMLOCK)
#else
#define KBD_DEFLEDS 0
@@ -1358,8 +1362,17 @@ int __init kbd_init(void)
{
int i;
int error;
+#ifdef CONFIG_KBD_DEFLEDS_PCBIOS
+ int KBD_DEFLEDS = 0;
+ /* address 0x40:0x17 */
+ char * bios_kbd_status=xlate_dev_mem_ptr(0x417);
+
+ /* Numlock status bit set? */
+ if (*bios_kbd_status & 0x20)
+ KBD_DEFLEDS = 1 << VC_NUMLOCK;
+#endif
-for (i = 0; i < MAX_NR_CONSOLES; i++) {
+ for (i = 0; i < MAX_NR_CONSOLES; i++) {
kbd_table[i].ledflagstate = KBD_DEFLEDS;
kbd_table[i].default_ledflagstate = KBD_DEFLEDS;
kbd_table[i].ledmode = LED_SHOW_FLAGS;
diff -pruN -X dontdiff linux-2.6.23.pure/drivers/input/keyboard/Kconfig
linux-2.6.23.base/drivers/input/keyboard/Kconfig
--- linux-2.6.23.pure/drivers/input/keyboard/Kconfig2007-10-11
14:14:41.0 +0200
+++ linux-2.6.23.base/drivers/input/keyboard/Kconfig2007-12-30
12:11:45.0 +0100
@@ -12,6 +12,17 @@ menuconfig INPUT_KEYBOARD
if INPUT_KEYBOARD
+config KBD_DEFLEDS_PCBIOS
+ bool "Enable Num-Lock based on BIOS settings"
+ depends on X86_PC && EXPERIMENTAL
+ help
+ Turns on Numlock depending on the BIOS settings.
+ This works by reading the BIOS data area as defined for IBM PCs
(1981).
+
+ If you have an alternative firmware like OpenFirmware or LinuxBios,
+ this flag might not be set correctly, which results in a random state
+ of the Numlock key.
+
config KEYBOARD_ATKBD
tristate "AT keyboard" if EMBEDDED || !X86_PC
default y
--
Top 100 things you don't want the sysadmin to say:
39. It is only a minor upgrade, the system should be back up in
a few hours. ( This is said on a monday afternoon.)
--
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/
[PATCH] Get NUMLOCK from PC BIOS
This patch enables reading the default NUMLOCK status from the BIOS data
area as defined for IBM PCs (1981). Using this area has been a reliable way
to detect (or set) the NUMLOCK status for about 27 years, and it will
continue to work on any IBM-compatible system that might run DOS.
Especially, the NUMLOCK status on Linus' famous laptop should be usable.
---
I'd like some information about how this patch works non non-IBM-compatible
x86 PCs. For now, I've documented the wordt possible outcome I can imagine.
Signed-Off-By: Bodo Eggert [EMAIL PROTECTED]
diff -pruN -X dontdiff linux-2.6.23.pure/drivers/char/keyboard.c
linux-2.6.23.base/drivers/char/keyboard.c
--- linux-2.6.23.pure/drivers/char/keyboard.c 2007-10-11 14:15:18.0
+0200
+++ linux-2.6.23.base/drivers/char/keyboard.c 2007-12-30 12:12:11.0
+0100
@@ -24,6 +24,7 @@
* 21-08-02: Converted to input API, major cleanup. (Vojtech Pavlik)
*/
+#include asm/io.h
#include linux/consolemap.h
#include linux/module.h
#include linux/sched.h
@@ -57,7 +58,10 @@ extern void ctrl_alt_del(void);
* to be used for numbers.
*/
-#if defined(CONFIG_PARISC) (defined(CONFIG_KEYBOARD_HIL) ||
defined(CONFIG_KEYBOARD_HIL_OLD))
+#ifdef CONFIG_KBD_DEFLEDS_PCBIOS
+/* KBD_DEFLEDS is a variable */
+#undef KBD_DEFLEDS
+#elif defined(CONFIG_PARISC) (defined(CONFIG_KEYBOARD_HIL) ||
defined(CONFIG_KEYBOARD_HIL_OLD))
#define KBD_DEFLEDS (1 VC_NUMLOCK)
#else
#define KBD_DEFLEDS 0
@@ -1358,8 +1362,17 @@ int __init kbd_init(void)
{
int i;
int error;
+#ifdef CONFIG_KBD_DEFLEDS_PCBIOS
+ int KBD_DEFLEDS = 0;
+ /* address 0x40:0x17 */
+ char * bios_kbd_status=xlate_dev_mem_ptr(0x417);
+
+ /* Numlock status bit set? */
+ if (*bios_kbd_status 0x20)
+ KBD_DEFLEDS = 1 VC_NUMLOCK;
+#endif
-for (i = 0; i MAX_NR_CONSOLES; i++) {
+ for (i = 0; i MAX_NR_CONSOLES; i++) {
kbd_table[i].ledflagstate = KBD_DEFLEDS;
kbd_table[i].default_ledflagstate = KBD_DEFLEDS;
kbd_table[i].ledmode = LED_SHOW_FLAGS;
diff -pruN -X dontdiff linux-2.6.23.pure/drivers/input/keyboard/Kconfig
linux-2.6.23.base/drivers/input/keyboard/Kconfig
--- linux-2.6.23.pure/drivers/input/keyboard/Kconfig2007-10-11
14:14:41.0 +0200
+++ linux-2.6.23.base/drivers/input/keyboard/Kconfig2007-12-30
12:11:45.0 +0100
@@ -12,6 +12,17 @@ menuconfig INPUT_KEYBOARD
if INPUT_KEYBOARD
+config KBD_DEFLEDS_PCBIOS
+ bool Enable Num-Lock based on BIOS settings
+ depends on X86_PC EXPERIMENTAL
+ help
+ Turns on Numlock depending on the BIOS settings.
+ This works by reading the BIOS data area as defined for IBM PCs
(1981).
+
+ If you have an alternative firmware like OpenFirmware or LinuxBios,
+ this flag might not be set correctly, which results in a random state
+ of the Numlock key.
+
config KEYBOARD_ATKBD
tristate AT keyboard if EMBEDDED || !X86_PC
default y
--
Top 100 things you don't want the sysadmin to say:
39. It is only a minor upgrade, the system should be back up in
a few hours. ( This is said on a monday afternoon.)
--
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: provide a DMI based port 0x80 I/O delay override
Ingo Molnar [EMAIL PROTECTED] wrote: do you have any memories about the outb_p() use of misc_32.c: pos = (x + cols * y) * 2; /* Update cursor position */ outb_p(14, vidport); outb_p(0xff (pos 9), vidport+1); outb_p(15, vidport); outb_p(0xff (pos 1), vidport+1); was this ever needed? This is so early in the bootup that can we cannot do any sensible delay. Perhaps we could try a natural delay sequence via inb from 0x3cc: outb(14, vidport); inb(0x3cc); /* delay */ outb(0xff (pos 9), vidport+1); I've never seen code which would do that, and it was not suggested by any tutorial I ever saw. I'd expect any machine to break on all kinds of software if it required this. The only thing I remember being warned about is writing the index and the data register at the same time using outw, because that would write both registers at the same time on 16-bit-cards. BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c uses while(1) without cpu_relax() in order to halt the machine. Is this fixed? Should it be fixed? -- 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: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007, Ingo Molnar wrote: * H. Peter Anvin [EMAIL PROTECTED] wrote: Ingo Molnar wrote: * Bodo Eggert [EMAIL PROTECTED] wrote: BTW: The error function in linux-2.6.23/arch/i386/boot/compressed/misc.c uses while(1) without cpu_relax() in order to halt the machine. Is this fixed? Should it be fixed? this is early bootup so there's no need to be nice to other cores or sockets - none of them are really running. It probably should actually HLT, to avoid sucking power, and stressing the thermal system. We're dead at this point, and the early 486's which had problems with HLT will lock up - we don't care. ok. Like the patch below? - while(1); /* Halt */ + asm(cli; hlt);/* Halt */ The other users would loop around the hlt. Cargo Cult? -- Top 100 things you don't want the sysadmin to say: 97. Go get your backup tape. (You _do_ have a backup tape?) -- 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
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. -- 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: permit link(2) to work across --bind mounts ?
On Wed, 19 Dec 2007, Al Viro wrote: > On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote: > > Since nobody knows about this "security boundary" and everybody knows about > > the annoying "can't link across bind-mountpoints bug", > > ... how about teaching people to RTFM? Starting, perhaps, with man 2 link? What about reading POSIX which says 1264 [EXDEV] 1265 Improper link. A link to a file on another file system was attempted. So if the link creates a file on NOT another filesystem (which is the point of bind mounts), it should NOT return EXDEV. Having an artificial boundary between different views to a fs may happen to be a security feature if used with care, but most users do expect the opposite and wonder why mv is needlessly slow. I'm not even sure if defaulting to having a barrier is sane at all, but if people confuse filesystems and mountpoints^W^W^W^Wuse this feature, they will depend on this feature not changing:-) -- "It is generally inadvisable to eject directly over the area you just bombed." -U.S. Air Force Manual -- 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: permit link(2) to work across --bind mounts ?
On Wed, 19 Dec 2007, Al Viro wrote: On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote: Since nobody knows about this security boundary and everybody knows about the annoying can't link across bind-mountpoints bug, ... how about teaching people to RTFM? Starting, perhaps, with man 2 link? What about reading POSIX which says 1264 [EXDEV] 1265 Improper link. A link to a file on another file system was attempted. So if the link creates a file on NOT another filesystem (which is the point of bind mounts), it should NOT return EXDEV. Having an artificial boundary between different views to a fs may happen to be a security feature if used with care, but most users do expect the opposite and wonder why mv is needlessly slow. I'm not even sure if defaulting to having a barrier is sane at all, but if people confuse filesystems and mountpoints^W^W^W^Wuse this feature, they will depend on this feature not changing:-) -- It is generally inadvisable to eject directly over the area you just bombed. -U.S. Air Force Manual -- 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
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. -- 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: permit link(2) to work across --bind mounts ?
Al Viro <[EMAIL PROTECTED]> wrote: > On Tue, Dec 18, 2007 at 11:00:16PM +, Al Viro wrote: >> On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote: >> > Why does link(2) not support hard-linking across bind mount points >> > of the same underlying filesystem ? >> >> Because it gives you a security boundary around a subtree. > > PS: that had been discussed quite a few times, but to avoid searches: > consider e.g. mount --bind /tmp /tmp; now you've got a situation when > users can't create links to elsewhere no root fs, even though they > have /tmp writable to them. Similar technics works for other isolation > needs - basically, you can confine rename/link to given subtree. IOW, > it's a deliberate feature. Note that you can bind a bunch of trees > into chroot and get predictable restrictions regardless of how the > stuff might get rearranged a year later in the main tree, etc. Since nobody knows about this "security boundary" and everybody knows about the annoying "can't link across bind-mountpoints bug", what about introducing a mount option to allow link()ing? -- 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: permit link(2) to work across --bind mounts ?
Al Viro [EMAIL PROTECTED] wrote: On Tue, Dec 18, 2007 at 11:00:16PM +, Al Viro wrote: On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote: Why does link(2) not support hard-linking across bind mount points of the same underlying filesystem ? Because it gives you a security boundary around a subtree. PS: that had been discussed quite a few times, but to avoid searches: consider e.g. mount --bind /tmp /tmp; now you've got a situation when users can't create links to elsewhere no root fs, even though they have /tmp writable to them. Similar technics works for other isolation needs - basically, you can confine rename/link to given subtree. IOW, it's a deliberate feature. Note that you can bind a bunch of trees into chroot and get predictable restrictions regardless of how the stuff might get rearranged a year later in the main tree, etc. Since nobody knows about this security boundary and everybody knows about the annoying can't link across bind-mountpoints bug, what about introducing a mount option to allow link()ing? -- 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: 1st version of azfs
Maxim Shchetynin <[EMAIL PROTECTED]> wrote: > +config AZ_FS > +tristate "AZFS filesystem support" > +default m ^ STRONG NACK, I hate digging in the menu tree and hunting for things I don't need. > +help > + Non-buffered filesystem for block devices with a gendisk and > + with direct_access() method in gendisk->fops. > + AZFS does not buffer outgoing traffic and is doing no read > ahead. > + AZFS uses block-size and sector-size provided by block > device > + and gendisk's queue. Though mmap() method is available only > if > + block-size equals to or is greater than system page size. What is the benefit or intended use of this filesystem? Will your intended user say "gendisk->fops->direct_access? I wanted to use it all my life"? AZFZ seems to be an acronym. AirZound File System? http://globetrotter.de/de/shop/detail.php?mod_nr=ex_35001=7c553060901a873c5bd29a1846ff39a3a32 -- 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: 1st version of azfs
Maxim Shchetynin [EMAIL PROTECTED] wrote: +config AZ_FS +tristate AZFS filesystem support +default m ^ STRONG NACK, I hate digging in the menu tree and hunting for things I don't need. +help + Non-buffered filesystem for block devices with a gendisk and + with direct_access() method in gendisk-fops. + AZFS does not buffer outgoing traffic and is doing no read ahead. + AZFS uses block-size and sector-size provided by block device + and gendisk's queue. Though mmap() method is available only if + block-size equals to or is greater than system page size. What is the benefit or intended use of this filesystem? Will your intended user say gendisk-fops-direct_access? I wanted to use it all my life? AZFZ seems to be an acronym. AirZound File System? http://globetrotter.de/de/shop/detail.php?mod_nr=ex_35001GTID=7c553060901a873c5bd29a1846ff39a3a32 -- 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] xen: relax signature check
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Some versions of Xen 3.x set their magic number to "xen-3.[12]", so > relax the test to match them. > - BUG_ON(memcmp(xen_start_info->magic, "xen-3.0", 7) != 0); > + BUG_ON(memcmp(xen_start_info->magic, "xen-3", 5) != 0); Not BUG_ON(memcmp(xen_start_info->magic, "xen-3.", 6) != 0); ? I don't thin Xen version 32 will be compatible ... -- 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] xen: relax signature check
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Some versions of Xen 3.x set their magic number to xen-3.[12], so relax the test to match them. - BUG_ON(memcmp(xen_start_info-magic, xen-3.0, 7) != 0); + BUG_ON(memcmp(xen_start_info-magic, xen-3, 5) != 0); Not BUG_ON(memcmp(xen_start_info-magic, xen-3., 6) != 0); ? I don't thin Xen version 32 will be compatible ... -- 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 tree module using LSM
Jon Masters <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-29 at 11:11 -0800, Ray Lee wrote:
>> On Nov 29, 2007 10:56 AM, Jon Masters <[EMAIL PROTECTED]> wrote:
>> > On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
>> > > On Nov 29, 2007 9:36 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
>> > > > > closed. But more importantly further access to it can be blocked
>> > > > > until appropriate actions are taken which also applies with your
>> > > > > example, no? Is
>> > > >
>> > > > That bit is hard- very hard.
>> To lift Alan's example, a naive first implementation
>> would be to create a suffix tree of all of ESR's works, then scan each
>> page on fault to see if there are any partial matches in the tree.
>
> Ah, but I could write a sequence of pages that on their own looked
> garbage, but in reality, when executed would print out a copy of the
> Jargon File in all its glory. And if you still think you could look for
> patterns, how about executable code that self-modifies in random ways
> but when executed as a whole actually has the functionality of fetchmail
> embedded within it? How would you guard against that?
You can't scan all possible code for malware:
Take a random piece of code, possibly halting. Replace all halting conditions
using a piece of malware. Scan it. If it were possible to detect the malware
without false positives, you'd have solved the halting problem.
In practice, this does not hinder virus scanners from preventing most damage.
Therefore I think it's OK to have one.
If I had to design a virus scanner interface, I'd e.g. create a library*
providing an {open|mmap}_and_scan() function that would give me a clean
copy/really-private mapping of a scanned file, and a scan_{blob,file}()
function that would scan a block of memory/a file. Then, it's up to the
application to ensure that it uses that library. As a result, you could
e.g. run "less eicar.sh", but you could not run "bash eicar.sh"**, and an
application receiving a strangely encoded piece of malware into it's
memory has a chance of avoiding an infection without writing it to a file.
Maybe gpg < eicar.gpg.sh|sh will unintendedly work, but I don't think
scanning pipes would be easy anyway. OTOH, maybe the library would make
it feasible at all, provided the malicious code is not located way before
the signature.
Off cause I'd need to do something about binaries. At first glance, this
does not seem too bad, since there is a way to run ld*.so. I'd just use it
to enforce a preloader for static binaries, too. (I'm glad I can leave the
implementation details to somebody else.-)
* Without having a virus scanner installed, this library will just NOOP
by default.
** Bonus: I can unzip open_office_file; rm macros; zip open_office_file.
OTOH, the scanner should provide a cleaner for those simple cases.
--
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 tree module using LSM
Jon Masters [EMAIL PROTECTED] wrote:
On Thu, 2007-11-29 at 11:11 -0800, Ray Lee wrote:
On Nov 29, 2007 10:56 AM, Jon Masters [EMAIL PROTECTED] wrote:
On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
On Nov 29, 2007 9:36 AM, Alan Cox [EMAIL PROTECTED] wrote:
closed. But more importantly further access to it can be blocked
until appropriate actions are taken which also applies with your
example, no? Is
That bit is hard- very hard.
To lift Alan's example, a naive first implementation
would be to create a suffix tree of all of ESR's works, then scan each
page on fault to see if there are any partial matches in the tree.
Ah, but I could write a sequence of pages that on their own looked
garbage, but in reality, when executed would print out a copy of the
Jargon File in all its glory. And if you still think you could look for
patterns, how about executable code that self-modifies in random ways
but when executed as a whole actually has the functionality of fetchmail
embedded within it? How would you guard against that?
You can't scan all possible code for malware:
Take a random piece of code, possibly halting. Replace all halting conditions
using a piece of malware. Scan it. If it were possible to detect the malware
without false positives, you'd have solved the halting problem.
In practice, this does not hinder virus scanners from preventing most damage.
Therefore I think it's OK to have one.
If I had to design a virus scanner interface, I'd e.g. create a library*
providing an {open|mmap}_and_scan() function that would give me a clean
copy/really-private mapping of a scanned file, and a scan_{blob,file}()
function that would scan a block of memory/a file. Then, it's up to the
application to ensure that it uses that library. As a result, you could
e.g. run less eicar.sh, but you could not run bash eicar.sh**, and an
application receiving a strangely encoded piece of malware into it's
memory has a chance of avoiding an infection without writing it to a file.
Maybe gpg eicar.gpg.sh|sh will unintendedly work, but I don't think
scanning pipes would be easy anyway. OTOH, maybe the library would make
it feasible at all, provided the malicious code is not located way before
the signature.
Off cause I'd need to do something about binaries. At first glance, this
does not seem too bad, since there is a way to run ld*.so. I'd just use it
to enforce a preloader for static binaries, too. (I'm glad I can leave the
implementation details to somebody else.-)
* Without having a virus scanner installed, this library will just NOOP
by default.
** Bonus: I can unzip open_office_file; rm macros; zip open_office_file.
OTOH, the scanner should provide a cleaner for those simple cases.
--
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/
